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

From: Bo Burman <[email-masked]>
Date: Thu, 15 Sep 2016 09:24:01 +0000

MMUSIC,

This email starts a two week WG last call that ends on September 29, 2016.
The intended status of this document is standards track (Proposed Standard).

Please review and provide any comments you may have on the document. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Please also forward this WGLC call to any other interested parties who may be able to review the draft, asking them to also direct their comments to the authors and the list as above.

The document can be retrieved here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

Thank you!

        Bo Burman (MMUSIC co-chair)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2016 17:51:14 -0400

I have reviewed the document.

The first comment is about the summary:

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.

Second comment is about underlying transport protocols:

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.

Regards,

_____________
Roman Shpount

On Thu, Sep 15, 2016 at 5:24 AM, Bo Burman <[email-masked]> wrote:

> Please review and provide any comments you may have on the document.
> Comments should be sent to the document authors and the MMUSIC WG list. If
> you review the document but do not have any comments, please send a note to
> that effect as well.
>
>
>
> Please also forward this WGLC call to any other interested parties who may
> be able to review the draft, asking them to also direct their comments to
> the authors and the list as above.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Sep 2016 18:54:45 -0400

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

> These are definitely not used in RTCWeb. I think these should be removed

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.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2016 19:30:05 -0400

On Thu, Sep 15, 2016 at 6:54 PM, Paul Kyzivat <[email-masked]> wrote:

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

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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 21 Sep 2016 14:17:39 +0200

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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 27 Sep 2016 14:11:25 +0200

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Sep 2016 13:23:22 +0000

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.

Thanks again,
Juergen

1.  Introduction

   ...

   ...

   ...

   ...

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:

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.

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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 27 Sep 2016 16:31:22 +0200

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:
> From: mmusic <[email-masked] <mailto:[email-masked]>> on behalf of Juergen 
> Stoetzer-Bradler <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> 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
>>
>>>     UDP/DTLS/SCTP and TCP/DTLS/SCTP. (Because ICE might end up having to run over TCP rather
>>>     than UDP.)
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Sep 2016 11:20:07 -0400

This seems good to me.

	Thanks,
	Paul

On 9/27/16 10:31 AM, Juergen Stoetzer-Bradler wrote:
> 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
>
>
>> 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]>>
>> 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.
>>> 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
>>> "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.".
>>> 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
>>>
>>>>     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.)
>>>>
>>>>
>>>> (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-1).
>>>>     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
>>>>     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.
>>>>
>>>>
>>>> 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
>>>
>>
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2016 14:19:47 -0400

Juergen,

The proposed language looks good.

After reading the multiplexing language, I have a related question: Is it
allowed to tear down the SCTP association and setup a new SCTP association
over the same DTLS association?

Regards,

_____________
Roman Shpount

On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler <
[email-masked]> wrote:

> introduction and in the dcmap and dcsa multiplexing category sections as
> follows.
> 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.".
> 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.
> "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
>
> 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.
>
> 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
>
>
>
>

---

From: "Schwarz, Albrecht (Nokia - DE)" <[email-masked]>
Date: Wed, 28 Sep 2016 06:34:18 +0000

Christer,

> Shouldn't it be a normative reference?

which would be then add further delay to the WGLC, right?

Albrecht

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Dienstag, 27. September 2016 20:20
To: Stoetzer-Bradler, Juergen (Nokia - DE) <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

Juergen,

After reading the multiplexing language, I have a related question: Is it allowed to tear down the SCTP association and setup a new SCTP association over the same DTLS association?

Regards,

_____________
Roman Shpount

On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler <[email-masked]<mailto:[email-masked]>> wrote:
Roman, Paul,

Thanks again,
Juergen

1.  Introduction

   Protocol (SCTP).  ...

   ...

   ...

   ...

   ...

Regards,
Juergen

Regards,
_____________
Roman Shpount
 ailman/listinfo/mmusic

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Sep 2016 06:59:01 +0000

Hi,

> which would be then add further delay to the WGLC, right?

No – you can still go ahead with the WGLC, publication request etc.

Having said that, as the dtls-id will only be in the examples, maybe we don’t need to add a reference after all. The draft already normatively references draft-ietf-mmusic-sctp-sdp, which normatively references draft-dtls-sdp, so...

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Dienstag, 27. September 2016 20:20
To: Stoetzer-Bradler, Juergen (Nokia - DE) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09

Juergen,

Regards,

_____________
Roman Shpount

Thanks again,
Juergen

1.  Introduction

   Protocol (SCTP).  ...

   ...

   ...

   ...

   ...

Regards,
Juergen

Regards,
_____________
Roman Shpount
 ailman/listinfo/mmusic

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 28 Sep 2016 09:45:18 +0200

Hi Christer,

Basically, that was what I was thinking, too - the data-channel-sdpneg draft is largely independent 
from the actual DTLS association negotiation. That's why I thought that adding draft-dtls-sdp as 
informative reference would be sufficient.

Thanks,
Juergen

On 28.09.2016 08:59, Christer Holmberg wrote:
> Having said that, as the dtls-id will only be in the examples, maybe we don’t need to add a 
> reference after all. The draft already normatively references draft-ietf-mmusic-sctp-sdp, which 
> normatively references draft-dtls-sdp, so...
> Regards,
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Roman Shpount
> *Sent:* Dienstag, 27. September 2016 20:20
> *To:* Stoetzer-Bradler, Juergen (Nokia - DE) <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09
>
> Juergen,
>
> After reading the multiplexing language, I have a related question: Is it allowed to tear down the 
> SCTP association and setup a new SCTP association over the same DTLS association?
>
> Regards,
>
>
> _____________
> Roman Shpount
>
> On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>         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.".
>         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.
>         "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
>
>                 UDP/DTLS/SCTP and TCP/DTLS/SCTP. (Because ICE might end up having to run over TCP
>                 rather than UDP.)
>
>                 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.)
>
>                 UDP/DTLS/SCTP and TCP/DTLS/SCTP, and note that definition for use of SCTP over
>                 other lower layers is left for future definition.
>
>             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
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 28 Sep 2016 13:39:26 +0200

Roman,

As per my understanding it should indeed be allowed to shutdown an SCTP association and then to 
establish a new one over the same DTLS association. Both SCTP association endpoints would have to 
choose new values for the initiate tags / verification tags, such that received SCTP packets could 
be uniquely associated with either the previous or the new SCTP association.
However, I am not an SCTP expert - might be good to hear additional feedback.

Best regards,
Juergen

On 27.09.2016 20:19, Roman Shpount wrote:
>>     "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.".
>>     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.
>>     explicitly refers to draft-ietf-rtcweb-data-channel, where only these two transport stack
>>     cases are considered.
>>
>>     Regards,
>>     Juergen
>>
>>>     (https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-1
>>>     <https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-1>). Should be
>>>         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.)
>>>
>>>         UDP/DTLS/SCTP and TCP/DTLS/SCTP, and note that definition for use of SCTP over other
>>>         lower layers is left for future definition.
>>>
>>>
>>>     <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
>     https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2016 08:34:51 -0400

Juergen,

This was my understanding as well but I would also like the rest of the
group to confirm.

Regards,

_____________
Roman Shpount

On Wed, Sep 28, 2016 at 7:39 AM, Juergen Stoetzer-Bradler <
[email-masked]> wrote:

> Roman,
>
> As per my understanding it should indeed be allowed to shutdown an SCTP
> association and then to establish a new one over the same DTLS association.
> Both SCTP association endpoints would have to choose new values for the
> initiate tags / verification tags, such that received SCTP packets could be
> uniquely associated with either the previous or the new SCTP association.
>> SCTP/DTLS is mentioned in the introduction (https://tools.ietf.org/html/d
>> raft-ietf-mmusic-data-channel-sdpneg-09#section-1). Should be replaced
>> UDP/DTLS/SCTP and TCP/DTLS/SCTP (https://tools.ietf.org/html/d
>> raft-ietf-mmusic-data-channel-sdpneg-09#section-5.1.1.2 and
>> https://tools.ietf.org/html/draft-ietf-mmusic-data-chann
>> el-sdpneg-09#section-5.1.2.2 for instance). These mentions should be

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Sep 2016 13:04:53 +0000

Hi,

As specified in draft-ietf-mmusic-sctp-sdp, the SCTP association and DTLS association are handled independently of each other.

And, in order to re-establish an SCTP association, an endpoint needs to provide a new SDP 'sctp-port' attribute value.

Regards,

Christer

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

Juergen,

This was my understanding as well but I would also like the rest of the group to confirm.

Regards,

_____________
Roman Shpount

On Wed, Sep 28, 2016 at 7:39 AM, Juergen Stoetzer-Bradler <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

As per my understanding it should indeed be allowed to shutdown an SCTP association and then to establish a new one over the same DTLS association. Both SCTP association endpoints would have to choose new values for the initiate tags / verification tags, such that received SCTP packets could be uniquely associated with either the previous or the new SCTP association.
However, I am not an SCTP expert - might be good to hear additional feedback.

Best regards,
Juergen

Regards,

_____________
Roman Shpount

Thanks again,
Juergen

1.  Introduction

   ...

   ...

   ...

   ...

Regards,
Juergen

Regards,
_____________
Roman Shpount
 ailman/listinfo/mmusic

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 28 Sep 2016 16:59:55 +0200

Hi Christer,

Thanks for further feedback.
The first bullet point of section 10.5 in draft-ietf-mmusic-sctp-sdp-17 says:
"Unless the offerer wants to re-establish an SCTP association, the offerer MUST associate an SDP 
'sctp-port' attribute, with a new attribute value, with the m- line..."

Now I am not sure anymore regarding the meaning of "re-established" in this context.
If the previous SCTP association is closed, and if then a new SCTP association is established, is 
the idea to distinguish between a "re-establishment", where the formerly used "sctp-port" values are 
re-used, and a "new establishment", where new values of "sctp-port" are used?

Thanks again,
Juergen

On 28.09.2016 15:04, Christer Holmberg wrote:
> From: mmusic <[email-masked] <mailto:[email-masked]>> on behalf of Roman Shpount 
> <[email-masked] <mailto:[email-masked]>>
> To: Juergen Stoetzer-Bradler <[email-masked] 
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Wed, Sep 28, 2016 at 7:39 AM, Juergen Stoetzer-Bradler <[email-masked] 
>     As per my understanding it should indeed be allowed to shutdown an SCTP association and then
>     to establish a new one over the same DTLS association. Both SCTP association endpoints would
>     have to choose new values for the initiate tags / verification tags, such that received SCTP
>     packets could be uniquely associated with either the previous or the new SCTP association.
>>     After reading the multiplexing language, I have a related question: Is it allowed to tear
>>     down the SCTP association and setup a new SCTP association over the same DTLS association?
>>
>>     Regards,
>>
>>     _____________
>>     Roman Shpount
>>
>>         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.
>>>         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.".
>>>         which explicitly refers to draft-ietf-rtcweb-data-channel, where only these two
>>>         transport stack cases are considered.
>>>
>>>         Regards,
>>>         Juergen
>>>
>>>>         <https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-1>).
>>>>             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
>>>>         <https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09#section-5.1.2.2>
>>>>         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
>>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Sep 2016 15:28:48 +0000

Hi,

>"Unless the offerer wants to re-establish an SCTP association, the offerer MUST associate an 
>SDP 'sctp-port' attribute, with a new attribute value, with the m- line..."
>
>If the previous SCTP association is closed, and if then a new SCTP association is established, is the idea to distinguish between a "re-establishment", where >the formerly used "sctp-port" values are re-used, and a "new establishment", where new values of "sctp-port" are used?

I was just having a chat with Roman about that.

In my opinion, the most simply way would be to say that whenever a new SCTP association is established, one MUST use a different sctp-port value than the previously used – no matter if the previous SCTP association exists or not.

Another question is whether the closure of an SCTP association requires explicit signalling. In that case, perhaps using a sctp-port value of zero? One can obviously set the m- line port to zero, which will close both the DTLS association and the SCTP association – but the question is whether there is a use-case where one would only want to close the SCTP association, without touching the DTLS association. BUNDLE?

Regards,

Christer

Thanks again,
Juergen

Hi,

Regards,

Christer

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

Juergen,

Regards,

_____________
Roman Shpount

On Wed, Sep 28, 2016 at 7:39 AM, Juergen Stoetzer-Bradler <[email-masked] <mailto:[email-masked]> > wrote:

Roman,

Best regards,
Juergen 

Juergen, 

Regards,

_____________
Roman Shpount

On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler <[email-masked] <mailto:[email-masked]> > wrote:

Roman, Paul,

Thanks again,
Juergen

1.  Introduction

   ...

   ...

   ...

 
   ...

Roman, Paul,

Regards,
Juergen

On Thu, Sep 15, 2016 at 6:54 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]> > wrote:

Regards, 

_____________
Roman Shpount

 ailman/listinfo/mmusic

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Thu, 29 Sep 2016 14:39:32 +0200

Hi Christer,

Regarding the establishment of a new SCTP association, yes, agree that the simplest way could be to 
request new sctp-port values being used - provided a new SDP offer/answer exchange is used. Would 
SCTP association endpoints be allowed to autonomously establish a new SCTP association using the old 
sctp-port values if the previous SCTP association failed for any reason. So far I would assume yes.

Regarding the explicit closure of an SCTP association while keeping the DTLS association - right now 
I also only would have the BUNDLE case in mind which you are mentioning.
That could indeed be a valid use case as far as I am concerned.

Thanks,
Juergen

On 28.09.2016 17:28, Christer Holmberg wrote:
> the idea to distinguish between a "re-establishment", where >the formerly used "sctp-port" values 
> are re-used, and a "new establishment", where new values of "sctp-port" are used?
>
> In my opinion, the most simply way would be to say that whenever a new SCTP association is 
> established, one MUST use a different sctp-port value than the previously used – no matter if the 
> previous SCTP association exists or not.
>
> Another question is whether the closure of an SCTP association requires explicit signalling. In 
> that case, perhaps using a sctp-port value of zero? One can obviously set the m- line port to 
> zero, which will close both the DTLS association and the SCTP association – but the question is 
> whether there is a use-case where one would only want to close the SCTP association, without 
> touching the DTLS association. BUNDLE?
>
> Regards,
>
> Christer
>
>
> Thanks again,
> Juergen
>
>     *From: *mmusic <[email-masked] <mailto:[email-masked]>> on behalf of Roman
>     Shpount <[email-masked] <mailto:[email-masked]>>
>     *Date: *Wednesday 28 September 2016 at 15:34
>     *To: *Juergen Stoetzer-Bradler <[email-masked]
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-09
>
>     Juergen,
>
>         As per my understanding it should indeed be allowed to shutdown an SCTP association and
>         then to establish a new one over the same DTLS association. Both SCTP association
>         endpoints would have to choose new values for the initiate tags / verification tags, such
>         that received SCTP packets could be uniquely associated with either the previous or the
>         new SCTP association.
>             After reading the multiplexing language, I have a related question: Is it allowed to
>             tear down the SCTP association and setup a new SCTP association over the same DTLS
>             association?
>
>             Regards,
>
>
>             _____________
>             Roman Shpount
>
>             On Tue, Sep 27, 2016 at 8:11 AM, Juergen Stoetzer-Bradler
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 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.
>                     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:
>                     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.
>                     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
>
>                             lower layers: UDP/DTLS/SCTP and TCP/DTLS/SCTP. (Because ICE might end
>                             up having to run over TCP rather than UDP.)
>
>                             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
>                             So why does this draft have to say *anything* about what is under
>                             SCTP? That is just a matter for each specific usage.
>