<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Carlos,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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 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 count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space.</blockquote><div><br></div><div>The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants. </div><div>You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24?<br>
</blockquote>
<br></span>
Yes, a /23+/24 or a /23 would be a step in the right direction. If, at global level, a /25 or a /26 was acceptable (routing-wise), then that would be even better. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span style="font-size:12.8px">I would also like to draw your attention to the last section about "Alignment with other RIRs": LACNIC already has this in place. ARIN has something, which isn't really exactly the same, but the main goal is very similar. :-)</span><br></blockquote><div> </div><div><br></div><div>Still unanswered, why /24 not a /23+/24 or a /23?</div><div><span style="font-size:12.8px">what is the benefit of this "Alignment with other RIRs" to the RIPE community? I don't see any need for that too. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Arash</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
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></span>
      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>
</blockquote>
</blockquote></div><br></div></div>