Thus spake Jay Moran via ARIN-PPML ([email protected]) on Fri, Sep 19, 2025 at 03:18:46PM -0400: > Thank you, Leif. Good information. I think you said that it would be hard > to get Hank Williams, Jr. to re-record his song to say "Are you ready for > somet American Football!!!" So, we'll keep using ISP. > > I'm okay with the switch to ISP and the footnote about the LIR term being > equivalent - essentially what Mohibul said quoted below. I think we should > also add another footnote and state that American's term "Soccer" is also > equal to the other 7.5+ BILLION people in the world's Football. ;-) > > "To bridge this, I’d suggest we converge on a practical editorial approach: > > • Select one preferred term for the NRPM (ISP or LIR). > > • Add a clear definition note stating that ISP and LIR are can be used > interchangeably in ARIN policy." > > My company still is NOT the commonly accepted definition of ISP, and we > will STILL allocate address space to our customers for various reasons, so > I guess we're also this special use of the term ISP.
This would be the problem I have as well. ISP is overloaded with varying colloquial usage, particularly with an interdependence with customers, commerce having transpired, or even that Internet service is a line of business. From a policy perspective I think it's problematic to reign "ISP" in vs migrate to LIR as a term of art and work to define how it operates within this region. Dale > On Fri, Sep 19, 2025 at 2:53 PM Leif Sawyer via ARIN-PPML < > [email protected]> wrote: > > > Hi Owen (et al) – > > > > > > > > Apologies if this is a little scattered, but I’m trying to summarize > > everything that’s happened on the back end and front end. > > > > > > > > > > > > Internally, ARIN uses ISP (or end-user) nearly universally for all > > communications, back-end terminology, documentation, and business-practices. > > > > > > > > It DOES, however, use LIR/ISP in the IP request flow ( > > https://account.arin.net/public/secure/resources/request/ip) with the > > following definition: > > > > > > > > “An LIR/ISP (Local Internet Registry or Internet Service Provider) is an > > 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 hosting services, colocation, dedicated servers, virtual > > private servers, and virtual private networks.” > > > > > > > > We can align the definitions in the NRPM to match the line above, noting > > that LIR is a term not used in this region but is operationally equivalent > > here. > > > > > > > > Since it’s beyond the scope of a policy proposal to change the business of > > ARIN ( back-end programming, databases, etc ) to move to “LIR” as the > > industry-standard term of art (rather than ISP) > > > > it would require following the ACSP – so that everyone can weigh in on > > whether the cost/effort/desire to implement is community supported. > > Alongside the policy changes, of course. > > > > > > > > Since using the conjoined term “LIR/ISP” was shot down at ARIN55 , and > > since LIR isn’t used in region, the move to “ISP” as the single term was > > proposed for the Section 6 corrections, in order to match the remaining > > sections of the NRPM. (converting to LIR impacts the entirety of the NRPM) > > > > > > > > Note also that all of this stems from the Section 6 global policy > > inclusion not correcting the [ LIR==ISP ] “applies to this document” > > statement into “applies to this section” when it was imported after > > approval. > > > > > > > > My personal question: Outside of limited scope of people who work with > > directly with the outside-region registry systems, is there any other > > compelling reason to move to LIR in this region, given the amount of work > > involved in re-education and retooling? > > > > > > > > > > > > I hope that helps reframe and clarify the work that’s happening here, and > > keeps this discussion moving! > > > > > > > > -Leif > > > > > > > > *Leif Sawyer* > > > > *GCI* | he/him | Engineer, CNI – Standards and Planning > > > > *t:* 907-351-1535 | *w:* www.gci.com | KL5BN > > > > > > > > *From:* ARIN-PPML <[email protected]> *On Behalf Of *Owen DeLong > > via ARIN-PPML > > *Sent:* Wednesday, September 17, 2025 8:22 AM > > *To:* Jay Moran <[email protected]> > > *Cc:* [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.] > > > > Exactly what Jay said. David’s definitions are livable, but why not join > > the rest of the world in using globally accepted terminology rather than > > contorting the definition of ISP because we can. It kind of reminds me of > > the US still using imperial units while the rest of the world moved on to > > SI (metric) long ago. > > > > > > > > Owen > > > > > > > > > > > > On Sep 17, 2025, at 05:18, Jay Moran (AOL) via ARIN-PPML < > > [email protected]> wrote: > > > > > > > > I can live with that definition; it covers the description of my > > organization as written. However I believe that goes against the commonly > > understood definition of an ISP. > > > > > > > > I’ll state one last time that LIR seems fine, and just because we in the > > “American Region” don’t normally use or “like” the term/acronym LIR, > > doesn’t make it any less accurate… or globally accepted where the majority > > of humans live. > > > > > > > > For now, I am going to go watch some football. ;-) > > > > > > > > > > -- > > Jay Moran > > http://linkedin.com/in/jaycmoran > > > > > > > > > > > > On Wed, Sep 17, 2025 at 7:27 AM David Farmer via ARIN-PPML < > > [email protected]> wrote: > > > > I suggest the following revised definitions for LIR and ISP; > > > > > > > > 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, other > > organizations, or possibly other ISPs. LIR is the term used for an ISP in > > the context of the Internet Registry System, defined in RFC 7020 and in the > > diagram at the beginning of this section. > > > > > > > > 2.18 Internet Service Provider (ISP) > > > > > > > > An Internet Service Provider (ISP) is any organization that provides > > Internet services to its customers, who are primarily end users > > (individuals other than employees or visitors to a premises), other > > organizations, or possibly other ISPs. The specific Internet services are > > irrelevant; the important aspect is that Internet Number Resources are > > consumed and justified by assigning them to customers. ISP is the term used > > in the context of ARIN Policy, instead of Local Internet Registry (LIR). > > > > > > > > Thanks. > > > > > > > > > > > > On Tue, Sep 16, 2025 at 5:28 PM 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]> 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]> 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]> 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 | KL5BN > > > > > > > > *From:* ARIN-PPML <[email protected]> *On Behalf Of *Owen DeLong > > via ARIN-PPML > > *Sent:* Saturday, September 13, 2025 7:39 AM > > *To:* ARIN <[email protected]> > > *Cc:* [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]> 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. > > > > _______________________________________________ > > 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 > > <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g> > > 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. > > > > > > > > > > -- > > > > =============================================== > > David Farmer Email:[email protected] > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE > > <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g> > > 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. > > > > _______________________________________________ > > 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.
