<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I believe that the problem statement remains fundamentally flawed and that the resulting policy suffers from those flaws. Clarification in-line below...</div><blockquote type="cite"><div><div dir="ltr"><div><Begin Draft><br><h3>1. Summary of the problem being addressed by this proposal</h3>
<p>The current Soft-Landing Policy describes how AFRINIC should manage allocations/assignments from the last /8.</p>
<p>While the stated policy objective is to ensure that
allocations/assignments are managed in a manner that is acceptable to
the AFRINIC community, there is a general feeling from the AFRINIC
community that certain provisions in the policy are not consistent with
this objective.</p>
<p></p>
<p>Specifically, the current Softlanding Policy:</p>
<ol style="list-style-type:lower-alpha"><li>Allows a maximum allocation size of a /13 in Phase 1. The authors
feel this is too large based on average allocation size, and can be
abused.</li></ol></div></div></div></blockquote>Please define the perceived "abuse" and explain how it constitutes abuse. Note, I feel that use of loaded terms like "abuse" to describe "a result we don't like" is disingenuous and contrary to open and transparent policy development.<br><blockquote type="cite"><div><div dir="ltr"><div><ol style="list-style-type:lower-alpha" start="2"><li>Allows organizations to request allocations/assignments without
limiting the number of times or maximum size that can be requested. The
authors of this policy feel this can advantage a few, mostly large
organizations, at the expense of the general community, and can also be
abused.</li></ol></div></div></div></blockquote>This perpetuates the myth that large organizations don't serve the general community when in reality, depending on the organization, in some cases, large organizations serve the biggest fractions of the general community. While I can't cite specific examples within the AfriNIC region, I will point out that a /8 being held by a fruit company in Cupertino (ticker symbol AAPL) (large-ish organization that serves a very small fraction of the IP-using community) is probably a very poor use of resources. OTOH, /8s held by various large ISPs actually serve very large fractions of the internet community in the region. Organization size alone is not an effective measure of benefit offered to the community for addresses consumed.<div><br></div><div>The current policy does not "advantage" large organizations in any way. True, you can't fill as many large requests from the remaining free pool as you can smaller requests, but the reality is that customer growth is likely to be roughly the same over the same period of time regardless of whether those customers are connected to a few large providers or a whole lot of smaller ones.</div><div><br></div><div>Preventing larger providers from obtaining addresses for their customers in order to protect the abilities of smaller providers to serve smaller blocks of customers is arguably not so much leveling the playing field as it is creating an advantage for smaller providers at the expense of larger ones.<br><blockquote type="cite"><div><div dir="ltr"><div><ol style="list-style-type:lower-alpha" start="3"><li>Does not make any specific provisions for new entrants. The authors
feel that this might advantage existing organizations at the expense of
new entrants.</li></ol></div></div></div></blockquote><div>Please explain why this is a bad thing? Why should we create additional hardships for existing organizations with real needs now on the basis that there might be some other organization that doesn't even exist now which might need addresses at some later date?</div><div><br></div><div>It would be akin to having a tank of potable water and refusing to allow thirsty people to fill their canteens because there might be a drought next year.</div><div><br></div><div>If your IPv4 need doesn't already exist, then it's probably a really bad time to be considering starting a business that depends on IPv4. We need to move beyond this idea that we can somehow continue to artificially extend the useful life of IPv4 and stop helping people buy into this illusion that IPv6 is an optional change.</div><div><br></div><div>Anyone who hasn't already figured these things out from the 20+ years of warning and 4+ years of post-IANA-depletion experience that we now have really doesn't deserve special policy consideration moving forward.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>
<p></p>
<h3>2. Summary of how this proposal addresses the problem</h3>
<p>This proposals tries to address these problems by:<span style="background-color:rgb(221,221,221)"> </span></p>
<ul><li>Reducing the maximum prefix in phase 1. We arrived at this figure by
looking at the average allocation prefix. We found the average to be
between /17 and /16.</li></ul></div></div></div></blockquote>Reducing the maximum prefix to match the average allocation size simply guarantees that you are knee-capping the top 50% of providers in the region to subsidize the bottom 50%.<br><blockquote type="cite"><div><div dir="ltr"><div><ul><li>Disallowing allocation to organisations who have been allocated up to the maximum prefixes during each phase for certain duration.</li></ul></div></div></div></blockquote>This simply insures that the knee-capping in the previous provision has maximal effect on a potentially expanded fraction of the community.<br><blockquote type="cite"><div><div dir="ltr"><div><ul><li>Adjusted the maximum prefix for phase 2, to bring it closer to average allocation size.</li></ul></div></div></div></blockquote>It's not entirely clear whether that is an expansion or a reduction in the maximum prefix size, nor am I sure it matters given the above flaws.</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div><div dir="ltr"><div>
<p></p>
<h3>3. Proposal</h3>
<p><strong>Modify Section 5.4.3.1 of the CPM to the following:</strong></p>
<p>Exhaustion Phase 1:</p>
<p>During this phase, allocation/assignment of address space will
continue as in the Current phase (/24 for a EU and /22 for a LIR) but
the maximum will change from /10 to /16.</p>
<p></p>
<p><strong>Modify Section 5.4.3.2 of the CPM to the following :</strong></p>
<p>Exhaustion Phase 2</p>
<p>During this phase a minimum allocation/assignment size will be /24, and the maximum will be /20 per allocation/assignment.</p>
<p><strong>Modify section 5.4.4 of the CPM to the following:</strong></p>
<p>For any LIR or End User requesting IPv4 address space during the Exhaustion phases:</p>
<p> 5.4.4.1 An organization may request additional IPv4 address space in
both Phase 1 and Phase 2. However, such an organisation's total
allocations/assignments must not exceed the maximum allowable prefix of
/16 for Exhaustion Phase 1 and /20 for Exhaustion Phase 2.</p>
<p> 5.4.4.2 Notwithstanding 5.4.4.1, an organization that has received
the maximum allowable prefix in each phase may request for another round
of allocation/assignment in the same phase (as per 5.4.4.1), after a 36
calendar months waiting period.</p>
<p> 4. Revision History</p><p>Version 2.0</p>
<ul><li>Modification of maximum prefix allowed during phase 1 based on staff analysis and community feedback</li><li>Modification of section 2 of the proposal, specifically to provide
justification for change in prefix which is based on community feedback
and staff analysis</li><li>Re-wording and renumbering of section 5.4.4, specifically to
provide more clarity based on community feedback and ensure that
exhaustion is steady enough. It also ensures that new entrants are
granted sufficient opportunity to acquire space by disallowing early
return of existing members who have reached their maximum prefix in the
respective phases.</li><li>Addition of revision history to section 4</li></ul></div><End Draft><br><div>Draft url: <a href="http://afrinic.net/en/community/policy-development/policy-proposals/2055-soft-landing-sd">http://afrinic.net/en/community/policy-development/policy-proposals/2055-soft-landing-sd</a><br><br><br>-- <br><div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">------------------------------------------------------------------------<br><font color="#888888"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:garamond,serif">
<i><span style="color:rgb(0,102,0)">Seun Ojedeji,<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Federal University Oye-Ekiti<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">web: </span><a href="http://www.fuoye.edu.ng" target="_blank">http://www.fuoye.edu.ng</a><br>
<span style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Mobile: <a value="+2348035233535">+2348035233535</a></span><span style="color:rgb(0,102,0)"></span><br></i><i><span style="color:rgb(0,102,0)">alt email:<a href="http://goog_1872880453" target="_blank"> </a><a href="mailto:seun.ojedeji@fuoye.edu.ng" target="_blank">seun.ojedeji@fuoye.edu.ng</a></span></i><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bringing another down does not take you up - think about your action!<br></blockquote></blockquote></font><br></div></div></div></div></div></div>
</div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>RPD mailing list</span><br><span><a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a></span><br><span><a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a></span><br></div></blockquote></div></body></html>