From iesg-secretary@ietf.org Tue Jan 8 06:59:05 2013 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B016921F8A5E; Tue, 8 Jan 2013 06:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBmFHQSrZNht; Tue, 8 Jan 2013 06:59:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9B21F8479; Tue, 8 Jan 2013 06:59:05 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130108145905.18288.39298.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 06:59:05 -0800 Cc: rmt@ietf.org Subject: [Rmt] Last Call: (FCAST: Scalable Object Delivery for the ALC and NORM Protocols) to Proposed Standard X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:59:05 -0000 The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'FCAST: Scalable Object Delivery for the ALC and NORM Protocols' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-fcast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-fcast/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Jan 8 06:59:38 2013 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFF121F8A94; Tue, 8 Jan 2013 06:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Bk1s-3zU7Rh; Tue, 8 Jan 2013 06:59:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3095E21F8703; Tue, 8 Jan 2013 06:59:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130108145938.18294.84551.idtracker@ietfa.amsl.com> Date: Tue, 08 Jan 2013 06:59:38 -0800 Cc: rmt@ietf.org Subject: [Rmt] Last Call: (SDP Descriptors for FLUTE) to Proposed Standard X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 14:59:38 -0000 The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'SDP Descriptors for FLUTE' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-sdp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-sdp/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1938/ From Martin.Stiemerling@neclab.eu Tue Jan 22 05:50:10 2013 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1CA21F8920 for ; Tue, 22 Jan 2013 05:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pebUQ781gpm for ; Tue, 22 Jan 2013 05:50:09 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D32B121F891D for ; Tue, 22 Jan 2013 05:50:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3C469102E9B for ; Tue, 22 Jan 2013 14:50:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXtC7PYbHYQ2 for ; Tue, 22 Jan 2013 14:50:08 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 0BDF2102E81 for ; Tue, 22 Jan 2013 14:50:03 +0100 (CET) Received: from [10.1.99.64] (10.1.99.64) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 Jan 2013 14:50:02 +0100 Message-ID: <50FE990A.10205@neclab.eu> Date: Tue, 22 Jan 2013 14:50:02 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> X-Forwarded-Message-Id: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> Content-Type: multipart/mixed; boundary="------------060405000004040402070305" X-Originating-IP: [10.1.99.64] Subject: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 13:50:10 -0000 --------------060405000004040402070305 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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 martin.stiemerling@neclab.eu 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 To: mmusic@ietf.org CC: draft-ietf-rmt-flute-sdp@tools.ietf.org 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). -- martin.stiemerling@neclab.eu 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 mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------060405000004040402070305-- From Martin.Stiemerling@neclab.eu Tue Jan 22 05:50:16 2013 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4021F8946 for ; Tue, 22 Jan 2013 05:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ5QoHW08kkl for ; Tue, 22 Jan 2013 05:50:15 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6176B21F893D for ; Tue, 22 Jan 2013 05:50:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CAD43102E9B for ; Tue, 22 Jan 2013 14:50:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyF1lPNGP-EL for ; Tue, 22 Jan 2013 14:50:14 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AAF7E102E81 for ; Tue, 22 Jan 2013 14:50:09 +0100 (CET) Received: from [10.1.99.64] (10.1.99.64) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 22 Jan 2013 14:50:09 +0100 Message-ID: <50FE9911.1020507@neclab.eu> Date: Tue, 22 Jan 2013 14:50:09 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <50EC4E57.7010407@alum.mit.edu> In-Reply-To: <50EC4E57.7010407@alum.mit.edu> X-Forwarded-Message-Id: <50EC4E57.7010407@alum.mit.edu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.99.64] Subject: [Rmt] Fwd: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 13:50:16 -0000 and the mentioned 2nd email. -------- Original Message -------- Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 Date: Tue, 8 Jan 2013 11:50:31 -0500 From: Paul Kyzivat To: Christer Holmberg CC: draft-ietf-rmt-flute-sdp@tools.ietf.org , mmusic@ietf.org 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 > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From brian.adamson@nrl.navy.mil Tue Jan 22 07:52:23 2013 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFE21F8586 for ; Tue, 22 Jan 2013 07:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmcS5dlkqUoo for ; Tue, 22 Jan 2013 07:52:22 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98421F8588 for ; Tue, 22 Jan 2013 07:52:20 -0800 (PST) Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r0MFqIp2032423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Jan 2013 10:52:18 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-69-457978379 From: Brian Adamson In-Reply-To: <50FE990A.10205@neclab.eu> Date: Tue, 22 Jan 2013 10:49:43 -0500 Message-Id: <6CB7590C-EF84-44F2-BFA2-301FDE8658C6@nrl.navy.mil> References: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> <50FE990A.10205@neclab.eu> To: Martin Stiemerling X-Mailer: Apple Mail (2.1085) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Cc: rmt@ietf.org Subject: Re: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:52:23 -0000 --Apple-Mail-69-457978379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Martin, We will rally the troops to address these. beset regards, Brian Adamson brian.adamson@nrl.navy.mil 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. >=20 > There a number of points that require attention. See below. >=20 > Martin >=20 > --=20 > IETF Transport Area Director >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > -------- 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 > To: mmusic@ietf.org > CC: draft-ietf-rmt-flute-sdp@tools.ietf.org > >=20 >=20 >=20 > Hi, >=20 > I am the assigned SDP directorate reviewer for >=20 > draft-ietf-rmt-flute-sdp-03 >=20 > For background on the SDP directorate, please see the FAQ at >=20 > http://www.ietf.org/iesg/directorate/sdp.html >=20 > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. >=20 > SUMMARY: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I have technical concerns with a number of the technical content of = this > document, and at least the =93Composite Session=94 concept, as = currently >=20 > 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. >=20 > Regards, >=20 > Christer >=20 > -------------------------------------------------------- >=20 > TECHNICAL >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > General: >=20 > ------------ >=20 > 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. >=20 > =93The Composite Session mechanism enables the = grouping > of media lines >=20 > in to distinct sessions. The complete Composite > Session semantics >=20 > are protocol-specific - as determined by the protocol > id of the >=20 > grouped media lines.=94 >=20 > 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 :) >=20 > In section 3.2.1, the text says: >=20 > =93The Composite Session provides an unambiguous way = to > define multiple >=20 > FLUTE sessions as distinct from multiple the > media-sessions semantics >=20 > of RTP.=94 >=20 > But, what is the technical need for this? >=20 > 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? >=20 > 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? >=20 > 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. >=20 > Section 1: >=20 > ------------- >=20 > T-1-1: The text says: >=20 > =93Note, this document may also be used to describe > sessions of the >=20 > experimental FLUTE specification [RFC3926].=94 >=20 > I think you need to indicate whether or not there will be any changes = in > the usage of SDP in that case. >=20 > Section 3.2: >=20 > --------------- >=20 > 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. >=20 > Section 3.11: >=20 > ----------------- >=20 > T-3_11-1: As the syntax mandates at least one fmt value, I > suggest that the document specifies which value SHALL be used. >=20 > EDITORIAL >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > General: >=20 > ----------- >=20 > 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. >=20 > Section 1: >=20 > ------------- >=20 > E-1-1: s/defines two new protocol = identifiers/defines > two new SDP protocol values >=20 > 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 = the > section defining the new SDP attributes. >=20 > Section 3: >=20 > ------------- >=20 > 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. >=20 > Section 3.1: >=20 > --------------- >=20 > 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. >=20 > Section 3.11: >=20 > ----------------- >=20 > E-3_11-1: I suggest to remove this section. It=92s not = needed, > and I don=92t even agree with the content. >=20 > Section 4: >=20 > ------------- >=20 > 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 >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt --Apple-Mail-69-457978379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Brian = Adamson



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

martin.stiemerling@neclab.eu<= /a>

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 <christer.holmberg@ericsson.com>
To: = = mmusic@ietf.org <mmusic@ietf.org>
CC: = draft-ietf-rmt-flute-sdp@tools.ietf.org
<draft-ietf-rmt-flute= -sdp@tools.ietf.org>



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: =             &n= bsp;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.

=             &n= bsp;   =93The Composite Session mechanism enables the = grouping
of media lines

=             &n= bsp;   in to distinct sessions.  The complete = Composite
Session semantics

=             &n= bsp;   are protocol-specific - as determined by the = protocol
id of the

=             &n= bsp;   grouped media lines.=94

T-GEN-2: =             &n= bsp;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:

=             &n= bsp;   =93The Composite Session provides an unambiguous = way to
define multiple

=             &n= bsp;   FLUTE sessions as distinct from multiple = the
media-sessions semantics

=             &n= bsp;   of RTP.=94

But, what is the technical need = for this?

T-GEN-3: =             &n= bsp;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: =             &n= bsp;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: =             &n= bsp;      The text says:

=             &n= bsp;   =93Note, this document may also be used to = describe
sessions of the

=             &n= bsp;   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: =             &n= bsp;      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:<= br>
-----------

E-GEN-1: =             &n= bsp;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: =             &n= bsp;      s/defines two new protocol = identifiers/defines
two new SDP protocol values

E-1-2: =             &n= bsp;      I suggest to remove =93The = formal ABNF syntax
[RFC5234] is used for the attributes.=94 It only = needs to be stated in the
section defining the new SDP = attributes.

Section 3:

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

E-3-1: =             &n= bsp;      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: =             &n= bsp; 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: =             &n= bsp;      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).


-- =
martin.stiemerling@neclab.eu

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
Rmt@ietf.org
https://www.ietf.org/mailman/listinfo/rmt

= --Apple-Mail-69-457978379--