<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 28, 2016 at 6:32 PM, Douglas Onyango <span dir="ltr"><<a href="mailto:ondouglas@gmail.com" target="_blank">ondouglas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Scott,<br>
<span class="">On 29 January 2016 at 04:28, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>> wrote:<br>
>I don't have a strong opinion on how that should be<br>
> done: I'm just pointing out that it would be good to ensure some sort of<br>
> soft landing free pool remains for several more years to ensure IPv4 space<br>
> is still available for new entrants until the burden of interconnecting the<br>
> legacy IPv4 Internet to the IPv6 Internet switches from IPv6-only to<br>
> IPv4-only networks.<br>
<br>
</span>I believe this is why we have the /12 reserved.<br></blockquote><div><br></div><div>Yep.  I was referring to Andrew's assessment that:</div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">Due to the fact that the current soft landing policy still allows extremely large allocations, this will not significantly slow down the allocation rates, and if anything, moving into soft landing may well spur more people into action and applications, which could actually INCREASE the rate of allocation.  Should the allocation rate remain unchanged, Africa is out of space by late March/Beginning April 2017.</blockquote><div><br></div><div>If you close the loopholes or otherwise adjust the soft landing policy so that the allocation rate under soft landing policy slows down significantly, then I think that addresses the concern.  And if it turns out that your adjustments are insufficient, then you might still be able to create a smaller IPv6 transition pool using the IANA returned space AfriNIC will receive over subsequent months.</div><div><br></div><div>-Scott </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
> On Thu, Jan 28, 2016 at 6:22 PM, Douglas Onyango <<a href="mailto:ondouglas@gmail.com">ondouglas@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Scott,<br>
>> In this case, I think adding v6 deployment as an eligibility<br>
>> requirement should suffice?<br>
>> Whether it's on the first allocation/assignment or on subsequent ones<br>
>> can be discussed.<br>
>><br>
>> Regards,<br>
>><br>
>> On 29 January 2016 at 04:11, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>><br>
>> wrote:<br>
>> > There are certain needs for IPv4 space that only require uniqueness, but<br>
>> > not<br>
>> > routability.  For example, router IDs often need to be unique IPv4<br>
>> > addresses<br>
>> > (even when only routing IPv6), but they don't need to be announced to<br>
>> > anyone.  To date, most requests under 4.10 have been for /24s, and ARIN<br>
>> > considers "we'd like to route this block on the Internet" to be valid<br>
>> > justification for needing a /24, so the policy allowing (but not<br>
>> > requiring)<br>
>> > smaller allocations doesn't do any harm.  ARIN already has to do<br>
>> > non-classful rDNS delegation for blocks >/24, so I don't think the<br>
>> > burden<br>
>> > there (if people actually choose to request smaller blocks) will be all<br>
>> > that<br>
>> > significant.<br>
>> ><br>
>> > I am not necessarily suggesting reserving *more* space: if you'd prefer<br>
>> > you<br>
>> > could tighten up the eligibility requirements on some of the<br>
>> > already-reserved space.  I am only suggesting that completely exhausting<br>
>> > the<br>
>> > AfriNIC IPv4 free pool, with no space left to allocate to new entrants<br>
>> > for<br>
>> > any reason, would put African companies at a disadvantage to new<br>
>> > entrants in<br>
>> > other regions, who all have some sort of space reserved for that<br>
>> > purpose.<br>
>> ><br>
>> > -Scott<br>
>> ><br>
>> > On Thu, Jan 28, 2016 at 5:58 PM, Douglas Onyango <<a href="mailto:ondouglas@gmail.com">ondouglas@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi Scott,<br>
>> >> On 28 January 2016 at 23:25, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >><br>
>> >> > I would also suggest that at the very least the AfriNIC community<br>
>> >> > consider<br>
>> >> > an addition to the soft-landing policy that sets aside an IPv4 block<br>
>> >> > dedicated to facilitating IPv6 deployment, by making IPv4 addresses<br>
>> >> > available for IPv6 translation technologies, dual stack DNS servers,<br>
>> >> > etc.<br>
>> >> > Something like <a href="https://www.arin.net/policy/nrpm.html#four10" rel="noreferrer" target="_blank">https://www.arin.net/policy/nrpm.html#four10</a> could be<br>
>> >> > implemented either by carving out a pool out of AfriNIC's existing<br>
>> >> > inventory, or by dedicating space newly redistributed from IANA for<br>
>> >> > the<br>
>> >> > purpose.  Alternately, a RIPE/APNIC style "one block per network"<br>
>> >> > soft<br>
>> >> > landing policy would accomplish a similar objective: making sure that<br>
>> >> > future<br>
>> >> > new entrants can continue to receive enough IPv4 addresses to talk to<br>
>> >> > the<br>
>> >><br>
>> >> While I like the idea of promoting v6 deployment as we near<br>
>> >> exhaustion, I find the idea of further reserving the more space not<br>
>> >> very appealing. You must recall that the Softlanding has already<br>
>> >> reserved a /12 for unforeseen circumstances.<br>
>> >><br>
>> >> Further, I am curious as to what motivated ARIN's choice to allocate<br>
>> >> /28-/24 block from the reserve in your policy<br>
>> >> <a href="https://www.arin.net/policy/nrpm.html#four10" rel="noreferrer" target="_blank">https://www.arin.net/policy/nrpm.html#four10</a><br>
>> >><br>
>> >> I can only see this approach either breaking the Internet, as people<br>
>> >> drop your routes on account of size, or additional reverse delegation<br>
>> >> work being created for the RIR.<br>
>> >><br>
>> >><br>
>> >> Regards,<br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Douglas Onyango, PRINCE 2, ITILv3<br>
>> UG: <a href="tel:%2B256%20776%20716%20138" value="+256776716138">+256 776 716 138</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Douglas Onyango, PRINCE 2, ITILv3<br>
UG: <a href="tel:%2B256%20776%20716%20138" value="+256776716138">+256 776 716 138</a><br>
</div></div></blockquote></div><br></div></div>