Subject: Re: Registry policies

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Mar 2012 09:24:29 +0100

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Mar 2012 11:02:35 +1100

On 01/03/2012, at 7:24 PM, Julian Reschke wrote:
> 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.

Well, we burned a lot of cycles *talking* about it; actually doing it was trivial.

> Cache Directives and Range Specs: maybe. They are they way they are because we used IETF Review as default.
> 
> If we're ready to change existing procedures, then yes, we should change this.
> 
> 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.

While I agree that ER is tricky to get right, the problem with IETF Review is that the registry gets far away from practice. I'd very much like to be able to document values that are in use.

Thinking out loud, IETF Review would be ok if we augmented it with a DE-like function -- call it a Registry Maintainer -- whose job would be to submit other values that are in use and have them designated with a special status, so that a) the registry was (more) complete, and b) collisions were avoided.

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

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 02 Mar 2012 13:12:21 +1300

my vote would be for deprecation of the concept of extensions for the 
range header.  Unless we are going to allow extension for 
Content-Length, we shouldn't allow it for Range.

e.g remove other-range-unit from the BNF.

Systems that want to request parts of things that aren't specified by 
bytes can do that some other way.  Absolutely no need to overload 
Range.  Otherwise a cache has an impossible job.

Adrien

On 1/03/2012 9:24 p.m., Julian Reschke 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
>> 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.
>
> 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
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 02 Mar 2012 15:14:32 +0900

I very much think that what you proposed in the first mail in this 
thread is best (maybe minus Ranges). Inventing a new mixture between a 
Designated Expert process and IETF Review is really overkill.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Mar 2012 17:17:40 +1100

I know it's coming out of left field somewhat, but Julian is speaking from painful experience (that I've shared), and we've been trying to improve this for a while in the HAPPIANA effort. Maybe it's too early to try here, just (as I was saying) thinking out loud.

Cheers,

On 02/03/2012, at 5:14 PM, Martin J. Dürst wrote:

> I very much think that what you proposed in the first mail in this thread is best (maybe minus Ranges). Inventing a new mixture between a Designated Expert process and IETF Review is really overkill.
> 
> Regards,   Martin.
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Mar 2012 09:24:19 +0100

On 2012-03-02 01:12, Adrien de Croy wrote:
> range header. Unless we are going to allow extension for Content-Length,
> we shouldn't allow it for Range.
>
> bytes can do that some other way. Absolutely no need to overload Range.
> Otherwise a cache has an impossible job.
>
> Adrien

No. Range units are in use, and there's nothing wrong with it.

It's ok for a cache to ignore them; so there's no additional burden.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Mar 2012 15:17:25 +1100

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Mar 2012 23:26:20 +0100

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

+1

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

When you say "quick I-D" what exactly do you mean? Register as 
"reserved" with a pointer to the I-D? If the idea is that the I-D will 
have to be approved and published, what's the difference to "Standard"?

(maybe standards-track vs non-standards-track?)

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

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Mar 2012 13:25:46 +1100

On 06/03/2012, at 9:26 AM, Julian Reschke wrote:

> When you say "quick I-D" what exactly do you mean? Register as "reserved" with a pointer to the I-D? If the idea is that the I-D will have to be approved and published, what's the difference to "Standard"?
> 

The difference is that "standard" means it has a specification, and that specification has consensus.

The alternative is something that's registered, but without consensus, and possibly without a (full) specification. I'm happy to use something other than "reserved" if there's a suggestion.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Mar 2012 09:00:47 +0100

> The alternative is something that's registered, but without consensus, and possibly without a (full) specification. I'm happy to use something other than "reserved" if there's a suggestion.

My point being: when you say

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

Do you *really* mean that is sufficient to write an ID, and *not* get it 
published as RFC?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 06:43:30 +1100

On 06/03/2012, at 7:00 PM, Julian Reschke wrote:

>  "... 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."
> 
> Do you *really* mean that is sufficient to write an ID, and *not* get it published as RFC?

No.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Mar 2012 20:50:59 +0100

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

If somebody writes that I-D and gets it published, why wouldn't the 
state then not be "Standard"?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Mar 2012 22:24:51 +0100

So...

+1 on making them all the same (except for header fields being defined 
elsewhere).

 > * Upgrade tokens - First Come First Served
http://www.iana.org/assignments/http-upgrade-tokens/http-upgradetokens.xml
 >    http://www.iana.org/assignments/http-parameters/http-parameters.xml

to IETF Review, which I believe makes a lot of sense for these anyway.

I'm not convinced yet on the part about "reserved" and would like to get 
more feedback, or optimally guidance from the happiana activity.

Proposal: just do the "make-them-consistent" part for now; will provide 
a proposed patch.

Feedback appreciated, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 15:06:46 +1100

I think that makes sense.

On 07/03/2012, at 8:24 AM, Julian Reschke wrote:

> So...
> 
> +1 on making them all the same (except for header fields being defined elsewhere).
> 
> I'm not convinced yet on the part about "reserved" and would like to get more feedback, or optimally guidance from the happiana activity.
> 
> Proposal: just do the "make-them-consistent" part for now; will provide a proposed patch.
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Mar 2012 09:03:15 +0100

> I think that makes sense.

As this change actually isn't something #247 asked for, I have opened 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/346> to track this.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Mar 2012 09:48:40 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/346> to track this.

Proposed change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/346/346.diff> 
(this harmonizes the 5226-related throughout, even when the Policy did 
not change).

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Mar 2012 11:33:21 +1100

Looks good to me.

On 07/03/2012, at 7:48 PM, Julian Reschke wrote:

> Proposed change: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/346/346.diff> (this harmonizes the 5226-related throughout, even when the Policy did not change).
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Mar 2012 11:39:02 +0100

> Looks good to me.

OK. -> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1567>