--On Tuesday, April 06, 2010 03:48:47 PM -0400 Tom Keiser
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
