<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 7:30 AM, <span dir="ltr"><<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was always under the impression that companies that operate in more than one region usually obtain their number resources from their home region, and use these worldwide.<br></blockquote><div><br></div><div>That is one way to do things, and especially if you primarily operate in one region and have some operations in other regions. However, if you view yourself as a global operation it is equally valid to obtain resources from multiple or all RIRs. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I once worked with a company who was based in the Netherlands, but has a presence all over the world. I was involved in their networks in the USA, using a portion of a class B legacy space, which was at the time assigned to RIPE. However, we used it in Texas and Florida. We dealt with the geolocation problem by setting up proxy servers with address space from a local ISP for internet access, and to save cross ocean bandwidth for general internet access. Places like Netflix treated this space as Europe, even though the space was SWIP'ed to the USA.<br>
<br>
It is my understanding that section 9 of the NRPM allows out of region use. Is there a reason you do not simply leave the resources registered with ARIN? Is it because local affiliates, or otherwise?<br></blockquote><div><br></div><div>The out of region use policy, is permissive not proscriptive policy, it allow out of region use, and only requires that need in another region cannot be used as a justification to obtain resources from both ARIN and another RIR at the same time. The choice of where to obtain resources or maintain the registry of resources used in another region remains with the entity using the resources. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
<br>
On Fri, 18 Aug 2017, David Huberman wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am a US-based company and I operate a network on multiple continents.<br>
<br>
I need to be able to move space from my home RIR of ARIN to other regions as I expand my network overseas.<br>
<br>
The current policy that has been in effect for many years allows me to operate my network properly -- using ARIN blocks in ARIN, APNIC blocks in APNIC, and RIPE blocks in RIPE. The policy is predictable and I can plan network growth around it.<br>
<br>
If this proposal passes, it will shut off transfers between ARIN and APNIC. This will hurt my business's finances. We purchased addresses in the ARIN region wth the intention of moving them to APNIC in the future. We did so because the size blocks we needed were not available in the APNIC region. So now we are talking about hurting my business for ... what reason? How do network operations benefit from this proposal?<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Aug 18, 2017, at 6:10 AM, <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a> wrote:<br>
<br>
I would not consider an RIR that has NIR units that do not have a bi directional transfer policy to comply with the policy of ARIN to only permit transfers to/from those with a bi directional transfer policy.<br>
<br>
Thus, I support the statement being added in this draft to make this more clear.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 17 Aug 2017, WOOD Alison * DAS wrote:<br>
<br>
Thank you for the feedback on this draft policy to date. I would appreciate any other thoughts or comments on this draft policy.<br>
<br>
For review, Draft Policy 2017-6 is intended to add the following conditions on Inter RIR transfers to section 8.4:<br>
<br>
Recipient RIR policy must not permit transfers to other RIRs or NIRs whose policies do not support bi-directional transfers.<br>
<br>
And the problem statement on this draft policy is:<br>
<br>
Currently ARIN's requirement that inter-RIR transfer policies be reciprocal has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR transfer process can be used to circumvent the intent of the requirement. Rather than eliminate the requirement, a better approach would be to close the loophole.<br>
<br>
All feedback is appreciated.<br>
<br>
Thank you<br>
<br>
-Alison Wood<br>
<br>
</blockquote>
______________________________<wbr>_________________<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" target="_blank">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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
______________________________<wbr>_________________<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" target="_blank">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" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-3142731932119512508gmail_signature" data-smartmail="gmail_signature">==============================<wbr>=================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank">612-626-0815</a><br>Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank">612-812-9952</a><br>==============================<wbr>================= </div>
</div></div>