DBTF Bof

Minutes

On 5 May 2021 from 16:00 to 17:30 (UTC+2), the RIPE Database Requirements Task Force (DBTF) held a remote BoF session via Zoom.

Slides

Recording

General Feedback

Rüdiger Volk, speaking for himself, asked if the reference for the task force’s final document would be the draft published in October 2020. He noted that the task force’s charter mentioned that it would publish regular draft documents.

Bijal Shanghani, DBTF Chair, confirmed that the latest draft (published in October 2020) would be the basis for the final document. The task force had decided to publish a final draft after tackling open issues with the community. She mentioned that the task force sent multiple emails to the Database Working Group (DB-WG) mailing list asking feedback on the draft text about these issues.

Rüdiger said this was not mentioned on the web page and at this stage the task force’s final draft would be very unlikely to reach consensus.

Daniel Karrenberg, RIPE NCC, agreed and added that more transparency would be in order.

Rüdiger also pointed out that some links on the web page were broken and there was no mention of the RIPE 81 BoF.

Boris Duval, RIPE NCC, said that the RIPE NCC would update the page.

Bijal said the minutes of the task force contained a lot of information about the task force’s work and progress.

Cynthia Revström, speaking for herself, said that looking at an entire year’s minutes could take a lot of time and intermediate summarised notes would be helpful.

James Kennedy, DBTF, said the task force had published one draft, hosted multiple BoFs, and presented updates at RIPE Meetings. He added that the task force always welcomed recommendations to improve its transparency.

Daniel shared general feedback on the draft document and offered some help on how to structure it. He explained that it needed more information on the status quo, stakeholders and the requirements (including conflicting requirements). [He later sent this feedback viaemail.]

Cynthia and Rüdiger mentioned that there was still more work to be done on the document before publishing a final version. She added that it would be useful if the task force posted more often in the DB-WG.

Mirjam Kühne, RIPE Chair, pointed out that after the publication of the final document, the community would have to evaluate each of the task force’s recommendations and discuss their implementation.

Rüdiger asked if the task force still wanted to stick to its original timeline and publish the document before RIPE 82.

Bijal said the task force could change the timeline again, but would like to conclude its work so other parties (the RIPE NCC, WGs) could take over.

Open Issues

Legal Address

Randy Bush, RGnet OÜ, said advertisers were also interested in getting contact information from the RIPE Database. He added that RIPE’s purpose was not to serve the needs of LEAs or parties other than network operators.

Rüdiger mentioned that publishing the legal address of resource holders would not help to fulfil the original purpose of the RIPE Database, which was to facilitate network operations. He added that even if the legal address was published, it would not be helpful to LEAs.

Peter Koch, DBTF, explained that the RIPE NCC already had the legal address of top-level resource holders in the RIPE Registry, but this information could only be disclosed via a court order. He explained that there were two extremes between publishing all legal addresses or using a court order but no middle ground available at the moment.

Randy said requiring a court order to access this information was a sound process and publishing the data was a whole different subject.

Cynthia asked if top-level resource holders also included PI holders. She said LEAs had other sources to get the legal address of resource holders and they could always get a court order if needed.

Kaspar Kelder, EC3, shared his perspective as an LEA and said that even though law enforcement could find this information in different ways, there was a lot of cybercrime and it was not always easy to engage in cross-border translation processes. Publishing the legal address in the RIPE Database could help LEAs to be more efficient in their work and that would benefit Internet security in general.

Cynthia mentioned that the barriers to access this information were justified and it was not the role of the RIPE NCC to publish this data. Knowing the location and name of the resource holder should be enough information in most cases. She further explained that the RIPE NCC would have find it hard to distinguish legal persons from natural persons, especially regarding partnerships.

Bijal said the RIPE NCC did know if you were an individual or a company.

Maria Stafyla confirmed and said that natural persons and individuals would not be affected by this recommendation. She added that the RIPE NCC had ways to define whether a partnership should be regarded as a natural vs legal person and suggested they share more details on this process after the BoF to save time.

Kaspar said LEAs could indeed use the name and location to find a potential criminal but that would take a lot of extra time and resources. Having the legal address published would help them be more efficient in their work. He suggested they weigh the concerns/risks (e.g. privacy, respect of checks and balances) against the advantages (e.g. more efficient investigations) to find a way forward on this.  

James said another alternative would be to find a middle ground such as publishing the corporate ID or giving access to verified LEAs. Cynthia agreed that finding a middle ground would be better than publishing all legal addresses.

PERSON objects

Rüdiger pointed out that PERSON objects were not always reliable, as some contained role information and some ROLE objects contained personal information. Rüdiger also mentioned that in many cases, PERSON object data was filled in by a third party which was problematic. He also said he didn’t like the idea of adding verification mechanisms to PERSON objects.

Cynthia said it would not be easy to solve this issue as people could easily add personal data to a ROLE object, but that keeping both as an option until there was a solution would be good. She added that “defaulting” objects, which is a recent addition to the RIPE Database, could help mitigate part of the issue.

Edward Shyrane, RIPE NCC, mentioned that this change was useful but only had a marginal impact to help reduce the number of PERSON objects in the database. He added that he will soon contact the LIRs that are creating most of these objects to better understand how to mitigate the situation.

Cynthia asked Ed for statistics on the impact of defaulting objects. Ed said he would try to come up with a graph by RIPE 82.

Rüdiger commented that the small impact might be due to old templates used by LIRs to enter information and asked Ed if the RIPE NCC had discussed this change with big LIRs.

Ed answered that those LIRs were probably using their own mechanisms, so it would not make a great difference to update those templates.

James agreed that there was no perfect solution to this issue. The task force was working on data management principles (e.g. data minimisation) to give better guidance on how to deal with data stored in the RIPE Database.

Historical information

Cynthia said that filtering was good, but too much “smart” filtering might be complicated and that removing fields (e.g. remarks) might be an easier solution.

Peter said this was valuable input and should be considered by the community when it looked at implementing this recommendation.

Daniel explained that as a researcher, he needed a comprehensive overview of all historical data in the database. As such, he was always concerned about deleting some of this data. He also mentioned that data minimisation of personal data should be included in the task force’s document. He added that when an object was deleted and re-added later, the history was lost. He suggested finding a solution to this problem.

Randy said that as a researcher he agreed. This data was useful for his work. However, researchers were not the main “clients” of the RIPE Database.

Peter asked the community for use cases regarding historical data.

Nick Hilliard, DBTF, agreed that use cases would be help to inform decision on how to deal with historical data. The main issue was to formulate a requirement that would also cover personal data and GDPR concerns.

Rüdiger pointed out that some of this data might not only be used for research and the community should be careful when choosing to disclose data.

Cynthia said that it also depended on why you needed certain types of historical data and the scope of the research to better define what to keep and what to delete.

James said that as there were a lot of acquisitions in the telecommunications sector and sometimes no proper handover, historical data was useful to fill the gaps and understand how networks were set up.

Daniel said it was hard to define in advance what he would need as a researcher (in terms of historical data) and that this might include personal data. He added that it was the job of the task force to reconcile these diverging needs and perspectives.