[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text

[Dale W. Carder]

Thus spake Jay Moran via ARIN-PPML (arin-ppml at arin.net) 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 <
> arin-ppml at arin.net> 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 <arin-ppml-bounces at arin.net> *On Behalf Of *Owen DeLong
> > via ARIN-PPML
> > *Sent:* Wednesday, September 17, 2025 8:22 AM
> > *To:* Jay Moran <jay-ARIN at tp.org>
> > *Cc:* arin-ppml at arin.net
> > *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 <
> > arin-ppml at arin.net> 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 <
> > arin-ppml at arin.net> 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 <mohibul.mahmud at gmail.com>
> > 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 <
> > arin-ppml at arin.net> 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 <farmer at umn.edu> 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 <
> > arin-ppml at arin.net> 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 <arin-ppml-bounces at arin.net> *On Behalf Of *Owen DeLong
> > via ARIN-PPML
> > *Sent:* Saturday, September 13, 2025 7:39 AM
> > *To:* ARIN <info at arin.net>
> > *Cc:* arin-ppml at arin.net
> > *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 <info at arin.net> 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 (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > David Farmer               Email:farmer at umn.edu
> > 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 (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > David Farmer               Email:farmer at umn.edu
> > 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 (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >

> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.