[db-wg] Suggestion of change for inverse query of notify

Dear Fredrik

Before we get into a discussion about how behaviour should/should not be 
changed, perhaps I can explain the technical details of how these 
queries work. There are several inter-related factors here.

First of all, for a non inverse query as in your second query below, we 
parse the query string to see what type of object primary key it could 
match. We then search for matching objects of those types. If you use -T 
we filter the result set according to the types specified in the 
argument to -T. Adding the -r means we don't look into any of the 
objects in the (filtered) result set to find the referenced secondary 
object types (such as PERSON or ROLE).

It was specifically requested by the community many years ago that if 
the query result set includes an Internet number resource object 
(INETNUM or INET6NUM) we also return any ROUTE/ROUTE6 object with a 
matching prefix. This is regardless of whether the query search string 
matches the primary key of the ROUTE/ROUTE6 object. These objects are 
added to the result set before any filtering or referral queries are 
made. If -r was not specified the secondary object for the routes would 
also be returned. If -T did not include ROUTE it would be added to the 
result set to satisfy the community exception and then filtered out with 
the -T.

To enable inverse searches we keep index tables of all inverse 
searchable attributes. The primary result set of an inverse query is all 
objects that contain the inverse searched attribute with the specified 
value. The results are then subject to filtering with -T and expansion 
without -r in the same way as the above query.

In general most uses of inverse queries only want to find those objects 
that contain the specified string in the searched attribute. The 
community exception for always returning ROUTE/ROUTE6 objects when the 
result set includes an INET(6)NUM object with matching prefix has never 
been applied to inverse queries. If this is the behaviour change you 
want it is quite a significant change. It will return objects in the 
result set that do not include the inverse searched string (ignoring 
referred secondary objects subject to -r).

So for your specific examples, the inverse query looks for objects with 
"notify: info at resilans.se". This includes the INETNUM but not the ROUTE 
object.

The other query looks for address space including the address 194.14.3.0 
and any matching ROUTE object. So you get back both the INETNUM and 
ROUTE object.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Team


On 19/03/2014 13:41, Fredrik Widell wrote:
>
>
> Hello db-wg.
>
> I would like to change the behaviour of the whois-output for the 
> following query
>
> whois -h whois.ripe.net -- "-r -T inetnum,route -i notify 
> info at resilans.se"
>
> Via that question, I will see every object that has the notify 
> info at resilans.se set, which right now is
>
> inetnum:        194.14.3.0 - 194.14.3.255
> netname:        RESILANS
> descr:          Resilans AB
> remarks:        VV
> org:            ORG-ABUS1000-RIPE
> country:        SE
> admin-c:        RESI1-RIPE
> tech-c:         RESI1-RIPE
> status:         ASSIGNED PI
> mnt-by:         RESILANS-MNT
> mnt-domains:    RESILANS-MNT
> mnt-routes:     RESILANS-MNT
> source:         RIPE # Filtered
>
>
>
> However, my request is that the above query should give the exact same 
> output as the below query
>
> whois -h whois.ripe.net -- "-r -T inetnum,route 194.14.3.0"
>
> which will also display the corresponding route-object, is there any 
> real reason why this
> is not displayed with an inverse query? it looks like:
>
> inetnum:        194.14.3.0 - 194.14.3.255
> netname:        RESILANS
> descr:          Resilans AB
> remarks:        VV
> org:            ORG-ABUS1000-RIPE
> country:        SE
> admin-c:        RESI1-RIPE
> tech-c:         RESI1-RIPE
> status:         ASSIGNED PI
> mnt-by:         RESILANS-MNT
> mnt-domains:    RESILANS-MNT
> mnt-routes:     RESILANS-MNT
> source:         RIPE # Filtered
>
>
> route:          194.14.3.0/24
> descr:          Resilans AB
> origin:         AS12381
> mnt-by:         RESILANS-MNT
> source:         RIPE # Filtered
>
>
>
>
>