<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    A new policy proposal updating 5.4 of the Consolidated Policy Manual
    (CPM) has been received as follows, and is now open for discussions:<br>
    <div class="moz-forward-container"> <br>
      <p>Policy Proposal: Soft Landing SD<br>
        <br>
        ——————————————————————————————————————————————————————<br>
        ID: AFPUB2017V4001DRAFT01<br>
        Submission Date: 30 March 2017<br>
        Version: 1<br>
        Author(s: <br>
        Douglas Onyango (ondouglas at gmail.com)<br>
        Seun Ojedeji (seun.ojedeji at gmail.com)<br>
        Amends : Soft Landing Policy CPM 5.4 <br>
        ——————————————————————————————————————————————————————<br>
      </p>
      <p><br>
        1. Summary of the problem being addressed by this proposal<br>
        <br>
        The current SoftLanding Policy describes how AFRINIC should
        manage allocations/assignments from the last /8.<br>
        <br>
        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. Specifically, the
        current Softlanding Policy:<br>
        <br>
        a. 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.<br>
        b. 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.<br>
        c. Does not make any specific provisions for new entrants. The
        authors feel that this might advantage existing organizations at
        the expense of new entrants.<br>
        <br>
        2. Summary of how this proposal addresses the problem<br>
        <br>
        This proposals tries to address these problems by:<br>
        * Reducing the maximum prefix in phase 1. We arrived at this
        figure by looking at the average allocation prefix which is
        between /19 and /18 and then doubling that average allocation.<br>
        * Disallowing allocation to organisations who have been
        allocated up to the maximum prefixes during each phase.<br>
        * Adjusted the maximum prefix for phase 2, to bring it closer to
        average allocation size<br>
        <br>
        3. Proposal<br>
        <br>
        Modify Section 5.4.3.1 of the CPM to the following:<br>
        <br>
        Exhaustion Phase 1:<br>
        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 /17.<br>
        <br>
        Modify Section 5.4.3.2 of the CPM to the following :<br>
        <br>
        Exhaustion Phase 2<br>
        During this phase a minimum allocation/assignment size will be
        /24, and the maximum will be /20 per allocation/assignment.<br>
        <br>
        Modify section 5.4.4 of the CPM to the following:<br>
        For any LIR or End User requesting IPv4 address space during the
        Exhaustion There is no explicit limit on the number of times an
        organization may request additional IPv4 address space, so long
        as such organisation has not received allocations/assignments
        equivalent to the maximum prefix during<br>
        each phase.<br>
        <br>
        4. Revision History</p>
      <p> N/A</p>
      <p><br>
      </p>
      <p><br>
      </p>
    </div>
  </body>
</html>