[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
owen at delong.com
Sun Apr 7 17:14:47 EDT 2013
>> One possible way to distinguish ISP size for IPv6 would be to use
>> annual gross revenue instead of total address holdings. I don't know
>> if that would be an improvement or not. I realize it would be more
>> complex to calculate and enforce. I think it would likely be more fair.
> More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN.
I disagree completely here. An end-user with a single /48 is not in any way reasonably expected to pay the same as an ISP with multiple ASNs, a /20 of IPv6 and an aggregate /6 of IPv4 space.
I can't imagine in what possible universe anyone could imagine that to be fair.
> Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent.
We can agree to disagree on what constitutes "fair" here. I believe it is "fair" for those that are extracting a greater amount of revenue from the community resources they hold to contribute a greater share to the costs of maintaining said community resources.
I don't see it so much as extracting extra revenue so much as differentiating the allocation of the total costs. I don't believe for a second that ARIN is increasing its overhead just to ensure the money gets spent. I have reviewed the ARIN public financials several years in a row and I believe that ARIN does a great deal for the community at a very reasonable cost to said community.
> But we see this all over the world these days, so it isn't like I'm surprised that they would behave this way. At least they're not creating additional address registries and then telling people they need to register their addresses there too in order to protect their trademarks, like some other winners of the how-can-we-charge-for-things-that-were-free game that the Internet played some years ago.
This really isn't a fair characterization of either structure. First, I agree that what has happened in the DNS realm has been badly mismanaged and that most of the mismanagement has come about as a result of various profit motives. However, to claim this was strictly a matter of "how can we charge for what was free?" is not at all accurate. The original switch to "charging for what was free" was an effort to sustain the existing infrastructure from a new funding source since the previous government contracts were about to become unfunded.
I think that the number registries have done a vastly better job of the transition and keeping things cost-recovery based while providing the services the community has said it is valuable for them to provide at a very reasonable cost to the community.
As much as I think that the new fee structure contains some really poor decisions that will drive poor number resource policy as a consequence, I do think that the board is trying to balance a number of tradeoffs and has made a reasonable attempt at doing so in a fair and consistent manner.
>> I would like to hear about other creative ideas on ways to measure
>> size and/or appropriate metrics to be used for fee determination.
> Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row.
The problem with this is that it would again create negative incentives. It will financially incentivize the following negative behaviors:
1. Avoid updating records to reflect changes.
2. Downsize customer assignments to avoid having to request additional space.
3. Avoid interacting with ARIN until it's absolutely necessary and cannot be avoided
through other contortions of ones own address space.
I don't thin that's a desirable outcome any more than what is proposed in the adopted fee structure combined with what is proposed in 2013-3.
More information about the ARIN-PPML