Re: Registry policies

On 2012-03-01 07:05, 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?

Warn codes are scarce. We already burned lots of cycles on a registry 
that's probably never be used; so I'm -1 on any more changes on it.

Cache Directives and Range Specs: maybe. They are they way they are 
because we used IETF Review as default.

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

If we're ready to change existing procedures, then yes, we should change 
this.

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

And we should consider how well Expert Review works in practice (ahem!), 
and how many DEs we'll be able to recruit. Maybe this is an argument in 
favor of IETF Review.

Best regards, Julian

Received on Thursday, 1 March 2012 08:25:06 UTC