<div><br></div>Same, +1. <span></span><br>
<br>
Which isn't Section 11 a better place to address this?<br>
<br>
Best,<br>
<br>
-M<<br>
<br>
<br>
On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <<a href="javascript:;" onclick="_e(event, 'cvml', 'David.Huberman@microsoft.com')">David.Huberman@microsoft.com</a>> wrote:<br>
> Support in principle, strongly opposed as written.<br>
><br>
> ARIN is a registry, not a regulator.  Networks with global reach should not have regulatory rules placed on them by ARIN whose job is primarily to record number assignments, not make rules which affect network topology. Thus I support the idea that numbers should not be bound to arbitrary political boundaries.<br>

><br>
> I oppose this draft as written, however, because it adds hundreds of words to NRPM where only a few are needed to address the stated goal.  The problem statement indicates: " The next logical option is to discuss a proposal that clearly permits out of region use without limits".  Well ok.  If you wanted to do that explicitly in policy, how about:<br>

><br>
>         Section 1.x -  ARIN-issued number resources may be used on equipment located anywhere.<br>
><br>
> All the rest of the text that I see in this draft come down to, "if you have resources in other RIRs, we'll audit them to ensure you aren't double dipping." Policy already allows that:<br>
><br>
>         "ISPs must have efficiently utilized all previous allocations and at least 80% of their most recent allocation<br>
>          in order to receive additional space."<br>
><br>
>         " In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all<br>
>         previous assignments, and must provide ARIN with utilization details"<br>
><br>
> We need to simplify NRPM and start peeling back a lot of this over-regulatory policy.  To do so, let's write clearer and more concise policy proposals, please.<br>
><br>
> David R Huberman<br>
> Microsoft Corporation<br>
> Senior IT/OPS Program Manager (GFS)<br>
><br>
><br>
> From: <a href="javascript:;" onclick="_e(event, 'cvml', 'arin-ppml-bounces@arin.net')">arin-ppml-bounces@arin.net</a> [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'arin-ppml-bounces@arin.net')">arin-ppml-bounces@arin.net</a>] On Behalf Of David Farmer<br>

> Sent: Friday, March 28, 2014 10:23 AM<br>
> To: ARIN PPML<br>
> Subject: [arin-ppml] Update: 2014-1 Out of Region Use<br>
><br>
> Based on the discussion at the PPC in Atlanta (link below), the following changes are proposed.<br>
><br>
> <a href="https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov" target="_blank">https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov</a><br>
><br>
> There is a summary of the changes and a red-lined version of the policy text with new and deleted text highlighted following the complete Draft Policy.<br>
><br>
> ----<br>
><br>
> Draft Policy ARIN-2014-1<br>
> Out of Region Use<br>
><br>
> Date: 28 March 2014<br>
><br>
> Problem statement:<br>
><br>
> Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is to discuss a proposal that clearly permits out of region use without limits, beyond those already existing in policy.<br>

><br>
> Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use needs a clear definition and any operational practices based on that definition must not be unnecessarily burdensome. It is significantly more difficult and costly for ARIN Staff to independently verify the justification and utilization of resources that are reassigned or otherwise used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices, especially the cost differential when there is more than an incidental amount of out of region use.<br>

><br>
> Policy statement:<br>
><br>
> Create new Section X;<br>
><br>
> X. Out of Region Use<br>
><br>
> ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. Resources are considered to be used outside the region if the user or customer service address or the technical infrastructure address, such as the point of presence (POP), data center, or other similar location, are outside the ARIN service region.<br>

><br>
> There is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.  Therefore, the organization should, not hold any resources with the other RIR, or demonstrate that all such resources held are utilized based on ARIN policy requirements, or provide an operational justification clarifying how the resources from ARIN will not duplicate any underutilized resources held with the other RIR.<br>

><br>
> Only the utilization rate of ARIN registered resources or immediate need may be use to determine a valid request size beyond the applicable minimum allocation size.  The utilization rate of resources received from another RIR is not applicable in determining a valid request size.<br>

><br>
> X.1 Verification of Out of Region Use<br>
><br>
> The utilization of all ARIN registered resources must be verified when evaluating a request for additional resources or during a resource review, including any resources used outside the ARIN service region. All ARIN registered resources used outside the region must be verified to no less than an equivalent standard as resources used within the ARIN region. To this end ARIN, in its sole discretion, may engage independent external entities to assist it in the verification of information related to any resources used outside the region.<br>

><br>
> X.2 Reporting Resources Held with other RIRs<br>
><br>
> Except to the extent that incidental use, multi-instance use, or the critical infrastructure criteria described below apply, when out of region need is used to justify a request for resources from ARIN; The requesting organization will also report to ARIN the utilization status, based on applicable ARIN policy, of all resources it holds with the RIRs who's service regions the need justifying a request to ARIN is within, and any additional supporting documentation requested by ARIN regarding these reported resource.<br>

><br>
> X.3 Incidental Use<br>
><br>
> Out of region use of ARIN registered resources by an organization that totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2) ASNs within each of the other RIR's service regions are considered incidental use and as such are accounted for as if used within the ARIN service region.<br>

><br>
> X.4 Multi-Instance Use<br>
><br>
> Any resources used simultaneously in multiple locations, such as an anycast prefix or ASN, are considered as used within the ARIN service region, provided at least one instance is located within the region, regardless of how many other instances are located outside the region.<br>

><br>
> X.5 Critical Infrastructure<br>
><br>
> Resources justified through ARIN critical infrastructure policies are accounted for as if used within the ARIN service region, regardless of their actual location of use.<br>
><br>
> Comments:<br>
> a. Timetable for implementation: Immediate<br>
><br>
> b. Anything else<br>
><br>
> Current policy is ambiguous on the issue of out of region use of ARIN registered resources. The only guidance on the issue in current policy is in Section 2.2, that defines the term RIR; "... The primary role of RIRs is to manage and distribute public Internet address space within their respective regions." Some in the community believe this means out of region use should be at least limited or restricted while others believe this is only intended to focus efforts within the region and not define where resources may be used.<br>

><br>
> Several other policy proposals have explored restricting or otherwise limiting out of region use. None of these proposals gained consensus within the ARIN community. During the latest of these proposals, ARIN-2013-6, several standards were explored, a majority of use within region, a plurality of use within region, and some discussion of a minimum of 20 percent use within region. It was felt that each of these standards would interfered, to one extent or another, with the legitimate operations of multi- or trans-regional networks.<br>

><br>
> Section 2.2 tells us, the primary purpose of the RIRs are to manage and distribute resources within their regions. None the less, there have always been networks that don't neatly fit within the regions created by the RIR system. These legitimate trans-regional networks are operated by international businesses or global service providers, many of which are based within the ARIN region. Prior to IPv4 run-out, many of these trans-regional networks requested resources from ARIN for use both inside or outside the region, as long as the requests were justified by need.<br>

><br>
> As a result of IPv4 run-out, many in the community want to restrict out of region use to prevent ARIN resources from going to networks without a real technical presence in the ARIN region. However, any attempt to limit or restrict such out of region use inevitably will affect these legitimate trans-regional networks. Further, even the most restrictive regional use requirements will not significantly prolong the availability of IPv4 resources within the ARIN region. Therefore, attempting to restrict or limit out of region use of resources, even if it were for IPv4 only, is ineffective, inefficient, and overly burdensome to important elements of the global Internet.<br>

><br>
> The major concept behind this proposal is to allow out of region use without any limits, other than those already in policy, but bring an economic and reporting factors to play on the issue. It requires ARIN to verify out of region use of ARIN registered resources to no less than an equivalent standard as in region use, and enables ARIN to engage external entities to assist in this verification. It is expected ARIN will have agreements with all such external entities to ensure the confidentiality of all supporting documentation is preserved.<br>

><br>
> ARIN engaging external entities to assist in verification of out of region use is mostly an ARIN business issue, and not primarily a policy issue. However, today there is a general assumption that such verification for in region use is done almost exclusively in house at ARIN. Making this issue clear in policy follows a principle of least surprise, as the use of such external entities is likely to be frequently necessary to verify out of region use, especially in parts of the world where English is not the primary language. Or put another way, use of an external entity when verifying out of region use is more likely to be the rule rather than an exception.<br>

><br>
> When resources are requested for out of region use an organization also needs to report the utilization status of all resources it holds with the RIRs for the regions that the requested need is within.  This is to ensure there are not underutilized resources held with another RIR that would contradict the justified need for resources from ARIN.<br>

><br>
> There are additional expenses and complexity involved in verifying out of region use, as a result of language and logistical barriers that the regionality of the RIR system was originally conceived to mitigate.<br>
> In addition, evaluating the reported information about resources held with other RIRs, needed to ensure ARIN resources are not duplicating resources held with outer RIRs, increase staff's burden related to out of region use. Furthermore, section 2.2 is clear that providing resources for out of region use is, at best, only a secondary role for ARIN. As a result, out of region use should not significantly burden the primary role of providing resources for use within the region. These factors justify a recommendation to the Board of Trusties to create a separate fee structure for out of region use, creating the aforementioned economic factor.<br>

><br>
> This economic factor and the recommendation for a separate fee structure, are again mostly ARIN business issues, and not part of policy in general. However, this is one of those instances where policies and fees are intertwined.<br>

><br>
> It seems reasonable that this economic factor should be applied only to those that make substantial use of ARIN registered resources outside the region, and not to those that primarily use resources within the region. This proposal defines incidental out of region use, to ensure that trivial, insignificant or otherwise incidental use are exempt from the discussed economic factor, the reporting of resources help with other RIRs as well, and are accounted for as if used within the region.<br>

><br>
> Some amount of out of region use should be considered normal even for a network primarily based within the ARIN region. For example, numbering a global backbone that provides global access necessary for in region customers. Also, the other RIRs have minimum requirements to justify an initial allocation or assignment, similar to ARIN. These and other examples and issues, justify allowing some minimal amount of out of region use to be accounted for as if it were in region use. The currently proposed policy statement, X.3, defines incidental use in terms of an absolute thresholds for each type of resource.<br>

><br>
> Another option would be a percentage based threshold, say 20%. However, a percentage based threshold has the disadvantage that even a minimal change in usage can cause the ratio between in region and out of region use to change, potentially causing an oscillation around this threshold. This creates significant uncertainty for organizations as to if the discussed economic factor will apply to them, or not. Where as once an absolute threshold has been crossed by a significant amount, it is highly unlikely that any additional changes in usage will cause an oscillation around the threshold, providing much more certainty for most organizations.<br>

><br>
> Additionally, the proposal deals with a couple special cases in X.4 and X.5. Due to the relatively small resource impact and high importance to overall Internet stability; resources for critical infrastructure are accounted for as if used within the region. Anycast prefixes, and other resources used simultaneously in multiple locations, are considered as used outside the region only when they are exclusively used outside the region. Or put another way, as long as at least one instance is located within the region, they are considered used within the region, regardless of how many other instances are located outside the region. Both of these special cases have an overall positive impact on the Internet and should not be discouraged in anyway by this policy, lumping them in with general out of region use could be a disservice to the Internet and unnecessarily burdensome.<br>

><br>
> The intent of allowing an operational justification to clarify how resources received from ARIN will not duplicate any underutilized resources held with another RIR is to account for situations like; It may be necessary to use resources from another RIR to meet legal or regulatory requirements, or prevailing operational expectations, in some economies around the world. In such cases it is justified to also receive minimal resources from another RIR for use only in those economies. And using resources received from ARIN for the rest of a global network.<br>

><br>
> In summary, this proposal ensures that global organizations or global service providers base within the ARIN region may receive resources to operate their global network solely from ARIN, if they wish to do so. As long as the utilization of the out of region resources are verified to no less than an equivalent standard as in region resources and any additional reporting requirements are also meet. This is particularly important for IPv6; requiring organizations get IPv6 resources from multiple RIRs, or even making it appear that they should, will result in additional unique non-aggregatable prefixes within the IPv6 route table, rather than minimizing them, which one of the policy objectives for IPv6.<br>

><br>
> Finally, a separate but somewhat related issue; regardless of where ARIN registered resources are used, inside or outside of the ARIN service region, organizations must first qualify to receive resources from ARIN. ARIN's current operational practice is that an organization must be formed within the ARIN service region in order to qualify to receive any resources from ARIN. The issue of who should be eligible to receive resources was commingled with out of region use in ARIN-2013-6. It was felt these issues should be considered separately. Therefore, the issue of who should be eligible to receive resources is purposefully not dealt with by this proposal, and if any changes are necessary there should be separate policy proposals to deal with this issue independently.<br>

><br>
> ----<br>
><br>
> Summary of Changes;<br>
><br>
> - Clarified out of region use is valid justification for both new or additional resources.<br>
><br>
> - Eliminated "user or customer billing address" from definition for out of region use, and change the items left to sentence from, instead of list form.<br>
><br>
> - Added that there is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.<br>
><br>
> - Made it clear that only the utilization rate of ARIN resources or immediate need are used to determine the valid request size.<br>
><br>
> - New sections X.2 "Reporting Resources Held with other RIRs," this new section is intended to have organizations report the utilization of their resources, based on ARIN Policy, for the other RIRs where they are requesting ARIN resources for.  Except to the extent incidental use, multi-instance use, or critical infrastructure clauses apply.<br>

><br>
> - Changed incidental use to be on a per other RIR region basis to simplify the determination of if the Reporting Resources Held with other RIRs applies.<br>
><br>
> - Changed multi-instance use to use "at least one instance is located within the region" language.<br>
><br>
> - Updated the comments section to account for the above changes.<br>
><br>
> ----<br>
> Here is an annotated version of the policy text<br>
><br>
> Deleted Text<br>
> New Text<br>
> Retained Text<br>
> X. Out of Region Use<br>
><br>
> ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. Resources are considered to be used outside the region if any of the following are located outside the region. A. The user or customer billing address B. the user or customer service address or C. the technical infrastructure address, such as the point of presence (POP), data center, or other similar location, are outside the ARIN service region.<br>

><br>
> There is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.  Therefore, the organization should, not hold any resources with the other RIR, or demonstrate that all such resources held are utilized based on ARIN policy requirements, or provide an operational justification clarifying how the resources from ARIN will not duplicate any underutilized resources held with the other RIR.<br>

><br>
> Only the utilization rate of ARIN registered resources or immediate need may be use to determine a valid request size beyond the applicable minimum allocation size.  The utilization rate of resources received from another RIR is not applicable in determining a valid request size.<br>

><br>
> X.1 Verification of Out of Region Use<br>
><br>
> The utilization of all ARIN registered resources must be verified when evaluating a request for additional resources or during a resource review, including any resources used outside the ARIN service region. All ARIN registered resources used outside the region must be verified to no less than an equivalent standard as resources used within the ARIN region. To this end ARIN, in its sole discretion, may engage independent external entities to assist it in the verification of information related to any resources used outside the region.<br>

><br>
> X.2 Reporting Resources Held with other RIRs<br>
><br>
> Except to the extent that incidental use, multi-instance use, or the critical infrastructure criteria described below apply, when out of region need is used to justify a request for resources from ARIN; The requesting organization will also report to ARIN the utilization status, based on applicable ARIN policy, of all resources it holds with the RIRs who's service regions the need justifying a request to ARIN is within, and any additional supporting documentation requested by ARIN regarding these reported resource.<br>

><br>
> X.23 Incidental Use<br>
><br>
> Out of region use of ARIN registered resources by an organization that totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2) 10 ASNs within each of the other RIR's service regions are considered incidental use and as such are accounted for as if used within the ARIN service region.<br>

><br>
> X.4 Multi-Instance Use<br>
><br>
> Any resources used simultaneously in multiple locations, such as an anycast prefix or ASN, are accounted for as used outside the region, only if they are exclusively used outside the region.considered as used within the ARIN service region, provided at least one instance is located within the region, regardless of how many other instances are located outside the region.<br>

><br>
> X.35 Critical Infrastructure<br>
><br>
> Resources justified through ARIN critical infrastructure policies are accounted for as if used within the ARIN service region, regardless of their actual location of use.<br>
><br>
><br>
><br>
> --<br>
> ================================================<br>
> David Farmer               Email: <a href="javascript:;" onclick="_e(event, 'cvml', 'farmer@umn.edu')">farmer@umn.edu</a><br>
> Office of Information Technology<br>
> University of Minnesota<br>
> 2218 University Ave SE     Phone: 1-612-626-0815<br>
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<br>
> ================================================<br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="javascript:;" onclick="_e(event, 'cvml', '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="javascript:;" onclick="_e(event, 'cvml', 'info@arin.net')">info@arin.net</a> if you experience any issues.<br>