RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
RFC 6884

Note: This ballot was opened for revision 08 and is now closed.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-12-19 for -09)
No email
send info

- 6.1: What is the MMM field? Seems to be missing a reference
there.

- section 16: I would encourage you to expand on the reference
to rfc 6562 to say that this codec, like all variable bit rate
codecs, might expose speech even if the flows are strongly
encrypted.

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-12-17 for -09)
No email
send info
  Please consider the editorial suggestions in the Gen-ART Review
  by Peter Yee on 12-Dec-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07985.html

Barry Leiba (was Discuss) No Objection

Comment (2013-01-21)
No email
send info
The -10 version addresses my concern about which version of the 3GPP2 document you're citing.  And IANA has already recorded that they will use this RFC as the registered reference for the audio media types, so my other DISCUSS point is covered.

But (and this is non-blocking) I would still like to see a URL: in Section 17.1, reference [4], can you please add a URL for the 3GPP2 document?  Here's where I found it:
http://www.3gpp2.org/public_html/specs/C.S0014-D_v3.0_EVRC.pdf

If you need xml2rfc code to do this, I can help; send me email.  Or it can be put in as an RFC Editor note, and the RFC Editor will take care of it.

(Pete Resnick) No Objection

Comment (2012-12-19 for -09)
No email
send info
Question off the top: Are there no implementations using this now? None were indicated in the shepherd writeup.

Section 5:

   The RTP header marker bit (M) SHALL be set to 1 if the first frame
   carried in the packet contains a speech frame which is the first in a
   talkspurt.  For all other packets the marker bit SHALL be set to zero
   (M=0).

Those SHALLs are meaningless. They should be changed to "will".

Section 6:

   1.  the mode change request field in the interleaved/bundled packet
       format MUST be interpreted according to the definition of the
       RATE_REDUC parameter as defined in EVRC-NW [4].

I don't understand what protocol requirement or interoperability consideration is contained in "MUST be interpreted". Please explain.

   2.  the mode change request field in the interleaved/bundled packet
       format SHOULD be honored by an EVRCNW encoding end point in an
       one-to-one session with a dedicated EVRCNW decoding end point
       such as in a two-party call or in a conference leg.
    
What would it mean to violate the SHOULD? I don't understand what this means.

Section 7:

   Congestion control for RTP SHALL be used in accordance with RFC 3550
   [5], and with any applicable RTP profile, e.g., RFC 3551 [7].

That SHALL doesn't seem useful. Should this simply be, "Congestion control for RTP is discussed in RFC 3550, and in applicable RTP profiles, e.g., RFC 3551. This document does not change those considerations."?

Section 9:

Generally, 2119 language in IANA Considerations is a problem. If it's a protocol requirement, put that in the body of the protocol; don't hide it in IANA Considerations. If it's instructions to IANA, that's not an appropriate use. So, for example:

9.1.1:

   maxinterleave: Maximum number for interleaving length (field LLL in
   the Interleaving Octet)[0..7].  The interleaving lengths used in the
   entire session MUST NOT exceed this maximum value.  If not signaled,
   the maxinterleave length MUST be 5.

You are defining maxinterleave. I presume the limitations on length are explained in [4]. Just make a reference to [4]; don't say MUST/MUST NOT here.

   When this media type is used in the context of transfer over RTP, the
   RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
   used.  In all other contexts, the file format defined in Section 8 of
   RFC XXXX SHALL be used.  See Section 6 of RFC XXXX for details for
   EVRC-NW.
   
Instead:

   This media type can be used with the file format defined in section
   8 of RFC XXXX is used in contexts other than RTP. In context of
   transfers over RTP, the RTP payload format specified in section 4.1
   of RFC 3558 is used for this media type.

If the restriction in usage needs to be called out for interoperability purposes, that belongs elsewhere.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection