New RIPE NCC reverse delegation procedure

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