<div dir="ltr">We have a similar discussion on redlining already with the comms team at ARIN from the AC and are trying to work on options. This does involve some additional work by ARIN staff and potentially a suggestion to make improvements to the policy section. The AC does agree some of these larger policies can be very difficult to parse through without the redline. We will continue to work with Hollis and team to see what our path forward is for this. <div><br></div><div>Kat Hunter</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 20, 2025, 12:06 AM Martin Hannigan <<a href="mailto:hannigan@gmail.com" target="_blank">hannigan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div dir="auto">You could put a redline on a variety a clouds and do a referral URL.</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025 at 23:51 Kat Hunter <<a href="mailto:takokat81@gmail.com" rel="noreferrer" target="_blank">takokat81@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">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. </p>
<p dir="ltr">Kat</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025, 11:36 PM Martin Hannigan <<a href="mailto:hannigan@gmail.com" rel="noreferrer" target="_blank">hannigan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Why can’t there be a redline now?</div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025 at 23:15 Douglas Camin <<a href="mailto:doug@dougcamin.com" rel="noreferrer noreferrer" target="_blank">doug@dougcamin.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
Martin - </div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
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. </div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
Hope that helps (and as Kat said, there will be a redline at ARN55.)</div></div><div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt">
Doug</div>
<div dir="ltr"><br>
</div>
<div id="m_1089003838121372220m_5575025360515702337m_1511886498576701349m_2501752780309580549m_-4337537569496484669ms-outlook-mobile-signature">
<div>
<div>
<p style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u style="font-family:Calibri,sans-serif"></u> <u style="font-family:Calibri,sans-serif"></u></p>
<p style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u style="font-family:Calibri,sans-serif"></u> <u style="font-family:Calibri,sans-serif"></u></p>
<p style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">--<u style="font-family:Calibri,sans-serif"></u><u style="font-family:Calibri,sans-serif"></u></p>
<p style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Douglas J. Camin<u style="font-family:Calibri,sans-serif"></u><u style="font-family:Calibri,sans-serif"></u></p>
<p style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="mailto:doug@dougcamin.com" style="font-family:Calibri,sans-serif" rel="noreferrer noreferrer" target="_blank">doug@dougcamin.com</a><u style="font-family:Calibri,sans-serif"></u><u style="font-family:Calibri,sans-serif"></u></p>
</div>
</div>
</div>
<div id="m_1089003838121372220m_5575025360515702337m_1511886498576701349m_2501752780309580549m_-4337537569496484669mail-editor-reference-message-container">
<div><span>
<div style="font-family:Aptos;font-size:12pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-color:rgb(181,196,223) currentcolor currentcolor;color:black">
<span style="font-weight:bold;font-family:Aptos">From: </span>ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" style="font-family:Aptos" rel="noreferrer noreferrer" target="_blank">arin-ppml-bounces@arin.net</a>> on behalf of Martin Hannigan <<a href="mailto:hannigan@gmail.com" style="font-family:Aptos" rel="noreferrer noreferrer" target="_blank">hannigan@gmail.com</a>><br>
<span style="font-weight:bold;font-family:Aptos">Date: </span>Wednesday, March 19, 2025 at 11:04 PM<br>
<span style="font-weight:bold;font-family:Aptos">To: </span>ARIN <<a href="mailto:info@arin.net" style="font-family:Aptos" rel="noreferrer noreferrer" target="_blank">info@arin.net</a>><br>
<span style="font-weight:bold;font-family:Aptos">Cc: </span><a href="mailto:arin-ppml@arin.net" style="font-family:Aptos" rel="noreferrer noreferrer" target="_blank">arin-ppml@arin.net</a> <<a href="mailto:arin-ppml@arin.net" style="font-family:Aptos" rel="noreferrer noreferrer" target="_blank">arin-ppml@arin.net</a>><br>
<span style="font-weight:bold;font-family:Aptos">Subject: </span>Re: [arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR definitions and references to address ambiguity in NRPM text<br>
<br>
</div>
<div><br>
</div>
<div dir="auto">A redline would be useful and easier to understand the ask accompanying such a large post.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Warm regards,</div>
<div dir="auto"><br>
</div>
<div dir="auto">-M<</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025 at 16:22 ARIN <<a href="mailto:info@arin.net" rel="noreferrer noreferrer" target="_blank">info@arin.net</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The following Draft Policy has been revised:<br>
<br>
*Draft Policy ARIN-2025-1: Clarify ISP and LIR definitions and references to address ambiguity in NRPM text<br>
<br>
Revised text is below and can be found at:<br>
<br>
<a href="https://www.arin.net/participate/policy/drafts/2025_1/" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/2025_1/</a><br>
<br>
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:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<br>
<a href="https://www.arin.net/participate/policy/pdp/" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.arin.net/participate/policy/pdp/</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<br>
<a href="https://www.arin.net/participate/policy/drafts/" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/</a><br>
<br>
<br>
Regards,<br>
<br>
Eddie Diego<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy 2025-1: Clarify ISP and LIR definitions and references to address ambiguity in NRPM text<br>
<br>
Problem Statement:<br>
<br>
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.<br>
<br>
Through implication and in common business practice, all ISPs are LIRs, but not all LIRs are ISPs.<br>
<br>
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.<br>
<br>
Policy Statement:<br>
<br>
Add Internet Service Provider definition:<br>
<br>
Remove the word “primarily” from the definition of LIR and add usage clarification:<br>
<br>
FROM: 2.4. Local Internet Registry (LIR)<br>
<br>
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.<br>
<br>
TO: 2.4. Local Internet Registry (LIR)<br>
<br>
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.
<br>
<br>
Add definition for ISP:<br>
<br>
2.18 Internet Service Provider<br>
<br>
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.<br>
<br>
Replace Section 6.5.1a<br>
<br>
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.”<br>
<br>
New Text: “[Retired]”<br>
<br>
Change all references in section 6.5 to use LIR/ISP, where appropriate:<br>
<br>
[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.]<br>
<br>
Amend Section 6.5.2 to add ISP and LIR in 15 locations<br>
<br>
6.5.2. Initial Allocation to LIRs_/ISPs_<br>
<br>
6.5.2.1. Size<br>
<br>
1. All allocations shall be made on nibble boundaries.<br>
<br>
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:<br>
<br>
* Hold IPv4 direct allocations totaling a /24 or less (to include zero) <br>
* Hold IPv4 reassignments/reallocations totaling a /22 or less (to include zero) <br>
<br>
In no case shall an _LIR/_ISP receive more than a /16 initial allocation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Amend Section 6.5.2.2 to add LIR in 2 locations:<br>
<br>
6.5.2.2. Qualifications<br>
<br>
An organization qualifies for an allocation under this policy if they meet any of the following criteria:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Amend Section 6.5.3 to add ISP in 4 locations:<br>
<br>
6.5.3. Subsequent Allocations to LIRs_/ISPs_<br>
<br>
1. Where possible ARIN will make subsequent allocations by expanding the existing allocation.<br>
<br>
2. An LIR_/ISP_ qualifies for a subsequent allocation if they meet any of the following criteria:<br>
<br>
* Shows utilization of 75% or more of their total address space <br>
* Shows utilization of more than 90% of any serving site <br>
* 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
<br>
<br>
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.<br>
<br>
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.<br>
<br>
Amend Section 6.5.4.1 to add ISP in 1 location:<br>
<br>
6.5.4.1. Reassignment to Operator’s Infrastructure<br>
<br>
An LIR_/ISP_ may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.<br>
<br>
Amend Section 6.5.5 to add LIR in 1 location:<br>
<br>
6.5.5. Registration<br>
<br>
_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.<br>
<br>
Amend Section 6.5.5.4 to add LIR in 1 location:<br>
<br>
6.5.5.4. Registration Requested by Recipient<br>
<br>
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.<br>
<br>
Amend Section 6.5.7 to add ISP in 1 location:<br>
<br>
6.5.7. Existing IPv6 Address Space Holders<br>
<br>
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.<br>
<br>
Amend Section 6.5.9 to add LIR and ISP in 2 locations:<br>
<br>
6.5.9. Community Network Allocations<br>
<br>
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.<br>
<br>
Amend Section 6.5.9.2 to add ISP in 1 location:<br>
<br>
6.5.9.2. Allocation Size<br>
<br>
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.<br>
<br>
Amend Section 6.5.9.3 to add ISP in 1 location:<br>
<br>
6.5.9.3. Reassignments by Community Networks<br>
<br>
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.<br>
<br>
Timetable for Implementation: Immediate.<br>
<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" rel="noreferrer noreferrer" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote>
</div>
</div>
</span></div>
</div>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" rel="noreferrer noreferrer" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" rel="noreferrer noreferrer" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" rel="noreferrer noreferrer" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>