I’m fully in support of this language and transitioning the to LIR language across the board as has been written in the latest draft.
Preston Ursini > On May 18, 2026, at 2:13 PM, [email protected] wrote: > > Send ARIN-PPML mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR > Definitions and References to Address Ambiguity in NRPM Text > (Leif Sawyer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 18 May 2026 19:13:17 +0000 > From: Leif Sawyer <[email protected]> > To: Matthew Cowen <[email protected]>, "[email protected]" > <[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 > Message-ID: > > <sa1pr18mb57439d010d47863aa45cbf83bf...@sa1pr18mb5743.namprd18.prod.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > Ack! > > I thought I purged that. Dang. Well, I?ll figure out a way to get that > addressed in the submission especially if it?s editorally moot. > > Leif Sawyer > GCI | he/him | Engineer IV, CNI ? Standards and Planning > t: 907-351-1535 | w: www.gci.com<https://www.gci.com> | KL5BN > > From: ARIN-PPML <[email protected]> On Behalf Of Matthew Cowen via > ARIN-PPML > Sent: Monday, May 18, 2026 11:03 AM > To: [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.] > > Hi Leif, > > A suggestion was made by a couple of us to drop ?at a local level? in 2.4. Is > it needed? (Unless we mean local to earth ?) > > My best, > > > On 18 May 2026, at 14:38, Leif Sawyer via ARIN-PPML > <[email protected]<mailto:[email protected]>> wrote: > > I guess this isn?t as much fun as TIPTOP, but hopefully the minor changes > help with readability (i.e., expanding the first use of acronyms in > paragraphs, removing broken parentheticals, etc) > > Any last concerns from the community before we ship this off to staff and > legal review? > > -L > > Leif Sawyer > GCI | he/him | Engineer IV, 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 > ARIN > Sent: Thursday, May 7, 2026 1:01 PM > To: [email protected]<mailto:[email protected]> > Subject: [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.] > > 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_050726.pdf<https://arin.net/participate/policy/drafts/pdf/ARIN_2025_1_diff_050726.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 > reframing and aligning with the term LIR, and replaces ISP with LIR > throughout the NRPM as appropriate. > > Policy Statement: > > Update the Table of Contents, replacing ISP with Local Internet Registries as > follows: > > 4.2. Allocations to Local Internet Registries > > 4.2.2. Initial Allocation to Local Internet Registries > > 4.2.3.4.2. Downstream Local Internet Registries > > 4.2.4. Local Internet Registry Additional Requests > > 6.5.4. Reassignments from Local Internet Registries > > > > Section 2: > > Rewrite the LIR definition to provide clarity and relationship to ISP > > 2.4. Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is an Internet Registry that is a member of > an RIR, receives allocations of internet numbers from that RIR, for > allocation to its customers, end-users, and infrastructure, at a local level. > LIRs include Internet Service Providers (ISPs) whose customers are primarily > end users and possibly other ISPs. Historically in the ARIN service region > "ISP" was used as an equivalent, albeit incomplete, term. > > > > Replace ISP with Local Internet Registry: > > 2.15. Provider Assignment Unit (IPv6) > > When applied to IPv6 policies, the term ?provider assignment unit? shall mean > the prefix of the smallest block a given Local Internet Registry assigns to > end sites (recommended /48). > > > > Add new 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. > > > > Section 3: > > Replace first ISP with Local Internet Registry, remaining with LIR > > This policy applies to every Organization that has Internet number resources > issued by ARIN (or one of its predecessor registries) or a reallocation from > an upstream Local Internet Registry. This includes but is not limited to > upstream LIRs and their downstream LIR customers, but not reassignments made > to their downstream end user customers. > > > > Section 4: > > Replace ISP with Local Internet Registry: in the following sections: > > 4.2. Allocations to Local Internet Registries (Requirements for Requesting > Initial Address Space) > > > > 4.2.1.1<http://4.2.1.1/>. Purpose > > ARIN allocates blocks of IP addresses to Local Internet Registries for the > purpose of reassigning and reallocating that space to their customers. > > > > 4.2.1.5<http://4.2.1.5/>. Minimum Allocation > > In general, ARIN allocates /24 and larger IP address prefixes to Local > Internet Registries. If allocations smaller than /24 are needed, LIRs should > request address space from their upstream provider. > > > > 4.2.2. Initial Allocation to LIRs > > All Local Internet Registry organizations without any IPv4 addresses from > ARIN automatically qualify for an initial allocation of a /24. LIRs providing > a 24-month utilization plan for the request size specified may receive up to > a /22. LIRs holding reallocations and/or reassignments must show the > efficient utilization of their resources consistent with the requirements in > sections 4.2.3 and 4.2.4. > > > > 4.2.3.1<http://4.2.3.1/>. Efficient Utilization > > Local Internet Registries are required to apply a utilization efficiency > criterion in providing address space to their customers. To this end, LIRs > should have documented justification available for each reassignment and > reallocation. ARIN may request this justification at any time. If > justification is not provided, future receipt of allocations may be impacted. > > > > 4.2.3.2<http://4.2.3.2/>. VLSM > > To increase utilization efficiency of IPv4 address space, Local Internet > Registries reassigning IP address space to their customers should require > their customers to use variable length subnet mask (VLSM) and classless > technologies (CIDR) within their networks. LIRs should issue blocks smaller > than /24 wherever feasible. > > > > 4.2.3.3<http://4.2.3.3/>. Contiguous Blocks > > IP addresses are allocated to Local Internet Registries in contiguous blocks, > which should remain intact. Fragmentation of blocks is discouraged. To avoid > fragmentation, LIRs are encouraged to require their customers to return > address space if they change LIRs. Therefore, if a customer moves to another > service provider or otherwise terminates a contract with an LIR, it is > recommended that the customer return the network addresses to the LIR and > renumber into the new provider's address space. The original LIR should allow > sufficient time for the renumbering process to be completed before requiring > the address space to be returned. > > > > 4.2.3.4<http://4.2.3.4/>. Downstream Customer Adherence > > Local Internet Registries must require their downstream customers to adhere > to the following criteria: > > > > 4.2.3.4.1. Utilization > > A downstream customer requesting address space from an upstream Local > Internet Registry must document a plan to the allocating LIR for their > utilization to conform to Section 4.3.3. Reassignment and reallocation > information for prior allocations must show that each customer meets the 80% > utilization criteria and must be available via SWIP / a distributed service > which meets the standards set forth in section 3.2 prior to issuing them > additional space. > > > > 4.2.3.4.2. Downstream Local Internet Registries > > Customers must follow ARIN policy for Local Internet Registries. > > > > 4.2.3.6<http://4.2.3.6/>. Reassignments to Multihomed Downstream Customers > > If a downstream customer has a requirement to multihome, that requirement > alone will serve as justification for a /24 allocation. Downstream customers > must provide contact information for all of their upstream providers to the > Local Internet Registry from whom they are requesting a /24, and utilize a > border routing protocol between the customer and the LIR. Customers may > receive a /24 from only one of their upstream providers under this policy > without providing additional justification. LIRs may demonstrate they have > made an assignment to a downstream customer under this policy by supplying > ARIN with the information they collected from the customer, as described > above, or by identifying the AS number of the customer. > > > > 4.2.3.7<http://4.2.3.7/>. Registration > > Local Internet Registries are required to demonstrate efficient use of IP > address space allocations by providing appropriate documentation, including > but not limited to assignment histories, showing their efficient use. > > > > 4.2.3.8<http://4.2.3.8/>. Reassignments for Third Party Internet Access > (TPIA) over Cable > > IP addresses reassigned by a Local Internet Registry to an incumbent cable > operator for use with Third Party Internet Access (TPIA) will be counted as > fully used once they are assigned to equipment by the underlying cable > carrier provided they meet the following requirements: > > > > 4.2.4. Local Internet Registry Additional Requests > > > 4.2.4.1<http://4.2.4.1/>. Utilization Percentage (80%) > > Local Internet Registries must have efficiently utilized all allocations, in > aggregate, to at least 80% and at least 50% of every allocation in order to > receive additional space. This includes all space reassigned or reallocated > to their customers. > > > > 4.2.4.3<http://4.2.4.3/>. Request Size > > Local Internet Registries may request up to a 24-month supply of IPv4 > addresses. > > > > Section 6: > > Update terminology section to reference how Internet Service Provider and > Local Internet Registry are used > > 6.5.1. Terminology > > a. The terms Internet Service Provider and Local Internet Registry were > previously used interchangeably in this section. Unless otherwise noted, the > term ISP is treated as a subset of LIR. > > > > Replace ISP with Local Internet Registry in the following sections: > > 6.5.2.1<http://6.5.2.1/> Size > > a. All allocations shall be made on nibble boundaries. > > b. In no case shall a Local Internet Registry receive smaller than a /32 > unless they specifically request a /36 or /40. In order to be eligible for a > /40, an LIR 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 LIR receive more than a /16 initial allocation. > > g. A Local Internet Registry 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 LIR?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 LIR?s current or former IPv4 address holdings. > > > > 6.5.2.2<http://6.5.2.2/>. Qualifications > > An organization qualifies for an allocation under this policy if they meet > any of the following criteria: > > a. Have a previously justified IPv4 allocation from ARIN or one of its > predecessor registries or can qualify for an IPv4 allocation under current > criteria. > > > > 6.5.4. Reassignments from Local Internet Registries > > 6.5.5. Registration > > Local Internet Registries are required to demonstrate efficient use of IP > address space allocations by providing appropriate documentation, including > but not limited to reassignment and reallocation histories, showing their > efficient use. > > > > 6.5.5.4<http://6.5.5.4/>. Registration Requested by Recipient > > If the downstream recipient of a static assignment of /64 or more addresses > requests publishing of that assignment in ARIN?s registration database, the > Local Internet Registry shall register that assignment as described in > section 6.5.5.1<http://6.5.5.1/>. > > > > 6.5.8.1<http://6.5.8.1/>. Initial Assignment Criteria > > f. By providing a reasonable technical justification indicating why IPv6 > addresses from a Local Internet Registry are unsuitable. > > > _______________________________________________ > 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<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<https://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact [email protected]<mailto:[email protected]> if you experience any > issues. > > > ? > My best/Cordialement, > > Matthew Cowen > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.arin.net/pipermail/arin-ppml/attachments/20260518/e6b3e792/attachment.htm> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > [email protected] > https://lists.arin.net/mailman/listinfo/arin-ppml > > > ------------------------------ > > End of ARIN-PPML Digest, Vol 251, Issue 12 > ****************************************** _______________________________________________ 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.
