RTP Payload Format for Generic Forward Error Correction
Note: This ballot was opened for revision 23 and is now closed.
(Cullen Jennings) Yes
Magnus Westerlund Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
Francis Dupont noted several editorial issues in his Gen-ART Review.
(Jon Peterson) No Objection
Comment (2007-05-10 for -** No value found for 'p.get_dochistory.rev' **)
In the MIME type registrations, especially in 13.3 (for text/ulpfec), it might be appropriate for the applicability section ("Applications which use this media type") to state something other than "Audio and video streaming tools" based on the MIME type being registered.
(Tim Polk) No Objection
(Dan Romascanu) (was Discuss) No Objection
The document lacks operational considerations information. The aspects that require clarification are the implications of the lack of backwards compatibility of the payload defined in this document with RFC 2733 and RFC 3009. A clarification was added in draft-22 about the fact that there are no interoperability issues, but yet there is no information or recommendations on the operational aspects of the transition between one version to the other. Do all hosts need to be upgraded simmultaneously if 2733 and 3009 are deployed, what will work and what will not work between two hosts that implement two different versions and is there a recommended strategy or scenarios of transition?