[arin-discuss] IPv6 as justification for IPv4?

[Jim Connolly]

Can you please stop with all the emails? 3 days of you going on and on.

________________________________

From: arin-discuss-bounces at arin.net on behalf of Jesse D. Geddis
Sent: Thu 4/18/2013 4:16 PM
To: Owen DeLong
Cc: arin-discuss at arin.net List; John Curran
Subject: Re: [arin-discuss] IPv6 as justification for IPv4?



Owen,

        Honestly, I don't know why this is even a topic of conversation still.
The fact is the fees are based on allocation size today and to my
knowledge they have ALWAYS been based on allocation size. It's in black
and white here:

https://www.arin.net/fees/fee_schedule.html

What I read in this fee schedule is "Size Category" with an associated
"Fee (US Dollars)" followed by a "Block Size"

        Nowhere on this current fee schedule do I see anything (not even a hint)
about it being linked to how many tickets ARIN thinks a specific size
category takes. Nothing about them being based on who ARIN thinks
generates better requests. Nothing. So can we please be done with that as
an excuse for the current fee structure?

Jesse Geddis
LA Broadband LLC




On 4/17/13 8:03 PM, "Owen DeLong" <owen at delong.com> wrote:

>>> Recognize that there is a transaction cost involved in issuing (or
>>> transfering) an address block to a party, but beyond that point,
>>> ARIN's actual costs are not significantly different for a large IP
>>> address block versus a small IP address block.  We should all be
>>> very thankful for this, as ARIN's costs would have become enormous
>>> upon the assignment of the first IPv4 block...  (which has so many
>>> individual IP addresses that any cost per IP would still be too much.)
>>
>> Well I think that depends and is highly subjective. In my experience
>>the time ARIN spends on a ticket directly correlates to the size of the
>>requested block. With the larger block I have found ARIN spends
>>exponentially more time vetting the documentation, diagrams,
>>spreadsheets, projections, and contracts than it does with say a /22.
>>From what I'm hearing you say you believe ARIN spends an equal amount of
>>time vetting a /22 as it does a /14. I can't fathom how this could be
>>possible. If I'm requesting a /14 ARIN would presumably be reviewing
>>documentation for hundreds of thousands of IPs and huge diagrams and
>>projections vs reviewing documentation for 500 IPs associated with a /22
>>request.
>>
>
>Nope.
>
>ARIN spends a lot more time on a poorly considered, poorly documented
>repeated rounds of asking for additional documentation request for a /22
>than they do on a well considered, well documented request for a /14.
>This has been
>stated in various forms multiple times, so it does not "lack foundation"
>as you are so fond of saying.
>
>Further, even in the case of a well formed request for a /22 and a well
>formed request for a /14, ARIN does not spend anywhere near 256 times as
>long on the /14 as the /22, yet you want to jack the price up *256 for
>that spread. In my
>experience, it's more like 1.5-2 times as long. Admittedly, my knowledge
>is limited to IPv4 from /24 to /12 and IPv6 from /48 to /24. I don't have
>experience applying for anything larger than /12 (IPv4) or /24 (IPv6). My
>experience does include multiple successful applications at each of those
>top sizes.
>
>ARIN should be spending considerably less time deliberating most IPv6
>requests than they do most IPv4 requests, since the policy is quite a bit
>simpler and allows for significantly more liberal allocations. Also a
>larger fraction of these are likely initial allocations with near
>automatic qualification.
>
>Owen
>

_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info at arin.net if you experience any issues.

--
This message has been scanned for viruses and
dangerous content by an automated system, and is
believed to be clean.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20130418/0b4ebf3f/attachment.html>