Subject: [MMUSIC] my review of draft-ietf-mmusic-data-channel-sdpneg-02

From: "Roni Even" <[email-masked]>
Date: Wed, 3 Jun 2015 13:29:03 +0300

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.

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.

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?

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

5.       In 5.2.3 need to expand SSN.

6.       In 5.2.3 "Depending upon the method used for external negotiation"
are there multiple ones? 

7.       In section 6.2.1 "However, a single stream is managed using one
method at a time." Suggest "MUST be managed"

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.

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"

10.   The IANA section does not mention the new SDP attributes

Thanks

Roni Even

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 15 Jun 2015 14:49:31 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2015 11:00:24 -0400

On 6/15/15 8:49 AM, Juergen Stoetzer-Bradler wrote:

>> 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/"

That construction seems very awkward. I suggest:

"By definition max-retr and max-time are mutually exclusive, so at most 
one of them MAY be present in a=dcmap."

	Thanks,
	Paul

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 17 Jun 2015 16:07:45 +0200

Hi Paul,

Thanks for feedback.
Agree to replace "MUST" with "MAY".

Thanks,
Juergen

On 15.06.2015 17:00, Paul Kyzivat wrote:
> "By definition max-retr and max-time are mutually exclusive, so at most one of them MAY be present 
> in a=dcmap."
>
>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic