Re: [AVT] Registration procedures for RTP header extensions

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

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

Thanks for the clarification.

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

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

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

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