New RIPE NCC reverse delegation procedure

  Hi Lee!

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

  My 1st reaction: this requires a bit more thinking
  
  - the people (individuals) running the address assignment business 
    are not necessarily the same persons which deal with DNS. Maybe they
    should, or the DNs folks should be added to the LIR contacts just for
    that purpose, but this requires a reality check and procedure review,
    I suppose?
    
  - between the lines, also, this states that users of address space
    obtained from LIRs which have been closed for one reason or another
    cannot get RevDNS services set up and/or changed - unless you provide
    some loopholes.
    I don't have an opinion about good/bad, it's just an observation.
    
>     - 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.

  Uhh, ohh, this might be a non-starter (the single inetnum object, not
  the idea in itself). I like the intent, but again this requires a review
  of other procedures (or customs) in some places.

  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
  Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
  Vienna University              :  Fax: +43 1 4277 - 9 140
  Universitaetsstrasse 7         :  RIPE-DB (&NIC) Handle: WW144
  A-1010 Vienna, Austria, Europe :  PGP public key ID 0xF0ACB369
 __________________________________________________________________________