Summary

  • ARIN added a customer-facing ROA Change Log in September 2025. It shows 365 days of changes with time, operation, source, origin AS, prefix, max length and the account name recorded as changing the ROA.
  • In May 2026, a user asked ARIN for equivalent action history on Internet Routing Registry objects. ARIN agreed it would help, placed it on its routing-security roadmap and closed the suggestion without a delivery date. A current IRR object, an NRTM feed and a ROA log each leave a different part of the change story visible.

The route filter breaks on Tuesday. The current IRR route object is easy enough to fetch. The hard question is who made it say this. A snapshot describes the object as it stands; it does not identify the account, interface and time behind a disputed edit. ARIN has already built that kind of customer-facing receipt for ROAs. The corresponding IRR request received a polite answer and a closed ticket.

The suggestion was filed on 11 May 2026 by Randal Kohutek. He asked ARIN to add IRR object action logging equivalent to the ROA log, pointing to date, time, source, user and action as useful fields. He said the IRR object system did not appear to expose comparable history. His reason was operational: a changed IRR object can affect routing and network visibility, and a timestamped record would help troubleshoot the change and any break in ROA/IRR integration. He gave no incident count. This was a request for a tool an operator could actually use during a disagreement, not a referendum on whether the IRR matters.

ARIN answered on 19 May. It agreed that customers would benefit, put the feature on its routing-security roadmap, referred it to internal prioritization and implementation planning, and marked suggestion 2026.9 Closed. The page gives no delivery date or proposed log schema. The ticket's status settles the suggestion-process paperwork; it leaves the customer-facing history to be built.

The comparison is unusually concrete. ARIN launched the ROA Change Log on 29 September 2025. Its current ROA guide describes a 365-day view of new and modified origin AS/prefix pairs. The table names a timestamp, an Added or Removed operation, a Web User, API User or ARIN System source, the origin AS, prefix, max length, and the first and last name from the changing account's profile. After 100 entries the UI paginates. A customer may request a full CSV through a ticket; ARIN says it reviews that request within two business days and makes the file available for download for 90 days. Those are two clocks: one year of visible change history and a three-month window to retrieve an approved export.

The IRR guide describes a different machine. Operators submit RPSL objects through ARIN Online or its REST API. ARIN publishes the resulting routing-policy data for other networks and registries to retrieve; NRTM, compressed database files and Whois queries are available. The guide's feature table says neither the web nor REST path sends update-email notifications. It also divides objects by creation method: simple objects can be edited through the web or XML REST path, while advanced RPSL REST objects can be viewed and deleted in the web interface but edited through RPSL REST. These are real access and distribution rules. They do not tell a customer which account changed an object last week.

There is a second reason the ROA log cannot be treated as the IRR log. ARIN's IRR Auto-Manager can generate route objects from ROA origin AS/prefix pairs. The user can decline that creation. A matching unmanaged IRR object can be left alone or replaced during ROA creation. Later, an IRR object can be deleted independently of its ROA. When the ROA is deleted, ARIN offers a choice to delete an associated IRR route object or leave it behind as unmanaged. The two records can begin together and then take different paths. A ROA-side receipt can establish a ROA action; it cannot, by itself, reconstruct the independent IRR path.

That distinction matters to a network engineer repairing a filter. The live RPSL object says what the registry currently publishes. A retrieved NRTM update can show that data moved through a feed. The customer-facing action log the requester wants would connect the object key and operation to a time, an interface and an actor. An operator could then ask the right person why the route object changed, compare it with the ROA and decide whether to restore an earlier intended policy. Without that receipt, the investigation begins by assembling external snapshots, local API logs and human memory.

Each can help; none substitutes for ARIN's own account-level record of the action.

The public evidence has a narrow edge. Kohutek described the missing IRR history as what he could see in the customer interface. ARIN acknowledged the benefit of adding action logging. Neither document inventories ARIN's internal event logs, and no public incident trace measures how often this gap delays a repair. The missing fact that would change this judgment is a shipped customer-facing IRR log naming the object, operation, timestamp, source and actor, with a published retention rule.

ARIN already chose those fields for a neighboring routing-security product. For the IRR it chose a roadmap and a closed public suggestion. A registry can publish the latest object quickly and still leave the author of its last edit behind a curtain. When an operator asks who pulled the curtain, “future development” is a poor incident timestamp.

ARIN suggestion 2026.9 and reply · ARIN IRR guide · ROA Change Log and Auto-Manager · September 2025 release