Re: [MMUSIC] IANA registration of SDP attributes

[Christian Groves <[e-mail]>]

Hello Paul,

Please see below.

Regards, Christian

On 24/03/2016 8:59 AM, Paul Kyzivat wrote:
> On 3/22/16 3:11 PM, Flemming Andreasen wrote:
>
>> Do we have a volunteer to drive the discussion there ?
>
> OK. I'll volunteer.
>
> The starting point for this discussion is the current text of section 
> 8.2.4 of rfc4566bis-16.
>
> Looking at that, one thing leaps out at me:
>
> There is a long list of "stuff" that must be provided when defining a 
> new attribute. IMO it is all *good* stuff, that should be provided. 
> But it also strikes me that it will be difficult for IANA to evaluate 
> the adequacy of this stuff itself. So we might want to require an 
> expert review as a gate to registration.
[CNG] What's the role of the SDP directorate in relation to this? I 
guess they would check any RFC defined attributes but that non-RFCs 
would also need to be checked? How much of this should be visible on the 
IANA registry page?

[CNG] Also in 8.2.4 there's bullet points for "Attribute Name" and "An 
ABNF definition..." both these mention ABNF definitions. What's the 
distinction?

>
> The other thing, that this thread has been discussing, is that this 
> only covers definitions of new attributes.
>
> What it doesn't cover are *new* usages of existing attributes. What 
> isn't covered are cases that *revise* the definition of an existing 
> attribute. For instance, the IANA registry entries for the 'setup' and 
> 'connection' attributes only reference RFC4145. (For use with TCP.) 
> But these attributes are also used in contexts (with proto values) not 
> covered by that RFC. For instance, RFC4572 defines a new proto 
> TCP/TLS, and reuses 'setup' and 'connection'. The semantics are mostly 
> the same, but additional behavior triggered by these is added on. 
> Perhaps the registry entries for these attributes should also 
> reference this RFC. In principle, in cases where it matters this 
> behavior can be discovered by looking up the references for the 
> TCP/TLS proto. But if you are particularly interested in what the 
> setup attribute is doing then it might not occur to you to look there.
>
> In that case, the relationship to the original definition is pretty 
> clear, since it is still TLS over TCP. It is less clear when used with 
> a protocol entirely distinct from TCP. For instance we have active 
> drafts draft-ietf-mmusic-sctp-sdp and draft-ietf-mmusic-dtls-sdp. 
> These both reuse 'setup', and sctp-sdp reuses 'connection', while 
> dtls-sdp has chosen an alternative to 'connection'. They also layer on 
> additional behavior. And dtls-sdp also forbids use of some of the 
> values defined in 4145 for setup.
>
> IMO it would be good if the registry for 'setup' referenced all of 
> these, and that for 'connection' referenced these with the exception 
> of dtls-sdp that doesn't use it. This is because these are extending 
> the semantics of the attributes.
[CNG] This is the big issue. It will mean an effort to bring the 
registry up to the current state and more effort to ensure that it 
remains current. It probably comes down to whether people see the 
registry as a simple tool to register unique names or something more.
>
> But it seems less critical as long as these other documents are 
> otherwise discoverable from actual uses. (Such as checking the 
> references for the proto value in the m-line associated with these uses.)
[CNG] Yes
>
> But IMO it would be essential if the syntax of the attribute is revised.
>
> As you can see, I am a bit ambivalent on this. That is why I think it 
> needs discussion.
[CNG] Agree
>
>
>     Thanks,
>     Paul
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>