[address-policy-wg] Hoarding /22 out of 185/8
- Previous message (by thread): [address-policy-wg] Hoarding /22 out of 185/8
- Next message (by thread): [address-policy-wg] Hoarding /22 out of 185/8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friacas
cfriacas at fccn.pt
Tue Apr 28 11:25:23 CEST 2015
On Tue, 28 Apr 2015, Radu-Adrian FEURDEAN wrote: > On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote: >> * -TOM- <tom at kebab.org.pl> >> >>> This means, thatdealings with opening multiple LIR's, get their /22 >>> allocation and merge this 'new lir's' with other 'host lir' is now in >>> progress at full throttle :( >> >> Indeed, this person appears to be using the LIR merger procedure, *not* >> the transfer procedure, to gather the /22s in his main LIR. At least I >> could not find any of the blocks in question mentioned on >> <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>. > > Which probbaly means revising the text of 2015-01, and/or adding > something similar to the merger procedure. > Then again, some basic "needs checking" (checking that the requestor > DOES NEED an allocation) would probably help too. "Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode... One idea could be: «If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool». Cheers, Carlos
- Previous message (by thread): [address-policy-wg] Hoarding /22 out of 185/8
- Next message (by thread): [address-policy-wg] Hoarding /22 out of 185/8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]