[AFS3-std] AFSVol tag-length-value extensions draft (second call for comments)

[Jeffrey Hutzelman]

--On Tuesday, April 06, 2010 03:48:47 PM -0400 Tom Keiser 
<tkeiser@sinenomine.net> wrote:

> There is a catch to using the "Designated Expert" policy: it may lead
> to a stalemate situation due to our current difficulty with
> legitimizing and bootstrapping the AFS-3 WG chair election process.

Well, we should just fix that.  It's mostly a matter of doing it.
Actually, I suppose I should send out a call for objections this week, 
which would allow us to run the election process on the timeline the 
document envisions, which is useful because it means we can use relatively 
current mailing list membership without fudging things.  But that's another 
thread.




> Although the cap bits namespace is not exactly small (~6300 entries),
> we should have some form of standardization and review requirements to
> curb abuse.  To handle the case of failure to elect an expert, I've
> tentatively placed language in the draft which gives the AFS Assigned
> Numbers Registrar the power to appoint interim experts to assist them
> with the vetting process for allocation requests.

So, my reference to RFC5226 was mostly about defining what is in the 
registry and what request for allocation of new numbers need to look like. 
I specifically did not intend to suggest selecting among the well-known 
policies listed in that document, many of which aren't really applicable to 
us.  I believe Simon's charter document proposes a default allocation 
policy which amounts to only allocating numbers to things going through our 
process, along the lines of "IETF Review", but does the actual assignment 
earlier than IANA typically does for IETF documents.

If you want to select a policy other than that, I can make some 
suggestions.  Of course, "reserved" and "private use" ranges make sense; 
these aren't really allocation policies, since the numbers they apply to 
cannot be allocated in the registry at all.  For numbers that will be 
assigned by the registry, pick a single policy or combination of policies 
that will be used to decide whether a number should be allocated at all, 
but leave it to the registrars to decide which numbers to choose.  Don't 
reserve different chunks of namespace for different policies unless there 
is a really good reason to do so.  For example, in some of its registries 
Kerberos reserves smaller values for numbers allocated through the 
standards process because they require less space to encode.

With regards to the specific allocation policy, pick one of these:

- FCFS (no review)
- RFC Required (*)
- Designated Expert (reviewed by expert; spec need not be public)
- Specification Required (reviewed by export; spec must be public)
- AFS3-STDS Early Assignment (see Simon's charter document)
- AFS3-STDS Consensus

In most cases, the expert will be designated by the AFS3-STDS chairs. 
However, I think you can feel free to use this policy even before we get 
the elections off the ground, on the theory that the registrars will find 
an expert, do the evaluation themselves, or ask on this mailing list. 
Unlike today's IANA, the registrars are comfortable with making such 
judgement calls, at least for now.

Most of the rest of the policies in RC5226 have little meaning for us:
- "Experimental Use" is really different from "Private Use" only in
  expected usage, and then not in any particularly important way.
  Neither is really an allocation policy, as both are explicitly not
  coordinated.

- "RFC Required" is slightly stronger than "Specification Required" in
  that it requires the spec to be an RFC, and slightly weaker in that it
  does not actually require review by an expert to determine that the
  specification is actually "real" enough to be usable.  I don't think
  the former distinction is useful to us, and I thing the latter is
  actively a bad idea.

- "IETF Review" and "Standards Action" both map to "AFS3-STDS Consensus";
  our process doesn't have distinct standards vs non-standards tracks

- "IESG Approval" has as its closest analog "AFS3-STDS Chair Approval".
  I don't see the need in our process to create this escape hatch on a
  case-by-case basis.  If we end up deciding we want to allow a chair
  or some other entity to override allocation policy in an emergency,
  lets do it globally by writing it into a charter revision.





> range : policy
> -----   ------
> 0 : reserved
> 1-0x3FFFFFF : "RFC" + "Designated Expert" Approval
> 0x4000000 - 0x7FFFFFF : "First Come First Served"
> 0x8000000 - 0xBFFFFFF : "Private Use"
> 0xC000000 - 0xFFFFFFF : "Experimental Use"
> 0x10000000 - 0xFFFFFFFF : reserved
>
> Do these range breakdowns and associated allocation policies seem
> reasonable?

In the context of what I said above, I think you should set aside a range 
for private use, define one policy for the rest, and leave it up to the 
registrar.  In this case there is no reason to allocate one chunk of space 
for FCFS and a different chunk for expert review.

In general, I would recommend against FCFS, in favor of at least Designated 
Expert or Specification Required.  But in any case, we should pick one, and 
exactly, one, rather than gratuitously requiring different levels of review 
for different parts of the namespace.

-- Jeff