Hi, I'm looking at https://www.ripe.net/lir-services/resource-management/tools-for-lirs/reponse... and jump to the conclusion that we're now in final /8 policy land, and IPRAs are out drinking. Whether this conclusion is indeed correct is irrelevant, we at close of business yesterday had 830k remaining addresses above final /8,/13. For those that are not clear on the policy on when final /8 will get enacted, the answer is: as soon as a request is approved that will run into final /8 space to fulfill (ie. minimum a /12, today), final /8 policy will get triggered *before* this allocation is made, and the requestor in question gets the first /22 from the final /8 (if PA request) otherwise nothing (if PI). (consensus from an IRC channel) With that out of the way, there are then no more PI allocations. Ever. (Well, until policy changes.) The result is now that the established market price for an IP address in the RIPE service region is $signup_fee + $first_period / /22, or 1024 addresses. That's roughly ~2.3 EUR / IPv4 address now in Q3, soon Q4. Will go up Q1 next year. (Adjust for my misunderstanding on what the minimum cost is here) This equates to roughly 35M EUR now heading RIPE's way. The question is: Is this a good thing? This will go faster than many anticipated with the current policy. The reason it will go fast is simply along the lines of the following example: Company X wants IPv4; their ordinary LIR (mothership) now simply applies for new-LIR in Company X name, gets a valid minimum alloc, and then just transfers this back to the mothership and new-LIR is retired ASAP. Adjust for shell-companies, etc, and the direct exchange of Money vs IPv4 addresses between RIPE NCC and the "market" has been fast. The only thing I'm not sure on here, which basically only affects the per-IPv4 price, is what the minimum cost of signing-up and then retiring a new LIR is. Should it *not* be a good thing to transfer 35M EUR to the RIPE NCC in max ~1 year time, we could just allow PI again and just be done with this whole thing. Best, Martin