- db-wg - mailman.ripe.net

Progress on Number Work Items
by Trudy Prins 01 Sep '16

01 Sep '16

Dear working group, as usual at the beginning of every month, here is an overview of all open Numbered Work Items. 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 30 messages 11 participants last message: 16 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 <https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items> Regards, Trudy Prins Manager SWE RIPE NCC

1 0

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

NWI-5 - Out of region ROUTE(6) / AUT-NUM objects
by Job Snijders 28 Jul '16

28 Jul '16

Dear Working Group, This is a slighly longer problem statement, please bear with us. There has been a LOT of discussion about the problems related to out-of-region ROUTE(6) and AUT-NUM objects in the RIPE Database. We would like to provide a starting point of the problem definition here, and ask the community to discuss it further. NWI-5 - Out of region ROUTE(6) / AUT-NUM objects ---------- The RIPE Database Internet Routing Registry (IRR) requires authorisation to create ROUTE(6) objects, by the appropriate maintainer for the covering inet(6)num object - or an existing covering ROUTE(6) object for the prefix in the "route(6):" attribute, as well as the appropriate maintainer for aut-num object matching the "origin:". For resources within the RIPE region this authorisation is covered by either: * Objects that RIPE NCC creates upon assigning or allocating resources to LIRs or end-users with a sponsoring LIR * Objects held by legacy resource holders (authorisation may be delegated to others by holders of these objects) However for out-of-region space the authorisation is different. Because out-of-region resources are not maintained in the RIPE Database there are no proper maintainers in the RIPE Database to authorise the creation of such objects. Because there is a need for having ROUTE(6) objects for these routes, and there were no authoritative alternative IRRs available, the RIPE community decided to support the creation of these objects in the RIPE Database IRR through the use of placeholder objects for out-of-region IP resources and ASNs. In case of IP resources the INET(6)NUM objects delegate authorisation to create route objects through "mnt-routes:" to a special use maintainer with a well-known password: RIPE-NCC-RPSL-MNT. In case of out-of-region ASNs the RIPE NCC maintains placeholder AS-BLOCK objects. Since "mnt-routes:" does not exist on AS-BLOCK objects the RIPE-NCC-RPSL-MNT is added to "mnt-lower:" here instead. Any user of the database can therefore create a AUT-NUM object for an out-of-region ASN, and use it to authorise ROUTE(6) objects. There are a number of problems resulting from this approach: * Authorisation for out-of-region objects is anecdotal * Globally duplicate AUT-NUM objects are required for out-of-region ASNs, confusing contact information, policy etc * This facilitates hijacking for out-of-region resources and RIPE NCC is neither mandated nor staffed to deal with these issues. * Detailed placeholders need to be maintained, which causes overhead especially w.r.t. inter-RIR transfers --------- We invite the working group to better define this problem definition so that a structured discussion about (partial) solutions can follow. Kind regards, Job

3 2

Re: [db-wg] NWI-3 - AFRINIC IRR Homing
by Daniel Shaw 20 Jul '16

20 Jul '16

> > 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. > Hello NCC DB WG, Just a note to mention that AFRINIC supports this as a valid problem statement and is looking forward to working with you on the solution phase. Cheers, Daniel

1 0

NWI-2 - displaying history for DB objects where available
by Job Snijders 12 Jul '16

12 Jul '16

Dear Working Group, This is the second Numbered Work Item. (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-2: The RIPE NCC was tasked with the following action point: AP69.2 [RIPE NCC] Come up with some straw man proposals for displaying history for objects where available. The RIPE Database already provides a mechanism for object history. In our understanding the problem statement that motivated the action point is that some people are interested in seeing the history of *deleted* objects. It is our understanding that this interest is mainly focussed on primary (resource) objects. However, it is not entirely clear to the RIPE NCC why this is useful. We also have some concerns, mainly non-technical, and therefore we believe that the problem statement and motivation needs to be better defined in the working group. --------- The next step is to help refine the problem statement. I would appreciate it if working group participants with an interest in the history of objects speak up and elaborate on the issue. Kind regards, Job

7 9

Progress on Numbered Work Items - July 2016
by Job Snijders 09 Jul '16

09 Jul '16

Dear working group, As discussed during the Database Working Group session at RIPE 72, we have now published the new process, as well as an overview of the ongoing Numbered Work Items (NWIs) here: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items We currently have the following five NWIs, all in state "Problem Definition": NWI-1 Staying on top of abuse contact changes (2 responses) NWI-2 Displaying history for database objects where available (some discussion involving 3 people) NWI-3 AFRINIC IRR homing (5 responses) NWI-4 Role of status: field in multivalued status context (2 responses) NWI-5 Out of region ROUTE(6) / AUT-NUM objects (zero responses) <!--- ?!?! NWI-6 Applicable data model not clear from contextless objects (2 responses) Kind regards, Job

1 0

NWI-6 Applicable data model not clear from contextless objects
by Job Snijders 28 Jun '16

28 Jun '16

Dear WG, Please review the below problem statement: -------- NWI-6 - Applicable data model not clear from contextless objects Currently it is not possible to derive what semantics or data model applies to a RPSL object in the RIPE database. This disadvantageous property introduces complexity all across the board: - redefining the semantics of an existing RPSL attribute introduces operational complexity. - operators have precisely align their client-side software deployment with the RIPE database deployment timeline. - deprecating RPSL attributes which are "mandatory" (as defined in the RPSL dictionary) is challenging as a client cannot know if the object stems from a time in which the attribute was mandatory or not. - objects which are provided without historical context are hard to parse, one cannot programmatically know how to interpret the attributes or assess which attributes should have been there. ------- As author of this problem statement and co-chair of this Working Group I have the following notes I'd like to share. Reflecting on the past period in which I was tasked to assist the group in helping the database progress, I've observed that any change or even proposal for change in the database is easily met with detestation. A recurring theme is that post-deployment people comment "I was not expecting this", and before in the proposal phase other stakeholders state "this is too complex to deploy, we'll break old clients". I believe that if we somehow address the issue of introducing change _itself_, we'll garner a crucial feature which will be rewarding in whatever direction the database takes in future.

3 2

NWI-4 - role of status: field in multivalued status context
by Job Snijders 27 Jun '16

27 Jun '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-4 --------- The RIPE NCC was tasked with the following action point: AP70.2 [RIPE NCC] Come up with a proposal for the status: field to fix the requirement that certain objects may need multivalued status. Some believe that the main underlying issue here is that it is currently not possible to create an assignment that is the same size as an allocation in the RIPE Database. And resource holders are of course supposed to create an assignment for the address space in an allocation that is in use, by address policy. The main reason for this limitation is that the INET(6)NUM attribute is a primary key. There is a work-around for this problem. Instead of creating an assignment of the same size it's possible to create two smaller assignments instead. In our (red: RIPE NCC) experience this work-around has always been accepted. Still if the allocation is used as a whole, having a single assignment for the whole block is a more accurate reflection of reality, and it reduces the amount of objects to maintain. ---------- The AP70.2 action point refers to a suggest solution, following earlier discussion. But the chairs believe it would be good to bring this back to a clear problem statement first, and then suggest different solutions and their respective benefits and/or problems. Furthermore address-policy wg policies mention the different statuses and what the different statusses reflect. Therefore we'll need to inform the address policy working group as well. If you agree or disagree with this problem statement, please indicate your opinion on this mailinglist. Refinements to the text are welcome too. Kind regards, Job

3 3

NWI-1 - staying on top of abuse contact changes
by Job Snijders 27 Jun '16

27 Jun '16

Dear WG, This is our first Numbered Work Item! We are now in phase 1. (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.) The following preliminary problem statement has been put forth by Denis & Piotr: "The resource holder could be unaware of changes made to the abuse contact details for his/her resources. This could happen as a result of any addition, change or deletion of any part of the abuse contact details put in his/her ORGANISATION object ("abuse-c: attribute, referenced ROLE object, "abuse-mailbox:" attribute)." I ask the working group whether they agree with this problem statement, they can identify with the problem, whether the statement needs amendments. Kind regards, Job

3 3

Deployed 1.87.4 with two fixes for business rules
by Tim Bruijnzeels 22 Jun '16

22 Jun '16

Dear working group, We deployed version 1.87.4 to production earlier this week with two fixes for business rules that impacted a number of users: 1) It was not possible to set "mnt-lower:" on INET6NUM objects with status "ALLOCATED-BY-RIR". This restriction existed when object editors were used, but was ignored at that time because object editors used a different authorisation method. The restriction has now been removed. 2) The fix in 1.87.3 allowed "netname:" to be changed on objects with status "ASSIGNED PI", but unfortunately not for other "ASSIGNED" objects. We have made sure that the restriction only applies to INET(6)NUM objects for allocations done by the RIPE NCC. To summarise the following business rules apply to objects that are 'co-maintained', i.e. allocations, assignments or legacy space that is registered with RIPE NCC: = Allocations INETNUM objects with "status:" ALLOCATED PA, ALLOCATED PI or ALLOCATED UNSPECIFIED, and INET6NUM objects with "status:" ALLOCATED-BY-RIR Restricted attributes: netname, org, sponsoring-org, status, mnt-by (you can only change your default maintainer through the LIR Portal) = Assignments INET(6)NUM objects with at least one RIPE-NCC-XYZ-MNT and "status:" ASSIGNED PI, or ASSIGNED ANYCAST Restricted attributes: org, sponsoring-org, status, mnt-by (you cannot add or remove RIPE-NCC-XYZ-MNT) and mnt-lower = Legacy space registered with RIPE NCC INETNUM objects at least one RIPE-NCC-X-MNT and "status:" LEGACY Restricted attributes: org, sponsoring-org, status, mnt-by (you cannot add or remove RIPE-NCC-XYZ-MNT) In addition to this, all objects described above can only be deleted by RIPE NCC. I hope this makes it clear how we apply business to these objects. If you have any questions or comments, please let us know. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

Organisation Names in "descr:" cleaned up and no longer enforced
by Tim Bruijnzeels 08 Jun '16

08 Jun '16

Dear working group, As we just announced on the ncc-announce mailing list, we have completed the clean up of "descr:". Resource holders who configured "notify:" were alerted about this cleanup. We updated the RIPE Database to version 1.87.3 in order to make "descr:" on allocations editable by LIRs. Please let us know if you find any issues. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

3 2

Faked entries in the RIPE db
by Dickinson, Ian 02 Jun '16

02 Jun '16

There appears to be abuse happening in the RIPE db - presumably to allow other online activity to be done with abuse indirection to an innocent bystander (e.g. my employer) - all over the last day or two... The specific items I noticed are all inet6num maintained by BSKYB-BROADBAND44-MNT, along with BSKYB-BROADBAND44-MNT itself, and ORG-BBH4-RIPE and ACRO772-RIPE This was due to the fake objects referring to our real role/person objects. It appears that there are many other faked entries under 2a07:7ec0::/29 - pretending to be Deutsche Telekom or Time Warner Cable for example. Either that LIR is a bad actor, or their maintainer credentials have been 0wned. This needs to be killed off. Cheers, -- Ian Dickinson Network Architect Sky Network Services ian.dickinson(a)sky.uk Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

3 4

Progress on Number Work Items - June 2016
by Tim Bruijnzeels 01 Jun '16

01 Jun '16

Dear working group, As discussed during the Database Working Group session at RIPE 72, we have now published the new process, as well as an overview of the ongoing Numbered Work Items (NWIs) here: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items For the impatient, we currently have the following five NWIs, all in state "Problem Definition": NWI-1 Staying on top of abuse contact changes NWI-2 Displaying history for database objects where available NWI-3 AFRINIC IRR homing NWI-4 Role of status: field in multivalued status context NWI-5 Out of region ROUTE(6) / AUT-NUM objects Please let us know if you have any questions or comments. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

2 1

Deployed 1.87.1 to RC - supporting business rules that allow phasing out object editors
by Tim Bruijnzeels 27 May '16

27 May '16

Dear working group, We deployed release 1.87.1* to RC today. This new Database release introduces several business rules that allow us to phase out object editors for LIRs in the near future. As announced by Alex Band to the services working group on 21 April: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2016-April/002999.h… Since this release does not introduce any other functional changes, we believe that a one week RC test period should be enough. And we propose to deploy this release to production next Wednesday 11 May, unless of course issues are found or concerns are raised. The new business rules ensure that once an LIR maintainer is added to "mnt-by:" of an LIR ORGANISATION object and/or INET(6)NUM objects for LIR allocations, attributes that are maintained by RIPE NCC remain maintainable by RIPE NCC only. For organisation objects the following attributes will not be modifiable by the LIR: "organisation:"**, "org-name:", "org-type:", "address:" ***, "phone:" ***, "fax-no:" ***, "email:" ***, "mnt-by:" **** For inet(6)num objects the following attributes will not be modifiable by the LIR: "inetnum:"**, "netname:", "org:", "sponsoring-org:" (on assignments, included here for completeness), "status:", "mnt-by:" **** Please note that these changes only come into real effect after we deploy changes to the LIR Portal that allow LIRs to select a maintainer to use. We are working hard on this at this moment, but we are not sure whether we can have these changes ready before the RIPE Meeting, or that we will have to wait a bit longer. Of course we will communicate how this changes the way that LIRs can maintain their objects before that time. Please let us know if you find any issues or have any concerns or questions, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group *: Note that we caught a small issue internally before we planned to deploy 1.87, hence the version currently deployed is 1.87.1. **: primary key, so not modifiable - included here to make it clear that these objects are created by RIPE NCC ***: These fields will remain modifiable through the LIR Portal only for now, since they are stored both in the RIPE NCC internal member database and the RIPE Database ****: During the first phase of this effort the LIR can only choose one MNTNER to use, through the LIR Portal

2 2

Re: [db-wg] Geolocation in the RIPE Database
by Wilfried Woeber 25 May '16

25 May '16

On 2016-05-25 20:25, Job Snijders wrote: > Hi wilfried, > > Would you be willing to work with the chairs to formulate a problem statement and follow the NWI process? Sure :-) I guess it would be reasonably easy, along the following lines: - functionality was introduced to "test the waters" - it never became obvious how to maintain it or which party would actually be allowed or mandated to manage the entries - whatever rudimentary functionality there was/is, it is not helping the "victims", ie. the end users - geo-location is better (but not nearly good![1]) maintained by entities like maxmind - geo-location is pretty far out from the mandate of the Resource Registry - there was never a common understanding, how to deal with assignments within an LIR with global or at least continental or regional coverage - we never had any sense of applicable granularity of longitude/latitude or national boundaries - we never got useful feedback on the usefulness or "consumer processes" for this particular dataset - all of that related to the 1st entry in this list :-) Wilfried [1] the RIPE Meeting Network here in Copenhagen is still considered to be located in Romania, with all the ill-advised side effects... > Job > > Original Message > From: Wilfried Woeber > Sent: woensdag 25 mei 2016 20:08 > To: Tim Bruijnzeels; Database WG > Subject: Re: [db-wg] Geolocation in the RIPE Database > > > Hi Tim, DB-WG community! > > On 2016-05-25 19:51, Tim Bruijnzeels wrote: >> Dear working group, >> >> We have an update with regards to the following action point: >> AP69.3 [RIPE NCC] To examine and report on possible solutions to improving geolocation >> data in the RIPE DB (Ongoing but if no progress by RIPE 72 then kill it) >> >> Following a decision by the RIPE NCC Executive Board not to support resource expenditure >> in the area of geolocation services, the RIPE NCC has no plans to examine this further. > > I can easily relate to this decision and can easily "accept" it. > > But as a consequence, I'd like to propose to *discontinue* all geo-location > related functionality in the Resource Registry as soon as possible. > > Regards, > Wilfried > >> A write-up is published on our website: >> https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… >> >> Kind regards, >> >> Tim Bruijnzeels >> >> Assistant Manager Software Engineering >> RIPE NCC Database Group > > >

1 0

Geolocation in the RIPE Database
by Tim Bruijnzeels 25 May '16

25 May '16

Dear working group, We have an update with regards to the following action point: AP69.3 [RIPE NCC] To examine and report on possible solutions to improving geolocation data in the RIPE DB (Ongoing but if no progress by RIPE 72 then kill it) Following a decision by the RIPE NCC Executive Board not to support resource expenditure in the area of geolocation services, the RIPE NCC has no plans to examine this further. A write-up is published on our website: https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

3 2

proposal for a review of the RIPE Database data model
by ripedenis＠yahoo.co.uk 24 May '16

24 May '16

HI All Piotr asked me if I would have time to write a short problem statement about the data model for consideration as an NWI. For once I will try to make it brief(er). Current model developed in late 90s as a further development of the previous RIPE Database design from much earlier. Nothing fundamental has changed in the last 15 years. It makes virtually no use of inheritance which has led to massive amounts of duplicated data, with all the problems of managing and interpreting that data. It was designed in a day when it was more normal to manage data by sending and receiving emails. Although I welcome the improvements to Webupdates, this feature is still something bolted on to the side and not fundamental to the design. There is no concept of 'user accounts' beyond SSO (another feature bolted on) so it is not possible to manage your data online and set permissions or do any configuration. The database contains two basic types of data: 1/ Operational data as determined by the purpose of the database 2/ Organisational and security data for the management of the operational data Far too much of the security and organisational management data is public. How I secure my data and who, within my organisation, has permission to do what is non of your business. That information is confidential to my organisation. With user accounts that can all be kept confidential. The lack of business rules and constraints in the early days of the database allowed massive misuse of the original design. Especially in the area of PERSON, ROLE and MNTNER objects. A lot of the relationships between these objects and others is totally screwed up now making management, security and interpretation of the data far more complex than it needs to be. Over the last 12 months I have pointed out so many examples on the mailing list of how things are over complicated, or cannot be changed, or features that cannot be implemented because of the constraints of this data model. The most recent example being a very good suggestion by someone to customise the notification message and define a simple rule set for sending them out as part of a bulk update. This cannot be done by the database software based on this data model. It has to be done externally by the NCC staff by analysing the data involved in the bulk update, building the customised notification messages and sending them out with an email client. What I am suggesting is a serious review of the data model and the database design to identify areas that could be improved in an organised, backwards compatible, step by step process. It is also important to stress what I am not suggesting as this topic seems to carry as much negative propaganda as the UK's foolish, brexit campaign. I am not suggesting a team of engineers hide in a dark room for a year then launch a completely re-designed data model on the community and force you all to change all your tools used to engage with the database overnight. That is not how software is developed these days. Small steps, backwards compatible, testing, reviews, run in parallel, slowly moving forwards. That is how software is developed these days. On this basis I put this forward for consideration as an NWI. cheers denis

2 1

RIPE 72 DB-WG agenda V2
by Piotr Strzyzewski 24 May '16

24 May '16

Dear DB-WG Members This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE72 at the Tivoli Hotel & Congress Center in Copenhagen, Denmark. The DB-WG Meeting is scheduled as usual for Thursday, May 26th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 72 meeting plan please refer to its most up-to-date version at https://ripe72.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. RIPE DB development process: Numbered Work Items (Job Snijders) [~5 min] C. Follow-up from GAC Public Safety Working Group in ICANN (Hans Petter Holen) [~10 min] D. DB Operational Update New and revised DB-Software functionality (proposed, test, deployment) Recent DB issues (Tim Bruijnzeels, RIPE NCC) [~15 min] . setting abuse-c for remaining organisation with resources allocated or assigned by the RIPE NCC . cleaning-up Organisation Names in "descr:" . ripe objects as single text field . restrict usage of RIPE-NCC-RPSL-MNT . increase daily db dump frequency . clean-up of "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06 . locking unmaintained PERSON and ROLE objects in the RIPE Database . other aspects E. Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~5 min] F. Recent work on the UI improvements + Phasing out the LIR Portal object editors (Alex Band, RIPE NCC) [~20 min] G. Follow-up from AA-WG: 2016-01 (Piotr Strzyżewski) [~5 min] H. NWI-1: staying on top of abuse contact changes (Piotr Strzyżewski) [~5 min] I. ROUTE objects for non RIPE resources (Job Snijders) [~15 min] Y. Input from other Working Groups and/or Task Forces Z. AOB -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

RIPE Policy Proposal 2016-03 Affects Database Status for Allocations from IPv4 Pool
by Marco Schmidt 17 May '16

17 May '16

Dear colleagues, A new RIPE Policy proposal, 2016-03, "Locking Down the Final /8 Policy" is available for discussion on the Address Policy Working Group mailing list. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These allocations will receive a separate status with several restrictions. As this proposal introduces a new status for these INETNUM objects, we would like to notify the Database Working Group and invite you to discuss the proposal on the Address Policy Working Group mailing list. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 June 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE 72 DB-WG agenda V1
by Piotr Strzyzewski 13 May '16

13 May '16

Dear DB-WG Members This is the 1st draft of an agenda for the DB-WG Meeting at RIPE72 at the Tivoli Hotel & Congress Center in Copenhagen, Denmark. The DB-WG Meeting is scheduled as usual for Thursday, May 26th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 72 meeting plan please refer to its most up-to-date version at https://ripe72.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. RIPE DB development process: Numbered Work Items (Job Snijders) [~5 min] C. Follow-up from GAC Public Safety Working Group in ICANN (Hans Petter Holen) [~10 min] D. DB Operational Update New and revised DB-Software functionality (proposed, test, deployment) Recent DB issues (Tim Bruijnzeels, RIPE NCC) [~15 min] . setting abuse-c for remaining organisation with resources allocated or assigned by the RIPE NCC . cleaning-up Organisation Names in "descr:" . ripe objects as single text field . restrict usage of RIPE-NCC-RPSL-MNT . increase daily db dump frequency . clean-up of "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06 . locking unmaintained PERSON and ROLE objects in the RIPE Database . other aspects E. Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~5 min] F. Recent work on the UI improvements + Phasing out the LIR Portal object editors (Alex Band, RIPE NCC) [~20 min] G. Follow-up from AA-WG: 2016-01 (Piotr Strzyżewski) [~5 min] H. NWI-1: staying on top of abuse contact changes (Denis Walker/Piotr Strzyżewski) [~5 min] I. ROUTE objects for non RIPE resources (Denis Walker/Piotr Strzyżewski) [~15 min] Y. Input from other Working Groups and/or Task Forces Z. AOB -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

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

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

02 May '16

Hello again. I spoke too soon. I still get errors when I try to make NIC-handles looking like this: ALE1574-ADMIN AK1576-ADM Etc. That shouldn't happen, right? Thanks again. - Ø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 ************************************

3 3