RTP Payload Format for G.711.0
draft-ietf-payload-g7110-06

Joel holds a DISCUSS for the OPS-DIR review.

I want to thank David Black for an extensive review of this document, as well as the authors for working diligently through some of the points raised. The discussion is still ongoing, but I see Joel has already a Discuss raised to ensure that the resolutions get completed. Thank you. I am interested in the resolutions, but I do not plan to hold another Discuss for the same topic.

Thanks for adding text on the output buffer overrun risk and your explanation as to why no reference is needed to RFC6562 (Guidelines for the Use of Variable Bit Rate Audio with Secure RTP).

I can't say I truly understand the technology in G.711.0 (let alone G.711), but I am still left to wonder why section 3 is in this document. I would expect any implementer is going to have to read the G.711 specs anyway in order to produce the data, and section 3 just seems to repeat information you could get from there. Maybe there's something in section 3.3.1 which adds something specific to RTP, but otherwise, I don't understand. Can this be deleted? (Nobody ever wants to delete things from documents.)

Throughout: I always find the "we" language jarring. "We" in this case is the WG, and that just comes out sounding bizzarre. Instead of "we note", use "note that". Instead of "In this section we describe", say "This section describes". Etc. Please change this.

3.3: Hiding a MUST inside a figure is a really bad idea. Luckily, the MUST is useless. Change "MUST be" to "is" and you're fine.

3.3.1: Change "MUST be supported" to "are always supported".

Except for the one in section 5.3, you really should change all "MAY"s to "can"s. The one is section 4.2.1 and the one at the end of section 4.2.2 are harmless but useless. The one at the beginning of 4.2.2 is a bit more problematic: As written "MAY be any integer multiple of 5 ms" means that it also MAY be 23 ms (because having it be a multiple of 5 ms is OPTIONAL). If you want this to be a requirement, perhaps you mean, "MUST be any integer multiple of 5 ms", but I think "can" is correct. The one at the end of 4.2.4 cracks me up. Speaking of which:

4.2.4:

   When SDP is used, the number of
   channels is known because the optional parameter is a MUST when there
   is more than one channel negotiated (see Section 5.1).  Additionally,
   when SDP is used the parameter ptime is a RECOMMENDED optional
   parameter.

OK, I have to say, using MUST as a noun would be pretty funny by itself, but also getting in a "RECOMMENDED optional parameter" is just adorable! :-D Do you simply mean the following?:

   When SDP is used, the number of channels is known because the
   channels parameter is always present when there is more than one
   channel negotiated (see Section 5.1).  Additionally, when SDP is used
   the parameter ptime is normally present.
   
I think that's simpler and clearer.

I agree with Kathleen's DISCUSS following up on the
secdir review.