[address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN
<ripe-wgs at 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