Domain object template

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

This is actually a naming policy issue, and as such this decision
may eventually rest with the administrator of each top-level domain.
I do however agree that adhering to this practice is a very good
idea indeed, and that we should strongly reocmmend it.

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

That the network template is broken is no excuse for not doing it
right in this document...  But I'm sure I misunderstood what you are
saying.

>    > nserver: The  nserver  attribute  contains   the   list   of
>    >          nameservers  for of this domain, primary first. The
>    >          format  is  fully  qualified  domain  name  without
>    >          trailing  "."  OR IP Address(es) of the nameserver.
>    >          Only one server should be described per  line.   An
>    >          example:
>    > 
>    >                  nserver: iraun1.IRA.UKA.DE
>    > 
>    >          Status: optional, multiple lines allowed
>    
>    Can we please drop the possibility of allowing IP numbers here?

Yes!  I'm all for it.  It has one disadvantage, though, in that
required glue information which has to be inserted in the zone file
doing the delegation currently has no place in the domain object.
Personally I do not view this as a great loss, it should however be
noted.

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

Indeed.

>    Also, we might add 'the first nserver listed is the primary for the zone'
>    
> => "primary first" is in the text.

Hmm, if I'm not totally mistaken, the concept of primaries and
secondaries is a BINDism, and the concepts are likely to vanish some
time in the not too distant future.  Thus, I'm a little reluctant to
mandate this usage.

>    > dom-net: The dom-net attribute contains the list of IP  net-
>    
>    Can someone please explain why it is useful to record this?
>    Seems that this info might get outdated quickly as it isn't
>    related to the domain _name_.
>    
> => 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.

This attribute is essentially unmaintainable and quite difficult to
check for as well (think about unannounced networks with no hosts
registered in the "externally" viewable DNS tree).  I think it
should go into the dustbin.


- Havard