Session Description Protocol Elements for the Forward Error Correction (FEC) Framework
draft-ietf-fecframe-sdp-elements-11

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?

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

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.

Section 4.6., paragraph 3:
>    can be adjusted if there are mising packets at the beginning of the

  Nit: s/mising/missing/

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.

Concerned that ABNF doesn't validate.

NITS

  == Outdated reference: A later version (-10) exists of
     draft-ietf-fecframe-framework-09

  == 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

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?