Draft RIPE Database Working Group Minutes RIPE 91
Thursday, 23 October, 09:00 ‐ 10:30 (UTC +3)
Chairs: David Tatlisu, Peter Hessler
Scribe: Antony Gollan
Status: Draft
Stenography transcript
A. Introduction
Peter Hessler, Database WG Co-Chair, welcomed attendees and ran through the agenda. The minutes from RIPE 90 were approved.
Peter thanked Piotr Strzyżewski, RIPE NCC Executive Board, for his work to clean up the archived actions list and minutes. This was important for the history of the WG and so he wanted to acknowledge that here.
B. NWI Review
David Tatlisu and Peter Hessler, Database WG Chairs
Presentation
David Tatlisu, Database WG Co-Chair, shared the results of his review of the Numbered Work Items (NWIs), starting with NWI-2, which would make the history of deleted objects visible. The chairs had gone through the email archives and found little discussion in the 11 years that this item had been open, which indicated there was little interest. He therefore proposed that they close the item.
Niall O’Reilly, RIPE Vice-Chair, suggested the room applaud to indicate the level of support for David’s proposal. The WG indicated there was enough support to close NWI-2.
David moved to the next item. NWI-17 had been created to meet a recommendation from the RIPE Database Task Force, which was about giving data to researchers on a case-by-case basis according to specific criteria defined by the RIPE community. However, he hadn’t seen any discussion on what those criteria should be. They could create a new email thread to request an evaluation from the RIPE NCC on this, since it was the data controller and thus responsible under GDPR. Alternatively, they could drop the task of finding criteria for research access, or they could drop NWI-17 altogether and simply say that the RIPE NCC was responsible for ensuring GDPR compliance.
Niall asked if David had a recommendation.
David said he thought they should close this item, since there had been no interest from the community after several attempts to reopen the topic.
David said that NWI-20 aimed to fix the inconsistency between PERSON: and ROLE: objects by removing the phone number requirement and making email addresses the primary mandatory contact method. NWI-20 also added a new attribute to allow alternative communications methods like messaging platforms to be specified. Retroactively enforcing the change would require updating around one million PERSON: objects, many of which had not been modified in years, which made full compliance unlikely. Instead, the proposal could update the template and apply the new requirements only to future changes, allowing for a gradual transition. He also noted that the RIPE NCC’s Policy Officer had confirmed that NWI-20 did not affect RIPE policy and therefore did not need to go through the Policy Development Process (PDP). David highlighted that the proposal would improve operational communication while also reducing the amount of personally identifiable information stored in the RIPE Database, as users would be able to remove physical addresses and phone numbers in favour of email or alternative contact methods.
Leo Vegoda, And Polus/PeeringDB, said he was one of the three people who had put together the proposal for NWI-20. He suggested David reverse the order of his previous slide, since the real driver behind this item had been adding support for alternative contact methods like Signal, as people were more likely to respond if they could be contacted via their preferred method. In his work on PeeringDB, people had come to him to say that they didn’t use email. While he had no objection to aligning PERSON and ROLE objects, he also didn’t think this would do anything useful. If they were only going to do part of this item, he thought they should focus on the part that involved adding support for new contact methods.
David clarified that the two bullets in his slide were in no particular order and he agreed that the focus was really on adding new contact attributes.
Niall responded to a comment David had made that NWIs were sometimes seen as the fast-track or “PDP-lite”. While he understood that this was not David’s intention, he noted that some community members did view NWIs as a way to bypass the Policy Development Process. He said that engineering changes and new features should be considered business as usual when they stayed within the existing policy framework, particularly when confirmed by the RIPE NCC’s Policy Officer. However, he cautioned against “NWI creep” beyond the policy envelope and said the community should take a trust-but-verify approach when the RIPE NCC gave assurances in this regard. He added that not every minor change needed to go through the PDP, and ultimately they should let common sense prevail, which was something Rob Blokzijl had always advocated for.
C. RIPE NCC Operational Update
Edward Shryane, RIPE NCC
Presentation
Ed gave the RIPE NCC’s operational update. He covered recent Whois releases, web application improvements, Terms and Conditions updates, archived action-list work, operational statistics, the deprecation of MD5 hashed passwords, NWI-20, proposed NONAUTH clean-ups, RDAP work, UTF-8 support and NRTMv4 mirroring.
Peter Hessler, speaking for himself, said his organisation relied on a third-party application to update the database that only supported MD5 within the RIPE NCC service region. He had been asking the vendor to update this, but all human users who touched the database were already using the SSO method. He said they had done as much as they could while still depending on the third-party application.
Peter also said that, regarding the NONAUTH Database, his organisation had created an object for resources that had originally been allocated in another RIR because it had been easier to maintain the object in the RIPE Database. Since then, the other RIR had made it easier to update the object there, and that was now the preferred place for it. He said they were ready for the RIPE NCC to delete the NONAUTH object.
Ed asked whether Peter had received the RIPE NCC’s emails about MD5.
Peter said he had, but they were stuck waiting for someone else to do the work.
Ed said many other maintainers were in a similar situation, and that this was something the RIPE NCC needed to discuss with the community before the end of the year, given the deadline to remove MD5 hashed passwords.
Stavros Konstantaras, AMS-IX, said he fully supported decommissioning the NONAUTH Database and recommended keeping this work in the action plan. AMS-IX had stopped using the RIPE NONAUTH Database for route server filters a few years earlier and had not seen any operational impact or complaints. The only issue they had seen was with AS112, but he understood this was being moved to the official RIR and signed with RPKI by mid-November. He said he saw no meaningful reason to keep RIPE NONAUTH in the ecosystem and was happy to share information or data from AMS-IX.
Ed said he would like to hear from other operators who still depended on NONAUTH, so the RIPE NCC could understand why and look for ways to end that dependency without causing operational impact.
Stavros said the dependency was probably mostly legacy, as people forgot the database existed when things continued to work. Ed said that because the proposed clean-ups affected many NONAUTH objects, the RIPE NCC needed to be careful. The speaker said they could not expect to succeed 100%, but that if people did not wake up, they might need to be prompted to fix things. Ed said this would be taken into account in any clean-up proposal.
Peter Hessler, speaking as WG Co-Chair, thanked Stavros for mentioning the AS112 issue. He asked whether the RIPE NCC could look for NONAUTH objects that had been created through IANA or ICANN action, such as special reserved ASNs or address space, as these might require special handling. Ed said that if the affected resources could be identified, the RIPE NCC could look for matching prefixes. Peter said the IANA registration documentation should contain references for these special-use numbers. Ed said this was something they could share with the WG.
Niall asked whether the RIPE NCC had compiled a list of the top three RDAP clients.
Ed said this depended on the user-agent strings in HTTP requests, but that RDAP was still a minority of queries, at less than 5%.
Niall said that if he wanted to stop using Whois, he needed something at least as convenient as Whois was today.
Ed said this was a cross-RIR effort and that the goal was to make RDAP as featureful as Whois, but Whois had a head start of more than 30 years. He added that more than 90% of query traffic was still port 43.
Emanuele Iovini, Europol, asked about the more than 8,000 undeliverable email addresses Ed had mentioned. He said he was concerned about contactability: whether people could be contacted in some way, and what the consequences were if they could not be contacted by the RIPE NCC. He said this could become a vulnerability if people deliberately made themselves unreachable.
Ed said there were over 900,000 email addresses in the RIPE Database, which made this a difficult problem to address at scale. The RIPE NCC mostly discovered undeliverable email addresses through Whois update notifications. If a permanent delivery failure was received, the address was marked as undeliverable so the RIPE NCC would not continue sending bad email and risk being blocked by mail providers. He said most email addresses in the RIPE Database were user-maintained and the RIPE NCC had no control over that data, though there was a RIPE policy mechanism for Abuse-C validation. Abuse-C involved around 84,000 email addresses, rather than the wider set of around 900,000 email addresses in the database.
Leo Vegoda, speaking for himself, said email deliverability was not binary. Some mail providers accepted email but did not pass it on to end users, and an email address that worked for some senders might not work for everyone. He said this was one of the drivers for NWI-20, as email was hard and people might want to be contacted through other methods.
Ed agreed that the community might need to look at alternatives to email, as Whois depended heavily on email to contact users about changes to the database. He said large mail providers could be difficult to work with, and that failure responses were often non-standard and hard to parse. He added that the figure of 8,000 undeliverable addresses was likely an underestimate, as it only reflected addresses the RIPE NCC tried to contact day to day.
Angela Dall’Ara, RIPE NCC Policy Officer, clarified that the business-rule changes discussed under NWI-20 did not affect RIPE policy. The relevant policy required a contact, and adding optional contact methods did not change that. She said unreachable email addresses were followed up at an organisational level, depending on which address was affected. She also noted that Marco Schmidt would address some related topics later in the Address Policy WG.
Niall said there was a division of labour and a hierarchy of contacts. In the Database WG, and in the RIPE NCC team Ed led, the concern was the RIPE Database and its engineering. Knowing the customer was more a matter for the registry function. The RIPE NCC’s immediate customers were the LIRs, while more remote customers were the responsibility of others further down the chain. He said this cascade of responsibility was understood in the law enforcement community, but it was not something Ed could fix. It would be useful if everyone’s problems could be solved through a one-stop shop, but it did not work that way.
Emanuele asked whether technical contactability issues were escalated so they could be understood at a higher level. He said that even if an Abuse-C address was technically deliverable, that did not necessarily mean anyone actually read or acted on the messages. What mattered was whether an entity could actually be contacted.
Ed said the RIPE NCC knew and validated its members, but there were levels in the database hierarchy where third-party organisations were responsible for data in assignments. He said that where data was maintained by a third party, the first step was to contact that organisation and ask them to fix it. He also said the RIPE NCC was working to make query responses clearer about which data the RIPE NCC was responsible for and which data was the responsibility of a third party.
Peter said he understood Emanuele’s concern. He had found abuse-c to be unworkable in some cases, where the RIPE NCC could validate the address but a normal sender could still be rejected by the mail server. He said this was separate from the further question of whether a human would actually respond, and that deliverability was only half the battle.
Ed said abuse-c validation meant that if the RIPE NCC could deliver the abuse-c message, the validation was satisfied. What happened after that was outside the RIPE NCC’s control, though he said people should contact the RIPE NCC if an organisation was misbehaving.
Peter Koch, DENIC eG, said there seemed to be some confusion between whether an object was mandatory in the RIPE Database and whether there was a legal or policy obligation on the person maintaining that object. He said the community should address that confusion rather than trying to solve it with technology, which might create more confusion.
Peter Hessler, speaking as WG Co-Chair, said the chairs would like the RIPE NCC to send the draft NWI-20 solution definition to the mailing list. He said the draft should include what would happen to existing data when attributes changed from required to optional. He also proposed a two-week discussion period for the UTF-8 discussion so the WG could reach consensus and avoid another item remaining open for 11 years.
D. AOB
Peter Hessler asked whether there was any other business. A speaker reminded him that there had been an email to the mailing list about changes to the NWI process. Peter asked the WG to send comments, as the chairs wanted feedback on this.
Peter reminded attendees to vote in the Programme Committee that day, to vote in the NRO NC election by Friday, and, if they were RIPE NCC members, to vote in the General Meeting election. He then closed the session.