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

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