Skip to main content

Last Call Review of draft-ietf-avtcore-avp-codecs-02
review-ietf-avtcore-avp-codecs-02-secdir-lc-perlman-2013-06-07-00

Request Review of draft-ietf-avtcore-avp-codecs
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-11
Requested 2013-05-30
Authors Timothy Terriberry
Draft last updated 2013-06-07
Completed reviews Genart Last Call review of -02 by Brian E. Carpenter (diff)
Genart Telechat review of -02 by Brian E. Carpenter (diff)
Secdir Last Call review of -02 by Radia Perlman (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-avtcore-avp-codecs-02-secdir-lc-perlman-2013-06-07
Reviewed revision 02 (document currently at 03)
Result Has Nits
Completed 2013-06-07
review-ietf-avtcore-avp-codecs-02-secdir-lc-perlman-2013-06-07-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This is a completely harmless editorial update of another document (RFC 3551]
to replace the paragraph

   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol.

 with

   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload type 0 (PCMU).  This allows
   interoperability without format negotiation and ensures successful
   negotiation with a conference control protocol.  Some environments
   REQUIRE support for PCMU.

There are certainly no security implications (as correctly noted in this draft).

My only question is...shouldn't this be an actual updated document, rather than
a tiny document saying "replace this paragraph with this other paragraph"?
 Surely we wouldn't make this document an RFC rather than simply replacing RFC
3551 with an updated RFC?

Radia