Subject: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 8 Oct 2018 11:57:35 +0000

Hi,

I updated the document in -21 that will be available based on the AD review.

I have an open issue from the AD review is

"§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."

When trying to understand  I am now wondering what is the IANA action in section 9.3 https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-20#section-9.3.  is it really needed? I am not sure that the proposal to update the IANA sdp att-field is the right way and there is no usage level in the mentioned registries

Will it be better if in section 5.2.1 we will say that new attributes that are for dcsa usage should mention it in the document relevant document ( at least this is what section 5.2.1 say now)

Roni Even

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Oct 2018 13:43:56 -0400

On 10/8/18 7:57 AM, Roni Even (A) wrote:
> “§9.3, first paragraph: " SDP attributes that are defined for use at the 
> dcsa
> 
>     attribute.”
> I don’t understand this sentence. Consider a MUST NOT/SHALL NOT 
> construction.”

I agree this is a little odd. In particular it seems to assume that when 
new attributes are defined for use with dcsa that they will *only* be 
used with dcsa, while existing attributes may have their definitions 
extended for use with dcsa.

Also, I've lost track of the path to getting att field stuff in iana 
cleaned up. I'm sure there was intent to do so, but it currently still 
isn't. Specifically:

Right now there are separate registries for: session level only, media 
level only, both session and media level, source level, and unknown. 
Adding dcsa level to that structure would presumably be analogous but 
parallel to source level. The "both" structure is weird in this context. 
It seems that in this structure it would simply make sense to list an 
attribute in every category it applies to, which means in both session 
and media if both apply.

But this is all messy to manage and to look things up in. It would be 
better to simply have a single registry with an entry for each 
attribute, and a field in that to enumerate the contexts in which it is 
valid - session, media, source, and dcsa.

As I said, I have some memory that there was a plan to make this change. 
But I don't recall what that plan was attached to. Maybe it was with the 
changes for bundle and mux-attributes. (The mux-attributes draft seems 
to assume this change has been made, but I don't see actions to cause 
this change in either it or bundle.)

> When trying to understand  I am now wondering what is the IANA action in 
> section 9.3 
> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-20#section-9.3.  
> is it really needed? I am not sure that the proposal to update the IANA 
> sdp att-field is the right way and there is no usage level in the 
> mentioned registries
> 
> Will it be better if in section 5.2.1 we will say that new attributes 
> that are for dcsa usage should mention it in the document relevant 
> document ( at least this is what section 5.2.1 say now)

Given what is in the registry now, this would be very misleading.

I guess another way to go would be to remove all mention of level from 
the registry, just enumerate the attributes and the documents that 
define them, and count on the documents to fill in the detail. But then 
we would have to verify that every single one of them has enough 
definition in the corresponding document. And I think people expect more 
in the registry.

	Thanks,
	Paul

> Roni Even
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 18 Oct 2018 05:15:13 +0000

Hi,
I took the editorship of the document late in the process and I am trying to understand what was the purpose of section 9.3.  It does not ask to create a new registry which I agree will be odd since it will require to look at existing attribute and add them to this registry. On the other hand there is no field in any of the att-field registries to add dcsa usage level.
Any feedback?

Roni Even

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, October 08, 2018 8:44 PM
To: [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

> I don't understand this sentence. Consider a MUST NOT/SHALL NOT 

I agree this is a little odd. In particular it seems to assume that when new attributes are defined for use with dcsa that they will *only* be used with dcsa, while existing attributes may have their definitions extended for use with dcsa.

Also, I've lost track of the path to getting att field stuff in iana cleaned up. I'm sure there was intent to do so, but it currently still isn't. Specifically:

Right now there are separate registries for: session level only, media level only, both session and media level, source level, and unknown. 
Adding dcsa level to that structure would presumably be analogous but parallel to source level. The "both" structure is weird in this context. 
It seems that in this structure it would simply make sense to list an attribute in every category it applies to, which means in both session and media if both apply.

But this is all messy to manage and to look things up in. It would be better to simply have a single registry with an entry for each attribute, and a field in that to enumerate the contexts in which it is valid - session, media, source, and dcsa.

As I said, I have some memory that there was a plan to make this change. 
But I don't recall what that plan was attached to. Maybe it was with the changes for bundle and mux-attributes. (The mux-attributes draft seems to assume this change has been made, but I don't see actions to cause this change in either it or bundle.)

> When trying to understand  I am now wondering what is the IANA action 
> in section 9.3 
> is it really needed? I am not sure that the proposal to update the 
> IANA sdp att-field is the right way and there is no usage level in the 
> mentioned registries
> 

I guess another way to go would be to remove all mention of level from the registry, just enumerate the attributes and the documents that define them, and count on the documents to fill in the detail. But then we would have to verify that every single one of them has enough definition in the corresponding document. And I think people expect more in the registry.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2018 10:14:00 -0400

> I took the editorship of the document late in the process and I am trying to understand what was the purpose of section 9.3.  It does not ask to create a new registry which I agree will be odd sinc…

As I previously stated, the att-field registries are in great need of 
being reorganized. As written, I think this text assumed that such 
reorganization has already been done. But it hasn't. Maybe we need to 
rewrite this this to spell out the complete reorganization.

	Thanks,
	Paul

---

From: Keith Drage <[email-masked]>
Date: Thu, 18 Oct 2018 22:24:19 +0100

I vaguely remember that there was thinking that the set of attributes 
that can be used with dcsa is not the same as the set of attributes that 
are defined for the a= level. In general, that applied that all 
generally defined attributes cannot be be used with dcsa, but I think 
there was also a thought that it could be the other way round.

I think there was a thought that attributes used in dcsa should have 
that usage explicitly described, but not sure how that got carried through.

Keith

On 08-Oct-18 6:43 PM, Paul Kyzivat wrote:
>> “§9.3, first paragraph: " SDP attributes that are defined for use at 
>> the dcsa
>>
> I agree this is a little odd. In particular it seems to assume that 
> when new attributes are defined for use with dcsa that they will 
> *only* be used with dcsa, while existing attributes may have their 
> definitions extended for use with dcsa.
>
> parallel to source level. The "both" structure is weird in this 
> context. It seems that in this structure it would simply make sense to 
> list an attribute in every category it applies to, which means in both 
> session and media if both apply.
>
> attribute, and a field in that to enumerate the contexts in which it 
> is valid - session, media, source, and dcsa.
>
> As I said, I have some memory that there was a plan to make this 
> change. But I don't recall what that plan was attached to. Maybe it 
> was with the changes for bundle and mux-attributes. (The 
> mux-attributes draft seems to assume this change has been made, but I 
> don't see actions to cause this change in either it or bundle.)
>
>> IANA sdp att-field is the right way and there is no usage level in 
>> the mentioned registries
>>
> define them, and count on the documents to fill in the detail. But 
> then we would have to verify that every single one of them has enough 
> definition in the corresponding document. And I think people expect 
> more in the registry.
>
>     Thanks,
>     Paul
>
>> Roni Even
>>
>>
>>

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 21 Oct 2018 06:52:04 +0000

Hi Paul,
Thanks for the feedback but I think that your point deserve a new thread in MMUSIC since it is a reorganization issue of the registry, I do not think that it should be part of this document
Regards
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, October 18, 2018 5:14 PM
To: Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

> I took the editorship of the document late in the process and I am trying to understand what was the purpose of section 9.3.  It does not ask to create a new registry which I agree will be odd sinc…

As I previously stated, the att-field registries are in great need of being reorganized. As written, I think this text assumed that such reorganization has already been done. But it hasn't. Maybe we need to rewrite this this to spell out the complete reorganization.

	Thanks,
	Paul

> But I don't recall what that plan was attached to. Maybe it was with 
> the changes for bundle and mux-attributes. (The mux-attributes draft 
> seems to assume this change has been made, but I don't see actions to 
> cause this change in either it or bundle.)
>

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 21 Oct 2018 06:55:44 +0000

Hi Keith,
Thanks, so I understand from the document that dcsa has different set of attributes which will require to create a registry in section 9.3? 

Roni

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Keith Drage
Sent: Friday, October 19, 2018 12:24 AM
To: [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

I vaguely remember that there was thinking that the set of attributes that can be used with dcsa is not the same as the set of attributes that are defined for the a= level. In general, that applied that all generally defined attributes cannot be be used with dcsa, but I think there was also a thought that it could be the other way round.

I think there was a thought that attributes used in dcsa should have that usage explicitly described, but not sure how that got carried through.

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Oct 2018 13:28:38 -0400

> Thanks for the feedback but I think that your point deserve a new thread in MMUSIC since it is a reorganization issue of the registry, I do not think that it should be part of this document

Well, there currently is no way to record dcsa attributes in iana, so we 
need *something*. If the reorganization was done, then it would only be 
to start using a new value in the (reorganized) registry. Without that 
we need to invent some other way, such as a separate registry of dcsa 
attributes.

Can the ADs give us some input on how we should proceed?

	Thanks,
	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 22 Oct 2018 08:30:19 +0000

Hi Paul,
I was thinking that currently we can ask for a new registry for dcsa parameters similar to the ones on SSRC or RID attributes
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, October 21, 2018 8:29 PM
To: Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

On 10/21/18 2:52 AM, Roni Even (A) wrote:
> Hi Paul,
> Thanks for the feedback but I think that your point deserve a new 
> thread in MMUSIC since it is a reorganization issue of the registry, I 
> do not think that it should be part of this document

Well, there currently is no way to record dcsa attributes in iana, so we need *something*. If the reorganization was done, then it would only be to start using a new value in the (reorganized) registry. Without that we need to invent some other way, such as a separate registry of dcsa attributes.

	Thanks,
	Paul

>>> When trying to understand  I am now wondering what is the IANA 
>>> action in section 9.3 
>>> Will it be better if in section 5.2.1 we will say that new 
>>> attributes that are for dcsa usage should mention it in the document 
>>> relevant document ( at least this is what section 5.2.1 say now)
>>

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 22 Oct 2018 10:19:59 +0000

Hi,
I suggested another option which is not register DCSA attributes and specify that for new DCSA attribute a draft will be needed that will update this document.

Roni

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Roni Even (A)
Sent: Monday, October 22, 2018 11:30 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

Hi Paul,
I was thinking that currently we can ask for a new registry for dcsa parameters similar to the ones on SSRC or RID attributes Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Sunday, October 21, 2018 8:29 PM
To: Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2018 10:43:47 -0400

> I suggested another option which is not register DCSA attributes and specify that for new DCSA attribute a draft will be needed that will update this document.

IMO that is contrary to the philosophy that has been applied to all 
other uses of attributes. I would at least like to be consistent. 
Otherwise we are going to confuse people.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2018 10:53:32 -0400

> I was thinking that currently we can ask for a new registry for dcsa parameters similar to the ones on SSRC or RID attributes

I don't see the relevance of RID here. Its parameters are independent 
from 'attributes'.

But dcsa attributes are indeed analogous to ssrc attributes, and so 
should be registered in an analogous way.

I can live with that. Still the registry is a mess, and should be 
reorganized, but I agree that can be considered a separate task. Perhaps 
it can be done via a back-room agreement with IANA.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Oct 2018 11:44:03 -0500

> On Oct 21, 2018, at 12:28 PM, Paul Kyzivat <[email-masked]> wrote:
> 

Be careful what you wish for :-)

I see two questions here, and I am not sure which ones you seek input for:

1) Do we tie a registry reorganization to this document

2) How should do we that attributes are intended for the dcsa label.

On point 1, I generally lean towards agreeing with Roni that any such reorg should be a separate effort. It’s not fair to this document to hold it hostage to a reorg, and it would not be reader friendly to have this RFC contain a lot of IANA text that is at best loosely related to the rest of the content.

OTOH, it’s pretty clear the current organization didn’t contemplate adding new levels. Do people have an idea what a reorg would look like?

On point 2, it’s not clear to me what the text intends as written. I _think_ its saying the following:

- if a new attribute is defined that is only intended for use with subprotocol negotiation, it MUST be defined at the dcsa level.
- if an existing attribute is dual use, i.e. can be used for subprotocol negotiation among other things, then it MUST have a dcsa level usage defined (and I assume registered as dual/multi use? ).

- It doesn’t talk about _new_ attributes that can be used at multiple levels. Would that be any different than for existing attributes?

How common do we expect attributes useable at the dcsa and also other levels to be? Could we just rule that out? (i.e. say that if you think you need to define a dcsa usage for an existing attribute, just define a new attribute?)

Ben.

> 	Pau

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2018 14:12:14 -0400

> Be careful what you wish for :-)

I know this will take some work. But it needs doing.

> On point 1, I generally lean towards agreeing with Roni that any such reorg should be a separate effort. It’s not fair to this document to hold it hostage to a reorg, and it would not be reader fri…

I agree this is a reasonable approach.

> OTOH, it’s pretty clear the current organization didn’t contemplate adding new levels. Do people have an idea what a reorg would look like?

What I think will work well is simply a single registry for all 
attributes, with fields indicating all those levels for which the 
attribute is valid.

> - It doesn’t talk about _new_ attributes that can be used at multiple levels. Would that be any different than for existing attributes?

IMO the document defining an attribute needs to specify all the levels 
at which it applies, and details of how it applies to those. For 
purposes of grandfathering, levels that are not mentioned in the 
document are not defined.

We might want to tweak that a bit, so that there might be multiple 
documents, defining the usage at different levels. (This might be 
helpful for retrospectively defining existing attributes for additional 
levels.

> How common do we expect attributes useable at the dcsa and also other levels to be? Could we just rule that out? (i.e. say that if you think you need to define a dcsa usage for an existing attribut…

I think they may be *very* common. An obvious thing to do is to define 
existing protocols (that have attributes) to also work over data channels.

	Thanks,
	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 23 Oct 2018 05:20:50 +0000

Hi,
On point 2 my proposal is to take the same approach as was done for the ssrc attribute
See https://tools.ietf.org/html/rfc5576#section-12.2

Roni Even

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, October 22, 2018 7:44 PM
To: Paul Kyzivat
Cc: Roni Even (A); [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

>> thread in MMUSIC since it is a reorganization issue of the registry, 
>> I do not think that it should be part of this document
> 

Ben.

>>> seems to assume this change has been made, but I don't see actions 
>>> to cause this change in either it or bundle.)
>>> 
>>>> attributes that are for dcsa usage should mention it in the 
>>>> document relevant document ( at least this is what section 5.2.1 
>>>> say now)
>>>