Domain object template

Hello, a couple of additions to the discussion:

>  *    Can we please drop the possibility of allowing IP numbers here?
>  *    If one of the secondaries of your domain changes IP number, then
>  *    he has the nearly impossible task of finding all these outdated
>  *    references. Bind only allows hostnames here; I think it is a good
>  *    idea to restrict the database in the same way.
>  *    
>  * => IP numbers were allowed in the previous template then we need
>  * a general agreement before dropping this possibility...
>  
> Perhaps we should try and completely overhaul the domain object? Why
> would we go for small changes when we may need major changes?

I somehow agree with the positions Geert Jan and Marten gave, a complete
overhaul is probably needed and especially the nserver, IP-address
idea was much discussed the last time at the RIPE meeting in Amsterdam
(May 1994) with the idea that there is a much more useful place to store
it - BIND !

On the other hand there is maybe one useful point to IP-numbers here, for
a domain abc.zz with a set of nameservers ns1.abc.zz and ns2.abc.zz which
have lost connectivity - a very bad situation, I agree - it might be
helpful to find there IP addresses here as well, so I would propose to
use it only for nserver within the specified domain.

domain: ABC.zz
descr: ABC company
....
nserver: ns1.abc.zz   194.205.120.3
nserver: ns2.abc.zz   194.205.120.6
nserver: ns.domain.my
nserver: foo.bar.com
...

Giving the primary first is probably a good idea, but what about 'hidden'
primaries. It is I think a common situation for organisation behind a
dial-up connection administering there own nameserver (as given in the
SOA) with only a set of secondaries published as NS-RR's. This cannot be
documented - if one wants to - this way, but maybe with a useful remark:


>  * => there is a loose binding between names and addresses.
>  * This attribute can be used if someone'd like to describe it.
>  * This attribute has been made optional then you use it only
>  * if you like.
>  
> Hmm, personally I'd bin the attribute.....

I think that most of the attributes made optional instead of obsolete 
could be seen as a compromise we can agree upon as a transitional step 
until the complete overhaul - if not achieveable at this meeting ?

>    > admin-c: The admin-c attribute contains the name or the  NIC
>  
>    I suggest to make mandatory that the administrative contact
>    should reside on the site itself. Assume that people have outsourced
>    the 'technical stuff' of their network, then it is likely that the
>    technical contact is someone belonging to another company, and
>    it might be difficult to get in touch with the holder of the 
>    domain itself because the address/phone number is different.
>    
> => the admin contact for domains is different from the admin
> contact for networks. It is explicitely an administrative
> person who can answer to questions about name property,
> legal problems, etc... In fact I understand your problem
> but I believe the change should be done in the network
> template.

I totally agree with Geert Jan here, the admin-c should be from the 
organisation using domain and should be changed if he no longer represents
this organisation. I didn't follow the discussion but heard some rumors 
about mtv.com but this way might be a good start. You have to have the
organisation's address and at least one phone number somewhere.


Another but important aspect I think would be to find a better (more up to 
date) example, if it should convince and educate new registries. The current 
one contains a number of factional errors (I'll append the correct entry at
the bottom of this posting) and some discrepancy to it's own explanation
for instance the format of the change dates not in format YYMMDD.

Finally with the handles and names as key values for person objects 1.2
could be reformulated.
Before entering or updating person objects the database should be checked
for existing entries which were created as references of other objects
(inetnum,...). Care should be taken to keep them up to date, without 
generating duplicate entries one with and one without a handle. I did it 
a number of times myself when I started using handles so please don't take 
it as an accusation to anybody. On the other hand the advent of ripe handles 
gives us the proper way to create different objects for one person where
necessary - e.g. if he has his own domain at home and supports a number of 
networks or anything else at work.


--------------------------------------------------------------------------
domain:      uka.de
descr:       Universitaet Karlsruhe
descr:       Informatik Rechnerabteilung IRA
descr:       Am Fasanengarten 5, D-76128 Karlsruhe, Germany
admin-c:     WZ5-RIPE
tech-c:      KB49
tech-c:      AN45
zone-c:      KB49
nserver:     iraun1.ira.uka.de
nserver:     iraux1.ira.uka.de
nserver:     ns.germany.eu.net
nserver:     ns.nic.de
sub-dom:     ira
dom-net:     129.13.0.0 192.54.104.0
mnt-by:      DE-DOM
changed:     nipper at ira.uka.de 910208
changed:     knocke at nic.de 941121
source:      RIPE
 
person:      Werner Zorn
address:     Universitaet Karlsruhe
address:     Informatikrechnerabteilung
address:     Am Fasanengarten 5
address:     D-76128 Karlsruhe
address:     Germany
phone:       +49 721 608 3981
fax-no:      +49 721 699 284
e-mail:      zorn at IRA.UKA.DE
nic-hdl:     WZ5-RIPE
mnt-by:      DENIC-P
changed:     dfk at cwi.nl 900411
changed:     rv at Informatik.Uni-Dortmund.DE 930704
changed:     knocke at nic.de 941121
source:      RIPE
 
person:      Klaus Becker
address:     Universitaet Karlsruhe
address:     Informatikrechnerabteilung
address:     Am Fasanengarten 5
address:     D-76128 Karlsruhe
address:     Germany
phone:       +49 721 608 3973
fax-no:      +49 721 699 284
e-mail:      becker at ira.uka.de
nic-hdl:     KB49
mnt-by:      DENIC-P
changed:     nipper at xlink.net 940406
changed:     knocke at nic.de 941121
source:      RIPE
 
person:      Arnold Nipper
address:     NTG Netzwerk und Telematic GmbH
address:     Geschaeftsbereich XLINK
address:     Vincenz-Priessnitz-Str. 3
address:     D-76131 Karlsruhe
address:     Germany
phone:       +49 721 9652 0
fax-no:      +49 721 9652 210
e-mail:      nipper at xlink.net
nic-hdl:     AN45
changed:     nipper at xlink.net 940616
source:      RIPE