<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hello Tata, McTim,<br>My recollection of the deliberations was an understanding that we incorporate this into the last call version of the policy.<br><br>I could be wrong @chair, but i was thinking it was one of the  omissions  made while compiling the input<br><br><br>Regards,<br>Douglas Onyango +256(0712)981329<br>
Life is the educators practical joke in which you spend the first half learning, and the second half learning that everything you learned in the first was wrong.<br><br>--- On <b>Wed, 6/23/10, Auwal Tata <i><tatauwal@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Auwal Tata <tatauwal@gmail.com><br>Subject: Re: [AfriNIC-rpd] Last Call: IPv4 Soft Landing Proposal<br>To: "McTim" <dogwallah@gmail.com><br>Cc: "AfriNIC Resource Policy Discussion List" <rpd@afrinic.net><br>Date: Wednesday, June 23, 2010, 4:12 PM<br><br><div class="plainMail">Thanks MCTim, now somebody is actually thinking my direction. I raised<br>this issue during the Afrinic meetings in Kigali. I said limiting an<br>LIR to a /23 that will eventually subnetted and given out to endusers<br>will be grossly inadequate. /23 only contains 2 /24s with just 254<br>usable IPs how many end
 users can be accommodated with that. This will<br>only encourage NATting. I dont suppose that exactly conforms with our<br>cause.<br>I believe some of us have this sentimental attachment  to IPV4 will<br>not want to let go. I strongly think allocation of IPV4 should<br>continue as is so it gets exhausted, then people will realise how much<br>they need to move to IPV6.<br><br>Tata<br><br>On Wed, Jun 23, 2010 at 1:35 PM, McTim <<a ymailto="mailto:dogwallah@gmail.com" href="/mc/compose?to=dogwallah@gmail.com">dogwallah@gmail.com</a>> wrote:<br>> All,<br>><br>> I'm going on safari to USA soon, and will be unable to participate in<br>> policy discussions until August, so here is my preemptive reaction to<br>> the upcoming last call:<br>><br>> I must object quite strenuously to this policy and to it's being put<br>> to Last Call on both policy and process grounds.<br>><br>><br>> Policy objections:<br>><br>> 1.
 It aims to promote adoption of v6 by trying to lengthen the<br>> lifetime of IPv4.  This seems contradictory to me.  By making v4 last<br>> longer, we are only retarding the growth of IPv6<br>> usage.<br>><br>> 2. The stated objectives of all RIRs are Conservation, Aggregation and<br>> Registration.<br>><br>> See slide 33 of <a href="http://www.afrinic.net/training/materials/Member-Training-v2.pdf" target="_blank">http://www.afrinic.net/training/materials/Member-Training-v2.pdf</a><br>><br>> This policy negates 2 of those objectives.   It actively promotes<br>> deaggregation by setting an artificially low maximum allocation size.<br>> Currently our maximum allocation size is a /10.  This policy limits<br>> LIRs to a /23 in the exhaustion phase, thus mandating the announcement<br>> of multiple /23's.  This does not limit routing table growth, instead<br>> it encourages
 it.<br>><br>> In terms of conservation, the intended consequence of this policy is<br>> to reserve a /12 for future use, which is an idea I support.  However,<br>> the UNINTENDED consequence of this policy is to reserve the majority<br>> of the last /8, by "locking up" most of the 16 million IPs of the last<br>> /8.<br>><br>> quoting GB:<br>><br>> "You limit each LIR to a /21 of addressing resources. That provides<br>> for 7680 (excluding the reserved /12) LIRs to obtain maximum<br>> allocations. AfriNIC currently has 1009 members and a growth rate of<br>> less than 100 members per year[1]. This means that at the end of 5<br>> years 80% of our final /8 will be locked up and un-allocatable under<br>> this policy."<br>><br>> Conservation is one thing, however making a large portion of the /8<br>> "un-allocatable" as an unintended consequence is not only overly<br>> conservative, it is absurd
 and bad policy making IMHO.  In other<br>> words, while trying to extend the lifetime of v4 in this region, we<br>> are making it much shorter artificially!!<br>><br>> The response I got to this objection at he meeting is that "none of us<br>> know what the environment will be in the future".  While this is<br>> correct, it does not seem unreasonable to conclude that the current<br>> growth rate of LIRs will not change substantially due to consolidation<br>> in the ISP market.  Even if we quadrupled the number of LIRs in 2<br>> years, we would still be "locking" a substantial portion of the last<br>> /8.<br>><br>> While my crystal ball may be just as foggy as others, in the<br>> theoretical situation where each of the existing LIRs (~1000 now and<br>> approaching 1500 in 3 years time) has gotten all of their possible<br>> allocations AND demand by endusers for IPv4 is still high, then
 there<br>> is only one possible outcome (unless we change this policy at some<br>> point).  That outcome is a surge in demand for PI (EndUser) blocks.<br>><br>> Both Aggregation and Conservation depend upon LIRs requesting<br>> resources they need.  This is our mantra (some of our critics call it<br>> our "religion" see Milton Muelller).  We are changing that due to the<br>> perception (not the reality) of a shortage of IPv4 blocks in this<br>> region.  While it still holds true for v6, we are shooting ourselves<br>> in the v4 foot.<br>><br>> On process, I just didn't see the consensus that the PDP-MG did in the<br>> room or on the list on this one.  Points out that we do indeed need a<br>> new PDP.  But that one is for another day ;-)<br>><br>><br>> --<br>> Cheers,<br>><br>> McTim<br>> "A name indicates what we seek. An address indicates where it is. A<br>>
 route indicates how we get there."  Jon Postel<br>> _______________________________________________<br>> rpd mailing list<br>> <a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br>> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>><br>_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br></div></blockquote></td></tr></table><br>