Hi,

This policy may actually reduce the depletion rate for last /8, but without it the last /8 can be used more day by day.
In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?

This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions, so no change in depletion rate from my point of view.

Regards,

Arash Naderpour




On Mon, May 9, 2016 at 10:29 PM, Peter Hessler <phessler@theapt.org> wrote:
On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote:
:Hi Sander,
:
:Il 09/05/2016 10:42, Sander Steffann ha scritto:
:>Hello Ehsan,
:>
:>>we are agree about the Last /8 Allocation Criteria Revision proposal .
:>>https://www.ripe.net/participate/policies/proposals/2015-05
:>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.
:Can you please summarize us the main objections about this 2015-05 policy so
:that people can try to address a solution to those?

My main objection to this proposal is simple:  It depletes the available
pool for _new_ participants faster.  I strongly believe any new actor
should be able to go from zero to non-zero with the addresses available
from RIPE.  For an actor with non-zero addresses to get more addresses,
there is a secondary market.

Since that is the base of my objection, I do not see any way that a
middle ground can be met.  Based on my understanding of the other
objections, I believe this is held by at least a few others from the
objection side.

I appreciate the effort put into this proposal, but I do not think any
solution can be proposed.

(note: my stance is based on forming a LIR simply to get any amount of
announcable addresses.)

--
Quick!!  Act as if nothing has happened!