Hi Elvis and all, I fully agree with your reason for not agreeing with this proposal, mainly the fact that it acts retroactively. The only problem I see with your reason is that it would have fully applied to 2015-01, in the exact same manner. LIRs received an allocation knowing they will be able to transfer it if needed/wanted, and all of a sudden, they became nontransferable for 2 years, aplicable to resources already allocated. If the policy only applied to resources allocated after the adoption of the policy, there would have been no such problem. Difference of course is that with this proposal, the final allocation will NEVER be transferable via the RIPE standard transfer process. And in this case, the aplicability to only the resources allocated after the adoption is a no-go in my opinion, because it will cause tons of confusion and will be very difficult for RIPE NCC to manage.
So, just to reiterate, this policy wants to change the rules of the "game" during the game, which is not ok at all. Since at the time of the allocation (let's say 20th september 2012) these allocations didn't have a special status (except beeing the last allocation received by that LIR from RIPE) and were treated exactly like any other resources previously allocated, this must not ever change. Regardless of the reasons behind the request for the final /22, at the moment of allocation, they were "normal" resources. If in the meantime the LIR does not have a use for those resources anymore, or just considers that it's a better business to cash-in 7-10k euro, they are entitled to do so. Just like with legacy resource holders, they were allocated resources before the RIRs, and they were entitled to keep those resources per the initial conditions of allocation and transfer them, etc. Matei Storch -----Original Message----- From: address-policy-wg [mailto:[email protected]] On Behalf Of Elvis Daniel Velea Sent: Thursday, June 16, 2016 21:03 To: [email protected] Subject: Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy) Hi Remco, On 6/16/16 6:39 PM, Nick Hilliard wrote: > Remco van Mook wrote: >> I would encourage everyone to carefully read this second version (and not >> just respond "no, still hate it, kill it with fire") as it is quite >> different from the first version. Still hate it, kill it! >> Explicitly states that the current IPv4 allocation policy applies to >> all available IPv4 address space held by the RIPE NCC that has not >> been reserved or marked to be returned to IANA > This is probably useful. It would also probably be useful to define a > term to replace the name "last /8" so that it can be referred to > specifically in the policy documentation, e.g. "the remaining > unallocated ipv4 pool" or something along those lines. Totally not as > catchy as "the last /8", but sadly that is the nature of policy. while updating this to a form where it would be very clear is something I applaud, I do not think it is a must. > >> Adds a consideration to the IPv4 allocation policy that the LIR >> should conserve whole or part of their final /22 allocation for >> interoperability purposes > Neutral on this. People will do what they are going to do, even if > it's short-sighted. a good addition, also feeling neutral on telling LIRs what to use the resources for. > >> Bans transfers of final /22 allocations Changes the “status”field in >> the RIPE Database to reflect the transferability of an INETNUM > I'm against this because it conflicts with the core purpose of the > RIPE registry, which is to ensure accurate registration of resources. > Formally banning transfers will not stop transfers; it will only stop > those transfers from being registered which will lead to inaccurate > registry information. could not have said it better. While this is an interesting attempt, it will only drive _some_ transfers to the underground. Bad idea from my point of view. Additionally, it would still apply retroactively and people which since 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after the moment of the allocation) will end up with an allocation that is no longer transferable. I do not like policy proposals that apply retroactively, you should have thought of this in 2012 before the 'run out'. > > Overall, I am against the core proposal, namely banning transfers from > the remaining unallocated ipv4 pool. +1 > Nick > elvis
