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