Re: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03

[Paul Kyzivat <[e-mail]>]

When the request for review of this came out, I deferred because I knew 
nothing of flute. After seeing Christer's comments I was motivated to 
take a look.

I see many issues here, over and above those that Christer identified:

First, IIUC flute is intended primarily for use with multicast, though 
its spec says it can also be used with unicast. This bias towards 
multicast shows in this document. The examples are all multicast, and 
unicast is mentioned only twice.

Also, offer/answer is only mentioned in passing. There is no discussion 
of how all the constructs defined in this document should work in an O/A 
usage. I'm pretty sure they won't work.

Of course this isn't necessarily a problem if this functionality is not 
intended for use in O/A. But if that is the case then it needs to be 
clearly spelled out. If it *is* intended to be used with O/A, and 
especially with O/A negotiation of unicast, then a lot more work is 
needed to specify how this will work.

As Christer noted, the Composite Session grouping defined here seems to 
be addressing much the same problem as BUNDLE and MMT. But of course it 
has a somewhat different spin on things. This grouping introduces an 
another level of attribute inheritance that is kind of "interesting". It 
shares the problem of when and how to aggregate attribute values in the 
group, but only addresses it for a few attributes.  IMO we *really* 
don't want a bunch of grouping mechanisms, each focused on a different 
application.

This spec has a need to identify the source address. It repurposes 
a=source-address to satisfy this need. This use is quite different from 
the intended use. Because of limitations on source addresses for flute, 
it imposes limitations on the use of the a=source-address attribute. 
(See section 3.3.) I think these limitations may break using 
source-address for its intended purpose.

	Thanks,
	Paul

On 1/8/13 7:30 AM, Christer Holmberg wrote:
> Hi,
>
> I am the assigned SDP directorate reviewer for
>
> draft-ietf-rmt-flute-sdp-03
>
> For background on the SDP directorate, please see the FAQ at
>
> http://www.ietf.org/iesg/directorate/sdp.html
>
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
>
> SUMMARY:
>
> ==========
>
> I have technical concerns with a number of the technical content of this
> document, and at least the “Composite Session” concept, as currently
>
> defined in the document, would need to be discussed in MMUSIC. I think
> they need to be resolved/clarified before this document can be published.
>
> Regards,
>
> Christer
>
> --------------------------------------------------------
>
> TECHNICAL
>
> =========
>
> General:
>
> ------------
>
> T-GEN-1:              The draft seems to define a new generic SDP
> mechanism, “Composite Session”, for grouping media streams into
> protocol-specific sessions. I am not really sure what that means, but it
> seems to go outside the scope of FLUTE. I also think it overlaps with
> the SDP BUNDLE work, and such work shall be done in MMUSIC.
>
>                  “The Composite Session mechanism enables the grouping
> of media lines
>
>                  in to distinct sessions.  The complete Composite
> Session semantics
>
>                  are protocol-specific - as determined by the protocol
> id of the
>
>                  grouped media lines.”
>
> T-GEN-2:              Maybe I’ve missed it, but it is a little unclear
> to me why the grouping framework is needed in the first place. If that
> is described somewhere, please tell me :)
>
> In section 3.2.1, the text says:
>
>                  “The Composite Session provides an unambiguous way to
> define multiple
>
>                  FLUTE sessions as distinct from multiple the
> media-sessions semantics
>
>                  of RTP.”
>
> But, what is the technical need for this?
>
> T-GEN-3:              The draft uses the same source address for every
> m- line associated with a group, but it uses different addresses in each
> m- line. Aren’t the media streams symmetric?
>
> T-GEN-4:              There is chapter describing the SDP Offer/Answer
> aspects. How is the answer generated? What if the answerer does not
> support (or, supports, but don’t want to use) the mechanism?
>
> If the mechanism is not to be used with SDP Offer/Answer, but e.g. for
> some kind of declaration, I think that needs to be described.
>
> Section 1:
>
> -------------
>
> T-1-1:                    The text says:
>
>                  “Note, this document may also be used to describe
> sessions of the
>
>                  experimental FLUTE specification [RFC3926].”
>
> I think you need to indicate whether or not there will be any changes in
> the usage of SDP in that case.
>
> Section 3.2:
>
> ---------------
>
> T-3-2:                    I would like to have some input from the
> MMUSIC community whether “FLUTE/UDP/ESP” is appropriate to describe a
> IPSec encrypted FLUTE channel, or whether something like “SFLUTE/UDP”
> should be used instead.
>
> Section 3.11:
>
> -----------------
>
> T-3_11-1:             As the syntax mandates at least one fmt value, I
> suggest that the document specifies which value SHALL be used.
>
> EDITORIAL
>
> =========
>
> General:
>
> -----------
>
> E-GEN-1:              The Abstract and Introduction needs to explicitly
> state that the specification defines a new SDP grouping framework value.
> The Abstract also needs to mention the new SDP protocol values.
>
> Section 1:
>
> -------------
>
> E-1-1:                    s/defines two new protocol identifiers/defines
> two new SDP protocol values
>
> E-1-2:                    I suggest to remove “The formal ABNF syntax
> [RFC5234] is used for the attributes.” It only needs to be stated in the
> section defining the new SDP attributes.
>
> Section 3:
>
> -------------
>
> E-3-1:                    I think the second last paragraph, comparing
> FLUTE with RTP media streams, sessions etc is confusing. I think it is
> enough to describe that each SDP m- line represents a FLUTE channel.
>
> Section 3.1:
>
> ---------------
>
> E-3_1-1:               I would suggest to have a new parent chapter,
> “SDP Extensions”, with sub-chapters defining the new SDP protocol
> values, attributes etc.
>
> Section 3.11:
>
> -----------------
>
> E-3_11-1:             I suggest to remove this section. It’s not needed,
> and I don’t even agree with the content.
>
> Section 4:
>
> -------------
>
> E-4-1:                    Instead of saying “a=FEC-declaration line”, I
> suggest to say “SDP FEC-declaration attribute”. (Also applies to the
> description of the other attributes).
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>