[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Bill Manning <bmanning@isi.edu>
Cc: michaelm@netsol.com, Hollenbeck Scott <shollenbeck@verisign.com>, ietf-provreg@cafax.se
From: George Belotsky <george@register.com>
Date: Mon, 12 Mar 2001 14:37:31 -0500
Content-Disposition: inline
In-Reply-To: <200103121902.f2CJ24R17354@zed.isi.edu>; from bmanning@isi.edu on Mon, Mar 12, 2001 at 11:02:04AM -0800
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Unique handle generation

A digest can be used as a handle.  A composite built up of atomics
(UUID-style) can be used as input to the digest function.  The
handle's owner still has the easy to remember representation,
which they can share or keep from whoever they like.

As I said in a previous post, the digest solution does provide
a measure of security.  Additional benefits are consistency of
representation, and proper enforcement of access control.  The digest
handle is opaque.  I cannot get any information from such a handle by
itself.  

For example, the full names of domain owners may be privileged
information in some registries (this is a matter of policy).  The
digest handle would allow users with varying privilege levels to get
just the allowed amount of information about a specific object.

The UUID-style approach of building up a unique handle from components
is easier, far less costly, and inherently much safer than running a
handle repository.  What happens if a coding error is introduced into
the repository, and duplicate handles are handed out?  What if the
handle registry is not accessible/down?  Who will build the necessary
registry infrastructure for the entire world, maintain it, provide
24x7 support for it, and pay for it?

George.


On Mon, Mar 12, 2001 at 11:02:04AM -0800, Bill Manning wrote:
> 
> A globally unique space is required within a given object type or
> confusion reigns. Constructing composites out of atomics can assist
> in removing abiguity.
> 
> Without additional information, I can't discriminate George from George
> from George.  Adding a Surname helps. (different object type) Adding 
> a registry helps (different object type).  Still too many GEORGEB-ARIN
> handles... 
> And while ARIN may fabricate its own ideas of which GEORGEB is which,
> unless there is some atomic way of removing the ambiguity of GEORGE, as
> that object type pertains to the Internet, then we can only refer to GEORGE
> in its relationship to another object type.  We can't talk about GEORGE as
> a handle with independent meaning.
> 
> 
> 
> 
> % 
> % A globally unique handle does not necessarily require
> % coordination between organizations to ensure uniqueness.
> % 
> % George.
> % 
> % 
> % On Mon, Mar 12, 2001 at 10:04:20AM -0800, Bill Manning wrote:
> % > %>% I'm not sure I understand the point you're trying to make in the context of
> % > %>% admin repository changes over time.
> % > %>% 
> % > %>% What happens to your example handle if the admin function is one day moved
> % > %>% from ARIN to some other administrative entity (call it !ARIN for the sake of
> % > %>% argument), but the person and prefix remain constant?  Does the handle
> % > %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
> % > %> 
> % > %> 	The legecy composite  WM110-ARIN remains
> % > %> 	If -I- chose to do business w/ !ARIN, then !ARIN may
> % > %> 	create the composite WM110-!ARIN.  If !ARIN wishes
> % > %> 	to create the composite anyway, they -MUST- use my
> % > %> 	handle, WM110, not create something else.. like BM14
> % > %> 	or WM73.
> % > %
> % > % So your personal handle is part of a globally unique space that all
> % > % registries have to coordinate to ensure uniqueness, right?
> % > % 
> % > % -MM
> % > 
> % > 	Unfortunately, yes.
> % > 	Just like the registry handles have be be globally unique.
> % > 	(It would be confusing to have two registries with the same
> % > 	handle... :)
> % > 	One must have globally unique space within each object type.
> % > 	
> % > 
> % > -- 
> % > --bill
> % 
> % -- 
> % -----------------------------
> % George Belotsky
> % Senior Software Architect
> % Register.com, inc.
> % george@register.com
> % 212-798-9127 (phone)
> % 212-798-9876 (fax)
> % 
> 
> 
> -- 
> --bill

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

Home | Date list | Subject list