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

[Paul Kyzivat <[e-mail]>]

On 10/22/18 12:44 PM, Ben Campbell wrote:
> 
> 
>> On Oct 21, 2018, at 12:28 PM, Paul Kyzivat <[e-mail]> wrote:
>>
>> 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.
>>
>> Can the ADs give us some input on how we should proceed?
> 
> Be careful what you wish for :-)

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

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

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.

> 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?

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 attribute, just define a new attribute?)

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

> Ben.
> 
> 
> 
>>
>> 	Thanks,
>> 	Pau
>>
>>> Regards
>>> Roni
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: Thursday, October 18, 2018 5:14 PM
>>> To: Roni Even (A); [e-mail]
>>> Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20
>>> On 10/18/18 1:15 AM, Roni Even (A) wrote:
>>>> 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?
>>> 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
>>>> Roni Even
>>>>
>>>> -----Original Message-----
>>>> From: mmusic [mailto:[e-mail]] On Behalf Of Paul
>>>> Kyzivat
>>>> Sent: Monday, October 08, 2018 8:44 PM
>>>> To: [e-mail]
>>>> Subject: Re: [MMUSIC] open issue in AD review of
>>>> draft-ietf-mmusic-data-channel-sdpneg-20
>>>>
>>>> On 10/8/18 7:57 AM, Roni Even (A) wrote:
>>>>> 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."
>>>>
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>