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

From: [email-masked]
Date: Wed, 16 Jan 2013 13:43:00 -0800

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-isac-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 17 Jan 2013 11:43:41 +0000

> 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)?

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 25 Jan 2013 12:16:11 +0100

On 01/17/2013 12:43 PM, Colin Perkins wrote:
> 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.

            Harald

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Jan 2013 12:05:43 +0000

On 25 Jan 2013, at 11:16, Harald Alvestrand wrote:
> 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/