[arin-discuss] tweak to proposed fee schedule

[Brent Sweeny]

I agree that it makes a lot of sense and seems to incorporate the right
kind of incentives (for adoption of v6) without too much 'cost'. I'd
also like to hear, as Michael solicited, if there are good reasons not
to do this; absent them, this sounds like a good way to go.
	Brent Sweeny, Indiana University

On 4/8/2013 12:18 AM, Michael Sinatra wrote:
> Hi,
> 
> Currently there is a discussion going on over on ppml@ regarding policy
> 2013-3, which is largely being driven by an incentive issue with ARIN's
> proposed fee schedule.  Specifically, the proposed fee schedule allows
> for very small ISPs to fit in the "XX-small" category.  However, the
> current minimum allocation for an ISP is a /36 (with a /32 being the
> "standard" allocation), which does not allow a very small ISP to fit in
> the XX-small category.
> 
> See the tables here for more info:
> 
> https://www.arin.net/fees/pending_fee_schedule.html
> 
> Because of this, concern has been expressed that this creates a
> disincentive for small ISPs to adopt IPv6.  A policy proposal (2013-3)
> has been developed that allows small ISPs to receive allocations as
> small as /40s, while still reserving indefinitely a /32 for the ISP,
> some or all of which the ISP can request at any time and without
> justification.
> 
> However, there are some operational issues that arise from this use of
> number policy to patch an issue with the fee schedule; these issues have
> been discussed at length on PPML, and I refer the reader to the archive
> of that discussion.  Briefly summarized:
> 
> o It results in a messy addressing plan, where the ISP is forced to fit
> into a small corner of the potential space it has available to it.
> This, in turn leads to two consequences:
> 
> o Customers will receive sub-standard reassignments as the ISP becomes
> increasingly parsimonious with address space.
> o As the allocation grows toward the /32 boundary, it becomes less
> likely that the ISP will be able to have internally aggregable routing,
> and this may make it more likely that the ISP won't re-aggregate its
> space as it increases the size of its allocation over time, *even* if
> that space is from a single aggregable /32.
> 
> I'd like to propose a tweak to the proposed fee schedule as follows:
> 
> "ISPs which have IPv4 resources and an IPv6 allocation of exactly /32
> will have their fees calculated from the fee schedule based only on
> their IPv4 allocation.  All allocation sizes other than IPv6 /32 will be
> calculated from the fee schedule based on the greater of their IPv4 or
> IPv6 allocation."
> 
> This only affects ISPs whose IPv4 allocations are in the X-small or
> XX-small range *and* who have a /32 allocation.  ISPs and end sites with
> allocations/assignments in the small or greater category will still pay
> the greater of their IPv4/IPv6 allocation-category fee.
> 
> It's revenue-neutral with respect to the pending fee schedule, combined
> with proposal 2013-3 because that proposal calls for the reservation of
> the /32 for that ISP anyway.  I believe this tweak still allows for a
> sustainable revenue model for ARIN until such a time as ARIN ceases to
> provide IPv4 services, at which point the fee schedule will likely need
> to be revisited anyway.
> 
> I am interested in this community's thought on this tweak.  I realize
> the fee schedule is always a contentious issue, and I am reluctant to
> get into a general discussion of fees (for more general discussions,
> please create a separate thread).  However, I would like to know if
> there are specific issues or incentive problems with what I am proposing.
> 
> Note also that I have no stake in this issue; this fee tweak would not
> impact myself nor my current or previous employers.
> 
> Michael Sinatra
> Energy Sciences Network
> LBNL/DOE Office of Science
> _______________________________________________
> 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.
>