Last Call Review of draft-ietf-avtext-lrr-05
review-ietf-avtext-lrr-05-opsdir-lc-baker-2017-06-07-00

Request Review of draft-ietf-avtext-lrr
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-06-08
Requested 2017-05-25
Draft last updated 2017-06-07
Completed reviews Secdir Last Call review of -05 by Tero Kivinen (diff)
Opsdir Last Call review of -05 by Fred Baker (diff)
Genart Last Call review of -05 by Roni Even (diff)
Assignment Reviewer Fred Baker
State Completed
Review review-ietf-avtext-lrr-05-opsdir-lc-baker-2017-06-07
Reviewed rev. 05 (document currently at 07)
Review result Has Nits
Review completed: 2017-06-07

Review
review-ietf-avtext-lrr-05-opsdir-lc-baker-2017-06-07

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