[address-policy-wg] Splitting 2015-05 in two

On Sat, May 14, 2016 at 9:35 AM, Radu-Adrian FEURDEAN <
ripe-wgs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160514/74989169/attachment.html>