Summary

  • ARIN's IRR Auto-Manager can create or link an IRR route object while a ROA is created, and the two records can later be separated through explicit delete-or-retain choices.
  • ACSP 2026.9 asks for IRR action logging comparable to the existing ROA history. That would improve visibility, but two separate logs still need a common operation ID and pre/post state if an operator is to reconstruct the operation.
  • A bounded cross-record receipt can preserve user choice and the different meanings of ROAs and IRR objects while making automation, divergence and correction auditable.

One action in ARIN Online can now produce two records. A resource holder creates a Route Origin Authorization and, if IRR Auto-Manager is enabled and accepted for that action, ARIN can also create a matching IRR route or route6 object. The records are linked. Work that once required separate systems becomes one guided operation.

This is a sensible piece of infrastructure. It reduces duplicate entry. It can replace a matching unmanaged IRR object or leave that object alone. It can be switched off for an organization, and a user can decline the IRR object during an individual ROA creation. A Sync Up tool can bring existing ROAs and matching route objects together later. The design assists an operator without pretending that the registry owns the operator's routing policy.

The separation built into the feature is just as important as the link. An IRR object may be deleted independently without affecting the ROA. When a ROA is deleted, its linked IRR objects may also be deleted or may remain behind as unmanaged objects. A ROA containing several prefixes can generate one IRR object for each prefix. The operator is not trapped in a permanent one-record-to-one-record bond.

Nor are the two records interchangeable. A ROA is signed origin-authority data. It can include maxLength, which defines how specific an authorized announcement may be. An IRR route object is an RPSL declaration keyed by a prefix and origin AS. ARIN deliberately does not copy the ROA's maxLength into a family of more-specific IRR objects; the auto-managed object uses the prefix entry. That is a boundary worth preserving, not an inconsistency to be erased.

ARIN has therefore solved a useful coordination problem while retaining local choice. It has not yet described an equally complete public evidence object for the coordination itself.

What the ROA history already shows

ARIN's ROA documentation describes an Origin AS/Prefix Pair Change Log covering new and modified ROAs for an organization during the previous 365 days. Histories longer than 100 items are paginated. Each row carries a timestamp, an operation expressed as Added or Removed, a source—Web User, API User or ARIN System—an origin AS, a prefix, a maximum length and the identity shown in Changed By. A full CSV can be requested through a support ticket and, after ARIN's review and response, remains downloadable for 90 days.

This is not merely a list of current objects. It is an account of change. It distinguishes a human web action from an API action and from an ARIN System action. It joins the affected origin-AS/prefix pair to time and source. When a ROA is modified, the pair history can express what was removed and what was added.

The current documentation does not describe a comparable visible action history for IRR objects. That is not my inference alone. On 11 May 2026, Randal Kohutek submitted ARIN Consultation and Suggestion Process item 2026.9 asking ARIN to add IRR object action logging equal to ROA action logging. The suggestion carefully said that the IRR system “does not appear” to include such logging. It did not claim knowledge of ARIN's internal databases or security records.

Eight days later, ARIN agreed that the feature would benefit customers who need to track IRR object actions. It added the suggestion to its routing-security roadmap for future development, referred it to the internal prioritization and implementation-planning process, and closed the suggestion. That is a prompt and constructive response. It is not a release date, a promise of a particular schema or evidence that the feature has already shipped.

Equal logs would still leave a join to make

Suppose the roadmap work produces an IRR history with the same basic fields as the ROA history. An operator could inspect two timelines. Yet the hardest troubleshooting question would remain: which rows belong to the same intention?

A ROA creation may find an existing unmanaged IRR object. The user can replace it or leave it alone. A multi-prefix ROA may create several objects. A later IRR deletion can leave the ROA intact. A later ROA deletion can remove the linked objects or retain them in unmanaged state. Sync Up can create a missing object or link one that already exists. Two timestamps close to each other are not proof that the events share a cause; two timestamps far apart are not proof that the later state is an error.

This matters because the two systems can feed different operational decisions. RPKI validators use ROAs as signed inputs to origin validation. Networks and tooling may use IRR data to build or review routing-policy filters. Neither database proves what a router actually announced or accepted, but divergence between them can still send an engineer looking for an explanation. Was the difference a deliberate opt-out, an independent delete, a retained unmanaged object, an existing match, a partial failure or a correction? Separate histories make that explanation possible only by inference.

The missing object is not a larger public surveillance log. It is a bounded operation receipt available to the authorized organization, with a public schema and privacy-conscious disclosure.

A receipt for the operation, not a merger of the records

The receipt should begin with an opaque operation ID and time. It should name the initiating surface—ARIN Online, RPKI API, IRR API, Sync Up or ARIN System—and an actor class without unnecessarily exposing a person's name. It should record the authorized organization and the intent: create or modify a ROA, delete it, create or link an IRR object, replace an unmanaged object, delete the IRR object, retain it as unmanaged or resynchronize the pair.

It should then show pre-state and post-state. On the ROA side, that means the handle, origin AS, prefix and maxLength. On the IRR side, it means the route or route6 key, prefix, origin, managed status and link status. If one ROA maps to several prefixes, the receipt should show that cardinality. If an object already existed, it should say whether it was reused, replaced or left untouched.

Deletion needs its own explicit field. “Delete ROA and delete linked object” is a different operation from “delete ROA and retain object as unmanaged.” The final state should not have to be reconstructed from absence. A failed or partially completed operation should carry an outcome class. A correction should point to the receipt it supersedes rather than silently rewriting the historical explanation.

Not every field must be world-readable. Personal names, API credentials and another organization's history do not belong in a public feed. ARIN can retain security detail internally while giving the authorized resource holder a structured receipt and publishing the schema, retention window and export rules. Auditability here is a property of a bounded relationship, not a demand that the registry expose everyone to everyone.

ARIN's current design contains the right institutional instinct: automate a narrow coordination task, preserve user choice and leave the underlying records distinct. ACSP 2026.9 identifies the next gap. The best implementation would go one step beyond equal columns. It would let an operator prove that two changes were part of one operation—or prove that they were not—without asking timestamps to carry a meaning they do not possess.

Sources