Re: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
Brian Adamson <brian.adamson@nrl.navy.mil> Tue, 22 January 2013 15:52 UTC
Return-Path: <brian.adamson@nrl.navy.mil>
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 <rmt@ietfa.amsl.com>; 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 <rmt@ietfa.amsl.com>; 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 <rmt@ietf.org>; 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 <brian.adamson@nrl.navy.mil>
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 <Martin.Stiemerling@neclab.eu>
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 <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2013 15:52:23 -0000
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. > > 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 <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: > > ========== > > 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 > > > <Attached Message Part.txt>_______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt
- [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of dr… Martin Stiemerling
- [Rmt] Fwd: Re: [MMUSIC] SDP Directorate: Review o… Martin Stiemerling
- Re: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review o… Brian Adamson