<div dir="ltr"><div>Dear all,<div dir="auto"><br></div><div dir="auto">We followed all the
discussion on the proposal and appreciate the comments/suggestions
provided. We have therefore reviewed the first draft of "Soft
Landing-SD" proposal accordingly. <br></div><div dir="auto"><br></div><div dir="auto">We
welcome any further comments/suggestion on this draft as applicable.
Specifically we will appreciate statement of support or opposition. In the case of opposition we will appreciate specific reasons for the opposition.<br></div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Seun and Douglas - Co-Authors</div><br></div><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><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><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>
<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><li>Disallowing allocation to organisations who have been allocated up to the maximum prefixes during each phase for certain duration.</li><li>Adjusted the maximum prefix for phase 2, to bring it closer to average allocation size.</li></ul>
<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>