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.