Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
Hi Akil, working group, If we perform the clean-up that was proposed your organisation name will be removed from "descr:" in your resource objects. But note that this *only* applies to 'top-level' objects: i.e. allocations or assignments you received from the RIPE NCC - not e.g. assignments done under a PA allocation. And we only perform the clean-up if the "descr:" exactly matches the organisation name - that RIPE NCC was enforcing. You can already update the "descr:" for assignments (PI and ASN) you received. If you change the "descr:" to something other than the organisation name they will not be touched. Until now it has not been possible to update "descr:" for allocation objects. So if we would run the clean-up today that would mean that all allocation objects end up with no "descr:" attributes. You would however still be able to find your objects, because they have a reference to your organisation object (and your organisation object has your organisation name). We are currently working on deprecating the object editors, so you will be able to edit the "descr:" attribute for allocations within a few weeks from now. After this work is done, you will be able to update your "descr:" of allocation objects as well. As mentioned earlier the clean-up was reverted and has been postponed. We can run it again on 9 May, but only if the working group co-chairs call consensus. We can also postpone the clean-up until after the object editors are deprecated and people have had a chance to update the "descr:" on their allocation objects. We can also cancel the clean-up if the working group feels this is better. Kind regards, Tim
On 28 Apr 2016, at 16:07, AKIL EVLAT <AKIL.EVLAT@kktcell.com> wrote:
Hi,
Since you have no longer got descr available at your end. How would we refer to our IP block at your end?
Regards,
AKIL EVLAT KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 Lefkoşa / KKTC T: E: akil.evlat@turkcell.com.tr
-----Original Message----- From: AKIL EVLAT Sent: Friday, April 22, 2016 10:50 AM To: 'Tim Bruijnzeels' <tim@ripe.net>; ncc-announce@ripe.net; 'db-wg@ripe.net' <db-wg@ripe.net> Cc: BARIS KIZILDERE (BARIS.KIZILDERE@kktcell.com) <BARIS.KIZILDERE@kktcell.com>; TO-CO-PN <TO-CO-PN@kktcell.com> Subject: RE: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
Hi,
From what i understand no changes are going to be made that effects users and no actions have to be taken by the users.
But as KKTCELL we would like to know what will the name/abbreviaton change to. What will be the new abbreviations?
Are any of the users going to be effected in any way? Or is there such a risk?
Kind Regards,
AKIL EVLAT KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 Lefkoşa / KKTC T: +90 533 850 0175 E: akil.evlat@kktcell.com
-----Original Message----- From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Tuesday, April 19, 2016 5:17 PM To: ncc-announce@ripe.net Subject: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
Dear colleagues,
We want to let you know about a clean-up that we have been planning with the RIPE Database Working Group (WG) and explain why this is being done. As this is currently being discussed on the WG mailing list, there is still time to comment if you wish.
Background ----------------
For a long time, there has been a requirement that the first "descr:" attribute of resource objects that were allocated/assigned by the RIPE NCC must match the name of the organisation that holds the resource. However, these resource objects have also had a reference to the organisation object of the holder of these resources for quite some time, and the RIPE NCC ensures that this organisation object matches what we have in the RIPE Registry. This means that we have been using two parallel approaches to achieve the same goal.
Since we began using organisation objects, requiring the organisation name in the “descr:” attribute has become redundant. It creates the potential for a mismatch between the name recorded here and the name on the actual organisation object. It also leads to confusion about where the correct name of the organisation can be found, along with a number of other issues.
This has been discussed at length on the RIPE Database WG mailing list and during WG sessions at RIPE 70, 71 and 72. Consensus was reached that going forward: - Organisation names should no longer be enforced in "descr:" attributes - LIRs should be allowed to modify the "descr:” attribute[1] and will be responsible for maintaining this (it will not be verified by the RIPE NCC) - The RIPE NCC should clean up existing cases where the organisation name is enforced - "descr:” should become an *optional* attribute
Last Week’s Reverted Clean-up ------------------------------------------
The WG decided that a clean-up was needed to remove any confusion about where the organisation name should be found. Because there are 93,105 objects that need to be updated, it is not practical to send notifications to all of these resource holders individually. As this change was expected to have little operational impact, it was decided that this should be done as a silent update. However, while the WG was informed of our intention to run the clean-up, it was an oversight on our part not to send a notification to the wider RIPE community.
We proceeded with our implementation of these changes in the RIPE Database and deployed release 1.86 to production on 21 March. We then communicated our intent to run the clean-up on 11 April to the Database WG[2]. When we ran the update last week, a community member alerted us to a problem and the clean-up was reverted the following day after it was completed[3].
There is now a discussion about how or whether to continue with this clean-up on the RIPE Database WG mailing list[4]. If the WG determines that we should proceed with this, we have a tentative date set for 9 May 2016. We invite you to discuss this further on the mailing list at <db-wg@ripe.net> if you have any opinions or concerns that you would like to share.
We will also be reviewing our processes to ensure we give adequate notification for such changes in the future.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC Database Group
[1] "descr:" is currently not editable in the Allocation Object Editor, but will become editable by LIRs in the near future. [2] https://www.ripe.net/ripe/mail/archives/db-wg/2016-March/005136.html [3] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005172.html [4] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005173.html
[http://www.kktcell.com/e-fatura/Disclaimer_Banner.jpg]<http://www.kktcell.com>
Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.KUZEY KIBRIS TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve KUZEY KIBRIS TURKCELLin goruslerini yansitmayabilir
Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir.
________________________________
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted.KUZEY KIBRIS TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of KUZEY KIBRIS TURKCELL.
This e-mail has been scanned for all known computer viruses.
Dear Tim, RIPE NCC, Working-Group, On Thu, Apr 28, 2016 at 05:11:02PM +0200, Tim Bruijnzeels wrote:
If we perform the clean-up that was proposed your organisation name will be removed from "descr:" in your resource objects. But note that this *only* applies to 'top-level' objects: i.e. allocations or assignments you received from the RIPE NCC - not e.g. assignments done under a PA allocation. And we only perform the clean-up if the "descr:" exactly matches the organisation name - that RIPE NCC was enforcing.
You can already update the "descr:" for assignments (PI and ASN) you received. If you change the "descr:" to something other than the organisation name they will not be touched.
Until now it has not been possible to update "descr:" for allocation objects. So if we would run the clean-up today that would mean that all allocation objects end up with no "descr:" attributes. You would however still be able to find your objects, because they have a reference to your organisation object (and your organisation object has your organisation name).
We are currently working on deprecating the object editors, so you will be able to edit the "descr:" attribute for allocations within a few weeks from now. After this work is done, you will be able to update your "descr:" of allocation objects as well.
As mentioned earlier the clean-up was reverted and has been postponed. We can run it again on 9 May, but only if the working group co-chairs call consensus. We can also postpone the clean-up until after the object editors are deprecated and people have had a chance to update the "descr:" on their allocation objects. We can also cancel the clean-up if the working group feels this is better.
After reviewing the contributions made regarding this topic, we see no reason not to proceed with the 'descr:' cleanup. RIPE NCC, please schedule a window in which the clean-up will be done. Some have argued on this mailing list "leave my data alone" - however, since RIPE NCC Registration Services has been enforcing the content of this attribute, it was never 'ours' to begin with. By doing this clean-up we have the equivalent of someone relinquishing control and taking their ball home. Various people have expressed their concern that by not cleaning up the existing (enforced) "descr:' lines, the data become stale over time and thus deteriorate the quality of the database. This one-off clean-up addresses that concern. Overloading the "descr:" attribute to forcibly contain the proper legal name has always been considered a temporary hack. After this clean-up everyone is free to put in the "descr:" attribute whatever they want. Kind regards, Job DB-WG Co-chair
Hi Job We have been in this situation many times in the past where an attribute has been deprecated or its value has been suspect for some reason. What we did in the past was to make the suspect/deprecated attribute into a "remarks:" attribute. This addresses both concerns raised in response to your discussion in this case. The old value is still there but it is clear it is not a reliable description. Those who want to keep that value can simply remove the "remarks:" tag. Those who don't want it can delete the attribute. After maybe 6 months you can do a final cleanup and remove any old value that has been left as a "remarks:". cheers denis On 10/05/2016 21:56, Job Snijders wrote:
Dear Tim, RIPE NCC, Working-Group,
On Thu, Apr 28, 2016 at 05:11:02PM +0200, Tim Bruijnzeels wrote:
If we perform the clean-up that was proposed your organisation name will be removed from "descr:" in your resource objects. But note that this *only* applies to 'top-level' objects: i.e. allocations or assignments you received from the RIPE NCC - not e.g. assignments done under a PA allocation. And we only perform the clean-up if the "descr:" exactly matches the organisation name - that RIPE NCC was enforcing.
You can already update the "descr:" for assignments (PI and ASN) you received. If you change the "descr:" to something other than the organisation name they will not be touched.
Until now it has not been possible to update "descr:" for allocation objects. So if we would run the clean-up today that would mean that all allocation objects end up with no "descr:" attributes. You would however still be able to find your objects, because they have a reference to your organisation object (and your organisation object has your organisation name).
We are currently working on deprecating the object editors, so you will be able to edit the "descr:" attribute for allocations within a few weeks from now. After this work is done, you will be able to update your "descr:" of allocation objects as well.
As mentioned earlier the clean-up was reverted and has been postponed. We can run it again on 9 May, but only if the working group co-chairs call consensus. We can also postpone the clean-up until after the object editors are deprecated and people have had a chance to update the "descr:" on their allocation objects. We can also cancel the clean-up if the working group feels this is better.
After reviewing the contributions made regarding this topic, we see no reason not to proceed with the 'descr:' cleanup. RIPE NCC, please schedule a window in which the clean-up will be done.
Some have argued on this mailing list "leave my data alone" - however, since RIPE NCC Registration Services has been enforcing the content of this attribute, it was never 'ours' to begin with. By doing this clean-up we have the equivalent of someone relinquishing control and taking their ball home. Various people have expressed their concern that by not cleaning up the existing (enforced) "descr:' lines, the data become stale over time and thus deteriorate the quality of the database. This one-off clean-up addresses that concern.
Overloading the "descr:" attribute to forcibly contain the proper legal name has always been considered a temporary hack. After this clean-up everyone is free to put in the "descr:" attribute whatever they want.
Kind regards,
Job DB-WG Co-chair
Hi Denis, On Wed, May 11, 2016 at 01:48:33AM +0200, denis wrote:
We have been in this situation many times in the past where an attribute has been deprecated or its value has been suspect for some reason.
What we did in the past was to make the suspect/deprecated attribute into a "remarks:" attribute.
Sometimes this approach was used, but certainly not always.
This addresses both concerns raised in response to your discussion in this case. The old value is still there but it is clear it is not a reliable description. Those who want to keep that value can simply remove the "remarks:" tag. Those who don't want it can delete the attribute. After maybe 6 months you can do a final cleanup and remove any old value that has been left as a "remarks:".
Had the attribute been an actual "user-owned" attribute, the "remarks:" approach might have made more sense, but this is not the case. Thanks for chiming in, Job ps. It still annoys me somewhat that the "remarks: For information on "status:"" remarks show up everywhere, years later. :)
HI Job On 11/05/2016 02:00, Job Snijders wrote:
Hi Denis,
On Wed, May 11, 2016 at 01:48:33AM +0200, denis wrote:
We have been in this situation many times in the past where an attribute has been deprecated or its value has been suspect for some reason.
What we did in the past was to make the suspect/deprecated attribute into a "remarks:" attribute.
Sometimes this approach was used, but certainly not always.
This addresses both concerns raised in response to your discussion in this case. The old value is still there but it is clear it is not a reliable description. Those who want to keep that value can simply remove the "remarks:" tag. Those who don't want it can delete the attribute. After maybe 6 months you can do a final cleanup and remove any old value that has been left as a "remarks:".
Had the attribute been an actual "user-owned" attribute, the "remarks:" approach might have made more sense, but this is not the case.
Thanks for chiming in,
Job
ps. It still annoys me somewhat that the "remarks: For information on "status:"" remarks show up everywhere, years later. :)
I believe these are only in AUT-NUM objects that had a new "status:" attribute added and all levels of legacy resource hierarchies that had their "status:" value changed. IIRC when I wrote the implementation plan for this change these "remarks:" attributes were locked in place to prevent accidental removal before anyone read it and then flood Customer Services with questions about the status change. Many AUT-NUM objects are auto-generated and it would be easy to lose these remarks. I think the plan was to unlock these attributes after about 1 year. Another thing that was forgotten after I left...keeping track of things like this was one of the many things someone at the NCC did not know I did :) cheers denis
If the objects are going to be automatically edited, I strongly perfer this to be only once, instead of twice. As a follow up: Is "last-modified:" going to be updated? Will the "your objects got changed" mail be generated? On 2016 May 11 (Wed) at 01:48:33 +0200 (+0200), denis wrote: :Hi Job : :We have been in this situation many times in the past where an attribute has :been deprecated or its value has been suspect for some reason. : :What we did in the past was to make the suspect/deprecated attribute into a :"remarks:" attribute. This addresses both concerns raised in response to your :discussion in this case. The old value is still there but it is clear it is :not a reliable description. Those who want to keep that value can simply :remove the "remarks:" tag. Those who don't want it can delete the attribute. :After maybe 6 months you can do a final cleanup and remove any old value that :has been left as a "remarks:". : :cheers :denis : :On 10/05/2016 21:56, Job Snijders wrote: :>Dear Tim, RIPE NCC, Working-Group, :> :>On Thu, Apr 28, 2016 at 05:11:02PM +0200, Tim Bruijnzeels wrote: :>>If we perform the clean-up that was proposed your organisation name :>>will be removed from "descr:" in your resource objects. But note that :>>this *only* applies to 'top-level' objects: i.e. allocations or :>>assignments you received from the RIPE NCC - not e.g. assignments done :>>under a PA allocation. And we only perform the clean-up if the :>>"descr:" exactly matches the organisation name - that RIPE NCC was :>>enforcing. :>> :>>You can already update the "descr:" for assignments (PI and ASN) you :>>received. If you change the "descr:" to something other than the :>>organisation name they will not be touched. :>> :>>Until now it has not been possible to update "descr:" for allocation :>>objects. So if we would run the clean-up today that would mean that :>>all allocation objects end up with no "descr:" attributes. You would :>>however still be able to find your objects, because they have a :>>reference to your organisation object (and your organisation object :>>has your organisation name). :>> :>>We are currently working on deprecating the object editors, so you :>>will be able to edit the "descr:" attribute for allocations within a :>>few weeks from now. After this work is done, you will be able to :>>update your "descr:" of allocation objects as well. :>> :>>As mentioned earlier the clean-up was reverted and has been postponed. :>>We can run it again on 9 May, but only if the working group co-chairs :>>call consensus. We can also postpone the clean-up until after the :>>object editors are deprecated and people have had a chance to update :>>the "descr:" on their allocation objects. We can also cancel the :>>clean-up if the working group feels this is better. :> :>After reviewing the contributions made regarding this topic, we see no :>reason not to proceed with the 'descr:' cleanup. RIPE NCC, please :>schedule a window in which the clean-up will be done. :> :>Some have argued on this mailing list "leave my data alone" - however, :>since RIPE NCC Registration Services has been enforcing the content of :>this attribute, it was never 'ours' to begin with. By doing this :>clean-up we have the equivalent of someone relinquishing control and :>taking their ball home. Various people have expressed their concern that :>by not cleaning up the existing (enforced) "descr:' lines, the data :>become stale over time and thus deteriorate the quality of the database. :>This one-off clean-up addresses that concern. :> :>Overloading the "descr:" attribute to forcibly contain the proper legal :>name has always been considered a temporary hack. After this clean-up :>everyone is free to put in the "descr:" attribute whatever they want. :> :>Kind regards, :> :>Job :>DB-WG Co-chair :> : -- I think that I shall never see A billboard lovely as a tree. Perhaps, unless the billboards fall I'll never see a tree at all. -- Ogden Nash
Dear working group, In answer to your question, let me ask the working group in return to take a decision by the end of the week.
As a follow up: Is "last-modified:" going to be updated?
If the working group prefers, we will update "last-modified:". We did not intend to do so because this is a bulk change and not a *user* initiated change. This was always about
Will the "your objects got changed" mail be generated?
Initially the intention was that we wouldn't because the clean-up affects 93k objects, out of which 49k have a 'notify'. This can result in too many support questions, especially in this busy time just before the RIPE Meeting. That said, we re-evaluated and we can send notifications, if we postpone the clean-up to a more quiet time. This implies that "descr:" remains maintained by RIPE NCC until then. So, working group, please decide between the following: a) Clean-up this Tuesday 17 May, with general announcement only b) Clean-up on Thursday 2 June, with notifications, RS keeps enforcing "descr:" until then. If option a is preferred we need to know this by Friday afternoon latest, so that we can prepare. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Dear Tim, On Wed, May 11, 2016 at 05:26:24PM +0200, Tim Bruijnzeels wrote:
In answer to your question, let me ask the working group in return to take a decision by the end of the week.
As a follow up: Is "last-modified:" going to be updated?
If the working group prefers, we will update "last-modified:".
We did not intend to do so because this is a bulk change and not a *user* initiated change. This was always about
Will the "your objects got changed" mail be generated?
Initially the intention was that we wouldn't because the clean-up affects 93k objects, out of which 49k have a 'notify'. This can result in too many support questions, especially in this busy time just before the RIPE Meeting.
That said, we re-evaluated and we can send notifications, if we postpone the clean-up to a more quiet time. This implies that "descr:" remains maintained by RIPE NCC until then.
So, working group, please decide between the following: a) Clean-up this Tuesday 17 May, with general announcement only b) Clean-up on Thursday 2 June, with notifications, RS keeps enforcing "descr:" until then.
If option a is preferred we need to know this by Friday afternoon latest, so that we can prepare.
Good write up Tim, thanks. I prefer option b and an update to "last-modified:". Kind regards, Job
Hi, On Wed, May 11, 2016 at 05:31:46PM +0200, Job Snijders wrote:
I prefer option b and an update to "last-modified:".
+1 (if some of our objects get modified, I really prefer noticing when it happens than "some time in the future, and then wondering how a change could happen without me noticing") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 2016 May 11 (Wed) at 17:26:24 +0200 (+0200), Tim Bruijnzeels wrote: :Dear working group, : :In answer to your question, let me ask the working group in return to take a decision by the end of the week. : :> As a follow up: Is "last-modified:" going to be updated? : :If the working group prefers, we will update "last-modified:". : :We did not intend to do so because this is a bulk change and not a *user* initiated change. This was always about : I have an extremely strong preference for last-modified to be updated. This *is* a modification. :> Will the "your objects got changed" mail be generated? : :Initially the intention was that we wouldn't because the clean-up affects 93k objects, out of which 49k have a 'notify'. This can result in too many support questions, especially in this busy time just before the RIPE Meeting. : :That said, we re-evaluated and we can send notifications, if we postpone the clean-up to a more quiet time. This implies that "descr:" remains maintained by RIPE NCC until then. : I have a preference (but not as strong) that the notification mail is generated. To me, that's the entire point of the notify field. Is it possible that the reason for this change be included in the notification mail? That may help reduce the number of support requests generated. :So, working group, please decide between the following: :a) Clean-up this Tuesday 17 May, with general announcement only :b) Clean-up on Thursday 2 June, with notifications, RS keeps enforcing "descr:" until then. : My preference is with notification, so #b. :If option a is preferred we need to know this by Friday afternoon latest, so that we can prepare. : :Kind regards, : :Tim Bruijnzeels :Assistant Manager Software Engineering :RIPE NCC -- "Under capitalism, man exploits man. Under Communism, it's just the opposite." -- John Kenneth Galbraith
Tim Bruijnzeels wrote:
So, working group, please decide between the following: a) Clean-up this Tuesday 17 May, with general announcement only b) Clean-up on Thursday 2 June, with notifications, RS keeps enforcing "descr:" until then.
option a, please. 50k notifications more technically correct, but is going to cause far more trouble than it's worth, assuming there is a pre-notification to e.g. db-wg, ncc-services-wg, ripe-list, etc. There is no option where 100% of people will be happy. My suspicion is that some people are going to be very annoyed indeed to get hundreds, if not thousands, of notifications. Nick
Hi, Excuse the briefness of this mail, it was sent from a mobile device.
On May 11, 2016, at 18:51, Nick Hilliard <nick@inex.ie> wrote:
Tim Bruijnzeels wrote:
So, working group, please decide between the following: a) Clean-up this Tuesday 17 May, with general announcement only b) Clean-up on Thursday 2 June, with notifications, RS keeps enforcing "descr:" until then.
option a, please.
50k notifications more technically correct, but is going to cause far more trouble than it's worth, assuming there is a pre-notification to e.g. db-wg, ncc-services-wg, ripe-list, etc.
There is no option where 100% of people will be happy. My suspicion is that some people are going to be very annoyed indeed to get hundreds, if not thousands, of notifications.
+1 Hundreds (if not thousands) of e-mails sent to the same LIR will cause all kind of troubles and, depending on the LIR processes, may cause problems to some LIRs. I would not mind if all the e-mail addresses which should receive a notification will receive only one regarding all of their resources. last-changed should be modified as well, if possible. my 2 cents, elvis
Nick
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. Rob
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
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
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.
Peter Hessler wrote:
What should the WG do, then? Ask the NCC to write new code? Update the data-model?
the code is new; the data model has it roots around 1992 (ripe-50) and can't be changed without causing serious disruption to data consumers, which would mean retooling pretty much anything ever built to ingest ripedb objects. There are a lot of db info consumers: https://www.ripe.net/analyse/statistics/ripe-database/ripedb-queries It works well enough that as a data consumer, I don't particularly need to see massive changes to it. It could be revolutionised and that might be interesting, but drastically changing the data model is a lot of work for all parties. Nick
Dear working group
On 11 May 2016, at 18:23, Sander Steffann <sander@steffann.nl> 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
Let me elaborate on the procedure we had in mind for this. In a nutshell we intended to use a custom notification mechanism avoiding duplicate emails. While it's true that the normal notification mechanism is triggered on the update of any object, and emails the "notify:" email for every modification. We can disable this mechanism, and get a list of affected objects and process them differently. We have done similar notifications in the past. Following this strategy every recipient would only get one email listing all affected objects, and an explanation of the background of this change. Avoiding duplicate emails helps reduce the impact on LIRs, but may not lower the support burden w.r.t. questions on the RIPE NCC side. To achieve that we aim to keep the email concise, explain that this was done after WG discussion and consensus, highlight that no action is strictly necessary, and explain that "descr:" can now be modified. Despite all this, it is likely that this will still surprise a number of object holders. We can expect support tickets from these people, and the working group may see comments from these people. Kind regards, Tim Bruijnzeels
Hi Tim, Thanks.
Following this strategy every recipient would only get one email listing all affected objects, and an explanation of the background of this change.
Excellent. Out of curiosity, how many unique ‘notify’ attributes are there that would receive a message as a result of this? Have you got that figure? Cheers, Rob
Hi Rob,
On 12 May 2016, at 10:43, Rob Evans <rhe@nosc.ja.net> wrote:
Hi Tim,
Thanks.
Following this strategy every recipient would only get one email listing all affected objects, and an explanation of the background of this change.
Excellent. Out of curiosity, how many unique ‘notify’ attributes are there that would receive a message as a result of this? Have you got that figure?
Cheers, Rob
Counting the distinct email addresses from the notify: attribute(s) for the affected objects, as well as mnt-nfy: attribute(s) for the maintainers, gives a total of 22,943 addresses. This total will change slightly by the time we run the cleanup. Regards Ed Shryane RIPE NCC
Hi Tim,
Let me elaborate on the procedure we had in mind for this. In a nutshell we intended to use a custom notification mechanism avoiding duplicate emails.
While it's true that the normal notification mechanism is triggered on the update of any object, and emails the "notify:" email for every modification. We can disable this mechanism, and get a list of affected objects and process them differently. We have done similar notifications in the past.
Following this strategy every recipient would only get one email listing all affected objects, and an explanation of the background of this change.
Sounds good!
Avoiding duplicate emails helps reduce the impact on LIRs, but may not lower the support burden w.r.t. questions on the RIPE NCC side. To achieve that we aim to keep the email concise, explain that this was done after WG discussion and consensus, highlight that no action is strictly necessary, and explain that "descr:" can now be modified. Despite all this, it is likely that this will still surprise a number of object holders. We can expect support tickets from these people, and the working group may see comments from these people.
Ok :) Cheers! Sander
Job Snijders wrote:
After reviewing the contributions made regarding this topic, we see no reason not to proceed with the 'descr:' cleanup. RIPE NCC, please schedule a window in which the clean-up will be done.
Thanks. Although this is going to cause some short-term hassle, it's in the long term best interests of the RIPE DB to remove non-atomic cruft like this. If it's not removed, fossilisation will happen and that is not a good thing. Nick
participants (11)
-
denis -
Edward Shryane -
Elvis Daniel Velea -
Gert Doering -
Job Snijders -
Job Snijders -
Nick Hilliard -
Peter Hessler -
Rob Evans -
Sander Steffann -
Tim Bruijnzeels