Protocol Action: 'Forward Error Correction Grouping Semantics in Session Description Protocol' to Proposed Standard

[The IESG <iesg-secretary at ietf.org>]

The IESG has approved the following document:

- 'Forward Error Correction Grouping Semantics in Session Description 
   Protocol '
   <draft-ietf-mmusic-fec-grouping-05.txt> as a Proposed Standard

This document is the product of the Multiparty Multimedia Session Control 
Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec-grouping-05.txt

* Technical Summary

This document defines the semantics that allows for grouping of
forward error correction (FEC) streams with the protected payload
streams in Session Description Protocol (SDP). The semantics defined
in this document is to be used with Grouping of Media Lines in the
Session Description Protocol (RFC 3388) to group together "m" lines
in the same session.

* Working Group Summary

The draft is a product of the MMUSIC working group.

* Protocol Quality

The draft extends an existing SDP feature, to support FEC. This 
is an obvious use of the grouping feature, and is needed to support the 
ULP work ongoing in AVT.


* Note to RFC Editor
 

Please change the reference to SDP (reference [3]) from informative to
normative.

Please consider the Gen-ART comments - they all look like good
improvements. 

Section 3, third paragraph:

Old
  When FEC data are multiplexed with the original payload stream, the
  association relationship is indicated as specified in RTP Payload for
  Redundant Audio Data (RFC 2198) [4]. As an example, such relationship
  can be indicated as in the generic RFC payload format for FEC [5].

New
  When FEC data are multiplexed with the original payload stream, the
  association relationship may for example be indicated as specified in
  RTP Payload for Redundant Audio Data (RFC 2198) [4].  The generic RFC 
  payload format for FEC [5] uses that method. 
  
Section 5:

Old: 
  It is recommended that the receiver
  SHOULD do integrity check on SDP and follow the security
  considerations of SDP to only trust SDP from trusted sources.

New:
  It is recommended that the receiver
  SHOULD do integrity check on SDP and follow the   security
  considerations of SDP [3] to only trust SDP from trusted sources.


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce