RIPE Database Working Group Minutes RIPE 89
Thursday, 31 October 11:00 - 12:30 (UTC+1)
Chairs: David Tatlisu, Peter Hessler, William Sylvester
Scribe: Alena Muravska
Status: Draft
A. Introduction
Working Group Chair, Peter Hessler, opened the session, welcomed attendees and noted that he would chair the meeting as the other co-chairs were unable to attend. He also thanked the RIPE NCC staff for their support and the stenographers for their work. Peter reminded all speakers to maintain a reasonable pace when speaking to assist the stenographers in capturing the discussion accurately. He then went through the agenda for the session and invited Ed Shryane to begin with the operational update.
B. Operational Update
Edward Shryane, RIPE NCC
Ed Shryane, RIPE NCC, summarised the RIPE Database team’s work over the past six months, including three Whois releases and measures taken to address outages caused by updates with excessive maintainer references. He apologised for the disruptions and assured that steps had been taken to prevent similar issues.
Ed highlighted usage statistics, infrastructure updates, and upcoming changes, such as phasing out MD5 passwords in 2024 to improve security and revising email policies to resume delivery to temporarily failed addresses. He also outlined commitments from the draft 2024 Activity Plan, including enhancing query and update resilience, modernising database deployments, and advancing compliance with RDAP and ISO 27001 standards.
Peter asked about the potential issues with the RIPE NCC's handling of soft bounces, specifically regarding servers that use greylisting. The concern was that greylisting initially rejects emails with a temporary error (451) but expects retries within a shorter timeframe, such as four hours. Retrying every 24 hours, as planned, would likely result in persistent failures. Peter offered to discuss potential solutions.
Ed clarified that the outgoing NCC server supported grey listing. He clarified that the mail might go out a bit slower, but they didn’t receive a permanent failure on those messages.
Gert Döering, SpaceNet AG, asked how feasible it would be to map bounces to allow RIR accounts and then display this in the LIR Portal. He gave an example of five emails attributed to an LIR account and maintainers which weren’t receiving mails and if shown in the Portal, the account holder could fix the issue.
Ed thanked Gert and explained that the issue had not been addressed due to time constraints but acknowledged it was a broader problem affecting multiple RIPE NCC services. He noted that this topic was discussed in the RIPE NCC Services Working Group the previous day and said that the NCC did need to improve handling of undeliverable mail by making the process more transparent for users.
Rüdiger Volk asked if mail bounce handling was only for responses from the RIPE Database or for all mail handling.
Ed said that they had implemented it only for the RIPE Database due to time constraints.
Rüdiger replied that he had been unsubscribed from RIPE mailing lists over the last few decades which he hadn’t been happy about.
Hans Petter Holen, RIPE NCC, acknowledged that inconsistent handling of undeliverable mail across services was a widespread issue, with different software implementing it in various ways. He cited an example where Board members were unsubscribed from the internal Board mailing list. He suggested creating a master bounce list to standardise actions across services when an email bounces. He also highlighted the challenges posed by stricter spam policies enforced by major providers like Microsoft and Google, which were impacting email delivery. The issue was being thoroughly analysed internally and was being addressed alongside other priorities.
C. Dead-ends and Car Parks
Lee Kent, beIN
Lee from beIN outlined the challenges his organisation faced in using the RIPE Database to contact bad actors, citing issues like inaccurate data, fake email addresses, and misleading physical addresses. These problems, he explained, hinder efforts to address abuse and copyright infringements, even through legal means such as subpoenas.
While acknowledging the RIPE NCC’s support, Lee said that maintaining accurate information is a shared responsibility. He encouraged community engagement to improve data quality and processes and expressed his willingness to collaborate with stakeholders to address these challenges and achieve better outcomes.
Cynthia Revström, speaking in a personal capacity, noted that there had long been consensus that the RIPE NCC was not the Internet police and that it would have been unreasonable to expect the RIPE NCC to validate every address for all users. She questioned what the RIPE community or the RIPE NCC could realistically do to address the issue.
Lee responded that there should be a clear process to address inaccuracies in the Database, emphasising that it was the community's responsibility to ensure accurate and contactable information. He questioned why the community would allow a small minority of bad actors to exploit the system for harmful activities while clarifying that he was not asking the RIPE NCC or anyone else to act as enforcers but he asked for a framework that would facilitate reasonable communication with the responsible parties of Database resources.
Peter clarified the RIPE NCC's role in validation, stating that the NCC validates the entities receiving resources, such as members and PI end users, but does not typically validate the assignments issued by those resource holders.
Lee highlighted that the main challenge was often identifying the entity responsible for the resource, which was a block in the process. While acknowledging the RIPE NCC's workload and the limitations of the validation process, he said that it was important to address the inaccuracies.
Brian Story from Gamma Telecom asked whether the RIPE NCC and the community recognised that insufficient outreach or inadequate support could be perceived as evidence of a lack of seriousness in addressing these matters, potentially leading to greater external oversight or the risk of litigation.
Peter, answering on behalf of the Working Group, said that there were many different stakeholders with conflicting opinions on how the data should be represented.
Smahena Amakran, RIPE NCC, clarified that an unreliable email address didn’t mean that it was invalid. For invalid email addresses, she said that the RIPE NCC followed a validation process and that they did follow up with these issues.
Alex de Joode, AMS-IX, highlighted the existence of the DSA and an EU-level Working Group on streaming piracy, which is set to produce a report by the end of 2025. He said if the community failed to participate in addressing these issues, the EU would likely intervene, leaving no option for inaction.
In response, Peter asked Alex how the community could engage in the process and requested a brief summary for the Database Working Group on ways to participate at the EU level. Alex agreed and stressed the importance of collaboration between the community and resource holders to effectively tackle Database issues. He suggested that ongoing dialogue, such as presentations and special sessions, could demonstrate to legislators that the community is actively working with rights holders to find solutions. While acknowledging that a perfect solution may not be achievable, he noted that visible efforts by the community could reduce the risk of legislation negatively impacting the RIPE NCC. Alex added that he would contact the RIPE NCC to organise a combined session in Lisbon involving the Database and Security Working Groups, as well as lobby groups.
Farzaneh Badii, Digital Medusa, said that there was a need to respect resource holders' privacy rights when addressing Database issues and called for proportionate solutions. She criticised intellectual property advocates for actions that harm Internet accessibility and argued that IP and DNS resolver blocking often have disproportionate impacts. She stated that the Database’s role should be limited to providing accurate information and opposed the idea of the RIPE NCC taking on dispute resolution responsibilities.
Lee said that he had since spoken to people at RIPE 89 and that there had been a suggestion to hold a BoF to open up the discussion and discuss alternatives.
Wolfgang Zenker, punkt.de, said that it would be helpful if a Whois request for an IP address led to a supply allocated range and to add a node to the answer for the Whois server of how to get to the real holder, the right customer that owns that IP address.
Peter asked whether Wolfgang was asking for a similar set up to AFRINIC’s inetnum 6nums parent allocation or a remark in the field or in the full chain to be returned. Wolfgang said that he was requesting a remark and a hint in the full chain.
Rüdiger Volk asked in jest whether the solution for the community was to go to an IPv6‑only network. Lee responded that he did actually prefer Geoff's approach from the session in the morning; that everything was based on DNS.
Hans Petter Holen said that registry accuracy was a core priority for the RIPE NCC. He explained that an internal project was analysing datasets across systems to define and improve accuracy standards. Referencing his earlier presentation, he noted that matching data to business registers was part of the process but acknowledged challenges such as unverifiable locations like PO box addresses.
He stressed the importance of community input and collaboration, particularly through the Database Working Group, to clarify responsibilities and improve delegation chains. Hans Petter also called for agreed definitions of accuracy and transparent data presentation, aligning these efforts with the RIPE NCC’s roadmap and expressed enthusiasm for working with the community to address these challenges and improve processes.
Tom Strickx, Cloudflare, cautioned against framing the conversation solely around rights holders and their concerns, as it could sometimes shift toward a narrative of “protecting the children.” He stressed the importance of balancing these discussions with privacy considerations, which had already been raised by others in the community.
Tom also urged the community to actively engage with the Digital Services Act (DSA) at the European level. He warned that failing to do so could lead to unfavourable outcomes similar to those experienced with forced arbitration and legislation. He pointed to recent legislative efforts at both EU and national levels, citing examples from France, Italy, Portugal, and Spain, where processes have been largely unilateral and challenging for the community. He strongly encouraged proactive involvement to avoid such scenarios, which could have negative consequences for the community.
D. UTF-8
Edward Shryane, RIPE NCC
Ed presented the history and progress of enabling UTF-8 support in the RIPE Database, noting that most official languages in the RIPE region were not supported due to current Latin 1 encoding. While technical barriers have been resolved, Ed asked for community feedback on whether UTF-8 should be adopted for specific objects and attributes, such as names and addresses, and whether the default character set for key interfaces should change to UTF-8.
Lars Liman, Netnod recommended looking into how ICANN went through the process.
Peter Koch, DENIC, pointed out the risks for human interoperability and noted that APNIC stuck to Latin 1 and said that it would be very helpful to understand why that was.
Leo Vegoda, Polus LLC / PeeringDB, expressed his strong support for people's names being presented as they would want them presented as well as company names being presented as they were in company registries and said that it was a step in the right direction and thanked Ed for the work here.
Cynthia Revström, speaking in a personal capacity, suggested referencing the IETF for examples of handling names with both Unicode and Latinised versions. She highlighted the challenges posed by differing conventions across languages and proposed adding new fields for non-ASCII data while maintaining existing ASCII fields for compatibility. She also recommended exploring methods like Punycode to ensure data remained accessible even in Latin 1 encoding, particularly for outputs.
Tom Strickx, Cloudflare, proposed that an additional field be added to indicate the encoding used when the data was originally inserted (e.g., Latin 1 or UTF-8). This would help users identify potential issues when querying data in a different encoding, such as UTF-8 data queried in Latin 1, and aid in understanding discrepancies. The idea was put forward for consideration by the wider Database Working Group community.
Stavros Konstantaras, AMS-IX, expressed support for UTF-8, noting that it was feasible and logical. However, he echoed Leo's concern about fully supporting UTF-8 without limitations, as it could create practical challenges. He cited the example of resolving issues with a Greek operator, where all information is in Greek, posing difficulties for those unfamiliar with the language. He suggested defining and limiting where UTF-8 is supported, such as specific fields like company names or email addresses, and proposed drafting a proposal for community discussion via the mailing list before implementation.
Ed proposed summarising the key topics discussed and sharing them on the mailing list to facilitate further community discussion. He suggested that the next step could involve drafting a problem statement. Peter supported the idea and recommended including a list of current fields that support Latin 1, as some were already identified in the discussion. He encouraged the community to provide input on additional features, such as allowing submitters to specify their preferred Latinization of names, and to review how other RIRs and organisations handle similar issues. He said it was important to maintain consistency with other RIRs where possible.
E. MD5
Edward Shryane, RIPE NCC
Ed outlined the RIPE NCC’s plan to phase out MD5-hashed passwords due to their vulnerabilities, proposing API keys as a more secure alternative for automated updates. He also addressed less secure credential transmission methods and plans to transition users away from these practices.
The migration plan included notifying users in advance, providing support for switching to alternatives, and gradually phasing out MD5 passwords in 2025 to minimise disruption. Ed noted that 29% of maintainers still used MD5 passwords and said the importance of balancing security improvements with user support. He invited community feedback on the draft plan.
Peter thanked Ed and said that they had run out of time for questions but encouraged participants to bring any questions to the mailing list.
F. NWI Review
WG Chairs
Peter explained that over the summer, the Chairs had reviewed the status of the existing Numbered Work Items (NWIs) for the Database Working Group. Two NWIs, NWI-2 and NWI-17, related to displaying history for database objects, were found to still be relevant and interconnected, and work on them will continue. For other NWIs, the Chairs plan to circulate a list via the mailing list in the coming weeks to seek community consensus on whether to continue or discontinue them.
Z. AOB (open discussion)
Peter addressed the review of the minutes from RIPE 88. While no comments were received via email, Cynthia Revström pointed out a typographical error in the first sentence, which referred to the "RIE Chair" instead of the "RIPE Chair." This correction was acknowledged, and with no further comments, the minutes were declared final. The session concluded with encouragement to provide feedback on all RIPE 89 sessions and reminders to vote in the RIPE NCC and RIPE PC elections.