<div dir="ltr">Hi<div><br></div><div>Few commons I like to contribute(my personal view not represent my company as my company has no interest in this):</div><div><br></div><div>1. If there is an transfer policy, please make sure that the last /22 received was none-transferable for X amount of time(as it was an loophole in RIPE region and take quite a bit effects to close afterwards, and we can prevent it from beginning.)</div><div><br></div><div>2. I would suggest adding FIFO to the "near depletion" for the fair process, and reduce staff burden on the matter. An "near depletion" can be defines as an application is larger than current "free space" left in the pool( better definition is welcome of course)</div><div><br></div><div>3. Removing location requirement for the last /22 and allow companies world wide come to get the last /22, and expanding the reserved allocation to /10, might help Afrinic have a stable financial future.(1000USD/ member for 1000 IPs, a /10 can generate 4 millions USD per yaer revenue for Afrinic, in which would double it's current budget without African organizations paying anything).</div><div><br></div><div>All above are my personal ideas and hope community can help me to improve it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 6:58 AM, Andrew Alston <span dir="ltr"><<a href="mailto:Andrew.Alston@liquidtelecom.com" target="_blank">Andrew.Alston@liquidtelecom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
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.<br>
<br>
In addition to this, a clarification point was added in section 3.5.1 to avoid any ambiguity.<br>
<br>
Please see below for the updated draft which we have submitted to the PDWG Co-Chairs.<br>
<br>
Andrew<br>
<br>
AFPUB-2016-V4-002-DRAFT02<br>
Soft Landing Overhaul<br>
<br>
Authors:<br>
a. Andrew Alston, <a href="mailto:andrew.alston@liquidtelecom.com">andrew.alston@liquidtelecom.com</a><br>
b. Kris Seeburn, <a href="mailto:seeburn.k@gmail.com">seeburn.k@gmail.com</a><br>
c. Mark Elkins, <a href="mailto:mje@posix.co.za">mje@posix.co.za</a><br>
d. Michele McCann, <a href="mailto:michele@teraco.co.za">michele@teraco.co.za</a><br>
e. John Walubengo, <a href="mailto:jwalu@yahoo.com">jwalu@yahoo.com</a><br>
<br>
Draft Policy Version: 02<br>
Submission Date: 13 February 2016<br>
Status: Under Discussion<br>
Amends: AFPUB-2010-v4-005 (IPv4 soft landing policy)<br>
<br>
1) Introduction<br>
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<br>
form may actually damage the interests of the AFRINIC community rather than assist it.<br>
<br>
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.<br>
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<br>
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.<br>
<br>
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.<br>
<br>
<br>
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<br>
through standard demand, and hence encourages the uptake of IPv6 in a more aggressive manner.<br>
<br>
3) The Proposal<br>
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<br>
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.<br>
<br>
3.1) Policy Documents to be affected<br>
* IPv4 Allocation Policy<br>
<br>
3.2) Definitions<br>
* Local Internet Registry (LIR) - A Local Internet Registry (LIR) is an Internet Registry (IR) that<br>
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<br>
members of an RIR like AfriNIC; which serves the Africa Region and part of the Indian Ocean (Comoros, Madagascar, Mauritius, and Seychelles).<br>
<br>
* Existing LIR's - An Existing LIR is a LIR that assigns address space to 'end-users' and has already<br>
been assigned or allocated IPv4 address space by AfriNIC.<br>
<br>
* End User - An End User is an organization that receives assignments of IP addresses exclusively<br>
for use in its operational networks<br>
<br>
* New Entrant - Ether a member of new member that at the time of application had no previous<br>
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.<br>
<br>
* New Entrant Block - A /13 block of IPv4 space, reserved in entirety, for allocations of space to<br>
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<br>
increase in those allocations to provide sufficient space to allocate to new members for a period of 2 years.<br>
<br>
* Additional and Reclaimed Space - All IPv4 address blocks recovered from non-paying members,<br>
as well as all allocations of address space made to AFRINIC by IANA or a replacement organisation".<br>
<br>
3.3) Summary<br>
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,<br>
as defined in the definition above.<br>
<br>
3.4) Current Phase<br>
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<br>
IPv4 allocation policies as determined by the community through the policy development working group.<br>
<br>
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.<br>
<br>
<br>
3.5) New Entrant Specification<br>
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<br>
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<br>
say that applications will be processed in the order in which they are received.<br>
New Entrant applications with regards to justifications must conform to current IPv4 allocation policies as defined by the community.<br>
<br>
3.5.1) CLARIFICATIONS AND OTHER POINTS<br>
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<br>
the New Entrant definition.<br>
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<br>
cannot be fulfilled.<br>
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<br>
available as an alternative.<br>
<br>
4) HISTORY<br>
<br>
13.02.2016 - Proposal in new form with modifications resubmitted to the PDWG Chairs and posted to the mailing list by Andrew Alston<br>
12.02.2016 - Proposal in its initial form posted to the mailing list by Andrew Alston<br>
<br>
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.<br>
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<br>
<br>
<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>--<br>Kind regards.<br>Lu<br><br></div></div></div>
</div></div>