I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. My judgement: the document is ready. Understand that my expertise is neither in codecs nor RTCP, and I have not implemented the specification; there may be glaring issues in it from an implementor's perspective for all I know. I'm looking at the issues a network operator would face and need to deal with. My biggest concern, from a network perspective, has to do with congestion. The draft discusses congestion in passing, and calls for "consideration" of the congestion issues and algorithms raised in RFC 5104. The word "consideration" gives me some pause; Admiral Farragut famously "considered" a minefield between his fleet and the harbor at Mobile Alabama, and gave the order "damn the torpedoes, full speed ahead". I'd hope for a stronger word there. Also, the "consideration" in RFC 5104 is for congestion of the feedback path, but not the forward data path (which, if it becomes congested by having too many layers being sent, would reactively reduce its rate sometime later in response to loss or delay in transit). I'm more concerned about the latter, as I suspect an operator might be. However, that ultimately comes down to capacity planning and rate negotiation in SIP or whatever. Ship it, Danno. The authors replied, and we agreed on a text change. -06 should be "ready" from my perspective. Replace The sender MUST consider congestion control as outlined in section 5 of [RFC5104], which MAY restrict its ability to send a layer refresh point quickly. with The sender MUST respect bandwidth limits provided by the application of congestion control, as described in Section 5 of [RFC5104]. As layer refresh points will often be larger than non-refreshing frames, this may restrict a sender’s ability to send a layer refresh point quickly. (Also fixing Ben Campbell’s comment that the MAY in this paragraph shouldn’t be capitalized.)