[AFS3-std] Registrars Bootstrapping

[Jeffrey Hutzelman]

Section 2.3.2 of Simon's proposed charter document describes the
registrar function, which would be responsible for maintaining and
publishing lists of AFS-related protocol constants, serving as a
central point of allocation for new values while avoiding collisions.
I have been performing those functions, with varying degrees of
visibility and timeliness, since late 2001 or early 2002.

Simon's document proposes expanding the registrar role to a small
group rather than a single person.  It makes the group responsible
for setting its own procedures for managing its membership, including
adding and removing members and determining the size of the group.
It also proposes that the initial membership of that group consist
of the existing registrar (i.e. me) plus one representative from
each current AFS implementation wishing to participate.

Back in 2008, I made the decision to proceed with bootstrapping a
registrar group along the lines of Simon's proposal, without waiting
for formal adoption of a new charter.  This decision was based on
my observations that there appeared to be community consensus behind
the proposal, that the registrar function was already independent
and would largely remain so under the new proposal, and that it was
desirable to eliminate the single point of failure represented by
a single-person registrar.

In response to queries sent to the various implementors, Thomas Kula
agreed in 2009 to serve as a registrar on behalf of OpenAFS.  More
recently, David Howells has agreed to serve on behalf of kAFS.  No
volunteers were forthcoming from IBM or from the Arla community.
With these responses, I am pleased to report that initial formation
of the registrar group is now complete.

We still have a ways to go before the registrar function is running
as well as we'd like.  The proposed charter calls for the registries
to be maintained as a set of documents editable by all registrars and
accessible to the community.  The current database falls far short,
consisting of a few publicly-accessible web pages and the history
of previous requests I have processed.  Our first tasks will be to
establish internal procedures for managing both the registry and the
membership of the registrar group, and to devise a plan for moving
to a fully up-to-date, publicly accessible registry.  In the meantime,
of course, we will continue to process requests for new values.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   For the registrars