[address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8)

On 16/04/2010 00:49, Philip Smith wrote:
> Hi James,
>
> James Blessing said the following on 13/04/10 23:54 :
>> On 13/04/2010 13:55, Ingrid Wijte wrote:
>>> PDP Number: 2010-02
>>
>> Suggest Revised Text, just tweaking no real impact
>
> Actually, your suggestions are pretty major changes to the policy
> proposal. ;-)
>
>> Allocations from the last /8
>>
>> The distribution of the last /8 held by the RIPE NCC will be done as
>> follows:
>>
>> 1. Unforeseen circumstances pool
>>
>> Once RIPE NCC recieves the final /8 from IANA, a /16 will be held in
>> reserve for some future uses, as yet unforeseen.
>
> In 2010-2, Alain and I proposed that once the RIPE NCC holds the
> *equivalent* of a /8 or less of IPv4 address space, the policy would
> apply. This is different from when RIPE NCC receives the final /8 from
> IANA, as there may well be still be some IPv4 address space remaining in
> other blocks.

Nice idea but I think the trigger point for the change in policy should 
be the receiving of the /8 as its a clear (and very easy to track) 
public point at which the policy changes. If you change policy at the 
point of reach on /8 left then there would be a public announcement that 
could be missed and arguments about RIPE's timing of the announcement.

>> 2. Allocations for LIRs from the last /8
>>
>> On application for IPv4 resources when the RIPE NCC the final /8 has
>> been allocated by IANA to RIPE, LIRs will receive IPv4 addresses
>> according to the following:
>>
>> - LIRs may only receive one allocation from the final /8. The size of
>> the allocation made under this policy will be no larger than a /22.
>> Other space may be provided to the LIR should additional space outside
>> of the final /8 be available at the point of the request.
>
> We actually intended 2010-2 to apply to the remaining equivalent of a
> /8, not the last /8 that RIPE NCC receives from IANA. (For example, this
> could be two /11s from one /8 block, a /10 from another /8 block, and
> one /9 from a third /8 block.) There would be no other IPv4 space left
> at this stage.

My problem is the same as with the previous timing issue, I think that a 
/22 'each' from the last /8 is fine and RIPE can still continue 
allocations from what space was left when the /8 was delivered. The 
alternative is a /22 each from the point at which the /8 is delivered, 
full stop


>> 3. Final Exhaustion
>>
>> In the event that the unforeseen circumstances pool /16 remains unused
>> in the time the final /8 covered by this policy has been distributed, a
>> /15 will be returned to the main pool to be distributed as per clause 2.
>>
>> Once this /15 has been used then the final /15 will also be returned to
>> the pool s should an unforeseen usage have not been found.
>
> I think you mean /16 here, right?

I did indeed mean /17

J
-- 

James Blessing
http://www.despres.co.uk/
07989 039 476
Superbia in Proelio