<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It is unclear from the positioning and wording of 5.4.4 whether this applies beginning with the applicability of 5.4.3 (or rather at the implementation of this policy), or beginning upon triggering 5.4.3.2, or at some point after 5.4.3.2.<div class=""><br class=""></div><div class="">It’s also (IMHO) better if we define the beginning of exhaustion phase 2 as part of 5.4.3.2 rather than as part of 5.4.3.1.</div><div class=""><br class=""></div><div class="">I do commend the authors for addressing most of my concerns in redrafting this proposal. I’m still rather unconvinced that the problem statement represents an actual problem to be solved, but I am no longer so opposed to the adoption of the actual policy text.</div><div class=""><br class=""></div><div class="">I am opposed to allowing Core DNS service providers in 5.4.6 as they are not part of facilitating IPv6 deployment (or at least their IPv4 usage is not).</div><div class=""><br class=""></div><div class="">There is no limit to the number of times an organization may obtain a /24 under 5.4.6. I believe this is contrary to its intended use and purpose.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 18, 2017, at 15:41 , Dewole Ajao <<a href="mailto:dewole@forum.org.ng" class="">dewole@forum.org.ng</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  

    <meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class=""><p class=""> Dear PDWG members,<br class="">
      <br class="">
      This is to inform you that authors of the policy proposal named "
      <meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
      IPv4 Soft Landing-bis" have submitted an updated version as
      displayed below and online at <a class="moz-txt-link-freetext" href="https://afrinic.net/en/community/policy-development/policy-proposals/2073-internet-number-resources-review-by-afrinic">https://afrinic.net/en/community/policy-development/policy-proposals/2075-ipv4-soft-landing-bis</a><br class="">
    </p><p class="">Please take some time to go through the proposal contents and
      provide your feedback.</p>
    Thank you.<br class="">
    PDWG Co-Chairs<br class="">
    <br class="">
    ----------<br class="">
    Unique identifier (assigned by AFRINIC):AFPUB-2016-V4-001-DRAFT-01<br class="">
    <br class="">
    Draft Policy Name: IPv4 Soft Landing-bis<br class="">
    Author(s)<br class="">
         (a) Omo Oaiya | <a class="moz-txt-link-abbreviated" href="mailto:Omo.Oaiya@wacren.net|">Omo.Oaiya@wacren.net|</a> WACREN<br class="">
         (b) Joe Kimaili  | <a class="moz-txt-link-abbreviated" href="mailto:jkimaili@ubuntunet.net">jkimaili@ubuntunet.net</a>  | Ubuntunet Alliance<br class="">
         (c) Alain P. AINA  | <a class="moz-txt-link-abbreviated" href="mailto:aalain@trstech.net">aalain@trstech.net</a> | Technologies Reseaux
    et Solutions<br class="">
    <br class="">
    <br class="">
    Draft Policy Version 4.0<br class="">
    <br class="">
    Submission Date  04/14/2017<br class="">
    <br class="">
    Related Policies (where applicable)<br class="">
    <br class="">
    Obsoletes :Section 5.4 of the Policy manual  -
<a class="moz-txt-link-freetext" href="https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4">https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4</a><br class="">
    <br class="">
    <br class="">
    1.0 Summary of the Problem Being Addressed by this Policy Proposal<br class="">
    The soft-landing policy ratified by the board on the 11/11/2011
    describes how AFRINIC should manage allocations/assignments from the
    last /8. It defines 2 phases for the IPv4 exhaustion. During phase
    1, it sets the maximum to be /13 instead of /10 and in phase 2, the
    maximum to /22 and the minimum to /24. It makes no difference
    between existing LIRs or End-Users and new ones. The policy also
    does not impose IPv6 deployment.<br class="">
     <br class="">
    IPv4 exhaustion in other regions combined with other factors has
    imposed huge pressure on the AFRINIC IPv4 pool with requests for
    large IPv4 blocks, with very little IPv6 deployment. The pressure on
    the AFRINIC IPv4 pool has led to some policy proposals to reserve
    some blocks for certain sub-communities.<br class="">
     <br class="">
    2.0 Summary of How this Proposal Addresses the Problem<br class="">
    This policy proposal solves the problem described above by:<br class="">
    Changing the value of the maximum of allocations/assignment size
    during the exhaustion phase 1<br class="">
    Removing minimum allocation size as this may evolve over time during
    the exhaustion period<br class="">
    Reserving a dedicated block to facilitate IPv6 deployment<br class="">
    <br class="">
    3.0 The Proposal<br class="">
    3.1 Policy Manual section to be affected:<br class="">
    Section 5.4 of the CPM will be replaced as follows:<br class="">
     <br class="">
    5.4 Soft Landing<br class="">
    This proposal describes how AFRINIC shall assign, allocate, and
    manage IPv4 resources during the "Exhaustion Phase" which begins
    when AFRINIC first needs to assign or allocate IP addresses from the
    Final /8 block of IPv4 address space.<br class="">
     <br class="">
    5.4.1 Definitions<br class="">
    <br class="">
    Local Internet Registry (LIR) - A Local Internet Registry (LIR) is
    an Internet Registry (IR) that receives allocations from an RIR and
    assigns address space to customers who use its services. LIRs are
    generally ISPs and their customers are end-users and possibly other
    ISPs. LIRs must be members of an RIR like AFRINIC; which serves the
    Africa Region and part of the Indian Ocean (Comoros, Madagascar,
    Mauritius, and Seychelles).<br class="">
    <br class="">
    Existing LIR's - An Existing LIR is a LIR that assigns address space
    to 'end-users' and has already been allocated IPv4 address space by
    AFRINIC.<br class="">
    <br class="">
    New LIR - A New LIR, is a LIR that assigns address space to
    'end-users' and is a member of AFRINIC, but has not been allocated
    any IPv4 address space prior to the Exhaustion phase.<br class="">
    <br class="">
    Existing “End User” - An “End User” is an organisation that has
    already been assigned IPv4 space by AFRINIC for use in its
    operational networks.<br class="">
    <br class="">
    New “End User” -  A new “End User” is an End User who is member of
    AFRINIC, but has not been assigned any IPv4 address space prior to
    the Exhaustion phase.<br class="">
    <br class="">
    Final /8 block of IPv4 address space, or "Final /8" - The Final /8
    block of IPv4 address space, or "Final /8", is the /8 block of IPv4
    address space that has been allocated by the IANA to AFRINIC in
    terms of section 2.2 C of the Global Policy for the Allocation of
    the Remaining IPv4 Address Space<br class="">
    <br class="">
    Core DNS service provider:  A core DNS service provider is an
    organisation that provides DNS service for the root level of the DNS
    tree (ICANN-sanctioned root operators) or for an ICANN-sanctioned
    African ccTLD operating in AFRINIC service Region.<br class="">
     <br class="">
    5.4.2 Pre-Exhaustion Phase<br class="">
    The "Pre-Exhaustion phase" was the period during which AFRINIC
    allocated or assigned IPv4 addresses to LIRs and End Users using the
    section 5.0 of the policy manual and before the Exhaustion phase was
    triggered.<br class="">
    This phase ended when AFRINIC publicly announced that the Exhaustion
    Phase has begun.<br class="">
     <br class="">
    5.4.3 Exhaustion Phase<br class="">
    During the Exhaustion Phase, the following allocation and assignment
    policy will be used. This policy applies to both LIRs and End Users,
    and applies to all IPv4 address space allocated, assigned, or
    otherwise managed by AFRINIC during the transition to and after the
    beginning of the Exhaustion Phase, regardless of whether or not such
    IPv4 address space is a part of the Final /8. The exhaustion phase
    will be divided into two parts:<br class="">
     <br class="">
    5.4.3.1 Exhaustion Phase 1<br class="">
    During this phase, allocation/assignment of address space will
    continue as in the Pre-Exhaustion with no explicit minimum but the
    maximum will change from /10 to /18.<br class="">
    Allocations and assignments will be made from the Final /8 or from
    any other IPv4 address space available to AFRINIC, until no more
    than a /11 of non-reserved space is available in the Final /8. At
    this point the exhaustion phase 2 will begin.<br class="">
    For the avoidance of doubt all applications in the process at this
    point will be evaluated as per the new policy <br class="">
     <br class="">
    5.4.3.2 Exhaustion Phase 2<br class="">
    During this phase the maximum allocation/assignment size will be
    /22.<br class="">
    There is no explicit limit on the number of times an organisation
    may request additional IPv4 address space during the Exhaustion
    Period<br class="">
     <br class="">
    5.4.4 The allocation and assignment period shall be of 8 months.<br class="">
    The allocation and assignment period shall be of 8 months. This will
    help to ensure that LIRs request only for resources they need in the
    short to medium term, and promote fairness in the equitable
    distribution of the last IPv4 address pool. This
    allocation/assignment period will remain the same throughout the
    life span of this Policy<br class="">
     <br class="">
    5.4.5 Allocation Criteria<br class="">
    In order to receive IPv4 allocations or assignments during the
    Exhaustion Phase, the LIR or End User must meet IPv4 allocations or
    assignment policies requirements and have used at least 90% of all
    previous allocations or assignments (including those made during
    both the Pre-Exhaustion and the Exhaustion Phase).<br class="">
    In the case of new LIRs or End Users with no previous allocations or
    assignments, this requirement does not apply to their first
    allocation or assignment request.<br class="">
    AFRINIC resources are for AFRINIC service region and any use outside
    the region should be solely in support of connectivity back to the
    AFRINIC region<br class="">
     <br class="">
    5.4.6 IPv6 deployment reserve<br class="">
    A contiguous /12 IPv4 address block will be reserved out of the
    Final /8 to facilitate IPv6 deployment. When AFRINIC, can no longer
    meet any more requests for address space (from the Final /8 or from
    any other available address space), allocations and assignments from
    this block must be justified by needs for IPv4 addresses space to
    support IPv6 deployment. Examples of such needs include: [IPv4
    addresses for Core DNS service providers dual stack DNS servers,
    464XLAT translators or any other translators as defined by the IETF.
    This block will be subject to a maximum size allocation of /24.<br class="">
     <br class="">
    AFRINIC staff will use their discretion when evaluating
    justifications and should use sparse allocation when possible within
    that /12 block.<br class="">
     <br class="">
    In order to receive an allocation or assignment from the IPv6
    deployment reserve:<br class="">
    The applicant may not have received resources under this policy in
    the preceding six (6) months;<br class="">
    The applicant must demonstrate that no other allocations or
    assignments will meet this need.<br class="">
     <br class="">
    4.0 Revision History<br class="">
     <br class="">
    09 FEB 2016<br class="">
    AFPUB-2016-V4-001-DRAFT01 (Version 1.0)<br class="">
    Version 1 posted to the rpd mailing list<br class="">
    <br class="">
    16 FEB 2016<br class="">
    AFPUB-2016-V4-001-DRAFT02 (Version 2.0):<br class="">
    A complete new version of the section 3 and so the policy proposal
    now obsoletes the existing IPv4 Soft landing policy instead of
    amending it.<br class="">
    <br class="">
    22 JUL 2016<br class="">
    AFPUB-2016-V4-001-DRAFT03 (Version 3.0):<br class="">
    Maximum Allocation/Assignment size changed from /15 to /18 in phase
    1 as per discussions at AFRINC-24 public policy meeting and follow
    on discussions on RPD.<br class="">
    <br class="">
    14 APR 2017<br class="">
    AFPUB-2016-V4-001-DRAFT04 (Version 4.0)<br class="">
    Updated version based on consensus from online and AFRINIC-25
    discussions.<br class="">
    Formatted for direct insertion to CPM<br class="">
    “current Phase” replaced by “Pre-exhaustion Phase”<br class="">
     No more direct reserve for critical Internet Infrastructures<br class="">
    No more direct reserve for New entrants<br class="">
    A dedicated reserve to facilitate IPv6 deployment<br class="">
     <br class="">
    5.0 References<br class="">
    Global Policy for the Allocation of the remaining IPv4 address
    pool: 
    <a class="moz-txt-link-freetext" href="http://www.afrinic.net/en/library/policies/135-afpub-2009-v4-001">http://www.AFRINIC.net/en/library/policies/135-afpub-2009-v4-001</a><br class="">
    <br class="">
  </div>

_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></div></blockquote></div><br class=""></div></body></html>