Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Sep 2016 15:38:01 +0000

Shouldn't it be a normative reference?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Juergen Stoetzer-Bradler<mailto:[email-masked]>
Sent: ‎27/‎09/‎2016 17:31
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

Hi Christer,

Good point. Agree to add the dtls-id attribute to the examples and to add draft-ietf-mmusic-dtls-sdp to the list of informative references.

Thanks,
Juergen

On 27.09.2016 15:23, Christer Holmberg wrote:
Hi,

I think draft-dtls-sdp should also be referenced, and the SDP dtls-id attribute should be added to the examples.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Juergen Stoetzer-Bradler <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 27 September 2016 at 15:11
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

Roman, Paul,

Based on your comments I would propose to modify the text in the introduction and in the dcmap and dcsa multiplexing category sections as follows.
I've removed all text parts, in which the "m" line proto values "SCTP" and "SCTP/DTLS" had been mentioned.

Are you ok with these changes?

Thanks again,
Juergen

1.  Introduction

   The RTCWeb working group has defined the concept of bi-directional
   data channels running on top of the Stream Control Transmission
   Protocol (SCTP).  ...

   ...

   This document defines SDP offer/answer negotiation procedures to
   establish data channels for transport of well-defined subprotocols,
   to enable out-of-band negotiation.  These procedures are based on
   generic SDP offer/answer negotiation rules for SCTP based media
   transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
   line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.  In future data
   channels could be defined over other SCTP based protocols, such as
   SCTP over IP.  However, corresponding potential other "m" line proto
   values are not considered in this document.

   ...

5.1.1.2.  dcmap Multiplexing Category

   ...

   As the usage of multiple SCTP associations on top of a single DTLS
   connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
   "a=dcmap:" attribute multiplexing rules are specified for the
   UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values.  If future extensions
   of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
   multiple SCTP associations on top of a single DTLS connection, or how
   to add multiple SCTP associations to one BUNDLE group, then
   multiplexing rules for the "a=dcmap:" attribute need to be defined as
   well, for instance in an extension of this SDP based data channel
   negotiation specification.

5.1.2.2.  dcsa Multiplexing Category

   ...

   As the usage of multiple SCTP associations on top of a single DTLS
   connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
   "a=dcsa:" attribute multiplexing rules are specified for the
   UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values.  If future extensions
   of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
   multiple SCTP associations on top of a single DTLS connection, or how
   to add multiple SCTP associations to one BUNDLE group, then
   multiplexing rules for the "a=dcsa:" attribute need to be defined as
   well, for instance in an extension of this SDP based data channel
   negotiation specification.

On 21.09.2016 14:17, Juergen Stoetzer-Bradler wrote:
Roman, Paul,

Thanks for your comments.

The protocol stack notation "SCTP/DTLS" in the introduction was actually meant to refer to the "SCTP on top of DTLS" case, which is also mentioned in the succeeding parentheses. I fully agree that this is confusing and would propose to remove "SCTP/DTLS" from the introduction and instead to just say:
"The RTCWeb working group has defined the concept of bi-directional data channels running on top of SCTP over the Datagram Transport Layer Security protocol.".
Or just "... on top of SCTP over DTLS".

And indeed, as draft-ietf-mmusic-sctp-sdp doesn't contain m-line proto value "SCTP/DTLS" at all anymore, I would agree to remove it from sections 5.1.1.2 and 5.1.2.2.
Also agree to restrict the scope of the whole document to the two "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" transport stack cases and to explicitly say so e.g. in the introduction. This would be inline with the definition of "data channel" in the terminology section, which explicitly refers to draft-ietf-rtcweb-data-channel, where only these two transport stack cases are considered.

Regards,
Juergen

On 16.09.2016 01:30, Roman Shpount wrote:
On Thu, Sep 15, 2016 at 6:54 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 9/15/16 5:51 PM, Roman Shpount wrote:

RTCWeb defines data channels running over DTLS/SCTP (SCTP over the
Datagram Transport Layer Security protocol) not SCTP/DTLS which is DTLS
over SCTP and is a completely different thing.

SCTP/DTLS is now gone, so we don't need to consider it.

IIUC RTCWEB needs for data channels to be defined over at least two lower layers: UDP/DTLS/SCTP and TCP/DTLS/SCTP. (Because ICE might end up having to run over TCP rather than UDP.)

SCTP/DTLS is mentioned in the introduction (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-1). Should be replaced with UDP/DTLS/SCTP and TCP/DTLS/SCTP.

Do we even define data channels on top of SCTP and SCTP/DTLS transports?
These are definitely not used in RTCWeb. I think these should be removed
from the document.

Fundamentally data channels are defined over SCTP. Whether that is over UDP, TCP or IP or something else is irrelevant to its definition. The only thing that is relevant is to have a <proto> value that has SCTP on top, and for both ends to agree on that. (And those proto values are defined in draft-ietf-mmusic-sctp-sdp, not here.)

So why does this draft have to say *anything* about what is under SCTP? That is just a matter for each specific usage.

But, if that is too much of a change, then I guess the next best is to only define UDP/DTLS/SCTP and TCP/DTLS/SCTP, and note that definition for use of SCTP over other lower layers is left for future definition.

The document mentions SCTP/DTLS as well as SCTP in the same list as UDP/DTLS/SCTP and TCP/DTLS/SCTP (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-5.1.1.2 and https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-5.1.2.2 for instance). These mentions should be removed. If needed, introduction can mention that data channel can be defined in the future over other SCTP based protocols, such as plain SCTP and SCTP/DTLS.

Regards,
_____________
Roman Shpount
 ailman/listinfo/mmusic