- db-wg - mailman.ripe.net

Re: [db-wg] db-wg Digest, Vol 57, Issue 1
by Øystein Gåsdal 02 May '16

02 May '16

I thank you all for good answers. I think I know what to do now. - Øystein -----Opprinnelig melding----- Fra: db-wg [mailto:db-wg-bounces@ripe.net] På vegne av db-wg-request(a)ripe.net Sendt: søndag 1. mai 2016 12.00 Til: db-wg(a)ripe.net Emne: db-wg Digest, Vol 57, Issue 1 Send db-wg mailing list submissions to db-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/db-wg or, via email, send a message with subject or body 'help' to db-wg-request(a)ripe.net You can reach the person managing the list at db-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of db-wg digest..." Today's Topics: 1. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (Anand Buddhdev) 2. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (denis) ---------------------------------------------------------------------- Message: 1 Date: Sat, 30 Apr 2016 16:58:01 +0200 From: Anand Buddhdev <anandb(a)ripe.net> To: "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <5724C7F9.8020403(a)ripe.net> Content-Type: text/plain; charset=utf-8 On 30/04/16 14:02, ?ystein G?sdal wrote: Hi ?ystein, > Hello, and thank you for your answer. > But I think I need to be spoonfed about this? Denis has already provided a good answe. But let me help more with an example. > So according to the rules, the NIC-handle can be something like this: > > ALE-ADMIN-C ? No, you may not have 2 dashes in the NIC handle. You can only have a NIC handle of the form: XXX or XXX-YYY The first part (XXX) has to start with 2-4 letters, and optionally up to 6 digits. The -YYY part is optional, but if present, must be a dash, followed by up to 9 letters. Here are some valid examples: ALE ALE-RIPE ALE1234 AL345-RIPE ALE90-KOMMUNE But the following are NOT allowed: ALE-ADMIN-C AL023 ALESUND Regards, Anand ------------------------------ Message: 2 Date: Sat, 30 Apr 2016 23:25:59 +0200 From: denis <ripedenis(a)yahoo.co.uk> To: Anand Buddhdev <anandb(a)ripe.net>, "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <572522E7.7030800(a)yahoo.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Hi Anand, ?ystein On 30/04/2016 16:58, Anand Buddhdev wrote: > On 30/04/16 14:02, ?ystein G?sdal wrote: > > Hi ?ystein, > >> Hello, and thank you for your answer. >> But I think I need to be spoonfed about this? > > Denis has already provided a good answe. But let me help more with an > example. > >> So according to the rules, the NIC-handle can be something like this: >> >> ALE-ADMIN-C ? > > No, you may not have 2 dashes in the NIC handle. You can only have a > NIC handle of the form: > > XXX > > or > > XXX-YYY > > The first part (XXX) has to start with 2-4 letters, and optionally up > to > 6 digits. The -YYY part is optional, but if present, must be a dash, > followed by up to 9 letters. Here are some valid examples: > > ALE > ALE-RIPE > ALE1234 > AL345-RIPE > ALE90-KOMMUNE Almost :) But after the '-' you can only use a source name, like 'RIPE, 'APNIC', etc. so ALE90-KOMMUNE is not allowed cheers denis > > But the following are NOT allowed: > > ALE-ADMIN-C > AL023 > ALESUND > > > Regards, > Anand > End of db-wg Digest, Vol 57, Issue 1 ************************************

1 0

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

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

objection to RIPE policy proposal 2016-01
by Ruediger Volk 11 Mar '16

11 Mar '16

Dear colleagues, I object to passing the policy as proposed. There is no serious need for the policy, and at this time and under curent circumstance it would actually be harmful. I believe that the supposed good intentions would be better served by other actions, and the policy focussing on enforcement is ill advised. I understand that the current implementation of the RIPE database allows legacy holders to enter abuse-c attributes for their legacy resources if that's currently not possible the required extension of the database should be discussed (in the approprioate wg) and implementation would NOT require the PDP (as more drastic changes have been done to the database - and that extension hardly would contradict existing policy). No PDP is needed to send friendly invitations to legacy holders to populate their data objects with abuse-c information; I'm sure asking the RIPE NCC to do this would not create an undue burden or serious problem. Enhancing the invitations with some additional information potentially helpful to the recipients could be considered too: - some hints/guidance about expected use and support of that mailbox (active members of the abuse handling community probably will NOT be the typical recipient! and no injuries are expected if any community member sees that information:-) - specific suggestions what to put into the abuse-c field (whatever the RIPE NCC might use to extrapolate abuse-c from existing data) The working group should contribute helpful information to be included. I'm quite certain running a second invitation campaign would be even less of a problem and effort for RIPE NCC; I cannot predict how much the information provided in a later campaign can be improved based on feedback and experience from an earlier one. You may argue, that such more friendly approach could have been used also earlier - and I would very much agree and I certainly complained and suggested that at least the forced population of missing abuse-c should be postponed until friendly information was made available. Now we do NOT HAVE TO repeat past errors... Specifically with legacy resource holders it would be a good idea for RIPE community and NCC to address them with an inviting and helpful approach; as there is a sad history of seemingly coercive and unfriendly communications towards legacy holders. REPEATING the error now - even considering the much lower number of relevant records - is however actually MORE SERIOUS in DAMAGING the CREDIBILITY of the working group (and as a consequence the RIPE NCCs position) because of the accumulated history. Repeated requests for information on supposed use und handling of abuse-c has been answered by pointing out that it is required by a policy that was consciously created without any such information. The new policy proposal painfully fits into the sad observation that the anti-abuse working group as a community has constantly put effort into enforcing creation and population of abuse-c data but not (even tried) to provide to the rest of the world helpful explanations on requirements and expected handling at the requested mailboxes. That observations leads to the question whether the community is not able to come up with some helpful explanation or whether it does not care... :-( In both cases asking for enforcement does seem neither appropriate nor acceptable and means that the request cannot be taken serious - bad for the perception of RIPE and RIPE NCC activety by parties that are not heavily involved in the community processes. Consider the typical person confronted with a request to define abuse-c: how deeply is he involved with the anti-abuse working group (where a common understanding might exist - I consider myself only occassional observer and not a member and don't know)? Trying to close more quickly and on a more constructive perspective let me skip to elaborate here on my judgement: at close inspection the rationale and arguments look quite broken. The policy content does actually not matter that much - look for a sketch of a potential harmless implementation approach above in this message. What matters is appropriate use of the PDP (it can be abused!!!) and what are good goals of the working group and good ways of achieving them. The assumed good goals (as I understand it) are (a) improving quality of abuse-c information in order to (b) improve abuse reporting and report handling processes and (c) extending the abuse-c coverage for Internet number resources in the RIPE NCC registry The policy proposal references (a) and (b) quite explicitly; I took the liberty to interpolate (b) which actually seems to be the primary goal, and it looks like the working group decided that this will be helped by means of creating distinctly identified mailbox information to be put into abuse-c. The criterium for gauging (a) seems to be whether "improved data" actually helps "improve processing" (b) - what else? Creating abuse-c entries of better/good quality obviously depends on the recipient being appropriate and informed about expected potential messages and preparing to deal with them. Forcing creation of abuse-c in any other way is not going to create better quality but actually looses information (you loose track of which entries have the "quality of informed and [potentially] prepared recipient"). We have to assume that Internet number resource holders requested to establish abuse-c - usually are NOT focussed an abuse handling (different core business:-) - in many cases are not members of the anti-abuse working (and unlikely to have insight into undocumented potential consensus views of the working group or the larger abuse-c activist community) - in general willing to cooperate (we really should care for those and help them! ... yes, there are others - from "don't care" to "evil") For making a reasoned decision about the recipient for abuse-c and preparing for handling messages one obviously needs some understanding/explanation of what is expected. If no such helpful information is offered at the time of requesting abuse-c setup, many well intentioned parties will *something* (not really good "quality") to fill required fields and little motivation to followup will remain. If they care to ask for helpful information and the answer stays "this is required by policy, and it consciously declines to explain", they are likely to conclude that they have to submit to RIPE policies and the policy makers+process that cannot be taken serious... I note that for goal (b) of course some common understanding of expected use and handling for the abuse-c mailbox is a prerequisite on BOTH sides (senders also!) I do not expect to see formal, precise, and exhaustive definition of requirements and intended/expected use of abuse-c use - that would seem fairly impossible and certainly would not provide a practical answer to the issue. The working group needs to followup it previous abuse-c policy by starting to create practically useful explanations, before considering more "enforcement" (actually IMHO all enforcement activety should [have] be[en] postponed - potentially replaced by friendly invitations). It may take considerable effort to develope consensus on such documentation - but is it reasonable to rely on all relevant outside parties to have the first contact figure out completely on his own and explain to his management, consultants, service providers, etc... what needs to be done? (what aggregated cost and what "quality" implications do you expect?) It's ok to have working groups that just have internal fun between some birds of a feather. If a working group feels like making demands (e.g. policies) to a larger community it should also consider what support it needs to provide to serve the purposes of that larger community. Thanks for your attention and consideration. Ruediger Volk P.S.: Sorry, for a painfully long message. Trust me I had more painful time writing - and making it shorter would have been worse - with termination not secure:-) I hope that the painful length does not obscure - valid concern - constructive suggestions

27 87

ROUTE objects for non RIPE resources
by denis 10 Mar '16

10 Mar '16

Hi guys For the last 2 or 3 RIPE Meetings a conversation has started just before the meeting and carried on during the meeting. It is the same conversation about what to do with ROUTE objects in the RIPE Database for non RIPE resources. The same possible solutions have been proposed at each meeting. By the end of the meeting the same conclusion is drawn...something needs to be done. Then.....silence....until just before the next meeting when the cycle is repeated. In fact if you look at the archive for the routing and DB WGs nothing has been said about this on the mailing lists since the start of RIPE 71. So are we going to have this same conversation just before RIPE 72 and end with the same result? Or do you think we could break this cycle and have a different conclusion...decide to do something instead of deciding something needs to be done. Subtle but significant difference. The simple solution I proposed that would solve the consequences of having these ROUTE objects in the RIPE Database was on the table 18 months ago. Most of the software building blocks for it already exist in the database software, so it could be implemented in a month or so. Even if this is not the final solution, as a temporary fix it could be up and running so easily and improve the confidence in the IRR. cheers denis

1 0

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by h.lu＠anytimechinese.com 08 Mar '16

08 Mar '16

Hi I fail to understand how spammer are legal in certain country has to do with my reasoning or logic. The argument is about if there is managing position for community to take, my answer is no, we are not law enforcement and we only do book keeping, we don't tell people what to do, if they want to be good guy, great, if they don't care about spam or any abuse so to say, ok, it's their call. Making things mandatory with no real enforcing power are just not working. So make logic simple to understand, if the abuse is serious as crime, you don't need abuse c to get the right person(law enforcement has much better way than ripe db), if it is not serious as crime, if the op cares, with or without abuse c they will have their abuse contact there, and will deal with it. For ops don't care, with or without abuse c, they still don't care. So you can put up an extra line ask people to fill, but I don't think it makes much difference. > On 4 Mar 2016, at 20:00, Jeffrey Race <jrace(a)post.harvard.edu> wrote: > > Dear Lu, > > Your reasoning fails the logic test because you do not cognize the mismatch > between the operation of "law to enforce things" and the spammer business > model. The loss to no single victim rises above the threshold to initiate > either criminal or civil proceedings. The spammers organize their business > model in this way expecting most people to have your attitude. > > This is clearly explained in > > <http://www.jeffreyrace.com/nugget/spam_05.pdf> > > Kind regards, > > Dr. Jeffrey Race, President > Cambridge Electronics Laboratories > 20 Chester Street, Somerville MA 02144-3005 > Tel +1 617 629-2805 Fax +1 617 623-1882 > > Avoid spinal damage from computer use! > Read "Cripples by Thirty?" > > <http://www.camblab.com/nugget/nugget.htm> > > --Original Message Text--- > From: Lu Heng > Date: Fri, 4 Mar 2016 14:20:28 +1300 > > Hi there: > > I think the whole notion about we are managing the internet though the policy are not correct. > > > We are not managing the internet, we are book keeping really. > > > Denis, your argument standing on a group that if we do not manage the internet, the gov will step > in and do it for us, but that is largely untrue. > > > The Gov are managing it now as we speak, they have something called law to enforce things, they > really don't need bother to go though policy here to block content they dislike, bust people they > think are bad, find people are responsible, if there is a seriou crime going on, with or without > abuse-c, gov will find them or not---abuse c does not change the outcome. > > > Take China for example, A 500 m user can not access Facebook, tell me they go though any sort of > APNIC policy to do that, same goes for some countries inA Middle East. > > > So my last point is. If you like their gov job, you can apply one, don't try to push community here > to do gov's job. > > > On Friday 4 March 2016, denis <ripedenis(a)yahoo.co.uk> wrote: > Hi Peter > > OK lets cut to the bottom line. Does anyone NOT agree with these points: > > -Internet abuse (in it's various forms) is considered both a nuisance and a danger by the publicA > -Politicians will jump onto any band wagon that has popular public support and enhances their > careers > -Responsible internet resource management includes receiving and handling abuse complaints related > to the networks you manage > > If we all supported these points, especially the last one, then in an ideal world all network > managers would be happy to provide abuse contact details and would take action on complaints > received. > > Unfortunately we don't live in that ideal world. The fact that so many experienced technical > internet people are opposing this policy worries me. So many of you are fixating on this point > about 'mandatory', 'enforcing', 'justifying'. If everyone agreed with point 3 above then you would > all be willing to do this voluntarily anyway. So what difference does it make to those of you who > do this anyway if it is mandatory? > > But we know some people simply can't be bothered to handle abuse complaints and we also know some > people make money by providing services to the abusers. There is no point pretending this does not > happen. If there is a lot of money to be made some people will want a slice of it. That is why this > has to be mandatory. > > When abuse-c was first introduced it was made clear that this was the first step of a process. The > intention was for all IP addresses within the RIPE region to have one common way of documenting an > abuse contact that can be accessed programatically. It was also made clear that this first step had > nothing to do with whether anyone responds to reports sent to that contact. Because it was and > still is clear that some people don't want to publicise any abuse contact details it had to be and > still has to be mandatory. If you enter data into the RIPE Database you are required to ensure it > is correct. Dealing with whether anyone responds to the reports sent to this contact is a separate > issue and should not cloud the discussion on the abuse-c information in the RIPE Database. Neither > should the technical implementation of the abuse-c attribute. > > I know there are policies about policies for legacy resources. Personally I think that is crazy. > All IP addresses are technically the same no matter how or when you acquired it. Abuse can come > from any one of them. > > I don't know why we are making the policy side so complicated. The principle is simple. If you > manage IP addresses in the public domain, from where abuse can be generated, responsible management > requires you to provide abuse contact details!!! > > cheers > denis > > On 03/03/2016 23:30, Peter Koch wrote: > On Thu, Mar 03, 2016 at 11:46:45AM +0100, denis wrote: > > In these days of political interest in how the internet is 'managed' the > RIRs need to do more than 'just maintain an accurate registry'. The > > > indeed. The community should be careful to maintain and improve the > credibility and legitimacy of its policy development process. > ``Extra constitutional'' activity (imposing "abuse" handling procedures > camouflaged as syntax changes to database objects) and retroactive > changes to policy without an exceptional justification both aren't > helpful. > > 2016-01 claims "Better data quality", which is not backed with arguments. > 2016-01 claims "More accurate data for abuse contact", which is not > A A A A A supported by arguments or evidence/precedent. > > internet is a crucial part of modern life. Abuse is considered to be a > serious problem. What you are saying is that you don't give a dam about > abuse and are not interested in being part of the management of abuse. > > > The alleged correctness of data does not imply a "right to response" (cf ripe-563), > and rightfully so.A Therefore the claims that refusal to add abuse-c > would imply refusal to deal with abuse reports are pointless, since > the sheer presence of the attribute does not imply anything, either. > > Also, I have not heard RA¬diger (or anyone else) claim they would not > want to even add abuse-c - it's making this policy mandatory what is > being contested.A ripe-639 re-establishes the 'special role' of > legacy resources as exempt from policy changes: > > A A A A Any existing or future RIPE policy referring to resources shall not apply > A A A A to legacy resources unless the policy explicitly includes legacy resources in its > scope. > > Now, if that was simply a matter of a boilerplate in any future policy > (xxx shall also apply to legacy resources), this clause would not make > the slightest sense.A Consequently, a special consideration is needed. > 2016-01 simply refers to inconsistency (obviously a simple consequence > of ripe-639 and thus not exceptional) and "better data quality" - without > justification.A No indication is given of any harm caused by legacy > resources currently not subject to ripe-563.A ripe-563/ripe-639 > do not preclude use of abuse-c for legacy resources, either. > > All in all, I understand the motivation behind 2016-01, but the reasoning > is far too poor to justify proceeding with the proposal. > > -Peter > > > > > > > > -- > -- > Kind regards. > Lu > > > > > > >

9 19

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by h.lu＠anytimechinese.com 05 Mar '16

05 Mar '16

Hi guys: I think I really should make myself clear here. (Sorry for sending 3 mails in a row as I just realise people are taking to me one by one) I do not against abuse c or support it, I just don't think it will make much difference. That's all I have to say about abuse c. However, I do against the idea "if we not managing the internet the gov will step in and take over". The last thing I would want the community is doing the gov's managing job for them. So that's what my last email about. > On 5 Mar 2016, at 08:32, andre(a)ox.co.za wrote: > > On Fri, 4 Mar 2016 17:55:16 +0000 > Michele Neylon - Blacknight <michele(a)blacknight.com> wrote: > <snip> >> >> We are not managing the internet, we are book keeping really. > [...] > > If you are correct (and imho you are) > > the whole point of book keeping is to have accurate data and records > > so, pick your poison. All POV leads to exactly the same thing: the ncc > needs accurate abuse-c as much as any of the other data.

1 0

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal
by Marilson 04 Mar '16

04 Mar '16

Hello I am also impressed and concerned with the old, inopportune and improper posture of the gentlemen Randy Bush and Gert Doering. Denis, it is gratifying to hear someone concerned about the future of the Internet and with the exponential increase in the abuse. Greed, not wanting to plagiarize Gordon Gekko, reigns absolute and moves the wheels of the global economy. The agenda is: cheat as much as you can, just try not to get caught. HSBC and Volkswagen are the portrait of this posture unethical where the end, profit, justifies the means. You all have the opportunity to do the right thing. How do you want to be remembered? Or you start a remediation process of such abuses or will be done by rulers (governments) pressured by the world's population. Thanks Marilson

3 2

Cleanup work for "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06
by Tim Bruijnzeels 04 Mar '16

04 Mar '16

Dear working group, As you know, the RIPE NCC completed the work for the 2011-06 policy on 15 February, and "abuse-c:" is now added to all organisations that hold resources allocated or assigned by the RIPE NCC. Going forward we propose to: - Remove "abuse-mailbox:" for all ORGANISATION objects that *have* "abuse-c:" in a one-off operation - Introduce a business rule to prevent adding "abuse-mailbox:" to ORGANISATION objects, urging people to use "abuse-c:" instead Please note that the proposal above does not force anyone to use "abuse-c:", it just enforces that "abuse-c:" is used instead of "abuse-mailbox:". Having both attributes on an ORGANISATION object is extremely confusing, and currently updating "abuse-mailbox:" does not work in the LIR Portal organisation object editor. We therefore believe that the cleanup is needed, and we hope that this will not be controversial. We would like to ask the working group for the mandate to do the cleanup proposed above. Originally the intent was to clean up "abuse-mailbox:" on all objects (except in abuse-c roles) and possibly IRT objects. However, we are fully aware that more controversy exists here. There is a lot of discussion about whether "abuse-c:" can be mandatory for organisations holding legacy resources (2016-01). Questions are being raised about the data model. We are following these discussions with interest and we believe that this part of the originally proposed cleanup should be put on hold until we have a more clear direction from those discussions. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

2 1

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by Gert Doering 03 Mar '16

03 Mar '16

Hi, On Thu, Mar 03, 2016 at 12:56:05PM +0200, andre(a)ox.co.za wrote: > it is actually very simple: > > any rigorously correct resource allocation registry data must > include accurate abuse records. No. It needs to contain accurate records of who has been delegated responsibility for that (admin-c / org). abuse-c is a way to ease finding the *right* contacts instead of always having to write paper mail to the company CEO - and that makes sense, but it's a convenience to operators (as is tech-c), and in no means required for the function as registry. Which might conincide with the fact that the paperwork you sign when opening a LIR has no field for abuse-c... 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

4 4

[training] RIPE NCC Training Courses April-June 2016
by Training Services 29 Feb '16

29 Feb '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Budapest, Tirana, Manchester, Lisbon, Bologna, Munich, Tallinn, Moscow, Vienna, Valletta, Reykjavik. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

RIPE DB services downtime
by Thiago da Cruz Pereira 19 Feb '16

19 Feb '16

Dear working group, Later today, we’re going to restart our servers to apply a patch. A short downtime to updates is expected and queries will not be affected. Kind regards, Thiago da Cruz Software Engineer - Ripe Database Team

1 1

RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
by Tim Bruijnzeels 19 Feb '16

19 Feb '16

Dear working groups, As you know all organisations that have internet number resources allocated or assigned by the RIPE NCC need to have an abuse-c attribute according to policy 2011-06. The following implementation plan was communicated for this policy: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… Phase 1 of this plan was completed in December 2013, setting up abuse-c for then existing LIRs. Phase 2 of this plan was completed for organisations holding sponsored PI resources in November 2014. However, since then LIRs and end-users have been responsible for ensuring that an abuse-c exists for their organisation. In practice it has proven difficult to enforce this, since abuse-c is not a mandatory attribute in the RIPE DB schema, and as a result new cases where organisations do not have an abuse contact have been created. There is an important change in the implementation we would like to do – based on our experiences thus far – which would like the community's mandate on. We propose to use the end-user organisation's email address instead of the sponsoring LIR email address. We believe there are valid reasons for this change, but of course if this suggested change is controversial we would encourage discussing it in the anti-abuse working group. Ideally, we need to have a decision on this by early January so that we can prepare the work. 1) Prevent NEW cases We want to ensure that no new cases will be created as follows: = Since 1 March, the new member application form already provides much better integration with the RIPE Database - because of this an abuse contact is now created whenever a new LIR is activated - it can be modified the LIR, e.g. using web-updates, but not removed = We are currently adapting the new create organisation webupdates form to include abuse-c by default allowing the user to: - reference an existing abuse-c role object, or - enter an email address to create an abuse-c role for the organisation (using the same maintainer) = We are also adapting the edit organisation webupdates form to always suggest adding an abuse-c contact if it's not present = We plan to extend the new request forms: - check that an end-user organisation has abuse-c before it can be used - if not, refer to the edit form for the organisation where it will be easy to add reference an existing abuse contact, or create a new object 2) Resolve remaining EXISTING cases Originally the idea for phase 2 was to use the sponsoring LIR's email address in case the end-user organisation was unresponsive to requests to set their own abuse contact. However, since then policy 2012-08 has been implemented and nowadays the sponsoring LIR, and its abuse contact, can be found through the sponsoring-org attribute. Also, the RIPE NCC found that using the sponsoring organisation's email address leads to a number of issues: - end-users have no incentive to set their own abuse-c, rather then letting abuse questions go to their sponsor, so the majority remains unresponsive - in case an end-user has resources from more than one sponsor it is ambiguous which sponsor's email should be used - many LIRs were unpleasantly surprised by finding their email address in the abuse-c of the organisation they sponsor - in case LIRs no longer wish to sponsor resources, or when they are returned, existing references to their email in the end-user abuse-c are not cleaned up We would therefore like to propose a change to the implementation plan when addressing the remaining cases. Today, in case no abuse contact is set, users of the database will resort to using the organisation's default email. Therefore, adding a dedicated abuse-c role object using this email address, doesn't cause any noticeable new effects on organisations. It may well be the correct email address to use for an organisation, and no action would be required. However, it *enables* an organisation to use a different email address for abuse questions if appropriate. We would like to email remaining LIRs, and end-user organisations and sponsoring LIRs on Monday 1 February, giving them until Monday 15 February to set their abuse contact. We realise that this means we would have another delay, but we believe that it would be unwise to do this change over the end of year holiday period, and to ensure that we can give proper support to questions we want to avoid doing this at the same time as the start of the year invoicing. Please let us know what you think. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14