<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta content="MSHTML 6.00.6000.16825" name="GENERATOR">
</head>
<body>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">I agree with Leo's comments regarding the risks to deaggregation and routing table size with no sizable benefit.</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009"></span></font> </div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">The comment was made in San Antonio when we were discussing relaxing standards for community networks, and I'll echo/paraphrase it here...</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009"></span></font> </div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">I need to see some level of justification as to why provider independent space is a requirement and provider-allocated space will not work for a non-multihomed
network. Otherwise I'm not convinced that there's sufficient reason to loosen the requirements for direct allocations simply on the basis that it discriminates against those who can't/won't multihome or don't have a network of a specific size.</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009"></span></font> </div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">While I can see how innovation might be chilled by overly stringent allocation policies, I don't see how innovation or adoption is chilled by having to
use PD allocations, and I echo the statement that if policy was the only reason why IPv6 wasn't widely deployed, we'd be in FAR better shape right now.
</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009"></span></font> </div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">Yes, in the short term while there are ISPs that don't have their collective "stuff" together on an IPv6 deployment and it is not possible to *get* IPv6
service (and therefore also an allocation) from one's upstream, this would be a problem. However, that is going to be self-correcting for a lot of reasons, and if it's a deal-breaker, the entity in question will find another ISP that is able to meet their
needs.</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">If it's a block size issue, I would expect that this will go similarly to the way that it does in IPv4, either an ISP has enough space to allocate the requested
block size to their customer, or they go to Arin to get more space using this as the justification.</span></font></div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009"></span></font> </div>
<div dir="ltr" align="left"><font face="Arial" color="#0000ff" size="2"><span class="485505219-29052009">That said, as IPv4 space is getting harder to come by, ISPs have tightened up their justification requirements. It would be good to ensure that ISPs are
being more open in their allocations of IPv6 by comparison in order to ensure that we aren't preventing people who want IPv6 space from getting it. If that falls beyond ARIN's purview and this is an attempt to solve that, I'm not sure that it's the best solution.</span></font></div>
<!-- Converted from text/rtf format -->
<p><font face="Arial" size="2">Thanks,</font> <br>
<font face="Arial" size="2">Wes</font> <br>
</p>
<div class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left">
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net]
<b>On Behalf Of </b>Stacy Hughes<br>
<b>Sent:</b> Friday, May 29, 2009 1:49 PM<br>
<b>To:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Policy Proposal: Open Access To IPv6<br>
</font><br>
</div>
<div></div>
A multihoming requirement discriminates against networks that either cannot or do not want to multihome.
<div>I oppose this modification.</div>
<div>Stacy <br>
<br>
<div class="gmail_quote">On Fri, May 29, 2009 at 10:42 AM, Leo Bicknell <span dir="ltr">
<<a href="mailto:bicknell@ufp.org">bicknell@ufp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">In a message written on Fri, May 29, 2009 at 11:14:45AM -0400, Member Services wrote:<br>
> 1) Remove ?by advertising that connectivity through its single<br>
> aggregated address allocation? from article 3 of section 6.5.1.1<br>
><br>
> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in<br>
> the ARIN region or have a plan for making at least 200 end-site<br>
> assignments to other organizations within 5 years? in its entirety.<br>
<br>
</div>
I fear the way this is written may be confusing. Section 6.5.1.1 is at<br>
<a href="https://www.arin.net/policy/nrpm.html#six511" target="_blank">https://www.arin.net/policy/nrpm.html#six511</a><br>
<br>
If these changes were made, I believe the section would then read:<br>
<br>
6.5.1.1. Initial allocation criteria<br>
<br>
To qualify for an initial allocation of IPv6 address space, an<br>
organization must:<br>
<br>
1. be an LIR;<br>
2. not be an end site;<br>
3. plan to provide IPv6 connectivity to organizations to which it<br>
will assign IPv6 address space.<br>
<br>
I would like to make two comments as a result.<br>
<br>
Criteria #1 doesn't make a lot of sense. If you were a new participant<br>
(no IPv4 or IPv6 resources at all) and going only for IPv6 then you<br>
aren't an LIR yet, indeed, you are trying to become one. I think,<br>
but cannot be sure, that the LIR reference has to do with fee/membership<br>
structures of other RIR's.<br>
<br>
The result of this policy is basically you get an allocation if you<br>
want one and can show you will provide IPv6 to another entity and<br>
are willing to pay the fees. This is too loose of a standard.<br>
While I believe we should be giving out IPv6 relatively easily and<br>
there is no danger in running out of the numbers that does not mean<br>
we don't still have the issue of routing slots, staff to deal with<br>
the number of requests, and other issues.<br>
<br>
To that end, I would like to suggest a new criteria:<br>
<br>
- Plan to announce the IPv6 address space provided to at least<br>
two other autonomous systems.<br>
<br>
Basically, setting the bar at being multi-homed to BGP speaking<br>
networks. No number of sites requirement, you only need 1 customer<br>
to meet the customer requirement.<br>
<font color="#888888"><br>
--<br>
Leo Bicknell - <a href="mailto:bicknell@ufp.org">bicknell@ufp.org</a> - CCIE 3440<br>
PGP keys at <a href="http://www.ufp.org/~bicknell/" target="_blank">http://www.ufp.org/~bicknell/</a><br>
</font><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" target="_blank">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>
</blockquote>
</div>
<br>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1">This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and
delete all copies of the message.<br>
</font>
</body>
</html>