[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR definitions and references to address ambiguity in NRPM text

Wed Mar 19 23:36:20 EDT 2025

Why can’t there be a redline now?

On Wed, Mar 19, 2025 at 23:15 Douglas Camin <doug at dougcamin.com> wrote:

> Martin -
>
> To make this readable via plaintext formats, when I originally wrote it, I
> came up with the tactic of adding an underscore character before and after
> every change inline. This seemed easier to see the changes instead of
> making two large text blocks with no easy way to identify what was altered
> when it mostly was adding “LIR” or “ISP” to the various references.
>
> Hope that helps (and as Kat said, there will be a redline at ARN55.)
>
>
> Doug
>
>
>
>
>
> --
>
> Douglas J. Camin
>
> doug at dougcamin.com
> From: ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Martin Hannigan
> <hannigan at gmail.com>
> Date: Wednesday, March 19, 2025 at 11:04 PM
> To: ARIN <info at arin.net>
> Cc: arin-ppml at arin.net <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
>
>
> A redline would be useful and easier to understand the ask accompanying
> such a large post.
>
> Warm regards,
>
> -M<
>
>
>
> On Wed, Mar 19, 2025 at 16:22 ARIN <info at arin.net> wrote:
>
>> The following Draft Policy has been revised:
>>
>> *Draft Policy 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/
>>
>> 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 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,
>> removing an ambiguous word and clarification on usage for the term LIR,
>> removing an ambiguous terminology statement in Section 6.5.1a, and changing
>> terms in Section 6.5 to explicitly state it applies to “LIR/ISP,” thus
>> fulfilling the original intent of 6.5.1a, in all appropriate locations.
>>
>> 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.
>>
>> Add definition for ISP:
>>
>> 2.18 Internet Service Provider
>>
>> An Internet Service Provider (ISP) is a type of LIR 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]”
>>
>> Change all references in section 6.5 to use LIR/ISP, where appropriate:
>>
>> [Editing note: For the purposes of clarity in plaintext communication
>> mediums, any addition of LIR or ISP 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 add ISP and LIR in 15 locations
>>
>> 6.5.2. Initial Allocation to LIRs_/ISPs_
>>
>> 6.5.2.1. Size
>>
>> 1. All allocations shall be made on nibble boundaries.
>>
>> 2. In no case shall an LIR_/ISP_ receive smaller than a /32 unless they
>> specifically request a /36 or /40. In order to be eligible for a /40, an
>> _LIR/_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 _LIR/_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/3serving sites and Y is a multiple of 4 greater than 4/3end 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 LIR_/ISP_ which has
>> subordinate LIRs_/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 LIR_/ISP_. LIRs_/ISPs_ which do not receive
>> resources directly from ARIN will not be able to make such reallocations to
>> subordinate LIRs_/ISPs_ and subordinate LIRs_/ISPs_ which need more than a
>> /32 shall apply directly to ARIN.
>>
>> 6. An LIR_/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 LIR_/ISP_ is entitled.
>>
>> 7. An LIR_/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 LIR_/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 _LIR/_ISP’s current or former
>> IPv4 address holdings.
>>
>> Amend Section 6.5.2.2 to add LIR in 2 locations:
>>
>> 6.5.2.2. Qualifications
>>
>> An organization qualifies for an allocation under this policy if they
>> meet any of the following criteria:
>>
>> 1. Have a previously justified IPv4 _LIR/_ISP allocation from ARIN or one
>> of its predecessor registries or can qualify for an IPv4 _LIR/_ISP
>> allocation under current criteria.
>>
>> 2. Are currently multihomed for IPv6 or will immediately become
>> multihomed for IPv6 using a valid assigned global AS number. In either
>> case, they will be making reassignments or reallocations from allocation(s)
>> under this policy to other organizations.
>>
>> 3. Provide ARIN a reasonable technical justification indicating why an
>> allocation is necessary. Justification must include the intended purposes
>> for the allocation and describe the network infrastructure the allocation
>> will be used to support. Justification must also include a plan detailing
>> anticipated reassignments and reallocations to other organizations or
>> customers for one, two and five year periods, with a minimum of 50
>> assignments within 5 years.
>>
>> Amend Section 6.5.3 to add ISP in 4 locations:
>>
>> 6.5.3. Subsequent Allocations to LIRs_/ISPs_
>>
>> 1. Where possible ARIN will make subsequent allocations by expanding the
>> existing allocation.
>>
>> 2. An LIR_/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
>> LIR_/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 LIR_/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 add ISP in 1 location:
>>
>> 6.5.4.1. Reassignment to Operator’s Infrastructure
>>
>> An LIR_/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.5 to add LIR in 1 location:
>>
>> 6.5.5. Registration
>>
>> _LIRs/_ISPs 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.
>>
>> Amend Section 6.5.5.4 to add LIR in 1 location:
>>
>> 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 _LIR/_ISP shall register that assignment as described in
>> section 6.5.5.1.
>>
>> Amend Section 6.5.7 to add ISP in 1 location:
>>
>> 6.5.7. Existing IPv6 Address Space Holders
>>
>> LIRs_/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.9 to add LIR and ISP in 2 locations:
>>
>> 6.5.9. Community Network Allocations
>>
>> While community networks would normally be considered to be LIR/ISP type
>> organizations under existing ARIN criteria, they tend to operate on much
>> tighter budgets and often depend on volunteer labor. As a result, they tend
>> to be much smaller and more communal in their organization rather than
>> provider/customer relationships of commercial ISPs. This section seeks to
>> provide a policy that is more friendly to those environments by allowing
>> community network to receive a smaller allocation than other LIRs or
>> commercial ISPs. Community networks may also qualify under section 6.5.2 as
>> a regular LIR/ISP.
>>
>> Amend Section 6.5.9.2 to add ISP in 1 location:
>>
>> 6.5.9.2. Allocation Size
>>
>> Community networks are eligible only to receive an allocation of /40 of
>> IPv6 resources under this section. Community networks that wish to receive
>> a larger initial allocation or any subsequent allocations must qualify as a
>> regular LIR_/ISP_, see sections 6.5.2 or 6.5.3 respectively.
>>
>> Amend Section 6.5.9.3 to add ISP in 1 location:
>>
>> 6.5.9.3. Reassignments by Community Networks
>>
>> Similar to other LIRs_/ISPs_, Community networks shall make reassignments
>> to end-users in accordance with applicable policies, in particular, but not
>> limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate
>> resources under this section.
>>
>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250319/4dc51751/attachment-0001.htm>