- db-wg - mailman.ripe.net

RIPE89 Database Working Group Minutes
by Peter Hessler 17 May '25

17 May '25

Hello Database Working Group, The draft minutes from our session at RIPE89 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 Alena 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

Regarding the issue of empty AS-SET in databases
by liu haoran 16 May '25

16 May '25

As the administrator of AKIX , we have observed a recurring issue where newly joined members frequently submit AS-SET objects without populating the mandatory members attribute in IRR databases. From both operational and RPSL (Routing Policy Specification Language) specification perspectives, an AS-SET containing no members represents an invalid configuration, as it fundamentally defeats its purpose of aggregating Autonomous Systems (AS) for routing policy management. We formally propose that IRR database maintainers implement mandatory validation during AS-SET creation to enforce: 1. Require at minimum one valid AS number in the members field 2. Reject AS-SET submissions containing empty/null members attributes 3. Provide clear error messaging specifying the validation requirements This technical enforcement would align with RFC 2725 (Routing Policy System Security) recommendations while significantly improving routing registry data quality and operational reliability for Internet Exchange ecosystems.

4 5

Hierarchical AS-SET names
by James Bensley 12 May '25

12 May '25

Hi all, I raised a request with ARIN to enforce the use of hierarchical AS-SET names moving forward, as is the case in RIPE, APNIC, and LACNIC. ARIN have opened a consultation process, which closes on the 23rd of May. If you would like to see ARIN also adopt the requirement for AS-SETs to have hierarchical names, please visit the following page and contact ARIN to record your support for this request: https://www.arin.net/participate/community/acsp/consultations/2025/2025-1/ Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello(a)inter.link, Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss

1 0

RIPE Database Acceptable Use Policy Updated
by Edward Shryane 30 Apr '25

30 Apr '25

Dear colleagues, At the 183rd RIPE NCC Executive Board meeting on 21st March 2025, the following changes to the RIPE Database Acceptable Use Policy were approved: * Clarified that the RIPE NCC accounts by prefix, the size of which is determined by the RIPE NCC. This better reflects the reality of how we implemented the feature. * Clarified that the RIPE NCC may lift a permanent block of a user from querying the RIPE database on request, at our sole discretion and on a case-by-case basis. * Use the term "RIPE NCC Access" rather than "SSO". The minutes from the 183rd Executive Board meeting are available: https://www.ripe.net/about-us/executive-board/minutes/2025/183rd-executive-… The updated Acceptable Use Policy is available on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… A diff of the changes is visible in the DB documentation repository : https://github.com/RIPE-NCC/ripe-database-documentation/blame/main/docs/25.… Previous discussion: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/VNZW422LST24X6… Regards Ed Shryane RIPE NCC

1 0

Questions on "status:"
by denis walker 29 Apr '25

29 Apr '25

Colleagues I am working with the RIPE NCC to document the current rules for the "status:": attribute values. This is not an attempt to simplify or substantially change the values, although some aspects do need clarifying. There is no documentation anywhere on what the current rules are. This information only exists completely in the RIPE Database software and in the test suite for the database software. The goal is to describe all the current status rules and relationships in the RIPE Database documentation. Some of these rules have never been discussed by the community to the point of a consensus. Some are interpretations made by the database developers over the years (myself included) based on comments in various other discussions. I have some questions that need clarification from the community. I have listed them below. Some might seem obvious, but within the software some things are allowed and some things are not disallowed just because no one has ever specified what it should (not) be. If you have a strong opinion on any of these questions, please share it. Any questions that no one comments on, then as we have done in the past we will document 'an interpretation'. If the community accepts the resulting documentation, the software will be adjusted accordingly. cheers denis 1/ Is there a use case for AGGREGATED-BY-LIR more specific to AGGREGATED-BY-LIR? If so, to how many levels? 2/ Is there a use case for LIR-PARTITIONED PA more specific to ALLOCATED UNSPECIFIED? 3/ Is there a use case for LIR-PARTITIONED PA more specific to SUB-ALLOCATED PA? As the name suggests, it was introduced to partition an allocation. There are currently about 438 hierarchies with LIR-PARTITIONED PA more specific to SUB-ALLOCATED PA in the database. 4/ Is there a use case for LIR-PARTITIONED PA more specific to LIR-PARTITIONED PA? If so, to how many levels? There are currently about 83 hierarchies with LIR-PARTITIONED PA more specific to LIR-PARTITIONED PA in the database. They only exist to two levels. 5/ Should we say that SUB-ALLOCATED PA 'must' be defined in the RIPE Database? This is not clear in the address policy. As we move to a world where not everything must be defined in the database, we probably should be clear about what must be defined there. (Which may require an update to the address policy.) 6/ There are currently multiple levels of SUB-ALLOCATED PA in the database. The max that exists at the moment is 4 levels of SUB-ALLOCATED PA. Is that a reasonable level to set as a limit? Or should we not allow it at all? 7/ Should there be a limit on the number of levels in a LEGACY hierarchy?

1 0

Re: DRAFT Agenda @ RIPE90 - Database Working Group
by William Sylvester 21 Apr '25

21 Apr '25

All, We are a few weeks away from RIPE90 in Lisbon, Portugal. Our session will be after the morning coffee break @ 11:00 in the Main room on 15 May (Thursday). Please take a look at the NWIs to foster good discussion at the meeting. The NWIs are viewable at: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ Below is the draft agenda, please feel free to offer feedback as appropriate. If you have an interest in presenting to the working group please contact the Database Working Group Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net>. Best regards, William, Peter, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 20 mins Edward Shryane, RIPE NCC C. Your Presentation Here – 25 mins, You, Your Org D. NWI Review – 10 mins, WG Chairs Z. AOB (open discussion)

1 0

Whois Release 1.117
by Edward Shryane 17 Apr '25

17 Apr '25

Dear colleagues, RIPE Database release 1.117 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 17th April. Whois release 1.117 contains the following changes : Inetnum status hierarchy : * Parent status for LIR-PARTITIONED PA cannot be ASSIGNED PA (#1669) * ASSIGNED PA Cannot have less/more specific ASSIGNED PA (#1672) * Aggregation by LIR Parent should not be allowed for Aggregation by LIR (#1673) * Do not allow LIR-PARTITIONED PA under SUB-ALLOCATED PA in (#1702) RDAP RIR Search: * RDAP Self Links Must Have the Type Set (#1685) * RDAP Validate Correct Key Before Redirect (#1689) * RDAP Fix Relation For Cross-Prefix Inetnum Range (#1693) * RDAP Bottom should check Parent does not CONTAINS search term (#1701) * RDAP Non Existing Search IP Terms in TOP and UP (#1703) * RDAP Add "-rdap" prefix to Relations And Change links (#1700) * RDAP Minimum status for Relations (#1705) NRTMv4: * NRTMv4 Correct aut-num object class name in delta file (#1692) * NRTMv4 Client Reject Deltas When Discontinuous and reinitialise (#1699) * NRTMv4 Client Reject update in case client is ahead instead of reinitialise (#1698) OAuth 2.0 (not ready for production use yet) : * Support OAuth 2.0 (#1688) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/66dd8671...fba36664 The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-117 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 31st March. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year
by Edward Shryane 02 Apr '25

02 Apr '25

Dear colleagues, According to January's updated migration plan to remove all MD5 hashed passwords from the RIPE database in 2025 : https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication in the past year, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. Using 1st January 2024 as a cut-off, we found this will affect approximately 17,000 out of 62,000 maintainers. Accordingly, between this April and June, we will split these affected 17,000 maintainers into small groups and email each group separately, explaining that we plan to remove any such hash(es) from their mntner object. We will give each group at least one week's notice before updating their mntner object. We will not quote a password hash in any email to avoid exposing it, the maintainer is expected to know which password(s) are in active use. Affected maintainers will be free to create a replacement MD5 hashed password themselves. However as passwords will be removed by the end of 2025, we will encourage them to switch to an alternative authentication method instead, such as API keys. Most affected maintainers have an alternative method of authentication. However, approximately 3,000 of those do *not* have any alternative. If a maintainer is left without any authentication method, the Forgot Maintainer Password process will have to be followed to regain access to the maintainer. We plan to leave these maintainers until last. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

2 3

RIPE NCC User Research on OAuth 2.0 Authentication
by Edward Shryane 14 Mar '25

14 Mar '25

Dear colleagues, On 16 April, the RIPE NCC will host an Open House from 13:00 to 14:00 CET to discuss and demo the new OAuth 2.0-based authentication solution for maintainers in the RIPE Database. We have developed a prototype and would like to share it with the community to gather your feedback and find out what your needs are. Please join us for this online discussion. Whether you are a database maintainer, network operator or just interested in authentication developments, your feedback will help shape the final implementation. You can sign up at: https://ripe.net/s/open-house-oauth2-authentication Regards Ed Shryane RIPE NCC

1 0

Mailupdates were not applied to the RIPE database
by Edward Shryane 13 Mar '25

13 Mar '25

Dear colleagues, Between approximately 12:34 UTC on March 11th and 08:18 UTC on March 13th, some mailupdates messages were not applied to the RIPE database. This was due to an upgrade of the database software. The current Long Term Support (LTS) release of Mariadb dropped a reference to mysql which the mailupdates script depended on. If you did not receive any acknowledgement for a mailupdates message during this time, then please re-submit the mailupdate. The DB team apologies for any inconvenience this incident may have caused. Regards Ed Shryane RIPE NCC

1 0