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

[William Herrin]

On Sun, Oct 12, 2014 at 10:03 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 12, 2014, at 1:53 PM, William Herrin <bill at herrin.us> wrote:
>
> It is specifically my role to facilitate the discussion of any
> proposals brought forth; this includes yours, those in the Fee Structure
> report, and any others that may appear. For example, it would be helpful to
> get more insight into what exactly you are suggesting, as your statement that
>
>> "I honestly don't care about the exact formula. Pick one that's convenient."
>
> doesn't really allow the community to understand what you are proposing (i.e.
> it could be linear or algorithmic/logarithmic, with narrow range or wide...)

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?

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?