Dear working group, As announced on Wednesday we reverted the formatting change introduced by the "descr:" clean-up. Out of 93,015 objects, 323 were not reverted automatically because the user had made changes since the script ran. In cases where users fixed the whitespace we left the objects as they are. We have dealt with the others on case by case basis - taking care that we only revert the formatting problems we caused. This means that "descr:" is back for the moment. With regards to the warning given about this change. It was a conscious decision not to send notification for 93,015 objects because this would overwhelm our support queue with questions, regarding what we believed was change that was discussed in this working group, and that would have little or no operational impact. But as Job mentioned, even though this change was discussed at length in this working group, not warning ncc-announce in advance was an oversight. Going forward we suggest that we postpone the clean-up, warn ncc-announce in advance, and only run the clean-up some time later allowing stakeholders to be warned, and possible follow-up discussion to be had in this working group. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

On 15 Apr 2016, at 17:03, Job Snijders <job@instituut.net> wrote:

Hi Peter,

On Thu, Apr 14, 2016 at 02:14:58PM +0200, Peter Hessler wrote:

...

New member of the DB-WG here.

Thank you for joining!

...

Some of our objects were affected by the change to the "descr" object.

FWIW, I fully support the change to the object type and removing required attributes.

HOWEVER, I am EXTREMELY UPSET that my objects were edited without my consent or even a warning.

I can understand anyone becoming upset when they are faced with unexpected change. I believe a good effort (but not perfect, as you can see at the bottom of this email) was made to inform the community that change is coming through updates from RIPE NCC staff to this (db-wg@) mailing-list.

...

11 April, clean-up existing "descr:" attributes where the RIPE NCC enforced organisation names

In our objects, we wanted to keep our org name in the descr attribute. Having our objects unilaterately changed by RIPE NCC as a "clean up", is frankly not acceptable.

The goal of this whole operation was to allow the community to put whatever they want in the "descr:" attribute, if you choose to put your orgname in there, that is fine. If you prefer to express something else that is fine too.

Previously RIPE NCC enforced the content of the "descr" attribute, as it was agreed upon that the contents of that attribute should not be enforced, on this list an argument was made that by doing a one-off clean-up you are ensured that no stale data remains.

...

And worse, it only affected some of our objects, not all of them as I would have expected. IMHO, the worst part is the "last-modified" field was not updated, nor was a "your object has changed" email generated.

This is useful feedback, arguments for both updating "last-modified" and not updating "last-modified" can be made. The mechanics for this type of operation are not well established. It appears that adding things to RPSL is quite trivial, (the RFC even specifies "just ignore what is new and you dont understand"), but deprecating or changing existing attributes continues to pose a challenge: Not everyone reads the same news outlets, we have no programmatic way to signal to data producers/consumers that a change is coming.

...

Many people use the descr field for things, as an example: the "name" attribute at bgp.he.net. When browsing through the ASes in Germany, I noticed many companies that were likely hit by this (they showed a partial or complete address in the "name" field, instead of the name of the company), including one of the largest ISPs in Germany.

I recommend that developers of tools such as database analytics follow the "org:" attribute and use the content of the "org-name:" when it concerns RIPE objects instead. I would argue that the developer of such a tool has a duty to try and stay current on any changes concerning the data sources the tool uses.

...

I was unable to find a discussion of the _clean-up_ in the WG archives. Why was it decided not to inform the affected members, or even all members via the announce mailing list? Is that a standard policy?

In August and October 2015 there was discussion (https://www.ripe.net/ripe/mail/archives/db-wg/2015-August/thread.html look for the word "descr"), in January 2016 https://www.ripe.net/ripe/mail/archives/db-wg/2016-January/004970.html the chairs pulled the trigger and now its been implemented.

The proposal mentioned that an announcement would be send to the ncc-announce@ripe.net list, but I fear there has been an oversight and this has not happened. Point taken.

Kind regards,

Job

Is there any way I can register a "please leave my objects alone" request? I don't care that there were once rules about descr: I can edit my objects if I choose to. Ian -----Original Message----- From: db-wg [mailto:db-wg-bounces@ripe.net] On Behalf Of Piotr Strzyzewski Sent: 17 April 2016 18:53 To: Tim Bruijnzeels Cc: Database WG Subject: Re: [db-wg] db 1.86 and descr objects On Fri, Apr 15, 2016 at 05:50:02PM +0200, Tim Bruijnzeels wrote: Tim

As announced on Wednesday we reverted the formatting change introduced by the "descr:" clean-up. Out of 93,015 objects, 323 were not reverted automatically because the user had made changes since the script ran. In cases where users fixed the whitespace we left the objects as they are. We have dealt with the others on case by case basis - taking care that we only revert the formatting problems we caused.

This means that "descr:" is back for the moment.

With regards to the warning given about this change. It was a conscious decision not to send notification for 93,015 objects because this would overwhelm our support queue with questions, regarding what we believed was change that was discussed in this working group, and that would have little or no operational impact. But as Job mentioned, even though this change was discussed at length in this working group, not warning ncc-announce in advance was an oversight.

Going forward we suggest that we postpone the clean-up, warn ncc-announce in advance, and only run the clean-up some time later allowing stakeholders to be warned, and possible follow-up discussion to be had in this working group.

Thanks for that. I suggest that we postpone this for no more than one month from now. If there will be an extensive discussion here or at the ncc-announce, we can always extend this time. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

On 2016 Apr 15 (Fri) at 08:03:54 -0700 (-0700), Job Snijders wrote: :On Thu, Apr 14, 2016 at 02:14:58PM +0200, Peter Hessler wrote: :> And worse, it only affected some of our objects, not all of them as I :> would have expected. IMHO, the worst part is the "last-modified" :> field was not updated, nor was a "your object has changed" email :> generated. : :This is useful feedback, arguments for both updating "last-modified" and :not updating "last-modified" can be made. The mechanics for this type of :operation are not well established. It appears that adding things to :RPSL is quite trivial, (the RFC even specifies "just ignore what is new :and you dont understand"), but deprecating or changing existing I think that if there is a last-modified field, it should always be accurate. And, since the objects were modified, that should have updated the fields. I'm torn on the notify emails, though. I can see they would create an immense amount of support tickets, but on the other hand, as a producer of db objects I want to know what changed in my objects _especially_ when I didn't change them myself. :attributes continues to pose a challenge: Not everyone reads the same :news outlets, we have no programmatic way to signal to data :producers/consumers that a change is coming. : Should there be a db-announce@ list then? I don't know how much that will help the producers, but consumers of the db can get the changes summarized without having to follow the whole discussion. :> Many people use the descr field for things, as an example: the "name" :> attribute at bgp.he.net. When browsing through the ASes in Germany, I :> noticed many companies that were likely hit by this (they showed a :> partial or complete address in the "name" field, instead of the name :> of the company), including one of the largest ISPs in Germany. : :I recommend that developers of tools such as database analytics follow :the "org:" attribute and use the content of the "org-name:" when it :concerns RIPE objects instead. I would argue that the developer of such :a tool has a duty to try and stay current on any changes concerning the :data sources the tool uses. : Yes and no. Not everything should be called by the org name. E.g. If an org has 15 ASNs, they can be labeled for their purpose, instead of the org name. descr: makes sense to me. :> I was unable to find a discussion of the _clean-up_ in the WG archives. :> Why was it decided not to inform the affected members, or even all :> members via the announce mailing list? Is that a standard policy? : :In August and October 2015 there was discussion :(https://www.ripe.net/ripe/mail/archives/db-wg/2015-August/thread.html :look for the word "descr"), in January 2016 :https://www.ripe.net/ripe/mail/archives/db-wg/2016-January/004970.html :the chairs pulled the trigger and now its been implemented. : Thanks for these. When I looked, I didn't go back far enough in the archives. :The proposal mentioned that an announcement would be send to the :ncc-announce@ripe.net list, but I fear there has been an oversight and :this has not happened. Point taken. : :Kind regards, : :Job -- Sure, Reagan has promised to take senility tests. But what if he forgets?

Dear working group, First of all. We just sent an email to ncc-announce to alert people to the intended clean-up and ongoing discussion in this group. Secondly. We have a tentative date that we can run the clean-up again: 9 May. But, we will only do so on the basis of consensus called in this working group by the co-chairs. RIPE NCC originally suggested that a clean-up would be useful (more on that below), but the working group can also decide to postpone, or cancel the clean-up. That being said, please allow me to give our perspective on some of the issues below.

On 19 Apr 2016, at 12:54, Peter Hessler <phessler@theapt.org> wrote:

On 2016 Apr 15 (Fri) at 08:03:54 -0700 (-0700), Job Snijders wrote: :On Thu, Apr 14, 2016 at 02:14:58PM +0200, Peter Hessler wrote: :> And worse, it only affected some of our objects, not all of them as I :> would have expected. IMHO, the worst part is the "last-modified" :> field was not updated, nor was a "your object has changed" email :> generated. : :This is useful feedback, arguments for both updating "last-modified" and :not updating "last-modified" can be made. The mechanics for this type of :operation are not well established. It appears that adding things to :RPSL is quite trivial, (the RFC even specifies "just ignore what is new :and you dont understand"), but deprecating or changing existing

I think that if there is a last-modified field, it should always be accurate. And, since the objects were modified, that should have updated the fields.

In our understanding "last-modified:" should indicate when a user last made a semantically important change, because it can be interpreted as an indication of how well maintained an object is. Therefore we thought that in this case it was better not to update it. I can't remember exactly where this was said before, but I believe this intent was discussed as part of the "last-modified:" change. In short this was in no way meant to hide the fact that an update had happened, and the actual update is visible in history. If the working group feels that "last-modified:" should be updated in this clean-up then we can certainly do so. Also as Job indicates, this is probably a question that should be addressed explicitly whenever we have bulk update (or clean-up) tasks - unless of course there is consensus that it should always be updated.

I'm torn on the notify emails, though. I can see they would create an immense amount of support tickets, but on the other hand, as a producer of db objects I want to know what changed in my objects _especially_ when I didn't change them myself.

Given the number of objects it's not feasible to notify all individually.

:attributes continues to pose a challenge: Not everyone reads the same :news outlets, we have no programmatic way to signal to data :producers/consumers that a change is coming. :

Should there be a db-announce@ list then? I don't know how much that will help the producers, but consumers of the db can get the changes summarized without having to follow the whole discussion.

I believe it would be better that we always inform ncc-announce@ripe.net of changes like this.

:> Many people use the descr field for things, as an example: the "name" :> attribute at bgp.he.net. When browsing through the ASes in Germany, I :> noticed many companies that were likely hit by this (they showed a :> partial or complete address in the "name" field, instead of the name :> of the company), including one of the largest ISPs in Germany. : :I recommend that developers of tools such as database analytics follow :the "org:" attribute and use the content of the "org-name:" when it :concerns RIPE objects instead. I would argue that the developer of such :a tool has a duty to try and stay current on any changes concerning the :data sources the tool uses. :

Yes and no. Not everything should be called by the org name. E.g. If an org has 15 ASNs, they can be labeled for their purpose, instead of the org name. descr: makes sense to me.

The intent of the clean up was to have a clean starting point. The "org:" reference is authoritative w.r.t. the organisation name, and the "descr:" attribute can be used for anything else. In addition removing the organisation names from "descr:" would leave the objects in a state where "descr:" was completely controlled by the holder of the resource object. That said it seems that at least some people want to keep using their organisation name here. However, because of the number of objects it is not feasible to pro-actively contact all object holders beforehand and give people an option to exempt their objects from the update. And more fundamentally I believe that this would defeat the purpose of doing the clean-up in the first place. If a significant number of resource holders want to keep their organisation name in the "descr:" field, then confusion about where the organisation name should be found and updated remains. There are arguments in favour of doing the clean-up (most importantly clean state, one clear source for org name), and there are arguments against (most importantly silent updates). Making the call which is the greater good is not trivial. RIPE NCC argued for the clean-up case and earlier there was consensus on this, but if the working group now decides against it then we have peace with that too. Kind regards, Tim Bruijnzeels

:> I was unable to find a discussion of the _clean-up_ in the WG archives. :> Why was it decided not to inform the affected members, or even all :> members via the announce mailing list? Is that a standard policy? : :In August and October 2015 there was discussion :(https://www.ripe.net/ripe/mail/archives/db-wg/2015-August/thread.html :look for the word "descr"), in January 2016 :https://www.ripe.net/ripe/mail/archives/db-wg/2016-January/004970.html :the chairs pulled the trigger and now its been implemented. :

Thanks for these. When I looked, I didn't go back far enough in the archives.

:The proposal mentioned that an announcement would be send to the :ncc-announce@ripe.net list, but I fear there has been an oversight and :this has not happened. Point taken. : :Kind regards, : :Job

-- Sure, Reagan has promised to take senility tests. But what if he forgets?