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) <[email protected]> For the registrars _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
