[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sorry -- Re: Merging RRP and Whois
I totally agree that the external (outside the local registry) reference is
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
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.
Cable & Wireless USA
Network Tools and Analysis Group
> -----Original Message-----
> From: Shane Kerr [mailto:shane@xxxxxxxx]
> Sent: Tuesday, January 30, 2001 1:17 PM
> To: Lu, Ping
> Cc: ietf-provreg@xxxxxxxx; ietf-whois@xxxxxxx
> 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
> 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!