Forward Error Correction Grouping Semantics in Session Description Protocol
draft-ietf-mmusic-fec-grouping-05

Note: This ballot was opened for revision 05 and is now closed.

(Cullen Jennings) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) (was Discuss) No Objection

Comment (2006-09-11)
No email
send info
Adapted from Gen-ART review by Francis Dupont:

 - in 3 page 3 I suggest to add "(RFC YYYY)" (as it is done in 4.1 page 3)
 - in 3 page 3 and in 9.2 page 5 I believe it is "RTP" in place of "RFC"
   (again 4.1 page 3 seems right)
 - I'd like to get the name of the I-D for reference [5], BTW it seems to
   be draft-ietf-avt-ulp

(Lisa Dusseault) (was No Record, No Objection) No Objection

(Lars Eggert) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

Comment (2006-09-12)
No email
send info
Section 3, third paragraph:

   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].

I would like to change this to clear that RFC 2198 is an defined for ULP and not necessarily binding for all future FEC schemes that multiplex data and FEC repair data on the same flow.

   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:

There is a lack of reference in the following: 
                         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.

Please change that to:
                         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.

And move that document into the normative class.