Last Call Review of draft-ietf-fecframe-sdp-elements-
review-ietf-fecframe-sdp-elements-secdir-lc-williams-2010-09-25-00

Request Review of draft-ietf-fecframe-sdp-elements
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-09-21
Requested 2010-08-30
Authors Ali Begen
Draft last updated 2010-09-25
Completed reviews Secdir Last Call review of -?? by Nicolás Williams
Assignment Reviewer Nicolás Williams 
State Completed
Review review-ietf-fecframe-sdp-elements-secdir-lc-williams-2010-09-25
Review completed: 2010-09-25

Review
review-ietf-fecframe-sdp-elements-secdir-lc-williams-2010-09-25

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 document deals with the encoding of FEC parameters in SDP for
unicast and multicast of video and other media.

Modulo the COMMENTs and DISCUSSes on the datatracker, I believe this
document is ready for publication.  Its security considerations section
appears to me to be complete.

I do have one minor comment regarding this text:

   5.1.  Declarative Considerations
   
      In multicast-based applications, the FEC Framework Configuration
      Information pertaining to all FEC protection options available at the
      sender MAY be advertised to the receivers as a part of a session
      announcement.  This way, the sender can let the receivers know all
      available options for FEC protection.  Based on their needs, the
      receivers MAY choose protection provided by one or more FEC Framework
      instances and subscribe to the respective multicast session(s) to
      receive the repair flow(s).  Unless explicitly required by the CDP,
-->   the receivers SHOULD NOT send an answer back to the sender specifying
      their choices since this can easily overwhelm the sender particularly
      in large-scale multicast applications.

Why not "MUST NOT" instead of "SHOULD NOT"?  When would a receiver ever
want to send an answer back to a multicast sender?

Nico
--