Subject: Re: [MMUSIC] IANA registration of SDP attributes

From: Flemming Andreasen <[email-masked]>
Date: Mon, 4 Apr 2016 21:37:58 -0400

On 3/11/16 11:46 AM, Paul Kyzivat wrote:
> On 3/11/16 11:15 AM, Juergen Stoetzer-Bradler wrote:
>> Paul,
>>
>> The last alternative would have the advantage that different subprotocol
>> documents could be referenced for the same attribute. Like e.g. for the
>> setup attribute (if there were BFCP over data channel transport specific
>> aspects):
>>
>> *SDP Name*     *Level(s)*     *Reference(s)*
>> accept-types
>>     media,
>> dcsa(MSRP)
>>     [RFC4975]
>> [draft-ietf-mmusic-msrp-usage-data-channel]
>> cat
>>     session
>>     [RFC4566]
>> fmtp
>>     media,source     [RFC4566][RFC5576]
>> mediaclk
>>     session,media,source
>>     [RFC7273]
>> ptime
>>     media
>>     [RFC4566]
>> recvonly
>>     session,media,
>> dcsa(MSRP)
>>     [RFC4566][RFC4975]
>> [draft-ietf-mmusic-msrp-usage-data-channel]
>> setup
>>     session, media
>> dcsa(MSRP)
>> dcsa(BFCP)
>>     [RFC4145]
>> [draft-ietf-mmusic-msrp-usage-data-channel]
>> [draft-schwarz-mmusic-bfcp-usage-data-channel]
>>
>>
>> Therefore I'd be in favor of your last alternative.
>
> Let's see what other comments we get, especially from Flemming.
>

Thanks for putting this together Paul. My preference is also the last 
alternative.

Thanks

-- Flemming

> Then, if this is preferred direction we can work on refining it.
>
>     Thanks,
>     Paul
>
>> Thanks,
>> Juergen
>>
>>
>> On 10.03.2016 19:48, EXT Paul Kyzivat wrote:
>>> [splitting off from the thread on data-channel-sdpneg]
>>>
>>> Currently IANA has five(!) separate registries for sdp attributes:
>>>
>>> att-field (session level)
>>> att-field (both session and media level)
>>> att-field (media level only)
>>> att-field (source level)
>>> att-field (unknown level)
>>>
>>> They all have the same format:
>>>
>>> *Type**
>>> *     *SDP Name**
>>> *     *Reference**
>>> *
>>> att-field (session level)     cat     [RFC4566]
>>> att-field (both session and media level)     recvonly
>>>     [RFC4566]
>>> att-field (both session and media level)     mediaclk
>>>     [RFC7273]
>>> att-field (media level only)     accept-types
>>>     [RFC4975]
>>> att-field (media level only)     fmtp
>>>     [RFC4566]
>>> att-field (source level)     fmtp
>>>     [RFC5576]
>>>
>>>
>>> This format is a pain, because it is hard to look an attribute up if
>>> you don't know at what level(s) it is valid. It also has the potential
>>> to allow an attribute name to be registered for unrelated purposes if
>>> the type is different. (IMO that would be bad.)
>>>
>>> A long time ago (several years now), as part of the 4566bis work, I
>>> proposed that these tables be merged into one. It was my impression
>>> that this was agreed and would be done. But I don't recall any
>>> agreement on the logistics of doing so.
>>>
>>> My thought was that the combined table would look like:
>>>
>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>> accept-types
>>>     media
>>>     [RFC4975]
>>> cat
>>>     session
>>>     [RFC4566]
>>> fmtp
>>>     media,source     [RFC4566][RFC5576]
>>> mediaclk
>>>     session,media,source
>>>     [RFC7273]
>>> ptime
>>>     media
>>>     [RFC4566]
>>> recvonly
>>>     session,media
>>>     [RFC4566]
>>>
>>>
>>>
>>> Then we get to data channel attributes. My thought is to incorporate
>>> them into this table structure, as yet another "level". E.g.,
>>>
>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>> accept-types
>>>     media,dcsa
>>>     [RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]
>>> cat
>>>     session
>>>     [RFC4566]
>>> fmtp
>>>     media,source     [RFC4566][RFC5576]
>>> mediaclk
>>>     session,media,source
>>>     [RFC7273]
>>> ptime
>>>     media
>>>     [RFC4566]
>>> recvonly
>>>     session,media,dcsa
>>>     [RFC4566][RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]
>>>
>>>
>>> (And this could also be extended for websockets if somebody proposes a
>>> way to negotiate attributes for data channels too.)
>>>
>>> Using this format, if you want to know more than the name and the
>>> level(s) at which it can be used you need to consult the references.
>>> And when there are multiple references you don't know which one(s) you
>>> need to consult. This can be "fixed" by including more information
>>> from the reference into the registry. Conversely, we could strip it
>>> down further and remove the levels from the registry - so you need to
>>> consult the references for that too.
>>>
>>> For instance, if we wanted to simplify finding the right reference for
>>> the level you are interested in, we could do:
>>>
>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>> accept-types
>>>     media,
>>> dcsa
>>>     [RFC4975]
>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>> cat
>>>     session
>>>     [RFC4566]
>>> fmtp
>>>     media,source     [RFC4566][RFC5576]
>>> mediaclk
>>>     session,media,source
>>>     [RFC7273]
>>> ptime
>>>     media
>>>     [RFC4566]
>>> recvonly
>>>     session,media,
>>> dcsa
>>>     [RFC4566][RFC4975]
>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>
>>>
>>> Or we could go further, and break the dcsa level down by subprotocol:
>>>
>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>> accept-types
>>>     media,
>>> dcsa(MSRP)
>>>     [RFC4975]
>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>> cat
>>>     session
>>>     [RFC4566]
>>> fmtp
>>>     media,source     [RFC4566][RFC5576]
>>> mediaclk
>>>     session,media,source
>>>     [RFC7273]
>>> ptime
>>>     media
>>>     [RFC4566]
>>> recvonly
>>>     session,media,
>>> dcsa(MSRP)
>>>     [RFC4566][RFC4975]
>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>
>>>
>>> Thoughts?
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 4 Apr 2016 22:23:13 -0400

On 3/29/16 1:28 AM, Christian Groves wrote:
> 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:
>
<snip>
>>
>> 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.
There is a difference between revising and extending usage. For 
extensions, we normally put a sub-registry and a set of associated 
extension procedures in place. Now, in the case of RFC4145, I don't 
believe it was envisioned to go beyond TCP originally, and hence 
extension procedures weren't actually defined at the time. Other 
protocol uses where later found to be able to use it as well, but again 
without any formal registry structure to make that clear. Do we have 
more examples like this or was this a special case (with relatively old 
origins) ?

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

If you change either the syntax or semantic of the attribute, then by 
definition you have changed it and the reference would need to be updated.

If the attribute includes an extension mechanism, then as part of its 
definition, it needs to include instructions for how to do so, including 
IANA registration procedures (typically a sub-registry). Normally, this 
is easy to identify because extensions tend to involve new values and/or 
parameters of some sort (something syntactical). When the extension is 
merely semantic (e.g. applying it in a context it was not envisioned 
originally, like TLS rather than TCP), then it's less clear, because the 
attribute in question may not have considered that when it was defined 
originally and hence a formal extension mechanism and registration 
procedures do not exist. In such a case, I do think it's desirable to 
have the registry updated to include this new semantic - it makes it 
easiser to find what they are looking for (or should be looking for).

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 4 Apr 2016 22:28:32 -0400

On 3/29/16 1:48 PM, Paul Kyzivat 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?
>
> The SDP directorate will only be invoked for ietf documents. The 
> policy for attributes is Specification Required, so it might be a 
> document from another SDO, ore even no SDO. In those cases there would 
> be no SDP directorate review.
>
> After refreshing my memory about the definition of Specification 
> Required, I see that it implies Expert Review. (Flemming is currently 
> listed as the expert.) 
Right - I'm currently the designated expert and hence review all 
external registration requests (i.e. from outside IETF).

> That may be good enough, though we might want to beef up the 
> requirements in section 8.2.4 of 4566bis.
>
> The hard part is seeing to any new actions when *existing* attributes 
> are used in new ways. For that I think the SDP Directorate is all we 
> have to check for that sort of thing. I wonder if there ought to be a 
> checklist of things for SDP Directorate reviews.
>
There probably should, but it shouldn't be any different than for any 
other SDP extension (syntactic and/or semantic) and hence we should have 
that in 4566bis.

> And of course *that* also will only work for IETF documents. If 
> somebody outside the IETF defines a new use for an existing attribute 
> then we have no mechanism to notice that and trigger an update to the 
> registry.
>
True

-- Flemming