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

Yes

(Cullen Jennings)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Cullen Jennings Former IESG member
Yes
Yes (2006-09-29) Unknown 
Some notes to consider From: "Mark Watson" <mark@digitalfountain.com>

>
> Hi,
>
> The following comments rather minor. Sorry for missing the WG last 
> call:
>
> 1) Section 3, 3rd para, 1st sentence of 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]."
>
> I think RFC2198 is just an example here. The point is that in this 
> case
> the relationship between media and FEC is specified within a single
> media component of the SDP. I suggest the following re-wording:
>
> "When FEC data are multiplexed with the original payload stream, the
> association relationship is generally indicated within a single media
> line, for example as specified in "An RTP Payload for Redundant Audio
> Data" (RFC 2198) [4]."
>
> 2) Section 3, 3rd para, 2nd sentence, "As an example, such 
> relationship
> can be indicated as in the generic RFC payload format for FEC [5]."
>
> I think this should be "This approach is one of the options 
> described in
> "An RTP payload format for generic FEC" [5]."
>
> 3) 4.1, 3rd para, 5th line: the reference to [5] needs to be corrected
> (the title is wrong and the RFC YYYY should be removed or replaced 
> with
> the RFC number if it has been allocated).
>
> 4) 4.2, 2nd para, this paragraph appears to place a "SHOULD" 
> requirement
> on equipment which does not support this draft, which seems rather
> paradoxical. If anything, this paragraph should contain informative 
> text
> which repeats the relevant forward-compatibility requirements of SDP
> (for the case that the grouping attribute is not supported -
> specifically, the attribute is ignored) or of the SDP grouping 
> mechanism
> (for the case that just the FEC semantics are not supported -
> specifically, the behaviour in this case appears to be undefined).
>
> 4) Section 9.2, Reference [5], the title is wrong
>