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

["Roni Even (A)" <[e-mail]>]

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


-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Wednesday, January 09, 2019 9:11 PM
To: Bo Burman
Cc: Roni Even (A); Paul Kyzivat; [e-mail]
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20



> On Jan 9, 2019, at 7:16 AM, Bo Burman <[e-mail]> wrote:
> 
> 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.

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

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

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

> 
> /Bo
> (as individual)
> 
> -----Original Message-----
> From: Roni Even (A) <[e-mail]>
> Sent: den 24 december 2018 10:29
> To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: Paul Kyzivat <[e-mail]>; [e-mail]
> 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:[e-mail]]
> Sent: Friday, December 14, 2018 4:32 PM
> To: Ben Campbell; Roni Even (A)
> Cc: Paul Kyzivat; [e-mail]
> 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 <[e-mail]>
> Sent: den 11 december 2018 18:25
> To: Roni Even (A) <[e-mail]>
> Cc: Bo Burman <[e-mail]>; Paul Kyzivat 
> <[e-mail]>; [e-mail]
> 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) <[e-mail]> 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:[e-mail]] On Behalf Of Bo Burman
>> Sent: Friday, December 07, 2018 10:55 AM
>> To: Ben Campbell; Paul Kyzivat
>> Cc: [e-mail]
>> 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 <[e-mail]> On Behalf Of Ben Campbell
>> Sent: den 27 november 2018 23:53
>> To: Paul Kyzivat <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [MMUSIC] AD Evaluation of
>> draft-ietf-mmusic-data-channel-sdpneg-20
>> 
>> 
>> 
>>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>