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@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@resilans.se"
Via that question, I will see every object that has the notify info@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