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

--------------060405000004040402070305
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: quoted-printable

FYI, the first email about the SDP review of=20
draft-ietf-rmt-flute-sdp-03. I will also forward the 2nd email, just in=20
a second.

There a number of points that require attention. See below.

  Martin

--=20
IETF Transport Area Director

[email protected]

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 <[email protected]>
To: 	[email protected] <[email protected]>
CC: 	[email protected]
<[email protected]>



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:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I have technical concerns with a number of the technical content of this
document, and at least the =93Composite Session=94 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

=3D=3D=3D=3D=3D=3D=3D=3D=3D

General:

------------

T-GEN-1:              The draft seems to define a new generic SDP
mechanism, =93Composite Session=94, 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.

                  =93The 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.=94

T-GEN-2:              Maybe I=92ve 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:

                  =93The Composite Session provides an unambiguous way to
define multiple

                  FLUTE sessions as distinct from multiple the
media-sessions semantics

                  of RTP.=94

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=92t 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=92t 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:

                  =93Note, this document may also be used to describe
sessions of the

                  experimental FLUTE specification [RFC3926].=94

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 =93FLUTE/UDP/ESP=94 is appropriate to describe a
IPSec encrypted FLUTE channel, or whether something like =93SFLUTE/UDP=94
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

=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 =93The formal ABNF syntax
[RFC5234] is used for the attributes.=94 It only needs to be stated in th=
e
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,
=93SDP Extensions=94, 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=92s not needed=
,
and I don=92t even agree with the content.

Section 4:

-------------

E-4-1:                    Instead of saying =93a=3DFEC-declaration line=94=
, I
suggest to say =93SDP FEC-declaration attribute=94. (Also applies to the
description of the other attributes).


--=20
[email protected]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283



--------------060405000004040402070305
Content-Type: text/plain; charset="UTF-8"; name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Attached Message Part"

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic


--------------060405000004040402070305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt

--------------060405000004040402070305--