Summary

  • RIPE NCC’s 0.006% Whois figure describes query cases returning NONAUTH objects; the 20% figure describes NRTM requests asking for NONAUTH updates. They are not comparable shares of users or traffic.
  • The next cleanup proposal is still at “Starting.” A useful decision record should identify each object rule, affected population, notice, migration path and post-change test before any removal.

A query and a mirror ask different questions

A user asks Whois about a name, address range or network number. A mirror asks for changes to a database source. The first is a lookup; the second keeps a local copy current. A record can rarely appear in one kind of answer and still be requested regularly through a separate update stream. Those are not contradictory observations. They are observations from different paths.

That distinction is obscured by the two figures now used in discussion of RIPE-NONAUTH. In a 17 July 2025 Database Working Group message, RIPE NCC staff said objects from the non-authoritative source were returned in about 0.006% of Whois query cases. In the same message, staff said approximately 20% of NRTM requests queried for updates to NONAUTH. The message provides neither the measurement interval nor the raw denominators or number of distinct mirror clients. The percentages cannot be divided, subtracted or treated as a usage-versus-non-usage score.

The small Whois figure does answer something: a NONAUTH object was returned in relatively few query cases in the measured data. It does not say how many separate networks rely on those cases, whether those queries were operationally important, or what a network receives from a local mirror instead. Nor does it describe users who query only authoritative sources. It is evidence about one interface’s output, not a census of the source’s users.

The NRTM figure answers a different question. It says a substantial share of requests in that stream asked for NONAUTH updates. It does not state whether those requests came from many clients or a few, whether every request resulted in a successful transfer, or whether each client used the resulting records in production. One automation could generate repeated requests. Conversely, a client could download a daily file rather than use the update stream. The published percentage is not a count of operators, customers, traffic volume or dependency.

The reason to clean is real; so is the evidence gap

RIPE-NONAUTH was separated from authoritative data in 2018 to hold out-of-region objects. RIPE NCC has a legitimate data-quality concern: its July 2025 message said the source contains non-authoritative information whose origin or continued validity may be unknown, and a client can mistake it for a better-supported record if it ignores the source attribute. The 2025 operational update also reported fewer than 100 changes per year and a gradual reduction in object count. The figures support asking whether each object still has a purpose. They do not, by themselves, prove that every remaining object is redundant.

The controls already considered are more specific than a blanket purge. RIPE NCC’s 2025 discussion included objects matching a valid ROA or a route object in another RIR database. In RIPE 91, the team said it had sent just over 2,000 notices about potentially affected objects. Thirty-three replies arrived: 23 asked that their objects not be deleted, while staff discussed use with ten maintainers and helped them create alternatives in authoritative databases. The answers show that the transition can require operator work.

They are not a representative audit: maintainers who replied may not resemble silent recipients, and the replies do not count every mirror consumer.

At RIPE 92, Job Snijders supported cleanup of route objects with a matching valid ROA or a corresponding route object elsewhere. AMS-IX said its route servers had stopped using NONAUTH years earlier without complaints or operational impact. That is useful operational testimony, but it describes one operator’s path, not every implementation or every historical object. RIPE NCC staff asked other operators still depending on NONAUTH to come forward; the minutes record discussion, not a vote to retire the source.

“Starting” is not a deletion schedule

RIPE NCC’s Q4 2026 plan, updated on 17 September, says it intends to propose further cleanups after discussion on the mailing list and at RIPE 92. The item’s status is “Starting.” It does not identify a final object set, matching logic, deadline, grace period, exception list or change to NRTM service. A proposal to reduce records is not the same as a decision to shut down the database, and neither is reported as implemented.

The decision record should therefore make the measurement boundary visible. For each proposed rule, publish the snapshot date, object classes, match definition and count. Report Whois query cases and NRTM update requests separately, with their respective observation windows and base counts. If the data permit it, add a privacy-safe count of distinct active consumers; do not infer that count from requests. Record how many maintainers were reached, how many replied, what migrations were completed and which cases need another route.

Then name the grace period and the test that would pause a cleanup if the resulting source changes behaved differently than expected.

That is not a demand for another permanent telemetry programme. It is a versioned receipt for a consequential change to the data path. If the rule only removes exact duplicates, say so. If it extends to all objects covered by a ROA or to the NRTM service itself, identify that as a different decision. A summary that lets readers distinguish “few interactive returns,” “many update requests,” “maintainers contacted” and “clients migrated” would be more informative than calling all four “usage.”

Sources