[ncc-services-wg] Re: [db-wg] "referral-by:" attribute

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 at 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
>
>
>