David and others, I've put comments in-line. On Fri, 3 Oct 2003 16:27:41 -0700 David Kessens <david@iprg.nokia.com> wrote:
Olaf,
On Wed, Oct 01, 2003 at 05:39:28PM +0200, ext Olaf M. Kolkman wrote:
- The introduction of a new attribute, "mnt-domains:", in INETNUM and INET6NUM objects to be able to delegate the authority to create new domain objects.
Does this mean that the 'rev-srv:' attribute will be retired too ?!?
the "rev-srv:" attribute has been retired for the purpose of requesting reverse delegation. E.g see: http://www.ripe.net/ripencc/faq/reverse/qa2.html#14: What are those "rev-srv" lines in an inetnum object for? Previously, delegation requests could be made using either an inetnum object or a domain object. We discovered several problems with this, one being inconsistency of the two possible sources. Requests are now only accepted via domain objects, so you must register your reverse servers only in the domain object. If you're changing a reverse delegation and find rev-srv lines in the corresponding inetnum object in the RIPE DB, you must create a domain object and you should delete the rev-srv lines from the inetnum. (...)
This proposal also means that one has to submit for example 16 reverse delegation objects to do a reverse delegation of a single /20.
To request delegation ranges you can use the "y-x.z.w.in-addr.arpa" notation. This only works for "3rd" octets and there are problems when using this update method in combination with PGP (will be fixed during the migration to the WHOIS interface). Documentation on the range-update feature cannot be found on the web. It used to be part of the documentation, but fell through a crack at some point. We will be reviewing the documentation as part of the project but will fix this omission soon. In the mean time, this is the relevant piece of documentation: http://www.ripe.net/reverse/howtoreverse.html#ranged-domain The range-update is also part of the LIR training curriculum: http://www.ripe.net/training/lir/material/slides/page97.htm (...)
In fact, there is actually very little use for doing the whole thing in the RIPE database in the first place. I haver never found any use at all for looking up one of the in-addr.arpa objects in the database. Maybe we should even think about retiring the 'domain:' objects and 'rev-srv:' attributes altogether and offer a simple secure web or mail user interface for submitting reverse delegations.
We need an interface to 'transport' reverse zone information; now only nameserver attributes but in the future also DNSSec key attributes. Our "philosophy" when drawing this proposal is to provide our customers with uniform interfaces to deal with the RIPE NCC. By having one data-store, that comes with authorization mechanisms and a well defined API we are able to develop multiple interfaces to it; currently we have a mail and a network interface to the WHOIS database, web-portal functionality is being extended. Outside of the scope of this project, but this project enabling it, is the idea of a web-interface to reverse delegation management. Which includes easier management for simultaneous updating of "y-x.z.w.in-addr.arpa" objects (e.g. the same contact info, ns, etc.). I hope this addresses you question and comments. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC