[address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses

Dear Tore,

> The way I see it, this argument applies equally well to LIR->EU
> assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand
> what makes sub-allocations special here.

 Transfers are very useful for permanent transfer.
   
  Sub-allocations - for temporary use. This allows to control what happend's
with IP-addresses while if they will be in black list (SpamHouse, etc..) -
then impossible to use them in future.
 
--
Kind regards,
Alexey Ivanov

09.10.2012 14:16 - Tore Anderson написал(а):
 * Gert Doering

> James' proposal has its merits, but OTOH, just loosening up sub-allocations
> might be the approach more appropriate for "the time we're living through".
>
> [...]
>
> While we still do not have much experience with sub-allocations, the
> warning "if you hand it all out, you might not get new space easily,
> so be wary" is moot - it's now "if you hand it out, there will not be
> any more space, period!", and LIRs should have noticed *that* by now...

The way I see it, this argument applies equally well to LIR->EU
assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand
what makes sub-allocations special here.

It would IMHO be much more interesting to see a proposal that would
retire the needs-based principle completely for all forms of IPv4
delegations (that aren't taken from the NCC pool). Does it really serve
any useful purpose nowadays?

If some LIR wants to give away (assign, transfer, sub-allocate -
whatever) all their remaining free space to someone who doesn't really
need it - why not let them? It won't impact me or anyone else since
their wasteful spending can no longer translate into an increased draw
from the shared pool. I, on the other hand, would certainly not miss the
assignment request documentation bureaucracy.

--
Tore Anderson
Redpill Linpro AS - [1]http://www.redpill-linpro.com/
 

[1] http://www.redpill-linpro.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20121011/fd8b982f/attachment.html>