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

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

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 co-chair volunteers
by David Tatlisu 06 Apr '26

06 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.

1 0

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