On Thu, 28 Sep 2017, Radu-Adrian FEURDEAN wrote:
Hi All,
Hi, Thanks for your input!
I oppose this proposal. My reasons, or at least most of them, have explained by other people during the last week: - maintaining a lack of incentive for IPv6 deployment ("still have some IPv4")
The proposal tries to remain neutral about that. But you are not alone on this point.
- forcing desegregation, as if the problem is not bad enough already, and possibility to make things even worse (by creating new pretext for "longer than /24 in GRT").
Any prefix can be split into /24s and still remain globally routable. Going beyond /24 is really not in this proposal. A new proposal would be needed for that...
I would also add some other reasons: - community's duty/responsibility for future generations : apart what it has already been discussed (get v4 on the market, get it from upstream, or even "really need to get v4 ?"), we are representing here the RIP*E* community, with limited geographical scope. However, the policy is quite lax at the moment concerning the out-of-region use of resources, basically allowing an out-of-region entity to get resources with a sole promise to use *some* of them in-continent.
If you disagree with the current "lax" status, why not build a new proposal? We don't need to address everything with just one proposal...
- this brings us to the next point : with RIPE region being for the moment the second-richest RIR (v4-wise) and the lax rules regarding out-of-region use, I would not like RIPE NCC to become the world's "last resort" registry for v4 resources (or any other resources for that matter).
It's a valid viewpoint. I would also agree with "less lax", but that would be a different proposal.
And if I were to agree with the proposal (which is not the case right now), I would say that some thresholds should be used. Like /10 or /11 available for /23 allocations and /12 available for /24. Under no circumstance /24 now.
I can also agree with that, but it's just a matter of sizing it. If v2.0, v3.0, v4.0, ... is eventually approved/adopted, it may be that there isn't a /12 to do this anymore... So, we really didn't focus in the task of establishing barriers/boundaries. But we might consider this for v2.0, if it helps. :-) Best Regards, Carlos Friaças
-- Radu-Adrian FEURDEAN