On Mon, May 11, 2015 at 08:14:24PM +0200, Elvis Daniel Velea wrote:
This has already happened before (remember 2007-01?) and it happens with every change of policy..
2007-01 is a good example of why ex post facto changes are a bad idea. This was controversial then and is still controversial today, especially the application to resources long since assigned. Had I known then what I know now, I would have opposed it more stringently.
For example, criteria for making IPv4 assignments, 5 years ago, is no longer the same today, the IPv4 policy has changed several times since 2010 and everything that used to be policy in the past no longer matters, what matters is the latest policy document and not the criteria from years ago.
Well, had "last /8" been applied ex post facto, we would all have had to return our /20s and /16s etc. ;) (and we've seen ideas to that or similar effect floating around on the list these last few weeks!) As a LIR, I would want some security that what was perfectly appropriate last year does not suddenly expose me to sanction because someone decided, after the fact, that it should have been illegal all along. (not this proposal specifically, but the precedent)
It will not be a precedent, the precedent has been already approved years ago.
Thank you for proving my point. Because it was done for 2007-01 it can now be done for 2015-01. So if, next week, the community decides that all allocations > /22 should never have been made, I lose the ones I have already? Because it was already done for 2015-01 which was done because it was already done for 2007-01?
I would not support an implementation that would require the RIPE NCC to apply the same policy differently for an allocation received on the 20th of July vs an allocation received on the 21st of July. This policy proposal's intent is to bring all allocations under the same umbrella (once implemented) and not create more umbrellas..
I'll only apply to allocations made >= 2 years before the implementation date for a maximum of 2 years. Not, IMO, such a problem. rgds, Sascha Luck
