Summary

  • ARIN's 28 July 2026 maintenance notice separated reader access from change propagation: Whois, Whois-RWS, RDAP, IRR and the RPKI repository would remain operational, but no updates would be published during the window.
  • ARIN Online, RESTful Provisioning, RPKI Up/Down and RPKI Repository Publication would be unavailable; REST calls could be queued and might need resubmission. That is a documented retry boundary, not evidence that a call was lost.
  • Appendix C of ARIN's 2025 Annual Report reports six availability results—99.9, 99.9, 99.9, 100, 100 and 99.9 percent—but the frozen table has no field for freshness, data age, last publication or authoritative update.
  • A public two-clock service card could make query availability, write acceptance, authoritative publication and reconciliation legible together without exposing internal architecture or declaring a harmless maintenance state to be an incident.

The word operational does useful work, but it cannot do every kind of work.

Consider the question an operator asks after a registry lookup succeeds: did the service answer? That question has a clean answer. The response arrived. It may be enough for a historical lookup, a cached validation decision, or a check that does not depend on a change made moments ago.

But another question follows: how recently did the authoritative state behind that response move? It is not a disguised uptime question. A system may be entirely reachable while a controlled publication path is paused. The answer may still be correct; it may simply describe the last successfully published state rather than the state a writer is trying to create now.

ARIN put this distinction into public view before its scheduled maintenance on 28 July 2026. Its notice said ARIN Online, RESTful Provisioning, RPKI Up/Down and RPKI Repository Publication would be unavailable. In the same notice, ARIN said that Whois, Whois-RWS, RDAP, IRR and the RPKI repository would remain operational, although no updates would be published during the maintenance. RESTful calls would be queued, with the caution that they might need to be resubmitted afterwards.

That is not an outage report. It says neither that a reader saw stale data nor that a caller lost work. It is more precise, and more useful, than either claim. ARIN identified a planned period in which a reader path could work while a publication path could not advance. It also identified a third condition—queued work whose final state still needs to be checked—and a fourth one that operators usually need: completed reconciliation.

The strongest case for ARIN's design

Keeping reader services open during planned write maintenance is not a cosmetic choice. It can be a valuable degraded mode.

A Whois or RDAP query can remain useful without accepting a new registration action. An IRR reader can continue to serve the state already published. RPKI gives the distinction particular weight: relying-party software works from published signed objects and local cache, not from an operator's intention to publish an object. ARIN's hosted RPKI, Repository Publication Service, Trust Anchor Locator and terms document related but distinct roles in that path. A validator can retain verifiable material while a new authoritative publication is intentionally paused.

That is exactly why the public vocabulary should be more rather than less exact. “Operational” can correctly describe the reader. It should not silently become a claim that writes are being accepted, that the newest intended state is published, or that a post-maintenance queue has fully settled.

ARIN has other useful public building blocks. Its status page is componentized rather than a single monolithic light. Its maintenance notice gives advance warning. Its RPKI documentation distinguishes repository access and publication responsibilities. None of this is proof of an internal dashboard, a particular recovery target, or an undisclosed dependency map. It is evidence that public service states already have more texture than a single green label.

Six scores, and the missing second clock

Appendix C of ARIN's 2025 Annual Report reports six categories of service availability: ARIN Online, Whois/RDAP, Resource Public Key Infrastructure, RDAP Bootstrap, Internet Routing Registry and Registration Transaction Service. The frozen table gives 2025 results of 99.9, 99.9, 99.9, 100, 100 and 99.9 percent, with component figures beneath them.

Those figures should not be dismissed. Availability is a real dimension of service. A registry whose public readers disappear cannot comfort an operator by saying that its latest write was accepted. The annual report's table is valuable precisely because it tells the reader something measurable about whether the named services were available.

Its limitation is narrower than a denunciation. In the frozen Appendix C table, there is no column or label for freshness, data age, last published, or authoritative update. The observation applies to that page and those labels. It says nothing about what ARIN records internally, what another public surface may display, or what every component requires.

Still, the omitted dimension changes the meaning of a good availability result during a controlled publication pause. A green result can answer, “Could I reach it?” It cannot by itself answer, “How old is the authoritative state I reached?” The two answers may both be good. They are simply different answers.

Give every public component two clocks

The useful remedy is not a melodramatic dashboard or a demand to publish topology. It is a small public service card that keeps two clocks separate.

The first clock is the reader clock: component name, reader interface, and query availability. It tells a user whether a lookup, repository fetch or other public read can be attempted.

The second is the authoritative-state clock: write acceptance, normal publication cadence, last successful authoritative publication, and the maximum age that should be expected in the present state. Where maintenance changes the path, the card should also say whether a submission was rejected, accepted into a queue, awaiting replay, requires resubmission, or has been reconciled. A version and correction record would allow a reader to distinguish a later repair from an unexplained change.

This is not one universal freshness target. A routing validator, a registration transaction and a public directory query have different uses and different tolerances. Nor is it a demand to reveal private contact data, credentials, security procedures, supplier identities or internal topology. It is an account of what the public service currently promises at its boundary.

The distinction also disciplines language after maintenance. “All services operational” is a useful present-tense indicator on a status snapshot. “Queued call reconciled” is a different fact. “Last authoritative publication completed at this time” is different again. Combining them under one green word asks a status surface to carry a contract it never made.

The larger principle is modest. A registry should not be judged as failed because it preserves readers while it pauses writers. But a successful reader response should not force users to infer the publication clock. During planned maintenance, that inference is the whole operational question.

Sources

  1. ARIN scheduled maintenance notice, 14 July 2026
  2. ARIN 2025 Annual Report, Appendix C
  3. ARIN service-level reports
  4. ARIN Statuspage and summary endpoint
  5. ARIN hosted RPKI, RPS, TAL and RPKI terms