<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN <span dir="ltr"><<a href="mailto:ripe-wgs@radu-adrian.feurdean.net" target="_blank">ripe-wgs@radu-adrian.feurdean.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class=""><br>
On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:<br>
> Indeed. It all comes down to "the needs of those in the next few years<br>
> with no IPv4 addresses" vs "those today who have only one /22".<br>
<br>
</span>I find the situation a little more complex than that:<br>
 - First, the "in a few years with no IPv4" is not so far away. Even<br>
 with current policy, it is for 2020, with a lot of chance 2021. With<br>
 the proposal, worst case scenario is that we MAY loose up to 18 months<br>
 (more likely something in the 6-12 months range ). Which is not<br>
 completely sure (as Martin Huněk noted a few messages ago).<br>
 - Second, right now the NCC is just handing out /22 to whoever can pay<br>
 for them (with only a small extra administrative restriction during the<br>
 last 6 months). For me this is plain "selling IP addresses" (concept<br>
 that the NCC avoided like hell int the past), and it is also defeating<br>
 the "keep space for later entrants" purpose. No need check (as in "do<br>
 you really need that space" *), no requirement to deploy IPv6 of any<br>
 kind, just a simple "pay to have it".<br></blockquote><div><br></div><div>This could be solved without introducing yet another way to deplete the remaining pool.</div><div><br></div><div>The problem with 2015-05, is its similarity to how certain acts of Congress in the US come to pass:</div><div><br></div><div>You bundle what you want with something else, to sweeten the deal.</div><div><br></div><div>So here is how you can fix the deadlock:</div><div><div><br></div><div>Unbundle. Split the proposal in two parts.</div><div><br></div></div><div>Part A: Additional requirements for IPv4 allocations</div><div><br></div><div>Part B: Additional periodical IPv4 allocations for existing LIRs</div><div><br></div><div>This would, for instance, make it easy for me to say "yes" to part A, and "no" to part B, instead of "no" to the entire package.</div></div>-- <br><div class="gmail_signature">Jan</div>
</div></div>