- db-wg - mailman.ripe.net

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 05 Dec '25

05 Dec '25

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 3

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

NWI-20: Solution definition and impact analysis
by Edward Shryane 20 Nov '25

20 Nov '25

Dear colleagues, As discussed at the DB-WG session at RIPE 91, following is a draft solution definition and impact analysis from the RIPE NCC for NWI-20: "adjusting contact method requirements and adding new methods". Please let me know any questions or comments. Regards Ed Shryane RIPE NCC --- Introduction ------------ Following discussion of the NWI proposal “adjusting contact method requirements and adding new methods” on the DB-WG mailing list [1], the Co-chairs declared the problem statement as NWI-20 and asked the RIPE NCC for further input on potential solutions. Following is a Solution Definition from the RIPE NCC including an impact analysis. Requirements ------------ The following requirements are proposed in NWI-20 [1]: * Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all such contact methods optional for the public RIPE Database as long as one is chosen. * Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. * Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. * E-mail is a mandatory attribute in role and person objects (additional requirement identified during discussion) This proposal is limited to admin-c and tech-c contact types. Existing RIPE Policy -------------------- The NWI-20 proposal is not a proposal to change policy requirements for contact methods, and has no impact on current RIPE policy. Current RIPE policy documents are listed on the RIPE NCC website [2]. Object Template Changes ----------------------- The RIPE NCC proposes the following changes to the object templates in the RIPE database to satisfy NWI-20 requirements: • 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. • Add a new “contact:” as an optional attribute type on person, role, organisation, irt (see below). With these changes, the person object template becomes identical to the role template. E-mail Address is Mandatory in Administrative and Technical Contacts -------------------------------------------------------------------- The participants in the NWI discussion agreed that an e-mail address should be mandatory in “admin-c” and “tech-c” contacts. The “e-mail:” attribute is currently mandatory on organisation and role object types, but optional for person. We propose to change the “e-mail:” attribute to mandatory for person also. Creating or updating person objects will require at least one “e-mail:” attribute to be present. Address is Optional in Person and Role -------------------------------------- We propose to make the “address:” attribute optional in both person and role object types, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Phone is Optional in Person --------------------------- We propose to make the “phone:” attribute optional in person to match the role type, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Adding New Contact Types ------------------------ To support new contact types, we recommend adding a new “contact:” attribute type, that is optional and can appear multiple times on ORGANISATION, PERSON, ROLE and IRT object types. We will not change the definition of existing attributes already used as contacts. The RIPE NCC is not responsible for “contact:” attributes. All “contact:” attributes are maintained by the resource holder maintainer and are not managed or validated by the RIPE NCC. In particular it is the responsibility of the maintainer to ensure they have the right to insert the contact information in this attribute and ensure they will keep it correct and up-to-date. The syntax of a “contact:” attribute value is a URI. Any valid URI value will be accepted. If the specific application URI is recognised by Whois then it is further validated to be correct. We will add support for recognising more applications in the future. Initially, Whois will recognise and validate Whatsapp, Signal, Telegram and SIP contact URIs. Whatsapp A WhatsApp contact URI [3] uses the format https://wa.me/<number> or https://api.whatsapp.com/send?phone=<number>, where <number> is the full international phone number with country code, omitting any plus signs, parentheses, dashes, or leading zeros. You can also add a pre-filled message using ?text=urlencodedtext after the phone number. SIP A SIP contact URI [4] is a Session Initiation Protocol Uniform Resource Identifier used to identify a user or device on a SIP-based network, allowing for real-time communication sessions like voice and video calls. It follows a format similar to an email address, with the general syntax being sip:username@host[:port] Signal The Signal messaging app launched signal.me URls for this purpose back in 2021 [5]. It allows you to share a link like https://signal.me/#p/+447700900123 and have your signal client open up a chat with that person. Then, towards the end of 2022 they added support for their own sgnl scheme (although it doesn't appear to have been submitted as an IETF draft, and isn't listed on IANA). It has exactly the same layout as it's https sibling: sgnl://signal.me/#p/+447700900123. There is also support for usernames instead of the telephone number. Telegram A Telegram URI [6][7] can consist of any of the following formats : * https://t.me/share/url?url={url}&text={text} * https://telegram.me/share/url?url={url}&text={text} * tg://msg_url?url={url}&text={text} Adding New Contact Types to RDAP -------------------------------- A “contact:” attribute value will be represented in an RDAP entity object vCard “tel” element, as follows: * “type” element is set to both “voice” and “text”. * The “uri” element is set to the “contact:” attribute value. * “pref” is set according to the order of the “contact:” attribute in the object. According to RFC 6350 “vCard Format Specification”, section 6.4.1., it is expected that the “tel” value will be a “tel: URI scheme, but other schemes MAY be used. If a HTTP or HTTPS URI value is provided in the “contact:” attribute value, then we will add a contact vCard as defined in the Contact URI RDAP extension [8], as according to the RFC, at least one "mailto", "http", or "https" URI value MUST be provided for CONTACT-URI. The contact attribute type can be represented using the existing RDAP protocol so we do not need any new extension for it. Impact Analysis --------------- We foresee the following impacts on the RIPE database from these changes. * Creating person objects will require the “e-mail” attribute to be present. About 10,000 person objects are created monthly, by a few hundred maintainers. This change will cause the creation of person objects to fail if “e-mail” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. * Updating person objects will require the “e-mail” attribute to be present. There are about 2 million person objects in the database, and about half of them already have an “e-mail:” attribute. This change will cause updates of person objects to fail if “e-mail:” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. Also, about half of all person objects are never updated after they are created, so we expect a limited impact on existing objects. * Existing person objects may not conform to the new template. This can be mitigated by notifying maintainers of existing objects that the template has changed, so they can update objects accordingly. * Making mandatory attributes optional may cause some contact information not to be added and existing data to be removed. This information may be useful to other users. However, this may have the benefit of reducing the amount of unnecessary personal information in the database overall. Also it may reduce the amount of incorrect information just to satisfy the validation. There is no point adding contact information that is not useful. * Making an “admin-c” or “tech-c” reference to a person requires a mandatory contact. All contact methods besides the mandatory “e-mail” address will be optional so long as one is chosen. * A new, optional, “contact:” attribute will be added to person, role and organisation types. Client software that does not recognise this attribute should ignore it. However a “contact:” containing a telephone number should be considered equivalent to the “phone:” attribute. References ---------- 1. NWI-20 Proposal https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6SIZ2AVFPD2ZXA… 2. RIPE Policies https://www.ripe.net/publications/docs/ripe-policies/ 3. Whatsapp “How to use Click to Chat” https://faq.whatsapp.com/5913398998672934 4. SIP URI Scheme https://en.wikipedia.org/wiki/SIP_URI_scheme 5. Signal URI Scheme https://shkspr.mobi/blog/2023/02/signals-newish-uri-scheme/ 6. Telegram URI Scheme https://stackoverflow.com/questions/56971172/telegram-uri-scheme-to-send-me… 7. Telegram Deep Links https://core.telegram.org/api/links 8. RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) https://datatracker.ietf.org/doc/html/rfc8605

1 0

Proposal to Allow UTF-8 in “descr:” and “remarks” Attributes
by Edward Shryane 19 Nov '25

19 Nov '25

Dear colleagues, As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes. Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback. Regards Ed Shryane RIPE NCC Problem Definition ------------------ It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability. Solution Definition ------------------- In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy. We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported. Background ---------- Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes. "Proposal to allow UTF8 (April 2015)" https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HN… In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-ri… At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-U… https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… Impact Analysis --------------- Backwards Compatibility UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters. Personal Data Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope. Interoperability If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used. Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters). Guidelines for the Implementation of Internationalized Domain Names https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en Transliteration Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is). Impact on RIPE Database Services -------------------------------- Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. * Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done. NRTMv3 (Port 4444) * The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character. NRTMv4 * No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files. Whois REST API * No impact. The Whois REST API already supports UTF-8. RDAP * No impact. The RDAP protocol already supports UTF-8. Web Application * UTF-8 encoding is already supported on the query page. * The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes. Mailupdates * No impact. UTF-8 encoding is supported. Syncupdates * No impact. UTF-8 encoding is supported. Daily Database Dump and Split Files * The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. * We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions. New LIR Application * No impact. Registry Team * No comments or conerns as changes are limited to descr and remarks attributes.

16 21

Re: Improving Identification of RIPE NCC Members and Independent Resource Holders by Publishing Company Registration Numbers
by Andrejs Guba 17 Nov '25

17 Nov '25

Hello, Why should the RIPE Database be required to enable users to uniquely identify specific legal entities? The purpose of the RIPE Database, as defined in long-standing RIPE policies, is operational coordination, facilitating contact between network operators, and supporting incident response — not acting as a corporate registry or providing legally unambiguous identification of companies. 1. The proposal expands the RIPE Database beyond its intended purpose The RIPE Database was never designed to be: a business registry a KYC system a tool for legal verification of corporate identity Adding national registration numbers pushes the database into an area that was explicitly avoided for decades and introduces duties and expectations that RIPE NCC should not carry. 2. Security and operational risks for resource holders A verified company registration number is a powerful OSINT key that enables: precise mapping between IP resources and corporate structures targeted attacks against specific businesses easier identification of operators in sensitive jurisdictions expanded attack surface for ransomware, DDoS extortion, and other threats Many operators understandably prefer not to expose more legal identifiers than strictly necessary. 3. The proposed benefit is marginal compared to the risks The argument about identical organisation names, transliteration issues, or address discrepancies describes edge cases, while the risks of publishing registration numbers are systemic and permanent. Existing attributes already allow for operational identification: org-name country address abuse-c / role-c LIR identifier verified contact details If further clarification is needed, users can directly contact the LIR or the RIPE NCC. 4. Risk of harming organisations in politically sensitive environments In some countries, linking IP resources to a precise legal entity through a government-issued ID number can expose businesses to: political pressure regulatory targeting unlawful interference censorship attempts The RIPE Database should remain a tool for technical coordination, not a legally authoritative directory of corporate identities. I therefore believe this proposal requires much deeper consideration of its broader implications, and in its current form I do not support the introduction of a mandatory reg-nr: attribute. Andrejs Guba Marco Schmidt wrote: > 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

1 0

Re: Recent changes to the Database Terms and Conditions
by Maria Stafyla 17 Nov '25

17 Nov '25

Hi Denis, Thanks for your message and apologies for the delayed response. The recent updates to the Terms and Conditions were introduced to facilitate the implementation of the new Digital Operational Resilience Act (DORA) by those members that fall within the scope of this Act. Such members include insurance companies, financial institutions, etc. By introducing the points you mentioned, we aim to facilitate, as much as possible, our members’ ability to meet their obligations. By setting out these general provisions in the clauses, we wanted to make clear, among others what possibilities exist, for example, in terms of the audits, security checks, and incident reporting, and to clearly state in writing the options our members have in these areas in relation to the use of the RIPE Database. Regarding your questions about clauses 5.6, 5.7, who “the Registrant” and “the Maintainer” refer to, whether they can report any identified incidents or incidents relating to their resources, what types of incidents are meant and whether Users can also report incidents, please see below: For the phrasing, much of the text follows standard legal language (when we use “the” before “Registrant” or “Maintainer” this means they must be read as the terms defined in Article 1 of the T&Cs). As the amendments were part of our efforts to facilitate members that fall under the scope of DORA, we only indicated the incident reporting ability with regards to Registrants and Maintainers. They may report any incident they identify when using the RIPE Database. This does not restrict any user to also report outages or incidents to our Technical Emergency Hotline and security issues to our security team, following our RIPE NCC Technical Emergency Hotline <https://www.ripe.net/about-us/support/contact/technical-emergency-hotline/> process. In relation to your questions about 5.9 and audit reports, the scope of a security check or audit depends on the matter at hand and might differ on a case-to-case basis. An available report of such a check or audit may be provided to a Registrant or Maintainer subject to a non-disclosure agreement. Please refer above on how to read the terms “Registrant” or “Maintainer”. Although the RIPE Database is publicly accessible, certain information within it is not. Therefore, information about protection, integrity and confidentiality of the data remains relevant for the Database in this context. Regarding your point about 2023-04 ‘Add AGGREGATED -BY-LIR status for IPv4 PA assignments’ to our understanding, this proposal did not make IPv4 assignments optional but introduced the option to group assignments in a single registration when the assignments share the same purpose and contact details. Even for such grouped assignments, authorised parties will still be able to find the contact details of their responsible party and contact them. Lastly, thank you for pointing out the missing text in article 2.6, we’ve corrected the error on the website. We have also separated the two definitions of RPSL and Internet Number Registry that Piotr noticed. Kind regards, Maria Stafyla Legal Counsel Specialist RIPE NCC > On Wed, Nov 12, 2025 at 11:04:00PM +0100, Piotr Strzyzewski wrote: > > Dear Denis, All, > > "2.6. A Maintainer may only Update the RIPE Database with these types of > data:" > This line ends with a ':'. That suggests there should be a list following > it. There is no list. If you change ':' to '.' then the sentence makes no > sense. > > > The list comes right after that sentence. From what I can see, it's just > missing bullet points. I'll pass this information on to the relevant > team. > > Now let's look at "Article 1 - Definitions" > "Internet number resources - globally unique address space (IPv4 and IPv6) > and Autonomous System Numbers (ASNs) issued by any Internet Number > Registry." > Note it says 'any' Internet Number Registry. An LIR is a Local 'Internet > (Number) Registry'. So 'Internet number resources' covers address space > issued by an LIR. These are assignments. > > > For some unknown reason, the definition of Internet Number Registry > (INR) has been linked to and placed at the end of the RPSL definition. > That definition uses the word "allocates". I'll pass this information on > to the relevant team. > > > Let me report back to you that, thanks to Marita's prompt help, these > two formatting issues have already been fixed. I hope that helps. > > Best, > Piotr > > -- > Piotr Strzyżewski > > >

1 0

New draft NWI process
by David Tatlisu 14 Nov '25

14 Nov '25

Hello Everybody, You are welcome to look over a draft of a new definition of the Numbered Work Item process. This new version keeps the existing process largely the same with some procedural tweaks here and there and also improves the readability of the text. Let us know what you think about this proposed change, good or bad. We'd like to make it official in about three weeks. NEW DRAFT Text: ––––– RIPE Database Working Group Numbered Work Items In order to facilitate discussion about issues and solutions, as well as report on the progress made with solution implementation, the RIPE Database Working Group employs a process using Numbered Work Items (NWIs). Please note that this does not replace the Policy Development Process. Instead it is used for smaller work items and helps to facilitate the communication between the DB WG and the RIPE NCC. Kickstart: Anyone can contact the RIPE DB WG co-chairs and present a proposal or a problem statement. Alternatively this can also be sent to the WG mailing list directly. If there is interest in this work item, the Database WG co-chairs will ask the RIPE NCC to assign a number to this work item and include it on the list of numbered work items (NWIs). Problem definition: After an NWI is created, the proposal or problem statement will be discussed in the WG. This can mean further specifying the problem statement and including example cases of the problem to clarify the scope. After two to three weeks the WG co-chairs will determine of there is a consensus and will either post a clearly defined problem statement to the list, or if there is no agreement on a problem statement, the NWI will be closed. Solution definition: Anyone, including RIPE NCC staff, can propose solutions to a work item's problem statement. The RIPE NCC will also provide an implementation analysis that can include feasibility, expected workload, proposed solutions, impact on other work items etc. In this phase, the RIPE NCC together with the RIPE DB WG co-chairs will also determine if the NWI might have an impact on an existing policy or if the NWI might in fact lead to a change in policy or a new policy. In this case, the WG co-chairs are advised to use the more formal Policy Development Process (PDP) instead of the NWI process. Implementation: Once the WG agrees on the proposed solution, the RIPE NCC can start implementing it, keeping the WG up to date about the timeframe, milestones, documentation etc. The RIPE NCC will also update the entry of the NWI on the table of NWIs accordingly. Finished: The project ends when the change has been deployed in the production environment. Cancelled: The project can also end when the working group decides to cancel it. The RIPE NCC will update the list of NWIs on a regular basis to reflect the status of each NWI. ––––– EXISTING Text for your convenience ––––– In order to facilitate an ordered discussion about issues and solutions, as well as report on the progress made with solution implementation, the RIPE Database Working Group employs the following process using Numbered Work Items (NWIs): Kickstart: To kickstart the process, any db-wg participant can email the chairs with a snippet of text (a rough problem statement) and formally ask the chairs to make it a work item. The chairs can then say “yes”, and assign it a number, or “no”. If a number is assigned, the work item will be routed through the following three phases: Phase 1: Problem Definition In this phase we will work as a group on formulating an exact problem definition: text goes back and forth in the working group, example cases of the problem are provided. In a timeframe of two to three weeks the chairs declare consensus on the problem statement of the NWI. Phase 1 output: A clearly defined problem statement, or a conclusion if we cannot agree upon a problem statement definition. If the latter is true, the NWI cannot proceed to Phase 2. Phase 2: Solution Definition Solution finding: People can propose solutions to a work item's problem statement. Solutions can come from RIPE NCC staff or from any working group member. The RIPE NCC may offer an implementation analysis on proposed solutions or aspects of solutions. For the NWI to move to Phase 3, the RIPE NCC has to provide the working group with a summary of their understanding of the solution, and the chairs declare consensus on the group's acceptance of this summary. Phase 3: Development and Deployment Phase The RIPE NCC writes the code, sets timelines and milestones and documents the transitions/migration plan if applicable. Finish: The project ends when the change has been deployed in the production environment. Cancelled: The project can also end when the working group decides to cancel it. Every month the RIPE NCC will update this page with an overview of all open NWIs, a brief summary of each, who is taking action and what that action is. ––––– I express my gratitude to all those who worked on this draft, and everybody who took the time to offer their feedback. Kind regards, Peter and David

2 3

Recent changes to the Database Terms and Conditions
by Karolina Bochenek 13 Nov '25

13 Nov '25

Dear all, At its 188th RIPE NCC meeting on 4-5 September 2025, the RIPE NCC Executive Board approved amendments to the RIPE Database Terms and Conditions. These changes are in response to the EU regulation Digital Operational Resilience Act (DORA) which came into effect in January 2025. While the requirements apply to financial institutions, the RIPE NCC aims to facilitate the implementation of this regulation for those entities that are RIPE NCC members to a reasonable extent. The following changes include: Adding details of how we manage planned maintenance and how incidents can be reported. We also added information about security measures and audits (articles 5.5-5.9) Adding subcontractor, service level and data protection information (articles 8.4-8.6) The updated RIPE Database Terms and Conditions are available at: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms You can find more information about DORA and other relevant regulations in the RIPE NCC Trust Portal: https://trust.ripe.net/legal-compliance/ The RIPE NCC Executive Board Meeting minutes are available at: https://www.ripe.net/about-us/executive-board/minutes/2025/188th-executive-… The amendment will come into effect on 13/11/2025. Kind regards, Karolina Bochenek RIPE NCC

3 3

Archiving the "Action List"
by Peter Hessler 21 Oct '25

21 Oct '25

As seen on the website, the Database Working Group has an Action List, instead of an Action Movie. https://www.ripe.net/community/wg/active-wg/db/action-list/ From a basic perusal of them, this seems to be a basic tracking system of TODOs and Proposals. Notice it says "last updated 7 May 2009". I propose we simply archive this list. If anything is still relevant, please bring it up as if it were new. Peter Hessler, On behalf of the DB WG Co-Chairs

4 5

RIPE90 Database Working Group Minutes
by David Tatlisu 15 Oct '25

15 Oct '25

Hi Everyone, The draft minutes from our session at RIPE90 have 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 Hans from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. David Tatlisu, On behalf of the DB WG Co-Chairs

2 1

Fwd: Re: [ripe-list] Re: beIN && RIPE NCC && Notorious Markets
by Nick Hilliard 09 Oct '25

09 Oct '25

Maybe add some comments in whois output to highlight which fields in which objects are authoritative? Or if there were a page put up on https://trust.ripe.net/ which explains this in more detail? There's a lot of head-boggle going on here, even for people who are familiar with whois output. Nick -------- Forwarded Message -------- Subject: Re: [ripe-list] Re: beIN && RIPE NCC && Notorious Markets Date: Thu, 9 Oct 2025 08:11:57 +0200 From: Daniel Karrenberg <dfk(a)karrenberg.net> To: Nick Hilliard <nick(a)foobar.org> CC: Andrew Campling <andrew.campling(a)419.consulting>, ripe-list(a)ripe.net Maybe it is finally time to make it *really obvious* even to the most ignorant which RIPE DB objects are authoritative info and which are not? --- Sent from a handheld device. > On 8. Oct 2025, at 19:49, Nick Hilliard <nick(a)foobar.org> wrote: > > Andrew Campling wrote on 06/10/2025 15:27: >> Irrespective of any view regarding rights holders, the lack of effective KYC procedures is also a problem in combating both malicious and illegal content. For example, you may be surprised that the Internet Watch Foundation finds a large percentage of illegal CSAM images hosted within Europe (here <https://www.iwf.org.uk/annual-data-insights-report-2024/data-and-insights/g…>) – for transparency, I’m an IWF trustee. I am not a lawyer but I understand that KYC is a requirement under the EU’s NIS2 Directive. >> In my view, extending effective KYC processes across the ecosystem will add friction, making the life of malicious actors more difficult. > > the ripe ncc already implements kyc for its members and direct assignment resource holders. You can't get a PI assignment without validating your identity, and there are comparable processes for businesses who wish to become LIRs. These are hard-enforced. If you don't comply, your application will be rejected. > > In addition to this, all LIRs are subject to a periodic Assisted Registry Check. > > The BEIN letter seems to confuse data about RIPE members / direct assignees with general end users of ISPs. > > The confusion may be happening because the RIPE database is a mixture of several different categories of data. Some of the data is authoritative (i.e. RIPE LIR and Direct Assignments) and some is non-authoritative (i.e. LIR assignments). A good deal of the non authoritative data is of very poor quality, but the authoritative data is all subject to RIPE KYC processes and regularly audited. Mixing these two data sets up does not benefit anyone. > > It's the job of the ISP to ensure that they have KYC processes with their end users. > > Nick > ----- > To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-list.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

2 2

Clarification of Database documentation
by denis walker 06 Oct '25

06 Oct '25

Colleagues Some documentation issues were raised during a discussion of contact methods. They have nothing really to do with the issue of contacts so I have started a new thread on the documentation. It is not the most urgent issue regarding the RIPE Database so you may not care about any of this. But documentation should be correct or it is a waste of time having it. If no one comments, maybe the chairs can pass judgement. Three issues are raised here: -Attribute properties -Description of AGGREGATED-BY-LIR -Missing attribute Attribute properties For years we only described attributes as mandatory, optional or generated. But there are some attributes that do not exactly fit any of these categories. Mandatory means that every instance of this object type must have this attribute present. Optional means it is entirely your choice if you include it or not. Some attributes sit in between these two options. They don't need to be in every instance of the objects, but sometimes it is not your choice to leave it out. There are business rules built into the software that determine when certain attributes must be present or if you can ignore it. Examples include abuse-c and org. In most instances of an INETNUM object the org attribute is optional. But if it is an allocation, then it must be included. So it is not truly mandatory or optional. When I re-wrote the database documentation in 2014 I tried to cover this middle ground giving these attributes the property of being 'required' [1]. But as Ed just pointed out, the word 'required' suggests it is 'mandatory'. Certainly for a non native English speaker it is easy to confuse these meanings. So it is not the best word to use. The only word I can think of that might reflect the true meaning of these attributes is 'variable'. Sometimes it must be there, sometimes you can choose. There will be another document or policy that explains the business rules that determine how it is used. So unless someone has a better suggestion for naming this attribute property, I recommend that we adopt 'variable' in the documentation and in the templates returned by a whois query with -t and -v. Description of AGGREGATED-BY-LIR This is described in both the database documentation [2] and in the address policy [3]. Neither is an accurate and clear description and they are both different. In the address policy it says "The purpose and the contact details must be consistent throughout the whole assignment.". This confuses the terms 'aggregation' and 'assignments'. An aggregation is a collection of 'multiple' assignments. So you must either refer to the aggregation or the collection of assignments.You cannot refer to a single assignment. This is not just splitting hairs. For a non native English speaker new to the database, they are reading this to try to work out what this means. The current wording suggests the aggregation represents a single block of assigned address space, rather than a collection of multiple address blocks, possibly of different sizes. The purpose of an assignment is not publicly defined or documented anywhere. What is the purpose of a block of assigned address space? Can it be 'used by an End User's public network' or 'used by the LIR for their own infrastructure'? But then these are two different purposes. So by definition you should not be able to aggregate a mix of End User's address space with an LIR's own infrastructure. Is that the case? How does anyone outside of the LIR know? Should the purpose be documented in a remarks attribute? Should an aggregation have a "purpose:" attribute? It seems like there was such a rush to make individual assignments optional, the actual details of the aggregation were not very well thought through. What does "the contact details must be consistent" mean? All the assignments have a tech-c? All the tech-c references are to a ROLE object or a PERSON object? They all include an email address? They all refer to the same ROLE object? All the different ROLE objects reference the same email address? It is not good enough to say "but we all know what it means". A new LIR, new to the policy documents, new to the database may not know what this means. That is why they are reading it. There is no explicit mention that the multiple assignments can all be of different sizes. Unless the "assignment-size:" attribute is included. Is it sufficient for all these details to be explained in the RIPE Database documentation, that is only advisory? Possibly leaving the policy statement so vague that it is easy to misunderstand or misinterpret. Either way, all of these points need to be explained, somewhere. I haven't even touched on rules that should have so obviously been documented somewhere. For example, if aggregations are created retrospectively, the boundary between aggregations within a single allocation must match the boundaries of the encompassed assignments. If the assignments are deleted before creating the aggregations then the software cannot enforce this and there is no way for anyone to verify this was done. The whole concept of aggregation was badly specified. But that is another story... Missing attribute There is no mention in the documentation of the INETNUM or INET6NUM attribute 'prefixlen'. References [1] https://docs.db.ripe.net/RIPE-Database-Structure/Attribute-Properties [2] https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects#… [3[ https://www.ripe.net/publications/docs/ripe-826/#70-types-of-address-space cheers denis

4 6

RIPE Database Release 1.119
by Edward Shryane 01 Oct '25

01 Oct '25

Dear colleagues, RIPE Database release 1.119 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Wednesday 1st October. This release contains the following main changes : * Support multiple maintainers in scope (#1866) * Fix indentation when Serialising JSON to Avoid Indentation Bug (#1855) * Always add Warning When using Password Authentication (#1859) * Return Not implemented in case of e164 ENUM domain (#1846) * Allow empty From: address in SMTP request (#1841) * title should be type in RDAP relations (#1842) * Retry on Failure during GRS (mirror) import download (#1837) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/505c5f7...1c439eb The release notes are on the website: https://docs.db.ripe.net/Release-Notes#ripe-database-release-1-119 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 15th September. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 1

NWI proposal: adjusting contact method requirements and adding new methods
by Leo Vegoda 30 Sep '25

30 Sep '25

Hi, A while back Cynthia, Dmitry and I looked at the possibility of adding new contact methods. Dmitry presented this at RIPE 88: https://ripe88.ripe.net/archives/video/1347/ I've tried to put this into a more complete NWI and offer it for discussion. The TLDR is: 1) Align the requirement levels for contact methods 2) Let people use new contact methods, like Signal We hope that by offering the methods people want to use, the contact data in the RIPE Database can be as useful as is possible. Kind regards, Leo ## Problem statement The requirement level for contact methods for person and role objects are inconsistent. This is both confusing and inconvenient. This is a proposal to add flexibility to the contact methods offered at the database level. It is not a proposal to change policy requirements for contact methods. This proposal is limited to admin-c and tech-c contact types. Our world offers more contact methods than were available when the currently supported methods were chosen for the RIPE Database. User acceptance of these methods differ by country and generation. Whether this proposal is accepted or not, it is good to review the rationale for these rules and have an updated rationale published. 1. Person and role objects have four contact methods. A postal address is mandatory for both. A phone is mandatory for person objects but not role objects. E-mail is mandatory for role but not person objects. 2. Postal mail is less useful than it was 20 years ago. Some countries are reducing the frequency of postal deliveries. And geographically distributed teams find postal mail less useful. 3. The telephone is becoming less useful, too. Call volumes are dropping and popular psychology publications explain why calls are less likely to be answered: - https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-c… - https://www.bbc.com/news/articles/ckg8jllq283o - https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-… ## Proposal We should provide contacts with more flexibility. We should also add new options that were not available when the RIPE Database's contact methods were last reviewed. The three elements below follow on from NWI-15, which is based on the RIPE Database Requirements Task Force recommendations for what should be published about resource holders. The registry needs to retain the full set of required data. The DBTF report did not mention contacts methods for the resources. 1. Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all contact methods optional for the public RIPE Database as long as one is chosen. There is no point publishing a contact method that will not be used. That would just waste the time of people trying to make contact. 2. Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. 3. Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. Making these changes will require updates to the RPSL and RDAP publication methods. The RIPE NCC should manage the specifics of the design and implementation. ## Recommendation for Impact Assessment The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement. The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.

10 24

RIPE 91 draft agenda & call for presentations
by David Tatlisu 20 Sep '25

20 Sep '25

Hi Everybody, RIPE 91 in Bucharest, Romania, will start in about four weeks. Our session will start at 9:00 in the side room on Thursday, 23 October. We still have a fairly open agenda and would love to have you present. If you are interested in presenting, please contact the working group chairs at db-wg-chairs(a)ripe.net. 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 current draft agenda; please feel free to offer feedback as appropriate. Best regards, Peter and David DB-WG Chairs A. Introduction - 15 min Welcome Scribe Agenda B. NWI Review - 15 mins, WG Chairs C. Operational Update - 30 mins. Edward Shryane, RIPE NCC D. [ YOUR PRESENTATION COULD BE HERE ] - 10-30 minutes, WG Chairs Z. AOB (open discussion)

1 0

FMP remark
by Miguel Mosquera 19 Aug '25

19 Aug '25

Dear colleagues, After we removed inactive MD5 passwords from maintainers, most of these objects have no auth attributes. This is why tomorrow we plan to add the remark "Use Forgot Maintainer Password to recover access to this object, see https://apps.db.ripe.net/db-web-ui/fmp" to maintainers with no authentication attributes (approximately 9k). Please let us know if anyone does not agree with this update. Best Regards Miguel RIPE NCC

1 1

RIPE Database OAuth 2.0 release
by Mahesh Aggarwal 13 Aug '25

13 Aug '25

Dear colleagues, We are pleased to inform that starting this week, RIPE NCC members can use OAuth 2.0 to authenticate applications that interact with the RIPE Database. Please refer to this article for further information : https://labs.ripe.net/author/adonis_stergiopoulos/oauth-20-available-for-th… Please let us know if you have any questions regarding this. Regards Mahesh Aggarwal RIPE NCC

1 0

RDAP for e164.arpa
by Cynthia Revström 07 Aug '25

07 Aug '25

Hi Ed and DB-WG, I just noticed that the RIPE DB RDAP interface returns a 500 error when querying for ENUM domains[1] (except for specifically the top level e164.arpa domain, which results in a 400 error). This seems to be due to an assumption that all domains in the RIPE DB are reverse DNS domains for IP addresses, which is not the case as ENUM domains are also in there. Is this an intentional decision or was this just an oversight? If it was just an oversight, consider this a bug report. :) If it was an intentional decision then I would be interested in hearing what the reasoning was. [1]: Example: https://rdap.db.ripe.net/domain/6.4.e164.arpa -Cynthia

5 7

Whois Release 1.118.1
by Edward Shryane 04 Aug '25

04 Aug '25

Dear colleagues, RIPE Database release 1.118.1 has been released to the PRODUCTION environment. Unfortunately a regression was found in the 1.118 release that was causing some route(6) object queries and updates via the REST API to fail: https://github.com/RIPE-NCC/whois/pull/1843 We have now deployed a fix for this regression, with no other changes from the 1.118 release. We did not wait for the usual 2 week testing period in the RC environment because this was an unintentional change and was impacting some of our users. The exact changes are available in the source repository: https://github.com/RIPE-NCC/whois/compare/505c5f7a...whois_1118_1_release?e… The release notes are on the website: https://docs.db.ripe.net/Release-Notes#ripe-database-release-1-118-1 We apologise for the inconvenience and thanks to the users for reporting this issue. Regards Ed Shryane RIPE NCC

1 0

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