This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Splitting 2015-05 in two
- Previous message (by thread): [address-policy-wg] agreement
- Next message (by thread): [address-policy-wg] Splitting 2015-05 in two
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Radu-Adrian FEURDEAN
ripe-wgs at radu-adrian.feurdean.net
Sat May 14 09:35:38 CEST 2016
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, 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). 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.
- Previous message (by thread): [address-policy-wg] agreement
- Next message (by thread): [address-policy-wg] Splitting 2015-05 in two
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]