Skip to main content

RIPE Database Working Group Minutes RIPE 87

Thursday, 30 November 2023, 09:00-10:30 (UTC+1)
WG Co-Chairs: William Sylvester, David Tatlisu, Denis Walker
Scribe: Ties De Kock
Status: Final

A) Introduction

William Sylverster, co-chair of the RIPE Database Working Group (WG), opened the meeting, and introduced the new co-chair David Tatlisu, who started off the first presentation.

B) NWI Update

The presentation can be found at:
https://ripe87.ripe.net/archives/video/1215/

David Tatlisu, co-chair of the RIPE Database Working Group, gave an overview of the Numbered Work Items (NWI) used by the DB WG, and discussed all NWIs that are open, or were closed since the last meeting. NWI-10, adding the country attribute to organisation objects; NWI-12, implementing NRTMv4; and NWI-14, protecting references to objects in the RIPE Database were finished since the last meeting. He then asked the room if the NWI process was a good fit for the WG, and if anyone wanted to comment.

There were no comments discussed in the room. There was one question on Meetecho that was missed.

C) Operational Update

The presentations can be found at:
https://ripe87.ripe.net/archives/video/1216/

Ed Shryane gave an update on behalf of the RIPE NCC Database team. They have had three whois releases since the previous RIPE meeting. First, 1.107 in June 2023, which added NWI 14, protecting the MNT ref. In September 2023, they released 1.108 which made improvements to the full-text search API. And on 4 December 2023, they aimed to deploy 1.109, removing prefix validation from the geofeed attribute, adding RDAP redaction, and HTTP basic and client certificate authentication. He then gave an overview of the changes in these releases and the upcoming changes to the RIPE database. One of which is a warning when a ROUTE object conflicts with RPKI, where the RIPE DB would show a banner above the ROUTE object if it conflicts with RPKI.Shane Kerr, IBM, asked if the check of ROUTE objects against RPKI was a background check, that scans for it, or if is it during query.

Ed replied that this is during query, meaning that anyone can see it, not just the maintainer of the object. This can be seen in the query response of the object.

Shane Kerr asked if someone owning objects in the database would be interested in that. When querying it might be interesting, but you cannot do anything about it.

Ed replied that indeed, you may not be able to do anything about it. But it is better to be informed when there is a RPKI ROA conflicting with a ROUTE. Ed welcomed any feedback from the community on how best to do this. The current plan is to add it to the query output.

Rüdiger Volk, no affiliation, asked if issuing a warning on queries refers to the web interface or some API, but not the traditional whois. Ed replied that this is correct. They could add a comment in port 43 with a comment, but this can be fragile if people are parsing whois objects and comments. For now, they will add it to the web output and API, and there will be a flag in the API response so people can detect it.

Rüdiger also described that the original RPSL had a specific formal grammar for the syntax. In the past, he hit issues when objects did not conform to the grammar, and he thinks a strong formal grounding for the syntax is a requirement. Ed agreed and added that this is something the WG needs to decide on before they make any changes. The RFCs specify ASCII, they already allow non-ASCII in descriptions and remarks (but not in primary keys or names), but it is something they need to be careful of. Most of the traffic is still port 43, 90% still uses latin-1 or ASCII so we need to be careful before any changes.

Harry Cross, on behalf of themselves, asked if there is a plan to expand the usage of client certificates to certificate authorities down the line. That would allow the use of short-lived certificates for one-time updates. Ed replied that the RIPE NCC can support that.

Marco D’Itri, Seeweb | DHH, mentioned that when he wrote the whois client that everybody uses. Unfortunately, in the client he implemented that responses from the RIPE server are in latin-1. So, returning LATIN-1 will cause issues unless this is changed. He totally supports returning UTF-8, but he does not have a strategy for handling it right now. Ed replied that UTF-8 is backwards compatible, and ASCII characters will still appear as ASCII characters. But anything else will change, and latin-1 will no longer be latin-1. Marco then replied that the point is that the client will re-code the input, assuming it is latin-1, and re-code it to whatever is the charset of the terminal. Ed confirmed that and mentioned that they cannot tell the terminal the character set [of the response]. Just changing from latin-1 to UTF-8 is going to be a big change. Marco answered that other whois implementations use a command line parameter on the query. This could be a very good solution, because it would allow clients to support UTF-8 at their own pace. Ed said that is a great idea and they already support converting from different character sets on update. If a client can tell them what character set, they want that is a nice solution.

Q&A:

Taras Heichenko, 1UntedID, asked if there is any information on what objects have been changed as part of the NWI 10 deployment. Ed replied that as seen in the database, the country code is now mandatory on any organisation or end user organisations with resources. They could publish the numbers in the WG, which could save some effort.

Robert Scheck, ETES GMBH, asked if the latest LTS version is Java 21. Ed confirmed this but they have not had the time to implement that. They are currently using Java 17.

D) Geolocation within RDAP

The presentation can be found at:
https://ripe87.ripe.net/archives/video/1219/

Mark Kosters from ARIN presented the work that has come up in the IETF since the last RIPE Meeting. He started with the background on RDAP. The whois protocol is old and by now all RIRs have deployed RDAP. For domain registries, ICANN is requiring the RDAP by 3-2-2024 and announced a sunset date for WHOIS of 28-1-2025. The RIRs have deployed RDAP services, four out of five RIRs support the profile, and the fifth one has planned it for Q1 2025. After this background Mark continued with the main topic, GeoFeed. RFC 8805 and 9092 detail the IP geolocation feed concept. RFC 9092 hints at using RDAP comments for geofeed. Mark’s proposal adds a geofeed extension to RDAP and geofeedv1_geofeed member in the data.

At the end Mark polled the temperature of the room by asking if this was a good idea. Nobody indicated it was a bad idea.

No questions were asked.

E) NWI-4 Tuple Impact Analysis

The presentation can be found at:
https://ripe87.ripe.net/archives/video/1221/

Ed Shryane, RIPE NCC, gave a brief presentation on the requirements for NWI-4 and the result of the impact analysis that has been done. There is a growing number of assignments that have the same size as their allocation, and NWI-4 seeks a way to model this more cleanly. Ed invited everyone to participate in the discussion on the mailing list. It is a choice between two choices with downsides, it is for the community to decide.

Wessel Sandkuijl, Prefix Broker, supported the tuple solution. He mentioned that the RIPE Database content should match as closely as possible what happens in real life.

Z) Any Other Business (AOB)

The video is available at:
https://ripe87.ripe.net/archives/video/1222/

William Sylvester, co-chair of the RIPE Database WG, opened the microphone for any other business. He wanted to propose some ideas that David had in his presentation, particularly if the DB WG want interim meetings to foster communication or if smaller groups should engage in discussions about specific interests.

Shane Kerr, IBM, thought this was a good idea as the time between RIPE Meetings is too long. Erik Bais, A2B Internet, and Mirjam Kühne, RIPE Chair, agreed. Mirjam pointed out that other WG have done similar interim sessions and have had great experience with them.

Rüdiger Volk, no affiliation, asked if this would be in a weekly format like the IETF or meeting on demand. William replied it makes sense to do this in hybrid mode and start with one or two meetings, and schedule extra if needed.

David Tatlisu, DB WG co-chair, suggested scheduling the first meeting sometime in December or early January and seeing how the demand would be. William agreed and asked the room for any other topics that anyone would like to raise. No further topics were raised.