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

> On Jan 9, 2019, at 7:16 AM, Bo Burman <bo.burman@ericsson.com> 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) <roni.even@huawei.com>
> Sent: den 24 december 2018 10:29
> To: Bo Burman <bo.burman@ericsson.com>; Ben Campbell <ben@nostrum.com>
> Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
> 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:bo.burman@ericsson.com]
> Sent: Friday, December 14, 2018 4:32 PM
> To: Ben Campbell; Roni Even (A)
> Cc: Paul Kyzivat; mmusic@ietf.org
> 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 <ben@nostrum.com>
> Sent: den 11 december 2018 18:25
> To: Roni Even (A) <roni.even@huawei.com>
> Cc: Bo Burman <bo.burman@ericsson.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
> 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) <roni.even@huawei.com> 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:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
>> Sent: Friday, December 07, 2018 10:55 AM
>> To: Ben Campbell; Paul Kyzivat
>> Cc: mmusic@ietf.org
>> 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 <mmusic-bounces@ietf.org> On Behalf Of Ben Campbell
>> Sent: den 27 november 2018 23:53
>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] AD Evaluation of
>> draft-ietf-mmusic-data-channel-sdpneg-20
>> 
>> 
>> 
>>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 

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

Attachment: signature.asc