<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello,</div><div class=""><br class=""></div><div class="">See inline...</div><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 5, 2016, at 6:40 AM, Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><blockquote type="cite" class="">On Nov 4, 2016, at 13:08 , Andrew Alston <<a href="mailto:Andrew.Alston@liquidtelecom.com" class="">Andrew.Alston@liquidtelecom.com</a>> wrote:<br class=""><br class="">Please can we know what the motivation behind the /14 number chosen for new entrants is and what data was used to select this number.<br class=""><br class="">The same applies for the /13 for unforeseen future, how was this number arrived at, and can we understand the motivation behind reserving more space for unforeseen future than for new entrants.<br class=""><br class="">Without data to evaluate these numbers they come across as arbitrary and without justification and I oppose putting anything into policy that cannot be backed by empirical facts.<br class=""><br class="">I oppose the IPv6 address space as a requirement – it has proven to be an ineffective method of promoting ipv6 and serves absolutely no purpose (see V6 announcement vs allocation statistics and the fact that the continent already has over 500 ipv6 assignments spread pretty evenly across the continent with active deployments in only 3 or 4 countries)<br class=""><br class="">I oppose the allocations for new entrants being used exclusively for ipv6 transition – I do not believe that AfriNIC has the right to dictate to anyone how they use their space, and if they have a legitimate requirement for v4 space for internal (non globally routable, but requirement global uniqueness) they should be able to get it – there would be no translation on such internal things. <br class=""><br class="">Andrew<br class=""><br class="">On 04/11/2016, 22:51, "ALAIN AINA" <<a href="mailto:aalain@trstech.net" class="">aalain@trstech.net</a>> wrote:<br class=""><br class=""> Hello All.<br class=""><br class=""> Thanks Co-chairs for the summary on the IPv4 softlanding-bis proposal.<br class=""><br class=""> Our proposal set:<br class=""><br class=""> a /16 for Critical Infrastructure : DNS root ops, IXPs, TLD (cc and g) ops, RIRs, IANA<br class=""></blockquote><br class="">This is too broad, given the IANA gTLD Make Money Fast scheme currently being deployed.<br class=""></div></blockquote><div><br class=""></div><div> We can narrow it down to the geographic gTLD. The plan was to make sure the emerging gTLD registries operating in the region, be treated as the cc. Let's hear what folks think .</div><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""> a /14 for new entrants<br class=""></blockquote><br class="">I’m not in support of this without further clarification as previously stated.<br class=""></blockquote><div><br class=""></div><div>Make sure New entrants( without no previous allocations/assignments) get the minimum v4 space needed from the "102/8" to support their v6 to v4 services.</div><div><br class=""></div><div>Rationale behind the /14. AFRNIC has in average 133 new members a year.The /14 covers the need for just under 2 years with a max allocation of /22. See slide 24 from presentation given at AFRINIC-24 in Botswana, <a href="http://www.trstech.net/alain/public/softlanding-slides-AFRINIC-24.pdf" class="">http://www.trstech.net/alain/public/softlanding-slides-AFRINIC-24.pdf</a> </div><div><br class=""></div><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""> a /13 for unforeseen future<br class=""></blockquote><br class="">I am absolutely opposed to this.<br class=""></blockquote><div><br class=""></div><div>This proposal stays in the spirit of the current soft landing policy. We propose to reduce the reserve to accommodate new entrants and critical infrastructures. </div><div><br class=""></div><div>This is a “Strategic Reserve” for future use on which community will decide as we go. As such i would like to hear from people in the region on the Strategic Reserve; 3.125% of the specific last /8 (102/8)</div><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""> IPv6 address space (AFRINIC or upstreams) as requirement to IPv4 allocations<br class=""></blockquote><br class="">Can you clarify this </blockquote><div><br class=""></div><div> Section 3.8, allocations criteria in the proposal read:</div><div>……………...</div><div>LIR and End users requesting IPv4 must have IPv6 resources from AFRINIC
(or request concomitantly with the IPv4) or from their upstreams.</div><br class=""><blockquote type="cite" class="">and how it is relevant or useful?<br class=""></blockquote><div><br class=""></div><div>The last /8 (102/8) gotten through the global soft landing policy aims among other objectives to encourage a smooth transition to IPv6. </div><div>So if you need space from this last /108, show your IPv6.</div><div><br class=""></div><div>Current allocations/assignment criteria for v6 are as below from CPM: </div><div><br class=""></div><div><p class=""><strong class="">6.5.1.1 Initial allocation criteria</strong></p><p class="">To qualify for an initial allocation of IPv6 address space, an organization must:</p>
<ol style="list-style-type: lower-alpha;" class="">
<li class="">Be an LIR;</li>
<li class="">Not be an end site;</li>
<li class="">Show a detailed plan to provide IPv6 connectivity to organizations in the AFRINIC region.</li>
<li class="">Show a reasonable plan for making /48 IPv6 assignments to end sites
in the AFRINIC region within twelve months. The LIR should also plan to
announce the allocation as a single aggregated block in the inter-domain
routing system within twelve months.</li>
</ol><div class="">===========</div><div class=""><br class=""></div><div class=""><p class=""><strong class="">6.8.2 Assignment Criteria</strong></p>
<ol style="list-style-type: lower-alpha;" class="">
<li class="">Assignment target - End-sites which provide Public Internet services
for a single administrative organisations' network, regardless of their
size.</li>
<li class="">Assignment criteria:</li>
</ol>
<ul class="">
<li class="">The end-site must not be an IPv6 LIR</li>
<li class="">The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its' membership category</li>
<li class="">The end site must either be a holder of IPv4 PI address space or
qualify for an IPv4 PI assignment from AFRINIC under the IPv4 policy
currently in effect.</li>
<li class="">The end-site must justify the need for the IPv6 PI address space.</li>
<li class="">The 'end-site' must show a plan to use and announce the IPv6
provider independent address space within twelve (12) months. After that
period, if not announced, the assigned IPv6 PI address space should be
reclaimed and returned to the free pool by AFRINIC.</li></ul></div></div><div>--------</div><div>If you do not have v6 or loose your v6 (review of allocations, etc…) you will not qualify for v4 in the last /8 unless justified.</div><div><br class=""></div><div><br class=""></div><div>Hope this helps</div><div><br class=""></div><div>—Alain</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class=""> We invite people to read the FAQ which is attached to the proposal and which helps with the understanding. <br class=""><br class=""> <a href="http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2" class="">http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2</a><br class=""><br class=""> From recent discussions, the authors of the solanding-bis proposal would be happy to consider making explicit in the proposal the following points:<br class=""><br class=""><br class=""> - Multiple new entrants under common ownership being treated as a single new entrant<br class=""></blockquote><br class="">If we are to have a new entrant reservation, this is a vital protection. Otherwise, anyone can find a friendly jurisdiction in the region and spin up as many new entrants as they like. Sort of like AWS for Coprorations to obtain addresses.<br class=""><br class="">We should also put some form of exclusion or protection against combining, consolidating, or trading in new-entrant space in any existing merger/acquisition transfer policy as well as for any future transfer/trade/sale policy that may be adopted.<br class=""><br class=""><blockquote type="cite" class=""> - Allocations to New entrants being used exclusively for IPv6 transitions mechanisms and services as explained in the FAQ<br class=""></blockquote><br class="">I think this is also a vital protection against new entrants seeking larger than acceptable allocations.<br class=""><br class="">Owen<br class=""><br class=""><blockquote type="cite" class=""><br class=""> Hope this helps<br class=""><br class=""> --Alain <br class=""><br class=""><blockquote type="cite" class="">On Nov 3, 2016, at 4:03 PM, Dewole Ajao <<a href="mailto:dewole@forum.org.ng" class="">dewole@forum.org.ng</a>> wrote:<br class=""><br class="">Thank you for the feedback, Owen. We look forward to the authors of both proposals considering the various inputs as well as offering further clarification to help the community better understand the rationale(s) behind the current drafts of their proposal(s).<br class=""><br class="">Regards,<br class="">Dewole.<br class=""><br class="">On 02/11/2016 23:16, Owen DeLong wrote:<br class=""><blockquote type="cite" class="">Thanks for doing this… It’s very useful.<br class=""><br class="">There are elements from each of the proposals I like, but none of them would get my support in their current form.<br class=""><br class="">I like the idea of a reserved carve-out for critical infrastructure.<br class="">I like the idea of a small (/12, perhaps) cutout for new organizations that are late to the party to receive up to a /24 for transition purposes.<br class=""><br class="">I do not like the idea of a large reservation for new entrants to the exclusion of the needs of existing participants.<br class=""><br class="">I especially do not like the idea of reserving a block of addresses for some undefined future use. Any future development that would require such a thing should be done under IPv6. There is no excuse for such development to be done in a manner that requires IPv4 addresses at this point in the evolution of the internet. We should not reward or encourage backward-thinking engineering.<br class=""><br class="">I think that the reservation for critical infrastructure should be from a specific block.<br class=""><br class="">I think it would be reasonable, if there is need, for the new entrant block to be comprised of fragments totaling a /12 equivalent rather than necessarily blocking out a specific /12.<br class=""><br class="">I do not think that reclaimed space should be reserved for new entrants. Rather, I would prefer to see one of two approaches taken to reclaimed space:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1.<span class="Apple-tab-span" style="white-space:pre"> </span>An annoucement is made on relevant mailing lists that the space has been received and applications will be accepted beginning at a<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>certain date and time. Such date and time to be not less than 14 days after the announcement is sent out.<br class=""><br class="">or<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2.<span class="Apple-tab-span" style="white-space:pre"> </span>A waiting list of unmet requests is created and the space is offered to those requestors on the waiting list on a FIFO basis.<br class=""><br class="">If we are to have a new-entrant block (I consider this optional, but desirable), it should be strictly for purposes of providing the addresses needed for transitional technologies (CGN, 6rd, etc.) and we should not allocate more than a /24 to any single new entrant. Multiple new entrants under common ownership should be treated as a single new entrant in most cases.<br class=""><br class="">Owen<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 2, 2016, at 13:49 , Dewole Ajao <<a href="mailto:dewole@forum.org.ng" class="">dewole@forum.org.ng</a>> wrote:<br class=""><br class="">Good day,<br class=""><br class="">As indicated in an earlier email, please take some time to view and comment on <a href="https://goo.gl/FDLmZF" class="">https://goo.gl/FDLmZF</a> with a view toward fine-tuning and producing an improved IPv4 runout management plan.<br class=""><br class="">Thank you.<br class=""><br class="">Dewole Ajao<br class="">PDWG Co-Chair<br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></blockquote></blockquote><br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></blockquote><br class=""><br class=""> _______________________________________________<br class=""> RPD mailing list<br class=""> <a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""><br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></blockquote><br class=""></blockquote></div><br class=""></body></html>