Olaf, On Wed, Oct 08, 2003 at 11:50:56AM +0200, Olaf M. Kolkman wrote:
David wrote:
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.
I agree "Clarity good, Confusion bad". I have not yet had the change to study all implications of getting rid of the "rev-srv:". But we'll look at this and get back on this issue; probably in the clean-up proposal that is to follow or in a separate proposal.
very good.
I may not have explicitly mentioned this but in the new system PGP will work in combination with the "range" update. (Technical detail, now the authorization checks are done after the objects have been split and individually processed, in the future the authorization check will be done first and then the objects are split to to further checks). Note also that not only PGP will work with the proposed setup but users will be able to use the consistent authorization model of the RIPE DB.
That is exactly why I think the RIPE database might be a good place. However, if we use 'rev-srv:' attributes instead of 'domain:' objects, we can still use this model without the need to rewrite users data.
As for using WHOIS directly to generate zone information, you hit the nail on the head, this is a real change.
And an important one. Not all database security mechanisms in use are good enough for this new purpose. They might be good enough for publishing data for informational purposes, they are not good enough to make actual changes to configurations.
However, we currently use the domain objects to maintain reverse delegations. Those domain objects do end up in the database while simultaneously updating zone files. So if everybody would use the proper interface to update domain objects than we would have full consistency. So when implementing the proposal we loose the ambiguity in the update path, we get consistent WHOIS and ZONE data. Besides we gain access, and use of new authorization mechanism that become available to the database (e.g. X509).
Yes, that is certainly useful. However, we would also get full consistency if we got rid of both 'domain:' and 'rev-srv:' attributes and use a simple specialized interface to do reverse delegations. The DNS is already a fully public database. There is no need to keep the data in yet another backend database or publish it in more than one place. I think the focus should be on the people who use the interface: we need to choose the most simple and easy way for the user to get the job done. The goal is not to make a complicated interface and declare victory because we have reached data consistency!
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.
I am not in the position to judge if this will be a problem. I hope and think the mechanism of the range update is documented well enough that users will know that the range update is "synthesizing multiple updates".
Rewriting users data is messy and should be avoided if there is other alternatives available. There is all kind of possible problems that one can come up with and you will find more when you start doing this in practise. To give another example: - Somebody sends in: 3-10.193.in-addr.arpa - Next, requests a change to: 4.193.in-addr.arpa - Next, somebody requests a deletion of: 3-10.193.in-addr.arpa Should the deletion fail since 3-10.193.in-addr.arpa is actually many different objects and one of them is not the same anymore so in fact there is really two sets of different objects ?!? This kind of things can be solved by applying (or implying) more rules and this will result in making life more difficult for the casual database user because one has to go first to a three week training class before one is able to interact properly with the RIPE database.
David wrote:
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.
Reading and open to suggestions see however the next point.
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).
There might be other mechanisms. But our requirements for the current proposal were minimal changes to the end-user and minimizing the amount of different back-end databases we have to maintain. It is hard to put hard numbers on these things but less complicated systems lead to less costs.
And that is exactly my problem with it. I don't think that the 'minimal changes to the end-user' is the right requirement. The right requirement is to make things as easy as possible for your customers. Doing reverse delagations with 'rev-srv:' attributes seems a lot easier to me (I prefer this option). There is no need to rewrite objects. And one can reverse delegate whole blocks at once by doing a single simple submission without a need to learn any complications like 'range' notations for domain objects. But as an alternative, I think not using the RIPE database at all can possibly be even easier (and there is no need to have multiple backend databases either, the DNS works just fine for that). And there are pretty good arguments for this too: the database allows one to submit objects that are lower in the delegation tree and they will be ignored because there are already delegations in another part of the tree. This points in the direction that neither 'inetnum:' objects or 'domain:' objects are the right datamodel to this. Again, this can solved by adding rules, but it adds complexity and in the mean time, the user will be confused because the user didn't read the 50 page database manual before requesting the reverse delegation.
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.
It strikes me that this example as remarkable similarity to the current proposal. Both use the DB for storage of reverse information and both use a new attribute to delegate authorization for updating specific information.
Of course there is a lot of similarity because they are trying to accomplish the same thing. But only one of the proposals is the easiest and least complicated to use.
Most users have been using domain objects for years. I am not sure if deprecating those in favor of reviving "rev-srv:" is something those users are waiting for.
Yes, but did they have a choice ?!? They had to submit 'domain:' objects to get their reverse delegations done. No wonder they are more up to date (but still far from correct) than the 'rev-srv:' attributes. Again, the requirement is what works easiest for your customer, it is not: 'let's keep doing it the old way because people are used to it'. I think it is time for me now to take a step back and watch what other people like as the best solution. David K. ---