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

On 2016 May 11 (Wed) at 19:27:05 +0200 (+0200), denis wrote:
: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.

Thank you for the history lesson!  As someone new to the WG I appreciate it.


: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.

Sigh.  Ok, thanks for this information.  Do you recall roughly when that
was decided / proposal?  I'd like to look at the discussions and
(possibly) submit a new proposal.


: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.

For those members that are NOT part of the WG, where are these important
changes documented?  How should non-WG members get updated?  Remember:
there was no announcement of this change outside of the WG.

And yes, I _am_ that person that yelled about RIPE changing my objects
this time, and it did bother me.  I was even more bothered by randomly
discovering the change, instead of it being communicated (either by an
announce mail, or by a notify email).  My inital reaction was not that
this was a thing done on purpose, but was caused by corruption or bad
actors.


: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.

If you mean "don't change the objects, just change the rules", I 100% agree.


: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.

That is sad, but the technical reality is relevant.

A pity, because the compromise seemed palatable to most people.


: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?

What should the WG do, then?  Ask the NCC to write new code?  Update the
data-model?


-- 
It is better never to have been born.  But who among us has such luck?
One in a million, perhaps.