Summary

  • In ACSP 2026.4, a submitter reported that after making a Detailed Reassignment to another Org, the upstream parent's API key could DELETE the child NET and retrieve it with mostSpecificNet using the exact start and end addresses, but could not GET the same child by handle. Only the recipient Org's key reportedly succeeded on that path.
  • ARIN closed the suggestion on 30 March 2026 after considering other retrieval methods and future development plans, saying a permission change was unnecessary at that time. The response does not independently confirm every reported step, and “Closed” is not a deployment certificate.
  • Current documentation separates public Whois/RDAP discovery, authenticated NET Payload operations, recipient management authority and direct-registrant reclaim authority. Those distinctions give path-dependent permissions a strong least-privilege defence.
  • The unresolved operating question is narrower: before an authorized DELETE or reclaim, can automation obtain a stable identity, dependency preview and version precondition for the exact object without receiving private fields or general PUT authority?

The most consequential line in an access-control table is often not “allow” or “deny”. It is the identifier placed to the left of the decision.

ARIN's ACSP suggestion 2026.4 describes a Detailed Reassignment created from one NET to another organization. According to the submitter, the direct registrant's API key was denied when it tried to GET the new child NET by its handle. The recipient Org's key could do so. Yet the submitter said the parent could DELETE the child, retrieve it with mostSpecificNet when given the exact beginning and ending addresses, and find public registration information through Whois by handle or IP address.

The submitter treated these results as an inconsistency and also argued for parent-side PUT because deletion followed by recreation could produce a similar outcome. ARIN did not adopt that reasoning. Its 30 March response said staff had discussed other retrieval methods available through existing tools and future development plans, and concluded that changing the API permission checks was unnecessary at that time. The record is marked Closed, with the submitter's agreement.

That is the complete evidentiary shape. It is an official record of reported behavior and an official closure response. It is not a vulnerability notice, an incident report or an independent reproduction. It does not establish that every current account, child NET or authentication context behaves the same way. ARIN's present documentation describes the available methods and payloads, but it does not by itself replay the permission decisions in the suggestion.

The value of the case lies elsewhere. It exposes how quickly a registry permission becomes ambiguous when actor, relationship, object class, identifier path and returned field set are compressed into a single verb.

Reclaim is not ordinary management

The strongest case for ARIN's boundary begins with the institutional relationship, not the endpoint.

ARIN's resource-management guidance distinguishes a simple reassignment, a detailed reassignment and a reallocation. A simple recipient has no direct management capability. A Detailed Reassignment goes to an Org that gains direct management authority. The direct registrant nevertheless retains reclaim authority, while some reverse-DNS and IRR functions may be shared. A reallocation creates a different downstream power again because the recipient may reallocate or reassign further.

These are not cosmetic labels. They assign different responsibilities to two organizations around one address block. The recipient needs enough control to maintain its registration and operational contacts. The direct registrant needs a bounded way to end the relationship and recover space for which it remains accountable. Giving the parent every read and write capability held by the recipient would erase the distinction that Detailed Reassignment is meant to create.

The public/private boundary adds another reason for caution. ARIN describes Whois-RWS and RDAP as public directory services backed by registry data. A public answer can show a handle, range and registration facts without necessarily exposing the same fields or semantics as an authenticated provisioning payload. The documented NET Payload can include version data, comments, dates, recipient identity, parent handle, network name, origin AS values and POC links. Some hierarchy fields cannot be changed during a modification. It would be a mistake to infer that because a handle appears in Whois, every actor should receive the complete operational payload behind it.

Least privilege can therefore produce an asymmetric result by design. The parent may be authorized to revoke its grant but not to administer the recipient's ordinary details. The recipient may be allowed to retrieve and modify the child because it bears that management role. A public directory may answer a narrower question for anyone. No universal access-control law says that DELETE must dominate GET, or that GET must imply PUT.

That defence is substantial. It is also incomplete for automation.

The same NET is not the same request

Current Reg-RWS method documentation describes four relevant calls:

Path and operation Documented output or input Operational question
GET /rest/net/NETHANDLE returns a NET Payload May this actor retrieve this object through its stable handle?
GET /rest/net/mostSpecificNet/STARTIP/ENDIP returns a NET Payload Which most-specific object matches this exact bounded range?
DELETE /rest/net/NETHANDLE returns a Ticketed Request Payload May this actor remove this reassignment or reallocation?
PUT /rest/net/NETHANDLE accepts and returns a NET Payload May this actor change permitted fields on this object?

These calls do not merely spell four verbs. They bind each verb to a resolution path and a payload. That binding matters because a handle is a stable registry identity, while a start-and-end range is a property the caller must already know. Public Whois is a third surface, optimized for directory lookup rather than authenticated provisioning.

ARIN's older ACSP suggestion 2023.13 makes the discovery limit explicit. An exact-range mostSpecificNet call is not a general way to bootstrap from any contained IP address: the caller must know the correct start and finish. An alternative route can be technically available yet operationally circular. It helps when an inventory is already accurate; it does not necessarily repair a stale inventory.

That is why “you can retrieve it another way” is not the end of the analysis. For a human using ARIN Online, a search and confirmation screen may be enough. For an automated reclaim process, the operator needs to know which identifier is authoritative, whether the object has changed since it was selected, and what will be affected. If the only successful API lookup requires the exact range already stored locally, automation may be confirming its own old belief rather than the registry's current identity.

The DELETE method raises the stakes. ARIN says deletion applies only to reassignments and reallocations. If the target has no child NETs, the request may be processed automatically and returns a Ticketed Request Payload containing details of the deleted network. If it has nested networks, the result is a ticket and the operator must wait for successful processing before reissuing the space. ARIN's reassignment instructions likewise tell a user to locate the network, select its Net Handle and confirm an operation described as irreversible.

The system plainly understands that NET identity and dependency state matter before reuse. The documentation, however, presents the richest result after the destructive request. That is the point at which a least-privilege preflight becomes useful.

A permission needs eight coordinates

A registry automation contract should not be reduced to a two-dimensional table of verbs and object names. The relevant unit is:

actor role × relationship × object class × identifier path × verb × field set × precondition × result

For this case, “parent can DELETE NET” leaves almost every safety question unanswered. Is the actor the direct registrant, a resource POC, a delegated technical contact or an Org administrator? Is the object a simple reassignment, Detailed Reassignment or reallocation? Is it a direct child or a deeper descendant? Was it resolved by handle, exact range or a search result? Does the actor receive a full NET Payload, public fields or a redacted view? Does deletion require a current version token? Are nested networks, DNS delegations, IRR objects or POC associations in scope? Is the result immediate or ticketed?

The same precision also protects the recipient. A parent-side ability to see a deletion preview need not include comments, private contact details or fields that only the recipient may manage. A permission can be narrow in both action and disclosure.

The NET Modify guidance points toward the right principle by telling a user to obtain the current NET with GET before changing it. That is a familiar concurrency rule: do not send a stale object back to a registry. Yet if an authorized reclaiming actor cannot retrieve the object through the handle used for the action, the system needs some other current-state primitive. Otherwise the safety instruction and the permission boundary do not meet.

This does not prove that the current API is unsafe. The suggestion record contains no wrong deletion, outage or disclosed private record. It shows a contract question that deserves a testable answer.

The smallest useful remedy is a deletion preview

ARIN need not grant the parent a full by-handle NET Payload or general PUT authority. A bounded endpoint could answer only the questions required to perform the authorized consequential act.

A deletion or reclaim preview could return:

  1. the stable NET handle and normalized address range;
  2. the object class and direct parent relationship;
  3. the recipient type, expressed without private contact fields;
  4. whether child NETs exist and whether processing will be automatic or ticketed;
  5. aggregate indicators for dependent DNS, IRR and routing objects whose treatment matters;
  6. the scope of records that will be removed, retained or require separate action;
  7. a current version or short-lived precondition token;
  8. the notifications and audit evidence that successful execution will create.

The subsequent DELETE would present that token. If the range, child structure or material dependency state changed, the request would fail closed and require a fresh preview. The operator would gain observability, not recipient-side management. ARIN would preserve its access boundary while making the irreversible act bind to the state that the actor actually reviewed.

A versioned public capability matrix should sit beside that primitive. It should enumerate each supported actor and NET relationship, accepted identifier routes, output class, permissible verbs, immutable fields, preconditions, ticket behavior and safe error path. It should say which cells are deliberately asymmetric and why. Where behavior changes, the matrix should preserve the prior version and effective date.

That document would do more than settle one suggestion. It would let operators generate contract tests before deploying registry automation. A test could confirm that a direct registrant receives a bounded reclaim preview, that a detailed recipient receives its management payload, that a simple customer receives no management authority, and that a reallocation follows its own downstream rules. The test would assert intentional differences instead of treating every difference as a defect.

Closed is a workflow state

The ACSP record says ARIN considered existing tools and future plans and found no permission change necessary at that time. That is a legitimate product decision. Alternate interfaces can meet a use case, and development capacity is finite. The submitter agreed to closure.

But Closed should be read as the state of the suggestion, not as proof that a new permission model was deployed, that the reported behavior was independently confirmed, or that the underlying automation question can never recur. The phrase “at this time” is itself a useful boundary.

ARIN can preserve that boundary by publishing the contract it intends operators to rely on. If the intended rule is that a direct registrant may reclaim a Detailed Reassignment but may not retrieve the recipient's full provisioning payload by handle, say so in the capability matrix. If exact-range lookup or ARIN Online is the supported preflight, state the inventory assumptions and returned field limits. If a future interface will provide safer object discovery, give it a version and migration path.

Access control is strongest when a denial is intelligible and an allowance is reviewable. The parent should not inherit the recipient's identity merely because it owns the enclosing space. The recipient should not be able to make the parent's reclaim responsibility impossible to exercise safely. A public directory should not be mistaken for a provisioning API. An irreversible operation should not depend on an object state the acting system cannot observe.

Those propositions are compatible. The way to keep them compatible is not a broader key. It is a smaller, explicit contract.