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