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

[Martin Stiemerling <[e-mail]>]

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