Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

From: Bo Burman <[email-masked]>
Date: Wed, 9 Jan 2019 13:16:26 +0000

I think Ben's opinion was that it is OK to stay with FCFS and to use the WebSocket registry, but that the text must then at least not require sub-protocol specification anywhere, which I believe is part of a single option.

I thought a bit more on this, trying to understand what could have been the reasons for the existing formulations that require specification. It seems to me that for any sub-protocol where stand-alone usage of that protocol (that is, not as sub-protocol of data channel) has existing offer/answer specifications, e.g. MSRP or BFCP, it would make sense to require specification also for data channel sub-protocol usage. For other protocols in the WebSocket registry that has no existing offer/answer considerations when used stand-alone, no specification would be required.

This could be achieved by something similar to:
"The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  A sub-protocol
   specification MUST define the offer/answer procedures for the dsca
   attribute (if applicable) associated with the sub-protocol, if the 
   sub-protocol has defined offer/answer procedures when used outside
   of dcsa.  If no offer/answer procedures exist for the sub-protocol when used
   outside of the dcsa attribute, no specification is required for use with dcsa."

/Bo
(as individual)

-----Original Message-----
From: Roni Even (A) <[email-masked]> 
Sent: den 24 december 2018 10:29
To: Bo Burman <[email-masked]>; Ben Campbell <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Hi Bo,
I am not sure what is the suggestion since there are two options.

We can keep the current registration and recommend that a spec with offer answer should be available Is this OK Roni

-----Original Message-----
From: Bo Burman [mailto:[email-masked]]
Sent: Friday, December 14, 2018 4:32 PM
To: Ben Campbell; Roni Even (A)
Cc: Paul Kyzivat; [email-masked]
Subject: RE: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Roni,

Please go ahead and make the changes suggested by Ben below and submit a new version at your earliest convenience.

Thanks
/Bo
MMUSIC co-chair

-----Original Message-----
From: Ben Campbell <[email-masked]>
Sent: den 11 december 2018 18:25
To: Roni Even (A) <[email-masked]>
Cc: Bo Burman <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

As a reminder, my concern was that the draft contains language that assumes a specification will exist. For example, §6 says:

"The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  A sub-protocol
   specification MUST define the offer/answer procedures for the dsca
   attribute (if applicable) associated with the sub-protocol."

If it is possible to register a data-channel sub-protocol without a spec, then the text that assumes a spec will exist needs to be revised. I understand the desire to share the websocket subprotocol registry, but the need for documented offer/answer procedures suggests that FCFS is not the right policy for data-channel subprotocols.

For the record, I would be okay with it if the wg decides to stick with FCFS, but the text would need to change in a few places to remove the assumptions that a spec would exist. We would, of course, have to accept the idea of a data-channel subprotocol with no documented offer/answer considerations. That might be okay if we allow private-use protocols and just want to avoid collisions.

Thanks!

Ben.

> On Dec 11, 2018, at 4:15 AM, Roni Even (A) <[email-masked]> wrote:
> 
> Hi Bo,
> I am not sure I understand the issue. According to section 9.1
> 
> A subprotocol may simultaneously be defined for data channel
>   transport and for Websocket transport.  In such a case the
>   "Subprotocol Definition" and "Reference" cells in the subprotocol's
>   row of the IANA "WebSocket Subprotocol Name Registry" table should
>   contain two entries.  One entry in each of these cells should refer
>   to the Websocket related subprotocol specification, and the other
>   entry should refer to the data channel related subprotocol
>   specification.
> 
> This applies to the msrp case if it was registered also for data channel.
> 
> I am not sure what we will have with a second registry is it only for data channel usage and we will not register it also in the web socket registry?
> 
> 
> 
> Roni
> 
> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Bo Burman
> Sent: Friday, December 07, 2018 10:55 AM
> To: Ben Campbell; Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [MMUSIC] AD Evaluation of 
> draft-ietf-mmusic-data-channel-sdpneg-20
> 
> When looking at the now expired draft-ietf-mmusic-msrp-usage-data-channel, I think the content clearly hints that at least for MSRP, a tag without further specification would simply not achieve interoperable implementations. I believe the same would be valid for many other subprotocols. Therefore, I share Ben's concern that FCFS doesn't seem generally sufficient.
> 
> /Bo (as individual)
> 
> -----Original Message-----
> From: mmusic <[email-masked]> On Behalf Of Ben Campbell
> Sent: den 27 november 2018 23:53
> To: Paul Kyzivat <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [MMUSIC] AD Evaluation of 
> draft-ietf-mmusic-data-channel-sdpneg-20
> 
> 
> 
>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <[email-masked]> wrote:
>> 
>> On 11/26/18 5:32 PM, Ben Campbell wrote:
>> 
>>>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.
>> 
>> IIRC this choice was made by the rtcweb wg. I don't recall how it was made.
>> 
>> It is my impression there is an expectation that many websocket protocols could also be used over data channels in order to get multiplexing of the socket.
> 
> I can accept that the reason might be “because that was what the WG wanted”, but isn’t there still a mismatch with the registration policy? This draft seems to expect subprotocol specifications -- is FCFS acceptable?
> 
>> 
>> 	Thanks,
>> 	Paul
>> 
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Jan 2019 13:10:51 -0600

> On Jan 9, 2019, at 7:16 AM, Bo Burman <[email-masked]> wrote:
> 

To be clear, I was not expressing a preference; I was saying I will support the WG decision, whichever that is.  But see below...

>   outside of the dcsa attribute, no specification is required for use with dcsa.”

Wouldn’t that need an expert review to determine if there was a need for offer/answer procedures? I don’t think we want to ask IANA to distinguish between things that have existing offer/answer specs and things that do not.

For the case of no offer/answer procedures existing: Would that assume a proprietary mechanism, where all we are doing is collision-avoidance? (I assume in these cases someone has an application doing something with offer/answer; they just aren’t publishing the details.)

---

From: Bo Burman <[email-masked]>
Date: Thu, 10 Jan 2019 08:44:04 +0000

Please see Inline below. /Bo

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: den 9 januari 2019 20:11
To: Bo Burman <[email-masked]>
Cc: Roni Even (A) <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

[BoB] I was thinking that the protocol specification of the sub-protocol (when not used as sub-protocol) would reasonably have to be referenced and for some of those it will be clear that offer/answer already exist. But agree, it might be very unclear for others and it seems expert review would in general be needed.

[BoB] Yes. It would also include the case where the proprietary mechanism is void, that is, no offer/answer procedures are needed, only simple identification of the sub-protocol.

> We can keep the current registration and recommend that a spec with 
> offer answer should be available Is this OK Roni
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 10 Jan 2019 08:30:23 +0000

Hi,
In my view the suggested text from Bo is OK even though I think that there is no problem with the current text in the last paragraph of section 6 and the IANA section.
The IANA section just ask to mention this document in the reference and add to the notes that is there is usage for both data channel and websocket and there are two separate documents they should both be mentioned in the registry.

The text in section 6 is for the case when a document will reference this document (sdpneg) it MUST include an offer answer procedure as specified in section 6. For example the CLUE data channel https://tools.ietf.org/html/draft-ietf-clue-datachannel-15 in section 3.3.2  and section 3.3.3 specifies such usage for data channel.

My view is that if a document references this document it MUST include the offer/answer section as mentioned in section 6.

Roni Even

---

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 17:14:35 -0600

Hi, what is the status of this? Any chance of submitting a new revision soon?

Thanks!

Ben.

> On Nov 26, 2018, at 4:32 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 
> Version 22 resolves most, but not all of my comments. I’ve copied the unaddressed comments below for reference. It may be that people disagree with my comments or suggestions, but if so please tell me so we can discuss :-)
> 
>> On Aug 27, 2018, at 10:06 PM, Ben Campbell <[email-masked]> wrote:
>> 
> 
> [...]
> 
>> Substantive Comments:
>> 
>> - There are 6 authors listed. Normally the limit is 5 unless there is a really good reason. Did all of the authors contribute substantial text? Could the author list be reduced to just editors, and have the rest in a “contributors” section?
> 
> Please note that, unless I can offer a really good reason why this needs more than 5 authors, this issue is almost certain to generate one or more DISCUSS positions during IESG evaluation.
> 
> [...]
> 
> 
>> §8: I am skeptical that this adds no security considerations above those in sctp-sdp. In particular, it seems worth mentioning that each subprotocol may come with it’s own security considerations that need to be documented as part of the subprotocol definition. (As an example, MSRP has security considerations about the URL used in the a=path attribute that would apply to any definition of the use of “path” at the dcsa level.)
> 
> [...]
> 
>> 
> [...]
>> Editorial Comments:
>> - Abstract: The abstract will not age well. Years from now, no one will think in terms of what RTCWeb vs some other working group defined. I suggest recasting this in terms of the documents and protocols, not the working groups.  (Comment repeats for introduction.)
>> 
> 
> [...]
> 
>> 
>> §9.3, first paragraph: " SDP attributes that are defined for use at the dcsa
>>  usage level only SHALL use the dcsa usage level when registering the
>>  attribute.”
>> 
>> I don’t understand this sentence. Consider a MUST NOT/SHALL NOT construction.
>> 
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 17 Jan 2019 08:47:46 +0000

Hi Ben,
Submitted a new revision -23
Changes from -22

1. Change the abstract and introduction sections to remove reference to WGs (RTCWEB)
2. Update the security section with your comment
3. Added the text proposed by Bo to section 5.2

As for the number of authored. There were 5 authored when I took the editorship of the document.  I assume this issue is for the WG chairs

Ron Even

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2019 1:15 AM
To: [email-masked]
Cc: mmusic WG
Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Thanks!

Ben.

> Version 22 resolves most, but not all of my comments. I’ve copied the 
> unaddressed comments below for reference. It may be that people 
> disagree with my comments or suggestions, but if so please tell me so 
> we can discuss :-)
> 
>> §8: I am skeptical that this adds no security considerations above 
>> those in sctp-sdp. In particular, it seems worth mentioning that each 
>> subprotocol may come with it’s own security considerations that need 
>> to be documented as part of the subprotocol definition. (As an 
>> example, MSRP has security considerations about the URL used in the 
>> a=path attribute that would apply to any definition of the use of 
>> “path” at the dcsa level.)
> 
> [...]
> 
>> 
>> - Abstract: The abstract will not age well. Years from now, no one 
>> will think in terms of what RTCWeb vs some other working group 
>> defined. I suggest recasting this in terms of the documents and 
>> protocols, not the working groups.  (Comment repeats for 
>> introduction.)
>> 
> 
> [...]
> 
>> 
>> §9.3, first paragraph: " SDP attributes that are defined for use at 
>> the dcsa  usage level only SHALL use the dcsa usage level when 
>> registering the  attribute.”
>>