Interim Session - 17 January

Date: Wednesday, 17 January 2023 15:00-16:00 (UTC)

WG Co-Chairs: Denis Walker, William Sylvester, David Tatlisu

Scribe: Karla Liddle-White

Status: Draft

A) Discussing the two possible solutions for NWI4 (multivalued status:)

David Tatlisu, DB WG Co-Chair, introduced the discussion on NWI4, noting that two solutions had some support but there hadn’t been a decision on either of them. The two solutions were to add a new combined status ALLOCATED-ASSIGNED PA or to combine the prefix and the status together to be the primary key.

Edward Shryane, RIPE NCC, said that they could combine everything into one object but the downside to this was that the object was co-maintained by the RIPE NCC, the LIR and End User so combining them was not feasible for three different parties to share ownership. He continued to explain that they could combine the prefix with the status allowing an allocation and assignment of the same prefix size but different status, but that approach would break existing interfaces like RDAP.

Cynthia Revström replied that if it's not enough of an issue then another option would be to close the NWI. David Tatlisu added that the new status approach looked to be the preferred option, and not to close the NWI. Edward Shyrane proposed to go ahead with the new status and that he would bring this to the RIPE Database mailing list.

B) Discussing the use of UTF-8 in the RIPE Database

David asked attendees to discuss whether UTF-8 should be incorporated into the RIPE Database. Poitr Stryzewski, RIPE NCC Board Member, said that he was in favour of UTF-8.

Edward Shryane, RIPE NCC, said that it would not be technically difficult to support UTF-8 but stressed not to break the existing interfaces. He said that the community wanted to support more characters, particularly in organisation and person names and addresses and asked attendees whether they should combine the technical characters and include non-latin characters.

Cynthia Revström replied that the technical change should happen and then discuss which characters to include later on. Ruediger Volk added that there were breaking changes in the past, and he posed the question of which fields would be ASCII if they moved forward with this proposal. David Tatlisu said that allowing non-ASCII characters would change accessibility in the RIPE Database.

Randy Bush said that the goal here was to include characters in people’s names and street addresses and to restrict where UTF-8 could be defined and not allow its use everywhere.

Edward added that based on Cynthia’s proposal they could make the technical changes and then they would be in a position to support non-latin characters. He proposed that an action here would be for him to create an impact analysis on this proposal.

C) Following the recent breach, feedback on how authentication could be improved

David asked attendees what their thoughts were on two-factor authentication when it comes to the RIPE Database following the RIPE NCC’s response to the recent security breach. Randy said that he thought this was an SSO issue, not a RIPE Database issue.

The group began discussing the LIR Portal and SSO authentication including roles and RPKI access but it was then agreed that the RIPE NCC Services Working Group was a more appropriate place for the discussion.

D) Alternative modes of contact in the RIPE Database

Dmitry Kohmanyuk shared a document he and Leo Vegoda drafted on adding extra contact methods in the RIPE Database. He noted that the contact fields available in the RIPE Database were limited to email, telephone, fax and postal address and asked whether more modern contact methods should be included. He added that fax and phone use is in decline while other forms of communication like messaging services and social media are now more widely used. He shared that the document included examples of syntax rules and values and asked the group for their views.

Cynthia Revström said that it was a good idea but she was not in favour of the suggested syntax with a space as a separator. Cynthia added that there should be guidelines on how to format each type of contact, for example, should the brand name or the domain be shared.

E) RDAP

David began by noting that some WHOIS functionalities were not supported by RDAP yet.

Dmitry added that RDAP was the common denominator between RIRs but RDAP won’t be a replacement for WHOIS just yet. He noted that everything in RDAP was mapped as an entity and then maintainers and roles where the primary key wasn’t maintained caused collisions and returned a 500 error. He added that it was difficult to know how to fix them, but he was trying to resolve the differences.

Edward replied with some of the drawbacks in the RDAP implementation. For example a 500 error is returned if there are multiple entities with the same primary key. This can happen in WHOIS (e.g. a maintainer and a person with the same key) but it’s not supported in RDAP and is one of the differences that will be hard to fix.

Cynthia suggested that when the RIPE Database software team adds a new feature, they look at how it works with RDAP and consider how it will interact with it.

William Sylvester, DB WG co-chair, said that they could provide new interfaces with the legacy interfaces which would be the best path forward. He noted that port 43 aligned with RDAP and that this was different across RIRs and how they’re implemented in RDAP. He said that hierarchy was the main issue and encouraged the working group to find ways to find NWIs to address these issues.

Cynthia raised the issue that there was a discrepancy between person objects and role objects with regards to contact information. More specifically, person objects currently require a phone number while role objects require an email address. She suggested bringing person objects more in line with role objects by removing the phone number requirement. Cynthia said that she would bring this suggestion to the RIPE Database Working Group mailing list.

David ended the session and thanked everyone for their contribution.