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


To: ietf-provreg@cafax.se
From: Lucio De Re <lucio@proxima.alt.za>
Date: Wed, 14 Mar 2001 09:03:51 +0200
In-Reply-To: <p05100313b6d4bf2df692@[10.0.1.8]>; from Patrik Fältström on Wed, Mar 14, 2001 at 07:30:34AM +0100
Reply-To: lucio@proxima.alt.za
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Unique handle generation

On Wed, Mar 14, 2001 at 07:30:34AM +0100, Patrik Fältström wrote:
> 
> I think you make life much too complicated.
> 
This I agree with.

> It is much easier if you use an algorithm which
> 
> (a) Divides the world in a number of registries. One can be a RIR, 
> another a TLD.
> (b) All registries get a unique identifier, and that is registered somewhere.

So far so good.

> (c) Each registry is responsible for assigning a unique local 
> identifier for each object.

Unless I'm missing the point, the middle ground between George and
Bill lies with making the "local" identifier globally unique.
Irrespective of the algorithm used to generate the ID, a digest
operation would provide a much greater degree of uniqueness.  Only
the participating parties need to know what was used to construct
the digest, the digest itself becomes the handle, guaranteed unique
by the {pre,suf}fix of the registry's unique ID.

The registrant retains the components, so she can advise the next
registry how the digest was constructed (if required, of course).

> (d) The globally unique identifier is a concatenation of the two.

Yes.

> (e) One might be able to create a URN scheme for this space of identifiers
> 
> This is what happens today (part from at VGRS and ARIN), and it 
> works. You don't have to come up with some rules for how a registry 
> works, and creates the identifier. That is up to them.
> 
But it could lead to collisions and/or incompatibilities in migrating
an object from one registry to another.  Fixing the digest algorithm
would avoid incompatibilities and, through sensible choice, minimise
collisions.  The few collisions that may still occur can be handled
manually.

> A registry might go away, but if that happens, I claim that all 
> records are moved together to a different organization, but the 
> registry stay atomic.
> 
I think this is an unnecessary restriction.  As the registrant of
a record, I may want to make a decision at the point of collapse
as to where I want my record to be migrated to.

> A registry might be split (something which will happen soon I think) 
> and this is the tricky part. One record might stay, and another might 
> be moved. This can be achieved by deleting records which are moved, 
> and creation of new ones in the new registry.
> 
Again, the registrant may want a choice.

> Note that splitting a registry is a very rare operation, and I am 
> prepared getting some trouble when that one-time-operation happens.
> 
At least in splitting a registry no collision is likely to happen.
COnsolidating registries would be a bigger problem, and the registrant
then has less say in the matter :-(

++L

Home | Date list | Subject list