[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

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
>