<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">


        <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.0  (Linux)"><meta name="CREATED" content="20090923;12595200"><meta name="CHANGED" content="16010101;0">
        
        
        
        
        <style type="text/css">
        <!--
                @page { size: 8.5in 11in; margin: 0.79in }
                P { margin-bottom: 0.08in }
        -->
        </style>

<pre>> a) Instead of the /22 block (1024) addresses allocated in the current policy, the new minimum allocation size of /23 (512 addresses) will be allocated to any LIR that qualifies for IPv4 resources.
> 

>This could be construed to mean that any LIR that requests resources gets them automatically.  You might want to say "any LIR that is approved for" rather than just "requests".
>
Noted!


>This statement that the 90% usage criterion (only) applies to allocations from the last /8 would seem to create a loophole.  If an organization gets a /23 and uses that up, but has a bunch of free space in their non-exhaustion-phase allocations, it would seem that they can get another /23 based solely on the exhaustion-phase usage without regard to overall usage.  I'm not sure if that's what you intended, but if not, you might want to just have it say something like "90% of all previous allocations."
>
I agree with this, effected the changes.

> In the event that the reserved /16 IPv4 address block remains unused by the time the remaining /8 address space covered by this policy has been allocated to LIRs, it returns to the pool to be distributed in compliance with this policy.
> 

>It would seem that this clause would defeat the purpose of having the reservation in the first place.  In other words, the /16 wouldn't really be "reserved" if it is thrown back in the general pool as soon as the general pool is fully allocated.
>

I share this view, i think the point  is  when addresses run out from the exhaustion pool, we shall really need these addresses and yet as stated in the policy we can also not neglect to think of posterity.

I can see two possible options here, (1) Just return the /16 back to the exhaustion pool when it dries up in which case our future plan would have only been 2/3 years give or take. 

(2) Or we can have a smaller number like /18 - 16384 (32 – allocations of /23) for posterity and the rest /12 (i believe) actually comes back to the pool for distribution – I believe we shall still be at peace with the “Route aggregation enthusiasts” and still have foresight. I wonder if anyone has a comment or different thought.
</pre>
<br><br>Douglas Onyango +256(0712)981329<br>
If you are not part of the solution, you are part of the Problem.<br><br>--- On <b>Tue, 9/22/09, 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 Softlanding Policy<br>To: "Douglas Onyango" <ondouglas@yahoo.com><br>Date: Tuesday, September 22, 2009, 7:27 PM<br><br><div class="plainMail">Excellent.  I hope you get some constructive feedback and participation.<br><br>-Scott<br><br>Douglas Onyango wrote:<br>> Hi Scott,<br>> I have taken note of all the contributions. i agree with some of them, <br>> but still will see what comes with consensus.<br>><br><br></div></blockquote></td></tr></table><br>