[arin-ppml] Revised text for Draft Policy 2014-1 (Out of region use)

Martin Hannigan hannigan at gmail.com
Mon Jul 28 13:51:10 EDT 2014


On Fri, Jul 25, 2014 at 2:29 AM, Milton L Mueller <mueller at syr.edu> wrote:

[ clip ]


>  Current policy neither clearly forbids nor clearly permits out of 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
> restricting
>
out of region use in various ways. None of these proposals have gained
> consensus. The next logical option is to discuss a proposal that clearly
> permits
>

IP numbers are both unique and globally route-able. Why do we need a policy
to tell us this?  How does inversing the statements (not allowed vs.
allowed) in the policy amount to any substantive change? It doesn't.


> out of region use. Permitting out of region use, however, poses issues
> that have
>
to be addressed by policy and adjustments to operational practice. Out of
> region use must be clearly defined and any operational practices based on
> that definition must not be unnecessarily burdensome. Also, it is more
> difficult and costly for ARIN staff to independently verify the
> justification and utilization of resources that are used outside of the
> ARIN service region. There needs to be recognition of this difference in
> policy and associated operational practices.
>

I'm confused. Why is it "more difficult" to verify justifications and
utilization "outside" of the ARIN region than in? If I assign an address to
an interface in Boston vs. an interface in Hong Kong, the only difference
is the geo. ARIN already doesn't understand the vast majority of the geo
nomenclature we use whether its in Boston or Hong Kong e.g. 230 Congress
vs. 9 Pat Tat, whether it's owned by a REIT (DLR) or is a tenancy (Equinix).



>  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. A resource
> is considered to be used outside the region if it exclusively serves a
> user, customer or technical infrastructure location outside the ARIN
> service region.
>

What does "exclusively" serves a user mean?

>
>
> The services and facilities used to justify the need for ARIN resources
> that will be used out of region should not also be used to justify resource
> requests from another RIR.
>
Isn't this meddling in other RIR local policies?

If LACNIC says it's ok for one to justify their utilization based on their
aggregate RIR history and that's acceptable to LACNIC and the party
requesting addresses, why is it not acceptable to ARIN? How is it enforced
if both parties simply ignore ARIN (which is what could likely happen)?

When a request for resources from ARIN is justified by need located within
> another RIR's service region and is more than the equivalent of a /20 for
> IPv4, a /36 for IPv6, or two (2) ASNs, the requesting organization will
> also report to ARIN the utilization status of all resources of the same
> type held with any other RIR that are used or are available for use within
> the requested service region.
>

[ Waiting to see the answer to the Schiller question ]


> The organization will also supply any additional supporting documentation
> requested by ARIN regarding the need for the reported resources.  The
> report must demonstrate that all resources currently available for use
> within the requested service region are efficiently utilized based on
> applicable ARIN policy.
>
If I have LACNIC resources in the LACNIC region and I am meeting the
prescribed needs requirements there, but not in the ARIN region, I have to
subject myself to a Section 12 audit for my LACNIC derived addresses? This
doesn't sound right, or productive.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140728/7f21a5b2/attachment.html>


More information about the ARIN-PPML mailing list