[db-wg] whois_rip feature request, multiple inverse attribute queries needed

Arnd Vehling wrote:
> Tobias Cremer wrote:
> 
>> Yes, but only for the same kind of attributes, right? Means I cannot
>> search for admin-c and mnt-by in the same -i query like I would do with
> 
> 
>> whois -i tech-c,mnt-by toc76-ripe,CW-EUROPE-GSOC
>>
>> but of course
>>
>> whois -i admin-c,tech-c toc76-ripe
>>
>> works.
> 
> 
> Right, i need to do searches on different inverse-attributes in one
> query. And i would like to only get those objects back which match both
> inverse attributes.
> 
>> So the question if it is a OR or a AND operation is a second point
>> beneath that and would apply to searching only i.e. "pn" attributes and
>> serching multiple different attributes.
> 
> 
> Right, would be cool to be able to specify if one wants to "AND" or "OR"
> the returned objects.
> 
> @DevTeam, would it be possible to get this in sometime soonish?

Actually, it might be nice to rethink the query mechanism a bit further.
There are a few limitations with the current setup.

Problem 1: ROUTE/ROUTE6 searches

There is no way to specify that you want only ROUTE or ROUTE6 objects with a
specific "origin:" attribute:

$ whois -T route -r 62.23.0.0/16

route:        62.23.0.0/16
descr:        FR-COLT-FRANCE
origin:       AS8220
  ...

route:        62.23.0.0/16
descr:        FR-COLT-FRANCE
origin:       AS6675
  ...


Problem 2: PERSON searches

Searching for PERSON objects sometimes returns results that are not desired.
This can happen if the name in a person object matches the string of a
"nic-hdl:" attribute, like when looking for "KIRI":

$ whois -T person -r kiri | egrep '^((person|nic-hdl):|$)'

person:       Kiri Butler
nic-hdl:      KB9435-RIPE

person:       Kiri Georgiou
nic-hdl:      Kir5-RIPE

person:       Aasish Kiri
nic-hdl:      AK3283-RIPE

person:       Robert Kirmayer
nic-hdl:      KIRI

The database has no way to know if you are looking for the "nic-hdl:" or the
"person:" attribute that matches.


Possible Solution A: multiple inverse queries

We can solve problem 1 (multiple "origin:" attributes), and Tobias' original
problem, by allowing multiple inverse queries in a logical AND operation.
We'd need to change the meaning of multiple "-i" flags though. Right now, if
you type:

$ whois -i tech-c -i admin-c swk1-ripe

It is the same as:

$ whois -i tech-c,admin-c swk1-ripe

The database *could* be changed to interpret them differently:

$ whois -i tech-c,admin-c toc76-ripe

Would work the same, but if you have more than one "-i" flag, you would list
the keys separately:

$ whois -i tech-c -i mnt-by toc76-ripe CW-EUROPE-GSOC

Limitations are:

o This does not work for problem 2 (ambiguous "person:" and "nic-hdl:"
attributes).

o It is not exactly simple for the average user to understand.



Possible Solution B: SQL-like searches

While we would be reluctant to allow actual SQL searches into the database,
we might be able to open the database up to an SQL-like search language:

$ whois --search tech-c='TOC76-RIPE' and mnt-by='CW-EUROPE-GSOC'

$ whois --search nic-hdl='kiri'

Problems:

o One could perform some extremely non-optimal searches. (We could possibly
avoid most of this problem by requiring that some key is present in the search.)

o A second query language for users to learn.


We would be unlikely to be able to implement either of these before the RIPE
meeting, but could begin before then (after the pending abuse changes).


Apologies for the long delay in replying, but I was nervous about raising 
the idea of SQL-like searches, and wanted to wait before mentioning it in 
public.

-- 
Shane Kerr
Software Engineering Department Manager
RIPE NCC