<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>
<div>
<div>Owen:</div>
<div><br>
</div>
<div>I appreciate your thoughtful and constructive suggestion.</div>
<div><br>
</div>
<div>There are a couple of factors at play here that I'd like to address directly, if possible:</div>
<div><br>
</div>
<div>Regarding the Existing Waiting List - I'm uncertain about the rationale behind altering the current waiting list and applying new criteria to members who have already been approved. I believe any new policy should not retroactively affect those who have
already undergone approval. Approved members should continue to receive the resources they were initially granted based on their justification until such point as new users are added under the new policy (after its approval) and its updated distribution methods
are implemented.</div>
<div><br>
</div>
<div>As for the New Policy for Future Applicants - Future applicants may be required to select from a /22, /23, or /24 allocation, with the decision weighted based on the considerations Owen has mentioned regarding the allocation of new resources.</div>
<div><br>
</div>
<div>I support the sentiments expressed by Fernando Frediani; there should be a reasonable approach that balances the need to avoid impacting the size of routing tables while still providing users with the flexibility they require to conduct business rather
than treating IPs as a hobby.</div>
<div><br>
</div>
<div>Thanks again,</div>
<div>Denis</div>
</div>
</div>
</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On 20 Feb 2024, at 21:53, Owen DeLong <owen@delong.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>How about this:</div>
<div><br>
</div>
<div>Each waitlist recipient specifies a desired block size and a minimum acceptable block size. Wait list recipients can change their minimum acceptable block size at any time so long as it is no shorter than their originally approved block size.</div>
<div><br>
</div>
<div>When ARIN receives a block to fulfill a waitlist request, the first waitlister in line with a minimum acceptable block size ≥ the available block size gets it.</div>
<div><br>
</div>
<div>In other words, let’s say we have the following waitlist:</div>
<div><br>
</div>
<div>Party<span class="Apple-tab-span" style="white-space:pre"> </span>Approved<span class="Apple-tab-span" style="white-space:pre">
</span>Minimum acceptable</div>
<div>A<span class="Apple-tab-span" style="white-space:pre"> </span>/23<span class="Apple-tab-span" style="white-space:pre">
</span>/23</div>
<div>B<span class="Apple-tab-span" style="white-space:pre"> </span>/22<span class="Apple-tab-span" style="white-space:pre">
</span>/23</div>
<div>C<span class="Apple-tab-span" style="white-space:pre"> </span>/22<span class="Apple-tab-span" style="white-space:pre">
</span>/24</div>
<div>D<span class="Apple-tab-span" style="white-space:pre"> </span>/24<span class="Apple-tab-span" style="white-space:pre">
</span>/24</div>
<div>E<span class="Apple-tab-span" style="white-space:pre"> </span>/22<span class="Apple-tab-span" style="white-space:pre">
</span>/23</div>
<div>F<span class="Apple-tab-span" style="white-space:pre"> </span>/22<span class="Apple-tab-span" style="white-space:pre">
</span>/24</div>
<div><br>
</div>
<div><br>
</div>
<div>Let’s say ARIN receives a /24. The first /24 would go to party C.</div>
<div>If ARIN then received another /24, it would go to party D.</div>
<div>If ARIN then received a /22, Parties A and B would receive a /23 each.</div>
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Feb 16, 2024, at 17:01, Denis Motova <dmotova@brcrude.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>Dear Scott,</div>
<div><br>
</div>
<div>I appreciate the innovative perspective and thorough thought process you've articulated in your email.</div>
<div><br>
</div>
<div>There are a couple of points I'd like to highlight:</div>
<div><br>
</div>
<div>The new policy shouldn’t be retroactive, it should be only a policy going forward. I mention it only because I think it’s important to make that distinction clear.</div>
<div><br>
</div>
<div>Secondly, I find your proposed approach in the second paragraph intriguing. It's far more nuanced than simply restricting everyone to a maximum of a /24. I believe you're onto something promising here, and it could serve as a sensible strategy moving forward.</div>
<div><br>
</div>
<div>Regarding the issue of "time," it's important to acknowledge the existence of a secondary market for IPs. If there's significant pressure, purchasing IPs should be considered a viable option rather than solely relying on expedited access through the waiting
list. Maintaining a balance is key; those with urgent needs can acquire IPs through purchase, while others can join the waiting list and adhere to the traditional process. Personally, I believe this approach strikes a fair and equitable balance.</div>
<div><br>
</div>
<div>-Denis</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On 16 Feb 2024, at 21:14, Scott Leibrand <scottleibrand@gmail.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">The point isn't to "improve the visual appearance of the waiting list numbers". Everyone knows the free pool is empty except for the reclaimed dregs, and we're deciding who should get how much of the dregs. The point of this proposal, limiting
the maximum allocation to /24, is to allocate smaller netblocks to organizations that have been waiting a shorter amount of time, instead of making everyone wait longer while those with a non-time-sensitive justification for a larger block can get one and
those who only need a smaller block wait in line longer.
<div><br>
</div>
<div>Another alternative to limiting everyone to a /24 would be to prioritize the waitlist such that everyone's place in line is determined by how long they've been waiting divided by how many /24s they're requesting. So at any given time, we might be fulfilling
/24 requests that have been waiting 6 months, /23 requests that have been waiting a year, and /22 requests that have been waiting 2 years. (Or 1, 2, and 4 years, respectively.) That way no one is penalized for accepting a smaller block, and an organization
who can usefully use a /24 now and a /24 later gets a /23 worth of space in the same amount of time as someone holding out for a contiguous /23.</div>
<div><br>
</div>
<div>-Scott<span style=""color: gray; user-select: none; -ms-user-select: none; -moz-user-select: none; -webkit-user-select: none;"" class="typeahead"></span></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Feb 16, 2024 at 12:56 PM Denis Motova <<a href="mailto:dmotova@brcrude.com">dmotova@brcrude.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>
<div>Dear William,</div>
<div><br>
</div>
<div>I appreciate your message and your input.</div>
<div><br>
</div>
<div>I have some reservations about agreeing with the statement you made, and I'll explain my reasoning below:</div>
<div><br>
</div>
<div>I strongly believe that there are numerous legitimate businesses currently on the waiting list seeking IP space allocations of /22, /23, and /24. By removing the option for these allocations, we essentially transform the waiting list into what you described
in a previous post as catering to "hobbyists and speculators." It's unlikely that any serious company would require only 256 IPs within a network; that's essentially a micro-network.</div>
<div><br>
</div>
<div>As you are aware, there are multiple avenues for obtaining IP space, including the waiting list and authorized purchase methods. From my perspective, if a business urgently needs IP space, they would likely follow the example of AWS and invest in acquiring
the necessary resources rather than wait through the waiting list.</div>
<div><br>
</div>
<div>For instance, one of our customers acquired a /17 by purchasing it from the market after providing justifications to ARIN for the IP space. While this involved a significant financial investment, it demonstrated the seriousness of their business needs.</div>
<div><br>
</div>
<div>I fail to see the value in limiting everyone's network size solely to improve the visual appearance of the waiting list numbers.</div>
<div><br>
</div>
<div>Thank you once again for your collaborative spirit and feedback.</div>
<div><br>
</div>
<div>Sincerely,</div>
<div>Denis</div>
</div>
<div><br id="m_6148248718107934890lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 16 Feb 2024, at 15:52, William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> wrote:</div>
<br>
<div>
<div>On Fri, Feb 16, 2024 at 8:52 AM Denis Motova <<a href="mailto:dmotova@brcrude.com" target="_blank">dmotova@brcrude.com</a>> wrote:<br>
<blockquote type="cite">A. Decreasing the allocation to a /24 means that new allocation<br>
holders would receive a minuscule network, hardly sufficient for<br>
small to mid-sized deployments.<br>
</blockquote>
<br>
Hi Denis,<br>
<br>
At this point, the wait list is for hobbyists and speculators: people<br>
who can afford to wait, which a serious business cannot.<br>
<br>
Tell me I'm wrong.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
-- <br>
William Herrin<br>
<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
<a href="https://bill.herrin.us/" target="_blank">https://bill.herrin.us/</a><br>
</div>
</div>
</blockquote>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br>
Unsubscribe or manage your mailing list subscription at:<br>
https://lists.arin.net/mailman/listinfo/arin-ppml<br>
Please contact info@arin.net if you experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<div><br>
</div>
</div>
</body>
</html>