Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 5 Oct 2015 14:56:58 +0200

Hello,

This version 05 adds the IANA registration sections for the dcmap and dcsa attributes
and adds new mux category related sections for both attributes.
It also adds [I-D.ietf-mmusic-sdp-mux-attributes] to the list of normative references,
as that draft is referenced by the two new mux category sections.

Additionally, this version updates section 5.1.1.5 regarding the dmap's 'subprotocol' parameter
as per the related MMUSIC discussion initiated by Christian in August,
http://www.ietf.org/mail-archive/web/mmusic/current/msg14946.html

Thanks,
Juergen

On 05.10.2015 14:45, [email-masked] wrote:
> A new version of I-D, draft-ietf-mmusic-data-channel-sdpneg-05.txt
> has been successfully submitted by Juergen Stoetzer-Bradler and posted to the
> IETF repository.
>
> Name:		draft-ietf-mmusic-data-channel-sdpneg
> Revision:	05
> Title:		SDP-based Data Channel Negotiation
> Document date:	2015-10-05
> Group:		mmusic
> Pages:		35
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-data-channel-sdpneg-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-05
>
> 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, where each data channel might be used to
>     transport other protocols, called sub-protocols.  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 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.  This
>     document is intended to be used wherever data channels are used.
>
>                                                                                    
>
>
> 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.
>
> The IETF Secretariat
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Oct 2015 17:12:20 -0400

These changes mostly seem good. I have a couple of small points:

* Section 5.1.1.2:

This section starts with:

    The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
    Usage of this attribute is only applicable when associated with
    UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines.

One issue is that usage of this attribute is also defined over pure 
SCTP. So I think it would be more accurate to say "*Multiplexing* of 
this attribute...".

Also, saying this is *only applicable* unnecessarily blocks future 
changes. I think it would be better to say *only defined*, or *outside 
the scope*.

* Section 5.1.2.2:

Analogous comment to that for 5.1.1.2.

* Section 8.2:

IIUC current practice is for documents coming through WGs to list the WG 
chair (e.g. [email-masked]) as the contact.

	Thanks,
	Paul

On 10/5/15 8:56 AM, Juergen Stoetzer-Bradler wrote:
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-mmusic-data-channel-sdpneg-05.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-05
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-05
>>
>>
>> Abstract:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 6 Oct 2015 17:18:29 +0200

Hello Paul,

Thanks much for your comments.
Please see my replies inserted below.

Thank you,
Juergen

On 05.10.2015 23:12, Paul Kyzivat wrote:
> One issue is that usage of this attribute is also defined over pure SCTP. So I think it would be 
> more accurate to say "*Multiplexing* of this attribute...".
[Juergen] In this second paragraph of 5.1.1.2 I wanted to express that this document defines the 
a=dcmap attribute only for
X/DTLS/SCTP attribute lines - quite similar to the mux category description of the a=sctp-port 
attribute in section 5.3 of draft-ietf-mmusic-sctp-sdp-15.
As multiplexing of multiple SCTP associations over one DTLS connection is not considered by 
draft-ietf-mmusic-sctp-sdp,
and as there can be just one DTLS connection within one BUNDLE group (potentially used by multiple 
media descriptions within this BUNDLE group)
my understanding is that in fact there can be just one SCTP association over DTLS within such a 
BUNDLE group.
Therefore I thought there's no need to define a multiplexing semantic for the a=dcmap (and a=dcsa) 
attribute (as described in the 3rd paragraph).

I am not sure "Multiplexing of this attribute is only applicable when associated with X/DTLS/SCTP 
"m" line" would be consistent
with the intended meaning of the 3rd paragraph.

>
> Also, saying this is *only applicable* unnecessarily blocks future changes. I think it would be 
> better to say *only defined*, or *outside the scope*.
[Juergen] Agree. How about the following?
"This document defines usage of this attribute only when associated with UDP/DTLS/SCTP or 
TCP/DTLS/SCTP proto SDP "m" lines".

> IIUC current practice is for documents coming through WGs to list the WG chair (e.g. 
> [email-masked]) as the contact.
[Juergen] I see, thanks,
Thus contact name would then e.g. be "MMUSIC Chairs"?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Oct 2015 12:37:30 -0400

See inline.

On 10/6/15 11:18 AM, Juergen Stoetzer-Bradler wrote:
> [Juergen] In this second paragraph of 5.1.1.2 I wanted to express that
> this document defines the a=dcmap attribute only for
> X/DTLS/SCTP attribute lines - quite similar to the mux category
> description of the a=sctp-port attribute in section 5.3 of
> draft-ietf-mmusic-sctp-sdp-15.
> As multiplexing of multiple SCTP associations over one DTLS connection
> is not considered by draft-ietf-mmusic-sctp-sdp,
> and as there can be just one DTLS connection within one BUNDLE group
> (potentially used by multiple media descriptions within this BUNDLE group)
> my understanding is that in fact there can be just one SCTP association
> over DTLS within such a BUNDLE group.
> Therefore I thought there's no need to define a multiplexing semantic
> for the a=dcmap (and a=dcsa) attribute (as described in the 3rd paragraph).
>
> I am not sure "Multiplexing of this attribute is only applicable when
> associated with X/DTLS/SCTP "m" line" would be consistent
> "This document defines usage of this attribute only when associated with
> UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines".

Ahh! I think we disagree on what the scope of this draft should be.

draft-ietf-mmusic-sctp-sdp defines several transport configurations for 
sctp: SCTP, SCTP/DTLS, UDP/DTLS/SCTP, TCP/DTLS/SCTP.

draft-ietf-rtcweb-data-channel defines data channels over sctp, but 
doesn't anything about allowed transport configurations of sctp.

Elsewhere webrtc specifies that only UDP/DTLS/SCTP and TCP/DTLS/SCTP are 
to be used for webrtc data channels.

I guess this draft is trying to restrict its applicability to only 
UDP/DTLS/SCTP and TCP/DTLS/SCTP. I see no reason to do that. This draft 
defines the dcmap and dcsa attributes. AFAIK there is *nothing* that 
prevents using data channels and these attributes over SCTP or 
SCTP/DTLS. That ought to be allowed and covered by this document.

Multiplexing in bundles is a different matter. As you point out, use in 
bundles is not defined for SCTP and SCTP/DTLS, while UDP/DTLS/SCTP and 
TCP/DTLS/SCTP can appear at most once in a bundle. So multiplexing of 
these attributes in bundles is currently undefined. This needs to be 
noted (and left for future work), but without excluding *unbundled* use 
with the other transports.

>> IIUC current practice is for documents coming through WGs to list the
>> WG chair (e.g. [email-masked]) as the contact.
> [Juergen] I see, thanks,

Yeah, I think so.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 9 Oct 2015 14:17:02 +1100

Hello Juergen and Paul,

You're updates look OK to me. I think this is ready for WGLC.

Please see below.

> draft-ietf-mmusic-sctp-sdp defines several transport configurations 
> for sctp: SCTP, SCTP/DTLS, UDP/DTLS/SCTP, TCP/DTLS/SCTP.
>
> Elsewhere webrtc specifies that only UDP/DTLS/SCTP and TCP/DTLS/SCTP 
> are to be used for webrtc data channels.
>
> UDP/DTLS/SCTP and TCP/DTLS/SCTP. I see no reason to do that. This 
> draft defines the dcmap and dcsa attributes. AFAIK there is *nothing* 
> that prevents using data channels and these attributes over SCTP or 
> Multiplexing in bundles is a different matter. As you point out, use 
> in bundles is not defined for SCTP and SCTP/DTLS, while UDP/DTLS/SCTP 
> and TCP/DTLS/SCTP can appear at most once in a bundle. So multiplexing 
> of these attributes in bundles is currently undefined. This needs to 
> be noted (and left for future work), but without excluding *unbundled* 
> use with the other transports.

Do we really need to extend the scope to SCTP or SCTP/DTLS? The 
mechanism is clearly related to the use of WebRTC data channel. Is SCTP 
and SCTP/DTLS going to be used for data channel in the future? There is 
"something" preventing data channels being used on SCTP or SCTP/DTLS its 
draft-ietf-rtcweb-data-channel which clearly shows the stack as 
UDP/DTLS/SCTP and TCP/DTLS/SCTP.

Regards, Christian

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 9 Oct 2015 14:54:42 +0200

Hello Paul, Christian,

Thank you for your feedback.

I was indeed much focused on the WebRTC data channel protocol stacks (SCTP over DTLS) when writing 
the mux category sections for dcmap and dcsa.
My reading of draft-ietf-rtcweb-data-channel-13 (e.g. sec 6.1) is that DTLS transport of SCTP must 
actually be used.
However, in order not to explicitly restrict potential future usage of the dcmap and dcsa attributes 
to x/DTLS/SCTP m-lines I'd propose to modify the text in section
5.1.1.2 as follows. (And correspondingly to also modify the dcsa related text in 5.1.2.2.)

Would you agree to following wording?

5.1.1.2.  dcmap Multiplexing Category
    Multiplexing characteristics of SDP attributes are described in
    [I-D.ietf-mmusic-sdp-mux-attributes].  Various SDP attribute
    multiplexing categories are introduced there.

    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.
    This document also does not specify multiplexing rules for this attribute
    for SCTP or SCTP/DTLS proto values.
    If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate
    multiplexing of multiple SCTP associations of top of a single DTLS connection
    or how to multiplex multiple SCTP associations within 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.

Thanks,
Juergen

On 09.10.2015 05:17, Christian Groves wrote:
>> draft-ietf-mmusic-sctp-sdp defines several transport configurations for sctp: SCTP, SCTP/DTLS, 
>> UDP/DTLS/SCTP, TCP/DTLS/SCTP.
>>
>> draft-ietf-rtcweb-data-channel defines data channels over sctp, but doesn't anything about 
>> allowed transport configurations of sctp.
>>
>> Elsewhere webrtc specifies that only UDP/DTLS/SCTP and TCP/DTLS/SCTP are to be used for webrtc 
>> data channels.
>>
>> I guess this draft is trying to restrict its applicability to only UDP/DTLS/SCTP and 
>> TCP/DTLS/SCTP. I see no reason to do that. This draft defines the dcmap and dcsa attributes. 
>> AFAIK there is *nothing* that prevents using data channels and these attributes over SCTP or 
>> Multiplexing in bundles is a different matter. As you point out, use in bundles is not defined 
>> for SCTP and SCTP/DTLS, while UDP/DTLS/SCTP and TCP/DTLS/SCTP can appear at most once in a 
>> bundle. So multiplexing of these attributes in bundles is currently undefined. This needs to be 
>> noted (and left for future work), but without excluding *unbundled* use with the other transports.
>
> Do we really need to extend the scope to SCTP or SCTP/DTLS? The mechanism is clearly related to 
> the use of WebRTC data channel. Is SCTP and SCTP/DTLS going to be used for data channel in the 
> future? There is "something" preventing data channels being used on SCTP or SCTP/DTLS its 
> draft-ietf-rtcweb-data-channel which clearly shows the stack as UDP/DTLS/SCTP and TCP/DTLS/SCTP.
>
> Regards, Christian
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 21 Oct 2015 17:01:51 +0200

Hello Juergen,

Sorry for the slow reply. Its OK with me.

Regards, Christian

On 9/10/2015 2:54 PM, Juergen Stoetzer-Bradler wrote:
> I was indeed much focused on the WebRTC data channel protocol stacks 
> (SCTP over DTLS) when writing the mux category sections for dcmap and 
> dcsa.
> My reading of draft-ietf-rtcweb-data-channel-13 (e.g. sec 6.1) is that 
> DTLS transport of SCTP must actually be used.
> However, in order not to explicitly restrict potential future usage of 
> the dcmap and dcsa attributes to x/DTLS/SCTP m-lines I'd propose to 
> modify the text in section
>>> draft defines the dcmap and dcsa attributes. AFAIK there is 
>>> *nothing* that prevents using data channels and these attributes 
>>> over SCTP or SCTP/DTLS. That ought to be allowed and covered by this 
>>> document.
>>>
>>> in bundles is not defined for SCTP and SCTP/DTLS, while 
>>> UDP/DTLS/SCTP and TCP/DTLS/SCTP can appear at most once in a bundle. 
>>> So multiplexing of these attributes in bundles is currently 
>>> undefined. This needs to be noted (and left for future work), but 
>>> without excluding *unbundled* use with the other transports.
>>
>> mechanism is clearly related to the use of WebRTC data channel. Is 
>> SCTP and SCTP/DTLS going to be used for data channel in the future? 
>> There is "something" preventing data channels being used on SCTP or 
>> SCTP/DTLS its draft-ietf-rtcweb-data-channel which clearly shows the 
>> stack as UDP/DTLS/SCTP and TCP/DTLS/SCTP.
>>
>> Regards, Christian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2015 11:49:39 -0400

Sorry for not responding sooner. I see you put the proposed language 
into -06. I'm satisfied with that.

	Thanks,
	Paul

On 10/9/15 8:54 AM, Juergen Stoetzer-Bradler wrote:
> (SCTP over DTLS) when writing the mux category sections for dcmap and dcsa.
>>> and TCP/DTLS/SCTP can appear at most once in a bundle. So
>>> multiplexing of these attributes in bundles is currently undefined.
>>> This needs to be noted (and left for future work), but without
>>> excluding *unbundled* use with the other transports.
>>