Re: Merging RRP and Whois

>>>>> "SK" == Shane Kerr <[email protected]> writes:

 >> I wounder if you could explain in a little more detail why RWhois
 >> was done wrong?

 SK> Well, I guess there's only two problems: the client and the server.  :)

 SK> <disclaimer>
 SK> These may have been fixed while I wasn't looking.
 SK> </disclaimer>

Based on some of your observerations, I'm guessing that you haven't
looked in a while.

 SK> As I understand it, the client does not follow referrals.  This
 SK> kind of puts a damper on the whole Referral Whois.

This was definitely an embarrassing problem for some time.  As of
early 2000, all the released clients follow referrals, including the
web based ones.

 SK> Other issues involve the server software.

 SK> First, if you look at the rwhois mailing lists, you'll see a
 SK> common problem is people not reindexing the database files and
 SK> having the server give incorrect results.  While you can
 SK> attribute this to human error ("this sort of thing has happened
 SK> before, Dave, and it has always been attributable to human
 SK> error"), the fact that it happens again and again implies that
 SK> the software should validate these files before loading and
 SK> giving bogus results.

There are many, many unfriendly aspects to the rwhois server.  This
example actually isn't the most common problem.  The most common
problem is forgetting to index at all.

 SK> The server software used to incorrectly track child processes,
 SK> causing the server to refuse connections after extended use (I
 SK> patched this at ARIN, did I ever send the patches?).

This has been fixed for a long time.  I don't remember patches being
sent in about this, particularly.

 SK> Unlike the Whois protocol, the RWhois connection is persistent
 SK> (well, it can be).  This means that cheap methods of preventing
 SK> clients from overloading the server (i.e. max connections per
 SK> time) don't work.  What we saw at ARIN was that an abusive client
 SK> could crush the server (admittedly only a Sparc Ultra2 300 or
 SK> something like that) when attempting to mine the database.  The
 SK> server needs to be restarted to reload the access lists, right?

No, this was never true, as the access control was implemented via
TCP_Wrappers, which reads the ACL files for every request.

This problem was solvable in a number of ways: you could've disabled
the -holdconnect directive (which isn't all that nice), or the server
could've been modified to count responses or requests per IP, rather
than connections.  Or you could've used a proxy that did that, which
is what we did.

 SK> Plus, there's not any standard for what information should appear
 SK> in an RWhois database.  This means that a client has to be
 SK> prepared for basically ANYTHING.  At least the format of the
 SK> output is specified.  Actually, the ability to dynamically query
 SK> the schema used by a particular server is nice, but without a
 SK> "core" set of guaranteed values, it doesn't actually buy you much
 SK> (ever written a TIFF viewer? - same problem).

I can agree with this.  Reliance on schema discovery presented a very
difficult client programming problem.  This is nit-picking, but there
is a set of 'core' values: ID, Auth-Area, Class.  They just don't
extend into the application area.  In the beginning of the project, it
was thought that someone who wanted to use RWhois for a particular
application would demand a particular core schema would be used.
RWhois just didn't have a method for publishing these schema.

 SK> Also, the root for the RWhois tree doesn't appear to be
 SK> well-maintained:

True.  The RWhois project is basically on ice here.

 SK> Hmm...wasn't there a discussion about exposing private IP
 SK> addresses on NANOG recently?  Anyway, even when the root WAS
 SK> working, it didn't actually refer IP queries to ARIN, which would
 SK> have been the logical thing to do.  At least, for the "referral"
 SK> in RWhois to mean anything.

The root has referred IP address stuff to ARIN for some time now.

 SK> Then there's the issue of acceptance and use in the wider
 SK> community.  Maintenance of RWhois software always seemed sporadic
 SK> to me - but is that really unfair, considering the only ones who
 SK> really need and/or use the protocol and software are ARIN and
 SK> some of ARIN's larger ISP members.

It always surprised me that no one, especially ARIN, stepped forward
to take a more active role in RWhois.

 SK> Perhaps a modern, threaded RWhois server using an SQL back-end,
 SK> with a client dropped into popular Linux distributions and on a
 SK> web page would make my concerns seem silly.  But would something
 SK> like that actually allow Randy Bush to have a globally unique
 SK> nic-handle?  (That is why this list is here, right?)

My guess is that a more modern RWhois client/server implementations
would make the operational concerns take a back seat to more
significant protocol problems.

--
David Blacka         <[email protected]> 
Sr. Research Engineer   Verisign Applied Research