[AfriNIC-rpd] Re: [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool.

[Vincent Ngundi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remarkable foresight!

If I read the policy right, do you suggest that we retain the current  
IANA allocation policy and instead concentrate on life after the  
depletion of IPv4 in the IANA pool?

Regards,

- -Vincent

On Oct 30, 2007, at 10:40 PM, Tony Hain wrote:

> Policy Proposal Name: 	 Cooperative distribution of the end of the  
> IPv4
> free pool.
>
> Author name:  Tony Hain
> email:  alh-ietf at tndh.net
> telephone:  +1-425-468-1061
> organization:  Cisco Systems
> Proposal Version:  1.0
> Submission Date: Oct-30-2007
> Proposal type:  new
> Policy term:  permanent
>
> Policy summary:
> This policy will establish a process for RIR-to-RIR redistribution  
> of the
> tail-end of the IPv4 pool, taking effect after the IANA Reserve is
> exhausted. Each redistribution Allocation will be triggered by the  
> recipient
> RIR depleting its reserve to a 30 day supply, and will result in up  
> to a 3
> month supply being transferred from the RIR with the longest  
> remaining time
> before it exhausts its own pool.
>
> Policy statement:
> At the point when any given RIR is within 30 days of depleting its  
> remaining
> IPv4 pool, a survey will be taken of the other 4 to determine the  
> remaining
> time before each of them exhausts their pool (including both member  
> use and
> recent redistribution allocations to other RIRs). The one with the  
> longest
> window before exhausting its pool will be designated as the source  
> RIR. The
> recipient RIR will follow procedures for an LIR in the source RIR  
> region to
> request a block that is expected to be sufficient for up to 3  
> months, but is
> no larger than 1/8th of the source RIR's remaining pool. At the  
> point where
> no RIR can supply a block that is less than 1/8th of their  
> remaining pool
> that will sustain the recipient RIR for 30 days, the recipient RIR  
> will
> collect its requests each week, and forward those individual  
> requests to the
> source RIR designated that week.
>
> Rationale:
> This policy will establish a mechanism for the Allocation of IPv4  
> address
> blocks between RIR's, but will not go into effect until the IANA  
> pool has
> been depleted.
>
> It is really bizarre to watch the maneuvering as the global RIR  
> community
> grapples with 'fairness' of distributing the last few IANA Reserve /8
> blocks. On one level this just appears to be petty sibling rivalry, as
> people are bickering over who gets the last cookie and whimpering  
> about
> 'fairness'. At the same time, each RIR is chartered to look after the
> interests of its membership so it is to be expected that they will  
> each want
> to get as much as possible to meet the needs of their respective  
> membership.
> Existing practice requires RIR's to acquire blocks from IANA, which  
> leads to
> the current round of nonsense about optimal distribution of the  
> remaining
> pool based on elaborate mathematical models.
>
> This globally submitted policy proposal attempts to resolve the  
> issue by
> shifting to an RIR-to-RIR Allocation model after the IANA pool is  
> depleted.
> This policy would effectively result in each RIR becoming a virtual  
> LIR
> member of all of the other RIR's for the sole purpose of managing the
> tail-end of the IPv4 pool.
>
> Timetable for implementation: 	Before 1/1/2009
>
>
>

- --
KeNIC - The Kenya Network Information Center
http://www.kenic.or.ke


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHKPAChPC3Z8cZxdsRAsbpAJ9QCtMgO6fbPhg5pHtjJzWVt8kf+QCgqu70
77KKjoP4KqBpGKQ59JE0NV8=
=k/EN
-----END PGP SIGNATURE-----