RIPE Database Working Group Minutes RIPE 83

Wednesday, 24 November 13:00-14:00
WG co-Chairs: Denis Walker, William Sylvester
Scribe: Pedro Vaz
Status: Final

A) Introduction

William Sylvester welcomed the participants and started the session.

B) Operational and Cloud Migration Update

Edward Shryane, RIPE NCC

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/60-DB-WG-Operational-Update-RIPE83.pdf

Edward Shryane, RIPE NCC, gave an overview of the new features implemented in the RIPE Database since RIPE 82 and of the features that will be added next year. He reported on outages that took place during this period as well as data cleanups. He also gave a status update on the Cloud migration project and open issues.

There were no questions.

C) UI Update

Rehan Syed, RIPE NCC

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/58-Improvements-in-the-RIPE-Database-RIPE83.pdf

Rehan Syed, RIPE NCC, presented a retrospective of the RIPE Database User Interfaces (UI) from 2014 to today. He then presented the upcoming UI changes for the WHOIS interface. Finally, Rehan asked for volunteers to participate in usability testing and to share feedback on the UI of all RIPE NCC services.

Christian Bretterhofer, representing himself, asked if it was possible to retrieve all objects linked to one’s mnt-by object in the My Resources overview. Rehan replied that they were looking into more possibilities on how to expand and improve the My Resources page and welcomed Christian to give more feedback on this topic.

Wessel Sandkuijl, Prefix Broker BV, asked if it was possible to clarify the meaning of the flags in the new UI without having to move the slider. Rehan replied that what he showed in the presentation were only wireframes. He added that the best way to show the flags is still being researched and will be based on user feedback.

Raymond Jetten, Elisa OYJ, asked if it was possible to have a full text search result of one’s LIR’s objects. Ed replied that it was possible to implement a functionality to return only objects that are maintained by the organisation’s maintainer.

Ruediger Volk, representing himself, asked if there was a clear way to identify an LIR’s objects. Rehan replied that it was possible by coupling the SSO account information with the maintainer to retrieve the LIR’s objects.

D) RIPE Database Requirements Task Force Update

Shane Kerr, RIPE Database Requirements Task Force

The presentation is available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/62-RIPE-Database-Requirements-Task-Force-RIPE-83.pdf

Shane Kerr, a member of the RIPE Database Requirements Task Force, presented on the work that has been done by the task force and highlighted the main points of the task force’s final report.

Elvis Daniel Lea, v4 Escrow, pointed out that recommending that the RIPE Database shouldn’t be used an IPAM solution conflicts with current policy requirements on how to document allocations and assignments.

Shane replied that it depended on how you approach IPAM (from an operational or administrative perspective). The task force recommends not using the RIPE Database to perform day-to-day IPAM.

Mirjam Kühne, RIPE Chair, thanked the task force for its work.

Ruediger Volk, representing himself, said that a disclaimer about consensus was needed at the top of the document (similar to IETF’s documents) to avoid confusion as task forces documents don’t require consensus from the community. Ruediger also mentioned that the task force report was a good starting point but that more work was needed.

Shane said that some recommendations were made to clean up parts of the RIPE Database while others were made to clarify current RIPE Database requirements but not all of the requirements were forward looking. He added that this shouldn’t prevent more work from being done in the future on this topic. 

E) RIPE Database Purposes

Denis Walker, Co-Chair DB-WG

The presentations are available at:
https://ripe83.ripe.net/wp-content/uploads/presentations/4-Purposes83Summary.pdf
https://ripe83.ripe.net/wp-content/uploads/presentations/5-Purposes83.pdf

The session ended with Denis Walker, co-chair, who followed up on a video he had previously shared to ask for input from the community about the purposes of the RIPE Database.

Mirjam Kühne and Daniel Karrenberg mentioned that it would be best to focus on the task force’s report first and have this discussion later.

Denis agreed.

Christian Bretterhofer, representing himself, mentioned that the RIPE Database was a great resource as it was right now.

Monika Ermert, journalist, asked what the consequences of a data protection perspective would be on the purposes of the RIPE Database.

Denis replied that this discussion was not about repurposing the RIPE Database but on getting a new consensus on existing purposes.

Ruediger Volk agreed with Mirjam to avoid mixing the task force report and the database purpose discussion. He also mentioned that the purpose discussion was abstract and suggested to go through Denis’s slides to identify concrete points that need to be discussed by the community. He also mentioned that although the task force didn’t go into operational details, some technical aspects of the database such as UTF-8 should also be debated and part of the consensus process.

Denis answered that regarding UTF-8, the technicalities were fine but that the policy side needed to be considered.

Tobias Knecht, ABUSIX, asked if the purpose of the RIPE Database was connected with the policy process.

Denis replied that policies and purposes were never linked before and added that the community might need a database policy.

Athina Fragkouli, RIPE NCC, said that any use not in line with the purposes defined in the RIPE Database terms and conditions are not allowed (articles 3 and 4). She also mentioned that any changes to the current purposes will have GDPR implications.

Denis replied that this is not about changing the purposes of the RIPE Database but acknowledging them.

F) AOB (open discussion)

There were no AOBs.