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

[Martin Millnert]

On Mon, 2015-09-14 at 09:51 +0200, Gert Doering wrote:
> IPv4 exhaustion is inevitable.

s/is inevitable/has already occured/g

IPv4 is by any practical standard; bankrupt.

/M - almost out of popcorns

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

[Sander Steffann]

Hi,

> 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 ?

While I like this idea, please do realise that a /8 has 16384 /22s in it. RIPE 
NCC has more than 12000 LIRs at the moment. Many of those would already qualify 
for an additional allocation based on this. That could drain the pool in a very 
short time...

> 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) ?

Re-introducing different allocation sizes would also mean going back to a 
needs-based system. I'm not sure we want to add that overhead/bureaucracy 
again. A lot of people were quite happy with 2013-03. Changing the size to a 
/24 for further allocations would extend the lifetime of the pool, but on the 
other hand I'm not sure if handing them a /24 every x months will really help 
many LIRs, and the routing overhead will be a lot more interesting...

So while I am happy to see work being done on this, I am still a bit cautious. 
But I'd love to be shown wrong :)

Cheers,
Sander

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

[Radu-Adrian FEURDEAN]

On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote:

> At my previous company, we joined RIPE as a LIR specifically because
> there was no other way to get our own IPv4 address space.  As a smaller
> orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_
> to provide serivces to our users.

This is pretty much the situation at my present company.

> I support the existing policy, and are very concerned with any proposal
> that would encourage faster exhaustion of the IPv4 space.
> 
> I respectfully disagree with the assertion that the existing last /8
> policy is painful for everyone.e

It depends : if you need more than a /22 it is (very) painful, if you
don't - it's not.
And don't forget that some people are still arguing that the last /8
policy is to be used as a workaround until IPv6 becomes a useful option.
Unfortunately, with the current stocks of available addresses, for a lot
of people it doesn't work this way.

--
Radu-Adrian FEURDEAN
fr.ccs

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

[Sascha Luck [ml]]

On Mon, Sep 14, 2015 at 09:17:04AM +0200, Radu-Adrian FEURDEAN wrote:

Before submitting the proposal we would like to have some community
feedback on several aspects :


My thoughts:

1) anything that increases the bureaucracy required to deal with
the NCC for a first allocation is a non-goer.

2) I could live with giving a LIR which has only received an
"austerity /22" another shot after a certain time, but I'd couple
it with some proof of ipv6 deployment (beyond just advertising a
/32)

3) The edge case of a LIR not needing the full /22 can be handled
by the transfer market. If you still think you don't need the
other three /24s after 24 months, sell them.

rgds,
Sascha Luck

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

[Tore Anderson]

* "Radu-Adrian FEURDEAN" 

> On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote:
> > Is there any urgency in getting closer to full exhaustion (i.e., no
> > remaining austerity pool)? Is full exhaustion somehow less painful than
> > the current status quo?
> > 
> > I guess we can look at the ARIN region, as they'll reach that point in
> > the coming weeks. If that situation turns out to benefit their
> > community somehow (like increasing the IPv6 deployment rate), I'm
> > willing to be persuaded that we should open the floodgates and get rid
> > of our austerity pool ASAP. I'm sceptical this will be the case, though.
> 
> I do think that it will push towards more serious IPv6 deployment
> (beyond "get the /29 or /32, announce it into the GRT, deployment
> successful").

If your goal is to get rid of the IPv4 austerity pool as quickly as
possible, that could be accomplished much more quickly and efficiently
than creating a "side pool" with associated rules for allocation. Some
possibilities:

* Re-instate additional allocations with "needs basis" and it'll be
  gone in a few weeks
* Return everything to IANA and decline further allocations from the
  Recovery pool
* Divide it up equally between all members and allocate everything at
  once
* Divide it up between all members based on the current amount of IPv4
  addresses held and allocate everything at once
* Divide it up equally between all members holding a five-star RIPENess
  rating and allocate it all at once
* Auction it all off to the highest bidder(s), use proceeds to reduce
  membership fees, give a cash return to members, or donate it to
  charity

IFF it could be demonstrated clearly that it would help further IPv6
deployment, I'd be willing to be persuaded into supporting a policy
proposal which leads to the rapid depletion of the austerity pool, thus
bringing us in line with ARIN.

Regarding the side pool idea specifically, an interesting post appeared
today on APNIC's policy list, which had the following to say about
their side pool:

«2. Status of IANA Recovered pool (non-103)
   - Will run out in next 7 months+
   - IANA may allocate additional space in every 6 months
   - This pool will repeatedly ‘run-out’ as IANA delegates more space
 and it is distributed by APNIC»

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/09/msg00025.html

I don't think duplicating this in our region would be helpful at all.

> > > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
> > > RIPE still has more than 0.98 of a /8 available (more likely 0.99).
> > 
> > And those three years we've delegated just shy of a /9:
> 
> Which makes the "austerity pool" (I would rather call it "waste pool")
> available for about 5-6 more years.

In my opinion that would the optimal outcome, and precisely the reason
why I do not support creating a side austerity pool or changing the
allocation criteria for the main austerity pool at this point in time.

Tore

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

[Sascha Luck [ml]]

On Mon, Sep 14, 2015 at 03:49:24PM +0200, Radu-Adrian FEURDEAN wrote:

On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote:

If you have some ideas of how to reliably determine "real ipv6
deployment" *AND* write down that criteria in a policy-friendly way,
you're welcome (want to be part of the proposal ? - ok).


I know that it's not likely we could come up with something that
is 100% reliable. I was thinking along the lines of a statement
in the allocation request like: "We have deployed IPv6 to our
customers and we are using $technology to do it." combined with a
mini-audit focusing on ipv6 assignments.

I know this could be gamed but it may serve as a gentle nudge in
the direction of at least making *some* effort towards ipv6
deployment.

rgds,
Sascha Luck

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

[Carsten Schiefner]

Richard, all -

On 14.09.2015 10:14, Richard Hartmann wrote:
> On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN
>  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.

how about combining this by treating all addresses equal in a single
pool, but advising the NCC to hand out recovered addresses first unless
there are specific, yet-to-be-defined reasons that they rather need to
come from the 185/8 heap?

Cheers,

-C.

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

[Radu-Adrian FEURDEAN]

On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote:
> 1) anything that increases the bureaucracy required to deal with
> the NCC for a first allocation is a non-goer.
> 
> 2) I could live with giving a LIR which has only received an
> "austerity /22" another shot after a certain time, but I'd couple
> it with some proof of ipv6 deployment (beyond just advertising a
> /32)

If you have some ideas of how to reliably determine "real ipv6
deployment" *AND* write down that criteria in a policy-friendly way,
you're welcome (want to be part of the proposal ? - ok).

--
Radu-Adrian FEURDEAN
fr.ccs

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

[Aleksey Bulgakov]

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-...@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
>
>

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

[Gert Doering]

Hi,

On Mon, Sep 14, 2015 at 10:36:22AM +0300, Aleksey Bulgakov wrote:
> 2015-01 has been approved to prevent IPv4 exhaustion  

Mostly to prevent policy abuse.

IPv4 exhaustion is inevitable.

Gert Doering
-- APWG chair
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


pgpqi5dyIFXDZ.pgp
Description: PGP signature

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

[Mikael Abrahamsson]

On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote:


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 )


Interesting presentation. There are some points there I was no aware of.

I would be interested in getting an educated guess what would happen if we 
went with the following policy:


You get /20 to /24 depending on need/want instead of /22 for everybody.

This would apply until we have last-/10 where we then go to /22-/24 
depending on need/want. We would treat recovered pool the same as last /8, 
it's just treated as "addresses" so /10 is "/10 worth of adresses".


My goal is still to have IPv4 addresses according to this policy by 2020.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

[Tore Anderson]

* "Radu-Adrian FEURDEAN" 

> 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

B. KISS.

> 2. Conditions for allocation the first /22.
>   - none (keep the situation as it is today - our preferred option)
>   - something else (please detail)

Maintain the status quo.

> 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 ???

None of the above. My preference is to maintain the status quo - no
additional allocations. I do not quite see why we should change the
«last /8» policy which in my view has been quite successful (except for
the abuse that 2015-01 hopefully helps shut down).

If it ain't broke, don't fix it?

Unless we interpret «broke» to mean «exhausted». If so, c'est la vie.

Tore

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

[Radu-Adrian FEURDEAN]

On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote:
> >   b. treat all addressing space available for allocation as a single pool
> B. KISS.
> 
> > 2. Conditions for allocation the first /22.
> Maintain the status quo.

Point taken.

> > 3. Further allocation(s) (after the first /22)
> None of the above. My preference is to maintain the status quo - no
> additional allocations. I do not quite see why we should change the
> «last /8» policy which in my view has been quite successful (except for
> the abuse that 2015-01 hopefully helps shut down).
> 
> If it ain't broke, don't fix it?
> 
> Unless we interpret «broke» to mean «exhausted». If so, c'est la vie.

I take "broken" as "painful and far enough from exhaustion", so in need
of a fix.
Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
RIPE still has more than 0.98 of a /8 available (more likely 0.99).

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

[Peter Hessler]

On 2015 Sep 14 (Mon) at 10:41:44 +0200 (+0200), Radu-Adrian FEURDEAN wrote:
:On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote:
:> > 3. Further allocation(s) (after the first /22)
:> None of the above. My preference is to maintain the status quo - no
:> additional allocations. I do not quite see why we should change the
:> ??last /8?? policy which in my view has been quite successful (except for
:> the abuse that 2015-01 hopefully helps shut down).
:> 
:> If it ain't broke, don't fix it?
:> 
:> Unless we interpret ??broke?? to mean ??exhausted??. If so, c'est la vie.
:
:I take "broken" as "painful and far enough from exhaustion", so in need
:of a fix.
:Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
:RIPE still has more than 0.98 of a /8 available (more likely 0.99).
:

At my previous company, we joined RIPE as a LIR specifically because
there was no other way to get our own IPv4 address space.  As a smaller
orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_
to provide serivces to our users.

I support the existing policy, and are very concerned with any proposal
that would encourage faster exhaustion of the IPv4 space.

I respectfully disagree with the assertion that the existing last /8
policy is painful for everyone.e

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

[Tore Anderson]

* "Radu-Adrian FEURDEAN" 

> > > 3. Further allocation(s) (after the first /22)
> > None of the above. My preference is to maintain the status quo - no
> > additional allocations. I do not quite see why we should change the
> > «last /8» policy which in my view has been quite successful (except for
> > the abuse that 2015-01 hopefully helps shut down).
> > 
> > If it ain't broke, don't fix it?
> > 
> > Unless we interpret «broke» to mean «exhausted». If so, c'est la vie.
> 
> I take "broken" as "painful and far enough from exhaustion", so in need
> of a fix.

Is there any urgency in getting closer to full exhaustion (i.e., no
remaining austerity pool)? Is full exhaustion somehow less painful than
the current status quo?

I guess we can look at the ARIN region, as they'll reach that point in
the coming weeks. If that situation turns out to benefit their
community somehow (like increasing the IPv6 deployment rate), I'm
willing to be persuaded that we should open the floodgates and get rid
of our austerity pool ASAP. I'm sceptical this will be the case, though.

> Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
> RIPE still has more than 0.98 of a /8 available (more likely 0.99).

And those three years we've delegated just shy of a /9:

http://www.potaroo.net/tools/ipv4/plotend.png

Also, keep in mind that the IANA IPv4 Recovered Address Space pool,
which so far has provided the majority (~4M) of the "new" IPv4
addresses added to the austerity pool since the "last /8" policy was
implemented, has pretty much dried up. There are currently only 163,481
addresses remaining in that pool earmarked to be delegated to the NCC.

In summary I don't think that we can open the faucet any more than it
currently is if we want to be able to give IPv4 for new entrants in
2020.

Tore

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

[Radu-Adrian FEURDEAN]

On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote:
> * "Radu-Adrian FEURDEAN" 
> > I take "broken" as "painful and far enough from exhaustion", so in need
> > of a fix.
> 
> Is there any urgency in getting closer to full exhaustion (i.e., no
> remaining austerity pool)? Is full exhaustion somehow less painful than
> the current status quo?
> 
> I guess we can look at the ARIN region, as they'll reach that point in
> the coming weeks. If that situation turns out to benefit their
> community somehow (like increasing the IPv6 deployment rate), I'm
> willing to be persuaded that we should open the floodgates and get rid
> of our austerity pool ASAP. I'm sceptical this will be the case, though.

I do think that it will push towards more serious IPv6 deployment
(beyond "get the /29 or /32, announce it into the GRT, deployment
successful").

> > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
> > RIPE still has more than 0.98 of a /8 available (more likely 0.99).
> 
> And those three years we've delegated just shy of a /9:

Which makes the "austerity pool" (I would rather call it "waste pool")
available for about 5-6 more years.

> implemented, has pretty much dried up. There are currently only 163,481
> addresses remaining in that pool earmarked to be delegated to the NCC.

I am fully aware of that.

> In summary I don't think that we can open the faucet any more than it
> currently is if we want to be able to give IPv4 for new entrants in
> 2020.

If needed, we can revise things in another 3 years.

--
Radu-Adrian FEURDEAN
fr.ccs

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

[Daniel Stolpe]

On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote:


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


This is the only part I find - and always found - a bit strange. I guess 
it does probably not make a lot of differense in practice, anyone knows 
the actual size of the "recovered pool"?


As the policy was written, once we hit the "last /8" stage there was no 
going back. Even if we for some reason would recover a lot more or start 
delegating E class or whaterver. I think it would be more logical to 
define the "last /8" as the actual last /8 (185/8).


People sometimes ask us whether to return unused address space to the RIPE 
NCC and we always tell them not to because the free pool has become a 
black hole.


But as/if the recovered pool is probably comparatively small, it is not a 
big issue.


Cheers,

Daniel

_
Daniel Stolpe   Tel:  08 - 688 11 81   
sto...@resilans.se
Resilans AB Fax:  08 - 55 00 21 63
http://www.resilans.se/
Box 45 094
556741-1193
104 30 Stockholm

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

[Radu-Adrian FEURDEAN]

On Mon, Sep 14, 2015, at 09:36, Aleksey Bulgakov wrote:
> Hi to all.
> 
> 2015-01 has been approved to prevent IPv4 exhaustion  (Elvis was an

Hello,

More to prevent abuse. Today we "celebrate" 3 years into exhaustion and
the only thing that can be done is make sure things are less painful
until we get rid of the "need for IPv4" by having a fully workable IPv6
Internet (for the moment we don't).

> author). And you suggest to allocate additional blocks now. As told some
> stuffs from the IPRA, here is the conflict, isn't it?

I'm not a broker and not in the transfer business (not at all for now,
and if I ever will, it's highly unlikely for me to be on anything other
than the receiving side).
So I don't see any conflict.

Regards,
--
Radu-Adrian FEURDEAN
fr.ccs

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

[Arash Naderpour]

Hi,

1. separate pool and APNIC-like distribution of additional blocks from
recoved space pool
2. no conditions for first /22 allocation, the goal is distribution of
resources and I can't see any benefit by adding this restriction
3.3.1 I don't think this one is a fair one: "LIR did not perform an outbound
transfer" 
I'm also thinking to prepare a proposal to remove current 24month transfer
wait period (or adjust it), IPs should be transferred easily for a better
utilization and really like to see the community feedback on your proposal. 

Regards,

Arash Naderpour

-Original Message-
From: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] On
Behalf Of Radu-Adrian FEURDEAN
Sent: Monday, September 14, 2015 5:17 PM
To: address-policy-wg@ripe.net
Subject: [address-policy-wg] "last /8" allocation size - community feedback
request before engaging PDP

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