#247 and Registry policies

Proposal:

Make all of our registries IETF Review (except for headers, which are governed by RFC3864).

Add a 'status' field to each registry, with the following possible values:

Standard / Reserved / Obsolete

... with the notion that if there are commonly-used values that haven't gone through IETF Review, they can be written up in a quick I-D and registered as Reserved.

Because the rate of change for all of these is pretty slow, excepting headers (which as per above aren't included), and the set of folks extending these is pretty limited, I think it's OK. The only thing that makes me a bit nervous is cache directives, but they still don't move that fast (and it seems like the most direct impact would be on myself ;).

Thoughts? I'm open to alternative approaches, just want to keep things rolling. If we keep things as they are, we need to identify a bunch of expert reviewers and document procedures for them.

Cheers,

P.S. this is related to <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/247>.



On 01/03/2012, at 5:05 PM, Mark Nottingham wrote:

> I've been reviewing the various registries we have in bis, and their associated policies (for reference: <http://tools.ietf.org/html/rfc5226#section-4.1>). 
> 
> Right now, we have:
> 
> p1
> * Transfer-codings - Specification Required
>   http://www.iana.org/assignments/http-parameters/http-parameters.xml
> 
> * Upgrade tokens - First Come First Served   
>   http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xml
> 
> p2
> * Methods - IETF Review
> 
> * Status Codes - IETF Review
>   http://www.iana.org/assignments/http-status-codes/http-status-codes.xml
> 
> * Headers - Specification Required
> 
> p3
> * Content Codings - Specification Required
>   http://www.iana.org/assignments/http-parameters/http-parameters.xml
> 
> p5
> * Range Specifiers - IETF Review
> 
> p6
> * Cache Directives - IETF Review
> 
> * Warn-codes - IETF Review
> 
> p7
> * Authentication Schemes - IETF Review
> 
> 
> A few thoughts:
> 
> I'm having a hard time believing that Cache Directives, Range Specifiers and Warn-codes should be IETF review. How do people feel about making them Specification Required?
> 
> Does FCFS really make sense for upgrade tokens? It seems like this should be Specification Required, at a minimum. Yes, I know that it's historically been FCFS, but we have the latitude to review registration policies.
> 
> Finally, all of the Specification Required registries (including any we decide to convert) imply use of an expert reviewer; we should make sure that we give reviewers advice.
> 
> Cheers,
> 
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 5 March 2012 04:17:52 UTC