Domain Object Queries and Referrals (was: Ripe change to whois)

Folks,

I have been pondering this for a day now and I conclude that there is no
easy answer to this issue, i.e.  it is not yes/no 1/0 black/withe in any
aspect.  I'll address two aspects here: process and technology.  I'll
then tell you what the RIPE NCC will do now.  I apologise for the
wordiness of this but I find no way to say it more concisely and stay
civil at the same time. 


Process

The number of regular database users is certainly measured in the
thousands these days.  This means is not OK any longer for Daniel or the
RIPE NCC to decide what is right or wrong, or what gets implemented. 
Over the years we have developed a process within RIPE to develop
database policy: the database working group which involves other working
groups as required.  Developments are discussed and announced in these
fora.  However it comes with a back side and that is that quick
pragmatic changes are more difficult.  Deciding to undo policy derived
by proper process in an ad-hoc way is something the RIPE NCC has to be
uncomfortable with and do only in rare exceptional cases.  But it should
be done when necessary and the RIPE NCC will take the responsibility
when it does so.  But it cannot be something one does lightly or even
regularly. 


Technology

In this particular case there are two changes that are relevant to the
issue and they are inter-related.  The first change is the introduction
of a referral mechanism by which an object in the database can cause the
query to be referred to another server.  This apparently was well
understood by everyone concerned, especially the fact that it is at the
user's discretion whether to use this mechanism or not.  A second but
tightly related change is recursive resoloution of queries for domain
object.  This changes the database behavior on *all* domain name
queries: if no object with the exact name queried exists this will
search the domain name hierarchy upwards and return the first object
found in this way; in other words subdomains will be stripped until a
match occurs.  At the time of the discussion it was explicitly noted
that recursive referral will return a parent domain object for
non-existing domains.  This was regarded as a feature since it would
return a pointer to the correct registrar with whom to register the
non-existant name and we have seen that it works ;-). 

The reason these changes are inter-related is that without recursive
querying TLD administrators will still be obliged to enter one object
for each domain and all these will have the same content: a referral to
the TLD whois server.  With recursive querying, only one object is
required and the need for regular redundant updates is eliminated.  
So the two changes are tightly inter-related and just switching off
recursive querying will hurt those implementing referral. 


How to Proceed

When deciding how to proceed we first had to consider whether the
problems raised by a few users warranted a deviation from the process. 
Our conclusion in this case is positive because apparently even some of
those involved in the process did not understand the proposal they
agreed to.  But we also do not want to make a fix that hurts those
who have been waiting for this change and are abut to make use of the
new functionality.

So we decided to do a quick and *very* ugly fix: We will leave recursive
querying active.  But in the case of finding a parent domain the result
will be determined by the content of the object found: if it is a
referral, the query will be referred as before; if it is a normal
(non-referral) object, the answer will be "no such object" as before the
change.  While addressing the problems raised by a few users this will
not hurt those planning to use referral based on recursive querying. 

Anyone with half a background in computer science and anyone with a bit
of intelligence will tell us that name scoping dependent on content of
the object named is a bad idea.  We agree!  This is why this fix will
only be kept up until the next RIPE meeting when the proper process can
determine the permanent soloution.  If the database WG can ome to a
conclusive decision before the RIPE meeting we will implement it
earlier.  We also do not expect to modify this fix further based 
on anything other than a decision based on proper process. 

We will also set up a special announcement list via which those not
participating in the policy developemnt process can be notified of
changes.

Kind regards

Daniel Karrenberg 
RIPE NCC Manager