[MMUSIC] Comments on draft-ietf-mmusic-rfc4756bis-03

["Jean-Francois Mule" <jf.mule at cablelabs.com>]

Ali,

   The draft is well written and provides clear justifications for the
updates to RFC 4756.

   Below are a few comments for your consideration.

Regards,
Jean-Francois.

- Document frontpage:
Given this draft extends the group and ssrc-group attributes with new
semantics (a=group:FEC-XR, a=ssrc-group:FEC-XR), the boiler plate should
indicate that this document does update RFC 3388bis and RFC 5576, I
think. 

- page 4, para 4: typo
s/the grouping semantics defined in this document offers flexibility
about which source streams can be grouped together prior to FEC
protection/ the grouping semantics defined in this document offer the
flexibility to determine how source streams are grouped together prior
to applying FEC protection

- page 5, numbered bullets 
(see next comment)
a) You summarize a few FEC framework requirements.  
I suppose they are contained in the document, if so put the document
reference [].
b) I'm not sure about this comment but I wonder whether these
requirements should be included with the capital verbs here. I would
turns those MAY into may, as they are duplicate requirements in the FEC
framework and implementations compliant with this draft would not need
to meet those as stated (see the comment below).  You only drive the one
SDP grouping semantics requirement you have below them (as a MUST).

- page 5, last sentence of section 1
Change the requirement to be more explicit on what the SDP semantics
must be able to express (and I would split bullet 3 into two bullets).
As written, the reader has to translate what the FEC requirements mean
for the SDP semantics (in reference to "these features").
Old text:
---
To summarize, the FEC Framework supports the following:
   1.  A source flow MAY be protected by multiple different FEC schemes.
   2.  An FEC scheme MAY generate multiple repair flows.
   3.  Source flows MAY be grouped prior to FEC protection.  That is,
       one or more repair flows MAY protect a group of source flows.

   To fully benefit from the flexibility provided by the FEC Framework,
   the grouping semantics for FEC MUST support these features.
---

New text:
In summary, based on the FEC Framework [], the SDP grouping semantics
for FEC MUST support the ability to indicate that:
   1.  a given source flow is protected by multiple different FEC
schemes.
   2.  multiple repair flows are associated with a given source flow
   3.  multiple source flows are grouped prior to applying FEC
protection
   4.  one or more repair flows protect a group of source flows.
--- or something like that.

- page 5, section 3
The text in section 3 should be written as if it is the new
to-be-published RFC. You should assume the draft is the RFC that
obsoletes RFC 4756 and explain what motivated some changes and
extensions.  
This leads to a few editorial changes, some of which are suggested
below.

s/issues with RFC 4756/changes from RFC 4756 (in the section 3 heading)

- page 5, section 3.1
Consider presenting what this document defines first, and finish with
the changes from previous RFCs.  

Example:
--- old text
   Currently, the 'group' attribute and the FEC grouping semantics
   defined in [RFC3388] and [RFC4756], respectively, are used to
   associate source and repair flows together.

   The 'group' attribute is used to group multiple repair flows with one
   or more source flows.  However, [RFC3388] prohibits an "m" line
   identified by its 'mid' attribute from appearing in more than one
   "a=group" line using the same semantics.  This limitation prevents us
   from indicating specific associations between the source and repair
   flows by using an "a=group:FEC" line per FEC Framework instance.  For
   example, for the scenario sketched in Figure 1, [RFC3388] mandates us
   to write

        a=group:FEC S1 S2 R1 R2

   Clearly, this "a=group:FEC" line does not say anything specific about
   which repair flows are protecting which source flows.

   A new work ([I-D.ietf-mmusic-rfc3388bis]) is currently in progress in
   the MMUSIC WG to remove this limitation in [RFC3388].  However,
   [RFC4756] also needs to be updated according to the FEC Framework
   requirements.

--- new text
   The FEC grouping semantics and 'group' attribute
   defined in this document and [RFC3388bis], respectively, are used to
   associate source and repair flows together.

   This document specifies how the SDP 'group' attribute is used to 
   group multiple repair flows with one or more source flows.  
   [I-D.ietf-mmusic-rfc3388bis] updates [RFC3388]
   to allow an "m" line identified by its 'mid' attribute to appear in
   more than one "a=group" line using the same semantics. This change
   allows us a sender to indicate the specific associations between the
   source and repair flows by using an "a=group:FEC" line per FEC
   Framework instance. 
   
// change the example to show the above and how the 3388bis helps

   This document updates [RFC4756] to allow the source and repair flows
   to be associated in SDP.

--- hope this helps convey what the text should look like expressing the
same things.

- section 4.1, bottom of page 6, first 2 paragraphs of page 7
This is where having some formal MUST requirements for compliant
implementations would be beneficial.

Change:
   If there are more than one
   repair flows included in an FEC group, they are considered to be
   additive.  Repair flows that are in different FEC groups are non-
   additive.

Into something like:
   Repair flows included in the same FEC Group MUST be additive. And
   repair flows that are not additive MUST be indicated in separate
   SDP FEC group lines.

- page 8, section 4.2
s/MUST/must in "we MUST write" 
(you have now a formal requirement in section 4.1)

- page 8, section 4.3
Change:
< Instead, the 'ssrc-group' attribute MUST be used.
With
> This document extends [RFC 5576] in two ways.  First we define how FEC
is applied to source and repair flows for SSRC multiplexed streams using
the 'ssrc-group' attribute.  We then specify how additivity of the
repair flows are expressed for SSRC multiplexed streams.

- page 8, last paragraph of section 4.3
Same comment as above for the "a=group" lines: it would be good to have
2 MUST requirements to indicate that additive repairs flows MUST be on
the same a=ssrc-group lines while non-additive ones MUST be on separate
lines.

- page 9, section 4.4., last paragraph at the bottom of page 9
I would not point to RFC4756 but instead point to this draft (from my
perspective, it does not make much sense to ask implementers to first
check that there is no ambiguity with the previous RFC.

- page 10, para 3:
Same comment as above.
 
- section 4.4 and backward compatibility
Given the new tokens you define (FEC-XR), there is no backward
compatibility issues. Section 4.4 explains how to cope with situations
when the remote party only understands RFC 4756.
Should this section be called "SDP Offer/Answer and backward
compatibility considerations"?

- aBNF?
Would it be beneficial to have a new BNF for the SDP attributes you
extend?
e..g
         
       group-attribute    = "a=group:" semantics  ; from [RFC3388bis]
                             *(space identification-tag)
        semantics          = "LS" / "FID" / 
                             "FEC" /               ; from RFC 4756 for
backward compatibility
                             "FEC-XR"               ; this RFC


> -----Original Message-----
> From: Jean-Francois Mule
> Sent: Wednesday, October 14, 2009 10:10 AM
> To: mmusic at ietf.org
> Cc: 'draft-ietf-mmusic-rfc4756bis at tools.ietf.org'; Joerg Ott
> Subject: WGLC on draft-ietf-mmusic-rfc4756bis-03
> 
> This is to start a 2-week working group last call on draft draft-
> ietf-mmusic-rfc4756bis-03, http://tools.ietf.org/html/draft-ietf-
> mmusic-rfc4756bis-03.  The comment period will end on Wednesday
> October 28.
> 
> Please send your comments to the mmusic list and the authors.
> 
> Thank you,
> Jean-Francois.
>