Subject: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

From: Bo Burman <[email-masked]>
Date: Wed, 25 Nov 2015 09:52:47 +0000

This is to announce a 4 week Working Group Last Call for

                draft-ietf-mmusic-data-channel-sdpneg-06

as proposed standard.

Please review and provide any comments you may have on the document by Wednesday, December 23, 2015. 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.

Thank you!

        Bo Burman (MMUSIC co-chair)

Draft information:

This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : SDP-based Data Channel Negotiation

        Authors         : Keith Drage

                          Maridi R. Makaraju (Raju)

                          Juergen Stoetzer-Bradler

                          Richard Ejzak

                          Jerome Marcon

                Filename        : draft-ietf-mmusic-data-channel-sdpneg-06.txt

                Pages           : 37

                Date            : 2015-10-19

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.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-06

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-06

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Groves <[email-masked]>
Date: Thu, 26 Nov 2015 11:39:22 +1100

Hello Juergen, all,

I have reviewed the document and I don't think there are any major 
issues preventing it from going forward. My comments below:

General: Double check acronyms are spelled out on first use, e.g. SCTP, SDP
General: Sometimes "subprotocol" is used, sometimes "sub-protocol" I 
guess we should be consistent.

Sect.1: The 2nd sentence seems confusing. I propose to reword "RTCWeb 
allows applications to use data channels. It RTCWeb defines an in-band 
DCEP however other in-band or out-of-band protocols may be used for 
establishing datachannels.

Sect.5.1.1: (defined in Section 4 ), this should probably be section 3?

Sect.5.1.1 1st para last sentence: Reliability is now two parameters: 
max-retr & max-time

Sect.5.1.1 1st para last sentence: Priority is not defined by the syntax 
however its part of DCEP. Do we need to add this?

Sect.5.1.1.1: "maxretr-value" should we actually add an ABNF value for 
this? The referred to draft doesn't have ABNF. Its a 2 byte integer

Sect.5.1.1.1: "maxtime-value" should we actually add an ABNF value for 
this? The referred to draft doesn't have ABNF. Its a 2 byte integer

Sect.5.1.1.1: The example for a=dcmap:4, wouldn't this be invalid as it 
contains both the max-time and max-retr parameters?

Sect.5.2.3, pg.14, 7th bullet: "Closes any created data channels for 
which the expected "a=dcmap:" and "a=dcsa:" attributes  are not present 
in the SDP answer." Should this also refer to section 5.2.4 on closure?

Sect.5.2.5: The miscellaneous section doesn't explicitly cover the case 
when a=dcmap is missing but a=dsca is included. I take it that its an 
error. Should we add this?

Sect.6 1st para under fig.2: "So, the offerer should  close the ..." is 
this really a "MUST close"? There is text about reusing a data channel 
but does it apply in this case when no previous data channel has been 
extablished?

Sect.6 bottom pg.18: "Continuing on the earlier example in Figure 1" Is 
this a continuation of figure 2? The text below figure 3 indicates that 
MSRP SCTP stream ID 2 is removed. This is example 2.

Sect.8.2.2: DCSA appropriate values. Now defined in sect. 5.1.2.1

Sect.11.2: There are no usages of RFCs 4975, 4976, 5547, 6135 and 6714 
in the document. These can be deleted.

Sect.11.2: There are no usages of RFC6455 and I-D.ietf-rtcweb-jsep the 
document other than in the changes section. These can be deleted.

Minor editorials: Sent offline to author.

Regards, Christian

On 25/11/2015 8:52 PM, Bo Burman wrote:
> Please review and provide any comments you may have on the document by 
> Wednesday, December 23, 2015. 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.
>
> Thank you!
>
>                 Filename        : 
> draft-ietf-mmusic-data-channel-sdpneg-06.txt
>
>                 Pages           : 37
>
>                 Date            : 2015-10-19
>
> Abstract:
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Thu, 26 Nov 2015 14:12:34 +0100

Hello Christian,

Thanks much for having reviewed the document and for all your comments.
Please see my replies below.

Best regards,
Juergen

On 26.11.2015 01:39, Christian Groves wrote:
> Hello Juergen, all,
>
> I have reviewed the document and I don't think there are any major issues preventing it from going 
> forward. My comments below:
>
[Juergen] Thanks, will do this.
> General: Sometimes "subprotocol" is used, sometimes "sub-protocol" I guess we should be consistent.
[Juergen] Ok, will make this consistent.
>
> Sect.1: The 2nd sentence seems confusing. I propose to reword "RTCWeb allows applications to use 
> data channels. It RTCWeb defines an in-band DCEP however other in-band or out-of-band protocols 
> may be used for establishing datachannels.
[Juergen] Thanks. This is clearer.
> Sect.5.1.1: (defined in Section 4 ), this should probably be section 3?
[Juergen] That's right. Will correct this.
>
> Sect.5.1.1 1st para last sentence: Reliability is now two parameters: max-retr & max-time
[Juergen] Indeed, would propose to replace "reliability" with "maximal number of retransmissions, 
maximal retransmission time, ...".
>
> Sect.5.1.1 1st para last sentence: Priority is not defined by the syntax however its part of DCEP. 
> Do we need to add this?
[Juergen] Indeed, that's missing. Would propose to extend the 'dcmap-opt' ABNF rule correspondingly:

    dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                      / maxretr-opt / maxtime-opt / priority-opt
                      ; Either only maxretr-opt or maxtime-opt
                      ; is present.

With 'priority-opt' being

    priority-opt    = "priority=" priority-value
    priority-value  = "0" / integer
                      ; unsigned integer value indicating the priority of the data channel
                      ; less than 2^16
                      ; derived from 'Priority' of
                      ; [I-D.ietf-rtcweb-data-protocol]

And would further propose to add a new sub section after current 5.1.1.8 (ordered Parameter) as follows:

5.1.1.8 priority Parameter
The 'priority' parameter indicates the data channel's priority
relative to the  priorities of other data channels, which may
additionally exist over the same SCTP association.
The 'priority' parameter maps to the 'Priority' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is optional.
In the absence of this parameter "priority=256" is assumed.

>
> Sect.5.1.1.1: "maxretr-value" should we actually add an ABNF value for this? The referred to draft 
> doesn't have ABNF. Its a 2 byte integer
[Juergen] Agree. How about:

    maxretr-value   = "0" / integer
                      ; number of retransmissions
                      ; less than 2^32
                      ; derived from 'Reliability Parameter' of
                      ; [I-D.ietf-rtcweb-data-protocol]

>
> Sect.5.1.1.1: "maxtime-value" should we actually add an ABNF value for this? The referred to draft 
> doesn't have ABNF. Its a 2 byte integer
[Juergen] Agree. Similar as above, this could be

    maxtime-value   = "0" / integer
                      ; milliseconds
                      ; less than 2^32
                      ; derived from 'Reliability Parameter' of
                      ; [I-D.ietf-rtcweb-data-protocol]

>
> Sect.5.1.1.1: The example for a=dcmap:4, wouldn't this be invalid as it contains both the max-time 
> and max-retr parameters?
[Juergen] Yes, indeed. One of both parameters needs to be removed. As the preceding example for 
a=dcmap:3 contains the max-retr parameter I'd propose to remove the max-retr parameter from the 
a=dcmap:4 line.
>
> Sect.5.2.3, pg.14, 7th bullet: "Closes any created data channels for which the expected "a=dcmap:" 
> and "a=dcsa:" attributes  are not present in the SDP answer." Should this also refer to section 
> 5.2.4 on closure?
[Juergen] Agree. Will add a reference to section 5.2.4.
>
> Sect.5.2.5: The miscellaneous section doesn't explicitly cover the case when a=dcmap is missing 
> but a=dsca is included. I take it that its an error. Should we add this?
[Juergen] Good point. I would also consider this as an error. Agree to add related text, e.g.:

SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes
* This is considered an error case. In this case the receiver of such an
   SDP offer or answer SHOULD ignore the "a=dcsa:" attributes and SHOULD
   process the SDP offer or answer as per above case 'SDP offer has no
   "a=dcmap:" attributes' or case 'SDP answer has no "a=dcmap:" attributes'.

>
> Sect.6 1st para under fig.2: "So, the offerer should  close the ..." is this really a "MUST 
> close"? There is text about reusing a data channel but does it apply in this case when no previous 
> data channel has been extablished?
[Juergen] Quite agree. As per the corresponding description in section 5.2.3 ("The agent receiving 
such an SDP answer performs the following:  o  Closes any created data channels for which the 
expected "a=dcmap:" and "a=dcsa:" attributes are not present in the SDP answer.") the SDP offerer in 
example 2 actually must close the data channel with SCTP stream id 0.
As the text in the paragraph after figure 2 is just focused on example 2, should we actually say 
"...the offerer MUST close the data channel for BFCP ...", or rather "... the offerer must close ..."?
>
> Sect.6 bottom pg.18: "Continuing on the earlier example in Figure 1" Is this a continuation of 
> figure 2? The text below figure 3 indicates that MSRP SCTP stream ID 2 is removed. This is example 2.
[Juergen] Yes, you are right. This needs to be changed to "The above example is a continuation of 
the example in Figure 2".
> Sect.8.2.2: DCSA appropriate values. Now defined in sect. 5.1.2.1
[Juergen] Indeed. Will change this to section 5.1.2.1.
>
> Sect.11.2: There are no usages of RFCs 4975, 4976, 5547, 6135 and 6714 in the document. These can 
> be deleted.
[Juergen] Agree. Will delete these MSRP related references.
>
> Sect.11.2: There are no usages of RFC6455 and I-D.ietf-rtcweb-jsep the document other than in the 
> changes section. These can be deleted.
[Juergen] Agree. Will also delete these.
>> Please review and provide any comments you may have on the document by Wednesday, December 23, 
>> 2015. 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.
>>
>> Thank you!
>>

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Nov 2015 09:56:09 +1100

Hello Juergen,

Thanks for the updates. Please see my responses below.

Regards, Christian

..snip..
> [Juergen] Indeed, would propose to replace "reliability" with "maximal 
> number of retransmissions, maximal retransmission time, ...".
[CNG] OK
>>
>> Sect.5.1.1 1st para last sentence: Priority is not defined by the 
>> syntax however its part of DCEP. Do we need to add this?
[CNG] The proposal is OK for me. Perhaps it would be worth adding the 
priority parameter to one of the examples?

>>
>> Sect.5.1.1.1: "maxretr-value" should we actually add an ABNF value 
>> for this? The referred to draft doesn't have ABNF. Its a 2 byte integer
[CNG] OK
>
>>
>> Sect.5.1.1.1: "maxtime-value" should we actually add an ABNF value 
>> for this? The referred to draft doesn't have ABNF. Its a 2 byte integer
[CNG] OK
>
>>
>> Sect.5.1.1.1: The example for a=dcmap:4, wouldn't this be invalid as 
>> it contains both the max-time and max-retr parameters?
> [Juergen] Yes, indeed. One of both parameters needs to be removed. As 
> the preceding example for a=dcmap:3 contains the max-retr parameter 
> I'd propose to remove the max-retr parameter from the a=dcmap:4 line.
[CNG] OK
>> which the expected "a=dcmap:" and "a=dcsa:" attributes  are not 
>> present in the SDP answer." Should this also refer to section 5.2.4 
>> on closure?
[CNG] OK
>>
>> Sect.5.2.5: The miscellaneous section doesn't explicitly cover the 
>> case when a=dcmap is missing but a=dsca is included. I take it that 
>> its an error. Should we add this?
[CNG] OK
>
>>
>> Sect.6 1st para under fig.2: "So, the offerer should  close the ..." 
>> is this really a "MUST close"? There is text about reusing a data 
>> channel but does it apply in this case when no previous data channel 
>> has been extablished?
> [Juergen] Quite agree. As per the corresponding description in section 
> 5.2.3 ("The agent receiving such an SDP answer performs the 
> following:  o  Closes any created data channels for which the expected 
> "a=dcmap:" and "a=dcsa:" attributes are not present in the SDP 
> answer.") the SDP offerer in example 2 actually must close the data 
> channel with SCTP stream id 0.
> As the text in the paragraph after figure 2 is just focused on example 
> 2, should we actually say "...the offerer MUST close the data channel 
> for BFCP ...", or rather "... the offerer must close ..."?
[CNG] How about avoiding "must" or "should" by saying the " ... The 
offerer closes the data or BFCP ..."? That's descriptive of the example.

..snip..

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 30 Nov 2015 13:55:53 +0100

Hello Christian,

Thanks for further feedback.
As you propose, I'll add the "priority" parameter to one or two of the examples in section 5.1.1.1
and will reformulate the sentence after figure 2 correspondingly.

Thanks,
Juergen

On 26.11.2015 23:56, Christian Groves wrote:
>>> Sect.5.1.1 1st para last sentence: Priority is not defined by the syntax however its part of 
>>> DCEP. Do we need to add this?
> [CNG] The proposal is OK for me. Perhaps it would be worth adding the priority parameter to one of 
> the examples?
>
>>>
>>> Sect.5.1.1.1: "maxretr-value" should we actually add an ABNF value for this? The referred to 
>>> draft doesn't have ABNF. Its a 2 byte integer
>>> Sect.5.1.1.1: "maxtime-value" should we actually add an ABNF value for this? The referred to 
>>> draft doesn't have ABNF. Its a 2 byte integer
>>> Sect.5.1.1.1: The example for a=dcmap:4, wouldn't this be invalid as it contains both the 
>>> max-time and max-retr parameters?
>>> Sect.5.2.3, pg.14, 7th bullet: "Closes any created data channels for which the expected 
>>> "a=dcmap:" and "a=dcsa:" attributes  are not present in the SDP answer." Should this also refer 
>>> to section 5.2.4 on closure?
>>> close"? There is text about reusing a data channel but does it apply in this case when no 
>>> previous data channel has been extablished?
>> [Juergen] Quite agree. As per the corresponding description in section 5.2.3 ("The agent 
>> receiving such an SDP answer performs the following:  o  Closes any created data channels for 
>> which the expected "a=dcmap:" and "a=dcsa:" attributes are not present in the SDP answer.") the 
>> SDP offerer in example 2 actually must close the data channel with SCTP stream id 0.
> [CNG] How about avoiding "must" or "should" by saying the " ... The offerer closes the data or 
> BFCP ..."? That's descriptive of the example.
>
> ..snip..

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Nov 2015 10:36:03 -0500

One thing occurred to me that we may have forgotten about:

This draft introduces the dcsa attribute, which allows other attributes 
to be used in this new scope. It notes that not all attributes are 
suitable for use this way.

ISTM that in the future other attribute definitions should include an 
indication of whether they can be used with dcsa, and the IANA 
registration of the attribute ought to include this. And then there is a 
need to update the iana registry for all the existing attributes.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 1 Dec 2015 11:53:15 +1100

Hello Paul,

I actually meant to post the reply to the list, sorry for the confusion.

I do understand your concerns. For multiplexing it makes sense to check 
all the existing attributes to see whether they're applicable due to the 
fact that quite alot may be used when multiplexing occurs. I think the 
data channel usage is quite a bit more narrow in scope.

Whilst this draft does introduce a general purpose mechanism the actual 
use of the dcsa is being defined by other drafts. E.g.
draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what happens 
when both a=setup and a=dcsa:setup are present. msrp-cema is another one 
discussed, etc.

I think you need to understand the application protocol being carried in 
a data channel before you can say whether particular attributes should 
be carried in dcsa and what that actually means. Going through the IANA 
registry wouldn't be trivial and unless the attributes are put in 
context of an application protocol I don't think it will be terribly 
helpful.

draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate that 
the dsca parameters follow the procedures defined in the subprotocol 
specific documents. Maybe we could strengthen this to indicate that the 
use of dsca by an application protocol should be documented in a 
specification?

Regards, Christian

On 1/12/2015 11:30 AM, Paul Kyzivat wrote:
> Christian,
>
> On 11/30/15 6:45 PM, Christian Groves wrote:
>> Is this level of detail really needed? There are several drafts for
>> CLUE, MSRP and BFCP related to the use of this sdpneg mechanism. E.g.
>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of dcsa.
>>
>> Can't we just follow the principle that the use of the dcsa attribute
>> should be detailed in a specification and leave it at that? I'm not sure
>> what we gain by analysing every existing attribute and forcing every new
>> attribute to do this analyses when the set of possible parameters in
>> likely to be very small.
>
> I guess it is arguable both ways. Originally there was only session 
> level and media level. That was always supposed to be identified, but 
> it wasn't always followed.
>
> Then we got source level. That has complicated the registry and the 
> usage. I am not convinced that two SDP experts would come up with the 
> same list of which attributes can be used at source level.
>
> The dcsa attribute becomes the 4th "level" for attributes. It at least 
> makes sense to me that it ought to be managed analogously to the 
> source attribute. But I agree it doesn't provide the same degree of 
> confusion as the others. It only makes sense if the usage the 
> attribute applies to works over a data channel. And that should be 
> known to whatever is processing the SDP.
>
> I see this was a private message. Why don't you repost it on the list 
> and lets see what other people think? (Feel free to repost this reply 
> if you wish.)
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote:
>>> This draft introduces the dcsa attribute, which allows other
>>> attributes to be used in this new scope. It notes that not all
>>> attributes are suitable for use this way.
>>>
>>> registration of the attribute ought to include this. And then there is
>>> a need to update the iana registry for all the existing attributes.
>>>
>>>     Thanks,
>>>     Paul
>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 1 Dec 2015 01:12:50 +0000

I think we need to be a little bit careful here.

In a large number of cases, the use of the attribute will be unaltered by the transport that is being used, and I do not think we should have a need of saying anything if this is the case - it should be the default.

So for example for MSRP, there are a number of attributes associated with MSRP - for file transfer and so on, and as far as I can tell, they are used when MSRP is sent over a data channel in exactly the same way as when MSRP is sent over TCP or SCTP. We don't write special rules for TCP, so why write special rules for datachannel.

We do need to identify how we document any special cases, and yes when we find them, drafts like the msrp draft are the way to do that.

Additionally, if we find when defining a new attribute, that it is inappropriate for datachannel usage in some way, then we can write that in the defining specification for the new attribute (although I suspect in this case it will be inappropriate to other transports than just datachannel).

I do assume this entire discussion is limited to attributes that can be applied to media lines. We might find it useful to say that in the general draft, if we have not done so already.

Regards

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 01 December 2015 00:53
To: [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Hello Paul,

I do understand your concerns. For multiplexing it makes sense to check all the existing attributes to see whether they're applicable due to the fact that quite alot may be used when multiplexing occurs. I think the data channel usage is quite a bit more narrow in scope.

Whilst this draft does introduce a general purpose mechanism the actual use of the dcsa is being defined by other drafts. E.g.
draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what happens when both a=setup and a=dcsa:setup are present. msrp-cema is another one discussed, etc.

I think you need to understand the application protocol being carried in a data channel before you can say whether particular attributes should be carried in dcsa and what that actually means. Going through the IANA registry wouldn't be trivial and unless the attributes are put in context of an application protocol I don't think it will be terribly helpful.

draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate that the dsca parameters follow the procedures defined in the subprotocol specific documents. Maybe we could strengthen this to indicate that the use of dsca by an application protocol should be documented in a specification?

Regards, Christian

On 1/12/2015 11:30 AM, Paul Kyzivat wrote:
>> should be detailed in a specification and leave it at that? I'm not 
>> sure what we gain by analysing every existing attribute and forcing 
>> every new attribute to do this analyses when the set of possible 
>> parameters in likely to be very small.
>
>>> ISTM that in the future other attribute definitions should include 
>>> an indication of whether they can be used with dcsa, and the IANA 
>>> registration of the attribute ought to include this. And then there 
>>> is a need to update the iana registry for all the existing attributes.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Please review and provide any comments you may have on the document 
>>>> by Wednesday, December 23, 2015. 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.
>>>>
>>>> Thank you!
>>>>