[consult] Call for Consultation: ARIN WHOIS Directory Services

[michael.dillon at bt.com]

> >   -Most of Mike Loevner's post - except that searching for 
> 12.0.0.0/9 
> > should return the  /8 (not nothing at all, because IMO, 
> that would be
> > misleading)

It strikes me that people are forgetting that we are dealing with IP
address ranges, not CIDR blocks. ARIN does not allocate CIDR blocks,
they allocate IP address ranges, especially to larger ISPs.

Would it be too hard to have a plain English search language?
If someone says:
12.0.0.0/9
Then only look for an exact match.
Same thing if they say:
12.0.0.0-12.255.255.255

But if they say

IN 12.0.0.0/9, only show exact matches or ranges entirely inside the
search range

OVERLAP 12.0.0.0/9 only show ranges which overlap the search range

CONTAINS 12.0.0.0/9 only show ranges which contain the search range
including exact matches.

Allow a LIMIT clause that limits the number of entries returned, i.e
LIMIT 10 would only return the 10 largest ranges.

Allow a MINIMUM clause that also limits entries returned, i.e. MINIMUM
/19 would only return ranges equal to or larger than /19

> >   -method to login online and manage your swip records and 
> other arin
> >    records (would be even better if the login method was 
> with an RSA token
> >    or the like)

I wonder if it is time to seriously look at a 1970's green-screen
solution. Back then all applications involved a dumb terminal which
logged into a UNIX server (or a mainframe) and ran an application. This
was often done without shell access at all, i.e. the application was the
shell. In this case, ARIN would offer access via SSH (not rlogin like
the bad old days) so that top notch security can be used, but the
application doesn't need to know about it. You don't need a special
email client or special signing software. Just the stock SSH client. And
the application could basically accept batch uploads of transactions,
i.e. SCP as well as some interactive editing capability.

> > -Whowas info - be able to search historical whois info 
> enter a prefix 
> > and specify a date range or starting date with a default 
> through the present.
> > This would help in researching claims of hijacked blocks.

I don't believe that ARIN has a mandate to help all comers to research
such claims. And the issues of stale data and unclean data lead me to
think it is better to leave the past alone.

> > -Clearly Mark Early Registration records with ERX as RIPE 
> does - and 
> > remove the ERX marking when a resource is brought uptodate/under RSA
> 
> Yes, please.  This one seems pretty easy, frankly.

In fact, mark every record with clear factual status. Who originally
allocated the block if it is known. If not known, put that fact down. If
a block is transferred, that is a fact. Put that in the status too. If
email contact is lost, that is another fact. If postal mail is returned
undelivered, another fact. If the last attempt at contact was 2007Mar23,
that is another fact. Instead of keeping all this status invisible,
display it all to us so people can see how complex things really are. If
a nameserver is lame, mark that fact in the whois record. If a
nameserver's name no longer exists, that is a fact. If the nameserver IP
address no longer responds to DNS queries, another fact. 

Just give us the facts!
> > -Add the ability to prepend searches with * for wildcard
> >   to be able to do wildcard searches on the beginning 
> instead of just 
> > the tail
> 
> I would extend this to simply support some sort of regexp expansion.

I agree. I do not like to see cryptic query syntax, but if ARIN did
adopt some standard regular expression syntax wholesale, such as PCRE,
then it would not be as bad.

> I think there's also a vital need for a web page or two that 
> explains all of these features in the (at present 
> hypothetical) new whois server.  A usage guide would be a 
> bare minimum requirement.

Document everything! Yes.

--Michael Dillon