[AFS3-std] AFSVol tag-length-value extensions draft (second call
for comments)
Tom Keiser
tkeiser@sinenomine.net
Tue, 6 Apr 2010 15:48:47 -0400
On Mon, Feb 22, 2010 at 4:16 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> --On Tuesday, February 16, 2010 10:33:56 AM -0500 Steven Jenkins
> <steven.jenkins@gmail.com> wrote:
>
>> I have submitted an I-D covering extensions to the AFSVol Rx service
>> which provide get, set, and enumerate services for tag-length-value
>> (TLV) tuples.
[snip]
>
> - For each new registry, describe what the registry is for, what
> =A0information must be provided to register new values, what will be
> =A0contained in registry entries, and complete initial contents of the
> =A0registry. =A0While not all of it applies here, RFC5226 Section 4 does
> =A0a good job of describing what goes into a new IANA registry.
>
I've uploaded a new revision of the AFSVol TLV draft to the IETF.
http://www.ietf.org/internet-drafts/draft-tkeiser-afs3-volser-tlv-01.txt
http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-afs3-volser-tlv-01.htm=
l
http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-afs3-volser-tlv-01.xml
Thank you to everyone who has taken the time to provide feedback for
draft -00. I believe I have responded to all of the suggestions made
on-list, with the notable exception of JHutz's comments with regards
to registry allocation directions, as described in RFC 5226. I have
filled in one registry allocation instructions sub-section as a
strawman, but I would like to invite further discussion before I
potentially head down the wrong path with the other similar sections.
Specifically, my initial thought is we want an allocation policy along
the lines of "Designated Expert" for the capability bit registry. The
reason I have been leaning in this direction is the long-awaited AFS-3
WG does not seem to formally exist at present. If the WG were to
materialize, I suppose we could raise the bar a bit and require
something akin to RFC 5226's "IETF Review". Thoughts?
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.
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.
With regard to the value type and tag namespaces, I would like to
propose subdividing the 32-bit regions into several sub-regions with
differing allocation policies. For example, perhaps something along
the lines of:
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 reasonabl=
e?
Cheers,
-Tom