Summary

  • ARIN’s current IRR overview divides objects into simple and advanced classes. The creation or migration path determines whether an object is managed through ARIN Online, XML REST or RPSL REST.
  • A migrated IRR-email object may be viewed and deleted in ARIN Online but edited only through the RPSL REST path. Deleting and recreating it through Online converts a correction into a new object lineage.
  • Two current ARIN pages disagree about whether an Online-created object can be managed through RPSL REST. Without testing an authenticated object, the discrepancy is documentation evidence—not proof of production behavior.
  • A compact conversion receipt could preserve the pre-object hash, class, channel, action, post-object hash and replacement link without exposing API keys, employee identities or private topology.

The edit button that provenance removes

The most revealing row in ARIN’s Internet Routing Registry documentation is not a failure message. It is a permission combination: view, no edit, delete. ARIN says an object migrated from its former email-based IRR system can be seen in ARIN Online and removed there, but cannot be modified there. An authorized operator who wants to manage it through the web interface must delete it and create it again. ARIN IRR user guide

That sequence can look like an awkward interface workaround. It is more consequential than that. The old object belongs to the class ARIN calls advanced: it was created through RPSL REST or arrived through the IRR-email migration. A replacement made in ARIN Online belongs to the simple class. The public routing-policy attributes may be typed back identically, yet the registry’s account of how the object may be changed has moved from one channel class to another.

Nothing in the pages examined here shows that an operator lost an object, that a route changed, or that ARIN processed such a conversion incorrectly. No account or object was tested. The evidence is the control model that ARIN itself publishes. It makes creation history part of future authority.

That is not inherently a defect. A migration cannot honestly pretend that a legacy record was born in a newer form. Encoding-specific validation may make some edits safe in one path and ambiguous in another. ARIN says migrated objects passed the newer system’s stricter validation and are identified by a note in the interface. Retaining their provenance can be a careful choice. The editorial question is narrower: when the supported remedy destroys and recreates the object, where is the continuity between the two records made explicit?

One registry, two object classes, three management surfaces

ARIN’s current IRR overview distinguishes simple and advanced objects. It associates simple objects with creation in ARIN Online or through REST using XML. Its table gives those objects create, view, edit and delete permissions in both places, and no permission through the RPSL REST route. Advanced objects are created through REST using RPSL or migrated from IRR-email. The table gives them full create, view, edit and delete rights through RPSL REST; no XML REST rights; and only view and delete rights in ARIN Online. ARIN IRR overview

The labels can mislead if they are read as a ranking. “Advanced” does not mean that the routing claim is more accurate, more widely accepted or more current. “Simple” does not mean that the underlying policy is trivial. They are management classes. ARIN also says the difference does not change the format in which readers retrieve the data: query output is RPSL.

This distinction matters because a public object and a write path answer different questions. A route object can state that an ASN originates a prefix. A route6 object does the corresponding work for IPv6. An aut-num, as-set or route-set object can express other parts of routing policy. The visible RPSL tells a consumer what the registry record asserts. It does not tell the consumer whether the maintainer used a web form, XML or an RPSL payload to establish that assertion.

Nor does it prove what BGP is doing. RFC 2622 defines the Routing Policy Specification Language used for IRR objects. It provides a syntax for recording policy; it is not a measurement of current route propagation. An object can be well-formed while a network announces something else, and a live announcement can exist without every registry consumer treating one IRR record as decisive. RFC 2622

The writing channel therefore belongs to provenance and authorization. It is valuable because it helps answer who could change a registry assertion, under which validator and through which interface. It becomes dangerous only when that administrative fact is inflated into routing truth.

Why the migration boundary deserves a defense

ARIN’s implementation notes place the split in a real transition. Records from the former email system did not all enter the same destination. Validated records associated with ARIN-managed resources were migrated into ARIN’s authoritative IRR environment; other records were placed in ARIN-NONAUTH. ARIN also says that once an organization begins using the web or REST service, its old IRR-email update path is permanently disabled. ARIN IRR Online implementation notes

A one-way transition can be a sensible control. Supporting two writers indefinitely would create ambiguity about which validation rules, credentials and last-write semantics govern an object. Closing the email path after a modern action reduces that split brain. Marking migrated objects also avoids laundering old provenance into a new interface merely because the bytes passed validation.

There are operational reasons to keep payload languages separate too. A structured web or XML form can enforce a bounded set of fields and relations. RPSL is a domain language whose object grammar and free-form attributes have their own parsing rules. If ARIN cannot guarantee that a web round-trip preserves every advanced RPSL expression, refusing an Online edit is safer than silently simplifying it.

This defense changes what a proportionate remedy looks like. The answer is not necessarily “put an edit button beside every object.” An edit surface that cannot faithfully represent the source object would be false convenience. The better question is whether an operator can see why a channel is unavailable, export the canonical preimage, choose a supported conversion knowingly and retain evidence linking the successor to what it replaced.

Delete and recreate is a conversion

Deletion has a different failure shape from editing. An edit can often be described as a transition from one canonical object hash to another under one persistent identity. Delete-and-recreate introduces an interval in which the old object is absent, a new validation transaction, and the possibility that the successor is not accepted or not observed by every downstream consumer at the same time.

The sources do not show that such an interval caused a routing or filtering event. They do not publish timing distributions, object counts or NRTM serial behavior for this workflow. Those facts must remain unknown. But the control difference exists even before harm is measured: the operator is being asked to replace continuity with a pair of operations.

If the visible attributes are copied manually, small changes can be intentional, accidental or validator-required. If the object key is reused, a reader may see what appears to be the same registry object while its creation class has changed. If the key changes, consumers need another way to understand that the new record was meant to supersede the old one. A screenshot of the form is not a durable answer. Neither is a support ticket that downstream systems cannot inspect.

ARIN’s REST guide documents GET, POST, PUT and DELETE methods for the supported IRR object types. PUT is the modification operation; DELETE removes the object. The guide accepts RPSL and XML subject to the object’s permissions. That makes the difference between modification and replacement explicit at the protocol level even when the final public RPSL looks familiar. ARIN IRR RESTful API

A conversion receipt need not become a surveillance record. It can use public object keys and hashes instead of private content, identify an actor class rather than publish a person’s name, and omit the API key entirely. The important facts are the pre-action class, creation-provenance class, permission-matrix version, canonical preimage hash, action, authorized channel and encoding, result, post-action class and hash, and a replacement link when deletion was followed by recreation. A publication observation or NRTM serial can be added if ARIN can supply it accurately.

Corrections and reversals should extend the chain rather than overwrite it.

Such a receipt would prove only that a registry operation occurred under a described control path. It would not prove that every IRR mirror received it, that a filter builder consumed it, that BGP followed it, or that traffic remained reachable. Keeping those limits in the receipt is part of making it trustworthy.

Two current pages leave one permission unresolved

ARIN’s public record contains a documentation conflict that should not be resolved by guesswork. The current overview matrix says simple objects have no RPSL REST permissions. The implementation notes, whose page lists updates through 17 January 2025, say objects created through ARIN Online can be viewed, updated and deleted through REST using either RPSL or XML.

Both pages were live in the captured source set. An authenticated test could still be misleading if it covered only one object type, one account state or one migration history. The reliable repair is one current permission contract that names the relevant class, object type, operation, channel and encoding, plus a documented version or effective date. Until ARIN aligns the pages or runtime evidence is gathered under a valid account, the article cannot say which statement describes production.

The historical record explains why such drift can occur. A February 2021 ARIN blog post described the incoming REST service and limitations that were then expected to change. ARIN now places that post in its Vault and warns that Vault material may be out of date. It is useful chronology, not a present permission table. ARIN Vault: REST API chronology

This is precisely where running code and institutional prose must be kept apart. A current table is a claim about supported control. A live response is an observation from one case. A historical announcement records intent at a past time. None should silently substitute for the other.

A narrow ledger for a narrow authority

ARIN controls the authoritative service, its validators and the account roles permitted to manage records. Its user guide says Admin, Tech and Routing POCs can manage IRR information, while Resource POCs cannot. That is an authorization boundary separate from the object class. An actor may hold an eligible role and still face a channel restriction because of how the object was created.

The organization controls its credentials, personnel assignments and decision to convert an object. Software clients control how faithfully they preserve RPSL and how they handle errors. Downstream consumers decide when to fetch IRR data and how much weight to give it. The registry can make the first part auditable; it cannot command the last part.

That distribution argues for a thin continuity record, not a new gate over routing. A receipt can help an organization prove that a planned conversion happened, help support distinguish a rejected recreation from a stale consumer, and help an auditor see that a class change was deliberate. It should not decide whether a route is legitimate or whether an operator is entitled to speak on the Internet.

The public evidence examined here establishes no bad object and no affected organization. It establishes a subtler design fact: in ARIN’s IRR, the path by which an object entered the system can remain attached to the path by which it may be corrected. Preserving that lineage is responsible. Making operators erase it in order to change interfaces, without an explicit replacement link, is the seam worth repairing.

Sources

  1. ARIN: Internet Routing Registry overview
  2. ARIN: IRR user guide
  3. ARIN: IRR Online implementation notes
  4. ARIN: IRR RESTful API
  5. ARIN Vault: Take a REST — the API is coming to ARIN’s IRR
  6. RFC 2622: Routing Policy Specification Language