I agree with what's been said thus far, but I want to propose a (potentially) radical idea: Do we need to define ISP/LIR/End User at all? Why not have 2 available pathways to justifying a request, and the requesting organization can just choose whichever is most appropriate for themselves?
Tyler On Sun, 2025-09-14 at 09:11 -0500, David Farmer via ARIN-PPML wrote: > The layman's definition of the term ISP (Internet Service Provider) is a > company that provides individuals and businesses with access to the internet > and related services, such as email and web hosting. ISPs facilitate your > connection to the global network, using various technologies like fiber optic, > cable, DSL, and satellite to deliver their services. Major examples of ISPs > include Comcast (Xfinity), Verizon, and AT&T. > > John, the technical definition you provided makes sense from an ARIN Policy > perspective. However, that is not the definition provided for ISP by this > policy. The definition provided in this policy is more like the layman's > definition. > > I think the question the ARIN community needs to ask itself is, "Do all ARIN > customers that request resources on the basis of the needs of their customers, > and not the needs of their own organization, want to be known as an ISP?" Many > organizations that qualify for this technical definition we are talking about > don't think of themselves as ISPs. > > As Owen said, "All ISPs are LIRs, but not all LIRs are ISPs." Or, maybe at > least all LIRs don't want to be considered as ISPs. This policy effectively > says they are ISPs regardless of what they think themselves to be. > > Attempting to make LIR and ISP have precisely the same meaning, and > eliminating the term LIR, is an oversimplification and will eliminate > important nuance of the current policy. > > I don't support the policy as written. > > Thanks. > > On Sat, Sep 13, 2025 at 11:54 PM John Sweeting <[email protected]> wrote: > > 2 points of clarification: > > > > If you need to use customers to justify your needs requirements then you are > > considered an ISP. > > > > Everyone receives allocations now so even end users can use > > Reassignments/reallocations if they require that service. > > > > No input on the policy, just clarifications. > > > > > > > > > > Sent from my iPhone > > > > > On Sep 13, 2025, at 9:39 PM, Owen DeLong via ARIN-PPML > > > <[email protected]> wrote: > > > > > > There are many ways to structure Colo and cloud services that need to be > > > LIRs but might not meet the definition of ISP. > > > > > > Certain large enterprises need to act as LIRs but don’t have external > > > customers and thus might not meet the definition of ISP. > > > > > > I’m sure there are others, but these are the obvious ones that come to > > > mind. > > > > > > Owen > > > > > > > > > > On Sep 13, 2025, at 11:17, Jon Lewis <[email protected]> wrote: > > > > > > > > Maybe I'm not thinking creatively enough, but can someone give an > > > > example of how an ARIN member would qualify for direct allocations from > > > > ARIN and operate as an LIR, but not be an ISP? > > > > > > > > > > On Sat, 13 Sep 2025, Martin Hannigan wrote: > > > > > > > > > > Hi Owen, > > > > > What is the difference between using one term or the other? Would it > > > > > make sense to consolidate to plain language and ubiquitous ISP? > > > > > Thanks, > > > > > Martin > > > > > > On Sat, Sep 13, 2025 at 11:40 AM Owen DeLong via ARIN-PPML > > > > > > <[email protected]> wrote: > > > > > I think this is the wrong approach. > > > > > > > > > > In reality, ARIN cares about LIRs and deals with LIRs and end > > > > > users. It is generally irrelevant from a policy perspective whether a > > > > > given LIR is an ISP or not. > > > > > > > > > > Therefore, IMHO, a better approach would be to simply consolidate > > > > > to the LIR term and eliminate ISP from the NRPM. > > > > > > > > > > IPv6 policy already explicitly declares that the terms are > > > > > interchangeable from a policy perspective. > > > > > > > > > > Owen > > > > > > > > > > > On Sep 12, 2025, at 10:18, ARIN <[email protected]> wrote: > > > > > > > > > > > > The following Draft Policy has been revised: > > > > > > > > > > > > *ARIN-2025-1: Clarify ISP and LIR Definitions and References to > > > > > > Address Ambiguity in NRPM Text > > > > > > > > > > > > Revised text is below and can be found at: > > > > > > > > > > > > https://www.arin.net/participate/policy/drafts/2025_1/ > > > > > > > > > > > > A PDF document showing the proposed NRPM edits is available to > > > > > > download at: > > > > > > > > > > > > https://arin.net/participate/policy/drafts/pdf/ARIN_2025_1_diff_091225.pdf > > > > > > > > > > > > You are encouraged to discuss all Draft Policies on PPML. The AC > > > > > > will evaluate the discussion to assess the conformance of this Draft > > > > > > Policy with ARIN's > > > > > Principles of Internet number resource policy as stated in the > > > > > Policy Development Process (PDP). Specifically, these principles are: > > > > > > > > > > > > * Enabling Fair and Impartial Number Resource Administration > > > > > > * Technically Sound > > > > > > * Supported by the Community > > > > > > > > > > > > The PDP can be found at: > > > > > > > > > > > > https://www.arin.net/participate/policy/pdp/ > > > > > > > > > > > > Draft Policies and Proposals under discussion can be found at: > > > > > > > > > > > > https://www.arin.net/participate/policy/drafts/ > > > > > > > > > > > > Regards, > > > > > > > > > > > > Eddie Diego > > > > > > Policy Analyst > > > > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > > > > > > > > > > > Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and > > > > > > References to Address Ambiguity in NRPM Text > > > > > > > > > > > > Problem Statement: > > > > > > > > > > > > Section 2.4 of the NRPM defines an LIR but does not explicitly > > > > > > define an ISP. An ISP is defined in the context of an LIR, but the > > > > > > explicit definition is > > > > > otherwise assumed. > > > > > > > > > > > > Through implication and in common business practice, all ISPs are > > > > > > LIRs, but not all LIRs are ISPs. > > > > > > > > > > > > This proposal adds clarity by creating an explicit definition for > > > > > > ISP, clarifying the historical and out-of-region usage for the term > > > > > > LIR, and replaces LIR > > > > > with ISP throughout the NRPM as appropriate. > > > > > > > > > > > > Policy Statement: > > > > > > > > > > > > Add Internet Service Provider definition: > > > > > > > > > > > > Remove the word “primarily” from the definition of LIR and add usage > > > > > > clarification: > > > > > > > > > > > > FROM: > > > > > > > > > > > > 2.4. Local Internet Registry (LIR) > > > > > > > > > > > > A Local Internet Registry (LIR) is primarily an IR that assigns IP > > > > > > addresses to the users of the network services that it provides. > > > > > > LIRs are generally > > > > > Internet Service Providers (ISPs) whose customers are primarily > > > > > end users and possibly other ISPs. > > > > > > > > > > > > TO: > > > > > > > > > > > > 2.4. Local Internet Registry (LIR) > > > > > > > > > > > > A Local Internet Registry (LIR) is an IR that assigns IP addresses > > > > > > to the users of the network services that it provides. LIRs are > > > > > > generally Internet Service > > > > > Providers (ISPs) whose customers are primarily end users and > > > > > possibly other ISPs. _While LIR has been historically referenced in > > > > > policies for ease of comparing > > > > > other region's policies, LIR is not used in the ARIN service > > > > > region; ISP is the equivalent term._ > > > > > > > > > > > > > > > > > > Add definition for ISP: > > > > > > > > > > > > 2.18 Internet Service Provider (ISP) > > > > > > > > > > > > An Internet Service Provider (ISP) is a type of organization that > > > > > > provides Internet services to other organizations, its customers, > > > > > > and\or individuals other > > > > > than its employees. Internet services include, but are not > > > > > limited to, connectivity services, web services, colocation, dedicated > > > > > servers, virtual private > > > > > servers, and virtual private networks. > > > > > > > > > > > > > > > > > > Replace Section 6.5.1a > > > > > > > > > > > > Original Text: “The terms ISP and LIR are used interchangeably in > > > > > > this document and any use of either term shall be construed to > > > > > > include both meanings.” > > > > > > > > > > > > New Text: “[Retired]” > > > > > > > > > > > > > > > > > > Remove all references in section 6.5 of LIR where appropriate: > > > > > > > > > > > > [Editing note: For the purposes of clarity in plaintext > > > > > > communication mediums, any changes to the text is denoted with the > > > > > > underscore character before and > > > > > after the insertion. The underscore character is not considered a > > > > > part of the final text.] > > > > > > > > > > > > > > > > > > Amend Section 6.5.2 to replace LIR with ISP, 12 in total > > > > > > > > > > > > 6.5.2. Initial Allocation to _ISPs_ > > > > > > > > > > > > 6.5.2.1. Size > > > > > > > > > > > > 1. All allocations shall be made on nibble boundaries. > > > > > > > > > > > > 2. In no case shall an _ISP_ receive smaller than a /32 unless they > > > > > > specifically request a /36 or /40. In order to be eligible for a > > > > > > /40, an ISP must meet the > > > > > following requirements: > > > > > > > > > > > > - Hold IPv4 direct allocations totaling a /24 or less (to include > > > > > > zero) > > > > > > > > > > > > - Hold IPv4 reassignments/reallocations totaling a /22 or less (to > > > > > > include zero) > > > > > > > > > > > > In no case shall an ISP receive more than a /16 initial allocation. > > > > > > > > > > > > 3. The maximum allowable allocation shall be the smallest nibble- > > > > > > boundary aligned block that can provide an equally sized nibble- > > > > > > boundary aligned block to > > > > > each of the requesters serving sites large enough to satisfy the > > > > > needs of the requesters largest single serving site using no more than > > > > > 75% of the available > > > > > addresses. > > > > > > This calculation can be summarized as /N where N = P-(X+Y) and P is > > > > > > the organization’s Provider Allocation Unit X is a multiple of 4 > > > > > > greater than 4/3*serving > > > > > sites and Y is a multiple of 4 greater than 4/3*end sites served > > > > > by largest serving site. > > > > > > > > > > > > 4. For purposes of the calculation in (c), an end site which can > > > > > > justify more than a /48 under the end-user assignment criteria in > > > > > > 6.5.8 shall count as the > > > > > appropriate number of /48s that would be assigned under that > > > > > policy. > > > > > > > > > > > > 5. For purposes of the calculation in (c), an _ISP_ which has > > > > > > subordinate _ISPs_ shall make such reallocations according to the > > > > > > same policies and criteria as > > > > > ARIN. In such a case, the prefixes necessary for such a > > > > > reallocation should be treated as fully utilized in determining the > > > > > block sizing for the parent _ISP_. > > > > > _ISPs_ which do not receive resources directly from ARIN will not > > > > > be able to make such reallocations to subordinate _ISPs_ and > > > > > subordinate _ISPs_ which need > > > > > more than a /32 shall apply directly to ARIN. > > > > > > > > > > > > 6. An _ISP_ is not required to design or deploy their network > > > > > > according to this structure. It is strictly a mechanism to determine > > > > > > the largest IP address > > > > > block to which the _ISP_ is entitled. > > > > > > > > > > > > 7 An _ISP_ that requests a smaller /36 or /40 allocation is entitled > > > > > > to expand the allocation to any nibble aligned size up to /32 at any > > > > > > time without > > > > > renumbering or additional justification. /40 allocations shall be > > > > > automatically upgraded to /36 if at any time said _ISP_’s IPv4 direct > > > > > allocations exceed a > > > > > /24. Expansions up to and including a /32 are not considered > > > > > subsequent allocations, however any expansions beyond /32 are > > > > > considered subsequent allocations and > > > > > must conform to section 6.5.3. Partial returns of any IPv6 > > > > > allocation that results in less than a /36 of holding are not > > > > > permitted regardless of the ISP’s > > > > > current or former IPv4 address holdings. > > > > > > > > > > > > > > > > > > Amend Section 6.5.3 to replace LIR with ISP in 4 locations: > > > > > > > > > > > > 6.5.3. Subsequent Allocations to _ISPs_ > > > > > > > > > > > > 1. Where possible ARIN will make subsequent allocations by expanding > > > > > > the existing allocation. > > > > > > > > > > > > 2. An _ISP_ qualifies for a subsequent allocation if they meet any > > > > > > of the following criteria: > > > > > > > > > > > > - Shows utilization of 75% or more of their total address space > > > > > > > > > > > > - Shows utilization of more than 90% of any serving site > > > > > > > > > > > > - Has allocated more than 90% of their total address space to > > > > > > serving sites, with the block size allocated to each serving site > > > > > > being justified based on the > > > > > criteria specified in section 6.5.2 > > > > > > > > > > > > 3. If ARIN can not expand one or more existing allocations, ARIN > > > > > > shall make a new allocation based on the initial allocation criteria > > > > > > above. The _ISP_ is > > > > > encouraged, but not required to renumber into the new allocation > > > > > over time and return any allocations no longer in use. > > > > > > > > > > > > 4. If an _ISP_ has already reached a /12 or more, ARIN will allocate > > > > > > a single additional /12 rather than continue expanding nibble > > > > > > boundaries. > > > > > > > > > > > > > > > > > > Amend Section 6.5.4.1 to replace LIR with ISP in 1 location: > > > > > > > > > > > > 6.5.4.1. Reassignment to Operator’s Infrastructure > > > > > > > > > > > > An _ISP_ may reassign up to a /48 per PoP as well as up to an > > > > > > additional /48 globally for its own infrastructure. > > > > > > > > > > > > > > > > > > Amend Section 6.5.7 to replace LIR with ISP in 1 location: > > > > > > > > > > > > 6.5.7. Existing IPv6 Address Space Holders > > > > > > > > > > > > _ISPs_ which received an allocation under previous policies which is > > > > > > smaller than what they are entitled to under this policy may receive > > > > > > a new initial > > > > > allocation under this policy. If possible, ARIN will expand their > > > > > existing allocation. > > > > > > > > > > > > > > > > > > Amend Section 6.5.8 to remove “or other LIR” in 2 locations > > > > > > > > > > > > 6.5.8.1. Initial Assignment Criteria > > > > > > > > > > > > FROM: > > > > > > > > > > > > f. By providing a reasonable technical justification indicating why > > > > > > IPv6 addresses from an ISP or other LIR are unsuitable. > > > > > > > > > > > > TO: > > > > > > > > > > > > f. By providing a reasonable technical justification indicating why > > > > > > IPv6 > > > > > > addresses from an ISP are unsuitable. > > > > > > > > > > > > > > > > > > FROM: > > > > > > > > > > > > Examples of justifications for why addresses from an ISP or other > > > > > > LIR may be unsuitable include, but are not limited to: > > > > > > > > > > > > TO: > > > > > > > > > > > > Examples of justifications for why addresses from an ISP may be > > > > > > unsuitable include, but are not limited to: > > > > > > > > > > > > Timetable for Implementation: Immediate > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > ARIN-PPML > > > > > > You are receiving this message because you are subscribed to > > > > > > the ARIN Public Policy Mailing List ([email protected]). > > > > > > Unsubscribe or manage your mailing list subscription at: > > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > > > Please contact [email protected] if you experience any issues. > > > > > > > > > > _______________________________________________ > > > > > ARIN-PPML > > > > > You are receiving this message because you are subscribed to > > > > > the ARIN Public Policy Mailing List ([email protected]). > > > > > Unsubscribe or manage your mailing list subscription at: > > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > > Please contact [email protected] if you experience any issues. > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > Jon Lewis, MCP :) | I route > > > > Blue Stream Fiber, Sr. Neteng | therefore you are > > > > _________ http://www.lewis.org/~jlewis/pgp for PGP public > > > > key________________________________________________________ > > > > ARIN-PPML > > > > You are receiving this message because you are subscribed to > > > > the ARIN Public Policy Mailing List ([email protected]). > > > > Unsubscribe or manage your mailing list subscription at: > > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact [email protected] if you experience any issues. > > > > > > _______________________________________________ > > > ARIN-PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List ([email protected]). > > > Unsubscribe or manage your mailing list subscription at: > > > https://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact [email protected] if you experience any issues. > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
