<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>The point is that you treating IP marketing as something
'natural' or a 'default route' which it is not and can never be.
Natural is to receive some addresses from the RIR in first place
so they are treated as anyone else was in the past and have a
chance to exist in the Internet with same conditions as all
others. From that if they need extra space then fine to seek for
alternative ways.<br>
</p>
<p>I don't think a new entrants would automatically qualify for 4.10
in all cases therefore any space left should be targeted also to
them as well to IPv6 transition and critical infrastructure.
Otherwise the community will be creating an artificial barrier to
them in order to favor the IP market while the RIR still has IPv4
space available for them.</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 30/07/2019 10:30, Tom Fantacone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:16c4313964b.1010e8ad7186525.8055944469641973377@iptrading.com">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div style="font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10pt;">
<div>I would think that the majority of new entrants would need
at least some allocation to help with IPv6 transition and
would qualify for addresses from the 4.10 pool. Depending on
what they receive from that pool and when, they may not
qualify for additional waiting list addresses and would have
to go to the transfer market for additional IPv4 space
anyway. Those that don't qualify under 4.10 can still get
smaller IPv4 blocks on the transfer market readily, and the
cost for blocks in the /24-/22 range is not prohibitive.
Certainly an organization seeking a small IPv4 block for
multi-homing or other purposes is better off spending a few
thousand dollars to purchase a range than waiting a year on
the waiting list to put their plans in motion.<br>
</div>
<br>
Note that while RIPE does not have a reserve pool specifically
for IPv6 transition, the expectation of their final /8 policy
was to allow new entrants access to IPv4 to assist in this
transition. In reality, it didn't work out that way and most of
the /22 allocations to new LIRs from the final /8 were to
existing organizations who spun up new, related entities in
order to increase their IPv4 holdings:<br>
<a target="_blank"
href="https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations"
moz-do-not-send="true"><br>
https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations</a><br>
<br>
I'm also sympathetic to new entrants, but don't see the current
waiting list as a great help to them vs. the 4.10 pool or the
transfer market, both of which allow you your allocation in a
timely fashion.<br>
<br>
Best Regards,<br>
<br>
Tom Fantacone<br>
<br>
<div style="" class="zmail_extra"><br>
<div id="Zm-_Id_-Sgn1">---- On Mon, 29 Jul 2019 11:39:32 -0400
<b>Fernando Frediani <<a target="_blank"
href="mailto:fhfrediani@gmail.com"
moz-do-not-send="true">fhfrediani@gmail.com</a>></b>
wrote ----<br>
</div>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);
padding-left: 6px; margin: 0px 0px 0px 5px;">
<div>I find it interesting the idea of privileging the pool
dedicated to <br>
facilitate IPv6 Deployment and I also agree with the
comments below in <br>
the sense that it's not very beneficial do most ARIN
members due to max <br>
size, /22, cannot be holding more than a /20.<br>
<br>
However one point I couldn't identify is where the new
entrants stand in <br>
this new possible scenario ? Will they only be able to
apply under the <br>
4.10 reserved pool ? If so for a access/broadband ISPs may
be easier to <br>
fit, but not necessarily for other scenarios and types of
ISPs. <br>
Therefore if I didn't miss anything these returned
addresses should also <br>
be able to go to new entrants, not only to 4.10 reserved
pool conditions.<br>
<br>
Best regards<br>
Fernando Frediani<br>
<br>
On 25/07/2019 17:32, Tom Fantacone wrote:<br>
> I found the wording of the Problem Statement on this
one a bit <br>
> confusing. However, after deciphering the effect of
the actual policy <br>
> change I support it.<br>
><br>
> Essentially, all returned IPv4 space will no longer
go to the waiting <br>
> list but will supplement the 4.10 reserved pool used
to enhance IPv6 <br>
> deployment. This essentially kills off the waiting
list.<br>
><br>
> The recent restrictions placed on the waiting list to
reduce fraud <br>
> have hobbled it to the point where it's not very
beneficial to most <br>
> ARIN members. (Max size, /22, cannot be holding more
than a /20). <br>
> It's essentially only useful to new entrants, but
those that go on it <br>
> still have to wait many months to receive their small
allocation. If <br>
> they justify need now, but have to wait that long,
how critical is <br>
> their need if they're willing to wait that long?
Small blocks are not <br>
> terribly expensive and can be quickly gotten on the
transfer market. <br>
> I can understand waiting that long for a large block
needed for a <br>
> longer term project due to prohibitive cost, but I
don't see a great <br>
> benefit to the waiting list as it stands.<br>
><br>
> Also, if there's any fraud left on the waiting list,
this would kill it.<br>
><br>
> I would hope, however, that if implemented, those
currently on the <br>
> waiting list would be grandfathered in. I do think
some entities with <br>
> legitimate need got burned on the last change made to
the waiting list.<br>
><br>
> At 04:05 PM 7/23/2019, ARIN wrote:<br>
>> On 18 July 2019, the ARIN Advisory Council (AC)
accepted <br>
>> "ARIN-prop-276: Returned Addresses to the 4.10
Reserved Pool" as a <br>
>> Draft Policy.<br>
>><br>
>> Draft Policy ARIN-2019-17 is below and can be
found at:<br>
>><br>
>> <a target="_blank"
href="https://www.arin.net/participate/policy/drafts/2019_17/"
moz-do-not-send="true">https://www.arin.net/participate/policy/drafts/2019_17/</a><br>
>><br>
>> You are encouraged to discuss all Draft Policies
on PPML. The AC will <br>
>> evaluate the discussion in order to assess the
conformance of this <br>
>> draft policy with ARIN's Principles of Internet
number resource <br>
>> policy as stated in the Policy Development
Process (PDP). <br>
>> 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>
>> <a target="_blank"
href="https://www.arin.net/participate/policy/pdp/"
moz-do-not-send="true">https://www.arin.net/participate/policy/pdp/</a><br>
>><br>
>> Draft Policies and Proposals under discussion can
be found at:<br>
>> <a target="_blank"
href="https://www.arin.net/participate/policy/drafts/"
moz-do-not-send="true">https://www.arin.net/participate/policy/drafts/</a><br>
>><br>
>> Regards,<br>
>><br>
>> Sean Hopkins<br>
>> Policy Analyst<br>
>> American Registry for Internet Numbers (ARIN)<br>
>><br>
>> Draft Policy ARIN-2019-17: Returned Addresses to
the 4.10 Reserved Pool<br>
>><br>
>> Problem Statement:<br>
>><br>
>> An inconsistent and unpredictable stream of
address space is an <br>
>> unsuitable method of populating the waiting list
(4.1.8.1) and <br>
>> fulfilling subsequent requests.<br>
>><br>
>> Policy statement:<br>
>><br>
>> Change "4.10. Dedicated IPv4 Block to Facilitate
IPv6 Deployment" to <br>
>> "4.10 Dedicated IPv4 Pool to Facilitate IPv6
Deployment"<br>
>><br>
>> Change" When ARIN receives its last /8 IPv4
allocation from IANA, a <br>
>> contiguous /10 IPv4 block will be set aside and
dedicated to <br>
>> facilitate IPv6 deployment. Allocations and
assignments from this <br>
>> block " to "In addition to the contiguous /10
IPv4 block set aside <br>
>> and dedicated to facilitate IPv6 deployment, all
returns and <br>
>> revocations of IPv4 blocks will be added to the
pool of space <br>
>> dedicated to the facilitation of IPv6 deployment.
Allocations and <br>
>> assignments from this pool "<br>
>><br>
>> Change "This block will be subject to a minimum
size allocation of <br>
>> /28 and a maximum size allocation of /24. ARIN
should use sparse <br>
>> allocation when possible within that /10 block."
to "This pool will <br>
>> be subject to a minimum size allocation of /28
and a maximum sized <br>
>> allocation of /24. ARIN should use sparse
allocation when possible <br>
>> within the pool."<br>
>><br>
>> Comments:<br>
>><br>
>> Timetable for implementation: Immediate<br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are
subscribed to<br>
>> the ARIN Public Policy Mailing List (<a
target="_blank" href="mailto:ARIN-PPML@arin.net"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list
subscription at:<br>
>> <a target="_blank"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a target="_blank"
href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<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
target="_blank" href="mailto:ARIN-PPML@arin.net"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription
at:<br>
> <a target="_blank"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a target="_blank"
href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed
to<br>
the ARIN Public Policy Mailing List (<a target="_blank"
href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a target="_blank"
href="https://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a target="_blank"
href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</div>
</blockquote>
</div>
<div><br>
</div>
</div>
<br>
</blockquote>
</body>
</html>