Re: [AVT] Open issue on hdrext draft

[Magnus Westerlund <[e-mail]>]

Dave Singer skrev:
> At 13:43  +0200 4/10/07, Magnus Westerlund wrote:
>> [e-mail] skrev:
>>
>> What we are discussing is what rules applies for the IETF URN space,
>> i.e. the header extensions that will look like they are blessed by IETF.
>> The current draft version was in fact a) as this specified
>> "Specification Required" from RFC 2434:
>>
>> "      Specification Required - Values and their meaning must be
>>            documented in an RFC or other permanent and readily available
>>            reference, in sufficient detail so that interoperability
>>            between independent implementations is possible."
>>
>> I think A is fine but would probably prefer this to be b) with explicit
>> rule requiring a publicly available specification.
> 
> I'm sorry, I may have mis-written something, since I tried to agree with
> you here!  The current intention is that for the IETF URN space, a
> standards-track RFC is required.  And that for IANA registration, an
> IETF URN is required:
> 
> "To be registered
>    with IANA, the extension MUST use this IETF URN form; to use the IETF
>    URN form, the extension MUST be defined in an RFC."
> 
> If there is other text that isn't clear, can you tell me what it is?

In section 9.1 of draft-ietf-avt-rtp-hdrext-13:

   The rtp-hdrext namespace under urn:ietf:params: needs to be created
   for management, referenced to RFCxxxx.  Additions in this namespace
   shall be made on the basis of "Specification Required".

Which indicates that you can add new entires only requiring a
specification which is actually a contradiction to what is written in
Section 5:

   For extensions defined in RFCs, the URI used SHOULD be a URN starting
   "urn:ietf:params:rtp-hdrext:" and followed by a registered,
   descriptive name.  These URNs are managed by IANA.  To be registered
   with IANA, the extension MUST use this IETF URN form; to use the IETF
   URN form, the extension MUST be defined in an RFC.


So I think you need to use the Standards Action level in 9.1 to match
the section 5 text.

> 
>> Having an expert look
>> at any registrations to ensure that they are not totally wacko is in my
>> book a good thing.
> 
> Me too, no dispute here.
> 
>> But at the same time put minimal bar on the
>> registrations. Other SDOs should basically be able to send in an email
>> with a request containing a reference and things usually go through.
>>
> 
> So, you would permit non-IETF URIs in the IANA registry, also, after,
> what 'expert review' and with 'publicly available specification required'?
> 
> That's fine by me also.
> 

I think we can allow people to use the public IANA registry for header
extensions as long as there is a reasonable and publicly available.

Thus I would use Expert Review and some requirements on what the Expert
is allowed to approve. Where the primary is: Open publicly available
Specification. But there is likely that some more should be written.

Cheers


Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt