[AFS3-std] Second Draft of Standardisation Document: Registrars

[Steven Jenkins]

On Fri, Aug 29, 2008 at 3:49 PM, Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:
> Steven Jenkins wrote:
>>
>> I understand that it's a clerical role, but in a paid position, there
>> are rules and procedures for terminating employment.  We need to have
>> analogous (not necessarily identical) ones here.  With respect to the
>> terms, once the boostrap has started, terms will be more loose, but
>> each registrar should be committing to a two year term (life will
>> interfere, in which case the registrars will be free to find a
>> replacement mid-term, whose term will be two years starting *then*).
>>
> I'm not sure I understand why registrars would have term limits or there
> would be limits on the number of them.
>

The point is to make sure there is a way to have registers stop being
registers when appropriate.  Any organization that has been around a
while tends to collect 'members' that may once have been very, very
involved, but now are not, but there isn't a clear way for them to
exit (or for the organization to drop them).  IMO, term limits help
with that, as do clear procedures to allow the group to remove
individuals when appropriate.


> The point of the registrars is so that there are sufficient and
> convenient numbers of them with access to the master registration lists
> to ensure that any group or individual that wants to propose an
> extension to the protocol can do so without producing an
> interoperability conflict because two implementations decided to use the
> same RPC numbers.
>

Right. This point is very clear.

> The bootstrapping process was specified as selecting an individual from
> each of the existing implementations because it is the implementation
> teams that will most often be the ones deciding that they need a number
> assigned.
>
> The registrars do not carry extra weight when it comes to
> standardization decisions nor do they have the right to turn down an
> assignment request.   If a new implementation comes along they too can
> and should be granted access to the master registration lists.
>

That last paragraph is not reflected in the language of the document.
While the registrars are to be bootstrapped from
a specific set of implementations, there is no language that says a
new implementation should be added to the registrars, other than
implicitly by appealing to the existing registrars.

There is also no language that says how an implementation should be
removed from the registrars either -- which is actually the line of
thinking that got me started on this.  But I don't think there needs
to be language targeting specific implementations -- the 'one per
implementation' is a boostrap issue only, and is a perfectly
reasonable way to kickstart getting an adequate number of registrars
in place.

I think it much better that registrars manage themselves.  After all,
their role is to merely ensure that assignment requests are granted;
they aren't in a decison-making role.  Thus, there is no need for a
new implementation to need to be granted access to the master
registration lists as long as there are sufficient numbers of active
registars handling the requests.

-- 
Steven Jenkins
End Point Corporation
http://www.endpoint.com/