RWHOIS proposal

[Lee Howard]

On Tue, 9 Oct 2001, Shane Kerr wrote:

> Date: Tue, 9 Oct 2001 12:16:54 +0200
> From: Shane Kerr <shane at time-travellers.org>
> To: Lee Howard <lhoward at uu.net>
> Cc: dbwg at arin.net
> Subject: Re: RWHOIS proposal
> 
> On 2001-10-04 10:55:09 -0400, Lee Howard wrote:
> > We've begun evaluating using RWHOIS.  Among the advantages I see are
> > instant updates, local access control, restricted access for bulk
> > queries, privacy protection, and if I'm lucky, a chance to integrate
> > RWHOIS and IRR.
> 
> True, true.
> 
> > The problems I'm having are that I will have to modify the code to 
> > query an existing SQL database, change the output to RPSL, and cost-
> > justify the work to the business.  I think ARIN can help me with the
> > last point.
> 
> When you say "change the output to RPSL" do you mean making an RWHOIS
> schema that is also valid RPSL?  I think this should be possible, as
> RWHOIS syntax is (mostly) a subset of RPSL.

Exactly.  Should be nearly trivial, right?

> > So, ultimately, if the membership agrees that RWHOIS is a Good Thing,
> > this would create an incentive for them to use it.  If it creates less
> > work for ARIN, so much the better.
> 
> Does the membership agree RWHOIS is a Good Thing?  IIRC, it was
> something that the IP registration office at InterNIC (then run by
> Network Solutions) had proposed and set up.  Was there any community
> involvement or discussion before this?  (There may have been, but it was
> not a member community the way ARIN is.)

RWHOIS has been a recurring topic at public policy meetings.  Come to 
think of it, most of those discussions were after you left ARIN.  There
has been enough interest/support to keep the conversations going. 

> I agree less work for ARIN is a good thing, but there are disadvantages
> to a distributed database.  Among these are: 
> 
> 1. No guarantee of data integrity.
>    I consider this a real problem for RWHOIS data because there is
>    some incentive for operators to provide a reduced subset of data, or
>    even incorrect, information.  With SWIP, ARIN has a record of all
>    database changes so this kind of switcheraoo is impossible.

I think it's easier to provide accurate data (as accurate as our database
of record) than false data.  For false data, I'd have to have a database
that doesn't reflect my database of record, then manually falsify data.
There are guidelines as to what data should be presented.  I honestly
think that maintaining data on my own server is more likely to result in
more accurate, current data than having it on ARIN's server. 

For example, say a customer calls our support line to give us updated
contact information.  If our hypothetical RWHOIS server is based on our
database of record, RWHOIS is automatically updated.  As it is, our
level one support tech might or might not remember to modify the SWIP
record.

> 2. No guarantee of reliability.
>    Unlike DNS, where it is in the interest of the administrator to keep
>    the service running, with RWHOIS the only users that the
>    administrator cares about are internal, customers, or ARIN staff.
>    There is simply no incentive to produce a reliable public database
>    by ISP's.  ARIN, however, does have incentive to provide this
>    database.

Well, it has to be up at least once in a while, so ARIN staff can review
the data to approve the next allocation.  But I see your point.  If an
animald existed where a server functioned as both an RWHOIS server and
a routing registry, the incentive is built in, since customer connectivity
might be impaired by an IRRd failure.


> Surely this is not an exhaustive list.  There are, of course, advantages
> to RWHOIS, but personally I'd prefer a robust, user-friendly ARIN-run
> database to a distributed database.

I'd also love to see universally-distributed whois clients capable of
recursive lookups, a la DNS, to make RWHOIS more user-friendly.  

> -- 
> Shane
> Carpe Diem
> Any opinions expressed are not necessarily those of anyone else.


Lee
copy Shane's disclaimer