<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="GENERATOR" content="MSHTML 8.00.6001.19400">
</head>
<body>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="439561415-11042013">+1</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" size="2" face="Arial"><span class="439561415-11042013">
<p class="MsoNormal" align="left"><span style="FONT-FAMILY: Garamond; FONT-SIZE: 18pt">Mel Stotyn<br>
</span><span style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Senior Operations Specialist</span><span style="FONT-FAMILY: Garamond; FONT-SIZE: 18pt"><br>
</span><span style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">ENMAX Envision Inc.</span><span style="FONT-FAMILY: Garamond; FONT-SIZE: 18pt"><br>
</span><span style="FONT-FAMILY: Arial; FONT-SIZE: 10pt"><a title="mailto:mstotyn@enmax.com" href="blocked::mailto:mstotyn@enmax.com">mstotyn@enmax.com</a></span><span style="FONT-FAMILY: Garamond; FONT-SIZE: 18pt">
<br>
</span><span style="FONT-FAMILY: Arial; FONT-SIZE: 10pt">Phone: 403 514-3443</span></p>
</span></font></div>
<br>
<div dir="ltr" lang="en-us" class="OutlookMessageHeader" align="left">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> arin-discuss-bounces@arin.net [mailto:arin-discuss-bounces@arin.net]
<b>On Behalf Of </b>Brian Jones<br>
<b>Sent:</b> April 9, 2013 6:42 AM<br>
<b>To:</b> Randy Carpenter<br>
<b>Cc:</b> arin-discuss<br>
<b>Subject:</b> Re: [arin-discuss] tweak to proposed fee schedule<br>
</font><br>
</div>
<div></div>
<div dir="ltr">
<div style="FONT-SIZE: small" class="gmail_default"><br>
</div>
<div style="FONT-SIZE: small" class="gmail_default">Here here! This is the most reasonable suggestion I have heard as well.<br>
</div>
<div style="FONT-SIZE: small" class="gmail_default"><br>
<br>
"<br>
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.<br>
"<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>--<br>
Brian</div>
<br>
<br>
<div class="gmail_quote">On Mon, Apr 8, 2013 at 12:44 AM, Randy Carpenter <span dir="ltr">
<<a href="mailto:rcarpen@network1.net" target="_blank">rcarpen@network1.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<br>
I've been reading all of the discussion about the fee schedule and proposal 2013-3.<br>
<br>
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.<br>
<br>
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.<br>
<br>
thanks,<br>
-Randy<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
----- Original Message -----<br>
> Hi,<br>
><br>
> Currently there is a discussion going on over on ppml@ regarding policy<br>
> 2013-3, which is largely being driven by an incentive issue with ARIN's<br>
> proposed fee schedule. Specifically, the proposed fee schedule allows<br>
> for very small ISPs to fit in the "XX-small" category. However, the<br>
> current minimum allocation for an ISP is a /36 (with a /32 being the<br>
> "standard" allocation), which does not allow a very small ISP to fit in<br>
> the XX-small category.<br>
><br>
> See the tables here for more info:<br>
><br>
> <a href="https://www.arin.net/fees/pending_fee_schedule.html" target="_blank">https://www.arin.net/fees/pending_fee_schedule.html</a><br>
><br>
> Because of this, concern has been expressed that this creates a<br>
> disincentive for small ISPs to adopt IPv6. A policy proposal (2013-3)<br>
> has been developed that allows small ISPs to receive allocations as<br>
> small as /40s, while still reserving indefinitely a /32 for the ISP,<br>
> some or all of which the ISP can request at any time and without<br>
> justification.<br>
><br>
> However, there are some operational issues that arise from this use of<br>
> number policy to patch an issue with the fee schedule; these issues have<br>
> been discussed at length on PPML, and I refer the reader to the archive<br>
> of that discussion. Briefly summarized:<br>
><br>
> o It results in a messy addressing plan, where the ISP is forced to fit<br>
> into a small corner of the potential space it has available to it.<br>
> This, in turn leads to two consequences:<br>
><br>
> o Customers will receive sub-standard reassignments as the ISP becomes<br>
> increasingly parsimonious with address space.<br>
> o As the allocation grows toward the /32 boundary, it becomes less<br>
> likely that the ISP will be able to have internally aggregable routing,<br>
> and this may make it more likely that the ISP won't re-aggregate its<br>
> space as it increases the size of its allocation over time, *even* if<br>
> that space is from a single aggregable /32.<br>
><br>
> I'd like to propose a tweak to the proposed fee schedule as follows:<br>
><br>
> "ISPs which have IPv4 resources and an IPv6 allocation of exactly /32<br>
> will have their fees calculated from the fee schedule based only on<br>
> their IPv4 allocation. All allocation sizes other than IPv6 /32 will be<br>
> calculated from the fee schedule based on the greater of their IPv4 or<br>
> IPv6 allocation."<br>
><br>
> This only affects ISPs whose IPv4 allocations are in the X-small or<br>
> XX-small range *and* who have a /32 allocation. ISPs and end sites with<br>
> allocations/assignments in the small or greater category will still pay<br>
> the greater of their IPv4/IPv6 allocation-category fee.<br>
><br>
> It's revenue-neutral with respect to the pending fee schedule, combined<br>
> with proposal 2013-3 because that proposal calls for the reservation of<br>
> the /32 for that ISP anyway. I believe this tweak still allows for a<br>
> sustainable revenue model for ARIN until such a time as ARIN ceases to<br>
> provide IPv4 services, at which point the fee schedule will likely need<br>
> to be revisited anyway.<br>
><br>
> I am interested in this community's thought on this tweak. I realize<br>
> the fee schedule is always a contentious issue, and I am reluctant to<br>
> get into a general discussion of fees (for more general discussions,<br>
> please create a separate thread). However, I would like to know if<br>
> there are specific issues or incentive problems with what I am proposing.<br>
><br>
> Note also that I have no stake in this issue; this fee tweak would not<br>
> impact myself nor my current or previous employers.<br>
><br>
> Michael Sinatra<br>
> Energy Sciences Network<br>
> LBNL/DOE Office of Science<br>
> _______________________________________________<br>
> ARIN-Discuss<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Discussion Mailing List (<a href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-discuss" target="_blank">http://lists.arin.net/mailman/listinfo/arin-discuss</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
><br>
_______________________________________________<br>
ARIN-Discuss<br>
You are receiving this message because you are subscribed to<br>
the ARIN Discussion Mailing List (<a href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-discuss" target="_blank">http://lists.arin.net/mailman/listinfo/arin-discuss</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br clear=all> <HTML>
<BODY>
*******************************<P>
This e-mail message is intended only for the person(s) named above and may contain confidential or privileged information. If you are not the person named or have not been authorized by them to access their mail, please notify the sender immediately and delete this e-mail and any attachments without reading, saving, or forwarding.
<P> ******************************
</BODY>
</HTML>
</body>
</html>