On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
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
The only reason I can see is to keep the unused, continuous blocks in 185.0.0.0/8 if we ever need them for something else and thus try to get rid of the recovered pool first.
2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail)
"First"? This already implies a change afaict.
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 ???
Why change it? This means that everyone will optimize for the maximum size in whatever way they can. And that's without the "I only got /n+1, while foo got /n, that's unfair" and the much-beloved "/n is not enough; let's increase to /n-1 as we already did once" (once==the proposal in this thread). If people want to get something longer than a /22, that might be a valid use case, but I am not convinced there will be enough to merit a pdp for this. Point in case: I helped an entity to become a LIR as they needed one /24. Within two months, they had an actual, valid use case for a second /24. If I had gotten them a /24 instead of a /22, we would then have had to jump through the hoops again. That's why a flat "no need, just /22" policy makes it simpler; even if it's wasteful in some cases. Richard