Olaf, On Mon, Oct 06, 2003 at 03:58:13PM +0200, Olaf M. Kolkman wrote:
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.
As you saw from my previous mail, if we decide to go the 'domain:' object way, let's get rid of the 'rev-srv:' attribute at the same time. I would like that to be part of the proposal. This whole 'rev-srv:' versus 'domain:' confusion has already lasted for such a long time that it is time to clear it up.
(...)
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:
Ok, but as you mentioned this gives problems with PGP. This is in my opinion a serious problem since this is the only real secure way to enter data in the database. Security is even more important if we use the data for actual operational purposes instead of informational purposes in contrast to all other registry data (with the exception of the routing registry part of the database). It is a real change from current procedures to use something from the RIR database for real operational purposes. It is also a departure of our policy of not rewriting users data. I am not sure whether that is a good thing. Rewriting and making a small correction to users input is one thing, expanding from one object to 16 or even more different objects is quite another. Don't be surprised if users are getting confused why they cannot find the range notation objects that they thought they just entered in the database.
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.
This is a very good point. However, I am not sure whether it is a good idea to overengineer a solution for a thing that we possibly might be doing in the future. I can probably be convinced if there is actually a concrete project plan that we can discuss for adding DNSsec.
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.
I think myself that using the database is probably the right way to do it but I am not really sure either. I do think that a bit more discussion on this list will help to determine that this is really the case. Doing a reverse delegation is a relatively easy transaction and the proposal that is currently on the table adds a tremendous amount of extra complexity to the database and the request process. I am not convinced that there are no alternate ways to make the life of the users easier (that can or cannot include the database). Doing the reverse delegation over a secure webinterface where one only has to choose for which allocation the reverse delegation has to be changed and entering a couple of servers comes to mind. I am afraid, despite my fondness for the database, that it will only get into the way of people doing their job. I have seen too many companies deciding that they wanted to have a uniform way of dealing with their company systems and they end up with this beautiful all encompassing SAP (or whatever other vendors) system and people have to become an expert in the system before being able to do relatively easy transactions. For example, simply using the 'rev-srv:' attributes and retiring the 'domain:' objects seems a lot easier for the user. Yes, there is the disadvantage of different administative responsibilities inside larger local registries that could make this more difficult in certain cases, but this should balanced against the much greater ease of use. In addition, there are solutions possible that can address this fairly easily like adding a 'mnt-rev-srv:' attribute that allows the 'mntner:' to only change the 'rev-srv:' lines and nothing else. And the good thing is that this is completely optional so it doesn't interfere with people who want to do it the easy way. David K. ---