Summary

  • In ARIN suggestion 2026.4, Richard Laager described creating a detailed reassignment from his parent NET to another organization. His parent-side API key could delete the child record and retrieve it by address range, while GET by the child’s NET handle was rejected; the recipient organization’s key could perform that handle lookup.
  • ARIN replied on 30 March 2026 that other retrieval tools and future plans made a change to current API permissions unnecessary. It closed the suggestion with Laager’s agreement. The public record establishes that decision and the reported reproducer, not a present-day production test of the permission check.

The API would let him remove the record. It would not let him read that record by its own name. Richard Laager’s suggestion 2026.4 puts that oddity into two steps: make a detailed reassignment out of one of your NETs to another organization, then use the parent-side API key to GET the resulting child NET by handle. The call was rejected for lack of permission. The same submitter said he could DELETE the child NET, obtain it by start and end IP address through mostSpecificNet, and see the same public information through anonymous Whois. A handle-based read had become the hardest action in a workflow that still permitted a destructive one.

The details of the reassignment matter. ARIN’s resource-management guide describes a detailed reassignment as a transfer of day-to-day management capability to a recipient organization with its own Org ID. The recipient can manage the assigned addresses in ARIN Online, and the direct registrant retains the ability to reclaim the reassignment. For IRR objects and reverse DNS associated with the record, the guide describes shared management. These facts establish two parties with continuing interests in one child NET. They do not create a universal entitlement to edit every field of the child record.

Laager’s report makes the access map unusually legible. The recipient Org’s API key could GET the child NET by handle. The parent-side key, which had created the detailed reassignment, could not. Yet that parent-side key could DELETE the NET, according to his reproducer. It could also use mostSpecificNet with the start and end addresses to retrieve it. Any anonymous Whois user could look up the same public information by handle or address. The paradox is not that the record was secret. The same record was available through other paths; one authenticated endpoint treated the parent-side relationship differently.

ARIN’s Reg-RWS method guide gives each path its own verb and URL. GET /rest/net/NETHANDLE returns a NET payload. GET /rest/net/mostSpecificNet/STARTIP/ENDIP returns the most specific NET for a range. DELETE /rest/net/NETHANDLE initiates a ticketed request to remove a reassignment or reallocation; it is not an instantaneous generic eraser of direct allocations. PUT /rest/net/NETHANDLE modifies a NET with a supplied payload. The guide lists these operations as separate calls, so the endpoint-specific authorization Laager reported has a real place to live. A successful range lookup does not silently turn into a successful handle lookup in an automated client.

The resulting operator problem is mundane and expensive. A provisioning system stores a NET handle when it creates a detailed reassignment. The next reconciliation pass normally reads that handle to compare desired and recorded state. If the parent-side key cannot perform that read, the system must also store the address range, invoke a different lookup, verify that the returned object is the intended child and then map its fields back to the original request. Public Whois can help a human investigate, but it is a separate interface and evidence path. The more surprising DELETE permission creates a dangerous temptation to rebuild a record merely to regain a clean state. Deleting a customer’s registration is a poor substitute for reading it.

Laager asked ARIN to make the GET check broadly permissive. He also argued that a party able to delete and recreate a direct child should be able to modify it with PUT. Those are two different decisions. A read of publicly visible NET data concerns retrieval and automation consistency. A parent-side write could change the network name, contact links or public comments described in ARIN’s network-modification guide; it needs its own authority boundary. The submitter’s inference from DELETE to PUT is a proposal, not a rule ARIN adopted.

ARIN replied on 30 March 2026. After considering other existing tools for retrieving the information and future development plans, it concluded that changes to current API permissions were unnecessary at that time. The suggestion closed with the submitter’s agreement. ARIN did not claim in that reply that handle-based GET had been changed. Its answer chose the alternate paths over endpoint parity.

That is a legitimate product choice with a cost attached. An operator can reach the object by range or public query, but must carry extra identity checks and reconciliation logic in the client. A registry can defend a permission line for a write. Here the denied operation was a read of data the requester could already obtain in several other ways. The boundary moved from who may know the NET to which request form may return it. An API key that can remove the record but cannot read it by handle is a memorable way to make that distinction visible.

The public record leaves one current-state question open: a fresh production trace using both organizations’ keys against the documented calls would show whether this reported handle-GET denial still occurs after ARIN’s March reply. The published decision was to leave the permission check alone. Until a changed endpoint or trace appears, a parent network automating detailed reassignments must plan around the exact call ARIN will accept.

Suggestion 2026.4 and ARIN reply · Reg-RWS methods · Resource-management guide · Network modifications