[arin-ppml] 2014-14, was Internet Fairness

Matthew Petach mpetach at netflight.com
Fri Dec 26 19:33:39 EST 2014


On Fri, Dec 26, 2014 at 3:01 PM, John Springer <springer at inlandnet.com>
wrote:

> Hi John,
>
> Thank you for the clear statement of opposition. Please allow me to
> address the points you offer inline.
>
> On Wed, 24 Dec 2014, John Santos wrote:
>
>
>> Oppose 2014-14
>>
>> 1) /16 is not "small"
>>
>
> This has actually been mentioned before, by several commentators. The
> problem with "big" and "not "small"" is that they require reference to a
> datum, which WRT to 2014-14 has not been provided. Owen Delong provided a
> fair attempt to come to grips with what big or small actually mean as
> percentages of the number and size of transfers that have occured since the
> STLS policy was adopted in 2009, here:
>



Hi John,

I think it might help if we use the terms
XX-Small, X-Small, Small, etc. as defined
by ARIN themselves at
 https://www.arin.net/fees/fee_schedule.html

This might help eliminate confusion, and allow
for some flexibility going forward; if we instead
of hard-coding a specific size, instead tie it to
the fee schedule, and say "only entities that
currently fall into the "Small" and below category
of the ARIN fee schedule (ie cumulative /18 or
less of total IPv4 holdings as of the 2013 fee
schedule) may obtain a single transfer allocation
of size not to exceed the largest allowed for an
XX-Small organization (which, as of the 2013
fee schedule would mean a /22 or smaller)."

Or perhaps keep it supremely simple:
"Any org-ID may obtain one transfer allocation
of size not to exceed the largest allocation
within the XX-Small category (currently a /22,
as of the 2013 fee schedule) per year without
requiring needs justification."

That way, as our concept of ISP size shifts
and changes over time, so too does the
maximum needs-free allocation size.

[after writing the first paragraph, I realized
we probably don't need to limit who can
make use of this; the larger org-IDs aren't
going to bother messing around with xx-small
sized allocations, so it should be self-limiting.]

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20141226/2308908b/attachment-0001.html>


More information about the ARIN-PPML mailing list