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 revision | No specific revision (document currently at 11) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2010-09-21 | |
| Requested | 2010-08-30 | |
| Authors | Ali C. Begen | |
| I-D last updated | 2015-10-14 (Latest revision 2010-10-20) | |
| Completed reviews |
Secdir IETF Last Call review of -??
by Nicolás Williams
|
|
| Assignment | Reviewer | Nicolás Williams |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-fecframe-sdp-elements by Security Area Directorate Assigned | |
| Completed | 2010-09-25 |
review-ietf-fecframe-sdp-elements-secdir-lc-williams-2010-09-25-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 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
--