> 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.
Douglas Onyango +256(0712)981329
If you are not part of the solution, you are part of the Problem.
--- On Tue, 9/22/09, Scott Leibrand <[email protected]> wrote:
From: Scott Leibrand <[email protected]>
Subject: Re: [AfriNIC-rpd] IPv4 Softlanding Policy
To: "Douglas Onyango" <[email protected]>
Date: Tuesday, September 22, 2009, 7:27 PM
Excellent. I hope you get some constructive feedback and participation.
-Scott
Douglas Onyango wrote:
> Hi Scott,
> I have taken note of all the contributions. i agree with some of them,
> but still will see what comes with consensus.
>
_______________________________________________
rpd mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo.cgi/rpd
