RIPE Database Working Group Minutes RIPE 92

Thursday, 21 May 2026, 9:00-10:30 (UTC+1)

Chairs: David Tatlisu, Peter Hessler

Scribe: Hans Bakker

Stenography transcript

A. Welcome to the RIPE 92 Database WG

Recording:

https://ripe90.ripe.net/archives/video/1647/

Working Group Chair, Peter Hessler, opened the session and welcomed attendees. Peter started with sharing that co-chair David Tatlitsu has been elected for a new term and congratulated David on this. Peter also mentioned that Piotr and Neil found some of the missing minutes from RIPE 70 and RIPE 72, which have been published on the website. The only missing minutes now are from RIPE 73.

After this, Peter went through the agenda for the session and invited David to begin with the NWI update.

B. NWI Update

David Tatlisu, Peter Hessler, Database WG Chairs

Presentation:

https://pretalx.ripe.net/media/ripe-92/submissions/FZKSVY/resources/NWI_update_v1_ahy8aZ6.pdf

Recording:

https://ripe92.ripe.net/media/videos/david-tatlisu_nwi-update_side_20260521-090228.mp4

David mentioned that over the past six months, several NWIs progressed significantly. NWI-2 and NWI-17, both related to historical data in the database, were closed.

NWI-12 (NRTMv4) has effectively been completed on the RIPE NCC side, despite the related RFC and IETF processes still being underway, and David suggested formally closing it following further discussion.

NWI-20 introduced a major overhaul of contact methods in the RIPE Database and has been shipped. Finally, David shared that for NWI-21 the reg-nr: attribute has been added to improve the ease of identification for organisations. Implementation is ongoing and over 32K

21 org: objects have already been populated.

There were no comments or questions.

C. Operational Update

Edward Shryane, RIPE NCC

Presentation:

https://pretalx.ripe.net/media/ripe-92/submissions/WNKKMB/resources/RIPE92_DB-WG_Operati_DQUwoGM.pdf

Recording:

https://ripe92.ripe.net/programme/meeting-plan/sessions/95/WNKKMB/

Ed Shryane, RIPE NCC, summarised the RIPE Database team’s work over the past six months, including six Whois releases. Ed went through three RIPE Database outages in the past months. He apologised for the disruptions and assured that steps had been taken to prevent similar issues.

Ed went a bit deeper into the work the Database team put into fixing a cross-site scripting vulnerability of Syncupdates requests, disclosed by Sasha Romijn in February 2025 (also discussed during the plenary session). Ed thanked Sasha for her work and explained how the Database team worked on mitigating the vulnerability. Direct contact with Sasha proved to be very valuable in this. There were lessons learned and some upcoming work left for the coming months. Most important is switching from *.ripe.net cookie to OpenID Connect.

After this, Ed highlighted usage statistics, infrastructure updates, and upcoming and ongoing changes. Amongst others, MD5 hashed passwords are no longer supported and there’s support for UTF-8 in the RIPE Database. There are ongoing efforts in obtaining ISO27001 certification and in RDAP work. With regards to NWI-21 (Registration number), Ed asked the community to report any issues with data quality, and for the input on whether the attribute name “reg-nr:” causes any confusion.

On the topic of undeliverable and unsubscribed email addresses, Ed asked the community whether the RIPE NCC could reduce the number of undeliverable addresses through means other than the current process, and whether it should investigate better ways of notifying users about relevant events.

Ed concluded his presentation by asking whether the RIPE NCC should proceed with any of the proposed changes to clean up the RIPE-NONAUTH database.

Job Snijders (speaking for himself) supported removing route objects from the RIPE-NONAUTH database when matching valid ROAs or matching route objects exist in other RIR databases. He argued that these sources are more authoritative because they rely on cryptographic validation or stricter authentication mechanisms. He noted that, unlike several years ago, all RIRs now enforce strict authorisation checks for the creation of route objects, making their data more trustworthy. While he ultimately supported hiding NONAUTH objects by default, he suggested first focusing on removing clearly invalid or duplicate entries as a simpler initial step.

Ed thanked Job for his feedback.

Piotr Strzyżewski (speaking for himself) noted that the slide discussing MD5 passwords did not mention the replacement of well-known passwords. Ed acknowledged the omission and said he would send an update to the mailing list explaining how these passwords are replaced and directing interested parties to the relevant documentation for further information.

Piotr Strzyżewski (speaking for himself) also raised concerns related to NWI-21, particularly regarding how registration numbers are handled for government organisations. He questioned why government organisations should receive special treatment, noting that many have official registration numbers that could be published. Piotr said he could only justify exceptions in countries where such registration numbers do not exist and argued that there was otherwise no reason to treat government organisations differently.

Piotr also commented on the term “co-maintained”, which he had initially understood to mean that the RIPE NCC directly maintained database objects alongside users. Following discussions with Marco Schmidt (RIPE NCC), he understood that the intended meaning was that users remain responsible for maintaining their own data, while the RIPE NCC supports or manages aspects of the process. He encouraged the RIPE NCC to communicate this distinction more clearly to avoid future misunderstandings.

Stavros Konstantaras (AMS-IX) expressed strong support for the proposed RIPE-NONAUTH cleanup measures, saying they made complete operational sense. He noted that AMS-IX route servers had not used or mirrored the RIPE-NONAUTH database for many years and that this had not resulted in any complaints or operational issues. While he said he would even support shutting down the database entirely, Ed clarified that he was not proposing such a step.

Leo Vegoda (speaking for himself) welcomed the progress being made on internationalisation and encouraged the RIPE NCC to continue its efforts in this area. He argued that the primary challenge for RIPE Database users is not the naming of registration numbers, but rather that many users do not understand what the displayed data represents or how trustworthy it is. He suggested improving the user experience by providing clearer information about who maintains data, when it was last updated, and whether it has been verified by the RIPE NCC.

Ed responded that explanatory text and attribute descriptions are already available through hover functionality and verbose WHOIS output, although he agreed that the visibility of this information could be improved.

Leo further suggested providing additional contextual information, such as verification dates and update histories, to make WHOIS queries more accessible and useful for users.

Kenny Huang (Chair of the APNIC Executive Council, speaking for himself) asked two questions related to abuse contacts and geofeed information. He noted that APNIC also requires abuse contact validation every six months, but that community feedback suggests the policy may not be particularly effective. He therefore asked about the RIPE NCC’s experience with the process.

Kenny also sought views on supporting geofeed information through WHOIS and RDAP, noting that some APNIC members have requested stronger support for geofeed data.

Ed responded that the RIPE NCC considers abuse-c validation to be successful, citing a reduction in open tickets and improvements in data quality over time. He also noted that geofeed adoption appears to be strong in the RIPE region, with more than 50,000 related database objects currently in use.

Sasha Romijn (Reliably Coded) raised concerns about a proposal regarding hash-mark comments, noting that people already tend to add whitespace around hash marks in practice, even if that is not specified in RFC 2622. She suggested gathering data on how hash marks are actually used across records before deciding whether the standard should change. Ed responded that there is no perfect solution because the hash character cannot be escaped in either RPSL or URIs, but his review of existing data showed that comments are already preceded by a space or tab in most cases. Sasha proposed expanding the analysis to other IRRs to confirm whether this pattern holds across the broader IRR system.

Ed agreed, adding that this is not a new issue and has previously affected free-text attributes, with contact information being the main current concern.

Peter Hessler (speaking in his personal capacity, rather than as co-chair) made three comments.

First, he noted that other languages treat a hash mark as part of a word when it is attached to text, and as indicating a comment only when preceded by whitespace. He suggested that this was therefore a widely accepted approach.

Second, he said that accessing historical database data can be difficult in the current WHOIS interface and expressed support for a simpler web-based interface for reviewing historical records.

Third, regarding geofeeds, Peter said they had been extremely valuable for network operators and were one of the few effective ways to publish accurate geolocation information. He strongly encouraged wider adoption of geofeed attributes, noting that they help address many geolocation issues that are otherwise difficult to resolve through geolocation vendors.

D. Reliable IRR Mirroring with NRTMv4

Sasha Romijn, Reliably Coded (IRRD, IRRexplorer, internet.nl)

Presentation:

https://pretalx.ripe.net/media/ripe-92/submissions/N7HBNS/resources/slides-dark-1_FdGYxS0.pdf

Recording:

https://ripe92.ripe.net/programme/meeting-plan/sessions/95/N7HBNS/

Sasha Romijn, Reliably Coded, maintainer of IIRD and co-author of NRTMv4, presented the new IRR mirroring protocol designed to address the limitations of NRTMv3. She explained that NRTMv3 relies on database dumps and incremental updates but lacks reliable synchronisation status, consistent error handling, and meaningful security features, making it difficult for operators to determine whether mirrors are up to date or to troubleshoot issues.

NRTMv4 was developed to provide integrity verification, synchronisation assurance, automatic recovery from failures, scalability, and a formal standards-based specification. The protocol uses HTTPS-hosted repositories containing snapshots, delta files, and cryptographically signed update notification files. Clients can verify the authenticity and integrity of mirrored data through signatures and file hashes, while built-in recovery mechanisms help detect and resolve synchronisation problems.

Sasha reported that NRTMv4 has reached maturity, with five interoperable implementations, deployment in production by the RIPE NCC, approved by IESG and the draft currently in the IETF last call (draft-ietf-grow-nrtm-v4). She emphasised that the protocol is ready for operational use today and encouraged operators to adopt NRTMv4 to improve the reliability, security, and maintainability of IRR mirroring.

There were no questions or comments on this topic.

As a follow-up to her NRTMv4 presentation, Sasha presented early work, developed with James Bensley (Inter.link), on improving member resolution in RPSL set objects.

She explained that ambiguity can arise when AS-SETs reference other sets that share the same name across multiple IRR databases. This can lead to different results during AS-SET expansion and, in some cases, operational issues. Although such inconsistencies are not extremely common, Sasha noted that they occur frequently enough to be problematic. Her analysis identified thousands of duplicate AS-SET names across IRRs, some of which have diverged over time despite efforts to keep them synchronised.

To address this issue, Sasha introduced a new IETF draft proposing registry-scoped members. The proposal would allow references to specify the source IRR while maintaining backward compatibility with existing tools. Rather than replacing the current member's attribute, the draft introduces a source-scoped variant and requires servers to keep both representations aligned. This approach would enable gradual adoption without disrupting existing clients.

Sasha also briefly presented a second draft that would allow operators to explicitly exclude objects from RPSL sets, providing greater control over set expansion.

She invited feedback from the community and expressed interest in seeing these proposals adopted by the RIPE Database and other IRR implementations.

Stavros Konstantaras, AMS-IX, expressed strong support for the proposals.

E. Closing and WG Chair Selection

WG co-Chair: Peter Hessler

Presentation:

https://ripe92.ripe.net/media/videos/na_closing-and-wg-chair-selection_side_20260521-101208.mp4

Piotr Strzyżewski, speaking for himself, pointed out that while it was earlier mentioned that Neil helped find the minutes for RIPE 70 and RIPE 72, it was actually Nigel Titley who did this.

The session concluded with Peter’s encouragement and reminders to vote in the RIPE NCC GM and RIPE PC elections.