Re: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt

[Colin Perkins <[e-mail]>]

On 25 Jan 2013, at 11:16, Harald Alvestrand wrote:
> On 01/17/2013 12:43 PM, Colin Perkins wrote:
>> On 16 Jan 2013, at 21:43, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF.
>>> 
>>> 	Title           : RTP Payload Format for the iSAC Codec
>>> 	Author(s)       : Tina le Grand
>>>                          Paul E. Jones
>>>                          Pascal Huart
>>>                          Turaj Zakizadeh Shabestary
>>>                          Harald Alvestrand
>>> 	Filename        : draft-ietf-avt-rtp-isac-03.txt
>>> 	Pages           : 15
>>> 	Date            : 2013-01-16
>>> 
>>> Abstract:
>>>   iSAC is a proprietary wideband speech and audio codec developed by
>>>   Global IP Solutions (now part of Google), suitable for use in Voice
>>>   over IP applications.  This document describes the payload format for
>>>   iSAC generated bit streams within a Real-Time Protocol (RTP) packet.
>>>   Also included here are the necessary details for the use of iSAC with
>>>   the Session Description Protocol (SDP).
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac
>> 
>> One quick comment: the examples in Sections 6.1 and 6.2 use RFC 2119 language ("SHOULD"), but I don't think an example is the right place to define normative requirements for implementations. Can the RFC 2119 terms be removed from these sections (and possibly be replaced by references to a section where the response is defined)?
>> n
> The normative language corrsponding to these examples is in section 5, where the parameters are defined. This language has been unchanged (including the use of uppercase MAY and SHOULD) since the July 2009 version of this draft, so the comment's definitely late.
> 
> I'll lowercase the terms in the next version; I don't see a need to do so before an IETF Last Call, but will take instructions from the chairs.


Just to be clear: no objections to normative language in Section 5, or in the start of Section 6 where the mapping is defined, but I believe it shouldn't be used in the examples in Sections 6.1 and 6.2.

And no, I don't see any need to do this before IETF last call. It's a nit after all.

-- 
Colin Perkins
http://csperkins.org/