[db-wg] Proposal for returning IRT objects

[Apologies for duplicate mails]


Proposal for returning IRT objects

Motivation
----------

The original proposal for the IRT object (ripe-254) did not make adequate provision for presenting 
the irt information to the user. A new query flag ("-c") was introduced. Because of the way this 
flag was implemented and the objects it returned, it was not considered intuitive or helpful. It 
can also cause confusion.

A discussion held at the RIPE 51 meeting decided that the original implementation was a 
misunderstanding of the requirements. For more information, see AOB in the Database Working Group 
minutes:
http://www.ripe.net/ripe/wg/db/minutes/ripe-51.html

There was further discussion at the RIPE 52 meeting, details of which can be found at:
http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00052.html


Objectives
----------

- To increase the availability of the irt information to users.

- To promote the use of the IRT object.

- To make it easier for third party tool writers to find the correct contacts.

Background
----------

There has been confusion in the past about the implementation of the IRT object. We have been 
studying the concept and looking deep into the whois query code. Our understanding of how this 
works now, and how the community wants it to work in the future, has changed. This proposal 
outlines the current behaviour and what we now understand to be the desired behaviour.

Current behaviour
-----------------

A standard query for address space returns the queried inetnum and related objects. This does 
not include an IRT object, even if it is directly referenced by the queried INETNUM object.

By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still 
returned.

By using the "-c" flag, an INETNUM object is returned with a referenced IRT object and objects 
related to this INETNUM. This may not be the INETNUM in the query. No ROUTE objects are returned. 
If no (less specific) INETNUM references an IRT object, nothing is returned.

By using the "-rc" flags, the related personal objects are filtered out, including the IRT object. 
The only object returned is the referencing INETNUM object, which may not be the one in the query. 
So it is not possible to find IRT objects without returning personal objects related to the 
referencing INETNUM object.

New behaviour
-------------

A standard query for address space returns the queried INETNUM and related objects. This does not 
include an IRT object, even if it is directly referenced by the queried INETNUM object. This is the 
same as the current behaviour. We propose to change this default behaviour at the second stage of 
implementation (see Implementation below).

By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still 
returned.

A standard query for address space including the "-c" query flag returns the queried inetnum and 
related objects. This will also include an IRT object referenced by the queried INETNUM object or 
the closest less specific INETNUM object, if one exists. It will also still include any ROUTE objects.

By using the "-rc" flags, the related personal objects are filtered out. The IRT object will still 
be returned along with any ROUTE objects.

When using any other address space query flags (lLmMxb) or querying for other object types, query 
behaviour remains the same as the current behaviour. If the "-c" query flag is used, it will be ignored.

Implementation
--------------

We propose a two stage implementation. The majority of the address space queries are made without 
any specific flags. We therefore propose to change the behaviour to return an IRT object by default 
(if one exists) only at the second stage.

For the first stage, we propose changing the behaviour of the "-c" flag and the "-rc" flag 
combination as described above. This should not make any fundamental changes to the way the queries 
work. Existing tools and scripts should not fail. The web query form on www.ripe.net will add the 
"-c" flag to address space queries, making it a default. This only occurs if no other address space 
query flags (lLmMxbc) are present.

At the second stage, the query server will add the "-c" flag to any address space query that does not 
include any of the address space query flags (lLmMxbc). This will make standard queries return IRT 
objects by default.

This second stage changes the current behaviour of queries. This may break some tools and scripts. 
We can mitigate this by providing new query flags or using existing ones in different ways so that 
the behaviour resulting from the first stage of implementation can be reproduced.

Tool writers
------------

Currently any third party tools that use the "-c" flag to find IRT objects run the risk of being 
blocked for returning too many personal objects. With the new behaviour, the "-rc" flags can be used 
to return the IRT objects without the personal objects. If only the IRT object is needed,
"-rc -T irt" can be used.

Notes
-----

Any references to INETNUM and ROUTE objects also imply INET6NUM and ROUTE6.

A consequence of this change is the return of an object with no direct reference from the queried 
object.

With grouping turned on (default without "-G"), we assume that the IRT object should be grouped with 
the queried INETNUM object.

--
Denis Walker
Software Engineering Department
RIPE NCC