RIPE DB domain object

    Hello Francis,
    
>The discussion about the RIPE DB domain object is still open...
>
>I remind you of the current proposal:
> (mininal) change status of zone contact, name server, sub-domain
>and reverse-server (the last one in IP network object) from mandatory
>to optional.
> (medium) change status of this attributes to obsolete.
> (maximal) delete domain object and reverse-server attribute.

    my comments to the medium and maximal versions:

    I clearly don't want to warm up a discussion which I didn't attend,
    however, the current situation in Austria is, that both serviceproviders
    and IRs (ACOnet and EUnet) have finally agreed that it is worth the
    effort to register second and third-level domains in the RIPE database,
    and this is done already for all 2nd-level and for all new 3rd-level
    applications, cleanup of 3rd-level up to end of 1994. 
    
    Even if there are no tools actively using the domain-objects in the
    RIPE-DB, me as a human beeing and network-administrator is considering
    it as useful information !!!  I definitely LIKE the RIPE-DB and it's
    simple tools (WHOIS, WAIS), it's a great help for my daily work, so
    please don't lock out valuable information, just because it's not used
    by poppy auto-config-tools !!!

> - do you know a real domain where zone contact is not one of the
>technical contacts ?

    Yes: e.g. univie.ac.at  
    
    zone-c: Gerhard Winkler (is responsible for the nameservers)
    tech-c: Ewald Jenisch (is responsible for the router-network)

> - do you know a general tool using name server or sub-domain attributes ?
>(these informations are already available via the DNS then a strong
>argument in favor of these attributes would be a tool using them
>producing or checking the DNS. Another idea is a tool producing domain
>objects from the DNS automa{t,g}ically...).

    I would prefer a tool producing DNS-entries from domain objects.  When
    you are just including in the RIPE-DB the information already available
    in the DNS, it wouldn't make much sense. Again, even if there are no
    config-tools using the domain-object, human beeings ARE !  To enforce
    the administrative registration of a domain in the RIPE-DB you might
    consider a tool checking DNS, comparing it with the RIPE-DB and sending
    domain templates to the mail addr in the SOA if the domain is not
    registered or contains wrong nserver fields (of course this tool could
    do a DNS primary/secondary sanity check as well).

>Once again: this relates ONLY to DNS. If you think it's really
>necessary to clog the RIPE database with useless information
>(like nameservers; info that is present already in DNS), you
>have to come with good arguments. And please note that it is
>not forbidden for a [TLD] registrar to keep a *local* database
>with all sorts of additional info about a domain.

    If there definitely are no tools using the nserver information at all
    and the RIPE-DB has to safe a few kbyte disk space, for my sake drop the
    nsfields, but don't drop the whole domain-object !
    
    Regards
    Christian
    
 --- Christian Panigl        : Vienna University Computer Center  -  ACOnet ---
 --- VUCC - ACOnet           : -------------------------------------------- ---
 --- Universitaetsstrasse 7  : Internet:   Christian.Panigl at CC.UniVie.ac.at ---
 --- A-1010 Vienna / Austria :      Tel:   +43 1 4065822-383    (Fax: -170) ---