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