[arin-ppml] Draft Policy ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool

[Owen DeLong]

> On Aug 26, 2019, at 18:09 , Martin Hannigan <hannigan at gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> Really, it seems to me that this proposal is another attempt at eliminating the waiting list for unmet requests.
> 
> The first attempt (ARIN auctions the space) met with resistance from ARIN’s legal team (for good reason), so now this attempts to sequester the space where it will be hard to distribute rather than allowing the waiting list to have any potential to compete with the transfer market.
> 
> The proposed targets (4.4 and 4.10 pools) are well stocked and unlikely to run out in any useful IPv4 lifetime.
> 
> Data: see "reserved"
> 
> https://www.arin.net/vault/knowledge/statistics/2018.html <https://www.arin.net/vault/knowledge/statistics/2018.html>
> 
> If you look at the numbers you can see a mild acceleration and then what looks like it could be a deceleration of assignments from this pool (and many others ironically). Note, the time period is only a year. My conclusions aren't rock solid as a result. I'm really just eyeballing.
>  
> 
> As such, restocking them from returned space strikes me as just a way to sequester this space where it cannot be used.
> 
> IMHO, this is counter to ARIN’s mission and should not be allowed.
> 
> Do you think having pools of the magnitude and current use profile of 4.10 and perhaps even 4.10 are in need of being re-evaluated?  
> 
> Admittedly, its a little re-arranging of the deck chairs. However, if the waiting list is truly stocked with people who have a need and aren't just using it to hedge against a transfer they already completed it may make sense to make adjustments. And to potentially apply it there. I won't speak to the authors intention on 4.10, but I had a hand in 4.4. I determined and argued for the pool size based on conditions on the ground at the time. Today I would argue IXP growth in NA is somewhat flat, that most are commercial in nature and won't have trouble using the transfer market. Yes, there are some that aren't for profit, but even those usually have an easy time fundraising. 

I think that IXPs are a sufficiently important benefit to peering density and interconnection that even if they are commercial, I don’t mind holding a carve-out for them. Note also that 4.4. covers some TLD and Root server addressing needs as well.

I think that the current sizes are working well for not. If we get a couple of years down the road and see that they really aren’t being used (and IPv4 is still perceived as a vital growth commodity), I’d be potentially willing to re-evaluate at that time, but in that case, if we shrank the pools, I’d probably want to use whatever we released to drain the waiting list queue (which I know will make the author’s skin crawl).

> If anything should have a pool, a small pool for the Caribbean makes sense. The contrast in economic conditions and market norms justify it easily in my opinion. Such as the US large volume transit price per mb/s between $0.05 and $0.15 nd for most there we're substantially north of a $1.00. 

I’m not sure what the relationship is between transit pricing and the need for IPv4 addresses. If anything, most of the Caribbean economies have a slight advantage in the IPv4 market place as few of them need short prefixes.

I also think that Caribbean transit prices will continue to fall and while they might not reach parity with the US in the next few years, the gap will close.

YMMV.

However, if you do feel that such a carveout would be desirable, please submit  a policy proposal. Make sure to cover where the addresses to stock the pool are supposed to come from and what, exactly, are the criteria for consuming from the pool. Lots of details to mask many devils in there, IMHO.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190827/f42c2eb5/attachment.htm>