<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hello Scott,<br>Thanks for the inputs.....Comments inline<br><br>>It's unclear to me what happens if there remain smaller blocks outside the last /8 at the point a (large) request cannot be met. For example, AfriNIC might have a /17, /19, /22, and four /24s left, when it gets a request for a /16 that it cannot meet. At that point, the policy says that "During the exhaustion phase, the following allocation and assignment policy for the last /8 IPv4 address will be used:", but doesn't specify whether addresses outside the last /8 will also be allocated in this way. Perhaps it would be best to simply strike "the last /8", leaving something like "During the exhaustion phase, the following allocation and assignment policy for IPv4 address will be used". That would also cover any reclaimed space from outside the last
/8.<br>><br><br>The proposal as is only caters for the /8 - there is general argument that the policy tries to do very many things at the same time, but i am personally ok with taking care of address space other than /8 when that time comes. This however is the foundation on which this policy is built hence calling of a fundamental change in overall direction. wonder what everyone else thinks......<br><br>>You might want to specify conditions for exiting the exhaustion phase someday (when sufficient space has been reclaimed and/or IPv4 demand has dwindled).<br>><br><br>It's my thinking that at this point everyone should have moved to IPv6 hence there shouldn't be any need for addressing space bigger than what the exhaustion phase can provide<br><br>>It's unclear to me how many times an existing LIR can come back for address space in the exhaustion phase. The Summary section's mention of 4 allocations seems to apply to everyone, but
under Allocation Criteria for Existing LIRs it doesn't mention that like it does for New LIRs.<br>><br><br>The Paragraph on Exhaustion phase clearly states 4 allocations......I am editing Existing LIRs to explicitly mention.....as below:-<br><br>An existing LIR may receive a maximum of four (4) address blocks according to the allocation size in effect at the time of allocation in the AfriNIC region. However, the address blocks shall be issued one at a time.<br><br>><br>And some minor nits:<br>><br><br>Yes, the definition of LIR was adopted from existing documentation --- i have edited the definition....to:-<br><br>A Local Internet Registry (LIR) is an Internet Registry (IR) that receives allocations from an RIR and assigns address space to customers who use it's 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><br>Is this better ?<br><br>>You might want to have the definitions for "Existing LIR" and "New LIR" simply reference the LIR definition rather than repeating the "defined<br>><br><br>Noted, adopted<br><br>>You should probably replace all instances of "LIR's" that are plural and not possessive with "LIRs".<br>><br><br>Noted, adopted<br><br>Regards,<br>Douglas Onyango +256(0712)981329<br>
Life is the educators practical joke in which you spend the first half learning, and the second half learning that everything you learned in the first was wrong.<br><br>--- On <b>Fri, 5/14/10, Scott Leibrand <i><scottleibrand@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Scott Leibrand <scottleibrand@gmail.com><br>Subject: Re: [AfriNIC-rpd] IPv4 Soft Landing Policy<br>To: rpd@afrinic.net<br>Date: Friday, May 14, 2010, 9:20 PM<br><br><div id="yiv2120713027">
Douglas,<br>
<br>
I'll hold off for now on expressing a position on the overall issue of
whether rationing IPv4 space in this manner is an improvement over
current AfriNIC policy. There are good arguments on both sides, and
the question of where to strike the balance depends a lot on the
characteristics of the Internet market in Africa, which I don't
understand all that well, being from outside the region.<br>
<br>
The text looks good overall. A few comments:<br>
<br>
It's unclear to me what happens if there remain smaller blocks outside
the last /8 at the point a (large) request cannot be met. For example,
AfriNIC might have a /17, /19, /22, and four /24s left, when it gets a
request for a /16 that it cannot meet. At that point, the policy says
that "During the exhaustion phase, the following allocation and
assignment policy for the last /8 IPv4 address will be used:", but
doesn't specify whether addresses outside the last /8 will also be
allocated in this way. Perhaps it would be best to simply strike "the
last /8", leaving something like "During the exhaustion phase, the
following allocation and assignment policy for IPv4 address will be
used". That would also cover any reclaimed space from outside the last
/8.<br>
<br>
You might want to specify conditions for exiting the exhaustion phase
someday (when sufficient space has been reclaimed and/or IPv4 demand
has dwindled).<br>
<br>
It's unclear to me how many times an existing LIR can come back for
address space in the exhaustion phase. The Summary section's mention
of 4 allocations seems to apply to everyone, but under Allocation
Criteria for Existing LIRs it doesn't mention that like it does for New
LIRs.<br>
<br>
It appears that there is no time limit on how frequently a New LIR can
come back for space. You may well have them getting a /23, using it
immediately, and coming right back for another block. You might want
to at least make sure that AfriNIC reserves the entire contiguous /21
for them, to avoid extra routes in the table. <br>
<br>
And some minor nits:<br>
<br>
I noticed an apparent contradiction in the definition of LIR: "A Local
Internet Registry (LIR) is an Internet Registry (IR) that
receives allocations from an RIR and primarily sub-allocates or assigns
address space to 'end-users'. LIRs are generally ISPs. Their customers
are other ISPs and possibly end-users." Specifically, "primarily
sub-allocates or assigns
address space to 'end-users'" seems to conflict with "Their customers
are other ISPs and possibly end-users." It looks like you inherited
that
definition from AFPUB-2005-v4-001, but it might be worthwhile to
clarify that
while we're at it. :-)<br>
<br>
You might want to have the definitions for "Existing LIR" and "New LIR"
simply reference the LIR definition rather than repeating the "defined
as being an organization that assigns address space to 'end-users'"
part. So, for example, "An existing LIR is an LIR that has already
been assigned or allocated IPv4 address space by AfriNIC."<br>
<br>
You should probably replace all instances of "LIR's" that are plural
and not possessive with "LIRs".<br>
<br>
-Scott<br>
<br>
On Wed 5/12/2010 10:18 AM, Douglas Onyango wrote:
<blockquote type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font: inherit;" valign="top">Hello all,<br>
I am presenting the latest version of the proposal for your review in
preparation for the the face-to-face meeting that is a couple of weeks
away.<br>
Your input in required<br>
<br>
==================================================================<br>
Your Name: Douglas Onyango<br>
Your Organisation: Delta IT Solutions<br>
Policy Afected: AFPUB-2005-v4-001<br>
Date: 27-11-09<br>
<br>
Proposal: IPv4 Soft Landing Policy<br>
<br>
Incentive<br>
------------<br>
In order to ensure a smooth transition from IPv4 to IPv6, the lifespan
of IPv4 can be increased in order to give network operators more time
to make the transition. This document proposes a strategy for
allocation and maintenance of AfriNIC's final /8 block of IPv4 from
IANA.<br>
<br>
Background<br>
---------------<br>
Following the much anticipated IPv4 pool exhaustion, a global policy,
"Global Policy for the Allocation of the Remaining IPv4 Address Space",
has been ratified. The policy ensures that IANA reserves one (1) IPv4
/8 address block for each RIR. Details of the Global Policy for the
Allocation of the Remaining IPv4 Address Space can be found at:
<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-v4gp200802.html">http://www.afrinic.net/docs/policies/afpol-v4gp200802.html</a>.<br>
This policy (IPv4 Soft Landing) applies to the management of address
space that will be available to AfriNIC under this Global Policy<br>
The purpose of this document is to ensure that this last block is used
in a manner that is acceptable by the AfriNIC community.<br>
Policy Documents to be affected:<br>
--------------<br>
<br>
(a) IPv4 Allocation Policy
<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm">http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm</a><br>
(b) Proposal to Change the Allocation & Assignment Period to 12
months <a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-af200611.htm">http://www.afrinic.net/docs/policies/afpol-af200611.htm</a><br>
Definitions<br>
--------------<br>
(a) Local Internet Registry (LIR)<br>
<br>
A Local Internet Registry (LIR) is an Internet Registry (IR) that
receives allocations from an RIR and primarily sub-allocates or assigns
address space to 'end-users'. LIRs are generally ISPs. Their customers
are other ISPs and possibly end-users. 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>
<br>
(b) Existing LIR�s An existing LIR is defined as being an organization
that assigns address space to 'end-users' and who has already been
assigned or allocated IPv4 address space by AfriNIC.<br>
<br>
(c) New LIR�s A new LIR is defined as being an organization that
assigns address<br>
space to 'end-users' and who is a member of AfriNIC but has not been
assigned or<br>
allocated any IPv4 address space prior to the Exhaustion phase.<br>
<br>
Summary<br>
------------<br>
This proposal describes how AfriNIC shall allocate and manage IPv4
resources from the last /8 block of IPv4 address allocated by IANA at
the time of total depletion of the IANA IPv4 address free pool.<br>
(i) Current Phase:<br>
<br>
During this phase, AfriNIC will continue allocating IPv4 addresses to
the LIR's using the current allocation policy
<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm">http://www.afrinic.net/docs/policies/afpol-v4200407-000.htm</a>. This phase
will continue until a request for IPv4 address space from any LIR to
AfriNIC either cannot be fulfilled with the IPv4 address space
available in the AfriNIC pool (with the exception of the last allocated
/8 address block from IANA) or can be fulfilled but leaving the AfriNIC
IPv4 address pool empty (with the exception of the last allocated /8
address block from IANA).This will be the last IPv4 address space
request that AfriNIC will accept from any LIR in the Current Phase,
AfriNIC, will declare that the Exhaustion Phase has begun at this point.<br>
(ii) Exhaustion Phase:<br>
<br>
During the exhaustion phase, the following allocation and assignment
policy for the last /8 IPv4 address will be used:<br>
a) Instead of the /22 block (1024) addresses allocated in the current
policy, the new minimum allocation size of /24 (256 addresses) will be
allocated to any LIR that qualifies for IPv4 resources - /23 (512)
will be the maximum allocation size possible and even though LIRs may
request for more than this, LIRs will not be able to get more a /23 in
a single allocation - they also will not get more than 4 allocations
once the Exhaustion phase has began.<br>
<br>
b) Together with the v4 allocation, AfriNIC shall allocate an IPv6
address block in compliance with the current IPv6 allocation policy
(<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>) to the
LIR (in case it doesn't have any).<br>
The current allocation and assignment period of 12 months shall be
changed to 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.<br>
Allocation Criteria<br>
---------------------<br>
a) Existing LIR's<br>
<br>
At the time of the first IPv4 allocation made during the exhaustion
phase, AfriNIC shall also allocate an IPv6 address block in compliance
with the current IPv6 allocation policy
(<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm">http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm</a>) to the
LIR. In order to receive additional IPv4 allocations in the exhaustion
phase, the existing LIR must have used at least 90% of all previous
allocations.<br>
b) New LIR's<br>
<br>
Each New LIR will receive IPv4 addresses which they can use for
supporting legacy IPv4 services to ensure their full presence on the
IPv4 Internet during the transition to IPv6. The following will apply:<br>
Upon application, a New LIR may receive a maximum of four (4) address
blocks according to the allocation size in effect at the time of
allocation in the AfriNIC region. However, the address blocks shall be
issued one at a time.<br>
In order to receive additional IPv4 allocations, the New LIR should
have used at least 90% of the previous allocations from the exhaustion
phase.<br>
New LIRs may apply for and receive this allocation once they meet the
criteria to receive IPv4 address space according to the policy in
effect at the time.<br>
IPv4 Address Space Reserve<br>
---------------------------------<br>
A /12 IPv4 address block will be in reserve out of the last /8 pool.
This /12 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.<br>
<br>
When AfriNIC can no longer meet any more requests for address space
from the last /8 pool because the pool is either empty or has no more
contiguous blocks, the board will based on the demand and other factors
at the time exercise the prerogative to replenish the exhaustion pool
from the reserve pool in a manner that is in the best interest of the
community.<br>
<br>
AfriNIC resources are for the AfriNIC geographical region. None of
these resources can be used outside of the AfriNIC region. All LIR's
requesting resources must have operations in Africa and all of the
allocations shall be used to support the LIR's African Operations.<br>
==================================================================<br>
<br>
Regards,<br>
Douglas Onyango +256(0712)981329<br>
Life is the educators practical joke in which you spend the first half
learning, and the second half learning that everything you learned in
the first was wrong.</td>
</tr>
</tbody>
</table>
<br>
<pre><fieldset class="mimeAttachmentHeader"></fieldset><br>_______________________________________________<br>rpd mailing list<br><a rel="nofollow" class="moz-txt-link-abbreviated" ymailto="mailto:rpd@afrinic.net" target="_blank" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br> </pre>
</blockquote>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="/mc/compose?to=rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br></div></blockquote></td></tr></table><br>