<div dir="ltr">Hi Carlos,<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
      This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for new entrants in<br>
      this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, and we can then<br>
      count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space.<br>
<br>
<br>
The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants. <br>
You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right?<br>
</blockquote>
<br></span>
I'm saying there is an obvious benefit: accomodate more new entrants.<br>
<br>
Because an org is able to have/open multiple LIRs, the real new entrants number is not really easy to calculate :-)<span class=""><br><br></span></blockquote><div><br></div><div>My understanding from this proposal is that it just change the allocation size but an org is still able to have/open multi LIRs,</div><div><br></div><div>If this proposal reach consensus, someone still can open four LIRs and get the same amount of IP address as now. The difference (from technical point of view) is that we may have less entry in routing tables with an /22 allocation but with this proposal we will have for sure 4x /24 entry without gaining that much.</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Arash</div><div><br></div><div> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
<br>
Arash<br>
<br>
<br>
<br>
<br>
<br>
<br>
 <br>
            Arash<br>
<br>
<br>
<br>
            On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <<a href="mailto:tjc@ecs.soton.ac.uk" target="_blank">tjc@ecs.soton.ac.uk</a>> wrote:<br>
                  > On 21 Sep 2017, at 13:33, Aled Morris <<a href="mailto:aled.w.morris@googlemail.com" target="_blank">aled.w.morris@googlemail.com</a>> wrote:<br>
                  ><br>
                  > On 21 September 2017 at 12:43, Marco Schmidt <<a href="mailto:mschmidt@ripe.net" target="_blank">mschmidt@ripe.net</a>> wrote:<br>
                  > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC<br>
                  > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation<br>
                  > directly from the RIPE NCC before.<br>
                  ><br>
                  > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands?<br>
<br>
                  There?s <a href="http://www.potaroo.net/tools/ipv4/" rel="noreferrer" target="_blank">http://www.potaroo.net/tools/i<wbr>pv4/</a>.<br>
<br>
                  Tim<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>