[rpd] New Proposal - "Soft Landing - BIS (AFPUB-2016-V4-001-DRAFT-01)"

[Andrew Alston]

Comments inline

> 3.1 The policy proposal changes clause/article 3.5.1 of the current IPv4 Soft Landing Policy to:
> 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.

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)

> For the avoidance of doubt all applications that will be in process at this point will be evaluated as per the new policy.

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.

> 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,
> new  LIRs or End-Users can receive only one allocation/assignment from the new LIRs or End-Users reserved pool.

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.

> 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.

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.

> 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

  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.


> Critical infrastructure are ICANN-sanctioned DNS root server operators, IXPs, TLD (Top Level Domain) operators, IANA and RIRs.
>   On application for IPv4 resources, an Internet Exchange Point (IXP) will receive one number resource (maximum /23) according to the following:
>    This space will be used to run an Internet Exchange Point peering LAN; other uses are forbidden.
>    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
>   utilization requires) assignment.
>    IP space returned by Internet Exchange Points will be added to the reserved pool maintained for use by Internet Exchange Points.

All of the above is covered under AFPUB-2014-GEN-004-DRAFT-03 and hence should be scrapped since its a duplication.

> 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
> (maximum /22).

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).

> 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
> might happen. Therefore, it is prudent to keep this block in reserve, just in case some future requirement creates a demand for IPv4 addresses.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160209/09c75ccf/attachment.html>