Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] AFPUB-2016-V4-002-DRAFT02

Owen DeLong owen at
Sat Feb 13 21:45:12 UTC 2016

> On Feb 12, 2016, at 21:58 , Andrew Alston <Andrew.Alston at> wrote:
> Hi All,
> In order to make the policy proposal submitted yesterday more readable, the policy draft has been rewritten to produce a draft that shows the exact final wording without needing to be read in conjunction with the old policy.
> In addition to this, a clarification point was added in section 3.5.1 to avoid any ambiguity.
> Please see below for the updated draft which we have submitted to the PDWG Co-Chairs.
> Andrew
> AFPUB-2016-V4-002-DRAFT02
> Soft Landing Overhaul
>  Authors:
>  a.      Andrew Alston, andrew.alston at
>  b.      Kris Seeburn, seeburn.k at
>  c.      Mark Elkins, mje at
>  d.      Michele McCann, michele at
>  e.      John Walubengo, jwalu at 
>  Draft Policy Version:       02
>  Submission Date:            13 February 2016
>  Status:                     Under Discussion
>  Amends:                     AFPUB-2010-v4-005 (IPv4 soft landing policy)
> 1) Introduction
> At the time when the original soft landing policy was authored, there were many unknowns and circumstances that could not be foreseen, and as a result of this, the policy in its current
> form may actually damage the interests of the AFRINIC community rather than assist it.
> Primary among these, it was not known when the rest of the world would run out of IPv4 space, and the adoption rates of IPv6 were also an unknown quantity.
> While it is acknowledged that there is a need to ensure that new entrants into the IP world may require some small amount of IPv4 space, beyond this, further delaying the depletion of
> IPv4 address space may well be holding the region back while the rest of the world moves on, leaving Africa at a significant disadvantage moving forward.
> In the original policy replaced by this, the numbers and allocation levels were also not based on any fundamental justifications, because of the unknowns that existed at the time.
> 2) Summary of How this Proposal Addresses the Problem This proposal still maintains a block of space reserved for new entrants, but beyond that, it allows for the natural depletion of IPv4 
> through standard demand, and hence encourages the uptake of IPv6 in a more aggressive manner.
> 3) The Proposal
> This policy (IPv4 Soft Landing), applies to the management of address space that will be available to AfriNIC after the current IPv4 pool is depleted. The purpose of this document is to ensure 
> that address space is assigned and/or allocated in a manner that is acceptable to the AfriNIC community especially during this time of IPv4 exhaustion.
> 3.1) Policy Documents to be affected
> *	IPv4 Allocation Policy
> 3.2) Definitions
> *	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).
> *	Existing LIR's - An Existing LIR is a LIR that assigns address space to 'end-users' and has already 
> been assigned or allocated IPv4 address space by AfriNIC.

An LIR should not have been assigned addresses, but strictly allocated.
The previous definition (LIR) is correct. However, you added assigned in this paragraph for reasons passing understanding. Assignments are not eligible for further delegation, but allocations are. An LIR should receive an allocation where an end user receives an assignment.

> *	End User - An End User is an organization that receives assignments of IP addresses exclusively 
> for use in its operational networks
> *	New Entrant - Ether a member of new member that at the time of application had no previous 
> IPv4 allocations or assignments made to them by AFRINIC, and were not holders of legacy IPv4 space or other IPv4 space sourced either through a potential transfer market or other RIR.

I am having trouble parsing “Either a member of new member that at the time…”

I think the intended outcome is: “A member, whether existing or new, who at the time of application had no IPv4 resources registered to them in any of the existing RIR databases.”

> *	New Entrant Block - A /13 block of IPv4 space, reserved in entirety, for allocations of space to 
> members of AFRINIC that at the time of application have no previous IPv4 address allocations.  A /13 was chosen based on historical member growth numbers within AFRINIC, including a certain
> increase in those allocations to provide sufficient space to allocate to new members for a period of 2 years.

As much as I like the 2-year clock, I think it is probably too short and suggest something larger than a /13 may be desirable if we want this to be meaningful. I propose a /10.

> *	Additional and Reclaimed Space - All IPv4 address blocks recovered from non-paying members, 
> as well as all allocations of address space made to AFRINIC by IANA or a replacement organisation”.

IANA is not an organization and cannot be replaced by an organization. IANA is a function (currently operated according to the IANA functions contract from US DOC) which is currently performed by ICANN.

Further, IPv4 blocks may be voluntarily returned to AfriNIC by members who are current on their bills under a variety of circumstance and should not, IMHO, be excluded as they are by the wording above.


*	Additional and Reclaimed Space — All IPv4 address blocks received
	by AfriNIC regardless of source after implementation of this policy.

> 3.3) Summary
> This proposal replaces AFPUB-2010-v4-005 with the effect of repealing most of the original policy and replacing it with a policy that deals only with the final /13 worth of space and new entrants,
> as defined in the definition above.
> 3.4) Current Phase
> The "Current Phase" is the status-quo at the time of the adoption of this policy.  During this phase, AFRINIC will continue allocating or assigning IPv4 address space to LIRs and End Users using current
> IPv4 allocation policies as determined by the community through the policy development working group.
> The current phase will continue until the depletion of IPv4 address space occurs, with the exception of IPv4 reservations as defined by this and other currently in force policies.
> 3.5) New Entrant Specification
> At the time where an application is made that cannot be fulfilled out of the AFRINIC pool, with the exclusion of space reserved by this and other policies, the only applications for IPv4 space which will be
> further considered by AFRINIC will be for New Entrants. The maximum size of a New Entrant allocation will be a /22. New Entrant applications will be processed on a first in first out (FIFO) basis, that is to
> say that applications will be processed in the order in which they are received.
> New Entrant applications with regards to justifications must conform to current IPv4 allocation policies as defined by the community.
> All space falling under the definition of Additional and reclaimed space, as from the time of ratification of this policy, will become part of the new entrant block and will be reserved for members who meet
> the New Entrant definition.
> For the sake of clarity, the policy will be triggered by the application, however, should an application be declared invalid, further processing may continue until once again another application is made that 
> cannot  be fulfilled.  

I oppose this clarification. I believe that once triggered, even if the triggering application is invalid, AfriNIC should deterministically remain in the post-runout state.

> In the event of the final application before depletion of all space outside of the New Entrant Block being too  large to fill from the available space, the applicant shall be offered whatever remaining space is 
> available as an alternative. 

I would propose that the applicant be offered the largest remaining aggregate (up to the size requested) and that the same be done for each applicant in line behind them.

Handing one applicant the entire remaining free pool just because they got their application in a few seconds or hours before the other applicants who may have more modest needs seems less fair to me than giving the largest aggregates possible to the remaining applicants.

> 13.02.2016 - Proposal in new form with modifications resubmitted to the PDWG Chairs and posted to the mailing list by Andrew Alston
> 12.02.2016 - Proposal in its initial form posted to the mailing list by Andrew Alston
> 5) Revision History (for all but the very first draft) Version 1 - Modified to show a full text rather than purely amendment text against the old policy.
> Section 3.3 was modified to replace the original summary from the old policy Section 3.5.1 was renamed to CLARIFICATIONS AND OTHER POINTS, and in addition added clarity on the process to trigger the new entrant block
> _______________________________________________
> RPD mailing list
> RPD at

More information about the RPD mailing list