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

From: Keith Drage <[email-masked]>
Date: Fri, 2 Nov 2018 12:48:10 +0000

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.

---

From: "Roni Even (A)" <[email-masked]>
Date: Fri, 2 Nov 2018 12:59:26 +0000

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:[email-masked]] On Behalf Of Keith Drage
Sent: Friday, November 02, 2018 7:48 PM
To: [email-masked]
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

> existing protocols (that have attributes) to also work over data 

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

---

From: Keith Drage <[email-masked]>
Date: Fri, 2 Nov 2018 14:05:26 +0000

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Fri, 2 Nov 2018 15:02:37 +0000

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:[email-masked]] On Behalf Of Keith Drage
Sent: Friday, November 02, 2018 9:05 PM
To: [email-masked]
Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

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