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

[Brian Adamson <[e-mail]>]

Thanks Martin,

We will rally the troops to address these.

beset regards,


Brian Adamson
[e-mail]




On Jan 22, 2013, at 8:50 AM, Martin Stiemerling wrote:

> FYI, the first email about the SDP review of draft-ietf-rmt-flute-sdp-03. I will also forward the 2nd email, just in a second.
> 
> There a number of points that require attention. See below.
> 
> Martin
> 
> -- 
> IETF Transport Area Director
> 
> [e-mail]
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
> 
> 
> -------- Original Message --------
> Subject: 	[MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
> Date: 	Tue, 8 Jan 2013 12:30:04 +0000
> From: 	Christer Holmberg <[e-mail]>
> To: 	[e-mail] <[e-mail]>
> CC: 	[e-mail]
> <[e-mail]>
> 
> 
> 
> 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).
> 
> 
> -- 
> [e-mail]
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
> 
> 
> <Attached Message Part.txt>_______________________________________________
> Rmt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rmt