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