RE: Sorry -- Re: Merging RRP and Whois

[Shane Kerr <shane@ripe.net>]

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