On Fri, Aug 29, 2008 at 4:04 PM, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote: > --On Friday, August 29, 2008 03:47:11 PM -0400 Steven Jenkins > <[EMAIL PROTECTED]> wrote: > >> On Fri, Aug 29, 2008 at 3:42 PM, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote: >> ... >>> >>> Would you be satisfied with language allowing the registrars to eject >>> one of their own? If not, what else do you think is necessary? >>> >> >> Yes. > > OK, then. Now let's see if we can agree on some text. I'll propose the > following as a replacement for the next-to-last paragraph of 2.3.2: > > This combination of roles makes it difficult for a single > individual to serve as registrar. Instead, it is proposed to > expand the role of registrar to include a number of individuals > from the community. This group would initially be composed as > described in section 3. > > Once established, the registrars set their own procedures for > adding new registrars, removing registrars, and determining the > size of the group. In the event there are no registrars, a new > group will be formed consisting of one representative from each > active AFS implementation and one representative chosen by the > chairs. > > I would also add the following sentence to the last paragraph of 2.3.2: > > The registrars must make the current set of registries available to > the community, including versions in the preferred source form. > > These changes have several effects... > > - Explicitly empower the registrars to establish a removal mechanism. > - Explicitly empower the registrars to set the size of the group. > - Remove mention of the "current registrar", which is meaningful only > during initial bootstrapping. > - Remove ex officio membership of chairs in the registrar pool. > - Provide a way to recover from all of the registrars disappearing. > - Insure source is available if someone else has to take over. > > Comments? >
Looks good to me. Thanks, Steven -- Steven Jenkins End Point Corporation http://www.endpoint.com/ _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
