August 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

all quiet
by ripedenis＠yahoo.co.uk 02 Sep '16

02 Sep '16

Hi guys It has been pretty quiet on this WG for a while. But I hear from 'sources close to the NCC' that they have been doing some amasing improvements to the Webupdates service. In my day at the NCC there was a manager who said she didn't know what I did (which says more about her than me). One of the many, many, many, many things I did was to let the world know what we were doing. So come on guys, don't be shy, let us all know what is cooking so we can all rejoice in your achievements. cheersdenis

5 5

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] [anti-abuse-wg] Definition of Abuse - preamble
by Marilson 25 Aug '16

25 Aug '16

Andre, Is praiseworthy your efforts as was the effort by Denis in this group. Sometimes I have the impression that you guys are giving punch in knife tip or barking up the wrong tree. The current discussion seems to seek answers at the semantic. And the idealization of the concepts and definitions begin to collide with the use of a language that is not native to all, as well remembered by Gunther Nitzsche in his last intervention. You are one step closer to doing what Gunther's ancestor did in the century XIX discussing On the Genealogy of Morality (F. Nietzsche) beginning to investigate the root of a single word: the word abuse. What is its genesis? And more importantly, what are the conditions of its genesis? Will discuss in the light of the uses and customs of the present age but there will no consensus. Anyway, I'll put the ball on the ground and try to give my definition of abuse in the most practical way possible, with my English. CAUSE AND EFFECT First remember that I am not an IT professional and I have no concern with possible abuses that ISPs, Registrars and RIRs may suffer. They have professionals and tools to care for themselves. What matters are the billion people on the planet victims of abuse as never before happened. Today the barbarian hordes do not invade the villages with their horses. They remain comfortable and cowardly sitting in front their keyboards stealing and angering millions of people every day - and properly protected and hidden under the cloak of pernicious "protect service". Today barbarians have a new name: coward psychopaths. DEFINITION AND SOLUTION There is nothing more dispensable than the definition of abuse. It is explicit in all AUPs, TOSs and ASPs that govern all contracts between these companies and their customers. Nothing is easier to implement than a solution to end the abuse. I have the perfect recipe: a dose of shame, a dose of honesty, a drop of ethics and a spray jet in the nose with Syntocinon to replace the Oxytocin that the hypothalamus of psychopaths do not produce - empathy. In other words, providers just need to put into practice what their AUPs, TOSs and ASPs, abundantly displayed on their websites, contractually determines. Losses and damage from such abuse are solely the responsibility of those companies. REGULATION AND MODUS OPERANDI If a victim denounces, with evidence, a customer of an ISP, the ISP must contact and warn his customer. If this victim denounce for a second time the same client, the ISP is obliged to penalize his client. In the third complaint ceases to be abuse to be a crime. Here it is characterized conspiracy to the practice of crime. And that is the psychotic posture, dishonest and greedy of most ISPs. No matter if we are denouncing a spammer or scammer. And by insisting on the complaint, copying to various institutions and to the media, the retaliation will be inexorable. Every crime is an abuse but neither all abuse is a crime. PROGNOSIS Nothing will be done. The status quo shall prevail. Marilson

1 0

NWI-3 - AFRINIC IRR Homing
by Job Snijders 16 Aug '16

16 Aug '16

Dear Working Group, (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) NWI-3 - Afrinic IRR Homing -------- In recent years Afrinic set up an IRR instance that enforces authorisation for ROUTE(6) objects at rr.afrinic.net And while the general problem of out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database IRR, and the problem where the prefix and the ASN belong to different regions is not trivial to resolve, there seems to be a general consensus that simple cases where ROUTE(6) objects have both an ASN and prefix in Afrinic (~34k objects), should appear in the Afrinic IRR where authorisation can be done and not in the RIPE DB. Complicated cases where the prefix is in Afrinic, but the ASN is another region -or- where the ASN in Afrinic, but the prefix is out of region are out of scope for this NWI. -------- Some of you might wonder why this topic is back on the table. The chairs felt that it would be most appropiate to follow our new NWI formal process to help progress this work. Working group participants, if you agree/disagree with the above problem statement please voice your opinion. If you have suggestions to refine the text that is welcome too. Kind regards, Job

12 28

Progress on Number Work Items
by Tim Bruijnzeels 02 Aug '16

02 Aug '16

Dear working group, We currently have the following NWIs: NWI-1 Staying on top of abuse contact changes State: Problem Definition 3 messages 3 participants last message: 27 June 16 NWI-2 Displaying history for database objects where available State: Problem Definition 10 messages 5 participants last message: 12 July 16 NWI-3 AFRINIC IRR homing State: Solution Definition 18 messages 8 participants last message: 1 August 16 NWI-4 Role of status: field in multivalued status context State: Problem Definition 4 messages 3 participants last message: 27 June 16 NWI-5 Out of region ROUTE(6) / AUT-NUM objects State: Problem Definition 3 messages 3 participants last message: 28 July 16 NWI-6 Applicable data model not clear from contextless objects State: Problem Definition 3 messages 3 participants last message: 28 June 16 The progress on numbered work items (NWIs) is also available on the web site: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items

1 0

Conditions for Transferring or Making Available NRTM Data
by Tim Bruijnzeels 01 Aug '16

01 Aug '16

Dear colleagues, Some users of the Near Real Time Mirroring (NRTM) Service may wish to transfer or make data from the service available to third parties. In order to make the process clearer, the RIPE NCC has now published conditions for doing so: https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring/conditions-for-t… <https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring/conditions-for-t…> If you are interested in using the NRTM Service this way, please follow the link above to read the conditions and find instructions for submitting a request. Kind regards, Tim Bruijnzeels Assistant Manager Database Group RIPE NCC

1 0