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

Something wrong?
by Hank Nussbacher 22 Mar '26

22 Mar '26

Hi, When attempting to update an in-addr.arpa object today, I repeatedly get: Unexpected error: please retry later Did not happen yesterday. Is it just me or everyone? Regards, Hank

6 11

ASN Reuse
by Antonis Chariton 30 Jan '26

30 Jan '26

Hello DB WG, As RIPE has been handing out new ASNs from previous allocations that have been returned for several months now, I wanted to ask if there’s any plan to clean up an entry somehow before reassigning the AS. With the current system you can request an AS, get it, and then have ROAs (ASPAs too?) / route{6,} / as-set objects, etc. from the previous one or more owners. I recently got an AS with valid ROAs and route objects for some IPv4 still pointed its way from a couple of operators ago (according to the bgp.tools history). For bonus points, it’s also included in a DE-CIX IXF feed and shows up as connected there :) Does it make sense to clean up objects or notify entities including an AS upon its return back to the available pool? Since you can’t really know who will get it and when, it’s unlikely you really mean to authorize announcements with a ROA, or IRR routes. It also probably doesn’t make any logical sense to include it in an as-set. I stumbled upon this when I tried generating filters with bgpq* and it added a few unknown /22s without me recognizing them. Pim here (in Cc) also had the same question :) Thanks, Antonis

9 17

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 14 Jan '26

14 Jan '26

Dear colleagues, The RIPE NCC database team published an updated plan in January to deprecate MD5 hashed passwords by the end of 2025: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… Since then, we have been working towards this deadline: * Added support for API key and OAuth 2.0 authentication * Notified maintainers and removed inactive passwords in June (including any passwords not used since January 2024) * Notified maintainers by email who are actively using passwords in July, September, October and November * Added a warning to the database web query page that passwords are deprecated * Added a warning to Whois update responses that passwords are deprecated I presented at the DB-WG session at RIPE 91 that use of password authentication is still very high: 32% of all updates used password authentication, by about 150 maintainers. By last week, this has decreased to 17% of all updates by about 105 maintainers. There is still a risk that the database community may not be ready for the end of year deadline. Taking this into consideration, I propose the following updated plan for the end of year deadline: * At the beginning of January (e.g. Monday January 5th at midday CET), remove all passwords from the RIPE database, after notifying maintainers and the working group. * Allow maintainers to add a password back to their maintainer if they still really need to use one (e.g. for operational reasons). * In the following Whois release, around the end of January, remove support for passwords altogether, again after notifying maintainers and working group. This gives us a rollback plan in case there are maintainers that need some extra time, and still allows us to follow through with deprecating passwords. In the meantime, we will continue to monitor use of password authentication. We also want to hear from any maintainers who need assistance with the migration, we are happy to help. Please let us know your questions or comments. Regards Ed Shryane RIPE NCC

2 7

Database API Key Flag added to the LIR Portal Users Page
by Edward Shryane 08 Jan '26

08 Jan '26

Dear colleagues, I am pleased to announce that the RIPE NCC has implemented a feature in the LIR Portal to display a "Database API key" flag on the Users page, if the user has any API key(s) to make updates in the RIPE database. This flag is only visible to Admin users. Regards Ed Shryane RIPE NCC

1 0

Last call for discussion regarding NWI-2 and NWI-17
by David Tatlisu 06 Jan '26

06 Jan '26

Hi Everybody, At RIPE 91 I talked about how we would like to cancel NWI-2 and NWI-17, which both concern some variation of historical data in the RIPE database. NWI-2 concerns lifting some arbitrary limitations in the retrieval of historical data, as well as allowing the retrieval of deleted objects which have not been re-created. NWI-17 is significantly more complex, as it centers around implementing the Database Requirements Task Force Recommendations [1], and I suggest three possibilities for the future of this NWI: 1. Try to move NWI-17 forward by requesting a GDPR compliance report from the NCC 1. Since the RIPE NCC is the data controller GDPR compliance is technically solely their responsibility 2. Try to move this NWI forward by reducing the problem stated in the Database Requirements Task Force Recommendations by removing the special case for researchers getting wider access to data 3. Cancel NWI-17 Considering the discussions about both NWIs have died down over the last years, I would suggest we cancel both NWIs while keeping the option to re-open them in case interest grows. With this, I would like to cancel both NWI-2 and NWI-17 on January 5th assuming the working group does not want to keep them open. Please keep in mind that I do understand that these NWIs have not been created for the fun of it, and have good reasons behind them, but lack of discussion around these NWIs even considering several attempts to rejuvenate them also tells a story. [1]: https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… Me talking about them at RIPE91: https://ripe91.ripe.net/programme/meeting-plan/sessions/38/R7WC3F/ Thank you for your feedback. David Tatlisu, On behalf of the Database WG Chairs. --- To me, in a personal capacity, closing them would be a formality as they have not had active discussions over the last several years, making them unofficially but effectively cancelled already.

3 3