I beleive the discussion that also started this was due to RIPE being very strict and overly complicated (in my opinion) about PI assignments. (even the first /24+AS) RIPE suggests a lot of: 'Customer should become LIR himself', even if he doesn't need the /21 in the forseeable future. I think your definition of a LIR is something else then RIPE defines it as. Nevertheless, I do agree with your definition of a LIR and I'd rather see the PI assignments being handled in < /21 allocations, and most definately in another (easier, less time consuming) way when a LIR requests one on behalf of a customer. Gert Doering wrote:
Hi,
On Wed, Jul 22, 2009 at 10:19:26AM +0200, Remco van Mook wrote:
So here goes. This is what I think that policy should look like. Any comments before I formally submit it?
Do we *really* need this?
The network that started this topic ("we have 10 locations that need a /24 each") is not your typical *LIR* in the first place, and might really be better suited with PI /24s - as that's what they are doing: connecting "independent locations" to the Internet. They are not doing LIR business.
A *LIR* needs a reasonable amount of address space, so I really fail to see why someone would want a /24 PA instead of a /24 PI... (which costs less, and has the same impact on the routing table).
Operationally, the "/24 PA" would come from the same blocks as /24 PI anyway (minimum allocation size, etc.)...
If you're convinced that this really is a good thing, by all means go ahead (and I won't oppose), I'm just afraid that this is a waste of "policy making brain power", solving a not really existing problem...
Gert Doering -- APWG chair
-- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl