September 2025 - db-wg - mailman.ripe.net

RIPE90 proposal to deprecate the RIPE NONAUTH Database
by Edward Shryane 10 Oct '25

10 Oct '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 22

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