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

[Martin Hannigan]

You could put a redline on a variety a clouds and do a referral URL.


On Wed, Mar 19, 2025 at 23:51 Kat Hunter <takokat81 at gmail.com> wrote:

> Many in the community have email set to plain text only. For the benefit
> of the entire community we try to not send email that is unreadable by
> adding redline.
>
> Kat
>
> On Wed, Mar 19, 2025, 11:36 PM Martin Hannigan <hannigan at gmail.com> wrote:
>
>> 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.
>>>
>> _______________________________________________
>> 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/20250320/617ae19d/attachment-0001.htm>