[ARIN-consult] Community Consultation: Future Direction for the ARIN Fee Schedule

[John Curran]

On Oct 12, 2014, at 9:47 PM, William Herrin <bill at herrin.us> wrote:
> 
> John, I did not make an specific proposal. I expressed three
> constraints that I believe any specific proposal must meet in order to
> be reasonable both now and in the near future:
> 
> Constraint #1: That the fees be strongly tied to the registrant's
> consumption of IPv4 addresses
> 
> Constraint #2: That the annual fee divided by held IPv4 addresses for
> each registrant vary by no more than one order of magnitude (10x)
> compared to any other registrant.
> 
> Constraint #3: That no fee be based on the assignment of IPv6
> addresses until such a time as IPv6 becomes the dominant protocol on
> the Internet.
> 
> I won't be making a specific proposal or suggesting a particular
> algorithm because the thing of importance I have to say is not found
> down in the weeds, it's found in these three high-level constraints.
> 
> 
> For the sake of further clarity, I will evaluate the proposals in the
> fee structure report in the context of these three constraints:
> 
> Proposal 1: stay the course.  Proposal 1 arguably meets constraint 1
> but fails abysmally at constraints 2 and 3
> 
> Proposal 2: add $64k and $128k IPv4 fee categories. Continues to fail
> constraint #2 as the disparity narrows from 3 orders of magnitude to
> "merely" 2. However, a proposal of this character with more boxes and
> different numbers could meet constraint #2. Does not speak to or meet
> constraint #3.
> 
> Proposal 3: Realign IPv6 fee categories. Fails constraint #3. Does not
> speak to or meet constraints 1 and 2.
> 
> Proposal 4: Linear IPv4 fee categories. Except it isn't because
> holdings start at /24 not /20. As specified in appendix A2, proposal 4
> meets constraint #1 but continues to fail constraint 2. Were the
> "doubling" changed to continue down to /24 and up to /6, it would
> probably meet constraint #2. Proposal 4 does not speak to or meet
> constraint #3.
> 
> Proposal 5: algorithmic IPv4 fees. Meets constraint #1. The proposed
> algorithm very clearly fails to meet constraints 2 and 3. A different
> algorithm could be selected to meet those constraints.
> 
> Proposal 6: Flat rate per organization served. Fails to meet
> constraints 1 and 2. Arguably meets constraint 3 though it does not do
> so in the scenario where an organization's sole holdings are IPv6
> addresses.
> 
> Proposal 7: transaction-based fees. Not only does this fail to meet
> the three constraints, it's positively corrupt: an organization is
> compelled to pay extra for the iterative transactions that it doesn't
> want in the first place, transactions it engages primarily because
> ARIN policy requires it.
> 
> In conclusion: all seven proposals in the report fail to meet at least
> one of the constraints I propose. Details in several of them could be
> changed to meet the constraints.
> 
> Is there further clarity to these proposed -constraints- on a fee
> structure which you would find helpful?

Bill -

It would be best for those in the community to discuss the 
constraints that you have for deeming something a successful 
proposal, in comparison to their own particular expectations.

Thank you for the clear enumeration of your requirements!
/John

John Curran
President and CEO
ARIN