Reviewer: Fred Baker
Review result: Has Nits
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.)