- db-wg - mailman.ripe.net

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by AKIL EVLAT 25 Apr '16

25 Apr '16

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(a)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(a)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(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 [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.

4 5

Phasing out the LIR Portal object editors
by Alex Band 21 Apr '16

21 Apr '16

Dear colleagues, Over the last year the RIPE NCC has been making a considerable amount of incremental changes to the RIPE Database user interface. Especially the implementation of streamlined authentication using RIPE NCC Access has put us in a position where we can further improve the user experience in other areas. As the next step in this process, we intend to phase out the so-called LIR Portal object editors. Currently, the object editors are necessary to allow you to make changes to particular attributes of RIPE Database objects that are maintained by the RIPE NCC. For example, you can use them to change the tech-c and admin-c in the inetnum object for the allocation that you hold. This system has always been the cause of much confusion. User data that you expect to be able to change in the RIPE Database can only be changed through the LIR Portal, whereas other information can be edited in the RIPE Database itself. Our plan is to bring all of this to the place where it belongs and where users expect it, the RIPE Database. The way we intend to do this involves a couple of steps. The first step is to use business rules to determine which attributes you can change, and which ones can only be changed by the RIPE NCC. For example, in an inetnum for an allocation only the RIPE NCC can change the range, but you can change the admin-c and tech-c. The second step is setting the authorisation for the attributes that you control. The RIPE NCC already has a maintainer on the allocation, RIPE-NCC-HM-MNT. In the system we envision, we would allow you to select an additional maintainer, to authorise changes over the attributes that you are authoritative for. You will be able to select this maintainer in the LIR Portal. We will place this maintainer on all existing and new objects that have joint responsibility: allocations for IP resources and the Organisation object. It is important to note that none of these changes have a fundamental impact on the RIPE Database itself. We are only making changes to the business rules and the way you determine authorisation. We look forward to your feedback! Kind regards, Alex Band Product Manager RIPE NCC

2 1

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