Re: Unique handle generation

[George Belotsky <george@register.com>]

We may be 'deja vu' on the questions, but not on the answers.

The messages you quote spell out some of the issues, and Dave
suggests the employee number analogy, which looks like an
opaque identifier.

The reason for having global identifiers for all objects is so
that they can move between various entities without changing.

For a domain name, you may get away with just using the fqdn 
itself, but then the handle would never change -- even if the
name is deleted and then registered by someone else.  This may be
undesireable (although you would want the handle to remain the same in
the case of an actual transfer).

For other objects (e.g. contacts), no unique identifier exists a
priori.  Thus, you are forced to choose either between a UUID-style
composite of atomics, or maintaining a shared database of handles
(after all, we have this for domain names, which is why we can trust
the uniqueness of an fqdn in the first place).

With Variant (3), I can still use my contact identifier with as many
registries/registrars as I choose.  The opaque identifier can also be
used to grant limited access to certain information.  

For example, a whois search (using an fqdn) can return the opaque
identifier of a contact as a parameter, along with the electronic
address of the administrative entitity holding the name.  Using this
returned identifier, I can query the administrative entity for more
information.  Depending on my permissions (which are a matter of
policy), I may be able to get the email address (but not the name or
telephone number) of the contact.

As can be seen from the above, Variant (3) functionality can still
have many uses.  We already have Variant (2) functionality for some
objects (such as domain names) through other means (such as whois).

Is it really worth it to have lookup (let alone search) functionality
for every single object type -- given the fact that a database of
handles would have to be maintained for this purpose?


George.


On Thu, Mar 15, 2001 at 07:59:26AM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: George Belotsky [mailto:george@register.com]
> >Sent: Wednesday, March 14, 2001 4:44 PM
> >To: Hollenbeck, Scott
> >Cc: 'Patrik Fältström'; ietf-provreg@cafax.se
> >Subject: Re: Unique handle generation
> >
> 
> [snip]
> 
> >This once again gets back to what the handle is for.  To illustrate, I
> >have listed three basic variants below.
> >
> >         (1) Handles are used to search for objects.
> >         (2) Handles are used to quickly look up objects, regardless of
> >             their location.
> >         (3) Handles are used only to request operations on 
> >objects whose
> >             location is already known.
> 
> [snip]
> 
> This feels like "deja vu all over again" (my apologies to Yogi Berra):
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00035.html
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00038.html
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00039.html
> 
> I think we've already determined (or at least I've suggested) that variant
> (2) is required functionality for systems like whois.  Within a registry, I
> don't believe variant (3) provides any functionality that we don't have with
> more basic identifiers -- I can refer to a domain name or host name by FQN
> and a contact name by whatever local part makes sense because these values
> are already unique within the repository.  There are deployed systems (like
> whois again) that provide variant (1) functionality, though I don't think
> this functionality is necessary in a provisioning protocol.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
george@register.com
212-798-9127 (phone)
212-798-9876 (fax)