[arin-ppml] maintenance fees for legacy space holders

[Stephen Sprunk]

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 
fee model...

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 
first place.

> 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 
amount...

S