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

[Paul Kyzivat <[e-mail]>]

On 10/22/18 6:19 AM, Roni Even (A) wrote:
> 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.

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

> Roni
> 
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Roni Even (A)
> Sent: Monday, October 22, 2018 11:30 AM
> To: Paul Kyzivat; [e-mail]
> 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:[e-mail]]
> Sent: Sunday, October 21, 2018 8:29 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/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?
> 
> 	Thanks,
> 	Paul
> 
>> 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
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>