Summary

  • Draft Policy ARIN-2025-1 says all Internet Service Providers are Local Internet Registries, but not all LIRs are ISPs. Its proposed LIR definition requires an Internet Registry, RIR membership, receipt of allocations and a downstream allocation function.
  • Its proposed ISP definition requires only that an organization provide Internet services to outsiders, with examples ranging from connectivity to web services, colocation, dedicated servers, VPS and VPN. Those predicates do not by themselves establish the claimed subset.
  • ARIN can keep business design local while making the policy role exact: bind each classification to a vocabulary version, resource lifecycle and delegation function, then track every consequential ISP-to-LIR text and application migration.

Two cards that do not nest

Imagine two intake cards on an analyst's desk. The first asks whether an organization sells an Internet service to someone other than its employees. The second asks whether the organization is an Internet Registry, receives number-resource allocations and distributes them onward.

An access carrier may answer yes to both. So may a hosting operator that directly holds space and subdelegates it to customers. Familiar examples make the cards look interchangeable.

A good definition is built for the unfamiliar answer. A managed web provider can supply an Internet service while using addresses obtained entirely from an upstream. A university can receive and distribute an allocation across departments without selling retail access. A large enterprise can operate a registry function for customers or affiliated end users without adopting the commercial identity of an ISP.

The independent NOG Alliance policy tracker records ARIN-2025-1 as a Draft Policy, with 13 August 2026 as its latest change. The proposal tries to bring order to the two labels. Its problem statement says LIR is defined while ISP has been left implicit, then states the intended relation: through implication and common business practice, all ISPs are LIRs, but not all LIRs are ISPs.

That is a set claim. Every organization satisfying the ISP definition must also satisfy the LIR definition. It is stronger than saying the categories often overlap, that ARIN commonly uses the labels together or that most direct allocation applicants providing customer services perform both roles.

The claim can be perfectly sensible as a policy choice. It still needs definitions that make it testable.

The LIR definition is about the resource chain

The proposal text preserved in an independent March 2026 PPML archive gives the LIR definition several links. A Local Internet Registry is an Internet Registry. It is a member of an RIR. It receives allocations of Internet numbers from that RIR. It allocates those numbers to customers, end users and infrastructure.

The examples are intentionally broader than retail carriers. The draft says LIRs include, but are not limited to, large enterprises, universities and ISPs whose customers are mainly end users and possibly other ISPs.

Each element concerns a number-resource relationship. The Internet Registry distributes numbers and records distributions. RIR membership supplies an institutional relation. Receipt of an allocation creates a lifecycle event. Allocation to downstream parties or infrastructure describes what happens next.

That archived distribution also shows the proposed migration: headings and operative clauses that used ISP would move to LIR, while the terminology clause would say ISP is a subset of LIR. This matters because the change is not a glossary footnote. It would carry one role name across allocation, reassignment, utilization and downstream-customer provisions.

The independent archive is documentary evidence of what was circulated, not an authority that settles the policy. The tracker establishes only the later version boundary and status. A publication package should therefore preserve both facts: the exact text being analysed and the later version state whose complete wording must be checked before implementation.

The ISP definition is about a market activity

The proposed ISP definition starts on another axis. An Internet Service Provider is an organization that provides Internet services to other organizations, customers or individuals other than employees. The list includes connectivity, web services, colocation, dedicated servers, virtual private servers and virtual private networks.

Nothing in that sentence expressly requires the ISP to be an Internet Registry. It does not require direct receipt of an allocation from an RIR. It does not require RIR membership. It does not require the provider to reallocate or reassign numbers to customers.

The ambiguity is visible in an independently preserved PPML exchange about the request guidance. A participant quotes the guidance calling an LIR an ISP while also quoting language that LIRs are only generally ISPs, then asks whether the categories are identical, nested or optional for direct-allocation holders. The archive proves confusion was expressed; it does not prove how staff would decide a particular request.

The exchange exposes the missing bridge. A service description tells a reader which door to inspect. It does not automatically satisfy the test behind the door. Selling VPN service is not the same fact as receiving an RIR allocation. Operating dedicated servers is not the same fact as registering downstream number-resource distributions.

The proposal can choose to make every ISP a type of LIR. Its original proposal used language closer to that choice. The current public definition instead defines ISP as a type of organization, not a type of LIR organization. The difference is only four words. Logically, it is the hinge.

The implication that is missing

The mismatch is easier to see with five analytical predicates. These symbols are not ARIN terminology and are not a proposed software schema.

Let IR(x) mean that organization x distributes Internet number resources and registers those distributions. Let M(x) mean it holds the specified RIR membership relation. Let A(x) mean it receives an allocation from that RIR. Let D(x) mean it allocates or otherwise subdelegates number resources downstream. Let S(x) mean it supplies at least one listed Internet service to an external party.

The proposed LIR definition can be read as LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x). The proposed ISP definition can be read as ISP(x) = S(x).

For every ISP to be an LIR, the text needs an implication: S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). It never states one.

This does not mathematically prove an operational error. Public policy contains context, staff interpretation and separate qualification clauses. It proves a narrower point: a reader cannot derive the declared subset relation from the two proposed definitions alone.

There are several coherent repairs. ISP could again be defined as a type of LIR. The service definition could be narrowed to a provider performing a qualifying distribution function. The categories could be described as overlapping rather than nested. Or ISP could disappear from normative eligibility text, leaving request paths attached to resource-use predicates.

The community should choose among those models. A reader should not have to guess which one it chose.

A synthetic provider at the boundary

Consider an invented company that sells managed web service and VPN access. It gets every address from an upstream provider. It has no direct RIR allocation and does not act as an Internet Registry by allocating and registering number resources for downstream customers.

This is a synthetic logic test. It is not a named operator, an ARIN request or a report of staff practice.

The company satisfies the public ISP service predicate: it supplies two listed Internet services to outsiders. It does not satisfy at least the direct-allocation and downstream-distribution predicates in the proposed LIR definition. Depending on the intended meaning of member of an RIR, it may fail that predicate too.

Calling it an ISP may be useful commercial language. Directing it to an ISP request guide may also be useful: the guide can help it discover whether its planned customer assignments justify a direct allocation. Neither step makes the allocation exist before the request or converts upstream address use into a registry function.

Boundary cases are not traps. They are the cheapest way to test whether a definition carries the relationship its authors intend.

Resource function and organizational label are separate axes

RFC 7020 describes the Internet Numbers Registry System as a hierarchy in which registries allocate number resources to customers and Local Internet Registries are typically ISPs. Typically describes a recurring relation; it does not define an identity between a registry role and every organization selling an Internet service.

That produces two axes. On the resource axis, an organization may be an applicant, a direct allocation holder, a downstream distributor, an end user or an operator using upstream space. On the service axis, it may offer connectivity, hosting, colocation or VPN products. A classification can legitimately consult both axes, but it must state which combination triggers the policy role.

An archived alternative proposed in the PPML discussion makes that choice explicit: it ties LIR to the registry system described by RFC 7020 and treats consumption and justification of number resources for customers as the important ISP feature. That wording was a participant's suggestion, not adopted text. Its value here is diagnostic: the missing bridge can be written in one sentence when the intended resource function is known.

If member of an RIR remains a necessary LIR predicate, the policy still needs to name the exact relation and the lifecycle moment when it must hold. A commercial service cannot create that state by implication, and a resource relation should not be inferred from a marketing noun.

The administrative history kept the roles distinct

RFC 2901, published in 2000 as an informational guide to administrative procedures, routed organizations to different request material according to how they would obtain and use address space. Its procedures are historical and cannot establish current ARIN requirements. They do establish a durable analytical point: ISP has long been used as a request-path label while LIR belongs to the registry hierarchy.

Terms can converge in ordinary speech while procedures still ask different questions. The correct common fact is therefore not the company's preferred noun. It is the resource function that selects a rule at a given version and time.

Public discussion already found the weak bridge

The independently archived discussion did not merely argue about style. One March 2026 reply agreed that the proposed LIR sentence was grammatically incomplete and questioned at a local level because some LIRs operate more broadly than a single RIR region. The same message reproduced the proposed ISP service definition.

That reply cannot settle policy and does not contain an implementation decision. It does show that participants were testing the predicates and their scope before the later 13 August version boundary. The issue in this article is therefore not a claim of hidden misconduct. It is a reproducible textual question that the next version can answer.

Terminology is distributed state. A definition change reaches headings, request guidance, staff instructions, training and application fields. A later version must be reviewed as a new object rather than treated as a silent continuation of the archived March text.

A minimum role-predicate crosswalk

The repair does not require ARIN to inventory every product a network sells. It requires a small protected record connecting the role decision to the rule and the actual resource function.

Sixteen fields are enough for an initial crosswalk and migration manifest.

  1. Organization and Org ID identity. Record the legal and registry identity used for the classification, with the relevant time boundary.
  2. Request or decision identity. Give the case a stable key, submission time and explicit links to revisions or replacement requests.
  3. Vocabulary version. Name the exact NRPM, draft or implementation version and effective date used for ISP, LIR, IR, end user and delegation terms.
  4. Classification purpose. State the policy decision for which the role is tested; do not let one universal business label decide unrelated actions.
  5. Commercial-service predicate. Record the bounded external service class asserted, without importing an entire private product catalogue into policy.
  6. Internet-Registry predicate. State whether the organization distributes number resources and registers those distributions, with a protected evidence reference.
  7. Direct-allocation state. Distinguish none, requested, approved, issued, returned, revoked and replaced, tied to the resource event.
  8. Downstream-delegation function. Record whether reallocation or reassignment occurs, the recipient class and the controlling clause.
  9. Internal-infrastructure use. Keep the organization's own bounded use distinct from customer distribution.
  10. Membership state. Record non-member applicant, Service, General, General in Good Standing or Trustee under the relevant rule; never infer voting power from a resource role.
  11. Agreement and authority state. Bind RSA or LRSA coverage and authorized organizational role to protected evidence without publishing authority documents.
  12. Applicable policy path. Name the exact clauses, qualification tests and exclusions selected by the verified resource function.
  13. Term-occurrence crosswalk. For each consequential occurrence, store old term, new term, section, surface and a bounded semantic-effect code.
  14. Implementation binding. Connect the policy meaning to the matching public guide, staff guidance, training, application field and test-vector version.
  15. Outcome, explanation and correction. Preserve decisive predicates, result, review path, later role transition and correction history.
  16. Privacy-safe aggregate projection. Publish request-path counts, classification changes, form-version mismatches and corrections without applicant names or product secrets.

This is not a demand for a particular implementation design. It is the minimum information another reviewer needs to replay why one policy path applied.

The common layer should know the function, not design the company

The Minimum Initial Specification provides the boundary. Shared coordination should be strict about the deterministic facts it needs for uniqueness, interoperability, proof, safety and security. It should leave business arrangements, institutional ambition and discretionary preference outside that common layer.

Here, common facts include organization identity, vocabulary version, resource lifecycle, downstream-delegation function, applicable rule and recorded state transition. Protected evidence can establish agreement and authority. A public aggregate can show how often request paths changed or forms disagreed.

Product mix remains local. The registry does not need to decide whether web hosting is the operator's main business, whether a VPN is packaged with access, which hypervisor runs a VPS, which router serves a colocation floor or how a university organizes departments. Those facts matter only when a named policy predicate makes them relevant.

Minimum does not mean vague. A small role definition should be stricter than an open list of services precisely because it claims less jurisdiction over the company.

Sources

What the evidence does not show

No source in this packet identifies a real organization that ARIN placed in the wrong request path because of ISP/LIR terminology. No source measures extra tickets, delay, denials or changed allocation size. No source exposes current internal application fields, staff training or complete classification logic.

The evidence therefore supports a textual finding and a migration recommendation. It does not support a misconduct claim or an incidence estimate.

Nor does it predict the policy outcome. ARIN-2025-1 remains under discussion. A new version can restore a direct set link, remove the subset claim, choose LIR alone or redesign the definitions. A fresh staff review can bind itself to that new object. Those would be new facts, not confirmation of today's inference.