Announcement to DB-WG

>From experience on/with previous RIPE meetings my conclusion was
that the DB-WG didn't accept decisions made by the DNS-WG on the
Domain object. Which is why I sent my "explosive" announcement to
the DB-WG only (and to the NCC). But that means some people who
are in de DNS-WG, but not in the DB-WG, have missed it.
So just for completeness and FYI, I'm including the complete text
of the message I sent to the DB-WG and the NCC. I think the text
speaks for itself.


	Piet

-----------------------------------------------------------------

To: ncc at ripe.net, db-wg at ripe.net
Subject: Announcement
Fcc: RIPE

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.                    *
**********************************************************************

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 admin-c>
  *st: <status> ("MX-only" or "delegated")
  *dr: <date of registration>
  *dc: <date of last change>
*) 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.