Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt

From: [email-masked]
Date: Sun, 03 Dec 2017 08:27:36 -0800

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-sdpneg-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-14

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/

---

From: Roni Even <[email-masked]>
Date: Mon, 4 Dec 2017 06:07:37 +0000

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

Abstract:

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.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 09:16:50 +0000

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:

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