- 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

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

Notes from 12 April 2021 Meeting
by Boris Duval 19 Apr '21

19 Apr '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 12 April 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane, Maria Stafyla Agenda: 1. Document writing a) Document overview The task force reviewed the current document and decided to focus on working on the requirements section and create a new section dedicated to data management principles. b) Appointing topic owners The task force appointed topic owners for each of the current open topics in the requirements sections as well as for the new data management principles sections. c) Scheduling editing meetings The task force decided to schedule individual meetings for each topic to work on the content. Boris will send a Doodle to the task force and book meeting slots for those meetings. d) Timeline The task force still aims to publish a final document before RIPE 82. 2. Collecting feedback on open issues a) BoF (date, announcement, agenda) The task force agreed to schedule the BoF on Wednesday, 5 May 2021 from 16:00-17:30. The meeting should only last one hour but the extra 30 minute buffer can be handy if there is a lot of feedback. b) Emails to WGs In order to have sufficient feedback on open topics (legal address, personal data in historical queries, and PERSON objects) before the BoF, the task force drafted a series of emails that they will send to the DB-WG mailing list. As these topics also concern other working groups, Bijal proposed to inform the chairs of the other working groups that these discussions will take place in the DB-WG mailing list. 3. Next Meetings The next meetings will be scheduled in April and will focus on editing specific topics in the requirements document.

1 0

Notes from 26 March 2021 Meeting
by Boris Duval 07 Apr '21

07 Apr '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 26 March 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla Agenda: 1. DBTF questionnaire review and next steps Maintaining an authoritative and accurate registry of Internet number resources C) Resources Registration Requirements The task force agreed on the following recommendation: “As resource holders have full responsibility over their allocation(s), they are free to make assignments or not. However, if a resource holder wants to sub-assign part of their resources to another entity, the task force strongly recommends to document this change in the RIPE Database. Parallel to that, making assignments should not be a prerequisite to get new Internet number resources.” Peter and Nick pointed out that it will be good to add data minimisation as part of the general data management principles in the draft. D) Historical Information The DBTF will wait for the BoF before taking a decision on how to deal with historical information. The main issue revolves around personal data being stored in historical information. Ed will check if it is technically possible to apply more filtering in order to minimise the risk of having returned personal data in historical queries. Facilitating Internet operations and coordination A) PERSON Objects The task force considered to keep PERSON objects but make it harder to create them by adding a disclaimer about personal data. This will help decrease the amount of unmaintained personal data. The task force will come up with a recommendation on this topic and will bring it for discussion at the BoF. 2. Document Structure Nick proposed to have two documents instead of one. One document with general principles (similar to the current draft) and one document with all recommendations and suggestions from the task force. The task force liked the idea and will discuss it further. 3. BoF Planning After reviewing the original timeline, the task force decided to organise a BoF early May. 4. Next meeting The next meeting will take place in April.

1 0

Notes from 19 March 2021 Meeting
by Boris Duval 25 Mar '21

25 Mar '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 19 March 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla Agenda: 1. DBTF questionnaire review and next steps A) Baseline information The task force decided to keep the current baseline information data and recommend using role-specific email addresses whenever possible. B) Legal Address The task force didn’t get enough information and arguments from the questionnaire survey results to decide whether or not the legal address of resource holders should be published in the RIPE Database. The task force will therefore ask the community via email to get more feedback on this topic before making a decision. C) Resources Registration Requirements The task force discussed formulating a new recommendation regarding assignments. Assignments were historically useful to justify the allocation of new resources but as this is no longer the case (due to IPv4 runout), the role for assignments need to be reevaluated. The task force discussed when and where assignments are needed and who is responsible for what. They will continue this discussion during their next call. The task force didn’t have enough time to review all of the questionnaire’s results and action points during their meeting and decided to schedule another call to finish their review. 2. Next meeting The next meeting will take place on Friday, 26 March 2021.

1 0

Notes from 26 February 2021 Meeting
by Boris Duval 10 Mar '21

10 Mar '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 26 February 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla, Edward Shryane Agenda: 1. DBTF questionnaire review and next steps The task force was pleased with the number of replies (49) and general quality of the feedback provided. Maria, Ed and Boris will summarise the questionnaire’s results and present actionable insights to the task force before next meeting. 2. Timeline review and BoF planning The task force decided to schedule a BoF mid-April and will soon choose a date. They also decided to only publish a final draft ahead of RIPE 82 and skip the publication of an intermediate draft. 3. NWI-2/historical data discussion The task force discussed Randy and Denis’s recent comments on the db-wg mailing list about NWI-2. Ed mentioned that this was one final call from Denis to see if there are any interest from the community to move NWI-2 forward. As the task force is already working on this topic, Ed proposed to inform the db-wg that they can close NWI-2. The task force agreed. 4. Next Meeting The next DBTF call will take place in March 2021.

1 0

DBTF - Notes from 12 February 2021 Meeting
by Boris Duval 26 Feb '21

26 Feb '21

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 12 February 2021 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla, Edward Shryane Agenda: 1. DBTF questionnaire The task force discussed feedback from the db-wg mailing list about the questionnaire. As the number of replies was relatively low (20), the task force decided to postpone the questionnaire’s deadline to 22 February 2021. The task force also discussed what will happen after their final report is published. They agreed that the implementation of the requirements could be delegated to the relevant working groups but mentioned that it will be up to the RIPE Chair team to decide what to do next with it. 2. Assignments in the RIPE Database Ed asked if the task force was considering to make a recommendation regarding assignments as it seems to drive the creation of a lot of unmaintained objects (especially PERSON objects). The task force replied that they were working on a recommendation dealing with assignments but didn’t reach a final decision yet. 3. Timeline and next steps The task force agreed to talk about their third BoF at their next meeting. They will also update their current timeline to be on track with publishing a final draft before RIPE 82. 4. Other Updates Sara is changing career and will be also be leaving the task force. As the task force is almost done with its work, all task force members agreed that it won’t be necessary to replace Sara. 5. Next Meeting The next DBTF call will take place on 26 February 2021.

1 0

Notes from 13 January 2021 Meeting
by Boris Duval 22 Jan '21

22 Jan '21

Dear all, Here's the meeting notes from our last call. Let me know if something’s missing! I’ll send them to the public list tomorrow. *RIPE Requirements Database Task Force Meeting Notes* 13 January 2021 Meeting Attendees: Boris Duval, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla, Edward Shryane Agenda: 1. Finalising the questionnaire The task force discussed and edited their new questionnaire that will be presented to the community during the last week of January. Their main challenge was to adapt the questionnaire to get relevant feedback from the community and try to build consensus on several topics. The questionnaire will go through a last review round before being published. 2. Next call The next DBTF call will take place in February.

1 0

Notes from 18 December 2020 Meeting
by Boris Duval 23 Dec '20

23 Dec '20

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 18 December 2020 Meeting Attendees: Boris Duval, Shane Kerr, Peter Koch, Sara Marcolla, Edward Shryane, Maria Stafyla Agenda: 1. Questionnaire Review The task force continued to review the questionnaire that will be sent out to the community in January to collect feedback on the current draft. One of the main challenges is how to best frame questions, so that the task force gets qualitative feedback from the community. Nick and Shane will look into coming up with questions for the routing requirements section. The task force will fine-tune the questionnaire and finalise it during their next call in January 2021. 2. Timeline Review The task force reviewed and agreed on the following timeline: 18 January 2021: DBTF to finalise questionnaire (sign off) 25 January 2021: Publication and promotion of the questionnaire 8 February 2021: End of questionnaire + discussing result and asking clarifying questions to the community 8 March 2021: Publication of an intermediate draft including feedback from the community 17 March 2021: 3rd BoF (if needed) to discuss the new draft and build consensus on potential open issues 12 April 2021: Publication of the final draft and last call for comment 3 May 2021: Final draft accepted and listing open issues (if any) 3. DB-WG discussion on historical data The task force mentioned the recent discussion about the use of historical data in the DB-WG mailing list: https://www.ripe.net/ripe/mail/archives/db-wg/2020-December/006737.html As historical data is addressed in the questionnaire, the task force will ask the community for more feedback on this topic. 4. Editing the current draft The task force will look at the current draft and see if it needs to be updated based on the feedback already received from the community (especially the routing requirements section). 5. Diagram review Boris presented a diagram representing the relationships between the RIPE Registry, the RIPE Database, the RIPE IRR and the RPKI Database (see attachment). The task force gave his feedback and mentioned that it will be good to include this overview in the final draft. Peter added than having a second more detailed diagram might be useful for internal use to shed some light on some of the data relationships between the different parts of the RIPE Database. 6. Next Meeting The next meeting will take place in January 2021.

1 0

Notes from 9 December 2020 Meeting
by Boris Duval 18 Dec '20

18 Dec '20

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 9 December 2020 Meeting Attendees: Boris Duval, James Kennedy, Shane Kerr, Peter Koch, Sara Marcolla, Bijal Sanghani, Edward Shryane, Marco Schmidt, Maria Stafyla Agenda: 1. Questionnaire Maria and Boris presented a questionnaire to the task force that will help them get more feedback from the community on the current draft. The questionnaire is asking questions on all recommendations and open items listed in the latest draft. The task force agreed with the overall structure but mentioned that some questions needed fine-tuning as they were too open. They also mentioned that it will be good to have the possibility to contact respondents (if they opt-in) to ask follow-up questions when needed. Maria and Boris will work on the questionnaire and present a new version to the task force at their next call. In the meantime, the task force will review the questions and share their feedback if needed. 2.Timeline The task force discussed a 2021 timeline to collect feedback (via the questionnaire and a possible BoF), build consensus and publish the final document ahead of RIPE 82. 3. Q&A with Marco Schmidt from RIPE NCC’s Registry Services Department The task force asked Marco Schmidt, representing Registry Services, several questions regarding his department’s work and the RIPE Database. The topics discussed included: the need to document assignments post-IPv4 run out, efforts from the RIPE NCC to keep the database accurate, how to deal with aged information and his recommendations regarding the future of the database. 4. Next Call The next call will take place on 18 December 2020.

1 0

Notes from 23 November 2020 Meeting
by Boris Duval 30 Nov '20

30 Nov '20

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 23 November 2020 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Maria Stafyla Agenda: 1. Feedback from the BoF The DBTF discussed what happened during the BoF and reviewed some of the feedback provided by attendees. For example, how to differentiate data maintained by the RIPE NCC and data maintained by resource holders in the draft. The task force will follow up on this feedback and integrate it in the new draft when relevant. The task force also mentioned that there was little feedback during the session and suggested that it might be due to the busy period for the industry (October-November) and lack of time from participants to review the draft. Bijal will send a reminder to the ripe-list to review the draft. 2. Get more community input As mentioned earlier, the task force was disappointed by the lack of feedback during the BoF and shared ideas to get more community input. One of the solutions proposed was to build a questionnaire to invite a guided discussion on specific sections of the draft. Maria and Boris agreed to start working on this questionnaire. 3. Meeting with the RIPE NCC’s Registry Services Department The task force is interested to meet with someone from the RIPE NCC’s Registry Resources Department to get input on different topics. Maria and Boris proposed to invite Nikolas Pediaditis, Registry Services and Policy Development Manager, to their next call. The task force agreed and will prepare questions ahead of the meeting. 4. Next Call The next call will take place in December 2020.

1 0

Notes from 22 October 2020 Meeting
by Boris Duval 29 Oct '20

29 Oct '20

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 22 October 2020 Meeting Attendees: Boris Duval, James Kennedy, Shane Kerr, Peter Koch, Sara Marcolla, Bijal Sanghani, Maria Stafyla, Edward Shryane Agenda: 1. Draft Document The task force reviewed the current draft document before publication. -- Publishing the Legal Address of Legal Persons The task force discussed this recommendation and decided to ask the community for feedback during the BoF. Also, the task force pointed out that the purpose for this recommendation needed to be clearer and more specific. -- Reverse Domain Name System (rDNS) The task force agreed to keep this requirement in the document and develop the text at a later stage. -- Personal Data and PERSON Objects Edward Shryane gave more information about the use of personal data in the RIPE Database and mentioned that there was still a huge amount of PERSON objects being created. The task force agreed that PERSON objects were not a requirement of the RIPE Database but mentioned that they needed more time and feedback from the community on this subject and more generally on the use of personal data in the database. 2. DBTF BoF The task force agreed to only talk about the following recommendations during the BoF as there will be limited time: *Resource registration requirements *Contact information *Legal address 3. Next Call The next call will take place in November 2020.

1 0

RIPE Database Requirements Task Force – Second Draft Published
by Bijal Sanghani 23 Oct '20

23 Oct '20

Dear colleagues, Since RIPE 79, the RIPE Database Requirements Task Force is working on a document to provide new requirements specification for the RIPE Database. We have now published our second draft and invite you to share your input on this mailing list and during our BoF that will take place Monday, 26 October from 16:00-17:00 (UTC+1). We apologies for the slight delay on the publication of this second draft. - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… We will try to build consensus on the document and discuss open issues with the community during the BoF. Please note that you don’t need to register for the RIPE meeting to participate to the BoF. A link to join the BoF on Monday is available at: https://ripe81.ripe.net/programme/meeting-plan/bof/#mon11 <https://ripe81.ripe.net/programme/meeting-plan/bof/#mon11> Best Regards, Bijal Sanghani

1 0

Notes from 15 October 2020 Meeting
by Boris Duval 22 Oct '20

22 Oct '20

Dear all, Here's the meeting notes from our last call. *RIPE Requirements Database Task Force Meeting Notes* 15 October 2020 Meeting Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Sara Marcolla, Bijal Sanghani, Maria Stafyla Agenda: 1. Draft Document The task force reviewed the current draft document. -- Structure The task force agreed on the following plan: · What is the RIPE Database? · The difference between the RIPE Database and the RIPE Registry · Why are we reviewing the RIPE Database functionality now? · Requirements · Recommendations · Terminology · Relevant Policies and Documents -- What is the RIPE Database? There was some references and elements missing in the current draft. For example, Peter suggested to include that the RIPE Database was originally used by many Domain Name Registries as their ccTLD authoritative registry database. This illustrates that some data was migrated out of the database in the past. -- The difference between the RIPE Database and the RIPE Registry The task force discussed the type of data contained in the RIPE Database and how its usage is regulated. -- Requirements The task force discussed which recommendations and requirements should be included in the document. There was a debate around the use of personal data in the RIPE Database and whether or not the legal address of legal persons should be disclosed. Other topics discussed included historical data, routing requirements and the use of PERSON objects. -- Text to be developed The current draft is not complete as some parts will require more time to be written. This will be indicated in the draft. -- Timeline The task force agreed to do its best to publish the draft before RIPE 81. 2. DBTF BoF The task force agreed to schedule another call to plan its upcoming BoF. 3. Next Call The next call will take place on Thursday, 22 October 2020.

1 0

DBTF Working Draft
by Boris Duval 19 Oct '20

19 Oct '20

Hi all, Please find attached the current DBTF working draft. The task force will published its second draft later this week. Cheers, Boris

1 0

Notes from 28 September 2020 Meeting
by Boris Duval 05 Oct '20

05 Oct '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 28 September 2020 Attendees: Boris Duval, Nick Hilliard, James Kennedy, Sara Marcolla, Bijal Sanghani, Maria Stafyla, Edward Shryane Agenda: 1. Draft Document Sara and Bijal's draft still need to be reviewed by the DBTF. Nick and Shane will meet in the coming week to discuss their draft and make progress. James and Peter had several meetings since the last DBTF meeting and made progress on their draft. Everybody will share their draft and comments with the task force before 9 October. Maria clarified that the RIPE Database provides access to the public parts of the RIPE Registry. She added that the other parts of the RIPE Registry were out of scope for the task force. Maria, Ed and Boris offered to help out with the document’s structure and to fill existing knowledge gaps in the document. The DBTF is aiming to publish its new draft one week before the DBTF BoF to allow enough time for review. 2. DBTF BoF The DBTF will take place on Monday, 26 October from 16:00-17:00 (UTC+1). The BoF will be announced via the relevant mailing lists and will take place via Meetecho. It is already advertised on the RIPE 81 website: https://ripe81.ripe.net/programme/meeting-plan/bof/ The purpose of this BoF is to discuss the task force’s draft with the community and start building consensus around the document. 3. Summary from the meeting with the RIPE Chair (Mirjam Kühne) The RIPE Chairs (James, Bijal and Shane) met with the RIPE Chair (Mirjam) on 14 September 2020. Timeline update After discussing with the RIPE Chair, the task force decided to revise its original timeline and to set RIPE 82 as the new deadline to hand over the final document. This is now reflected on the DBTF charter’s page: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf External Communication As the public mailing list is currently closed, the RIPE Chair asked the task force if it was possible to let external messages from the community through the list when relevant. The task force agreed. 4. Next Call The next call will take place in two weeks.

1 0

Notes from 7 September 2020 Meeting
by Boris Duval 14 Sep '20

14 Sep '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 7 September 2020 Attendees: Boris Duval, Nick Hilliard, James Kennedy, Shane Kerr, Peter Koch, Sara Marcolla, Bijal Sanghani, Edward Shryane Agenda: 1. Draft Document Sara and Bijal worked on the ‘facilitating communication about usage of the resources’ requirement with some feedback and suggestions from the RIPE NCC. The DBTF will review their text and discuss it at the next meeting. Peter and James will meet this week to work on their draft and send it to the task force before 18 September. Nick and Shane met a few weeks ago and started their draft. They will also send it to the task force before 18 September. Boris reminded the task force that the RIPE NCC can support them in reviewing the drafts and providing additional information if needed. 2. Q&A Session The task force discussed planning a Q&A session ahead of the RIPE meeting to answer community questions. 3. Next Call The next call will take place at the end of September.

1 0

Notes from 27 July 2020 Meeting
by Boris Duval 30 Jul '20

30 Jul '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 27 July 2020 Attendees: Boris Duval, Petrit Hasani, Nick Hilliard, Peter Koch, Bijal Sanghani, Edward Shryane, Maria Stafyla Agenda: 1. Run through actions from last meeting Ed sent information about the RIPE Database's language attribute. Maria sent an overview of relevant policies and procedures regarding the RIPE Database requirements. 2. Presentation about ARCs Petrit Hasani from the RIPE NCC gave a presentation to the task force about ARCs (Assisted Registry Checks) and answered their questions. Here are some of the takeaways from the discussion: ARCs participants are picked at random from a list of RIPE NCC members and these checks are mandatory. However, you can also volunteer to participate to an ARC. All ARC procedures were created by the RIPE NCC. ARCs can last between 5 min to 1 hour depending on members’ needs. ARCs are non-exhaustive checks of a member’s data, it helps members learn about policies and procedures. ARCs are not intended to make the RIPE Database 100% correct. 3. Next steps The task force will continue to work on the requirements document and plan a longer review session after the summer holidays. The task force will review Maria’s document on relevant policies and procedures. Petrit will send more information and statistics about ARCs. 4. Confirm actions and next call The next call will take place in September.

1 0

Notes from 14 July 2020 Meeting
by Boris Duval 21 Jul '20

21 Jul '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 14 July 2020 Attendees: Boris Duval, Peter Koch, Sara Marcolla, Bijal Sanghani, Edward Shryane Agenda: 1. Run through actions from last meeting Boris sent an overview of relevant data from past RIPE NCC surveys. Maria is working on compiling a list of relevant policies and procedures. The DBTF worked on editing and refining the RIPE Database's purposes. 2. Review/Discuss document Bijal and Sara shared their work on the “Facilitating communication about the usage of the resources” purpose. The DBTF gave feedback on the content and clarified the language when needed. During the review, the DBTF mentioned that they would need to know more about the ARC (Assisted Registry Check) procedure. Ed proposed to invite one the RIPE NCC staff in charge of running ARCs to the next call, so that they can explain their work to the DBTF. The DBTF agreed. 3. Next steps The DBTF will continue their work on editing the RIPE Database’s purposes. Sara and Bijal will integrate the feedback they received during the call in their current draft. Ed will ask a RIPE NCC colleague in charge of running ARCs to join the next call. Ed will send information about the RIPE Database's language attribute. Maria will send an overview of relevant policies and procedures. 4. Confirm actions and next call The next call will take place during the last week of July.

1 0

Notes from 15 June 2020 Meeting
by Boris Duval 23 Jun '20

23 Jun '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 15 June 2020 Attendees: Nick Hilliard, James Kennedy, Peter Koch, Sara Marcolla, Bijal Sanghani, Edward Shryane, Maria Stafyla, Boris Duval 1. Run through actions from last meeting James followed up with Maxmind and other stakeholders about their usage of the geolocation attributes. The feedback he received confirmed that a lot of stakeholders are using this geolocation data for operational matters and that we could therefore consider geolocation as a secondary function of the RIPE Database. He also pointed out that best practices on how to manage this data would be useful. Maria started to look into different RIPE Policies (IPv4, IPv6 and AS Number) and will prepare an overview for the DBTF that also includes more information about historical data. Boris and Sara shared that CERTs were using the data stored in the RIPE Database and didn’t plan to move it out. Sara proposed to survey CERTs to get a better understanding on how they are using this data. Boris analysed past RIPE NCC surveys and shared relevant highlights with the DBTF. He will send an email with his findings to the Task Force. James informed the group that results from the RIPE NCC survey and the DBTF survey directly overlap on areas for improvement, i.e. data accuracy (enforce data checks and validation), and ease of use (requests that the user interface could be improved were common, and there were also many comments suggesting improvements to search functionality). Nick followed up with the Routing Working Group and shared that although he received some feedback, it was not enough to decide what to do with RPSL. The DBTF agreed to look at the Internet Routing Registry instead of RPSL to widen the scope and help drafting more high-level requirements. 2. Reminder of the DBTF’s Charter 3. Goals of the document The DBTF Chairs (James, Bijal and Shane) agreed on goals to help and guide their work on the requirements document: - Outline current functions of the RIPE Database - Address common, overarching issues experienced by today’s users - Define how changes should be made to the RIPE Database in the future 4. Next steps The DBTF will focus on refining the functions/requirements in the document with justifications and will try to identify overarching issues and suggestions where possible. The DBTF decided to pair up to facilitate this work and will divide the workload as follow: - Provide registration information of Internet number resources - James, Peter - Facilitating communication about usage of the resources. - Sara, Bijal - Publishing routing policies by network operators (RIPE IRR) + The RPKI Database - Nick, Shane 5. Confirm actions and next call Maria will send an overview of the information she found in RIPE policies that will help the DBTF advance its work. Boris will send relevant data from past RIPE NCC Survey. The DBTF will work on improving the draft document by working in pairs on a specific topic. The next DBTF call will take place on Wednesday, 1 July 2020.

1 0

DBTF BoF Minutes
by Boris Duval 08 Jun '20

08 Jun '20

Dear all, The minutes and recording of the RIPE Database Requirements Task Force (DBTF) BoF are now available at: https://www.ripe.net/participate/ripe/bof/dbtf-bof Thank you to all attendees for their active participation and inputs. Best, Boris Duval Communications Officer RIPE NCC

1 0

Notes from 26 May 2020 Meeting
by Boris Duval 05 Jun '20

05 Jun '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 26 May 2020 Attendees: Nick Hilliard, James Kennedy, Peter Koch, Bijal Sanghani, Edward Shryane, Maria Stafyla, Boris Duval DBTF BoF 1. Review RIPE meeting presentations BoF -- General Feedback The DBTF was pleased with the feedback received during the BoF and will take it into consideration for its work. The DBTF also mentioned that they might organise a new session at a later stage to help build consensus around the final document. -- IPAM The DBTF received new information regarding IPAM usage during the BoF as several options were considered to tackle this issue. The DBTF will need to explore each of these options before coming up with guidelines regarding this topic. Maria proposed to prepare an overview of the assignment/allocation registration requirements to be made in the RIPE Database to help the DBTF take a decision. -- Geolocation The DBTF discussed what to do with geolocation and looked specifically at the “geoloc:” attribute that was created in 2011. James mentioned that he could contact Maxmind as they might use this attribute operationally. -- IRT objects The DBTF would like to know more about how CERTs are using IRT objects and if they plan to use a different source of data in the future. Boris proposed to contact Mirjam Kühne from the RIPE NCC as she is in contact with CERTs. Bijal added that she will also ask Sara as she knows some of the CERTs. -- Minutes The DBTF agreed with the current minutes draft and proposed to add more information regarding the number of BoF and polls participants. Community Plenary Bijal shared that her presentation went well but regretted to have not received a lot of feedback from the community. She mentioned that it might have been due to the fact that the session was scheduled towards the end of the RIPE meeting and that the meeting was taking place online. Routing WG Nick gave his presentation about RPSL at the Routing WG during RIPE 80 and will follow up on the Routing WG mailing list to ask the community their thoughts on RPSL. 2. Survey analysis and user-requirements matrix James analysed the results from the DBTF survey and elaborated a user-requirement matrix based on the results that would help guide the DBTF work and better define challenges. Bijal thanked James for his work and agreed that it was a useful exercise to map out users and their needs. Peter mentioned that we should also not forget to keep the RIR function in mind when writing requirements. Boris added that some of the information needed to fill-in the matrix could be find in the RIPE NCC Survey 2019. James proposed that everybody in the Task Force look at the survey as it contains relevant information regarding users’ needs and views on the RIPE Database. Bijal mentioned that it would be interesting to look at older RIPE NCC Surveys to see how the membership evolved. Boris agreed to look into it. 3. Next steps The DBTF Chairs agreed to have a separate meeting to write up a roadmap that will allow the Task Force to structure the remaining work on the requirements document. The DBFT agreed to make James co-Chair to help speed things up as he is willing to invest more time and energy into the Task Force. 4. Confirm actions and next meeting. James will contact Maxmind and ask them about their usage of the RIPE Database’s geolocation data. Maria will look into RIPE policies and prepare an overview of the assignment/allocation registration requirements to be made in the RIPE Database. Boris will update the minutes according to the DBTF’s feedback and publish them on ripe.net with the recording. Boris will contact Mirjam and Bijal will contact Sara about CERTs. Nick will follow-up with the Routing WG on RPSL. Boris will explore the RIPE NCC Survey 2019 data and highlight what’s useful to the DBTF as well as looking into older surveys. The DBTF will take a look at the RIPE NCC Survey 2019. The DBTF Chairs (Bijal, Shane and James) will come up with a roadmap to advance the Task Force’s work. The next meeting will take place at the beginning of June.

1 0

Notes from 5 May 2020 Meeting
by Boris Duval 12 May '20

12 May '20

Hi all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 5 May 2020 Attendees: Nick Hilliard, Shane Kerr, James Kennedy, Peter Koch, Bijal Sanghani, Maria Stafyla, Boris Duval Agenda: 1. Run through action points 2. BoF Planning Bijal prepared a presentation for the BoF, the rest of the Task Force provided feedback on the presentation and approved it. The DBTF worked on the different polls that will be displayed during the BoF about IPAM, RPSL, Geolocation and IRT and fine-tuned the questions. The DBTF agreed on publishing the recording and minutes of the BoF on ripe.net <http://ripe.net/> for community members that are unable to attend the session. 3. Review draft document text The DBTF discussed whether or not to send the current draft text about the RIPE Database purpose and its usage to the community before the BoF. After weighing the different pros and cons, the DBTF agreed to send the rough draft as plain text to the relevant mailing lists as it will allow BoF participants to provide feedback. 4. Next call The next DBTF call will take place shortly after RIPE 80.

1 0

RIPE Database Requirements Task Force BoF
by Bijal Sanghani 06 May '20

06 May '20

Dear colleagues, The RIPE Database Requirements Task Force (DBTF) will organise its BoF on Wednesday, 6 May from 14h00-15h00 CEST via Zoom. During this BoF, the DBTF will present its latest work and invite participants to discuss what functionality the RIPE Database should provide in the future. The presentation will include quick polls and will be followed by a moderated Q&A. You can register for the BoF at (no Zoom account required): https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog <https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog> We look forward to discussing the future of the RIPE Database with you! Kind regards, Bijal Sanghani on behalf of the DBTF

2 1

Notes from 28 April 2020 Meeting
by Boris Duval 04 May '20

04 May '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 28 April 2020 Attendees: Nick Hilliard, Shane Kerr, James Kennedy, Peter Koch, Bijal Sanghani, Edward Shryane, Maria Stafyla, Boris Duval Agenda: 1. Run through action points 2. Review draft document text Everybody to finalise the draft this week. Boris to review the draft and check it for consistency. The DBTF aims to publish the document before the BoF. 3. BoF Planning The DBTF agreed on coming up with a list of topics to discuss with the community at the BoF and start working on building up short polls. IPAM was mentioned as a discussion topic as the DBTF survey highlighted that an unusual high number of people was using the RIPE Database for their own IP management. Another topic mentioned was the historical purpose of the RIPE Database and how it aligns with the current needs of the community. Bijal will announce the BoF on the relevant community mailing lists and Boris will promote it on RIPE NCC social media channels. 4. Next call The next DBTF call will take place on Tuesday, 5 May.

1 0

More Specific Resources per LIR organisation
by Edward Shryane 28 Apr '20

28 Apr '20

Dear all, The DB team counted more-specific resources under IPv4 and IPv6 allocations registered in the RIPE database for all LIR organisations. We found that some LIRs have registered significantly more resources than others. Of 14,164 LIR organisations with more specific resources, 13,956 organisations have registered less than 1,000 of them. I've attached a count of more-specific resources (by LIR, using an anonymised label) for the remaining 206 LIRs. Let me know if you need any more information. Regards Ed

1 0

Notes from 17 April 2020 Meeting
by Boris Duval 24 Apr '20

24 Apr '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 17 April 2020 Attendees: Nick Hilliard, Shane Kerr, James Kennedy, Peter Koch, Sara Marcolla, Bijal Sanghani, Edward Shryane, Boris Duval Agenda: 1. Review action points Ed sent IRT statistics and the DBTF will now analyse them. Boris looked into interactivity options to use during the BoF and proposed to use Zoom polls. The DBTF agreed. 2. Preparation for remote RIPE meeting The DBTF decided not to present at the DB-WG during RIPE 80 as they will give an update during the Community Plenary. - BoF The DBTF decided to host their BoF on Wednesday, 6 May via Zoom. They will ask the PC if they agree to have the BoF outside of the RIPE 80 schedule. The DBTF discussed which topics will be the most interesting to raise with the community at the BoF and mentioned IPAM, accuracy and personal information. The DBTF also agreed to try to publish a first draft of the requirements document before the BoF, so that they can have time to discuss it with the community . 3. Next steps and actions Each member of the DBTF will finalise its work on the first draft of the requirements document by next call. Bijal and Boris will contact the PC to organise the BoF in the week before RIPE 80. 4. AOB There was no further business. 5. Next call The next DBTF call will take place on Tuesday, 28 April.

1 0

Notes from 6 April 2020 Meeting
by Boris Duval 15 Apr '20

15 Apr '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 6 April 2020 Attendees: Nick Hilliard, Shane Kerr, James Kennedy, Peter Koch, Bijal Sanghani, Edward Shryane, Maria Stafyla, Boris Duval Agenda: 1. Review action points Shane drafted a text breaking down the meaning of geolocation in the RIPE Database and is waiting for feedback from the DBTF. Boris sent a new version of the open-ended survey results including a cross-analysis. 2. Preparation for remote RIPE meeting - Community Plenary The DBTF will prepare an update for the Community Plenary. - BoF BoFs are going ahead at the virtual RIPE Meeting and the DBTF will have a time slot. The DBTF needs to investigate how to best collect feedback before and during the BoF as everything will be online. The DBTF discussed asking for feedback to the community before the BoF to save time. 3. Next steps and actions Nick will contact the Routing WG chairs about RPSL. Shane will send an email to the ripe-list to discuss IPAM usage within the community related to the recent DBTF survey results. Ed will explore more statistics on how IRT objects are used. Bijal will draft slides for the Community Plenary and schedule calls for next meetings to discuss next steps and how to prepare for RIPE 80. Boris will look into which tools/platforms can be used to foster engagement before and during the BoF. Each member of the DBTF will continue its work on a different RIPE Database purpose/requirement. 4. AOB - Denis Walker questions to the DBTF The DBTF acknowledged Denis’ questions sent via the DB-WG mailing list and will reply to him as soon as possible. - COVID19 and upcoming meetings As COVID-19 disrupted everybody’s schedule, the DBTF agreed to have more frequent calls in the coming weeks to better prepare for RIPE 80 and advance its work. 5. Next call The next DBTF call will take place in two weeks.

1 0

IRT Query Statistics
by Edward Shryane 08 Apr '20

08 Apr '20

Hi all, Here are some statistics on IRT queries for January. How much usage do these IRT objects get? Some background reading on IRT objects: https://www.ripe.net/manage-ips-and-asns/db/irt https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… The IRT object is meant to be used by Incident Response Teams directly, and "abuse-c:" is meant for general abuse complaints. IRT objects are *not* returned by default in Whois queries. Users must either specify the -c / --irt flag on an IP lookup, or specify the IRT-* primary key. There are about 400 IRT objects in the Whois database. To reference an IRT object from an IP range, you must add an "mnt-irt" attribute (and authenticate with the IRT object). I found 12,694 references to IRT objects from inetnums, and 901 references from inet6nums. A total of 174 distinct IRT objects are referenced (leaving 226 unreferenced). Out of 2 billion Whois queries in January, I found 204,318 queries with the irt flag (or ~7k/day), and 546 queries (or about 18/day) for an IRT object using the primary key. Let me know if you have any questions or would like more details. Regards Ed Shryane RIPE NCC

1 1

Domain Query Statistics
by Edward Shryane 04 Mar '20

04 Mar '20

Hi all, Here are some statistics on domain queries from the month of January. How much usage does the reverse delegation (domain) database get? Some background reading on reverse delegation: https://www.ripe.net/manage-ips-and-asns/dns/reverse-dns https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… Domain objects are not returned by default in IP lookups. Users must either use the -d / --reverse-domain flag on an IP lookup, or specify the .in-addr.arpa / ip6.arpa / e164.arpa primary key. Out of 2 billion whois queries in January, I found 422,061 queries with the reverse domain flag (or ~14k/day). I found 758,583 queries for domain objects by primary key (or ~24k/day). Let me know if you have any questions or would like more details. Regards Ed Shryane RIPE NCC

2 2

Notes from 18 February 2020 Meeting
by Boris Duval 02 Mar '20

02 Mar '20

Dear all, Here's the meeting notes from our last face-to-face meeting. Best, Boris +++ *RIPE Requirements Database Task Force Meeting Notes* 18 February 2020 Attendees: Peter Koch, Shane Kerr, Nick Hilliard, Bijal Sanghani, Sara Marcolla, James Kennedy, Maria Stafyla, Edward Shryane, Boris Duval 1. Opening / Welcome 2. Review action points from past meeting 3. Review Survey results -- Question 3 - "What do you use the RIPE Database for?” --- IPAM Bijal pointed out that a high number of respondents are using the RIPE Database for IPAM. She asked the DBTF if they should consider IPAM as a requirement. Sara asked why not regulating IPAM usage, as it seems to be widespread used and tolerated. Peter mentioned that it is important to be aware of the difference between how the RIPE Database is used and what it was built for. James added that if IPAM was to be considered as a requirement, it should be separated from the public database. Nick said that this will not be feasible to have IPAM as a requirement but that best practices could be useful. Shane proposed to send an email to the ripe-list to collect community feedback about IPAM and the survey results. Bijal suggested to bring up this topic at the DBTF Bof at RIPE 80. --- RPSL Nick asked the DBTF their thoughts about RPSL. He added that it is seldom used and cumbersome but provide data that cannot be find anywhere else. Ed mentioned that there was already a discussion going on in the Database Working Group (DBWG) about replacing RPSL by something better. Shane mentioned that the DBTF could recommend dropping RPSL if something better and more practical could provide the same data. Nick proposed to give a presentation on RPSL at the next RIPE meeting to continue the discussion with the community. --- Geolocation Peter pointed out that the term ‘geolocation’ can be interpreted in many different ways. Nick mentioned that the DBWG already looked into defining what geolocation means in the context of the RIPE Database. Sara added that Law Enforcement Agencies (LEA) interpreted geolocation as knowing the legal address of a resource holder. Shane asked the DBTF if they knew enough to come-up with a requirement regarding geolocation. Shane suggested to draft another email to get feedback from the community on this point. --- Postal and Legal address Ed mentioned that the postal address is available in the public database and that it can be easily edited in the RIPE Database. Sara added that the LEAs had to contact the Dutch police via subpoena to obtain the legal address and that it was an often lengthy process. Ed mentioned that the country code of the resource holder’s legal address will be soon added to the RIPE Database. Sara replied that it was a step forward but not enough to help LEA to do their work correctly. Bijal asked what the main reason was to keep the legal address private. Sara added that they came up with a policy proposal to make this address public but that it was rejected by the community. Peter asked if the RIR was the best platform to deal with this sort of issues. Shane answered that he did not see any other relevant platforms to tackle this problem. -- Question 4 "How do you query the database?” Sara asked why so few people were using RDAP. Ed answered that it was indeed surprising and that he could look into it. He also mentioned that NRTM will be soon open to everyone. Shane asked what requirement could be drawn from the query stats. Sara mentioned that the interest for webupdates was positive. Peter replied that the results were interesting but not extremely relevant to the work of the DBTF. 4. Review open-ended results Peter proposed to correlate the open-ended responses to the close responses to get a better overview of the results. Boris said that he will edit the current document to add the correlation and send the document to the DBTF. Shane asked the DBTF if some of these open-ended results would be useful to consider when listing the requirements. -- Data Accuracy Regarding results mentioning the lack of accuracy of the RIPE Database, Shane mentioned that it would be helpful for users to identify which fields need to be updated. Ed clarified that it was already the case for certain fields. Sara asked if Abuse-C fields were colour-coded. Ed said that they were not at the moment, but that his team could investigate it. Nick mentioned that a vast majority of the RIPE Database data is user maintained. He added that one could always try to improve processes but that it will be impossible to completely eliminate human mistakes. Maria mentioned that the RIPE NCC’s Assisted Registry Checks were helping members to update their data. Shane asked if the DBTF should make recommendations on how to improve accuracy. Peter replied that it is not the DBTF’s role to provide concrete solutions, but that they could highlight areas of improvement. Sarah pointed out that resource’s hijackers are taking advantage of vulnerabilities created by inaccurate data. Peter commented that regulating how resources are used by resource holders does not fit the Registry’s current mandate. Sara proposed to create a best practices document on how to update RIPE Database data. Shane mentioned that as long as the data is accurate, ISPs can find the malicious IP addresses and block them. He added that there is nothing else than the RIPE NCC can do to prevent hijacking. Maria added that if a resource holder is violating RIPE policies the RIPE NCC can act. This is done on a case-to case basis depending on the circumstances. Nick concluded that data accuracy is probably part of a bigger conversation and proposed to continue the discussion at another time. Bijal added that the DBTF might need to define what accuracy means as it might be useful when they will dive into RIPE Database objects. -- Person objects Ed mentioned that the RIPE Database Team started to clean-up locked person objects as they are many of them, and they are most likely not up to date. Peter pointed out that it might become worse with IPv6, and that the community should think about how deep the assignments should be reflected in the RIPE Database. James agreed and mentioned that it would make the whole IPAM issue worse. Shane suggested that stricter rules regarding data accuracy for IPv6 might be worth considering. --Role objects Bijal asked how much roles objects were created. Ed replied that only a tiny amount of Role objects was created in the RIPE Database. Bijal and Sara mentioned that this was odd as it should be the other way around. 5. Review data from action points Ed shared broad RIPE Database statistics with the Database including different objects data (e.g., Abuse C validation data). He then asked the DBTF to have a look at these preliminary statistics and choose the most relevant data sets to explore. The DBTF agreed and will provide him with this insight as soon as possible. They also discussed and questioned the usefulness of certain object types. -- IRT (Incident Response Team) Objects James asked if IRT Object types were used. Ed replied that there were only 400 IRT objects in total, which is really low. Shane added that as the objects are pointing to a CERT (Computer Emergency Response Team), 400 could be the number of CERTs existing in the RIPE Community. Ed suggested to look into the query statistics to assess the usefulness of those objects. Sara mentioned that due to recent regulations, the CERT environment rapidly evolved the past few years. Bijal proposed to directly ask some CERTs about their use and knowledge of the IRT object type. Sara suggested to talk to ENISA as they can directly contact CERTs. 6. Next steps -- BoF at RIPE 80 Bijal mentioned that the DBTF needed to plan for RIPE 80. Nick proposed to present at the RIPE Database Working Group. He also mentioned that it will be good to make sure that the DBTF receives enough feedback during the BoF. Sara proposed to use Slido at the BoF. Slido is an interactive poll tool that would help increasing participation and get more feedback from the audience. Peter commented that the DBTF should be cautious to not lose focus when introducing new tools. -- RIPE Database Purposes The DBTF agreed to take a deeper look at the RIPE Database purposes to help draft the requirements and understand how it relates to the RIR’s mission. This is the preliminary list of purposes defined by the DBTF: RIPE Database Purposes • Provide accurate registration information of Internet number resources • Facilitating communication about usage of the resources • Publishing routing policies by network operators (RIPE IRR) • Provisioning of Reverse Domain Name System (rDNS) • RPKI - not part of the RIPE Database but compliments and references the RIPE Database Other Usage • Research into network operations and topology • ENUM • Geolocation • IPAM • Enabling transfer of IP resources 7. Action points · Nick will contact the Routing WG chairs about RPSL and possibly give a presentation about this topic at RIPE 80. · Shane will send an email to the ripe-list to further discuss IPAM usage within the community. · Shane will draft a document highlighting the main complexities regarding geolocation use in the RIPE Database. · Boris will edit the open-ended responses summary and add the correlation with question 1,2,3. · Ed will look into how often IRT objects are found in query statistics and help the DBTF explore new data samples from the RIPE Database. · Sara in collaboration with ENISA to ask CERTs questions about the data contained in the IRT object. · Each member of the DBTF will work on a different RIPE Database purpose/requirement. 8. Next meeting The DBTF decided to have a teleconference call in March followed by another face-to-face in April.

1 0

Geolocation in the RIPE database
by Edward Shryane 02 Mar '20

02 Mar '20

Hi all, Here are some statistics for geolocation in the RIPE database. 25% of respondents in the recent survey use the RUPE database for geolocation. Background reading on geolocation in the RIPE database: https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database * There are 24,408 inetnum objects with a geoloc: attribute (with 7,731 distinct values). 25 different organisations are responsible for 51% of inetnums with a geoloc: attribute. * There are 516,354 inet6num objects with a geoloc: attribute (with 1,045 distinct values). 1 single organisation is responsible for 99% of inet6nums with a geoloc: attribute. * 127,105 occurrences of "51.507351 -0.127758" (London) * 130,175 occurrences of "40.712784 -74.005941" (New York) * 255,998 occurrences of "34.052235 -118.243683" (Los Angeles) There is no special query flag for geolocation - the geoloc: attribute will be included if present in any matching inetnum or inet6num. Let me know if you have any questions or would like more details. Regards Ed Shryane RIPE NCC

1 0

Notes from 4 February 2020 Call
by Boris Duval 07 Feb '20

07 Feb '20

Dear all, Here's the meeting notes from our last call. Best, Boris *RIPE Requirements Database Task Force Meeting Notes* 4 February 2020 Attendees: Shane Kerr, Nick Hilliard, Bijal Sanghani, James Kennedy, Edward Shryane, Maria Stafyla, Boris Duval Agenda: 1/ Review actions a) Nick to liaise with George Michaelson (APNIC) Update: Nick contacted George but is still waiting from him to reply. b) Ed to send RIPE Database stats to Nick and James Update: Ed started to send data samples to Nick and James and is liaising with them to determine which data sets will be the most useful to analyse. c) Boris to create and publish Database usage survey Update: The survey is now closed and collected 206 replies. For further information see agenda item 2. d) Maria to follow-up with the RACI programme manager if there are candidates interested in doing new research on database accuracy. Update: Ongoing 2/ Review survey results The task force was satisfied with the number of survey respondents and the overall quality of the feedback received. Ed mentioned that the results were useful for the RIPE NCC Database team and complementary to the 2019 RIPE NCC survey. Nick stressed out that some of the outcomes were peculiar. James mentioned that he was surprised by some of the answers, especially regarding Question 3 "What do you use the RIPE Database for?”. Bijal and Shane agreed. A high number of respondents answered that they were using the RIPE Database for personal IP address management and Geolocation purposes. These results are odd because they don’t align with the initial purpose of the Database. Nick added that the community always devised against using the Database for Geolocation but that users were still doing it anyway. Shane shared that he was surprised by the high amount of people using the Database for abuse handling. Ed mentioned that the Abuse C policy was rolled-out years ago and that the RIPE NCC actively promoted it. Shane asked what the best approach would be to evaluate the feedback received and to integrate it into the requirements document. Bijal replied that this could be discussed during the face-to-face meeting. Shane proposed to start discussing the results with the community. James agreed but added that it will be better to start this conversation after the next face-to-face meeting to give the Task Force more time to analyse the data. 3/ Next steps Boris will send the survey results excluding the open questions to the mailing list. Boris will categorise and collate the open question answers and send it to the mailing list as soon as possible. 4/ Planning next face-to-face meeting The meeting will take place at the RIPE NCC office in Amsterdam on 18 February 2020 from 9 to 16. The Task Force will further discuss the survey results and continue its work on the requirements document.

1 0

RIPE Database Usage Survey
by Boris Duval 22 Jan '20

22 Jan '20

Hi all, The RIPE Database Usage Survey is now available online at: https://www.surveymonkey.com/r/PC9HTYP <https://www.surveymonkey.com/r/PC9HTYP> The deadline to answer the survey is 31st January. We will now promote it on the RIPE NCC channels (DB page, social media etc). Feel free to also share the survey with your personal contacts as we need as many replies as possible. Thanks! Best, Boris

1 1

updates
by ripedenis＠yahoo.co.uk 19 Jan '20

19 Jan '20

Hi Shane Thanks for the update. Did anyone take minutes during the calls and meeting? Are these minutes going to be published as other Task Forces have done? I would like the discussions to be as open as possible so anyone who is interested can follow them. cheers denis co-chair DB-WG

1 0

RIPE Database Requirements Task Force status update
by Shane Kerr 18 Jan '20

18 Jan '20

Friends & colleagues, The RIPE Database Requirements Task Force was formed to create a RIPE Document containing requirements for the RIPE Database, with the intention to use that for changes to the RIPE Database going forward. In addition to some discussion on the mailing list, we have had 5 calls and 1 face-to-face meeting on the topic. While we have some conclusions in our draft document, we feel additional input is necessary, so we will be publishing a survey on Monday. In our original timeline we were to publish an outline of the document by the end of 2019, but this was too optimistic. Our current timeline involves collating the results of our survey and having another face-to-face meeting in February, with an expectation of having a draft document in mid-April. We are planning a BoF for RIPE 80, which is mid-May, to discuss the draft with the community present at the RIPE meeting. Cheers, -- Shane Kerr RIPE Database Requirements Task Force Vice Chair

1 0

Alternate Universe RIPE Database
by Shane Kerr 19 Nov '19

19 Nov '19

Fellow task force members, [ Apologies for the length. ] Yesterday on a conference call one of the things that we agreed was that it would be a useful exercise to consider what the RIPE Database would look like if we were building one from scratch today. The idea is that we can start with a set of requirements that is truly necessary. I think of this as an alternate universe version of the RIPE Database, a universe where somehow there has never been a RIPE Database, but all of a sudden 25000 network operators decided to get together and create one. -------------------------------------------------------------------------- As a starting point, possibly our other selves would look at RFC 7020 for guidance. Particularly the goals: Internet number resources are currently distributed according to the following (non-exclusive) goals: 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. 2) Hierarchical Allocation: Given current routing technology, the distribution of IP addresses in a hierarchical manner increases the likelihood of continued scaling of the Internet's routing system. As such, it is currently a goal to allocate IP addresses in such a way that permits aggregation of these addresses into a minimum number of routing announcements. However, whether IP addresses are actually announced to the Internet and the manner of their advertisement into the Internet's routing system are operational considerations outside the scope of the Internet Numbers Registry System. 3) Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. Uniqueness ensures that IP addresses and AS numbers are not allocated to more than one party at the same time. These goals may sometimes conflict with each other or with the interests of individual end users, Internet service providers, or other number resource consumers. Careful analysis, judgment, and cooperation among registry system providers and consumers at all levels via community-developed policies are necessary to find appropriate compromises to facilitate Internet operations. And also the technical considerations: As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: 1) Reverse DNS: In situations where reverse DNS was used, the policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements posed by reverse DNS zone delegation [RFC5855]. 2) Public WHOIS: The policies and practices of the Internet Numbers Registry System have included consideration of the technical and operational requirements for supporting WHOIS services [RFC3013] [RFC3912]. As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. This evolution is discussed in the next section. https://tools.ietf.org/html/rfc7020 I think that even these requirements are too broad for our re-imagined database. Lets look at the goals one by one: 1) Allocation Pool Management IPv4 has run out and IPv6 is effectively unlimited, so this is not actually a real goal any more. 2) Hierarchical Allocation While this is important in the context of IP usage (especially routing), I think that the RIPE Database only need record where it has gotten addresses from (the layer up in the hierarchy) and where it has given addresses to (the layer down in the hierarchy). 3) Registration Accuracy This one remains super important. Probably today this is our most important requirement. And the technical requirements, also one by one: 1) Reverse DNS The RIPE NCC plays a key role in the reverse DNS, but it is not clear exactly what requirements this places on the DNS. One can imagine other models of DNS delegation where the database does not contain any information about the DNS directly. However, reinventing how reverse DNS works is out of scope of our task force, and certainly including reverse DNS information in the database is a straightforward solution. 2) Public WHOIS Similar to DNS, there is no particular reason that there needs to be a public WHOIS for registration information. There may not be any particular need for there to be any public information about registrations at all. (I would prefer maximum transparency possible, but this does not seem like a strict requirement to me.) -------------------------------------------------------------------------- Getting back to our own universe, while the RIPE Database is first documented in the document RIPE 13, the original purpose for the database is probably best documented in RIPE 4: Task Force 2: Network Management and Operations European IP traffic is carried by a multitude of different infrastructures. The resulting pan-European IP infrastructure needs to be well managed in coordination with the managements of the underlying infrastructures. Currently this works well enough. With the expected growth a generally agreed management coordination is needed. This task force should develop a managament framework and collect the necessary management information. Coordination with all other task forces activities is needed. Task 2-1: Create and maintain a (`whois') database about RIPE IP networks and their management information. Term: Ongoing, reports monthly, first Dec89 Task 2-2: Create an infrastructure of operational contacts via various means of communication. Term: Jan90 Task 2-3: Create a procedure for notification of security relevant problems assuming that the networks itself are unusable. Term: Jan90 Task 2-4: Develop procedures for common network operations. These can be loosely agreed and need not be formally specified. Topics: Use of SNMP, reciprocal logins for testing purposes etc. Term: Mid90, first rep Jan90 Task 2-5: Gather operating statistics. Traffic volume. Number of networks, hosts. etc. These are useful for planning and external publicity. Term: Ongoing, first rep Jan90 Task 2-6: Set up a European NIC which makes available the results of tasks 2-1 to 2-5 to all interested parties. Term: End90, first rep Mar90 Task 2-7: Maintenance and distribution of sets of common utilities, needed for the execution of the tasks 2-1 to 2-5. Term: ongoing. Task 2-8: Create and maintain centers of expertise in certain areas: router hardware and software, NSS, IBM software, etc. Term: ongoing. https://www.ripe.net/publications/docs/ripe-004 Sadly the motivation for this particular list is not included in the RIPE document, although we can ask one of the authors (Daniel) if he thinks that it is useful for him to provide this. I tend to think in our alternate universe only the first three tasks have much relevance any more. -------------------------------------------------------------------------- So, my own straw-man proposal for the minimum set of goals of a greenfield RIPE Database would be mostly based on RFC 7020: A) Support accurate Internet number registration. B) Provide views of the registration information, including a public one. C) Include whatever data is needed to support dependent technologies like DNS and RPKI. If we can agree on a set of goals (whether a version of these or something radically different) we should be able to list requirements that follow from them. Cheers, -- Shane

1 0

Requirements for the RIPE Database... or Databases?
by Shane Kerr 18 Nov '19

18 Nov '19

Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 Cheers, -- Shane

4 3

@EXT: RE: Requirements for the RIPE Database... or Databases?
by Marcolla, Sara Veronica 06 Nov '19

06 Nov '19

Dear all, tl;dr:No, because I agree with the need to understand these several "functionally diverse” DB as ONE holistic concept of RIPE DB. Additional context: Reading the RIPE Database Documentation (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data…) it says that yes, the RIPE Database holds data for three separate registries (RIPE Internet Number Registry (RIPE INR) RIPE Internet Routing Registry (RIPE IRR) Reverse Delegation and ENUM Registry). However, while these could be three independent databases, the information in each of them is related to each other. In the past it was therefore decided to integrate the three registries into one logical database (which is also one physical database). I too substantially agree with the need to understand these several "functionally diverse' DB as one holistic concept of RIPE DB. One of the things I want to stress is that the RIPE Database is in reality used by many members of the RIPE community on a day-to-day basis and for many reasons, and if it is true that the RIPE Database has grown in complexity with more features, we need to keep in mind this practical usage, and perhaps strive for simplicity. Sara From: ripe-db-requirements-tf <ripe-db-requirements-tf-bounces(a)ripe.net> On Behalf Of Bijal Sanghani Sent: 05 November 2019 17:46 To: Shane Kerr <shane(a)time-travellers.org> Cc: ripe-db-requirements-tf(a)ripe.net Subject: Re: [ripe-db-requirements-tf] Requirements for the RIPE Database... or Databases? On 17 Oct 2019, at 14:07, Shane Kerr <shane(a)time-travellers.org<mailto:shane@time-travellers.org>> wrote: Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 I believe we should cover all databases that come under the RIPE Database umbrella today and as part of our role we should review their role and need. It would be good to hear what others think, should our work cover ALL databases within the RIPE database? Is there agreement here? Thanks, Bijal Cheers, -- Shane ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************

3 2

archive
by ripedenis＠yahoo.co.uk 25 Oct '19

25 Oct '19

Hi guys Are you using this email for your discussions and is it publicly archived as Hans Petter suggested? cheersdenis

2 1

RIPE DB Requirements - F2F
by Bijal Sanghani 24 Oct '19

24 Oct '19

Here’s the doodle for the face to face, can you please complete this by Tuesday 28th October - https://doodle.com/poll/pa6znwp39yxgp7h8 Let’s aim for a 9am start and finish by 4:30pm so those traveling can most likely get a flight home that evening, if that’s a problem for anyone please let me know. Thanks, Bijal

1 1