<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It seems the ARIN staff has taken a “virtualized hosts/devices/infrastructure don’t count” approach. I understand ARIN staff’s concern about potential abuse by some folk who may spin up a bunch of virtualized servers to get some address space, and then use that address space anywhere in the world and/or in a way that wouldn’t have met the NPRM’s criteria, but it seems that ARIN’s brush is a bit too broad.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>As others have pointed out at the PPC and in this discussion, virtualization is here to stay, and it doesn’t make sense that ARIN staff’s practices don’t line up with reality if the NPRM doesn’t preclude that. The NPRM only talks about hosts, devices, and infrastructure. I don’t believe there is anything that requires a <i>physical</i> host or <i>physical</i> infrastructure (i.e. load balancer). Rather than disallow virtualized hosts or infrastructure from contributing to a host count, why not require the requestor to provide some documentation of the validity of these virtualized hosts, perhaps through invoices showing that Customer A had an average of 30 servers and a peak of 45 servers in the last month, Customer B had an average of 10 servers and a peak of 50 servers in the last month, etc, and then some aggregate data that shows many virtualized servers operated on average and at peak. It seems that in general the community trusts ARIN staff to sniff out abuse – and if initially the requestors are required to show the last 3 or 6 or 9 months of invoices or virtualization data, that’s a lot better than the current practice of not being willing to count them at all. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>And just to state my understanding of current practice, the use of virtualization isn’t a major factor in current practice if the customers are predominately in the USA, but the concern is if the virtualization hoster has many out-of-region customers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Frank<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net] <b>On Behalf Of </b>Victor Kuarsingh<br><b>Sent:</b> Tuesday, October 08, 2013 12:46 PM<br><b>To:</b> Owen DeLong<br><b>Cc:</b> John Curran; arin-ppml@arin.net<br><b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Owen, all,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I am in agreement, in general, with text that takes that form if this would cover the cases where the use of the addresses would be used on an interfaces, servers, VMs or other elements which are built upon equipment which is present in the ARIN region.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>regards,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Victor K <o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Oct 8, 2013 at 1:06 PM, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>Perhaps replacing "technical infrastructure" with "addresses assigned<br>to equipment and/or interfaces physically present within the ARIN region".<br><br>Owen<br><br>On Oct 7, 2013, at 8:37 AM, John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>> wrote:<br><br>> On Oct 6, 2013, at 3:22 PM, William Herrin <<a href="mailto:bill@herrin.us">bill@herrin.us</a>> wrote:<br>><br>>> There is a subtlety here that is escaping me. If the addresses are<br>>> assigned to hosted infrastructure within the region then how are they<br>>> not used within the region?<br>><br>> Bill -<br>><br>> Apologies in advance for length - the community is entitled to a complete<br>> understanding of how we administer number resources, and that appears to<br>> take more words than I expected at first..<br>><br>> Technical infrastructure can be used to justify addresses (for example,<br>> network routers, POP equipment, concentrators, management systems, IT<br>> systems, data center servers, etc.) We're very experienced with this,<br>> and often ask for equipment lists, invoices, etc. to confirm existence<br>> of the asserted equipment.<br>><br>> When technical infrastructure grows, more IP addresses are needed for<br>> assignment to the technical infrastructure. Technical infrastructure<br>> exists in a region based on the location of the physical devices.<br>><br>> Customers growth can also justify addresses (e.g. you assign addresses to<br>> an single customer, or customer growth requires that a certain dynamic pool<br>> assigned to customers be expanded) We are also quite experienced with the<br>> verification of customers, including obtaining customer lists, contact info,<br>> etc.<br>><br>> When the number of customers served grows, more IP addresses are needed to<br>> assign to the new customers, or to assign to the dynamic pools for those<br>> customers. Customers exist in a region, based on their actual location of<br>> each customer.<br>><br>> For example, if someone needs more addresses because they are adding<br>> new VPN concentrators (i.e. more actual equipment itself), then that is<br>> indeed technical infrastructure need based on where the equipment will<br>> be installed. i.e. if you buy stacks of new VPN concentrators and have<br>> no addresses to connect them to your infrastructure, it's a simple matter<br>> to request (per policy) additional addresses needed. We do this all of<br>> the time with the infrastructure side of DSLAMS, cable head-ends, wifi<br>> nodes, etc.<br>><br>> If someone needs additional addresses for their _customers_ (including<br>> to expand a dynamically assigned pool), then we verify the customer<br>> growth as noted earlier, including the location of the customers.<br>><br>> Requesters have to show that they have additional equipment or additional<br>> customers to obtain addition addresses. Both equipment and customers are<br>> associated with real-world addresses, and hence are within some region of<br>> the registry system.<br>><br>>> What aspect of the draft policy would change that evaluation? ...<br>><br>> The draft policy 2013-6 reads as follows:<br>><br>> "In addition to meeting all other applicable policy requirements,<br>> a plurality of new resources requested from ARIN must be justified<br>> by technical infrastructure or customers located within the ARIN<br>> service region, and any located outside the region must be<br>> interconnected to the ARIN service region."<br>><br>> The requesters who were previously discussed (i.e. "the 52" who have received<br>> allocations since mid-year), often have some existing infrastructure, are not<br>> adding anything more, and do not need more addresses due to their _technical<br>> infrastructure_ growth.<br>><br>> They do have remarkable customer growth, and hence need additional addresses.<br>> Under the policy change proposed by 2013-6, we would only consider customers<br>> within the ARIN service region for this purpose, and would provide an allocation<br>> which they could justify based on that in-region customer demand. The proposed<br>> policy change makes clear that customers must be in-region to be considered.<br>> (The present policy does not have such a constraint, hence the approval of<br>> recent requests where the vast majority of customers are known to be outside<br>> the ARIN region.)<br>><br>> We don't consider virtual "technical infrastructure" for assessing the need<br>> for addresses, even though service providers may use such when adding customers.<br>> The additional customers driving such virtual growth are readily verifiable.<br>> The alternative would be to consider virtual equipment (e.g. VM's) as actual<br>> technical infrastructure and that would effectively open the justification of<br>> unlimited resources by any party without any actual equipment or customer growth.<br>><br>> If the desire was to simply clarify existing policy (without actually changing<br>> the current practice), it could be accomplished by dropping the "in region"<br>> requirement for customers as follows: "must be justified by technical<br>> infrastructure within the ARIN or by customers located anywhere as long as<br>> the addresses are managed and interconnected in the ARIN service region."<br>> (Note that such a change would make rather clear that nearly any heavily-utilized<br>> customer-driven IP address pool interconnected in the ARIN region can qualify<br>> for additional resources, which may or may not be a desirable outcome depending<br>> on one's individual perspective.)<br>><br>> I hope this helps in clarifying what ARIN-2013-6 would be change to the<br>> existing policy, as it would make clear that customer growth in-region<br>> would be necessary to justify requests, whereas presently we have some<br>> folks requesting resources using nominal equipment within the region and<br>> backed by extensive customer growth external to the region.<br>><br>> Please do not hesitate to ask if you have any further questions - it is<br>> indeed very important that folks understand how we implement the policy<br>> in order to fully consider any proposed policy changes, so thank you for<br>> your diligence on this topic.<br>><br>> /John<br>><br>> John Curran<br>> President and CEO<br>> ARIN<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><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.<o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></body></html>