[arin-ppml] Update: 2014-1 Out of Region Use

Fri Apr 4 20:12:46 EDT 2014

Same, +1.

Which isn't Section 11 a better place to address this?

Best,

-M<

On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <
David.Huberman at microsoft.com <javascript:;>> wrote:
> Support in principle, strongly opposed as written.
>
> 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.
>
> 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:
>
>         Section 1.x -  ARIN-issued number resources may be used on
equipment located anywhere.
>
> 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:
>
>         "ISPs must have efficiently utilized all previous allocations and
at least 80% of their most recent allocation
>          in order to receive additional space."
>
>         " In order to justify an additional assignment, end-users must
have efficiently utilized at least 80% of all
>         previous assignments, and must provide ARIN with utilization
details"
>
> 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.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
>
> From: arin-ppml-bounces at arin.net <javascript:;> [mailto:
arin-ppml-bounces at arin.net <javascript:;>] On Behalf Of David Farmer
> Sent: Friday, March 28, 2014 10:23 AM
> To: ARIN PPML
> Subject: [arin-ppml] Update: 2014-1 Out of Region Use
>
> Based on the discussion at the PPC in Atlanta (link below), the following
changes are proposed.
>
>
https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov
>
> 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.
>
> ----
>
> Draft Policy ARIN-2014-1
> Out of Region Use
>
> Date: 28 March 2014
>
> Problem statement:
>
> 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.
>
> 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.
>
> Policy statement:
>
> Create new Section X;
>
> X. Out of Region Use
>
> 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.
>
> 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.
>
> 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.
>
> X.1 Verification of Out of Region Use
>
> 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.
>
> X.2 Reporting Resources Held with other RIRs
>
> 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.
>
> X.3 Incidental Use
>
> 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.
>
> X.4 Multi-Instance Use
>
> 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.
>
> X.5 Critical Infrastructure
>
> 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.
>
> Comments:
> a. Timetable for implementation: Immediate
>
> b. Anything else
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> ----
>
> Summary of Changes;
>
> - Clarified out of region use is valid justification for both new or
additional resources.
>
> - 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.
>
> - 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.
>
> - Made it clear that only the utilization rate of ARIN resources or
immediate need are used to determine the valid request size.
>
> - 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.
>
> - 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.
>
> - Changed multi-instance use to use "at least one instance is located
within the region" language.
>
> - Updated the comments section to account for the above changes.
>
> ----
> Here is an annotated version of the policy text
>
> Deleted Text
> New Text
> Retained Text
> X. Out of Region Use
>
> 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.
>
> 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.
>
> 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.
>
> X.1 Verification of Out of Region Use
>
> 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.
>
> X.2 Reporting Resources Held with other RIRs
>
> 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.
>
> X.23 Incidental Use
>
> 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.
>
> X.4 Multi-Instance Use
>
> 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.
>
> X.35 Critical Infrastructure
>
> 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.
>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu <javascript:;>
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140404/2f266624/attachment.htm>