- db-wg - mailman.ripe.net

Whois Release 1.118
by Miguel Mosquera 29 Jul '25

29 Jul '25

Dear colleagues, RIPE Database release 1.118 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Tuesday 29th July. Whois release 1.118 contains the following changes : Resources : * Add prefixlen Attribute to Inet(6)num (#1816) * LIR-PARTITIONED PA inetnum status is not valid under ALLOCATED UNSPECIFIED (#1825) * Run RIR Authoritative Resources Task Every Hour and Import Data Only When Updated (#1749) * Removing mbrs-by-ref maintainer from set causes aut-num update containing member-of to fail (#1770) RDAP RIR Search: * Implemented administrative status on RDAP lookup but not rir-search (yet) (#1778, #1730, #1722) * Remove HTTP status code from RDAP response "title" element. (#1777) ACL: * Do not apply accounting for an Authenticated Maintainer's own Objects (#1723) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/fba36664...505c5f7a The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-118 More information on the Release Candidate environment can be found on our website: https://docs.db.ripe.net/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 14th July. Please let us know if you find any issues with this release in the RC environment. Regards Miguel Herrán RIPE NCC

2 1

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year (updated)
by Edward Shryane 16 Jul '25

16 Jul '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… And to update my previous mail from 31st March: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/4QNPE24MIDFRSG… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication since 1st January 2024, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. We found this will affect approximately 17,000 out of 62,000 maintainers. We have now split these maintainers into four batches and will notify the first batch by email *tomorrow* 11th June. We will send a reminder email for this first batch in one week (18th June), and then finally remove any inactive password hashes for the first batch in two weeks (25th June). We will wait one week before starting on the next batch of maintainers, and also give each batch two weeks notice. This should be enough time to suffiently notify affected maintainers, and to complete the process by mid-July, so we can begin to notify maintainers who are *actively* using password hashes (giving them 6 months notice before support for passwords is removed by end 2025). If maintainers need more time, or if we have many support requests, then we can adjust the timeline accordingly. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

1 1

Status of my NWI proposal
by Leo Vegoda 13 Jul '25

13 Jul '25

Hi, Where are we with the NWI I posted a while back. It got some suggestions for amendment and they all seem sensible. Do you need something from me? Thanks, Leo

1 0

Proposal: Privacy in RIPE database objects
by Rodolfo García Peñas (kix) 26 Jun '25

26 Jun '25

Hi, I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3]. My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information: - Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object. Example: person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public." Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private). This information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users. IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details. Regards, Rodolfo García (kix) PS. Thanks Jordi, Miguel for your help. [1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-t… [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… [3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOA… The content of this email reflects personal opinions and does not represent the views of any organization.

4 7

status levels
by denis walker 03 Jun '25

03 Jun '25

Colleagues Maybe I asked too many questions in one email, so I'll take it bit by bit. Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1? Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite. cheers denids

5 17

Publishing End-Site Prefix Lengths
by Randy Bush 26 May '25

26 May '25

i received a suggestion to mention this on the ripe wg list. similar to geofeed, it allows one to document the prefix length one is using. Publishing End-Site Prefix Lengths https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. randy

2 2

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

16 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 15 May '25

15 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