- db-wg - mailman.ripe.net

NWI-21: "Registration Number" Implementation Plan
by Edward Shryane 04 May '26

04 May '26

Dear colleagues, Following is the implementation plan for the NWI-21 "Registration Number" feature. We plan to go live with this feature on Thursday 30th April, in time for the RIPE 92 meeting in May. Introduction ------------ Adding a registration number to organisations in the RIPE Database was proposed by Marco Schmidt at the Address Policy session at RIPE 91. See slides 14 to 17 : https://pretalx.ripe.net/media/ripe91/submissions/FJ7YSH/resources/RIPE91_U… Following the RIPE Meeting, a Problem Statement was published to the DB-WG: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/77NQDFTMHLIOLE… Following the discussion, consensus was declared on the Problem Definition and the Solution Definition was agreed by the Database working group: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6S5ZIQ4TTCPNQF… RIPE Database ------------- The Database team is responsible for adding a new "reg-nr:" attribute to the organisation object template in the RIPE database. The attribute will only be added to organisations co-maintained by the RIPE NCC and cannot be modified by the organisation’s maintainer. The value is free text, as the value will vary by registry. The "reg-nr:" attribute will be visible in filtered Whois query responses and will be included in the nightly database dump files once we have finalised updating the relevant documentation.. RIPE Database Web Application ----------------------------- The Database team will add the "reg-nr:" attribute to organisations in query and lookup responses, and will be highlighted as a RIPE NCC managed attribute. As "reg-nr:" is a RIPE NCC managed attribute, users will not be able to add a "reg-nr:" to an organisation object themselves. The web application will not provide a link to a registry website. After internal review, it was decided that this would introduce significant complexity and would require ongoing maintenance effort considering that registry platforms and URLs can change over time. Registry Team ------------- The Registry team is responsible for validating the existing registration number data before it is published. The data should be consistent, where possible, for each national or regional company registry. Also, the Registry team is responsible for ongoing updates to the registration number. Internal Registry Software -------------------------- The Software Engineering team is responsible for synchronising the registration number from the internal registry to the RIPE database, after the Registry team has performed its validation. The software will perform the following validation for an organisation’s registration number: * Not have any leading/trailing whitespace * Only consist of Latin-1 characters * Not contain a "#" (reserved for a comment in RPSL) * Maximum length 60 characters If the organisation is a natural person or government entity, then "reg-nr: Not Applicable" is published. Regards Ed Shryane RIPE NCC

7 11

reg-nr entity types
by Cynthia Revström 04 May '26

04 May '26

Hi db-wg and ncc-services-wg, I'm not sure if this necessarily belongs in db-wg or ncc-services-wg but I felt like it might be of interest to both. Now that the reg-nr fields have been populated I have noticed some interesting places where it is present and where it is omitted. As far as I understand it, it is supposed to be omitted from orgs referring to natural persons (I assume including sole proprietors) and government agencies while being included for basically all other kinds of entities. When looking at the data for some Swedish entities I noticed that for both non-profit associations and government agencies, there were those with reg-nr and those without. I would expect non-profits to have reg-nr (except for the cases when they don't have one) while I would expect gov agencies not to have one. One example of a gov agency having reg-nr is SUNET, the Swedish NREN: ORG-SA58-RIPE As SUNET is also the employer of one of the current RIPE NCC EB members I would expect that the NCC would be somewhat familiar with the fact that it is a gov agency. I highlighted that I was worried about this kind of issue when we discussed this proposal in the db-wg in November so I can't say that I'm too surprised. I am however thankful that I at least haven't observed any cases of a natural person having a reg-nr on them as that was my biggest worry by far. -Cynthia

2 1

Whois 1.122 Release
by Edward Shryane 30 Apr '26

30 Apr '26

Dear colleagues, We have deployed Whois release 1.122 to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th April. The Whois 1.122 release contains the following changes : * Support UTF-8 in Free Text Attributes ("descr:" and "remarks:"). * NWI-20: Adjusting contact method requirements and adding new methods. * Do not allow "mnt-lower:" on inetnum ASSIGNED PA * Allow user to remove mnt-lower from ASSIGNED resources UTF-8 in Free Text Attributes ("descr:" and "remarks:") Implementation ---------------------------------------------------------------------- We have implemented support for UTF-8 in "descr:" and "remarks:" attributes, as described in the Solution Definition and Impact Analysis: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/V363E7FTMOXXZ3… Be aware that only Unicode code points included in IDNA 2008 are supported. Any unsupported characters are substituted with a "?". In addition to the existing latin-1 encoded dump and split files, we will also be publishing daily dump and split files with UTF-8 encoding, named with a "utf8.gz" extension. These files will be available on the FTP site after the production release at : https://ftp.ripe.net/ripe/dbase/ NWI-20: "Adjusting contact method requirements and adding new methods" Implementation ------------------------------------------------------------------------------------- We have implemented NWI-20 as described in the Solution Definition: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/CYCFEN2S3XTY3… We have implemented the following changes to the object templates: * The "e-mail" attribute becomes mandatory on person. * The "address" attribute becomes optional on both person and role. * The "phone" attribute becomes optional on person. * Added a new "contact:" as an optional attribute type on person, role, organisation, irt. Be aware that the "contact:" attribute value may contain a URI fragment (i.e. a "#" character), for example signal.me (see https://signal.miraheze.org/wiki/Signal.me_URLs) This is normally interpreted as an RPSL comment as defined in RFC 2622. We have decided to treat the URI fragment character in "contact:" attributes as part of the attribute value and *not* as the beginning of a comment. Other Changes ------------------------------------------------------------------------------------- The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6a2a42c...052a4c13 The release notes are in DB documentation: https://docs.db.ripe.net/Release-Notes The data in the Release Candidate environment is a dummified copy of production from 13th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Making Resource Holders Easier to Identify: Introducing reg-nr: in the RIPE Database
by Marco Schmidt 30 Apr '26

30 Apr '26

Dear colleagues, We’re happy to share that, as of 30 April, the reg-nr: attribute is now available in the RIPE Database following the completion of NWI-21. https://www.ripe.net/community/wg/active-wg/db/numbered-work-items/ First proposed at RIPE 91 in the Address Policy Working Group and then discussed further in the Database Working Group, it’s now in place ahead of RIPE 92. This is a great example of how community input can quickly turn into something tangible and useful. Thank you to all who provided feedback and contributed to this outcome. The reg-nr: attribute adds the official company registration number of resource holders to organisation objects co-maintained by the RIPE NCC. This makes it easier to clearly identify organisations, especially where names are similar or the same. Please note that this does not apply to all organisation objects. For privacy reasons, a reg-nr: with value "Not applicable" will be published for natural persons and governmental organisations. If you come across information that appears incorrect or incomplete, please let us know by sending an email to ripe-dbm(a)ripe.net. Our Member Services team will follow up. More details are available in the RIPE Labs article: https://labs.ripe.net/author/marco_schmidt/making-resource-holders-easier-t… Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Call for co-chair volunteers
by David Tatlisu 28 Apr '26

28 Apr '26

Hi Everyone, My current term as a DB-WG co-chair will expire at RIPE 92. To me it's a little hard to believe how quickly time passed, and looking back a lot has changed. As per the chair selection process any member of the RIPE community may stand for chair. If you have any questions about the experience, training opportunities or would like to express your interest in this position, please contact the chairs at db-wg-chairs(a)ripe.net *by 21 April. *Kind regards, David On behalf of the Database WG Chairs.

2 1

Whois 1.122 Release
by Edward Shryane 16 Apr '26

16 Apr '26

Dear colleagues, We have deployed Whois release 1.122 to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th April. The Whois 1.122 release contains the following changes : * Support UTF-8 in Free Text Attributes ("descr:" and "remarks:"). * NWI-20: Adjusting contact method requirements and adding new methods. * Do not allow "mnt-lower:" on inetnum ASSIGNED PA * Allow user to remove mnt-lower from ASSIGNED resources UTF-8 in Free Text Attributes ("descr:" and "remarks:") Implementation ---------------------------------------------------------------------- We have implemented support for UTF-8 in "descr:" and "remarks:" attributes, as described in the Solution Definition and Impact Analysis: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/V363E7FTMOXXZ3… Be aware that only Unicode code points included in IDNA 2008 are supported. Any unsupported characters are substituted with a "?". In addition to the existing latin-1 encoded dump and split files, we will also be publishing daily dump and split files with UTF-8 encoding, named with a "utf8.gz" extension. These files will be available on the FTP site after the production release at : https://ftp.ripe.net/ripe/dbase/ NWI-20: "Adjusting contact method requirements and adding new methods" Implementation ------------------------------------------------------------------------------------- We have implemented NWI-20 as described in the Solution Definition: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/CYCFEN2S3XTY3… We have implemented the following changes to the object templates: * The "e-mail" attribute becomes mandatory on person. * The "address" attribute becomes optional on both person and role. * The "phone" attribute becomes optional on person. * Added a new "contact:" as an optional attribute type on person, role, organisation, irt. Be aware that the "contact:" attribute value may contain a URI fragment (i.e. a "#" character), for example signal.me (see https://signal.miraheze.org/wiki/Signal.me_URLs) This is normally interpreted as an RPSL comment as defined in RFC 2622. We have decided to treat the URI fragment character in "contact:" attributes as part of the attribute value and *not* as the beginning of a comment. Other Changes ------------------------------------------------------------------------------------- The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6a2a42c...052a4c13 The release notes are in DB documentation: https://docs.db.ripe.net/Release-Notes The data in the Release Candidate environment is a dummified copy of production from 13th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 0

Re: ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 08 Apr '26

08 Apr '26

Dear colleagues, I would like to follow up on my previous message regarding ENUM (e164.arpa) and share a brief update on where things currently stand. As noted earlier, the RIPE NCC has been reviewing the operational status of the e164.arpa registry in light of its very limited usage, recent discussion in the RIPE Database Working Group, and the broader considerations surrounding the service operated by the RIPE NCC. Since my last email, the Internet Architecture Board (IAB) has discussed the matter at its last meeting. At this stage, the IAB has indicated that it would like to hear further feedback from the community before taking any further position. ITU-T has also initiated a consultation with Member States on the possible closure of the ENUM system under e164.arpa. As mentioned previously, this is an important part of understanding whether the service is still needed by the relevant delegating authorities and whether there is a continued operational justification for maintaining it. While the immediate trigger was a limited operational question, the topic also touches on broader considerations around community input, governance responsibilities, and coordination with relevant external bodies such as the IAB, IANA and ITU-T. For the RIPE NCC, the goal remains to approach this carefully and transparently: to understand whether there is still a real need for the service, to avoid unnecessary operational or compliance risk, and to ensure that any future steps are informed by both community feedback and the views of the appropriate stakeholders. I will present on this topic at RIPE 92, where I will provide more background, summarise the discussions to date, and invite further feedback from the RIPE community. In the meantime, I encourage anyone with views on this matter to share them on the RIPE NCC Services Working Group mailing list so that the discussion can continue openly and with the benefit of community input. Best regards, Hisham Ibrahim Chief Community Officer RIPE NCC On Tue, 17 Feb 2026 at 16:09, HMI IMH <hibrahim(a)ripe.net> wrote: > Dear colleagues, > > This message summarises recent discussion regarding ENUM (e164.arpa) and > clarifies the scope and next steps. > > The RIPE NCC has operated the e164.arpa registry for many years under > instructions and coordination arrangements established with the ITU-T and > IAB. These arrangements, and the operational context for how the registry > is run, are described here: > https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ > > Recently, a request was raised in the RIPE Database Working Group to > support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted > that RDAP support for ENUM is not currently implemented, but could be added > if there is clear interest. We also checked current query patterns and > found a few hundred ENUM-related queries per day in DNS and in Database; so > low usage, but not zero. > > Following discussion on the Database WG mailing list, including replies in > support, we proposed implementing RDAP support for ENUM. While this is a > limited operational change, it was recognised that anything touching E.164 > and e164.arpa can raise political questions that go beyond the purely > technical. > > As e164.arpa is directly linked to the ITU E.164 numbering system, the > relevant points of contact are typically national administrations and the > entities they designate. This led us to consult ITU-T Study Group 2 to > clarify the status of ENUM and its usage and needs for ongoing support. > ITU-T will ask member states for their feedback and share this with us. > > ITU-T provides an established and coordinated channel to reach those > administrations, and importantly confirm whether any delegating authorities > still rely on the service, so our technical decisions are informed by > real-world use and help us avoid unnecessary operational risk, confusion, > or compliance headaches (including in the context of regulatory frameworks > such as NIS2). > > We are also reaching out to the IAB regarding these operations, which the > RIPE NCC performs under its instruction on behalf of the global DNS and > Internet community. > > I am sharing this message with the DNS, Database, Cooperation and RIPE NCC > Services Working Group mailing lists to ensure all relevant working groups > are informed. If you wish to share thoughts in response, please reply to > the thread on the RIPE NCC Services WG mailing list. > > Best regards, > Hisham Ibrahim > Chief Community Officer, > RIPE NCC >

1 1

Call for presentations
by David Tatlisu 06 Apr '26

06 Apr '26

Hi Everyone, RIPE 92 is coming up, and we still have 10 - 20 minutes of space in our agenda. If you have something in mind and would like to present in Edinburgh, please get in contact with us via db-wg-chairs(a)ripe.net, send a message on this list or upload a proposal in Pretalx. https://pretalx.ripe.net/ripe-92/cfp We are very flexible and can accept talks *until 19 May.* * *Kind regards, David On behalf of the Database WG Chairs.

1 0

Last call for feedback for NWI-20 (Updating contact method requirements and adding new ones)
by David Tatlisu 06 Apr '26

06 Apr '26

Hi Everyone, After a lot of lively discussion just before RIPE 91, and a short presentation at RIPE 92 it appears that the community is largely in favor of this proposal. Behind the scenes, Ed and his team are ready to start the implementation. Should you have any input on this proposal, please post it before *11 April 2026. *Kind regards, David On behalf of the Database WG Chairs.

1 0

Extending API Keys
by Fallon Albrecht 01 Apr '26

01 Apr '26

Dear colleagues, We are extending the API key model introduced for the RIPE Database to the remaining API Keys in the LIR Portal, providing a more secure and flexible way to manage access across services. API keys for My resources and IP Analyser can now be created directly within the services where they are used, while centrally visible and manageable via RIPE NCC Access. You can read more about these changes and what they mean for you here: https://labs.ripe.net/author/fallon-albrecht/extending-api-keys-beyond-the-… Kind regards, Fallon Albrecht Manager Business Applications

1 0

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

RIPE Database 1.121.2 Release
by Edward Shryane 18 Mar '26

18 Mar '26

Dear colleagues, RIPE Database release 1.121.2 has just been released to the production environment. The only change from release 1.121.1 is a fix for a cross-site vulnerability affecting the Syncupdates service. We have removed support for the HTTP GET method in Syncupdates to update an object using a URL-encoded object. Now we only support the POST method. This helps to protect the RIPE database from Cross-Site Scripting (XSS) exploits, and the GET method was rarely used (the last update was in mid-January). We are following our internal Vulnerability Management policy remediation timelines and therefore not waiting for the normal release cycle. Regards Ed Shryane RIPE NCC

1 0

RIPE Database 1.121.1 Release
by Edward Shryane 16 Mar '26

16 Mar '26

Dear colleagues, RIPE Database release 1.121.1 has just been released to the production environment. The only change from release 1.121 is a fix for a cross-site vulnerability affecting the Syncupdates service. We are following our internal Vulnerability Management policy remediation timelines and therefore not waiting for the normal release cycle. Regards Ed Shryane RIPE NCC

1 0

Whois 1.121 Release
by Edward Shryane 04 Mar '26

04 Mar '26

Dear colleagues, RIPE Database release 1.121 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Wednesday 4th March. Whois release 1.121 contains the following changes : * Removed support for MD5 passwords in mntner and IRT object types * NWI-21: Added "reg-nr:" attribute to the organisation object type * Run GRS mirror imports after dump is updated, not all at midnight * Fix RDAP publicIds array * Return top-level IANA allocation or redirect RDAP domain queries The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6db089c3...94ed67c2 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 16th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removing MD5 Hashed Passwords from IRT Objects in the RIPE Database
by Edward Shryane 18 Feb '26

18 Feb '26

Dear colleagues, On 4th March along with the Whois 1.121 release to production, we also plan to remove MD5 hashed passwords from all IRT objects. This has already been done for all MNTNER objects in January. On 14th January, we informed 171 affected IRT maintainers that we will remove all passwords from IRT objects following the next Whois release, and also notified the DB-WG: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/WQWBPPB2AMTVI… We plan to email the remaining 135 affected IRT maintainers today to remind them of the plan and announce the specific date. We have asked the maintainers to switch to an alternative authentication method, including X.509, PGP or SSO. MD5 hashed passwords in IRT objects are used to authenticate adding an mnt-irt: reference to IRT objects in inet(6)num objects. This has only been done a handful of times this year, so we expect the impact to be low. Please let us know if you have any questions or comments on this plan. Regards Ed Shryane RIPE NCC

1 0

ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 17 Feb '26

17 Feb '26

Dear colleagues, This message summarises recent discussion regarding ENUM (e164.arpa) and clarifies the scope and next steps. The RIPE NCC has operated the e164.arpa registry for many years under instructions and coordination arrangements established with the ITU-T and IAB. These arrangements, and the operational context for how the registry is run, are described here: https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ Recently, a request was raised in the RIPE Database Working Group to support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted that RDAP support for ENUM is not currently implemented, but could be added if there is clear interest. We also checked current query patterns and found a few hundred ENUM-related queries per day in DNS and in Database; so low usage, but not zero. Following discussion on the Database WG mailing list, including replies in support, we proposed implementing RDAP support for ENUM. While this is a limited operational change, it was recognised that anything touching E.164 and e164.arpa can raise political questions that go beyond the purely technical. As e164.arpa is directly linked to the ITU E.164 numbering system, the relevant points of contact are typically national administrations and the entities they designate. This led us to consult ITU-T Study Group 2 to clarify the status of ENUM and its usage and needs for ongoing support. ITU-T will ask member states for their feedback and share this with us. ITU-T provides an established and coordinated channel to reach those administrations, and importantly confirm whether any delegating authorities still rely on the service, so our technical decisions are informed by real-world use and help us avoid unnecessary operational risk, confusion, or compliance headaches (including in the context of regulatory frameworks such as NIS2). We are also reaching out to the IAB regarding these operations, which the RIPE NCC performs under its instruction on behalf of the global DNS and Internet community. I am sharing this message with the DNS, Database, Cooperation and RIPE NCC Services Working Group mailing lists to ensure all relevant working groups are informed. If you wish to share thoughts in response, please reply to the thread on the RIPE NCC Services WG mailing list. Best regards, Hisham Ibrahim Chief Community Officer, RIPE NCC

1 0

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

inverse search help?
by Hank Nussbacher 18 Dec '25

18 Dec '25

I forgot how to do an inverse search to find my ASN in as-sets. So Google AI tells me: Yet: hank@nocvm:~$ whois -h whois.ripe.net -i members as378 % 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. %ERROR:105: attribute is not searchable % % "members" is not an inverse searchable attribute. %ERROR:101: no entries found % % No entries found in source RIPE. % This query was served by the RIPE Database Query Service version 1.120 (DEXTER) What am I doing wrong? Thanks, Hank

6 6

Defining NWI-21
by David Tatlisu 16 Dec '25

16 Dec '25

Hi Everybody, Marco Schmidt started a thread discussing the addition of the "reg-nr:" attribute to organization objects. Summarizing it very briefly, it would make identifying legal entities easier, as their government-issued identification number would be available in the database. The Database team plans on including a URL to the responsible company register on the web frontend where available, while the WHOIS and RDAP will not include the URL. Marco already went through the effort of writing both a Problem Definition and a Solution Definition, which "fast-tracked" a few steps of the NWI process :p From what I was able to determine, the discussion on the working group did not lead to any change of either the Problem or Solution Definition. There were some concerns about potential privacy issues which, as far as I was able to tell, were able to be rectified to a sufficient degree as the new data is already public and potential edge-cases were brought to the attention of the RIPE-NCC. With this, I now declare consensus on the Problem Definition and have determined that this can continue using the NWI process. Please share any additional feedback for the Solution Definition until 22nd December. Considering the current state of the discussion, I think it's safe to say that the working group participants will have agreed on the Solution Definition after this date. With this, I thank all participants for their contributions to this NWI. Kind Regards David Tatlisu, On behalf of the Database WG Chairs. ### Copied from Marco's original e-Mail from 17th November Problem Statement: The RIPE Database should allow users to uniquely identify Internet Number Resource holders. Today, organisation objects linked to RIPE NCC co-maintained inetnum, inet6num, and aut-num objects include the validated legal organisation name and country code where the resource holder is legally registered. However, these attributes alone are not always sufficient to uniquely identify a legal entity, for three main reasons: 1. Identical names: In some jurisdictions, different companies can legally register with the same or very similar names. 2. Transliteration issues: In countries using non-Latin scripts, converting names from and into Latin characters can produce inconsistent or inaccurate results. 3. Data discrepancies: Differences between the validated legal information (org-name and country) and the contact details maintained by the resource holder (for example, a postal address in another country) can create confusion and make identification more difficult. Solution Definition: Introduce a new reg-nr: attribute for RIPE NCC co-maintained organisation objects, containing verified company registration numbers issued by national authorities. The RIPE NCC already holds this information for ~99% of resource holders that are legal entities. Publishing a unique and verifiable registration number will significantly improve the ability of RIPE Database users to accurately identify resource holders and cross-check them in national company registries. Only publicly available registration numbers of legal entities will be published. Natural persons remain explicitly out of scope.

3 2

Whois Release 1.120
by Edward Shryane 27 Nov '25

27 Nov '25

Dear colleagues, RIPE Database release 1.120 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 27th November. Whois release 1.120 contains the following changes : * Whois scope is now mandatory for OAuth 2.0 tokens * Added conditional attributes to object template (which depend on business rules) * Add warning in update response if API key is expiring soon * Redirect top-level IANA administrative blocks (i.e. top-level /8 allocations) to other RIRs in RDAP response * Update RDAP geofeed implementation with changes in RFC 9877 The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/1c439eb5...6db089c The release notes are also in the repository : https://github.com/RIPE-NCC/whois/releases/tag/6db089c3 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 11th November. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Improving Identification of RIPE NCC Members and Independent Resource Holders by Publishing Company Registration Numbers
by Marco Schmidt 27 Nov '25

27 Nov '25

Dear colleagues, Following my presentation at the RIPE 91 Address Policy Working Group session, I’d like to propose adding a company registration number to the organisation object type. Problem Statement: The RIPE Database should allow users to uniquely identify Internet Number Resource holders. Today, organisation objects linked to RIPE NCC co-maintained inetnum, inet6num, and aut-num objects include the validated legal organisation name and country code where the resource holder is legally registered. However, these attributes alone are not always sufficient to uniquely identify a legal entity, for three main reasons: 1. Identical names: In some jurisdictions, different companies can legally register with the same or very similar names. 2. Transliteration issues: In countries using non-Latin scripts, converting names from and into Latin characters can produce inconsistent or inaccurate results. 3. Data discrepancies: Differences between the validated legal information (org-name and country) and the contact details maintained by the resource holder (for example, a postal address in another country) can create confusion and make identification more difficult. Solution Definition: Introduce a new reg-nr: attribute for RIPE NCC co-maintained organisation objects, containing verified company registration numbers issued by national authorities. The RIPE NCC already holds this information for ~99% of resource holders that are legal entities. Publishing a unique and verifiable registration number will significantly improve the ability of RIPE Database users to accurately identify resource holders and cross-check them in national company registries. Only publicly available registration numbers of legal entities will be published. Natural persons remain explicitly out of scope. Please let me know your feedback. Questions and comments are welcome. Regards Marco Schmidt Manager Registration Services RIPE NCC

15 32

RIPE90 proposal to deprecate the RIPE NONAUTH Database
by Edward Shryane 20 Nov '25

20 Nov '25

Dear colleagues, At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database: https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… (slide 20) 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 has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data. Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it. I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated. Should RIPE-NONAUTH Objects Be Returned By Default? --------------------------------------------------- The RIPE-NONAUTH database is included by default in Whois queries. This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned. Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned. We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database. Should objects in the RIPE-NONAUTH database continue to be returned by default? Near Realtime Mirroring (NRTM) ------------------------------ Approximately 20% of NRTM requests query for updates to the NONAUTH database. Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates? Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? ----------------------------------------------------------------------------------- Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database. Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database. Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database. Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database? Should unrouted RIPE-NONAUTH route(6) objects be deleted? --------------------------------------------------------- Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July). Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose? Regards Ed Shryane RIPE NCC

8 23