New RIPE NCC reverse delegation procedure

Good afternoon Wilfried, and thanks for your comments.

 * >---> 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 co
 * me 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 experie
 * nced
 * >       in the reverse delegation procedure and aware of the RIPE NC
 * C
 * >       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 th
 * e
 * >       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?

That's one of the problems. The DNS people often don't know all of the
RIPE NCC's P&P's (policies and procedures) when they are not also
fulfilling the role of LIR contacts, and we spend quite a while trying
to explain everything with lots of mutual frustration.

The idea is only to make sure that the same people, whoever it might
be, are always the ones making the requests.

As you suggest, the DNS people could register as contacts with the
RIPE NCC, though perhaps with a slightly different status to the
address registration staff, after taking some time to familiarise
themselves with the basics of the address registration P&P's.

Please note that we already have had a similar (LIR contacts only)
setup for AS number requests for quite a while. These are most often
for customers of a registry, but the registry makes the actual
request.

In any case, Mirjam will bring this up in the LIR WG at the RIPE
Meeting next week for discussion.

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

The intention is that end-users whose LIR is not open for whatever
reason, would approach another LIR which -was- open. The reason being
that in these cases the end-users are otherwise forced to attempt to
make requests themselves, a source of frustration and resource burning
for both the RIPE NCC and the end-users (do you remember what it's
like reading the documentation from scratch ?). In addition, those
end-users are receiving services which are being paid for by the open
registries.

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

Could you explain or give examples of why this would have
ramifications for other procedures in place ? Is your concern
non-uniformity of notation, in the sense that people would be tempted
to also send such shorthand notations to the database software, for
example ?

Lee