Forward Error Correction Grouping Semantics in the Session Description Protocol
draft-ietf-mmusic-rfc4756bis-10

[Ballot comment]
1) there are so many conditionals in 4.4 amd 4.5, it becomes hard to tell what behavior is MUST, SHOULD, or MAY. Could this be simplified with a diagram or improved indentation levels?

[Ballot discuss]
1) The new section 4.4 deprecates the FEC semantics, and it says "FEC-FR must be used instead; it then recommends also supporting FEC for backwards compatibility. And later says "the FEC semantics may be offered". This seems very inconsistent. Should FEC-FR be a "MUST implement" and "SHOULD use"?

2) in 4.5, "SHOULD respond was changed to "responds"; I think that should be "MUST respond"

3) in 4.4. and 4.5, the new text uses RFC2119 keywords in lowercase; uppercase is less ambiguous about the intention.

4) the RFC2119 keywords in the last paragraph of 4.5 are inconsistent with the RFC2119 language in earlier paragraphs. For example, the bullet "with an answer that ignores the grouping attribute" was changed from MUST send to SHOULD send (personally I think this should still be a MUST to ensure consistent bahvaiors, but I didn't follow the discussions that led to the change to SHOULD send). The last paragraph however still says "must send". As mentioned in my point#1, the language in 4.4 also seems inconsistent regarding RFC2119 keywords.

[Ballot comment]
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].

[Ballot comment]
A number of minor nits that you might fix to save the RFC Editor some
time and effort.

---
Throughout the document, please note that "semantics" should be used as
a plural.

---
Abstract
s/are more than one/is more than one/
s/repair flows/repair flow/
---
Abstract
Expand SSRC
--
Section 1
OLD
  receivers choose receiving
NEW ??
  receivers choose to receive
---
Section 1
Expand SSRC
---
Section 3.1
OLD
  associate source and repair flows together
NEW
  associate source and repair flows
---
Section 3.1
  This document also
  specifies how the 'group' attribute in SDP is used to group multiple
  repair flows with one or more source flows.
Please insert reference for the 'group' attribute.
---
Section 4.1
OLD
  If there are more than one repair flows
NEW
  If there is more than one repair flow
---
Section 4.1
s/transitive relation/transitive relationship/
---
Section 4.2
OLD
  If none of the repair flows are additive
NEW
  If none of the repair flows is additive

[Ballot discuss]
Two of my Discuss issues overlap somewhat with points raised by other ADs. I hope they can all be addressed with relatively small text changes.

---
RFC 4756 needs to be a normative reference (how else can you update it)

I would think that RFC 3388 should also be a normative reference since
I-D.ietf-mmusic-rfc3388bis is updated and itself updates RFC 3388.
                                                                     
---
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!

---
Section 4.3
  Thus, the 'ssrc-group' attribute MUST only be used at the
  media level [RFC5576].

This is fine, but you should describe (presumably with a simple
reference to 5576 error handling) what a receiver does if the
'ssrc-group' attribute is used at some other level.

---
Section 4.4

I find the backward compatibility section confusing. There seems to be a
fix of "does not understand" and "does not support". These are subtly
different cases (although the former inevitably encompasses the latter).

For "does not understand" I do not believe that this document can define
new behaviour. This is because the failure to understand indicates a
legacy implementation that will not implement any of this specification.
Thus, your description must give reference to some pre-existing
specification, and must describe what will happen according to that
specification (not what SHOULD happen according to this sepcification).

If you wish to allow a node that supports this specification (i.e.
"understads") to "not support" the function. Then this is a matter for
new specification. It is not a backward compatibility function, and
should be described in a separate section of the document.

[Ballot discuss]
With respect to having this document update RFC3388bis, I guess the reason is that Section 4.5 of this document updates the ABNF syntax of the group attribute by adding the new semantics values. The thing is that the complete ABNF syntax for that attribute would need to include all the semantics that have been registered by the IANA so far:

http://www.iana.org/assignments/sdp-parameters

I do not think it makes sense to update the ABNF syntax. Other RFCs that have defined semantics values in the past have not done that. My suggestion would be to remove Section 4.5 and avoid having this document update RFC3388bis.

Also, the last line of Section 4.5 contains a normative statement that is already present in Section 4 of RFC3388bis. That statement should be removed as well while removing the whole Section 4.5.

[Ballot comment]
1) "It should be noted that" - if you include the rest of the sentence, then it IS noted, so this clause can be eliminated.

[Ballot discuss]
1) I would like to support Lars's discuss regarding 3833bis - why is 3833bis simply not modified to include the grouping semantics?

2) "the FEC framework requires the source and repair packets to be carried in different streams." Can you provide a reference for that statement? I'm new to fecframe, but I read the framework and missed where it said that.

3) If fecframe DOES require this, I will want to understand why it is REQUIRED, and why this spec should be allowed to ignore the requirement.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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.)

[Ballot discuss]
INTRODUCTION, paragraph 1:
> Updates:  4756, 3388bis, 5576 (if approved)

  DISCUSS: I'd like to dissect the relationships between these documents
  for a bit. First, does this ID really update 4756, but does not
  obsolete it? I'm no media expert, but the way I read it, this seems to
  be a complete replacement for 4756. Second, why is this document
  updating a yet-to-be-published ID? It would be much less confusing if
  3388bis were modified to directly include the changes that this
  document makes to it.

[Ballot comment]
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..."

[Ballot discuss]
I have a couple of comments I would like to discuss before recommending approval of this document:

1) 4.4.  SDP Offer-Answer Model and Backward Compatibility Considerations

  When a node is offered a session with the "FEC-FR" grouping semantics
  but it does not support line grouping or the FEC grouping semantics,
  the node SHOULD respond to the offer either:

How can a document put a requirement on an implementation that doesn't comply with this document? I think the possible responses listed later in this section just follow generic behaviour for a responder that doesn't understand the offer. (Please correct me if this is not correct.) If that is the case, then I think you need to replace the uppercased SHOULD with an informative text, ideally pointing to the document that defines the behaviour.

  However, if the node does not understand the "FEC" semantics, it
  SHOULD respond to the offer either (1) with an answer that ignores
  the grouping attribute, or (2) with a refusal to the request.  In the
  first case, the sender MUST send a new offer without FEC.

As above.

2) 4.5.  ABNF Syntax:

      group-attribute = "a=group:" semantics
                        *(space identification-tag)

I can't find the document where  is defined.

            semantics = "LS" / "FID" /
                        "FEC" /      ; from [RFC4756] for backward
                                      ; compatibility
                        "FEC-FR"    ; from [RFCXXXX]

    identification-tag = token

You should specify where  is defined. I think you meant RFC 4566.
Please add an ABNF comment to make the clear.

IANA comments:

ACTION 1:

Make the following assignment in the "Semantics for the 'group' SDP
Attribute" registry at
http://www.iana.org/assignments/sdp-parameters

Semantics Token Reference
---------------------------------- -------- ---------
Forward Error Correction FR FEC-FR [RFC-mmusic-rfc4756bis-06]


ACTION 2:

Make the following assignment in the "Semantics for the 'ssrc-group'
SDP Attribute" registry at
http://www.iana.org/assignments/sdp-parameters

Token Semantics Reference
---------- --------------------------------------- ---------
FEC-FR Forward Error Correction
[RFC-mmusic-rfc4756bis-06]

Requested Publication Status: Proposed Standard
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)

--------------------------------------------------------------------
--- (1.a)
          Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the Document Shepherd. He has personally reviewed this version of the Internet-Draft. This Internet-Draft document is ready for forwarding to the IESG for publication.


--- (1.b)
          Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has received several reviews in both the MMUSIC WG (Colin Perkins, Roni Even, Thomas Schierl and Jean-Francois Mule) and the FEC Frame WG (UlaĹ� C. Kozat).  Jonathan Lennox also contributed to section 4.3.

The comments show sufficient reviews, no concerns.

A few minor typos and nits remain that can be corrected in the next revision:
- s/the semantics that was defined in RFC 4756 generally fail/the semantics defined in RFC 4756 generally fail
- s/Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this    purpose./At the time of publication of this document, SDP [RFC4566] uses [I-D.ietf-mmusic-rfc3388bis] and this RFC [RFCXXXX] for this    purpose.
        Note to the RFC Editor:  In the above, please replace "XXXX" with
        the number of this document prior to publication as an RFC.
- s/When Real-time Transport Protocol (RTP) [RFC3550] is used to carry
/ When the Real-time Transport Protocol (RTP) [RFC3550] is used to carry
- to conform with RFC 5234, on page 11, in the aBNF declarations:
s/space/WSP
so the new aBNF should look like this:
group-attribute = "a=group:" semantics *(WSP identification-tag)
semantics = "LS" / "FID" /
                    "FEC" /; from [RFC4756] for backward compatibility
                    "FEC-XR" ; from [RFCXXXX]
identification-tag = token


--- (1.c)
          Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

--- (1.d)

        Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. 
No concerns.

        Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No IPR disclosures have been filed.
Checked the IETF IPR Search Tool on both the ID submitted for publication () and RFC 4756 on 1/14/2010. Both searches returned zero.


--- (1.e) 
          How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is WG consensus for publication.

--- (1.f)
        Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

--- (1.g)
          Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the
          document met all formal review criteria it needs to, such as
          the MIB Doctor, media type and URI type reviews?


Yes, checked draft-05 with idnits 2.11.16.
There are 3 warnings which are ok at this stage: one for the date, two for references (RFCXXX and one outdated ID reference).


--- (1.h)
        Has the document split its references into normative and
        informative? 
Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion? 
There is one normative reference that is not yet an RFC, it is draft-ietf-mmusic-rfc3388bis.  This document has been through IESG review on version -03, and a recent update was submitted.  Given the authors' work on rfcv3388bis, the strategy to complete the work and close the ID is set.  No risks identified there.


        Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
No.  RFC 3388bis is going for Proposed Standard and other normative references are fine.


--- (1.i)
        Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document? 
Yes.

If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?
Yes.

        Are the IANA registries clearly identified?
Yes.

        If the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?
No.


--- (1.j)
          Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes, checked abnf with http://tools.ietf.org/tools/bap/abnf.cgi and the following aBNF contains no error (the author is requested to replace space by WSP as noted above):

group-attribute = "a=group:" semantics *(WSP identification-tag)
semantics = "LS" / "FID" /
                    "FEC" /; from [RFC4756] for backward compatibility
                    "FEC-XR" ; from [RFCXXXX]
identification-tag = token

--- (1.k)
        The IESG approval announcement includes a Document
        Announcement Write-Up. 

Here is the proposed Document Announcement Write-Up:

        Technical Summary
This document defines semantics for grouping the associated source and Forward Error Correction (FEC) repair flows in the Session Description Protocol (SDP).  It obsoletes the previous RFC 4756 that defines FEC grouping semantics in SDP by adding the three main capabilities:
a) It is now possible to indicate more than one source and/or repair flows in the same SDP group, and
b) Additive repair flows can be sufficiently described, and,
c) SSRC-level grouping of FEC flows is now possible for SSRC-multiplexed RTP streams.


          Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a Proposed Standard.

          Document Quality
The document has received several reviews in both the MMUSIC WG (Colin Perkins, Roni Even, and Thomas Schierl) and the FEC Frame WG (Ula� C. Kozat).

   
      Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Robert Sparks.