[address-policy-wg] About the /22 allocation limitation

Hi,

On Wed, Apr 09, 2014 at 06:39:51PM +0200, Dpto. Datos Television Costa Blanca wrote:
> I know and its ok the currect policy, but everybody should be ok too 
> with what I said.
> Marco Schmidt, Policy Development Officer, have been in touch with me 
> and told me to see this:
> http://www.apnic.net/policy/proposals/prop-105
> http://www.apnic.net/__data/assets/text_file/0006/62763/prop-105-v002.txt

Well, different regions are different, and this hasn't reached consensus
in APNIC region yet.

We've consciously decided that our last-/8 policy is a "no return" policy,
to ensure new entrants in the market can still have *some* IPv4, even if
they come in 5 years or 10 years time from now.

If you think you can convince the community that we should now go and
change it back, well, this is what the policy development process is for
- but I don't think the chances are good.  Of course everyone wants more
IPv4 addresses, but nobody wants anyone *else* to take away those last 
bits from him...

[..]
> Should we do a proposal like the APNIC's one? If yes, I would at least 
> set conditions for recieving a new block, and setting the minimun 
> allocation to /24 instead of /22.

I know at least one community member who would violently object to the
RIPE NCC hand out /24 allocations, because that would be fairly bad for
the global routing table.  This time, I would actually agree with him.

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

SpaceNet AG                        Vorstand: 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20140409/435eb57c/attachment.sig>