<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 21/02/2024 20:16, Owen DeLong wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D01D0A6F-F114-4F4C-9BBE-1A1CAE1AFB64@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite"><clip>
<div>
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">This is LACNIC waiting list which has
always assigned *only to new entrants*. It is currently
easily on 5 years wait time. Is this still to vague ?</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a
href="https://www.lacnic.net/6335/2/lacnic/ipv4-address-waitlist"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.lacnic.net/6335/2/lacnic/ipv4-address-waitlist</a><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
And? What does this have to do with whether it’s good policy in
the ARIN region or not?</div>
</blockquote>
<br>
It has to do with your argument that there will not be new entrants
that justify having the policy only to fulfill them.<br>
<blockquote type="cite"
cite="mid:D01D0A6F-F114-4F4C-9BBE-1A1CAE1AFB64@delong.com">
<div><br>
</div>
<div>IMHO, it’s also bad policy in the LACNIC region, but I have
less of a stake in the outcome in their region, so I don’t argue
as strongly there.</div>
<div>Also, since I don’t speak Spanish, participation on their
policy list would be difficult for me. It works for the majority
in the region so I am not complaining about this, merely stating
it as fact.</div>
<div><br>
</div>
<div>With few exceptions, I still see no valid reason to
disadvantage existing need for speculative future use. Those
exceptions are well covered by 4.4 and 4.10 (which LACNIC does
not have equivalent policies to the best of my knowledge, so
perhaps that is why they limit to new entrants here).</div>
</blockquote>
<br>
4.4 and 4.10 don't cover all minimal needs of new entrants in ARIN
as most of them are not critical infrastructure and cannot use 4.10
for any type of usage. LACNIC does have a 4.4 equivalent.<br>
<blockquote type="cite"
cite="mid:D01D0A6F-F114-4F4C-9BBE-1A1CAE1AFB64@delong.com">
<div><br>
<blockquote type="cite">
<div>
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>
<div><br>
</div>
This is purely your opinion. In my opinion, you
shouldn’t get to make that decision on behalf of
existing organizations and tell them how to run
their networks. </div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Oh again this.</div>
<div dir="auto">Yes people can chose whatever they want to
run their networks, but one that keeps refusing to
implement CGNAT in their operation and wishes the luxury
to keep assigning a Public IPv4 to each individual
customer, we as policymakers are able to limit their
choices by letting them to go to the transfer market in
order to fullfil their choice and not mess with a bet in
the waiting list.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
If we think that’s good policy, yes, we can do that. Personally,
I do not think forcing CGNAT in order to provide possible
addresses for some as yet unknown future use is a good policy
tradeoff. Obviously you think it is good policy. That’s fine, we
can agree to disagree and I’m sure others will express opinions
as well.</div>
</blockquote>
<p>Do you think I like to build CGNAT ? At least I build along with
well deployed IPv6 and with the minimal amount of IPv4 needed for
users to reach the entire internet. No RIRs or policies forced me
to do that. I make these decisions looking at the current
scenarios and taking in consideration the natural evolution of
IPv4 exhaustion which hits everyone the same way.</p>
<p>Fernando<br>
</p>
<blockquote type="cite"
cite="mid:D01D0A6F-F114-4F4C-9BBE-1A1CAE1AFB64@delong.com"><br>
<div><br>
</div>
<br>
</blockquote>
</body>
</html>