[arin-ppml] Fee Philosophy (was: Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs)

cb.list6 cb.list6 at gmail.com
Sun Apr 7 15:53:49 EDT 2013


On Apr 7, 2013 12:47 PM, "Owen DeLong" <owen at delong.com> wrote:
>
> >> I am not saying it needs
> >> to be right now, but I have a hard time understanding why we need to
> >> contort the NRPM to patch over bad incentives in the fee schedule.
> >
> > No NRPM change is needed because of the Revised Fee schedule; fees under
> > the new schedule will be lower for smallest ISPs in any case.
> >
> > The question is whether the community also provide support for a
xx-small
> > category which is even lower ($500/year) but distinguished by only a /40
> > IPv6 allocation.  This is being discussed in Draft Policy ARIN-2013-3,
and
> > while it is enabled by the Revised Fee schedule, it is an independent
item
> > for the community to consider and can be adopted or not based on its
merits.
> >
>
> No, that is not the only question. Because of the situation created by the
> restructuring of the fee schedule, we have several negative incentives
> newly created. It is true that we can choose one negative incentive[1]  by
> not modifying the NRPM. Policy 2013-3 attempts to replace that negative
> incentive with a different negative incentive[2].
>
> No matter what, the fee schedule as it currently stands creates negative
> incentives and I believe that is what Michael is calling into question
here.
>
> [1] The fee structure and policy as currently adopted will create the
> negative incentive for organizations in the xx-small IPv4 category to
> not deploy IPv6 in order to save $500/year.
>
> [2] The combination of the adopted fee structure (assuming it is modified
> to /40 instead of /48) and proposal 2013-3, if adopted would replace [1]
> with the negative incentive for those providers in the XX-Small category
> to obtain massively undersized allocations in order to save the same
> amount of money, allowing them to deploy IPv6 without additional
> address space cost, but very likely inflicting undue limitations on the
> space issued to their customers. This negative incentive already
> exists in both policy and the fee schedule for the X-Small category
> in the form of support for /36s.
>
> >> Moreover, that standard is called into question by the fact that ARIN
> >> charges based on the larger of the two address family allocations, with
> >> no regard to the situation where there are radical differences between
> >> IPv4 size and IPv6 size.
> >
> > Correct, and this has been covered on this mailing list before
> > <http://lists.arin.net/pipermail/arin-ppml/2013-March/026396.html> -
> >
> >  "that is precisely the benefit of the revised fee schedule;
> >   every size ISP category now includes both IPv4 and IPv6, so every
> >   ISP can add an IPv6 allocation and see _no_ change in fees at all.
> >   (This does mean that we can get ISPs for whom there is a "mismatch"
> >   between their IPv4 and IPv6 allocations, and they end up in a higher
> >   category, but to be truly fair we'd need to have distinct proportional
> >   fee for each of IPv4 and IPv6, and that's exactly what you don't want:
> >   any addition of IPv6 means an additional fee.)"
>
> Another alternative would be to base all revenues on IPv4 until a flag
> day to be determined by the board at a later date with at least 12 months
> notice to the community after which flag day, all revenue calculations
> would shift to IPv6. Organizations which did not hold IPv6 after the flag
> day would have the option of maintaining their IPv4 records either by
> obtaining an IPv6 allocation or by continuing based on their IPv4 fee
> category.
>

I support the idea of an Ipv4 only fee structure.

I support more the idea of an asn based fee structure.

CB

> I'm sure there are also other possible ways to avoid some or all of the
> issues of mismatch. In fact, have we considered the possibility that
> instead of MAX(IPv4,IPv6) we charge based on MIN(IPv4,IPv6)?
> I'm not sure that would be a good idea, either, but I think it may not
> have ever been considered and I would be interested to see what
> the implications of such a structure might be.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> 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-ppml/attachments/20130407/650ae2e3/attachment.htm>


More information about the ARIN-PPML mailing list