[arin-discuss] IPv6 as justification for IPv4?

Thu Apr 18 17:22:04 EDT 2013

Further, if the price isn't reduced for the lower tiers it would raise an additional $1.5mil by one posters model or ARIN to continue to subsidise ipv6 or advocacy of it. That's not a small amount by ARIN budget terms. That's an increase in revenue of 10% for ARIN. Nothing to sneeze at. 

Jesse Geddis
LA Broadband LLC

On Apr 18, 2013, at 2:15 PM, "Jesse D. Geddis" <jesse at la-broadband.com> wrote:

> Owen,
> 
> This has already been discussed and disproven. It does make a dent in
> everyone else's fees. I support the dent as being an appreciable one and
> others have voiced the same.
> 
> Thank you,
> 
> Jesse Geddis
> LA Broadband LLC
> 
> 
> 
> 
> On 4/17/13 7:50 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Apr 17, 2013, at 10:21 AM, "Jesse D. Geddis" <jesse at la-broadband.com>
>> wrote:
>> 
>>> Owen,
>>> 
>>> Whether its framed as 'paying for IP addresses' or 'paying for
>>> registration services' is really irrelevant. The fact is is that it is
>>> tiered up to a certain point until you get different rules from everyone
>>> else at x-large. Further, those tiers are pegged to an
>>> _allocation_size_. So applying a fee scale to IPs is something _ARIN_
>>> did by implementing this tiered structure in the first place. Not us.
>> 
>> So what this really boils down to is that you're upset that ARIN doesn't
>> extend the pricing model beyond XX-L
>> (look at the adopted fee structure, not the current one) because a very
>> small number of organizations at the top
>> don't get charged even more for their relative sizes within that category.
>> 
>> Frankly, the number of organizations at that tier is so small that
>> extending the linear pricing model wouldn't make
>> a significant dent in the pricing at any of the lower tiers, so it's not,
>> IMHO, worth complicating the pricing structure
>> to accommodate that.
>> 
>>> Regarding your mention of ARINs costs associated with different tiers
>>> and the assertion that x-large costs ARIN less money. No one has put
>>> forth any hard data whatsoever to support that argument. Its an
>>> unfounded assertion that's been given mythological status by you and
>>> some other folks. Indeed, even John Curran himself mentioned we can look
>>> at other models including pegging the fees to actual ARIN costs implying
>>> that they aren't right now. Based on these things I don't find this to
>>> be a valid excuse to give x-large much lower costs proportionately and
>>> to allow them to scale exponentially with no concern of fees or having
>>> to proportionately 'support' like everyone else.
>> 
>> They aren't pegged directly to costs because we aren't doing Fee for
>> Service billing. I don't think you want that.
>> 
>> However, ARIN has shown the over all cost to ARIN per organization size
>> based on the current fee categories and
>> has shown that the larger organizations do cost ARIN less per IP address
>> to work with. There is hard data to support
>> that fact. Further, simple logic from what ARIN actually does makes it
>> pretty obvious that the costs to ARIN do not
>> have any relationship to the size of address holdings of the various
>> organizations ARIN deals with. It has more
>> to do with the number of transactions, quality of the information
>> provided by the organization in each transaction,
>> and number of records held in the database. There's a little more staff
>> time to review the greater amount of data associated with an application
>> for a /12 than for a /22, but it certainly isn't 1024 times as much time.
>> 
>> X-Large pays double what Large pays. XXL pays double what XL pays.
>> 
>> This is the same as XS paying double what XXS pays, Small paying double
>> XS, Medium paying double Small,
>> Large paying double Medium, etc. At every tier your fee doubles and your
>> amount of space quadruples.
>> 
>> So by your argument, at every tier you pay proportionately less per IP
>> address. This reflects the fact that ARIN's costs do not scale linearly
>> with address size, but attempts to provide a rough approximation of
>> mapping sizes to actual costs.
>> 
>> Yes, the fee structure tops out at XXL. Once you reach a certain size and
>> are paying $32,000/year, you don't have to pay more even as you get more
>> addresses.
>> 
>> In reality, extending that pricing linearly beyond XXL wouldn't change
>> pricing at the lower tiers by much. Further, it is very unlikely that
>> those organizations are actually creating costs for ARIN that would come
>> even close to doing so.
>> 
>> Let's assume, for a moment, that an ISP existed that held </4, "/6. By
>> your argument, said ISP should, instead of $32,000/year, pay
>> $256,000/year instead of $32,000/year. To the best of my knowledge, there
>> is no such ISP and
>> there are probably fewer than 5 ISPs in the </6, "/8 category at
>> $128,000/year, so your maximum additional yield
>> there is $480,000/year. Of the remaining 48 organizations in the XX-L
>> category, I have no idea where the split would
>> fall between the $64,000 bracket you would establish at </8, "/10  vs.
>> the existing $32,000 bracket. My best guess
>> would be a ~50/50 split, so let's say 24 organizations.
>> 
>> So, you would increase costs for top-end organizations as follows:
>>    5    * 96,000
>>    24    * 32,000
>> ===============
>>        $1,248,000
>> 
>> If we were to spread that evenly across the X-S, S, and M registrants
>> (total 3818->3306 organizations), you would save each of those
>> organizations less than $400 per year.
>> 
>> I simply don't buy that it's somehow more fair to inflict 64k and
>> 128k/year pricing on to a small number of organizations at the top end to
>> subsidize $400 discounts to 3300 other organizations.
>> 
>>> What I'm interested in hearing, Owen, and others. As well as, I'm
>>> guessing the poster you replied to, several other people who have also
>>> publicly questioned the hybrid scale, and the 3 dozen people on this
>>> list who emailed me privately but weren't interested in the public
>>> flogging by some you folks (Matthew, Lee, and a couple others) is a
>>> reasoned answer to the following:
>>> 
>>> Why *should* there be a fee increasing cutoff at /14
>> 
>> Because beyond a certain point, continuing to double people's fees stops
>> making sense. The size model is designed to be a convenient approximation
>> of the cost-model that ARIN has along with some other tradeoffs. It
>> attempts to allocate the burden along similar lines as ARIN's cost burden.
>> 
>> If you extend it beyond the /12 point (which is where the XX-L category
>> actually begins), then it rapidly makes no sense and is overly burdensome
>> as described above.
>> 
>>> Why should x-large (73 orgs out of thousands) get a different set of
>>> rules than everyone else.
>> 
>> They don't. They live by the same rules. There are a number of services
>> with similar cost structures where you pay less for each incremental
>> level of service until you reach a certain tier where you simply get "all
>> you can eat" service for that price.
>> 
>> Some of them are even in this industry. It's not uncommon for mobile
>> providers, for example, to have usage sensitive pricing where you pay
>> less per GB transferred as you move up the usage stack until you finally
>> reach a point where the next increment gets you unlimited consumption.
>> 
>>> 
>>> And please, let's stick to the facts and avoid repeated assertions like
>>> the below that have no basis in actual data. Personally, I think trying
>>> to divine ARINs cost per tier and creating a fee structure based on that
>>> is a very bad idea. Indeed, my proposal is fundamental in getting rid of
>>> the current tier structure altogether.
>> 
>> I wasn't divining ARIN's cost per tierS It was published data from ARIN.
>> 
>> It is documented as one of the inputs to the current fee structure.
>> 
>> Claiming it has no basis in facts when the ARIN CEO has contradicted you
>> on this matter is folly.
>> 
>> Your proposal is fundamental in getting rid of the tier structure. It's
>> also a really bad idea IMHO. Your proposal is grossly unfair at both the
>> top and bottom extremes.
>> 
>> Owen
> 