- ripe-db-requirements-tf - mailman.ripe.net

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 27 September 2021 Meeting
by Boris Duval 04 Oct '21

04 Oct '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 27 September 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane 1) Draft updates The task force discussed how to update the draft to integrate some of the feedback received from the community. They agreed to add a comment about ENUM and geolocation for completeness, clarify the research purpose by adding a separate section, and make the distinction between when historical data was first published and when it was made available to the public. 2) Final draft publication and next meeting The task force agreed to only meet if they need to discuss community feedback or make last-minute changes to the document before publication. If this is not needed, the task force will meet again at the end of October to discuss the feedback received on their final draft.

1 0

Notes from 16 September 2021 Meeting
by Boris Duval 29 Sep '21

29 Sep '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 16 September 2021 Meeting Attendees: Boris Duval, Athina Fragkouli, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane 1. Draft feedback The task force reconvened after the summer to discuss the feedback received on their intermediate draft. A handful of community members shared their opinion on the document including Denis Walker who provided in-depth feedback and suggestions. The task force reviewed his comments and will reply to him via the db-wg and the ripe-list. 2) Publication of the final draft The task force decided to publish their last draft mid-October ahead of RIPE 83. The community will have two weeks to review the document and provide their last feedback.

1 0

Notes from 28 June 2021 Meeting
by Boris Duval 02 Jul '21

02 Jul '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 28 June 2021 Meeting Attendees: Boris Duval, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane, Maria Stafyla 1. Draft Document A) Historical Data Shane shared with the task force the feedback he received from Daniel Karrenberg and Erik Bais regarding their historical data usage. Erik Bais mentioned that their RIPE WhoWas service was using RIPE Database snapshots to build their own data sets and that they were not using historical data. However, Shane said that they were still missing the chain of ownership of objects as the object history is removed if it’s deleted and re-added. Daniel gave different use cases for operational and research purposes but mentioned that regarding research it could not be clearly defined as it depended on the research itself. The task force discussed restricting the usage of historical data to what’s necessary for the main operational use cases and give access to researchers to a wider set of data on a case-by-case basis. Shane mentioned that SIDN has a similar approach and is using a defined set of criteria to grant access to their historical data. The task force said that if they were to recommend this approach, the criteria should be discussed and defined by the community. The task force needed more time to think about this recommendation. B) Routing Relationship Information The task force agreed to remove this requirement as there was not a strong enough rationale to keep it in the document. The task force might revisit this requirement in its final draft. C) IPv4 PA Assignments The task force agreed that this recommendation was about giving the choice to resource holders to document IPv4 PA assignments but not about deleting all IPv4 PA assignments from the database. The task force will clarify this point in the document to avoid misinterpretations. D) IPAM Peter mentioned that this recommendation was linked to the IPv4 PA assignments recommendation. Boris proposed to change the document order, so that they are both following each other. Peter also mentioned that this specific usage of the database as an IPAM solution should be clearer to avoid confusion. James proposed to reword the recommendation with the following text: “The task force recommends to limit and discourage the use of the RIPE Database as an enterprise IPAM solution.” E) RPKI Database Maria pointed out that the current recommendation to ask the community if RPKI should be considered as a community resource or as a RIPE NCC service was unclear. The task force agreed to clarify this recommendation by adding more context. 2) Publication of the intermediate draft The task force agreed to review the document by Wednesday, 30 June and publish the draft on Thursday, 1 July. Bijal mentioned that she will have a call with the RIPE Chair, Mirjam Kühne, on Thursday to align on next steps before publishing the draft.

1 0

Notes from 21 June 2021 Meeting
by Boris Duval 30 Jun '21

30 Jun '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 21 June 2021 Meeting Attendees: Boris Duval, Nick Hilliard, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane, Maria Stafyla 1. Draft Document A) Data management principles The task force discussed how to fine tune the data management principles currently included in the document. They proposed to add clarity to the data consistency principle and add more examples to all principles. B) IPAM Regarding the use of the RIPE Database as an IPAM solution, the task force decided to discourage it by adding a separate ‘other consideration’ item in the document with a rationale and a recommendation. The main reason for this recommendation is that this usage clashes with the data minimisation principle. C) Baseline requirements for Internet number resources registration The task force reevaluated the current baseline requirements for the registration of Internet number resources, which includes the full legal name of resource holders, contact information for administrative and technical matters, and the full postal address with the recent addition of the legal Country Code (via NWI-10). The task force couldn’t think of any operational reasons that would justify the need for a postal address. They also mentioned that the current information (minus the postal address) should be sufficient and that they might be an alternative to disclosing the legal address that would complete this information. 2. Publication of the intermediate draft and next meeting The task force discussed the remaining work to finish the document and propose to have another call on Monday, 28 June 2021.

1 0

Notes from 7 June 2021 Meeting
by Boris Duval 14 Jun '21

14 Jun '21

Dear all, Here's the meeting notes from our last call. Cheers, Boris *RIPE Requirements Database Task Force Meeting Notes* 7 June 2021 Meeting Attendees: Boris Duval, Nick Hilliard, Shane Kerr, James Kennedy, Peter Koch, Bijal Sanghani, Ed Shryane, Maria Stafyla 1. Draft Document A) Data Management Principles The task force agreed on four leading principles for the management of data in the RIPE Database: -- Data accuracy -- Data minimization -- Data consistency -- Data security Nick suggested to add that all data stored in the RIPE Database should have a clearly defined purpose. Boris and Maria said that it could fall under the Data Minimisation principle and proposed to edit the current text. A) Document Structure The task force reviewed a new document structure based on Daniel Karrenberg’s remarks. The new structure includes a clear separation between Purposes, Requirements and Recommendations. For each requirement, there is also information about the current status quo and the rationale that led to the recommendation. The task force also suggested to add another category called “other consideration” for requirements that were considered but not included as such in the document. B) Legal Address The task force agreed on recommending to explore alternatives to publishing the legal address of RIPE NCC Members and End Users. C) PERSON Objects The task force agreed to recommend the implementation of stricter checks and measures to limit the creation of PERSON objects and to encourage the creation of ROLE objects instead. Ed received feedback from one of the top 10 members with the most PERSON objects. He shared that this member is referencing most of its PERSON objects from assignments (with consent from users), hence the huge number of objects created. James commented that it looks like they are using the RIPE Database as their IPAM solution. D) IPv4 PA Assignment The task force reviewed James’s recommendation regarding IPv4 assignment. This recommendation was presented during the AP-WG at RIPE 82. The task force agreed to include the following recommendation: “The task force recommends that as resource holders have full responsibility over their IPv4 PA assignment(s), they are free to make assignments or not. This means that IPv4 PA assignment(s) will stop being a policy requirement.” The task force also considered adding a disclaimer regarding previous assignments, as the intention of the task force is not to delete past assignments. E) Historical Data The task force agreed to add historical data as a requirement of the RIPE Database and to further limit personal data exposure in historical queries. Shane will follow up with Erik Bais and Daniel Karrenberg to collect use cases related to historical data usage. 2. Publication of an intermediate draft The task force agreed to publish an intermediate draft at the end of June to give the community an overview of its current work and get feedback. 3. Next Meeting The next DBTF meeting will take place on 21 June 2021.

1 0

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