Summary

  • ARIN's current database guide attaches a Resource Tech POC to a particular resource, but assigns responsibility for RPKI and IRR certification information to a Routing POC for the organization.
  • ACSP Suggestion 2026.10, submitted on 20 August, asks ARIN to let those Resource Tech POCs manage RPKI and IRR for the resources to which they are linked.
  • The page says only Confirmed. Under ARIN's published process, that means receipt has been confirmed before staff evaluation; it is not an acceptance, implementation commitment or delivery date.
  • A safe response would delegate exact actions over an exact prefix set, with expiry, revocation, approval rules and an immutable actor log. Giving a resource operator all organization-wide routing-security power would erase the requested boundary.

One prefix, two authority maps

ARIN's public database guide draws a precise distinction. An Organizational Tech POC can manage an Org ID and its resources. A Resource Tech POC is optional and may instead be attached directly to an allocation, address block or ASN. ARIN says that resource-level contact can change attributes such as a resource name and public comments, associate other resource POCs and, depending on the resource, specify nameservers or delegation-signer records.

The Routing POC is described differently. It is responsible for Internet Routing Registry and Resource Public Key Infrastructure certification information “for the organization.” The placement matters. One role follows a resource; the other follows the organizational container.

ARIN's operational interfaces reflect the second map. Its hosted-RPKI instructions tell a user to choose Manage RPKI for an organization. The REST transaction that creates and deletes ROAs is addressed to /rest/rpki/ORGHANDLE. The same transaction can carry several ROA changes and can be combined atomically with ASPA changes. ARIN's IRR API also describes an organization as the maintainer and lists Admin, Tech or Routing POCs for that maintaining organization.

None of this is a defect by itself. Organization-level control can make responsibility clear, prevent a narrowly attached contact from altering unrelated routes and give a direct resource holder one coherent security perimeter. But the two maps do not coincide when an organization delegates day-to-day work by resource.

That is the gap identified in ACSP Suggestion 2026.10.

What ARIN actually confirmed

The suggestion was submitted by Nathanael Jean-Francois on 20 August 2026. It asks ARIN to allow Resource Tech POCs to manage RPKI and IRR for the resources to which they are linked. The submitter says staff closest to particular resources cannot currently create or delete the relevant ROAs without going through the organization-level Routing POC. In the submission, that extra handoff is said to delay incident remediation and new-service provisioning.

Those delay claims are part of the request, not findings published by ARIN. The page contains no incident sample, elapsed-time distribution, affected prefix count or independent measurement. It also contains no staff response under “Tracking Information.” Its status is Confirmed, updated on the submission date, and its timeframe is “Not specified.”

ARIN's Consultation and Suggestion Process explains why the distinction is important. Staff immediately confirm receipt of a valid suggestion. They then have ten business days to evaluate it. A later response may reject and close the request, refer it to the Board or Advisory Council, find it implementable, or open a consultation. The bare confirmation therefore proves that the request entered the process. It does not prove that ARIN agrees with its premise, has chosen a permission model or will build the feature.

This is more than procedural caution. Treating confirmation as approval would turn a queue state into policy and could encourage users to assume permissions that do not exist.

The wrong shortcut is organization-wide access

The obvious implementation would be the dangerous one: if a person is a Resource Tech POC anywhere under an Org ID, give that person the same routing-security controls as the organization's Routing POC. That would reduce handoffs by expanding the blast radius.

It would also discard the information already present in ARIN's records. A Resource Tech attachment states that a particular contact has a relationship to a particular resource. It does not state that the contact may create or remove ROAs for every other prefix in the organization, change ASPAs for unrelated ASNs, alter the global IRR Auto-Manager setting or act for every business unit sharing the Org ID.

The request is valuable precisely because it asks for a narrower connection: the staff member who manages a resource should be able to perform selected routing-security work for that resource. The system should preserve “selected” and “that resource” as enforceable constraints, not as prose on an account page.

The inverse shortcut is also weak. Requiring every change to pass through one organizational role may preserve central control, but it can convert a registry contact graph into an operational bottleneck. A stale Routing POC, a timezone boundary or a separation between corporate administration and network operations can add delay. The sources do not measure how often this happens, but they make the architecture of the possible handoff visible.

A capability should be smaller than the organization

ARIN can evaluate the suggestion as an authorization-design problem. The useful public artifact is not a list of which employees can touch which prefixes. It is a documented capability model and a privacy-safe aggregate account of how it performs.

Each delegated capability could bind at least eight fields:

  1. the exact NET handles or prefix ranges covered;
  2. the action classes allowed, separately for ROA, ASPA and IRR operations;
  3. the POC or authorized organizational role that granted the capability;
  4. an effective time and optional expiry;
  5. whether create, modify and delete are independent rights;
  6. which high-impact actions require a second approver;
  7. the revocation and emergency-freeze path; and
  8. an immutable action record naming the authenticated actor, authority source, before-and-after object handles and result.

ARIN already exposes a ROA change log containing time, operation, source, origin AS, prefix, max length and the user who made the change. A resource-scoped model would need to add the authority path: not merely who clicked, but which active delegation permitted that exact action on that exact resource.

The model should also reject boundary leakage. A delegated user must not gain access to a parent allocation merely because a child prefix is in scope. Removing the Resource Tech link should revoke the derived capability promptly. Moving a resource between organizations should invalidate old grants. API keys should inherit no more authority than the account that created them, and bulk transactions should fail atomically when any requested object falls outside the permitted set.

These requirements are not arguments for or against the suggestion. They describe the evidence needed to know whether an implementation preserves least privilege.

What the record cannot support

The current sources do not show that ARIN caused a routing incident, blocked a valid launch or left a known incorrect ROA in place. They do not count Resource Tech POCs, affected organizations or delayed actions. They do not prove that all resource-level contacts should receive routing-security privileges or that unilateral deletion is appropriate in every organization.

Nor does a public POC label prove that the current person behind it has authenticated authority. ARIN Online account linkage, organizational approvals, agreement coverage, RPKI eligibility and the state of the resource certificate still matter. A role in Whois/RDAP is part of the authorization graph, not the whole graph.

The news is narrower. ARIN has recorded a request that exposes a real difference in its documented model: resource-specific technical authority exists, while RPKI and IRR responsibility is expressed at the organization level. The next defensible state is an evaluation that preserves both response speed and scope control—and publishes enough of the design to let operators tell which one was traded away.

Sources