- db-wg - mailman.ripe.net

Re: [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
by Athina Fragkouli 20 Apr '16

20 Apr '16

Dear Denis, all, The RIPE NCC is by default the "data controller" of the personal data in the Database (i.e. it has liability by law) but in practice it has no control over all these personal data. The Data Protection Task Force, representing the RIPE community, decided that this responsibility should be contractually (via the RIPE Database Terms and Conditions) transferred to those that have actual control over the personal data. In the RIPE Database, these persons are identified by the maintainer object (referenced by the “mnt-by:” attribute in any data object). The Data Protection Task Force decided that this attribute should be made mandatory for all objects. This attribute would be used to indicate who is really responsible for specific personal data in the RIPE Database. Additionally, the Data Protection Task Force decided that the RIPE NCC should remove all unreferenced personal data from the RIPE Database. Although the RIPE NCC allowed some time for the community members to add a mandatory "mnt-by:" to their so-far unmaintained personal data, there were still unmaintained personal data in the RIPE Database. The RIPE NCC was alerted by third parties that this data could be hijacked in order to facilitate illegal activities. It was the RIPE NCC's responsibility to inform the RIPE community of this security risk and initiate a community discussion on possible ways to handle it. At the same time, the RIPE NCC could anticipate that if we were merely exposed the security risk without taking any measures to prevent it, we would alert malicious people and the hijacking attempts would increase. Therefore, we considered that locking the objects, until the community could discuss a proper way forward, would be an adequate measure to prevent possible hijacking cases in the meantime, without creating a disproportionate burden for legitimate holders. This action was in line with the RIPE NCC's obligations by law. If people would like to have their locked personal data removed from the RIPE Database, they can submit a request to the RIPE NCC. Kind regards, Athina Fragkouli Head of Legal RIPE NCC References: RIPE Database Terms and Conditions https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms DPTF report https://www.ripe.net/participate/ripe/tf/dp/report-of-the-ripe-data-protect… Data Protection report https://www.ripe.net/about-us/legal/ripe-ncc-data-protection-report Procedure for the Removal of Personal Contact Details from the RIPE Database https://www.ripe.net/manage-ips-and-asns/db/support/documentation/removal-o…

2 1

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by Marcin Kuczera 19 Apr '16

19 Apr '16

On 2016-04-19 16:17, Tim Bruijnzeels wrote: > 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. I strongly support this. Normally there is ORG: in object, that refers to correct owner name. Company names in example in Poland are sometimes complicaded, some forms of company contain all founders names so this is very very long and as DESCR is often used by i.e. SpeedTest - such companies were angry that description displayed was i.e. "BestInternet and partners SVEN, OLAF, ANNA and ELSA" instead of just "BestInternet". So, in my opinion it is good step Marcin > > 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(a)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 -- Marcin Kuczera / Specjalista d/s telekomunikacji, Wiceprezes Zarządu +48 32 440 80 71/ marcin.kuczera(a)leon.pl <mailto:marcin.kuczera@leon.pl> Leon Sp. z o.o. ul. Kilińskiego 33d, 44-200 Rybnik http://www.leon.pl/ INTERNET | TELEWIZJA | TELEFON KRS 0000223101 Sąd Rejonowy w Gliwicach Kapitał zakładowy 282.500 zł NIP: 6332068698

1 0

db 1.86 and descr objects
by Peter Hessler 19 Apr '16

19 Apr '16

Hi all New member of the DB-WG here. 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. 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. 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. 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 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? -- Left to themselves, things tend to go from bad to worse.

7 9

Release 1.86 deployed to RC
by Thiago da Cruz Pereira 13 Apr '16

13 Apr '16

Dear working group, We have deployed release 1.86 to the Release Candidate environment. With this release we will: = Make "descr:" tribute optional for all object types as discussed in the Database WG. = Prevent RIPE-NCC-RPSL-MNT to be used as mnt-by We encourage all users of the database to test their tools. Kind regards, Thiago da Cruz Software Engineer - RIPE NCC Database Team

2 3

Call for agenda items, DB-WG and planned Routing-DB meeting during RIPE72, Copenhagen, Denmark
by Piotr Strzyzewski 12 Apr '16

12 Apr '16

Dear DB-WG participants It is now only a bit more than a month to the next RIPE Meeting. This is about time to ask you for agenda items. This time we are reaching out to you for agenda items for _two_ sessions during the RIPE72 meeting in Copenhagen, Denmark, 23-27 May 2016: - the usual Database Working Group, - the _planned_ joint Routing-DB session. The DB-WG session is currently scheduled as it was the last time, for Thursday (May 26th), starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. Please be aware that the date and time provided could change as the meeting itself still has the draft plan. The planned joint Routing-DB does not have time and date set up yet. As it was announced by Rob Evans at the Routing-WG mailing list, it purpose is to see if we can actually make some progress around the topic of non-authoritative routing registry information in the RIPE DB. Please submit your items or topic suggestions directly to the WG chairs or to the list for public discussion. The draft agenda will be published soon. Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

3 2

Locking unmaintained PERSON and ROLE objects in the RIPE Database
by ipmaster＠bt.com 08 Apr '16

08 Apr '16

reg id: uk.bt Dear Trudy Prins, Can you tell me what will happen at present with our current PA assignments to our end customers when we try to register them on the RIPE NCC database against an unmaintained person object. Will it fail, or will it pass and we just get a warning? Or, is the process now as stated in your proposal set out in your email ? Regards Myrna Goedluck BTnet IP Master Team Tel: 0800 085 0223 Option 3 +44 (0)331 666 2729[X] Email: IPMASTER(a)BT.COM British Telecommunications plc Registered Office: 81 Newgate Street London EC1A 7AJ Registered in England no.1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

2 1

New on RIPE Labs: Improved Syncupdates in the RIPE Database
by Mirjam Kuehne 06 Apr '16

06 Apr '16

Dear colleagues, Over the last couple of months we've been putting a lot of focus on improving the usability of the RIPE Database web interface. We started with tightly integrating our Single Sign-On system, RIPE NCC Access, into webupdates. We added better validation, auto-complete, "diffs", integrated abuse-contact creation, updates in a text-area and many more tweaks and improvements to enhance the user experience. The last big part of the RIPE Database web interface that was left untouched is Syncupdates. Until now... Please find more details on RIPE Labs: https://labs.ripe.net/Members/AlexBand/improving-syncupdates-in-the-ripe-da… Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: How Pingable are the Pingables?
by Mirjam Kuehne 05 Apr '16

05 Apr '16

Dear colleagues, We look at how the "pingable:" and "ping-hdl:" attributes have been adopted in the last five years and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas. Spoiler alert: It could be better. Please find the details on RIPE Labs: https://labs.ripe.net/Members/wilhelm/how-pingable-are-the-pingables?pk_cam… Kind regards, Mirjam Kuehne RIPE NCC

1 0

increase daily db dump frequency?
by Job Snijders 15 Mar '16

15 Mar '16

Hi RIPE NCC, WG, I have a use-case in which secondaire NRTM mirrors can't easily reseed from the data stored at ftp.ripe.net:/ripe/dbase/ because the intermediate NRTM mirror retains less history than the actual delta between when the dump was made and the current serial. In other words, if I want to reseed an IRR instance I have to do so before lunch (UTC), because after lunch the delta usually is too large. This can be mitigated if the dump files in ftp.ripe.net:/ripe/dbase/split are refreshed more often then once a day. Would it be possible to dump every 6 hours instead of every 24 hours? Kind regards, Job

6 6

Fw: [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by ripedenis＠yahoo.co.uk 12 Mar '16

12 Mar '16

Sorry I hit reply instead of reply-all... ----- Forwarded Message ----- From: "ripedenis(a)yahoo.co.uk" <ripedenis(a)yahoo.co.uk> To: Sander Steffann <sander(a)steffann.nl> Sent: Friday, 11 March 2016, 17:06 Subject: Re: [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01 Hi Sander I was not making any decision just expressing an opinion just as Elvis expressed his opinion on my implementation :) cheersdenis From: Sander Steffann <sander(a)steffann.nl> To: denis <ripedenis(a)yahoo.co.uk> Cc: Database WG <db-wg(a)ripe.net>; "anti-abuse-wg(a)ripe.net" <anti-abuse-wg(a)ripe.net> Sent: Friday, 11 March 2016, 16:54 Subject: Re: [anti-abuse-wg] [db-wg] objection to RIPE policy proposal 2016-01 Hello Denis, > Sorry Elvis but you are neither a software engineer nor a regular user inputting data into the RIPE Database. So your unsubstantiated statement of 'poor' does not carry much weight. Excuse me, but you do not get to decide that a fellow working group member's contribution does not carry much weight. That is the working group chairs' job when deciding on consensus, and from experience I know that even the chairs only do that in very rare circumstances. Consensus is based on content and supporting arguments, not on whether you judge somebody worthy... Cheers, Sander

6 6