Subject: [MMUSIC] Comments on draft-data-channel-sdpneg-16 [was: FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt]

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Mar 2018 12:08:26 +0000

Hi,

I previously commented on version -14 of the draft. In my opinion the
draft looks better now. However, I still have comments on the -16 version,
focusing here on sections 5 and 6.

SECTION 5:
----------

Q1:

I think the whole structure of section 5 can be simplified. Something like:

5.  SDP Attributes

This sections defines new SDP media-level attributes, that can be used
together with the SDP Offer/Answer mechanism to negotiate data
channel-specific 
and subprotocol-specific parameters, without the usage of DCEP
[I-D.ietf-rtcweb-data-protocol].

Note: Appendix A provides information how data channels work in general and
   especially summarizes some key aspects, which should be considered
   for the negotiation of data channels if DCEP is not used.

5.1. SDP dcmap Attribute

5.1.1. Introduction
5.1.2. Syntax
5.1.3. Parameter #1
5.1.x. Parameter #n
5.1.y. Mux Category
5.1.z. BUNDLE Considerations
5.2. SDP dcsa Attribute

<same as 5.1>

SECTION 6:
----------

Q2:

Section 6.3 contains the following:

"The procedure for opening a data channel using SDP offer/answer
   negotiation starts with the agent preparing to send an SDP offer.  If
   a peer receives an SDP offer before starting to send a new SDP offer
   with data channels that are to be SDP offer/answer negotiated, or
   loses an SDP offer glare resolution procedure in this case, it MUST
   wait until the ongoing SDP offer/answer completes before resuming the
   SDP offer/answer negotiation procedure.”

To me that text seems like basic offer/answer, and could be removed.

Q3:

In Section 6.3, you have the two following bullets:

- Generates a new SDP offer.

- Completes the SDP offer…

- Sends the SDP offer.

You don’t all that. Simply say what the offerer does when it generates the
offer (which attributes it includes etc).

Q4:

In Section 6.5, the first sentence says:

"The agent receiving such an SDP answer performs the following:”

Simply say “When the offerer receives an answer, it:”

Q5:

Section 6.6 should be a sub-section to a section called “Sending
Subsequent Offer”.

Regards,

Christer

On 04/12/17 11:16, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>I think this draft could use some editorial work.
>
>Q1: The document does not contain the O/A section structure that we
>nowadays use (“Sending of initial offer”, “Sending of answer”, etc.).
>There can then be subsections (separate for the offerer and answerer) on
>how to open channels, close channels etc.
>
>Q2: The procedure text itself is a little messy. There is lots of
>“generate SDP”, “send SDP”, “apply SDP”, etc. Yes, that is how things are
>done in 3GPP, but in my opinion it makes the draft text difficult to read.
>
>Q3: There is a section called "Various SDP Offer/Answer Scenarios and
>Considerations”, which describes how different SDP related cases shall be
>interpreted. The offerer section shall describe how attributes are set
>based on what the offerer wants to do, and the answerer section shall
>describe how the presence/non-presence of attributes is interpreted. It IS
>fine to have a section describing different error scenarios etc, but this
>section describes valid use-cases.
>
>Just to give one example. The text says:
>
>    "SDP answer has no "a=dcsa:" attributes for a data channel.
>
>    *  This is allowed and indicates there are no subprotocol
>      parameters to convey in the SDP answer.”
>
>
>This belongs in a “Sending of answer” section, and should say something
>like:
>
>    “If there are subprotocol parameters, the answerer shall assign a dosa
>attribute to the m- section”
>
>I should not have to read a “Various considerations” sections just to
>figure out how to create a normal answer.
>
>Q4: The dtls-id has been renamed to tls-id.
>
>Q5: The draft makes statements on how data channels and SCTP associations
>work and behave. There should be references to the appropriate
>specifications.
>
>Q6: I doubt the security considerations will pass the IESG review. If
>intermediaries etc having access to the information etc does not cause any
>security concerns you should say so. I also think it would be good to
>reference to the generic security considerations for data channels etc.
>
>Regards,
>
>Christer
>
>
>
>
>On 04/12/17 08:07, "mmusic on behalf of Roni Even"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>Hi,
>>
>>This new revision addresses all nits pointed out by the idnits tool.
>>As a new editor, I looked at the MMUSIC mail archive and as far as I can
>>tell there were no open issues from the list.
>>
>>Thanks
>>Roni Even
>>
>>
>>-----Original Message-----
>>From: mmusic [mailto:[email-masked]] On Behalf Of
>>[email-masked]
>>Sent: יום א 03 דצמבר 2017 18:28
>>To: [email-masked]
>>Cc: [email-masked]
>>Subject: [MMUSIC] I-D Action:
>>draft-ietf-mmusic-data-channel-sdpneg-14.txt
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the Multiparty Multimedia Session Control WG
>>of the IETF.
>>
>>        Title           : SDP-based Data Channel Negotiation
>>        Authors         : Keith Drage
>>                          Maridi R. Makaraju
>>                          Juergen Stoetzer-Bradler
>>                          Richard Ejzak
>>                          Jerome Marcon
>>                          Roni Even
>>	Filename        : draft-ietf-mmusic-data-channel-sdpneg-14.txt
>>	Pages           : 41
>>	Date            : 2017-12-03
>>
>>Abstract:
>>   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>>   charged to provide protocols to support direct interactive rich
>>   communications using audio, video, and data between two peers' web-
>>   browsers.  For the support of data communication, the RTCWeb working
>>   group has in particular defined the concept of bi-directional data
>>   channels over SCTP (Stream Control Transmission Protocol), where each
>>   data channel might be used to transport other protocols, called
>>   subprotocols.  Data channel setup can be done using either the in-
>>   band Data Channel Establishment Protocol (DCEP) or using some out-of-
>>   band non-DCEP protocol.  This document specifies how the SDP (Session
>>   Description Protocol) offer/answer exchange can be used to achieve
>>   such an out-of-band non-DCEP negotiation.  Even though data channels
>>   are designed for RTCWeb use initially, they may be used by other
>>   protocols like, but not limited to, the CLUE protocol (which is
>>   defined by the IETF "ControLling mUltiple streams for tElepresence"
>>   working group).  This document is intended to be used wherever data
>>   channels are used.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>>
>>There are also htmlized versions available at:
>>https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14
>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpn
>>e
>>g-14
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-1
>>4
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>mmusic mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mmusic
>>
>>_______________________________________________
>>mmusic mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 29 Mar 2018 05:04:36 +0000

Hi Christer,
Thanks for the review.
I will update based on your comments
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, March 26, 2018 3:08 PM
To: Christer Holmberg; Roni Even (A); [email-masked]
Subject: Comments on draft-data-channel-sdpneg-16 [was: FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt]

Hi,

I previously commented on version -14 of the draft. In my opinion the draft looks better now. However, I still have comments on the -16 version, focusing here on sections 5 and 6.

SECTION 5:
----------

Q1:

5.  SDP Attributes

This sections defines new SDP media-level attributes, that can be used together with the SDP Offer/Answer mechanism to negotiate data channel-specific and subprotocol-specific parameters, without the usage of DCEP [I-D.ietf-rtcweb-data-protocol].

5.1. SDP dcmap Attribute

5.1.1. Introduction
5.1.2. Syntax
5.1.3. Parameter #1
5.1.x. Parameter #n
5.1.y. Mux Category

<same as 5.1>

SECTION 6:
----------

Q2:

Q3:

- Sends the SDP offer.

You don’t all that. Simply say what the offerer does when it generates the offer (which attributes it includes etc).

Q4:

Q5:

Section 6.6 should be a sub-section to a section called “Sending Subsequent Offer”.

Regards,

Christer

wrote:

>There can then be subsections (separate for the offerer and answerer) 
>on how to open channels, close channels etc.
>
>“generate SDP”, “send SDP”, “apply SDP”, etc. Yes, that is how things 
>are done in 3GPP, but in my opinion it makes the draft text difficult to read.
>
>Considerations”, which describes how different SDP related cases shall 
>be interpreted. The offerer section shall describe how attributes are 
>set based on what the offerer wants to do, and the answerer section 
>shall describe how the presence/non-presence of attributes is 
>interpreted. It IS fine to have a section describing different error 
>scenarios etc, but this section describes valid use-cases.
>
>    “If there are subprotocol parameters, the answerer shall assign a 
>dosa attribute to the m- section”
>
>Q5: The draft makes statements on how data channels and SCTP 
>associations work and behave. There should be references to the 
>appropriate specifications.
>
>intermediaries etc having access to the information etc does not cause 
>any security concerns you should say so. I also think it would be good 
>to reference to the generic security considerations for data channels etc.
>
>Regards,
>
>Christer
>
>
>
>
>>As a new editor, I looked at the MMUSIC mail archive and as far as I 
>>can tell there were no open issues from the list.
>>
>>Thanks
>>Roni Even
>>
>>
>>This draft is a work item of the Multiparty Multimedia Session Control 
>>WG of the IETF.
>>