Skip to main content

You're viewing an archived page. It is no longer being updated.

The RIPE Database Requirements Task Force BoF

Minutes

On 6 May 2020 from 14:00 to 15:00 (UTC+2), the RIPE Database Requirements Task Force (DBTF) held a remote BoF session via Zoom.

Members:

Peter Koch, Shane Kerr (Vice Chair), Nick Hilliard, Bijal Sanghani (Chair), Sara Marcolla, James Kennedy (co-Chair)

RIPE NCC Staff Support:

Boris Duval, Maria Stafyla, Edward Shryane

Scribe:

Boris Duval

Number of participants:

46 

Bijal Sanghani gave an update on the DBTF’s work.

IPAM

Bijal launched a Zoom Poll about IPAM and shared the results with the audience:

  1. Where do you hold your canonical IP address assignment details? (13 answers)
  • Internal database or IPAM system (5 - 38%)
  • RIPE Database (5 - 38%)
  • Internal database for detailed assignments and RIPE database for allocations (3 - 23%)
  1. What should we do about the IPAM use of the RIPE Database? (12 answers)
  • We should discourage it (3-25%)
  • We should tolerate it but provide restrictions and best practices (5-33%)
  • We should promote it and facilitate it (4-42%)

Randy Bush suggested simply ignoring IPAM usage in the Database as it’ll be hard to regulate now that it has been allowed for so long.

Shane clarified that the DBTF is trying to move away from putting unessential information into the RIPE Database and that allowing IPAM use without a clear understanding on how it might affect the overall RIPE Database might not be beneficial in this regard. He also mentioned that the Task Force was highly surprised by the results from the DBTF survey conducted earlier this year as Task Force members didn’t expect that the RIPE Database was used as an IPAM solution by so many respondents.
Peter Koch suggested that the DBTF dive deeper into IPAM by defining its usage and purpose for the RIPE Database and possibly come up with rules to regulate its usage.

Tahar Schaa agreed with Peter and added that providing documentation on how to properly manage your company’s IP address space will also be a step in the right direction.

Nathalie Trenaman mentioned that around 50% of the RIPE Database training courses are using the RIPE Database to maintain their assignments. She added that participants also mentioned that they were missing a “pull feature” from open-source IPAM tools as one of the barriers that was preventing them from entirely switching to external IPAM solutions.

Daniel Karrenberg suggested that the RIPE NCC look into offering IPAM management as a separate service from the RIPE Database.

Shane mentioned that this was briefly discussed by the Task Force and they could explore this possibility further. Peter added that some users preferred to use a hosted IPAM solution rather than host it themselves.

Erik Bais pointed out that IPAM usage of the RIPE Database is also linked to HD ratio which is one of the current policy requirements to obtain more IPv6 addresses from the RIPE NCC.

Peter replied that the Task Force already made the distinction between documentation for compliance or HD ratio purposes and that they needed to do more work to explore how to address both issues in parallel.

RPSL 

Bijal launched a Zoom Poll about RPSL and shared the results with the audience:

What should we do about RPSL? (13 answers)
  • Keep everything as-is (2-15%)
  • Look at the possibility of deprecation of RPSLng as an overall project (8-33%)
  • Look at the possibility of deprecation of individual RPSLng object types (3-62%)

Daniel Karrenberg shared that the DBTF should avoid getting into too much specifics and stay at a higher level by asking themselves questions such as “what do we do if there is a big variation of details in the RIPE Database?” or “what do we do if we know that there is wrong information stored in the RIPE Database?”.

Nick Hilliard agreed but added that the issue around RPSL data is bigger than it seems as the RPSL data structure constitutes a lot of different types of objects maintained in the Database. He further explained that RPSL data is highly convoluted and might be the most incorrect dataset stored in the RIPE Database.

Nick asked the community for feedback about RPSL during the Routing Working Group at RIPE 80.

Peter Koch thanked Daniel for this input and clarified that the DBTF was already discussing high-level topics such as how to define accuracy in context of the RIPE Database.

Geolocation

Bijal launched a Zoom Poll about geolocation and shared the results with the audience:

Is the RIPE Database really the right place to get geolocation data and do you see it as a core function of the Database that should be maintained by the RIPE NCC? (19 answers)
  • Yes, it should be maintained by the RIPE NCC (6-32%)
  • It’s not a core function of the database (10-53%)
  • It should not be in the database (3-16%)

Tahar Schaa asked what was the main motivation to store geolocation data in the RIPE Database and if it was originally a requirement.

James Kennedy clarified that geolocation was not an original requirement of the RIPE Database but pointed out that the Task Force had to consider including new requirements as the usage and users of the database evolved over the years.

Erik Bais shared that the RIPE Database’s geolocation data was actively used by many organisations for different purposes such as geo-restricting content and that a slight mistake in the country name (e.g. using IR instead of IE) can have a dramatic operational impact. He added that whether or not storing this data in the RIPE Database was a different question.

James Kennedy replied that it was always good to see this topic from a user’s perspective and that if incorrect data might have serious consequences, it might be best to store this data somewhere else.

Tahar Schaa mentioned that legitimising the use of geolocation in the RIPE Database would put the data stored in the database under much more scrutiny and will give governments more authority to step in if the data stored was incorrect.

Leo Vegoda agreed with Tahar and suggested that the DBTF look at the purpose of storing geolocation data in the RIPE Database rather than looking at it as a feature.

Randy Bush added that it should be looked at from a customer’s point of view.

IRT Objects 

Bijal launched a Zoom Poll about IRT objects and shared the results with the audience

IRT objects are mostly used by CERTs for exchange contact information and form a self-contained part of the database. Do you use IRT objects? (17 answers)
  • Answer 1: Yes (5-29%)
  • Answer 2: No (8-47%)
  • Answer 3: What’s an IRT object? (4-24%)

Mirjam Kühne mentioned that CERTs in the RIPE’s service region are using IRT objects data for coordination purposes but that they are working on improving this system as the information is currently scattered across different databases. However, she added that the RIPE Database was one of the biggest data sources for CERTs.

Peter Koch replied that the DBTF needed to look if the RIPE Database was the right place to store IRT objects information and suggested to explore this topic further.

Daniel pointed out that the RIPE Database is primarily used for number resources data and that if there was a need to link number resources data and IRT data, then the database was the right place to store this type of information. He also remembered that he got feedback from number resources users that wanted to register their go-to IRT in the RIPE Database, which would legitimise storing IRT data in the database.

Draft Document

Daniel shared that the DBTF’s first draft was not mentioning how the RIPE Database will adapt to new changes. He added that there was a danger of stagnation if the DBTF started to list existing purposes and uses without adding room for change. He also mentioned that the document needed better structure and categorisation. He pointed out that it was important to mention in the document that the RIPE Database was an essential part of what is keeping the Internet running. Finally, he added that the DBTF should try to look at the requirements from a user’s perspective and avoid looking at it from its existing feature sets.

Daniel shared more extensive feedback about the draft document on the ripe-list.

Nick Hilliard thanked Daniel for his feedback and mentioned that this was the DBTF’s first draft and represented only a small part of their whole draft document. He added that he was happy to receive constructive feedback from the community and that it was exactly why the DBTF chose to have this BoF.

Bijal Sanghani thanked the participants and ended the BoF.