Last Call Review of draft-ietf-rtcweb-audio-10
review-ietf-rtcweb-audio-10-opsdir-lc-baker-2016-03-23-00

Request Review of draft-ietf-rtcweb-audio
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-03-15
Requested 2016-02-27
Authors Jean-Marc Valin, Cary Bran
Draft last updated 2016-03-23
Completed reviews Genart Last Call review of -10 by Ron Bonica (diff)
Secdir Last Call review of -10 by Vincent Roca (diff)
Opsdir Last Call review of -10 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Review review-ietf-rtcweb-audio-10-opsdir-lc-baker-2016-03-23
Reviewed rev. 10 (document currently at 11)
Review result Has Nits
Review completed: 2016-03-23

Review
review-ietf-rtcweb-audio-10-opsdir-lc-baker-2016-03-23

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.

I will start with a disclaimer on my own expertise; the draft has to do with codec requirements - availability of codecs, echo cancelling characteristics, DMTF signals, comfort noise, and so on. I can't say I personally know much about any of those. That said, I don't think network operators deal with those much either; they are part of the payload.

I suspect, therefore, that the draft has little impact that would affect a network operator unless that operator was dealing specifically with a WebRTC application. If the operator is dealing with such an application, the fact that it requires a common codec, and only requires one, seems reasonable. As such, I think the draft is ready with one nit.

The nit point is the reference to I-D.ietf-payload-rtp-opus. That draft has been published as RFC 7587, and should be referred to accordingly.


Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail