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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 08 January 2013 12:30 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 528EC21F867E for <mmusic@ietfa.amsl.com>; Tue, 8 Jan 2013 04:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eAbg-ttZJufy for <mmusic@ietfa.amsl.com>; Tue, 8 Jan 2013 04:30:07 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id F40AE21F8671 for <mmusic@ietf.org>; Tue, 8 Jan 2013 04:30:06 -0800 (PST)
X-AuditID: c1b4fb30-b7f736d0000010de-41-50ec114dce8f
Received: from ESESSHC018.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 49.7F.04318.D411CE05; Tue, 8 Jan 2013 13:30:05 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC018.ericsson.se ([]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:30:05 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
Thread-Index: Ac3tm68F9DIBrFHTT62cRwDB61Qgww==
Date: Tue, 08 Jan 2013 12:30:04 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B09423BESESSMB209ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja6v4JsAg9YOQ4uTr84wWkxd/pjF gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mq4df4Fc0HPdMaKl4tmMTcwLm9i7GLk5JAQ MJG4veQmE4QtJnHh3nq2LkYuDiGBQ4wS2/fMYQNJCAksYpTo2hnXxcjBwSZgIdH9TxskLCKg LvF1bw8ziM0sECnx/PYtVpASYQF7iX+duhAlLhKf/85ngbD1JF4d/c0OYrMIqEhcXHsGzOYV 8JZYtmkr2AmMQCd8P7WGCWKkuMStJ/OhThOQWLLnPDOELSrx8vE/VghbUWLn2XaoE/Ilpsz4 yAIxU1Di5MwnLBMYhWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSN7 bmJmTnq5+SZGYIwc3PLbYAfjpvtihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamBkmhccu+Wla96ikwYJD9a8X/Dr5qm8SbNWTtcp4zrFwqH8KV/giAfvuh8XJS+/LL6n +vjNrGO/hNaIrn6jvm3D6rZNc7+dyA+8XPLs+/ZprpvCkmxFJWV/7XbwNW5h4za+p8Iuu3qF 5EPTy+2LY4y65Lr93y6X5521fImm5VIpH3v2ennBSc1xSizFGYmGWsxFxYkAmuolHF8CAAA=
Cc: "draft-ietf-rmt-flute-sdp@tools.ietf.org" <draft-ietf-rmt-flute-sdp@tools.ietf.org>
Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2013 12:30:10 -0000


I am the assigned SDP directorate reviewer for


For background on the SDP directorate, please see the FAQ at


Please wait for direction from your document shepherd or AD before posting a new version of the draft.


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.






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.



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).