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 <[email protected]> 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 <[email protected]> wrote: > >> 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. >> >
_______________________________________________ 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.
