Re: [AVT] Registration procedures for RTP header extensions

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

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