I've been following the recent umpteenth (...) discussion on the domain object in the RIPE database. I haven't commented on it though, since frankly I couldn't care less anymore. As NL domain registrar I have had - and am having - increasing problems with the *lot* of extra work caused by trying to keep the RIPE database up-to-date as far as .NL (primary) subdomains are concerned. For one thing, the - perceived or real, that has never become clear in all the discussions on the domain object - need to maintain information that is completely irrelevant for maintaining a domain administration is a hassle. But it's far more a nuisance that the RIPE database has "person" objects that in itself are an absolute kludge, in that they are invisibly related to in any other sense completely unrelated things like network objects and domain objects. The mere presence of these objects in the RIPE database gives the impression that RIPE is trying to keep sort of a worldwide phone directory, but then a "gambling" one: whether or not one will find a person in it is pure luck: you'll find it if the person happens (or happened!) to be related to a network or a domain object, otherwise not. A random generator would do about as well... The person object, because of its linking to different other objects, is also a nuisance in another respect: it calls for the need of "handles", where there is no such need whatsoever if the NL domain administration would be maintained completely seperate from the [setup of the] RIPE database.

From the above it should be clear that, as NL domain registrar, I'm sick and tired of all the extra work caused by the "feed" given to the RIPE database. I want to strongly emphasize here that there in NO OBLIGATION whatsoever for any [top level] domain registrar to "feed" the RIPE database and/or to keep the administration of the domain in accordance with or modeled after the RIPE database.

What I'm saying below is therefore an OFFICIAL STATEMENT, and NOT a call for discussion. Included in it is an invitation to the RIPE NCC - as maintainers of the RIPE database and of the related software - and to the DB-WG, for a change in the setup of the database and software. I probably won't be far off if I'm saying that I think that I'm not the only [top level] domain registrar having problems like the ones described. I'm willing to illustrate and discuss on the forthcoming RIPE meeting the sort of problems that the current setup of the RIPE database is posing, even though I've done the same on previous RIPE meetings (albeit in the DNS-WG then). But it should be very clear that this will *not* lead to revoking the statement below and the actions announced in it. The time of endless discussions is really over. I have to "spit in the hands and get to work", without the work being hampered by external factors and matters of taste (which for a large part dominate the whole discussion on objects in the RIPE database). Piet ********************************************************************** * The NL naming authority is planning to change the setup of the * * NL domain administration, to make it possible to keep up with * * the ever increasing number of domain registrations, without an * * unnecessary amount of work posed by "external factors". * * Such an "external factor" is the regular feed of the RIPE whois * * database with complete .NL (primary) subdomain info, calling for * * the need of maintaining in said administration information that * * is not relevant for the purpose of said administration, but only * * for the "external factors". * * Because of the above mentioned change in setup, the information * * in the NL domain administration will no longer be compatible with * * the "domain objects" and "person objects" in the RIPE database. * * Feeding the RIPE database with said information will therefore * * stop. Thereafter anyone is free to enter .NL subdomain objects * * (in fact that's the case already, since there is no protection * * against entering such objects - only against changes), but it * * should be very clear that from the viewpoint of the NL domain * * registration such entries are NOT authoritative. * * * * The NL naming authority recognises the value of a whois service. * * Therefore the NL naming authority will make sure that a whois * * service for .NL (primary) subdomains will be provided, through * * a whois server [to be] set up by the NL naming authority. * * The NL naming authority at the same time recognises that the * * RIPE whois server is known worldwide and that people have come * * to rely on it. Therefore an invitation is enclosed below to the * * RIPE NCC - and to the DB-WG - for a change in the database and * * its software to make it possible that the "RIPE whois service" * * is maintained, with automatic referral of the NL domain info * * on requests for such info. * * * * As soon as the mentioned change of setup has been completed and * * the mentioned whois server made operational, all .NL subdomain * * objects will be removed from the RIPE database, leaving only a * * "minimised" entry for the NL top level domain itself, which will * * then look as follows: * * *dn: nl * * *de: Top level domain for the Netherlands * * *rm: Information about .NL (primary) subdomains can be * * *rm: obtained with "whois -h <server_name>.nl <domain>.nl" * * * * As mentioned above, here is an invitation for a change in the * * RIPE database/software to automate the referral to NL domain * * info on queries directed to the RIPE whois server. Described in * * RIPE database format, after the change of the database/software, * * the "minimised" entry for the NL top level domain would be: * * *td: nl * * *de: Top level domain for the Netherlands * * *ws: <server_name>.nl * * The "ts" attribute would signal this entry as a top level domain * * to the db/whois software, causing forwarding of the query to the * * listed whois server for both the top level domain itself and for * * any <domain>.nl query. This shouldn't sound unfamiliar: it's an * * almost complete analogon of DNS, with the exception that RIPE is * * not "delegating" any top level domain. * * This change/addition has been proposed to the RIPE NCC a couple * * of months ago already, but has met with no reaction whatsoever. * * This announcement is therefore also meant to evoke a reaction * * from the RIPE NCC on this issue/proposal. * * It is clear that the above construction introduces a completely * * new element in the RIPE database/software: an entry for a top * * level domain (NL) implicitly standing for subdomains (*.NL) of * * it. So it might not be trivial to implement it. Still we think * * the RIPE NCC people will be able to handle it. * * * * * * Signed: NL Naming Authority <hostmaster@cwi.nl> * ********************************************************************** For your information, I'm adding here what the NL domain administration will look like after the changes, in "RIPE database notation": *dn: <domain name> *on: <organisation's name> *cc: <Chamber of Commerce registration number> *ad: <organisation's location address> *) *ac: <admin-contact> *ph: <phone of admin-c> **) *em: <e-mail of admin-c> *tc: <tech-contact> *ph: <phone of tech-c> **) *em: <e-mail of tech-c> *st: <status> ("MX-only" or "delegated") *dr: <date of registration> *dc: <date of last change> There can be more than one tech-c. *) P.O. Box is *not* (since 1-1-95) accepted here. **) Fax number might be added, but the value of it seems next to zero, given that some 80% of all registered NL subdomains don't list a fax number of contact persons. That's all. An entry with all the really *necessary* information for the domain administration, without irrelevant bells and whistles. Things like nameservers are not included in an entry: that's information that belongs in and is entered in DNS, i.e. the NL zone file. If people feel the need to find that information, then there are plenty of tools (dig, nslookup, host) to find it in DNS. The *st field in the administration gives an indication of what can/should be expected there. If people are too lazy to query DNS, they're not interested in the information. Period. One note: some of the fields given above will not be presented on queries to the NL whois server; *cc is one of them, probably also *dr and *dc. Other fields may be added at any time, as need arises. It should be clear that the setup eliminates any need for a "handle". Sure enough, this change will also have the effect that there will be no more automatic "notification feedback" from the RIPE database in case the data of a person change. But that happens so rarely that I can live with that. Besides, changes pertaining to an NL (primary) subdomain *must* be sent to the NL registrar, not to RIPE.