October 2026 - db-wg - mailman.ripe.net

RIPE92 Database Working Group Minutes
by Peter Hessler 25 Oct '26

25 Oct '26

Hello Database Working Group, The draft minutes from our session at RIPE92 has been published on the RIPE website, available at https://www.ripe.net/community/wg/active-wg/db/minutes/ripe-database-workin… We'd like to thank Hans from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. Peter Hessler, On behalf of the DB WG Co-Chairs

1 1

My Resources Usability and Resource Check features deployed
by Edward Shryane 19 Oct '26

19 Oct '26

Dear colleagues, Today we have deployed a new version of the Resources page on the DB website: https://apps.db.ripe.net/db-web-ui/myresources/overview We have introduced some usability improvements based on user feedback, including displaying resources as a tree to make the hierarchy visible, which replaces the table view. We have also introduced resource checks, which allows a user to understand what needs attention. This functionality will also appear in the Assisted Registry Check workflows in the LIR Portal. If you are attending the RIPE 93 meeting next week, we encourage you to sign up for a Usability Testing session, which will include the Resources page. Please follow this link to book a session: https://calendar.app.google/1SJjYrqmdHgHuMP16 Please let us know your feedback. Regards Ed Shryane RIPE NCC

1 0

Problem Statement for Additional RIPE-NONAUTH Cleanups
by Edward Shryane 15 Oct '26

15 Oct '26

Dear colleagues, Following the discussion on cleaning up the RIPE-NONAUTH database last year: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/SFN4AKUI2G3XCZ… and also following the discussion at the DB-WG session at the RIPE 91 and RIPE 92 meetings, here is a problem statement to reduce the size of the RIPE-NONAUTH database. Introduction ------------ The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database now contains about 44,526 objects (about the same since RIPE 92). The existing cleanup jobs and maintainers are not deleting much data. I propose to implement additional cleanups to further reduce the size of the NONAUTH database. Scope ----- I propose to implement two additional cleanups of objects in the RIPE-NONAUTH database, as previously discussed. (1) Delete NONAUTH objects with a matching VALID ROA. This will affect approximately 16,497 objects. (2) Delete NONAUTH objects with a matching object in another RIR database. This will affect approximately 27,449 objects. The implementation should initially reduce the size of the NONAUTH database by about 60%, and will continue to reduce over time. Out of Scope ------------ * I do not propose to delete the NONAUTH database completely, only to implement these additional cleanups. * RIPE-NONAUTH database objects will continue to be returned in queries. * Any objects created under IANA or ICANN action will be excluded. See https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/D7242C4PRTXOP… * Mirroring the NONAUTH database using NRTM will still be supported. Conclusion ---------- I’d like to propose creating a new Numbered Work Item for this problem statement. If the WG agrees with the problem statement, I will follow up with a more detailed Solution Definition, including: * Defining how to match candidate objects in the RIPE-NONAUTH database * Notifying maintainer(s) of affected objects in advance * Allowing maintainer(s) to opt-out (so their object is not deleted) * Documenting the cleanups on the website Regards Ed Shryane RIPE NCC

6 10

whois server surprisingly looks up items based on "netname" even when query is for ASN
by Ben Cartwright-Cox 06 Oct '26

06 Oct '26

A surprise I just encountered was I was checking AS215165 (who recently had their aut-num object deleted) and I was surprised to see the whois server reply back with a inetnum having (I assume) matched the netname instead! I know the whois server logic is a bit mythical but this seems like a obvious case of the clear intention of the user is not what is being delivered, and I assume this will confuse other programs as well What do we think? (Example output below)-- $ whois AS215165 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2a13:2200:a::/47' % Abuse contact for '2a13:2200:a::/47' is 'xxxx' inet6num: 2a13:2200:a::/47 netname: AS215165 # 2150 country: GB admin-c: YZS9-RIPE tech-c: YZS9-RIPE status: ALLOCATED-BY-LIR mnt-by: mnt-tw-sky-digital-1 created: 2025-02-25T02:19:45Z last-modified: 2025-02-28T02:42:00Z source: RIPE org: ORG-YZS3-RIPE

2 1