Hi to all. 2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an author). And you suggest to allocate additional blocks now. As told some stuffs from the IPRA, here is the conflict, isn't it? This case community has to cancel 2015-01. 14 сент. 2015 г. 10:17 пользователь "Radu-Adrian FEURDEAN" < ripe-wgs@radu-adrian.feurdean.net> написал:
Hello everybody,
Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf )
Before submitting the proposal we would like to have some community feedback on several aspects :
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail)
3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ???
We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month.
The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :)
Regards, -- Radu-Adrian FEURDEAN fr.ccs