<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Feb 21, 2024, at 07:20, Fernando Frediani <fhfrediani@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi<br>
</p>
<p>This rather seems to be a vague assumption as you didn't provide
anything substantial for it to be a blocker to have a policy
adjusted in order to contemplate only new entrants.<br>
Why is it bad ? Do you think it is still rational to keep
supplying IP addresses to those who already have some in detriment
to those who have nothing ?</p></div></blockquote>I think any legitimate use of IPv4 addresses is no more or less worthy than any other. I see no reason to elevate theoretical new entrants to the point of depriving existing legitimate users. <div><br></div><div>IPv4 is an obsolete technology. Preserving an IPv4 free pool against legitimate demand to facilitate latecomers and laggards failure to deploy IPv6 is simply not in the overall best interests of the internet. <br><blockquote type="cite"><div dir="ltr">
<p>This is not unenforceable and just a supposition unsupported by
real data. ARIN has means to develop ways to check these newer
organizations and separate the possible fraudsters from the legit
ones. Just before there it serves to inhibit a lot of organization
to even request IPs under the waitlist making it much cleaner and
fair. LACNIC has been doing it for years and it has proven to be
successful in terms of fairness and possibility to check these
organization requests correctly. Are we going to avoid having a
policy which is the right thing to do just on the supposition that
there will be fraud ?</p></div></blockquote><div><br></div>While I stayed that the process in question was morally equivalent to fraud, it is 100% legal and utterly indistinguishable from a legitimate new entrant. </div><div><br></div><div>The policy you are proposing is not only the wrong thing to do (see above), it is also quite trivially worked around. One can legitimately spin up an organization for a few hundred dollars and a few hours of work. </div><div><br></div><div>ARIN can prevent the recording of that organization’s subsequent acquisition in the ARIN database, but that’s about all that ARIN can do. </div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div dir="ltr">
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 21/02/2024 04:13, Owen DeLong via
ARIN-PPML wrote:<br>
</div>
<blockquote type="cite" cite="mid:2591268E-675E-430C-9285-B0FEC36B17C6@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Anyone using IP to conduct business should recognize that IPv4 is
out and they’ll need IPv6 to do business going forward.
<div><br>
</div>
<div>I oppose Fernando’s idea that the waitlist should be limited
to new entrants. In addition to being bad policy, this is
completely unenforceable and only leads to widespread
workarounds (which are morally equivalent to fraud but probably
don’t quite fit the legal definition of the term). (The cost to
spin up an organization to acquire resources and then acquire
the organization is trivial compared to the value of the IPv4
resources obtained).</div>
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
<div>
<div>
<blockquote type="cite">
<div>On Feb 20, 2024, at 19:28, Denis Motova
<a class="moz-txt-link-rfc2396E" href="mailto:dmotova@brcrude.com"><dmotova@brcrude.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div 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
<a class="moz-txt-link-rfc2396E" href="mailto:owen@delong.com"><owen@delong.com></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:dmotova@brcrude.com"><dmotova@brcrude.com></a>
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
<a class="moz-txt-link-rfc2396E" href="mailto:scottleibrand@gmail.com"><scottleibrand@gmail.com></a>
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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">bill@herrin.us</a><br>
<a href="https://bill.herrin.us/" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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
(<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing
list subscription at:<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you
experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<span>_______________________________________________</span><br><span>ARIN-PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span>https://lists.arin.net/mailman/listinfo/arin-ppml</span><br><span>Please contact info@arin.net if you experience any issues.</span><br></div></blockquote></div></body></html>