To:
"'Shane Kerr'" <shane@ripe.net>, "Lu, Ping" <plu@cw.net>
Cc:
ietf-provreg@cafax.se, ietf-whois@imc.org
From:
"Lu, Ping" <plu@cw.net>
Date:
Tue, 30 Jan 2001 15:25:31 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
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: plu@cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Tuesday, January 30, 2001 1:17 PM > To: Lu, Ping > Cc: ietf-provreg@cafax.se; ietf-whois@imc.org > 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 >