"referral-by:" attribute
Dear Colleagues As a first step to clearing up long standing issues that cause confusion in using the RIPE Database, we would like to propose making the "referral-by:" attribute optional in maintainer objects. Historically maintainers were strictly controlled and users had to apply to the RIPE Database administrators to get one. This was created and "referral-by:" referenced ripe-dbm-mnt. The RFC for RPSS allowed for maintainers to be able to create other maintainers in this controlled world. The "referral-by:" attribute was intended to be an audit trail back to the root maintainer creation. This was never implemented in the RIPE Database software. Since the strict control was relaxed, we have always advised that "referral-by:" references itself. It is a redundant attribute that confuses new users. When we set up AfriNIC, they asked us to drop this attribute completely. If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way? Regards Denis Walker Business Analyst RIPE NCC Database Group
Denis, On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely. I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary. -- Shane
On Jun 8, 2010, at 5:54 AM, Shane Kerr wrote:
On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
I agree with Shane. Let's clean up after ourselves. Regards, Leo
On Tue, Jun 08, 2010 at 02:54:48PM +0200, Shane Kerr wrote:
On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
I agree with that point of view. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Shane Kerr wrote:
Denis,
On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
If it doesn't dere a purpose any longer, yes, I agree.
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
But I don't beliee in messing around with the users' input and (more or less silently) throwing away part of their submitted data.
-- Shane
IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time. I'm sure the DB guys can refresh our memory regarding the specifics. Wilfried.
Wilfried Woeber, UniVie/ACOnet wrote:
Shane Kerr wrote:
Denis,
On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
If it doesn't dere a purpose any longer, yes, I agree.
It never served any purpose as no code was ever written to check this audit trail.
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
But I don't beliee in messing around with the users' input and (more or less silently) throwing away part of their submitted data.
-- Shane
IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time.
I'm sure the DB guys can refresh our memory regarding the specifics.
I would suggest a first phase to make it optional. Then users can stop including this attribute and, in their own time, adjust any scripts they have for generating MNTNER objects and slowly remove them from their existing maintainers. We could also include a Warning message whenever this attribute is included to say it will be deprecated soon. Then after some time, deprecate the attribute, change the syntax rules and do a bulk cleanup to remove these attributes from any old maintainers. Regards Denis Walker Business Analyst RIPE NCC Database Group
Wilfried.
On 8 Jun 2010, at 15:55, Wilfried Woeber, UniVie/ACOnet wrote:
Shane Kerr wrote:
On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way? I'd actually suggest going further, and getting rid of it completely. If it doesn't dere a purpose any longer, yes, I agree.
I agree, let's do this. [...]
IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time.
I'm sure the DB guys can refresh our memory regarding the specifics.
This sounds like the way forward with regards to implementation too. Andy
Wilfried, On Tue, 2010-06-08 at 14:55 +0000, Wilfried Woeber, UniVie/ACOnet wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
If it doesn't dere a purpose any longer, yes, I agree.
Yay! We agree!
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
But I don't beliee in messing around with the users' input and (more or less silently) throwing away part of their submitted data.
Boo! We disagree! ;) In principle your view makes sense, but if we think about what is actually happening for the user, I tend to disagree. We can either have the following: 1. User submits a modification to the database 2. Database rejects the update and explains exactly how to fix it 3. User fixes the update 4. User re-submits the update 5. Database performs the update Or: 1. User submits a modification to the database 2. Database fixes the update 3. Database performs the (modified) update We're not talking about a substantive change - we're talking about a trivial modification that can be done completely correctly by a machine every time. I consider this somewhat akin to what happens now when you put a trailing dot on the end of a Whois query: shane@shane-asus-laptop:~$ whois -h whois.ripe.net 193.in-addr.arpa. ... %WARNING:906: trailing dot in domain query % % The key has been changed to "193.IN-ADDR.ARPA" for lookup. This is another case where we know what the user wants, make a trivial change to their input, and execute the correct command for them. We also tell the user, so they know exactly what is going on, and can change future input as necessary. I think this is a good model to follow. (Full disclosure: I think I wrote the warning in the lookup code.)
IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time.
For reasons above, I prefer to avoid a phased introduction with warning followed by rejection. It adds burden to the RIPE NCC and to database users, with less benefit than just Doing the Right Thing. -- Shane
Hi Shane I tend to disagree with you on this Shane. In principle I like the idea of software correcting 'obvious' mistakes. But how do we define 'obvious' and do we do this forever because no one learns from 'always corrected' mistakes? We implemented code to remove the trailing dot on rDNS objects about 5 yaers ago. We are still receiving objects today with trailing dots. Because we diligently do this for users no one bothers to fix their scripts to submit valid input. Yes we can do this again and again and again...with more fixes on this and that and the other. We will end up writing lots of functions to fix many variations and what we end up putting in the database will only vaguely match the user input. With the trailing dot we do know what the user wants. If we start adding more and more of these fixes will we really know what the user wants? Or is it better at some point to reject it and ask the user to fix it? In this case we are removing an attribute that has never been used and still confuses people. In 5 years time we don't want users to still be submitting data that they do not understand simply because we allow it and 'fix' it for them. Your analysis of the user experience is not quite right. In the first phase we have two options to make life easy for the user. Either we make the attribute optional and warn users if they use it, telling them it will be deprecated soon. Or we 'fix' it by removing the attribute and warn the user we fixed it. BUT we put a time limit on this phase. After that phase we would reject updates containing this attribute. regards denis Shane Kerr wrote:
Wilfried,
On Tue, 2010-06-08 at 14:55 +0000, Wilfried Woeber, UniVie/ACOnet wrote:
If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way?
I'd actually suggest going further, and getting rid of it completely.
If it doesn't dere a purpose any longer, yes, I agree.
Yay! We agree!
I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary.
But I don't beliee in messing around with the users' input and (more or less silently) throwing away part of their submitted data.
Boo! We disagree! ;)
In principle your view makes sense, but if we think about what is actually happening for the user, I tend to disagree.
We can either have the following:
1. User submits a modification to the database 2. Database rejects the update and explains exactly how to fix it 3. User fixes the update 4. User re-submits the update 5. Database performs the update
Or:
1. User submits a modification to the database 2. Database fixes the update 3. Database performs the (modified) update
We're not talking about a substantive change - we're talking about a trivial modification that can be done completely correctly by a machine every time.
I consider this somewhat akin to what happens now when you put a trailing dot on the end of a Whois query:
shane@shane-asus-laptop:~$ whois -h whois.ripe.net 193.in-addr.arpa. ... %WARNING:906: trailing dot in domain query % % The key has been changed to "193.IN-ADDR.ARPA" for lookup.
This is another case where we know what the user wants, make a trivial change to their input, and execute the correct command for them.
We also tell the user, so they know exactly what is going on, and can change future input as necessary. I think this is a good model to follow. (Full disclosure: I think I wrote the warning in the lookup code.)
IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time.
For reasons above, I prefer to avoid a phased introduction with warning followed by rejection. It adds burden to the RIPE NCC and to database users, with less benefit than just Doing the Right Thing.
-- Shane
participants (6)
-
Andy Davidson -
Denis Walker -
Leo Vegoda -
Piotr Strzyzewski -
Shane Kerr -
Wilfried Woeber, UniVie/ACOnet