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
>