[AVT] Registration procedures for RTP header extensions

[Cullen Jennings <fluffy at cisco.com>]

In processing the draft-ietf-avt-rtp-hdrex, the topic came up of what  
sort of restriction do we want to have to the registrations process  
for  getting a new RTP header extension. There are an infinite number  
of possibilities but let me list a few common ones we could choose from:

1) First Come First Serve - this would ensure that there are no  
collisions and perhaps encourage traceability to a document that  
defines the extension but there is no requirement for traceability in  
this option. There are lots of ways to set up a FCFS system. XML  
Namespace are one, IANA allocated is another.

2) Stable Document Required - to get a code point you have to be  
willing to describe your extension in some specification published  
somewhere (does not have to be an RFC but has to be real)

3) Requires an IETF approved RFC - this would include Informational  
and Experimental RFC as well as standards track.

4) Requires an Standards Track RFC

RTP header extensions are currently defined by a 16-bit RTP-profile  
specific code, with an unspecified code point allocation procedure.  
It does not matter much for this conversation but I had (perhaps  
mistakenly) interpreted the lack of a defined policy to imply that an  
document updating the document that defined the registry was required  
to allocate a new code point.  The hdrext draft registers a single  
code point (0xbede) for a generic extension header, and uses signaled  
URNs to distinguish particular uses of that generic extension. This  
is essentially a First Come First Serve policy, based on URN names.  
What I need from the working group is some idea whether this is  
appropriate, or whether some more controlled policy is required.

Now a few things to consider about selecting this. The code point  
space we are selecting from is for all practical purposes infinite so  
there is no need to worry about it getting "used up". The reasons for  
using something more like option 4 than 1 is so that the WG gets a  
change to comment on and possible approve a extension that changes  
RTP before it get allocated a code point.  In the past, I have seen  
more than one proposed extenuation to RTP where most people involved  
with the AVT would want to say "uh, that looks like a really bad  
idea, let us help you".  Often the only reasons that vendors bother  
to even describe what they are doing is to get a code point  
allocated. There are also arguments to be made that forcing people to  
form a full standards track document to get a code point is killing  
innovation and experimentation in AVT. As an standards organization,  
part of our goal is to enable different vendors to build  
interoperable devices - at times we are pushed to define things so  
that vendors can say their product is standards compliant but others  
can not actually interoperate with the features it provides. All the  
approaches other than 1) result in some difficulty of what do  
implementors do before the code point is approved - however in  
practice, this usually (but not always) turns out not to be a big deal.

How this registry is defined is key to what level of review the WG  
gets about changes done to RTP though the header extensions  
mechanism. The options 1 to 4 above corresponds to 1) no notification  
of what is going on 2) you can at least see what is happen and send  
email which may or may not be ignored 3) low bar to easily get an  
experimental but really crazy stuff can be stopped 4) WG needs to  
agree. Clearly we can have finer nuances than this but I would like  
to get the feedback from folks on roughly what range of options they  
would find acceptable and other things that should be taken into  
consideration in selecting this.

Please send responses before the end of July 4th.

Thank you,

Cullen <with my AD hat on>

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt