Re: [AVT] Registration procedures for RTP header extensions

[Cullen Jennings <fluffy at cisco.com>]

On Jun 20, 2007, at 2:09 AM, Magnus Westerlund wrote:

> Hi Cullen,
>
> Sorry, but I get confused by this message. Which issue are you  
> discussing?
>
> A. The policy for AVP (and by inheritance the other profiles) for  
> the first 16-bits in the header extension. Which currently RFC 3551  
> says should be managed but doesn't define a policy or a registry for.
>
> B. Header extensions signaled using the mechanism defined in draft- 
> ietf-avt-rtp-hdrext. Which currently is the equivalent of FCFS and  
> with the addition of a registry for keeping track of RFC defined ones.
>
> I think you are talking about B and like to have confirmation of  
> the WG be okay with this.
Yes - I am talking about B but A is effectively being replaced by B  
for all practical purposes so they are closely related.

> In the case of B my personal opinion is the following:
>
> 1. Per design using URIs as signalling names, this is impossible to  
> control. The only way of fix this would be to change the identifier  
> used for a mechanism into something a registration can keep track  
> and assign. However that also increases the chance of borrowing a  
> name without registering creating issues.

I was not really asking about if we should use URI or not, I was  
looking for opinion on what level of control the WG thought they  
should have from 1 to 4 - once we have a better idea of that, we can  
propose an appropriate mechanism. Thoughts on this?


> 2. I think the IANA section as currently written needs to be  
> improved it is not easy to understand for someone desiring to  
> register a name in the URN space that it is under specification  
> required. I think a better separation of what is the rule for  
> registration within the space and the details needed to have the  
> URN space itself created is needed.
>
> I think there might be some benefit in changing the rules for the  
> URN space to Expert Review and then have the Expert reviewer  
> guidelines require a specification as one of the criteria for  
> acceptance.
>
> However, the reality is that header extensions (16-bit field) have  
> been totally unmanaged and been in FCFS since day one.

interesting - which extension numbers are defined?

> Only the limitation on single ones have prevented an explosion in  
> the usage. So it is probably a great improvement to have an Expert  
> Reviewed or specification required  policy on the URN space for  
> header extensions.
>
> Cheers
>
> Magnus
> (With his AD hat very much off)
>
>
> Cullen Jennings skrev:
> > 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
>
>
> --
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
> ----------------------------------------------------------------------

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