[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Comments on draft-ietf-mmusic-rfc4756bis-03
Hi JF,
Thanks for the quick review. I addressed all of your comments and submitted a new version.
http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-04.txt
Let me know if you have further comments. The diff should be available shortly.
-acbegen
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of Jean-Francois
> Mule
> Sent: Wednesday, October 14, 2009 6:31 PM
> To: draft-ietf-mmusic-rfc4756bis at tools.ietf.org
> Cc: mmusic at ietf.org
> Subject: [MMUSIC] Comments on draft-ietf-mmusic-rfc4756bis-03
>
> 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.
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic