Subject: [AVT] Registration procedures for RTP header extensions

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Jun 2007 16:03:51 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2007 11:09:22 +0200

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.

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.

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. 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:
> 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:
> 
> 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.
> 
> specific code, with an unspecified code point allocation procedure. It 
> does not matter much for this conversation but I had (perhaps 
> 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.
> 

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jun 2007 14:12:42 -0700

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

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

> 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
>> 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:
>> 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.
>> 3) Requires an IETF approved RFC - this would include  
>> Informational and Experimental RFC as well as standards track.
>> 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.
>> 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.
>> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jun 2007 10:12:16 +0200

Cullen Jennings skrev:
>> 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.
> 

Thanks for the clarification.

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

My personal opinion is that for the URN space there should be at least 
expert review and specification required. We might consider that the bar 
for what is considered a specification is. I think it must be above a 
white paper but any industry forum or standards body that produce a 
permanent documents should be okay.  That way the ones existing in the 
formal registry are available to read. They will also receive some 
sanity check through the expert review. Going further to require an RFC 
only reduced the utility of the registry as a common gathering point for 
standardized solutions.

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

Well, that is the issue. I don't have any bodies/specifications that I 
can point at. But I have herd rumors about people using them, by simply 
picking a random number.

Cheers

Magnus Westerlund

---

From: Michael A Dolan <[email-masked]>
Date: Tue, 26 Jun 2007 10:55:55 -0700

>Well, that is the issue. I don't have any bodies/specifications that 
>I can point at. But I have herd rumors about people using them, by 
>simply picking a random number.

And, more interesting - non-static definitions, since there is also 
no requirement today that it be entirely a constant.

Regards,

         Mike

At 01:12 AM 6/21/2007, Magnus Westerlund wrote:
>>>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.
>>>
>>>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.
>>>
>>>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.
>>should have from 1 to 4 - once we have a better idea of that, we 
>>can propose an appropriate mechanism. Thoughts on this?
>
>My personal opinion is that for the URN space there should be at 
>least expert review and specification required. We might consider 
>that the bar for what is considered a specification is. I think it 
>must be above a white paper but any industry forum or standards body 
>that produce a permanent documents should be okay.  That way the 
>ones existing in the formal registry are available to read. They 
>will also receive some sanity check through the expert review. Going 
>further to require an RFC only reduced the utility of the registry 
>as a common gathering point for standardized solutions.
>
>>
>>>
>>>guidelines require a specification as one of the criteria for acceptance.
>>>
>Well, that is the issue. I don't have any bodies/specifications that 
>I can point at. But I have herd rumors about people using them, by 
>simply picking a random number.
>
>Cheers
>
>Magnus Westerlund
>