[ppml] [arin-discuss] Counsel statement on Legacyassignments?(fwd)

Michael Thomas - Mathbox mike at mathbox.com
Fri Oct 5 15:06:26 EDT 2007


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Friday, October 05, 2007 1:01 PM
> To: Michael Thomas - Mathbox
> Subject: Re: [arin-discuss] SPAM-WARN:Re: [ppml] Counsel 
> statement on Legacyassignments?(fwd)
> 
> 
> On Oct 5, 2007, at 9:35 AM, Michael Thomas - Mathbox wrote:
> 
> > Owen,
> >
> > Then ARIN should state the flat fee for processing a block. The  
> > price per IP
> > should be the same. ARIN _does not manufacture_ IP 
> addresses. There  
> > is no
> > cost savings in _not manufacturing_ a smaller block versus a large  
> > block. In
> > fact it costs ARIN _MORE_ to support the large block, because the  
> > large
> > block requires more RDNS entries.
> >
> That's simply not true.  A /16 requires 1 RDNS entry.  A /20 
> requires  
> 16.
> A /24 requires 1.
> 
> However, the cost of generating the RDNS entries is not 
> linear, either.
> 
> The increased costs in a block come more from things like the 
> churn rate
> of SWIPs, the number of SWIPs the block is subdivided into, 
> and a number
> of other ancillary functions which cannot be accurately 
> measured at the
> time of issuance.  To ARIN, a /24 to a customer of an ISP is virtually
> identical in incremental costs to a /29 to a customer of an ISP.
> 
> You are right that ARIN does not manufacture IPs.  However, it does  
> often
> cost ARIN more to process an application for a smaller block than a  
> larger
> one because the smaller applications often come from ISPs whose  
> personnel
> are less familiar with the process and policies and thus 
> require more  
> hand-holding
> and staff time.  Staff time is probably the biggest cost factor in  
> ARIN IP
> allocations.
> 
> I know that for the assignments and allocations I have 
> requested over  
> the
> last 3 years, I simply cannot compare the process to pulling teeth.   
> It has
> been relatively quick, simple, and painless to me.  In fact, my last  
> assignment
> was processed in less than 24 hours from initial paperwork through  
> billing
> and RSA all the way to addresses.
> 
> An ISP who has a total of fewer than 4096 IP addresses pays 
> $1,250/year.
> That works out to approximately $0.31/IP address.
> 
> An ISP who has between 4097 and 8192 IP addresses pays $2,250/year.
> That works out to approximately $0.27/IP address.
> 
>  From 8193 to 65536 total IP addresses, the cost is $4,500/year.
> This is approximately $0.07/IP address.
> 
> However, if we consider it along these lines... Let's assume 
> that the  
> fixed costs
> for preserving an allocation in the system are on the order of $750/ 
> year, then,
> we see something that looks like this:
> 
> x-Small (<=4096 IPs) = $750 + $500 = $0.12/IP
> Small (4097-8192 IPs) = $750 + $1500 = $0.18/IP
> Medium (8193-65536 IPs) = $750 + $3750 = $0.05/IP
> Large (65537-262144 IPs) = $750 + $8250 = $0.03/IP
> 
> As you can see, $750 is probably the wrong fixed cost number, but,  
> probably not
> too far off.  The cost per IP at the low end remains slightly high,  
> but, the taper at
> the higher end is relatively linear.  I believe this accurately  
> reflects the fact that
> on x-Small and Small allocations, staff tends to have to spend more  
> time working
> with the ISP on their requests.  Medium and bigger 
> organizations tend  
> to have
> people who manage the IP records as their full-time job and the  
> become quite
> skilled with the ARIN process and the record keeping necessary to  
> make that
> happen smoothly.  As such, it costs less for ARIN to deal with them,  
> and, these
> cost savings are reflected in the pricing.
> 
> BTW, before you think I represent some large ISP and have 
> some gain from
> the status quo of pricing, in actual fact, most of my ARIN  
> transactions are
> end-user direct assignments.  The majority of them do not 
> exceed a /20.
> 
> Owen
> 
> > Michael Thomas
> > Mathbox
> > 978-683-6718
> > 1-877-MATHBOX (Toll Free)
> >
> >> -----Original Message-----
> >> From: Owen DeLong [mailto:owen at delong.com]
> >> Sent: Friday, October 05, 2007 11:49 AM
> >> To: Michael Thomas - Mathbox
> >> Cc: 'Michael Lambert'; arin-discuss at arin.net
> >> Subject: Re: [arin-discuss] SPAM-WARN:Re: [ppml] Counsel
> >> statement on Legacyassignments?(fwd)
> >>
> >>
> >> On Oct 5, 2007, at 8:35 AM, Michael Thomas - Mathbox wrote:
> >>
> >>>> We are, with respect to IPv6.  So let's not put too much
> >> effort into
> >>>> solving the pricing problem of legacy assignments in 
> legacy address
> >>>> space.
> >>>
> >>> Actually everyone _is not_ treated the same for either. 
> The pricing
> >>> structure for both IPV4 and IPV6 indicates that there are
> >> first class
> >>> citizens, second class citizens, third class, etc. Otherwise,
> >>> everone would
> >>> pay exactly the same price per IP address.
> >>
> >> Not true.  The pricing structure indicates that IP addresses are a
> >> mixture
> >> of fixed and incremental costs.  This is also common in
> >> transactions of
> >> wholesale goods.  Companies that buy a container of a product get a
> >> much better price than companies that purchase a pallet of the  
> >> product
> >> at a time.  Companies that buy a pallet receive a better price than
> >> companies that buy a case at a time.
> >>
> >> While ARIN is not selling IP addresses, the reality is that
> >> to evaluate
> >> an allocation request requires a certain amount of effort  
> regardless
> >> of the size of the request.  Beyond that, a certain amount 
> of effort
> >> tends to be roughly proportionate to the size of the 
> request.  Thus,
> >> as the size of the address space allocated to a given organization
> >> increases, the price per IP appears to decrease, but, that 
> is because
> >> the fixed cost portion of the price is not growing as the 
> size of the
> >> allocations grows.
> >>
> >> Example (absurd numbers used to keep math easy):
> >>
> >> Fixed costs to maintain an organization in the system: $1000
> >>
> >> Per IP cost to maintain customers allocation records: $1
> >>
> >> Customer with a /22:	$1000 + $1024 = $2024	
> $2024/1024 = 1.9765625
> >>
> >> Customer with a /19:	$1000 + $8192 = $9192	
> $9192/8192 = 1.1220703
> >>
> >> Customer with a /16:	$1000 + $65536 = $66536	
> $66536/65536 = 1.0152588
> >>
> >> As you can see, the "apparent price" per IP drops somewhat
> >> substantially,
> >> but, the reality is that the pricing is quite linear.
> >>
> >> I have not evaluated the ARIN fee structure to see what 
> this constant
> >> is, and, there are some rounding and smoothing errors introduced
> >> into ARIN pricing to simplify the fee structure vs. a 
> unique price  
> >> for
> >> every customer.  However, it does roughly approximate such a
> >> pricing structure, and, this is a very common practice for 
> both sales
> >> and service pricing.
> >>
> >> Owen

Owen,

For several reasons, I honestly do not believe that your cost allocation is
accurate.

1. In another message unrelated to this one, you point out to Jeremy that
someone returning for another allocation does not pay separately for each
allocation.

2. In the second and subsequent years of an allocation, one still pays the
entire fee. If your argument held water, the second and subsequent year fees
would be reduced by the application processing cost and would reflect only
the maintenance cost.

3. Comparing the time to review an intial /24, /23, /22, /21 allocation to a
/14 or larger allocation as taking longer due to the applicant being
unfamiliar with the process is questionable. The allocation of a larger
block should actually be scrutinized more heavily, because it removes more
resources from the available pool.

4. If in fact the total cost is based on application costs and maintenance
costs, the fees would reflect that.

5. I just paid my second annual fee. The cost was the same as last year. I
did not make any applications this year.

6. The fees are based on the total size of all allocations. You have said
so.

Michael Thomas
Mathbox
978-683-6718
1-877-MATHBOX (Toll Free)  





More information about the ARIN-PPML mailing list