[arin-ppml] maintenance fees for legacy space holders
stephen at sprunk.org
Thu Sep 4 14:01:43 EDT 2008
Howard, W. Lee wrote:
>> 1. Is there any way to break out new allocation/assignment/transfer expenses vs. general maintenance, so that we can determine the share of expenses attributable to folks who are doing nothing other than holding on to legacy resources, not getting anything new, as well as making sure that the fees for new resources adequately cover the costs of evaluating justification that policy requires?
> I don't think it's possible. I'm not sure how we would measure the number of IN-ADDR lookups on legacy records only, or how many participants on the mailing list only hold legacy resources, or how much outreach benefits that segment of the community alone. I don't mean to be intractable, but I can't figure out how to frame the question in a specific enough way to get a meaningful answer.
I see how that is a difficult question to answer. What about limiting
it to this:
"What portion of ARIN's expenses are for (a) processing new
applications, (b) maintaining existing registrations, and (c) providing
other 'free' services to the community."
I expect (b) would include DNS and WHOIS expenses, while (c) would
include meetings, mailing lists, outreach, etc. I understand ARIN
doesn't track things this way so you won't have the exact numbers, but
your rough estimates would be more useful than my uninformed guesses :)
>> 2. What would the fees need to be if they were per-object instead of per-org? IMHO, this is the key to the whole "a domain only costs $10/yr" argument.
> Also a little tough to figure out. Currently, we allow all objects to be rolled up into a single maintenance fee. I haven't examined the records closely, but let's assume that all Class A and B assignments are classful, and that the average assignment size in Class C space is a /21 (there are many Class Cs, but also a good number of CIDR /18 - /20). let's say there are 90 Class A holders, 36*255=9000 Class B holders, and 7*255*32=57,000 legacy objects in Class C space.
> Approaching 67000 discrete legacy objects, so that's your denominator. You can do the math: 67k * $10 is $670,000. That's 5% of ARIN's 2008 budget.
Okay, so assuming 100% of legacy holders signed the LRSA, to get the
same revenue as $100/org we'd need to set the fee at $13.21/object. Or,
to put it another way, $100/org assumes an average of 7.5 objects/org.
Obviously, orgs with fewer than 7.5 objects would prefer the per-object
Of course, one side effect of setting the fee structure that way is that
some orgs would attempt to reduce the number of objects they held in
order to reduce their fees. These might be outright returns, which
would push out exhaustion slightly, or they might be aggregation
requests, which would pull it in. I have no clue which effect would be
stronger, but I'm guessing it'd be minimal either way since the cost of
renumbering will far outweigh the savings in fees for most orgs.
Also, that ignores the effect that a per-object fee structure would have
on the willingness of orgs with many objects to sign an LRSA in the
> Would this be fairer?
> We could debate whether that's a fair share, but it would be a matter of opinion of "fair."
> It would mean that those with a single allocation (say, a Class A) pay a single low fee, while those with multiple CIDR allocations pay several times as much.
It's definitely an interesting definition of "fair" where one registrant
holding a single /8 would pay less than another holding two /24s, but
we're already partway down that path today by charging them the same
More information about the ARIN-PPML