RIPE DB domain object

> Some important entries should be redefined:
>  - nserver (name servers): the new syntax should be:
>  (*) name [ (address)+ ]
>  with a star for unpublished (secondary) name servers,
Why restrict this to secondary servers ?
While it might really become a problem to hold this list up-to-date,
it is more important to have information about a probably hidden (or
"unpublished") primary server in the database.

>  fully qualified domain name of the name server and
>  the list of the IP addresses of the name server.
To avoid any duplication of information inside the db, this should probably
be done with DNS glue logic in mind: Specify the IP address(es) iff the
server resides inside the described domain. Having just the addresses does not
seem very readable to me, so the server name should be mandatory.
Further it might improve readability if we allow just one item per
*nserver: field. Any changes here imply changes to the *rev-srv: field
in the network object.

>  - sub-dom (sub domains): this entry should be either not present
>  or not empty. Domain names should be fully qualified (change).

How can I then interpret the list of "domains" shown by the sub-dom fields ?
Does it have to be a complete list of subdomains, if not empty ? How is
completeness determined in this case ?

To become concrete:
If I have a DNS object (2nd level domain in this case), e.g. for
Uni-Bielefeld.DE, which "subdomains" are to be listed in the sub-dom field ?
We have two delegated zones (==subdomains), some not-leaf subdomains (department
domains administered within the Uni-Bielefeld.DE zone) and their subdomains (in
fact, these are mostly the hosts) and even some leaf domains (mostly hostnames,
but also departmental "mail catchers") directly under Uni-Bielefeld.DE .
  Hostnames are surely not all candidates for the sub-dom (?), whereas the
delegated subzones are. What about the rest ?
I suggest to list a domain in the sub-dom field iff there is another domain
object describing this domain.

-Peter