Forward Error Correction Grouping Semantics in the Session Description Protocol
RFC 5956

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

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) (was Discuss) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-04-20)
No email
send info
Section 1., paragraph 1:
>    Any application that needs a reliable transmission over an unreliable
>    packet network has to cope with packet losses.  Forward Error
>    Correction (FEC) is an effective approach that provides reliable
>    transmission particularly in multicast and broadcast applications
>    where the feedback from the receiver(s) is potentially limited.

  FEC doesn't provide complete reliability - it provides *improved*
  reliability under loss (compared to no FEC), but only to a certain
  loss rate.


Section 3., paragraph 0:
> 3.  Requirements and Changes from RFC 4756

  It would be good to also discuss how exactly this document updates
  3388bis and 5576. (3388bis is mentioned, but at least to me it's
  unclear what the update here is; 5576 is not mentioned.)

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-04-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The -08 revision addresses nearly everything from my previous Discuss and Comment.

In my Discuss I said:

>> Section 3.2
>> It is not clear from reading this section how there is 
>> any "Requirement and Changes from RFC 4756" described.
>> I presume that [I-D.ietf-fecframe-framework] describes
>> something that cannot be provided by RFC 4756. The text
>> should say so!

Ali reponded:

> 4756 did not have semantics to define/specify additive
> repair flows.

I understand, but my problem is that the text in this section does not say what is new or different from 4756, and does not state that the description of additivity summarised in this section is a feature added by this document.

I would fix this as (changes in first and last paragraph)...

   The FEC Framework [I-D.ietf-fecframe-framework] also describes 
   support for additive repair flows.  Additivity among the repair flows
   means that multiple repair flows may be decoded jointly to improve
   the recovery chances of the missing packets in a single or the same
   set of source flows.  Additive repair flows can be generated by the
   same FEC scheme or different FEC schemes.

   For example, in Figure 3, repair flows R5 and R6 may be additive
   within the FEC Framework instance #1.  Alternatively, all three
   repair flows R5, R6 and R7 could be additive, too.

           SOURCE FLOWS              | FEC FRAMEWORK INSTANCE #1
           S4: Source Flow |---------| R5: Repair Flow
                           |         | R6: Repair Flow
                           |
                           |---------| FEC FRAMEWORK INSTANCE #2
                                     | R7: Repair Flow

    Figure 3: Example scenario with two FEC Framework instances, where
    two repair flows in the first instance and a single repair flow in
            the second instance protect the same source flow S4

   This document defines the mechanisms to support additive flows that
   were not included in [RFC4756].

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2010-04-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the Gen-ART Review comments from David Black:

  The IPv4 addresses used in the examples are not from the 192.0.2.0/24
  block of addresses for examples - they appear to be IP Multicast
  addresses, and I'm not sure what IP Multicast addresses are
  appropriate for use in examples.

  The 3388bis entry on the Updates: line on the title page is novel.
  Please add an RFC Editor Note to the Abstract asking the RFC Editor
  to replace that with the RFC number assigned to 
  draft-ietf-mmusic-rfc3388bis-04 when it is published.

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2010-04-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Alexey's discuss with respect to section 4.4.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-04-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please spell out "SSRC" on first use.

The text "It is RECOMMENDED that the receiver SHOULD do integrity check" is conformance language overload; it is sufficient to say "The receiver SHOULD perform integrity checks..."

(Sean Turner) No Objection

Comment (2010-04-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Two nits on the security considerations:

1) r/failure of FEC to protect, and/or mishandling of other media payload streams/failure of FEC to protect, and/or mishandle other media payload streams

2) r/do integrity check/do an integrity check