[address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

Dear Riccardo,

(I am responding on behalf of Andrea, who is currently traveling).

We just wanted to confirm that Hans Petter and Roger are correct. The 
policy text you quoted was designed to allow address space to be 
returned to IANA. It does not refer to the way that the RIPE NCC should 
allocate from our available IPv4 pool.

With the current policy, the RIPE NCC does not distinguish between 
address space in our available IPv4 pool on the basis of where it came 
from. We are currently allocating from 185/8 mainly for simplicity, and 
to allow a long quarantine period for returned address space. The RIPE 
NCC started to allocate from 185/8 on 14 September 2012, when we could 
no longer satisfy a request for address space without touching 185/8. 
That moment triggered section 5.1 that states that RIPE NCC members can 
request a one time /22 allocation (1,024 IPv4 addresses).

I hope this helps.

Best regards,

Ingrid Wijte
Assistant Manager Registration Services
RIPE NCC

On 20/04/2016 11:53, Riccardo Gori wrote:
> Hi Roger,
>
> Il 20/04/2016 11:00, Roger Jørgensen ha scritto:
>> On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen<hph at oslo.net>  wrote:
>>> On 16.04.2016 12.29,remco.vanmook at gmail.com  wrote:
>>>> This confusion has been haunting the final /8 policy from day one - it was
>>>> never about what to do with specifically 185/8, but what to do with all
>>>> future allocations from the moment we needed to start allocating out of it.
>>>> The policy text itself was never limited to a single /8, nor was that
>>>> limitation any part of the discussion.
>> It was a name for the point in time when it would be activated, and it would
>> stay there until there was no IPv4 left to hand out.
>>
>>
>>> I looked up the policy proposal at
>>> https://www.ripe.net/participate/policies/proposals/2010-02
>>>
>>> " This proposal describes how the RIPE NCC should distribute IPv4 address
>>> space from the final /8 address block it receives from the IANA."
>> Not the best wording back there it seems...
>>
>>
>>> Reading the rest of the proposal I fully understand the confusion and find
>>> it hard to read your interpretation into the proposal.
>>>
>>> The updated policy after this proposal can be found in RIPE 509
>>> https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations
>>> * The following policies come into effect as soon as RIPE NCC is required to
>>> make allocations from the final /8 it receives from the IANA.
>>>
>>> It does not discuss the event where RIPE NCC gets more address space and
>>> could allocate from - which would strictly speaking not be allocation from
>>> the last /8
>> somewhere along the way, I think, but haven't found it yet, it was
>> said that this
>> policy would get activated when they got the last /8 from IANA, that was the
>> intention. Whatever happend after _that_ point in time, would be covered by
>> that policy. That part was to cover what you mention next...
>
> Are you sure? I mean, when 185/8 has been reiceved from IANA:
> There was some space around left on the free pool and it has been 
> allocated under the same "last /8 policy" from that moment or followed 
> its own old path?
> I am serius since I wasn't here at that time and I don't really know 
> what happened.
> Andrea, can you help me understand what happened to available pool is 
> any when 185/8 was reiceved by IANA?
> please understand I signed up 01/2015, when exacly took place the 
> first allocation made under "last /8" policy?
> any help would be appreciated
> thanks
> Riccardo
>
>>
>>> Tracing the policy text trough the versions - This text was first removed
>>> between
>>> * RIPE 599 published on 20 December 2013
>>> https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations
>>> and
>>> * RIPE 604 - published on 4 Feb 2014:
>>> https://www.ripe.net/publications/docs/ripe-604
>>>
>>> Where the text was changed to:
>>>
>>> The size of the allocation made will be exactly one /22.
>>> The sum of all allocations made to a single LIR by the RIPE NCC after the
>>> 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a
>>> single /22 or the equivalent thereof).
>> The side story behind this is probably related to that it was assumed that
>> IANA would get some address space back, address space they again could
>> redistribute to the LIR. When slized up it would at some point not be possible
>> to hand out /22's, only smaller blocks that could add upto a /22.
>> All that would be addresses covered by "the last /8 policy", the runout policy.
>>
>>
>>> and no reference to the last /8.
>>>
>>> So I can easily understand the confusion.
>> The intention was that once the policy was activated it would be there for all
>> future until there was no IPv4 left. It was just called "the last /8 policy"
>> since that's how it started out, the activation point.
>>
>>
>>
>> (I can't find referenced to all of this but it is somewhere in the archives, and
>> guess Geert or you can find it all? Wonder if it might be somewhere in the
>> IETF space or so this was discussed to?)
>>
>
> -- 
> Ing. Riccardo Gori
> e-mail:rgori at wirem.net
> Mobile:  +39 339 8925947
> Mobile:  +34 602 009 437
> Profile:https://it.linkedin.com/in/riccardo-gori-74201943
> WIREM Fiber Revolution
> Net-IT s.r.l.
> Via Cesare Montanari, 2
> 47521 Cesena (FC)
> Tel +39 0547 1955485
> Fax +39 0547 1950285
>
> --------------------------------------------------------------------
> 	CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please contact us by re-
> plying toinfo at wirem.net
>          Thank you
> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
> --------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160420/ed343ebb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160420/ed343ebb/attachment.jpe>