...

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