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

From: Bo Burman <[email-masked]>
Date: Fri, 7 Dec 2018 08:54:51 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Dec 2018 10:31:15 -0500

> 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 int…
...
>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <[email-masked]> wrote...

I didn't particularly agree with this choice. The websocket 
registrations and definitions seem pretty "loosy goosy" to me.

Changing this means establishing a separate registry, and then double 
registering any protocols that want to be used in both.

	Thanks,
	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 11 Dec 2018 10:15:48 +0000

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

/Bo (as individual)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Dec 2018 11:25:16 -0600

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,

---

From: Bo Burman <[email-masked]>
Date: Fri, 14 Dec 2018 14:32:22 +0000

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

Thanks!

Ben.

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 24 Dec 2018 09:29:27 +0000

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,

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

Thanks!

Ben.