[db-wg] RIPE Database: Cleaning-up Organisation Names in "descr:"

HI all

Sorry guys but these sort of discussions really do bring tears to my 
eyes. I know you guys are out there on the front line of the internet, 
running businesses and the RIPE DB is only one small part of that 
process for you. So I can't blame you for forgetting the details of why 
things were done the way they are and the discussions at the time some 
features were implemented. That was why the RIPE NCC used to have people 
who maintained a collective history to remind you. But I can and do 
blame you for closing your eyes, covering your ears and burying your 
collective heads in the sand about moving forward technically.

OK one point at a time. When "last-modified:" was discussed and agreed 
it was agreed by consensus that it would reflect user modifications. 
When database syntax or semantics changed or when policy changes 
required bulk updates of data across many users, possibly involving 
thousands, tens of thousands or even millions of objects, it was agreed 
that this sort of database management change would be done silently, as 
far as the database system is concerned, but talked about more generally 
on these lists. For that the RIPE NCC implemented an internal update 
process that allows the normal notifications to be suppressed and the 
"last-modified:" attribute not to be updated.

If the RIPE Database is important to your business then you should keep 
up to date with important changes. But we all know most users don't. So 
when they receive a notification showing their data has been changed a 
common reaction is to scream at the NCC about 'someone' changing their 
data without their consent. When the number of objects changed is very 
large that can cause all sorts of problems for the NCC.

There is also the issue of the NCC sending out so many emails which gets 
detected and the NCC sometimes gets blacklisted as a potential spammer.

So I recommend that you keep to these original guidelines and don't send 
out notifications and don't update the "last-modified:" attribute. It is 
not a user instigated change and the actual change is administrative 
rather than changing operational data. So knowing about this change 
doesn't really tell most people anything useful.

As people have pointed out, this update will most likely be done by the 
NCC one individual object at a time. If you want notifications, one 
email will be generated for every object that is modified. If you have 
lots of resources you will get flooded with these emails.

The compromise some have mentioned sounds good. BUT that is not how the 
database software works. One notification is generated for one update. 
This may be a single object and may be sent to multiple email addresses. 
The notification is standardised with boiler plate text and the addition 
of the object with a diff. There is no mechanism to add any additional 
explanation or to customise the notification in any way. You either get 
this or nothing. It is a simple yes or no.

If you want this compromise, the NCC will have to manage that external 
to the update processing. They will have to analyse all the objects to 
be changed, link them all to ORGANISATION objects, group them, find the 
organisations email address that might like to know about this change 
and send a single, composite email listing the objects that have been 
changed with an explanation. Not only can that be a very long list in 
some cases, but which email address do you choose? One from the 
ORGANISATION object, which may be administrative? Or one from a MNTNER 
or resource object's notify attributes? But there may be many different 
email addresses for organisations that have many resources. So there is 
an element of guesswork here choosing the 'best guess'. That always 
upsets some people as well.

So I will say it AGAIN. Even though I know, for some odd reason that is 
not obvious to me, none of you want to hear this, acknowledge this, or 
discuss in any way. The current, historic, out dated data model does not 
support a simple and useful compromise that you have suggested for 
managing notifications of a bulk update. Other than single sign on, 
users of this database have no user accounts where they can store meta 
data, choose options, customise or in any way make choices that affect 
how they manage their data in this database. There is no way for users 
to log into an account and access details of changes online, review them 
and maybe download the details if they wish. They either get a massive, 
long email, or lots and lots of emails....or nothing. Everything is done 
in a very static, hard coded way.

This is very old technology. Nothing is easy to change. Time and time 
again we hit these situations where the inflexibility of the data model 
and the static code on top of it prevents useful ideas being 
implemented. When are you going to take your collective heads out of the 
sand and admit it is long overdue for a serious review?

Not expecting any reply.....
denis

On 11/05/2016 18:23, Sander Steffann wrote:
>
>> Op 11 mei 2016, om 18:15 heeft Rob Evans <rhe at nosc.ja.net> het
>> volgende geschreven:
>>
>>> I would not mind if all the e-mail addresses which should receive
>>> a notification will receive only one regarding all of their
>>> resources.
>>
>> I like that idea as a compromise if it lessens the support load.
>> “The following resources for which you are listed in the ‘notify’
>> attribute are about to be modified” with a list of resources.
>
> +1 Sander
>