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