I think the main goal (at least from my perspective) is to avoid making the policy more restrictive through unintended consequences of new definitions. I think clarity is a close second to that.
Owen > On Sep 16, 2025, at 15:27, Mohibul Mahmud <[email protected]> wrote: > > Hello Team, > > It seems most of us agree that clarity is the main goal. Would it make sense > to keep one preferred term in the NRPM, but also add a short note in the > definitions section that explains how ISP and LIR are used interchangeably in > ARIN policy? > > Best > Mohibul Mahmud > Microsoft > ARIN Advisory Council Candidate > > > > On Tue, Sep 16, 2025 at 3:54 PM Owen DeLong via ARIN-PPML <[email protected] > <mailto:[email protected]>> wrote: >> Precisely what David said. I prefer LIR since I think ISP is over-specific >> in its vernacular usage and LIR is the more accurate term for what ARIN is >> actually doing. However, I can live with either if the NRPM definition of >> whichever term is used matches the general meaning of LIR. >> >> The policy as written would disqualify several, if not many legitimate users >> of IP addresses. >> >> Owen >> >> >>> On Sep 16, 2025, at 11:58, David Farmer <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> Leif. >>> >>> If the ARIN community wants to use the term "ISP" instead of "LIR", I can >>> accept that. However, the definition for "ISP" provided in the draft policy >>> focuses on the types of services the ISP provides, which are mostly >>> irrelevant from an ARIN Policy perspective. The current definition of LIR >>> focuses on the relationship between users/customers and the LIR/ISP. I >>> would call your attention to the definition John Seeeting provided or the >>> definition of LIR in RFC 7020. They focus on what is important from an ARIN >>> Policy perspective: the relationship between the LIR/ISP and its >>> users/customers, and the relationship with the RIR. If the definition >>> provided focuses on the important aspects of ARIN policy, the term used >>> will be unimportant; LIR and ISP can be used interchangeably. But that is >>> not the case for the provided definition of ISP in the draft policy. >>> >>> Thanks. >>> >>> On Tue, Sep 16, 2025 at 1:11 PM Leif Sawyer via ARIN-PPML >>> <[email protected] <mailto:[email protected]>> wrote: >>>> Owen – >>>> >>>> >>>> >>>> This latest update is a result of the April ARIN meeting, where the >>>> overwhelming message was to “remove LIR” and use ISP, since that’s what >>>> >>>> Is used both internally by ARIN, and predominantly within this region. >>>> >>>> >>>> >>>> Note that the changes proposed are for section 6, to normalize it against >>>> the remainder of the NRPM’s use of ISP. >>>> >>>> >>>> >>>> -L >>>> >>>> >>>> >>>> Leif Sawyer >>>> >>>> GCI | he/him | Engineer, CNI – Standards and Planning >>>> >>>> t: 907-351-1535 | w: www.gci.com <https://www.gci.com/> | KL5BN >>>> >>>> >>>> >>>> From: ARIN-PPML <[email protected] >>>> <mailto:[email protected]>> On Behalf Of Owen DeLong via ARIN-PPML >>>> Sent: Saturday, September 13, 2025 7:39 AM >>>> To: ARIN <[email protected] <mailto:[email protected]>> >>>> Cc: [email protected] <mailto:[email protected]> >>>> Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP >>>> and LIR Definitions and References to Address Ambiguity in NRPM Text >>>> >>>> >>>> >>>> [EXTERNAL EMAIL - CAUTION: Do not open unexpected attachments or links.] >>>> >>>> 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] <mailto:[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/ >>>> > <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/ >>>> > <https://www.arin.net/participate/policy/pdp> >>>> > >>>> > Draft Policies and Proposals under discussion can be found at: >>>> > >>>> > https://www.arin.net/participate/policy/drafts/ >>>> > <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 <http://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 <http://6.5.4.1/> to replace LIR with ISP in 1 >>>> > location: >>>> > >>>> > 6.5.4.1 <http://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 <http://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] >>>> > <mailto:[email protected]>). >>>> > Unsubscribe or manage your mailing list subscription at: >>>> > https://lists.arin.net/mailman/listinfo/arin-ppml >>>> > Please contact [email protected] <mailto:[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] >>>> <mailto:[email protected]>). >>>> Unsubscribe or manage your mailing list subscription at: >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] <mailto:[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] >>>> <mailto:[email protected]>). >>>> Unsubscribe or manage your mailing list subscription at: >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] <mailto:[email protected]> if you experience any >>>> issues. >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:[email protected] >>> <mailto: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] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] <mailto:[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.
