<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;">
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>Comments inline</div>
<div><br>
</div>
<div>> 3.1 The policy proposal changes clause/article 3.5.1 of the current IPv4 Soft Landing Policy to:</div>
</div>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">> 3.5.1 EXHAUSTION PHASE 1During this phase,allocation/assignment of address space will continue as in the Current phase with no explicit minimum but the maximum will change from /10 to /15.<br>
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
While I understand the rationale for this, I’d like to see some justification of the number chosen.  /15? /14? /16? Whats the rationale of the author over the specific number chosen (not that I object, Im just trying to understand)</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr"><br>
> For the avoidance of doubt all applications that will be in process at this point will be evaluated as per the new policy.<br>
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
This is HIGHLY problematic.  To my knowledge applications are not processed on a first in first out basis.  Smaller “easier” applications are processed far faster than larger applications.  This means that if we hit soft landing due to small applications, a
 large application that is taking time to process will be bound by soft landing, irrespective of the fact that the large application may have been submitted long before the application that pushes us into soft landing.  I’d argue that this isn’t fair and could
 result in potential legal complications.  The only way this will work is if there is a commitment that all applications are processed on a FIFO basis, which will drastically slow down the allocation process.</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr"><br>
> 3.6 If any LIR or End User requests IPv4 address space during Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during Exhaustion Phase 1. During exhaustion Phase 2,
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
> new  LIRs or End-Users can receive only one allocation/assignment from the new LIRs or End-Users reserved pool.</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
I have reservations about this lack of a limit, in my view it kinda defeats the nature of the policy and will lead to abuse.  If we’re gonna go through this process of amending this, I’d rather see a hard limit.  Let me give you an example, if a mobile network
 with a few million subscribers needs address space, they could realistically submit /15 application after /15 application burning the space to DE-NAT on the same day its issued, resulting in 10 applications once after another.  Same guy still gets all the
 space, policy is defeated.</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
 </div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">> LIRs and End users requesting IPv4 space must have IPv6 resources from AFRINIC (or request IPv6 concurrently with their IPv4 request), or from their upstream providers.<br>
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
I find this kind of toothless, if we’re gonna demand V6 anything to get V4, it must be accompanied with a V6 addressing plan or a demonstration of IPv6 usage out of the space they have.  There is no point in demanding they have it, without a point of demanding
 that they USE it.  Either scrap this, or get people to show how they are actively deploying it (preferably more than just a v6 deployment in the core that does no one any good).  I’m agnostic over which option though, scrap the requirement or expand it.</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr"><br>
> AFRINIC resources are for the AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region<br>
<br>
  I object to this requirement for the same reasons I have objected to other policies that have tried to do this.  There is simply no way to enforce it and there is no definition as of yet that defines what “use inside the region” means or how its qualified.
  Without a definition of that, that explains the nature of geographic usage, I cannot support this policy.</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr"><br>
> Critical infrastructure are ICANN-sanctioned DNS root server operators, IXPs, TLD (Top Level Domain) operators, IANA and RIRs.<br>
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
>   On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (maximum /23) according to the following:</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">>    This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.<br>
>    New Internet Exchange points will be assigned a maximum of /24.  Internet exchange points may return this assignment (or existing PI used as in the IXP peering LAN) should they run out of space and receive a larger (a maximum of /23 if
</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
>   utilization requires) assignment.</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div dir="ltr">>    IP space returned by Internet Exchange Points will be added to the reserved pool maintained for use by Internet Exchange Points.<br>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<br>
</div>
<div><font face="Calibri,sans-serif" style="color: rgb(0, 0, 0); font-size: 14px;">All of the above is covered under</font><font face="Calibri"> <span style="line-height: 16.2px; widows: 1;">AFPUB-2014-GEN-004-DRAFT-03 and hence should be scrapped since its
 a duplication.</span></font></div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div dir="ltr"><br>
</div>
</span><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">> A /14 from the final /11 will be held in reserve for exclusive use by new LIRs or End-Users with no prior IPv4 address space from AFRINIC.  On application for IPv4 resources, a new LIR or End-User may receive one number resource</div>
</div>
</div>
</span>
<div>> <span style="font-family: Calibri, sans-serif; font-size: 14px;">(maximum /22).</span></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">While I have no fundamental objection to this clause, a word of warning.  RIPE did this, and from what I’ve heard, it resulted in an explosion of membership numbers as companies were registered just to get space.  It is however great for AFRINIC
 finances if this happens (and if you look at what happened in RIPE once this part of their policy kicked in, look at their membership numbers and the amount of money brought in as a result of those members going up and you’ll see what I mean).<br>
 <br>
> A /13 IPv4 address block will be in reserved out of the Final /8. This /13 IPv4 address block shall be preserved by AFRINIC for some future uses, as yet unforeseen. The Internet is innovative and we cannot predict with certainty what
</div>
</div>
</div>
</span>
<div>> <span style="font-family: Calibri, sans-serif; font-size: 14px;">might happen. Therefore, it is prudent to keep this block in reserve, just in case some future requirement creates a demand for IPv4 addresses.</span></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr">I have a major issue with this, future of the Internet is IPv6, we need to start to realise that, and this clause runs contrary to that.  If we’re locking in space for some future unforeseen circumstance, we’re kidding ourselves that we’re serious
 about the fact that Ipv6 is the future.  </div>
</div>
</div>
</span>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div dir="ltr"><br>
</div>
</div>
</div>
</span>
</body>
</html>