On Sat, May 14, 2016 at 9:35 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:

On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
> If it were my proposal, here's how I would go about it.
>
> Withdraw the current proposal.
> The proposer can always do this during the process.
>
> Introduce two new proposals (2016-somenumber and 2016-someothernumber)
> respectively containing the "Part A" and "Part B" material from the
> current proposal.

Hello,

As the proposal was written,

Yep, and this is why the suggestion starts with "withdraw the current proposal", also because that will make it easier to proceed.

the "part B" (allocation condition
including v6 deployment) would have no sense on its own, since it only
applies to the results of "part A" (further allocations).

This is indeed a weakness of the current proposal.

In order to have a "part B" that makes any sens, it would mean that
current rules for allocation of the "first /22 from last /8" would have
to change:
- for a "real" first allocation (LIR that never received a v4
allocation before) either conditions would not apply, or a new system
would have to be created where the allocation is time-limited, and at
the end of time limit the allocated block is either returned (condition
not met) or made "regular allocation" (condition met).
- for LIRs that had previously allocated IPv4 space, condition applied
directly.

This seems like putting the cart before the horse.

Allocation conditions should be introduced _first_, as a "part A".

Then a separate proposal for additional allocations should be introduced _second_, as a "part B".

This corresponds well to your own claim that your proposal intends to preserve the pool, and should not deplete it rapidly, and will perhaps even make it possible to proceed.

To me, this is the test of whether you actually stand by that claim.

Jan