April 2016 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

WG Chairs Selection
by Piotr Strzyzewski 16 Nov '16

16 Nov '16

Dear DB-WG Members As agreed during DB-WG session at RIPE69 Meeting in London on 06.11.2014, the WG Chair Selection procedure is executed at yearly intervals. This means that it is about time to run it for the very first time. This is the call for interested parties. Interested parties have 2 weeks to make their interest known on this mailing list. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. After two weeks the chairs will declare consensus. Since there is a limit of 3 co-chairs, if at the end of the discussion phase there will be more than 3 proposed co-chairs then a call will be made for any of the candidates to withdraw. If there still will be more than 3 candidates then names will be put into a hat and the first three names drawn from the hat will take on the role of chairs for the next 12 months. All three of present co-chairs expressed their interest in being co-chairs for another term. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

9 11

Locking unmaintained PERSON and ROLE objects in the RIPE Database
by Trudy Prins 02 Sep '16

02 Sep '16

Dear colleagues, The RIPE NCC Executive Board (EB) endorsed a proposal on how to deal with a vulnerability for RIPE Database users. Following their advice, the RIPE NCC proactively locked 848,986 unmaintained PERSON objects and 1,206 unmaintained ROLE objects on 6 April 2016. Since reaching the last /8, IPv4 address space has become more susceptible to hijacking. Unmaintained PERSON and ROLE objects are highly at risk of being found and hijacked. In addition, unmaintained PERSON and ROLE objects are an issue with regards to data protection obligations. The potential impact of abuse led us to consult with the EB on this intermediary solution before engaging with the community on the next steps. Exposing this issue without taking adequate measures would have left the RIPE NCC liable to third party damages. The proposed solution we outline below is a starting point, to be discussed by the community. Background: =========== Since 2010 it has been mandatory to protect PERSON and ROLE objects in the RIPE Database using a maintainer on "mnt-by:". A large number of PERSON and ROLE objects dating from before 2010 are still not protected in this way. Objects can be created that reference these unmaintained objects, but doing so will generate a warning. In recent years, given the scarcity of IPv4 address space, there is a higher risk of people searching for unmaintained PERSON or ROLE objects in order to pose as a resource holder to sell IPv4 space. In the case of legacy space, this could take place outside the view of the RIPE NCC if the address space is not registered with the RIPE NCC. Proposal: ========= 1) All unmaintained ROLE and PERSON objects are now locked. As the RIPE NCC will not be able to correctly check all claims on unmaintained database objects, unlocking is not available. Offering to unlock these objects could leave the RIPE NCC liable to third party damages if due diligence is not followed. 2) Furthermore, the RIPE NCC modifies the existing warning about referencing unmaintained persons/roles to a similar warning about referencing locked persons/roles. 3a) The locked objects can remain as they are. In time, all locked PERSON or ROLE objects no longer referenced by other objects could be automatically deleted: the current thinking is a 180-day deletion timeout for these locked, unreferenced objects. 3b) If there is an operational need, new PERSON or ROLE objects should be created by the object owners. This solution puts control back into the hands of the object owners. The user can follow the existing process for creating and referencing new objects. If there is a use case for supporting bulk migrations where a reference to a locked PERSON or ROLE object should be replaced, the RIPE NCC can create a wizard in the RIPE Database webupdates section of www.ripe.net <http://www.ripe.net/>. We look forward to your feedback. Kind regards, Trudy Prins Manager Software Engineering RIPE NCC

13 24

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by Tim Bruijnzeels 12 May '16

12 May '16

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(a)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(a)turkcell.com.tr > > > -----Original Message----- > From: AKIL EVLAT > Sent: Friday, April 22, 2016 10:50 AM > To: 'Tim Bruijnzeels' <tim(a)ripe.net>; ncc-announce(a)ripe.net; 'db-wg(a)ripe.net' <db-wg(a)ripe.net> > Cc: BARIS KIZILDERE (BARIS.KIZILDERE(a)kktcell.com) <BARIS.KIZILDERE(a)kktcell.com>; TO-CO-PN <TO-CO-PN(a)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(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.

11 21

Is it possible to choose your own NIC Handle when creating ROLE objects?
by Øystein Gåsdal 02 May '16

02 May '16

Hi I'm trying to create some ROLE objects, but encounter an error: nic-hdl: Syntax error I was told from support that in ROLE and PERSON object, I must use AUTO-1 as NIC handle. This information is not correct for the PERSON object, since I choose my own NIC handle when I created my own PERSON object. So is there a way around this for the ROLE object, too? Thanks. - Øystein

2 1

RIPE DB development process: Numbered Work Items
by Job Snijders 26 Apr '16

26 Apr '16

Dear team, Reflecting back upon the last 18 months, the chairs feel that we as a group can do better to make it easier to track and discuss ideas in a structurered way. Therefore, we propose a process/vehicle which we call "Numbered Work Items (NWI)". The goal of this proces is to make it simpler to learn the current status of a proposal, and in which court the ball lays. kickstart: To kickstart the proces, any db-wg participant can email the chairs with a snippet of text (a rough problem statement) and formally ask the chairs to make it a work item. The chairs then can say "yes" and assign a number, or "no". If a number was assigned, the work item will be routed through three phases. phase 1: problem definition In this phase as group we'll work on formulating an exact problem definition: text goes back and forth in the working group, example cases of the problem are provided. In a 2 or 3 weeks timeframe the chairs declare consensus on the problem statement of NWI. phase 1 output: clearly defined problem statement, or a conclusion we cannot agree upon a problem statement definition. If the latter is true, the NWI cannot proceed to phase 2. phase 2: solution definition solution finding: people can propose solutions to a work item's problem statement. Solutions can come from RIPE NCC staff, or any working group member. RIPE NCC may offer an implementation analysis on proposed solutions or aspects of solutions. For the NWI to move to phase 3, RIPE NCC has to provide the group with a summary of their understanding of the solution, and the chairs declare consensus on the group's acceptance of this summary. phase 3: development & deployment phase RIPE NCC writes the code, sets timelines what happens when, documents the transitions/migration plan if applicable. finish: when the change has been deployed in the production environment. Every month, someone will email the group with an overview of all open Work Items, a brief summary of the NWI, the phase they are in and possibly in who's court the ball is and the next action. Kind regards, Job

6 5

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 22 Apr '16

22 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