Dear Working Group, we intend to rewrite the software that we use to automate reverse delegation requests, with the (main) goals: - simplify/improve the request procedure - maximise automation to keep resource demands reasonable e.g. improving our internal system, including, for example, IPv6 automation - improve the maintainability of the software There are several issues which come up with regard to the request procedure. I've outlined some of our *intentions* below in the hope of soliciting feedback. ---> Requesters will only need to write to a single automatic mailbox <auto-inaddr@ripe.net>, to request reverse delegation. Database update will take place automatically once all other checks are passed. + simplifies and speeds up procedure ---> If we attempt a zone tranfer to check that the contents of a zone are syntactically correct and consistent with other nameservers, and the transfer fails, we will not reject the request. We will check all of the data which can be queried without a transfer. + many zone administrators are very happy. - we cannot check some of the zone contents for problems. However, we think that the information we can collect without the transfers is sufficient to decide whether the delegation itself is well setup, even if it's contents are not. [Note: zone tranfers to our network will still be *required* to be enabled for reverse /16 zones, since we will continue to require that ns.ripe.net be included as a secondary for these zones.] ---> It will be mandatory that a registry ID is included in all requests for reverse delegation, as is currently the case for requests to <hostmaster@ripe.net>. We will require that all requests come from an LIR receiving service (i.e. paying for services), and that the requester is one of the registry contact people/ contact role-account. + resource efficient. We only deal with people who are experienced in the reverse delegation procedure and aware of the RIPE NCC and RIPE DB procedures in general -> minimal time explaining procedure and general registry system concepts. Currently we spend much time dealing with inexperienced end-users who will set up only one or a few zones and therefore do not spend the time to become knowledgable concerning the procedures. + fair to paying members. We do not spend time guiding people who do not contribute to the costs. ---> We will only accept requests in the form of a RIPE DB domain object (as opposed to also accepting inetnum objects). + uniform update procedure for all types and sizes of zone, procedure becomes much clearer, confusion and doubt are banished. + removes possibility of 3-way inconsistency between domain objects in the RIPE DB, inetnum objects in the RIPE DB and the corresponding zone file delegations. + clear to users of DB in what type of object they need to look for contact info on the zone. + removes problem where errors in a single reverse zone of a corresponding large inetnum mean the whole inetnum has to be resubmitted, - for requests involving large numbers of zones lots of domain objects will be needed. We'll lessen this by making possible a shorthand domain object like this: domain: x-y.w.z.in-addr.arpa This will result in all reverse zones x-y being delegated (upon success), and x-y domain objects being entered in the database. This option will only be possible for corresponding address space which is occupied by a single inetnum object, to reduce the possibilty of misuse/mistakes. Thanks in advance for any input, Lee Wilmot RIPE NCC