Summary

  • ARIN's current policy, section 3.7, requires an existing downstream organization and at least one validated Point of Contact before a detailed reassignment or reallocation is accepted. ARIN must reject a request when the receiving organization has no validated contact. A simple reassignment has no such organization or contact linkage.
  • ARIN's operational guide says a simple record uses a customer name entered as unvetted free text and leaves management with the direct registrant. Detailed reassignments and reallocations require an Org ID and agreement, give the recipient different management capabilities, and still let the direct registrant reclaim the record.
  • ARIN's rejection template sends the next move to the downstream customer: validate a contact, then ask the upstream provider to retry. The template records a failed registration request and contains no routing measurements.

The most revealing line in ARIN's Managing Resource Records guide is that a simple reassignment's customer name is entered as free text and is not vetted by ARIN. The upstream registrant can use the record to show that some of its space serves another party. That other party cannot manage the reassigned block. The upstream can edit or delete the entry whenever it chooses. It is a useful ledger row, with the pen firmly on one side of the table.

The customer acquires a different relationship to the database when the provider asks for a detailed reassignment. ARIN says this requires the customer's Organization Identifier, or Org ID, and a Registration Services Agreement. The customer can then add contacts and manage the reassigned addresses in ARIN Online. The upstream and downstream sides can both work on Internet Routing Registry objects and reverse DNS. The upstream still retains the ability to reclaim the reassignment. The customer gets operating handles inside a record that the upstream can take back.

Reallocation goes further. It is for a downstream organization, often an ISP, that will manage and subdelegate address space to customers of its own. ARIN again requires an Org ID and agreement. The recipient can create downstream reallocation and reassignment records. Here too, ARIN says the direct registrant can reclaim the reallocation. The distinction is a ladder of record control, from provider-only entry to customer management to customer subdelegation. At each higher rung, a named organization replaces the free-text customer.

Now read section 3.7 of the Number Resource Policy Manual. A receiving organization for a detailed reassignment or reallocation must already exist in ARIN's database and have at least one validated Point of Contact. If there is no validated contact, ARIN shall reject the request. The policy explicitly excludes simple reassignments from this organization-and-contact linkage. Two records can describe use of provider-held space by a customer while exposing sharply different institutional demands.

The customer's wish for separate reverse-DNS delegation or its own displayed contacts is not decorative. ARIN's reporting guide says those needs can make a detailed reassignment appropriate. A customer planning to pass space to its own customers needs reallocation. The more an operator wants its operational identity and delegated functions represented accurately in the registry, the more it must satisfy the recipient-side contact test. A simple record may be easier to submit, but it leaves the customer without the controls it needed.

ARIN has published the failed transaction in miniature. Its status-message templates include a notice that a downstream Org ID has no validated Points of Contact and that the reassignment could not be processed. The recipient is told to validate a POC in ARIN Online and contact the upstream provider afterward. The provider is told to ask the customer to validate and then retry. The upstream can initiate the transaction; the downstream must repair the condition; the upstream must submit again. A workflow with three actors has a single missing checkbox that none of them can simply skip.

The contact rule has its own clock. Policy section 3.6 describes an annual verification email, with up to sixty days for a POC to confirm or correct its Whois information. ARIN staff may mark a POC invalid after careful analysis that it is completely and permanently abandoned or otherwise illegitimate. An invalid POC has limited ARIN Online access; an organization with no valid POCs cannot use other account functions until an Admin or Tech POC validates or corrects a record. Those are separate rules from the section 3.7 test, but they explain how an apparently clerical contact state becomes an operational gate.

The upstream cannot solve every missing identity by inventing a downstream Org ID. Section 3.8 says ARIN creates an organization record on a direct request from an authorized contact representing an entity ARIN can validate, not on a third party's request. The provider can ask its customer to participate, but cannot legitimately stand in for that customer's identity under the published creation rule. That separation protects the registry against forged organizations. It also places an actual duty on a downstream operator that wants its own record controls.

The sharp edge is admission to the registry. The official pages give a rule, a capability map and rejection language; they provide no dated customer ticket with a measured delay or routing outcome. A dated ticket and its outcome would show the operational cost in one real case.

The institutional choice is still visible without that case. ARIN is willing to carry a provider-controlled customer label without vetting the customer name. It demands a verified organization and reachable contact before assigning the customer a stronger role in the database. The more the record says the customer can do, the more the customer must prove it can answer. That is a coherent fraud-control instinct. It is also a reminder that the registry's account state controls which version of the customer can exist in the public ledger.