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

Hi Keith,
Thanks,
I agree that one registry would have been better. This is the thread I had with Paul. A similar example is SSRC in https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml  there re currently separate registries for session level, media level' both and the similar case is the source level.  There is no usage  as specified in  https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-21#section-9.3 . currently the only way is  to have a new registry similar to source level. 
It will be good to have just one att filed registry with usage level but this is not for the data channel sdpneg draft.  We will make this point in the MMUSIC session.

Roni

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Keith Drage
Sent: Friday, November 02, 2018 9:05 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

I'm not actually sure it does make sense.

Remember that the prime purpose of an IANA registry is to avoid double assignment of values. It also acts as a quick lookup for where those values are assigned.

Now, given that the values used for dcsa attributes are meant to be in the same space as ordinary attributes, ultimately that only needs a single registry.

Further an IANA registry does not make normative statements - we do not put statements in RFCs that say: "Items in this registry have this behaviour, and items outside it have a different behaviour, rather than behaviour and the conditions are defined by words in RFCs, that might also define a registry.

So while the registry might require a better structure to carry information, I am not sure that is the solution to the issue.

Keith

On 02-Nov-18 12:59 PM, Roni Even (A) wrote:
> Hi  Keith
> It looks like with the current structure of the IANA registry we will need a new registry with specification required policy.
> Does this make sense
> Roni
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Keith Drage
> Sent: Friday, November 02, 2018 7:48 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] open issue in AD review of 
> draft-ietf-mmusic-data-channel-sdpneg-20
>
> The original intent was to work with existing attributes, and I think much of that still applies.
>
> It is more a problem that there is a frequent class of exceptions, in some cases where the non-applicability would be obvious, and other cases where some more explanation of the impact is required. An IANA registry alone is not going to solve that latter problem - RFCs need to provide text.
>
>
>
> Keith
>
>>> 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.
> _______________________________________________
> 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
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic