[arin-discuss] tweak to proposed fee schedule

[Brian Jones]

Here here! This is the most reasonable suggestion I have heard as well.


"
This is the first suggestion that makes sense to me. I think it is a great
detriment to the deployment of IPv6 to hand out anything smaller than /32
to ISPs. I also think that the proposed fee schedule does potentially have
an unintended side-effect of encouraging bad behavior.
"

--
Brian


On Mon, Apr 8, 2013 at 12:44 AM, Randy Carpenter <rcarpen at network1.net>wrote:

>
> I've been reading all of the discussion about the fee schedule and
> proposal 2013-3.
>
> This is the first suggestion that makes sense to me. I think it is a great
> detriment to the deployment of IPv6 to hand out anything smaller than /32
> to ISPs. I also think that the proposed fee schedule does potentially have
> an unintended side-effect of encouraging bad behavior.
>
> Disclaimer: This potentially would affect my company and my customers.
> Although, I do not have any problem at all paying (or suggesting to my ISP
> customers that they should be paying) the rates set forth by the pending
> fee schedule. I would always choose a /32 for an ISP, as that is the proper
> thing to do.
>
> thanks,
> -Randy
>
>
> ----- Original Message -----
> > 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.
> >
> >
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20130409/5ef44d92/attachment.html>