May 2021 - ripe-db-requirements-tf

Database Usage Survey Results
by Boris Duval 16 Nov '21

16 Nov '21

Dear colleagues, We just closed the Database usage survey and collected 206 responses. Please find the survey results attached to this email. Thank you all for your input! Along with other sources of data, this feedback is really valuable to the current DBTF work. We plan to collate the open questions results and send them to the mailing list as soon as possible. Best, Boris Duval RIPE NCC

2 1

Notes from 10 May 2021 Meeting
by Boris Duval 20 May '21

20 May '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 10 May 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Peter Koch, Bijal Sanghani, Ed Shryane, Maria Stafyla 1. General feedback - BoF The task force mentioned that the BoF’s attendance was low (23 participants) but was happy with the quality and frequency of the interventions and discussions. 2. Transparency - BoF The task force received some criticism over transparency at the BoF. They discussed solutions to make the minutes more visible and having a generic email to contact the task force. 3. Document Structure - BoF The task force reviewed Daniel Karrenberg’s recent feedback (https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/2021-May/00…) regarding the document structure. The task force agreed with Daniel’s remarks and will do their best to add more context and clarity to the current draft. 4. Timeline and next steps Following the BoF, the task force didn’t think that there will be enough time to integrate all the feedback received before RIPE 82. The chairs discussed changing the current timeline with the RIPE Chair who granted them another extension. The task force is now planning to meet again in June 2021 to work on the content of the document and publish a new draft in the coming months. 5. RIPE 82 Updates The task force will present an update on its work during the AP-WG (pre-recorded) on Tuesday, 18 May 2021 and during the RIPE Community Plenary on Friday, 21 May 2021. 6. Next Meeting The next DBTF meeting will take place in June 2021.

1 0

Notes from 29 April 2021 Meeting
by Boris Duval 12 May '21

12 May '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 29 April 2021 Meeting Attendees: Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane Agenda: 1. PERSON Objects The task force discussed how to deal with the great amount of PERSON objects stored in the RIPE Database and the problem it causes in terms of personal data. Ed mentioned that only a few LIRs are responsible for the creation of most of these objects. Bijal proposed to reach out to those LIRs and ask them why they are creating so many PERSON objects. Peter mentioned that it will be best to contact them via Ed on behalf of the task force. Ed agreed to contact these specific LIRs and to mention the task force in his email. In addition to this, Ed proposed to provide the task force with more statistics regarding PERSON and ROLE objects. He also mentioned that there are far more PERSON objects than ROLE objects in the RIPE Database. Bijal mentioned that the task force should come up with a clear recommendation regarding how to deal with PERSON objects. The current recommendation is to make it harder for people to create PERSON objects by adding verification mechanisms. Ed added that this recommendation would be useful to slow down the creation of new objects but will not help to clean up old objects. Peter mentioned that they could be personal data stored in both ROLE and PERSON objects and that even though it would help with data minimisation, it will not solve the concerns around personal data. Nick shared that some of the data in the RIPE Database is being scraped for advertising purposes and that he and other LIRs were regularly receiving spam emails. Ed asked Nick to contact him directly, so that the RIPE NCC Database Team can look into this issue. Nick added that it will be hard for the RIPE NCC to differentiate between a role address and a personal address. Shane proposed to find a way to accelerate the clean-up of old PERSON objects by asking the RIPE NCC to step up its efforts in this area. Bijal proposed to first wait for the feedback of the LIRs creating the most PERSON objects. The task force discussed how the move from PERSON to ROLE objects should be dealt with by the community. James mentioned that the task force’s recommendation should stay high level as engineering details are out of scope. He proposed to delegate this work to another body (WG or new task force). The task force agreed to discuss this recommendation at the upcoming BoF and wait to hear from the LIRs who are creating the most PERSON object before taking a decision on this topic. 2. rDNS After agreeing that rDNS is a requirement of the RIPE Database, the task force decided that no recommendation was needed on this topic at this stage.

1 0

Feedback on Last Week's BoF
by Daniel Karrenberg 11 May '21

11 May '21

Dear TF, Thank you for holding the BoF yesterday. After learning that minutes of task force meetings were indeed published and after some more searching I have now found these minutes in the mailing list archives. You could probably have prevented some of the criticism about lack of transparency by publishing them in a more obvious place. For my part I apologise for not searching more thoroughly before this morning. For your convenience here is a summary of the input I intended to give yesterday. This is based on the discussion at the BoF and the previously published draft document. I have tried to take your minutes into account as much as the limited time allowed, but I may have missed some things. First and foremost I advise you to structure your document in a way that readers expect from a requirements document for an existing system. As an example here is an outline that I personally would expect: - Description of the Current State of the System - some information about the system evolution over time would be useful - start with contacts database for networks and domains maintained by volunteers - add reverse DNS delegation - add authoritative record of number resource distribution / delegation by RIPE NCC - remove domains - add routing registry / policy - [this is from memory and certainly incomplete] - this should definitely include where various objects and attributes originate and who is responsible to maintain them - List of New and Changed Requirements - describe where each requirement originates - there can be conflicting requirements here - notably absent in previous published draft is the privacy requirement - Recommendations for Further Action - list of recommendations - some recommendations for priorities and sequencing - list of identified requirements with no recommendation - suggestions for an action plan Note that this does not include engineering decisions as per your charter. Again: just a suggestion based on common expectations. —— On the feedback you requested: Your difficulties in making progress on the question of ‘legal address’ may be overcome by clearly recognising the conflicting requirements of privacy and implementation cost on the one hand and preserving LEA resources on the other. Once you clearly identify and enumerate the conflicting requirements it may become more obvious what you should recommend. If not I would consider your task achieved by enumerating the requirements and explicitly declining to make a recommendation. Then the community has to find a way to resolve the conflicting requirements. On person objects I get the impression that the requirements are also not clearly stated. The implicit requirement seems to be to eliminate ‘personal data’ for which the person concerned has not given permission to store it from the database. As far as I know there is a legal requirement today to give persons a way to remove or change their personal data too. Of course this requirement is more complex when it conflicts with other requirements such as keeping and publishing authoritative records about internet resources. Again it may help if these conflicting requirements were explicitly listed first before discussing your recommendations. I also have the impression that some people focus on the object type of ‘person:’. Changing that to ‘role:’ and keeping the same information will not solve the privacy requirements. It will also help you if you actually include some statistics and behavioural patterns of database users regarding these objects into the ‘status quo’ part of your report. In particular it may be useful to consider differences depending on the source/maintainer of the data here. — Here is some more input on requirements: # Maintainer / Controller ## Requirement The person or entity responsible for maintaining each object and, where different, particular attributes within the object is clearly defined an queryable. ## Rationale RIPE database objects originate from different sources. The responsibility and authority for entering the data and for making changes to it rests with different parties. A common misconception by database users is that the RIPE NCC is responsible for all data in the database or and that the RIPE NCC can change any data at will. Therefore is important to make it obvious to even the casual user who in fact has this responsibility and authority. ## Originator This requirement originates from both the RIPE community and the RIPE NCC. ## Example Use Cases - Identify who to contact for reporting inaccuracies. - Select data maintained by a specific entity. - Assess the credibility of data. # Historic Data ## Requirement The RIPE Database should preserve historical data, e.g. data that is no longer current and make it queryable as much as possible. ## Rationale Historic information is required to investigate the usage history of number resources. This can help diagnose operational problems that originate in recent changes to the use of number resources, including abuse. This information is required for interpreting measurement data. This information is required for research of Internet development. ## Originator ISPs, LEAs, Researchers in General ## Example Use Cases - Research into routing/traffic trends: identify changes caused by registration changes, take into account registered policies, … . - Investigate the usage history of resources. — I hope this all helps to reduce entropy for you. In case my remarks are too terse or obscure, I’ll be happy to expand and clarify. Thank you for your consideration and your difficult work. If it were easy it would have been done already. Daniel [Full disclosure for the record: I am on the RIPE NCC staff and I do *not* speak for the RIPE NCC here. As the first volunteer in 1989, I have maintained both the software and the data from the beginning. Between 1992 and 2000 I have been responsible for the operation and development of the RIPE Database as Managing Director of the RIPE NCC; during that time I have moved from extremely hands-on to very general management of RIPE Database operations and development. Since then I have had no responsibility for the RIPE Database other than providing advice from time to time.]

1 0

Notes from 20 April 2021 Meeting
by Boris Duval 04 May '21

04 May '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 20 April 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane 1. Reviewing the legal address recommendation The task force reviewed the following recommendation: “The task force recommends that the legal address of resource holders who are legal persons be published in the RIPE Database. This will clarify which organisation holds which Internet number resources and ensure quick action from incident responders such as CSIRTs and LEAs in case of abuse.” The task force discussed having a third option where LEAs could have access to the legal address upon request without a court order. However, this option would be difficult to implement because it will fall on the RIPE NCC to decide who can access the information and who qualifies as an LEA. Shane proposed to publish the corporate identifier rather the legal address as a stepping stone. Boris added that NWI-10 could also be considered as a stepping stone. Peter mentioned that it is unclear who will benefit from this recommendation being implemented. Looking at the Law Enforcement Agency Requests 2020 report, there was only one request about non-public information. Nick mentioned that resource holders should be able to have their legal address removed from the RIPE Database if they request it. He added that this would help make this recommendation compatible with the current privacy regulations (e.g. GDPR). Peter asked why the RIPE NCC decided to keep legal addresses private in the first place and if whether or not the task force or the membership could legally act on this topic. Nick mentioned that the RIPE NCC could probably decline to publish this information under GDPR or another privacy legislation. Peter mentioned that it would be good to clarify this point before going forward with the recommendation. Boris will follow up with the RIPE NCC legal team. Bijal mentioned that there wasn’t enough feedback from the community on this topic to take a decision. Bijal asked the RIPE Chair, Mirjam Kühne, to follow up with CSIRTs to get their input. Bijal also proposed to invite Dick Leaning to one of the DBTF calls. Dick previously worked for the RIPE NCC as an External Relations consultant and liaison to LEAs, and might have an interesting perspective to share on this topic. Parallel to that, Boris will coordinate with the RIPE NCC External Relations department and ask them to reach out to their CSIRTs and LEAs contacts about this recommendation. 2. Next Meeting The DBTF next meeting will take place in April.

1 0

Notes from 16 April 2021 Meeting
by Boris Duval 03 May '21

03 May '21

Dear all, Here's the meeting notes from our last call. Let me know if something’s missing. *RIPE Requirements Database Task Force Meeting Notes* 16 April 2021 Meeting Attendees: Boris Duval, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane 1. Reviewing and editing the routing requirements The task force reviewed the routing requirements from its current draft. -- Requirement: "The RIPE Database will provide routing information for: - Internet number resources delegated by the RIPE NCC. - Internet number resources which fall under the terms of the "RIPE NCC Services to Legacy Internet Resource Holders" policy. - Other Internet number resources which already have routing information in the RIPE Database." Shane mentioned that the last point, “Other Internet number resources which already have routing information in the RIPE Database”, was an attempt to capture all information not covered by the points above. James proposed to ask the RIPE NCC Registry Services department to double check if there was such information in the RIPE Database. Boris will follow up with Registry Services. -- Requirement: “The holders of these resources will be authenticated by the RIPE NCC and only they will be authorised to manage routing information for the resources that they hold.” Shane clarified that some of the language in the requirements such as “authenticated” and “authorised” refer to generic computing terms and are not specific to the current RIPE Database processes. James and Ed proposed to specify who is covered by this requirement. Shane suggested the following text: “The holders of these resources will be authenticated by the RIPE NCC or by the holders of parent resources, and only the holders will be authorised to manage routing information for the resources that they hold.” -- Requirement: “It should not be possible to add new routing information to the RIPE Database for address resources delegated by other Regional Internet Registries.” Shane asked if this there was already a policy for this. Ed confirmed that there was one. -- Routing origin information Shane mentioned that it’s important to include RPKI in this section. James and Ed mentioned that there are interlinks between the RIPE Database and RPKI and that should be taken into account when drafting the requirements. Shane added the following text to clarify these connections: “Maintaining accurate routing origin (address prefix and autonomous system number) information is a requirement of the RIPE Database. • Routing origin information is published via route: / route6: objects in the RIPE Database. • ROA are created in RPKI to represent routing origin information. In the RIPE Database, this routing information is stored using certain Routing Policy Specification Language (RPSL). Routing origin information is also stored in the RPKI Database. There is no direct link between these two databases, although both support authorization from address. (Although both address and ASN are needed for routing origination, only the address holder’s authorisation is used currently.)” -- Routing relationship information James pointed out that a lot of import/export lines in aut-nums are not maintained. Shane mentioned that it’s hard to analyse usage. Ed volunteered to check the query logs to see if there are queries for this object. Bijal proposed to ask the Routing Working Group about this topic and suggested phasing it out if that’s not being used. Shane will work on developing the text. -- RPSL Shane proposed to find a better way to represent routing policies than RPSL as it’s an outdated code language which is notoriously hard to work with. He also suggested to mention that RPSL was not a requirement of the RIPE Database. Bijal added that there was not a lot of support for RPSL in the community. Ed mentioned that it’s also possible to represent routing in JSON and XML. Ed also asked if the task force should document the drawbacks of RPSL or if this was already too detailed. Peter mentioned that if we were to recommend an alternative, we will have to be careful about not getting too much into details (e.g. object level) as this will be out of scope for the task force. Bijal mentioned that is will be worth looking at the advantages of RPSL instead of the drawbacks to save time. Shane suggested the following text: “RPSL is not a requirement for the RIPE Database. It is an old standard that never fully matured and has not been maintained over the decades. As such, the RIPE Routing working group should look at formal deprecation of RPSL, with the co-operation of the RIPE Database working group. The specific recommendation is not to adopt a new syntax such as XML or JSON, but rather to consider what routing information is useful to operators and design a way of representing that. Until RPSL is re-evaluated, the RIPE Database must continue to support it.” -- RPKI Database Shane and Peter mentioned that the RIPE community should consider whether or not RPKI is best treated as a community resource - like the RIPE Database - or as a RIPE NCC service. This should be highlighted in the document. Ed mentioned that there was an on-going effort to delegate RPKI to resource holders. 2. Next Meeting The next meeting will take place on 20 April 2021.

1 0