Session Description Protocol Elements for the Forward Error Correction (FEC) Framework
RFC 6364

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

(David Harrington) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2010-09-22)
No email
send info
These issues came up in a review by Ari Keranen:

4.5. Repair Flows

         sender-info = [ element *( ',' element ) ]

Shouldn't use "'" character in ABNF (same problem in multiple places)

         separator   = "(" | ")" | "<" | ">" | "@"
                       | "," | ";" | ":" | "\" | <">
                       | "/" | "[" | "]" | "?" | "="
                       | "{" | "}" | SP | HT

Should use "/" instead of "|" for alternatives. Should use "HTAB" 
instead of "HT"?

Rules element, name, token, value, and separator are defined twice.

    If the FEC scheme does not require any specific
    information, the 'ss-fssi' and 'fssi' parameters MAY be null and

By "be null" do you mean "not exist" or something else?

6.1. One Source Flow, One Repair Flow and One FEC Scheme

         m=application 30000 udp/fec

change "udp/fec" into "UDP/FEC" to be consistent with sec 4.1.

(Ron Bonica) No Objection

Comment (2010-09-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Concerned that ABNF doesn't validate.


  == Outdated reference: A later version (-10) exists of

  == Outdated reference: draft-ietf-mmusic-rfc4756bis has been published as
     RFC 5956

  == Outdated reference: draft-ietf-mmusic-sdp-capability-negotiation has
     been published as RFC 5939

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-09-22)
No email
send info
Section 4.6., paragraph 3:
>    can be adjusted if there are mising packets at the beginning of the

  Nit: s/mising/missing/

(Adrian Farrel) No Objection

Comment (2010-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
A couple of places in the text refer to "instances of the FEC Framework" (see Abstract, 3.3, etc.). I have trouble understanding this phrase. Can you instantiate a framework or an architecture? Or do you need to name a functional element that is instantiated?

(Russ Housley) No Objection

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2010-09-23)
No email
send info
Section 3.3 copies text from -framework. Would a pointer be sufficient? It would
certainly be easier to maintain should these documents ever be revised.

In the Security Considerations section: It is RECOMMENDED that you SHOULD is redundant.

(Sean Turner) No Objection

Comment (2010-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1) Sec 4.5: Maybe add a reference to where the registration procedures are:

These identifiers MUST be registered with IANA by the FEC schemes that use the FEC Framework [I-D.ietf-fecframe-framework].

2) as pointed out in the SECDIR review:

   5.1.  Declarative Considerations
      In multicast-based applications, the FEC Framework Configuration
      Information pertaining to all FEC protection options available at the
      sender MAY be advertised to the receivers as a part of a session
      announcement.  This way, the sender can let the receivers know all
      available options for FEC protection.  Based on their needs, the
      receivers MAY choose protection provided by one or more FEC Framework
      instances and subscribe to the respective multicast session(s) to
      receive the repair flow(s).  Unless explicitly required by the CDP,
-->   the receivers SHOULD NOT send an answer back to the sender specifying
      their choices since this can easily overwhelm the sender particularly
      in large-scale multicast applications.

Why not "MUST NOT" instead of "SHOULD NOT"?  When would a receiver ever
want to send an answer back to a multicast sender?