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