RE: Sorry -- Re: Merging RRP and Whois

I totally agree that the external (outside the local registry) reference is
a difficult 
problem to solve.

But nontheless there is a need to use them. Because the alternative ( let
each ISPs to maintain a different set of objects for each IR ) is a manual
process and is more prone to
error.

Just like the driver license. People only register in one state then all
other states can 
reference the information even there is a risk this license may be revoked
if you don't
check frequently enough.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: [email protected]


> -----Original Message-----
> From: Shane Kerr [mailto:[email protected]]
> Sent: Tuesday, January 30, 2001 1:17 PM
> To: Lu, Ping
> Cc: [email protected]; [email protected]
> Subject: RE: Sorry -- Re: Merging RRP and Whois
> 
> 
> On Tue, 30 Jan 2001, Lu, Ping wrote:
> 
> > As you mentioned the NIC-HANDLE problem is a global one.
> > 
> > There is no question that NIC-HANDLE should be unique inside each
> > Registry's database.
> > 
> > But what happen if you want to peer with other ISPs who is
> > registered all over the world ?
> > 
> > Either you REFERENCE their objects from all the RIRs (ARIN, RIPE,
> > APNIC ...) or you ask them to replicate their objects in your own
> > Registry. The former will require the NIC-HANDLE to be global
> > unique, the later will need all ISPs to maintain a seperate set of
> > objects for each IR.
> 
> Indeed it will require much more than being globally unique.  For
> instance, what happens if you have a database, PING, which a reference
> to an object, XYZ, in another database, KERR.  If someone wants to
> delete XYZ from KERR, KERR can either prevent the delete or not.
> 
> If KERR does not prevent the delete, you have a dangling 
> reference, and
> possibly no contact information for the objects in PING that refer to
> XYZ.  Suggestions have been made that PING could cache the object, and
> use the undeleted object.  However, in this case, you would 
> have either:
> 
> 1. A copy of an object, say XYZ-KERR, that is not in the KERR 
> database.
> 
> 2. A renamed copy of the object, say XYZ-PING, that XYZ did not create
>    or explicitly request the creation of.
> 
> If KERR prevents the delete, then you have authentication issues.  For
> example, if PING does not implement the same authentication that KERR
> does, then a user can create a reference to XYZ in PING and prevent an
> authenticated user from deleting the object in KERR.
> 
> In the cases where a new object is created from cache or a deletion is
> prevented, KERR needs some sort of registration mechanism to know that
> PING has a reference to the object.  (In the case of creation from
> cache, KERR needs to make sure that PING has the latest copy of the
> object before deleting it.)
> 
> I haven't touched on modification here, but it should follow the same
> general issues.  Creation will require appropriate 
> registration for any
> foreign keys used and such.  This registration and checking will of
> course slow down the modification of the databases, and also 
> add a level
> of unreliability.
> 
> In the case of objects in the RIPE database, we are extremely
> read-heavy, and write-light.  However, referring to foreign objects
> means occasionally querying other servers to get the data.  With a
> proper registration mechanism, objects can be cached locally.  I would
> prefer NOT to see a DNS-style system, where it is just assumed that
> queries provide incorrect data occasionally.  It may be the 
> best answer,
> but I think it is avoidable.
> 
> I believe that using references to other Whois databases requires a
> great deal of cooperation, at least on the protocol level.  Is it
> scalable?  I suggest that it probably is, for small numbers of Whois
> servers.  For large numbers of servers, you'll probably need some sort
> of graph - a tree perhaps? ;) - to distribute the load.  Perhaps some
> simulations should be done before moving too far along?
> 
> A bigger question is whether organizations would be willing to bind
> their databases together like this, and if so in what fashion.  I get
> very nervous considering the politics involved.  Am I the only one who
> thinks it may be an unsurmountable problem?
> 
> I've said it several times now, but this is a Hard Problem.  I have
> heard Bill Manning say that he thinks it would be worthwhile solving.
> Others (unnamed) just seem to want a global NIC-HDL, which I 
> don't think
> buys you anything unless you can use it.  I don't think you can use it
> unless you tackle the issues here.  It seems like a lot of 
> work for very
> little real gain!
> 
> Shane
>