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
