<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 only encourage NATting. I dont suppose that exactly conforms with our cause. I believe some of us have this sentimental attachment  to IPV4 will not want to let go. I strongly think allocation of IPV4 should continue as is so it gets exhausted, then people will realise how much they need to move to IPV6. Tata 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: > All, > > I'm going on safari to USA soon, and will be unable to participate in > policy discussions until August, so here is my preemptive reaction to > the upcoming last call: > > I must object quite strenuously to this policy and to it's being put > to Last Call on both policy and process grounds. > > > Policy objections: > > 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>