Why can’t there be a redline now? On Wed, Mar 19, 2025 at 23:15 Douglas Camin <[email protected]> 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 > > [email protected] > From: ARIN-PPML <[email protected]> on behalf of Martin Hannigan > <[email protected]> > Date: Wednesday, March 19, 2025 at 11:04 PM > To: ARIN <[email protected]> > Cc: [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 > > > 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 <[email protected]> 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 ([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.
