Re: [MMUSIC] my review of draft-ietf-mmusic-data-channel-sdpneg-02
Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Mon, 15 June 2015 12:49 UTC
Return-Path: <juergen.stoetzer-bradler@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBAD1B35B4 for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 05:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qustVzaur5gn for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 05:49:36 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB041B35B3 for <mmusic@ietf.org>; Mon, 15 Jun 2015 05:49:35 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A71FB377C7B1E for <mmusic@ietf.org>; Mon, 15 Jun 2015 12:49:31 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t5FCnXU9032129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 15 Jun 2015 14:49:33 +0200
Received: from [135.244.176.26] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Jun 2015 14:49:33 +0200
Message-ID: <557EC9DB.7080406@alcatel-lucent.com>
Date: Mon, 15 Jun 2015 14:49:31 +0200
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <097101d09de8$1e5e1480$5b1a3d80$@gmail.com>
In-Reply-To: <097101d09de8$1e5e1480$5b1a3d80$@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms040902000606070602060907"
X-Originating-IP: [135.239.27.38]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/TTzzrFkwiTOWJZ5KU3xDpbdSokg>
Subject: Re: [MMUSIC] my review of draft-ietf-mmusic-data-channel-sdpneg-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 15 Jun 2015 12:49:39 -0000
Hi Roni, Thank you very much for your comments. Please see my replies inserted below. Thanks, Juergen On 03.06.2015 12:29, Roni Even wrote: > > Hi, > > I read the documents and have some comments > > 1.The abstract says “This document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation.” While the introduction says “This document defines > SDP-based out-of-band negotiation procedures to establish data channels for transport of > well-defined sub-protocols“ I noticed that the document is about using SDP offer answer and not > about any other “out-of-band” negotiation. > [Juergen] This document indeed focuses on SDP offer / answer negotiation. We would propose to replace this last sentence of the introduction (section 1) with "This document defines SDP offer/answer negotiation procedures to establish data channels for transport of well-defined sub-protocols, to enable out-of band negotiation." Would that address your comment? > 2.In the terminology why do you need both internal and in-band negotiation and external and > out-of-band suggest using one term throughout the document. I think that using internal or even > better DCEP for in-band and using external or SDP offer/answer in the document will be better. > [Juergen] Agreed. We could replace "internal negotiation" and "in-band negotiation" with "DCEP negotiation", and "external negotiation" and "out-of-band negotiation" with just "SDP offer / answer negotiation", and correspondingly remove "external negotiation", "internal negotiation", in-band", "in-band negotiation" and "out-of-band" from the terminology list in section 3. Section 5 contains following sentence: "/… The application also specifies if it wants to make use of the in-band negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if the application intends to perform an "external negotiation" using some other in-band or out-of-band mechanism./" There, "external negotiation", "in-band" and "out-of-band mechanism" are used with a broader meaning. As this sentence is informative, we would propose to keep it as is. Also, in some cases "external negotiation" should probably be replaced with e.g. "non-DCEP negotiation". E.g. the first two sentences of the first paragraph in section 5.2.1 currently say: "/In-band negotiation only provides for negotiation of data channel// // transport parameters and does not provide for negotiation of sub-// // protocol specific parameters. External negotiation can be defined to// // allow negotiation of parameters beyond those handled by in-band// // negotiation, e.g., parameters specific to the sub-protocol// // instantiated on a particular data channel./" These could e.g. be reformulated as: "/DCEP negotiation only provides for negotiation of data channel// // transport parameters and does not provide for negotiation of sub-// // protocol specific parameters. Non-DCEP negotiation can be defined to// // allow negotiation of parameters beyond those handled by DCEP// // negotiation, e.g., parameters specific to the sub-protocol// // instantiated on a particular data channel./" Would that be agreeable? > 3.I am not sure that the following paragraph is needed “It is also worth noting that a data > channel stack implementation may not provide any API to create and close data channels; instead > the data channels are used on the fly as needed just by communicating via external means or by > even having some local configuration/assumptions on both the peers.” Why need API discussion in > the document? > [Juergen] Currently there are still some API related text parts in a few places in the document. If there are no objections we could completely remove all these (JavaScript) API related discussions from the document. > 4.Same for “Browser based applications (could include hybrid apps) will use [WebRtcAPI], while > native applications use a compatible API, which is yet to be specified” Why mention external API, > this is not required for the negotiation using SDP offer/answer > [Juergen] Agreed. Similar as above, we could remove such API related text parts. We would propose to then also remove the references to the W3C WebRTC API specification [WebRtcAPI] from the document. > 5.In 5.2.3 need to expand SSN. > [Juergen] Agreed. We could add "SCTP stream sequence number (SSN)" to the list of terms and add a reference to RFC 4960. > 6.In 5.2.3 “Depending upon the method used for external negotiation” are there multiple ones? > [Juergen] As this document's scope is just on SDP offer / answer negotiation, we could replace this second sentence in section 5.2.3 ("/Depending upon the method used for external negotiation and the sub- protocol associated with the data channel, the closing might in addition be signaled to the peer via external negotiation/") with just " /The closing might in addition be signaled to the peer via SDP offer / answer negotiation/ ". Would that be ok? > 7.In section 6.2.1 “However, a single stream is managed using one method at a time.” Suggest “MUST > be managed” > [Juergen] We'd propose to reformulate this sentence to "/However, an SDP offer / answer exchange MUST NOT be initiated if the associated stream is already negotiated via DCEP/". The opposite would actually be an informative statement in this document (that an SDP offer / answer negotiated data channel should afterwards not be negotiated via the DCEP). > 8.In section 6.2.2 “By definition max-retr and max-time are mutually exclusive, so only one of > them can be present in a=dcmap.” Suggest MUST be present. > [Juergen] As it is also allowed to neither specify max-retr nor max-time, would you agree if we said the following? "/By definition max-retr and max-time are mutually exclusive, so at most one of them MUST be present in a=dcmap/" > 9.In section 6.2.3 “If a peer receives an SDP offer before getting to send a new SDP “ I assume > you meant “before starting to send” > [Juergen] Agreed. We'll change this sentence to "If a peer receives an SDP offer before starting to send a new SDP ...". > 10.The IANA section does not mention the new SDP attributes > [Juergen] Thanks. Indeed, we'll add both new attributes to the IANA section. > Thanks > > Roni Even >
- [MMUSIC] my review of draft-ietf-mmusic-data-chan… Roni Even
- Re: [MMUSIC] my review of draft-ietf-mmusic-data-… Juergen Stoetzer-Bradler
- Re: [MMUSIC] my review of draft-ietf-mmusic-data-… Paul Kyzivat
- Re: [MMUSIC] my review of draft-ietf-mmusic-data-… Juergen Stoetzer-Bradler