<div dir="ltr">I think I agree with Owen here..  to say it simply:<div><br></div><div>Rather than sacrificing all the anti-flip protection by removing the word transfer from "<span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">Source entities within the</span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"> </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px">ARIN region must not have received a transfer, allocation, or assignment.."    </span><b>Add text</b> to include the exception you want.  Add one line to a<span style="font-size:12px;line-height:18px;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">llow transfers within the same entity to cross RIR boundaries. </span></div><div><br></div><div>--Heather</div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12px;line-height:18px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 11:39 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My suggestion is that I don't mind (virtually) unrestricted moves of addresses to different regions staying with the same organization. However, if we are to allow that, I want us to find a way that you can't merely use that as a way to move addresses out of flip protection to then flip them to another organization via an RIR with a less restrictive transfer policy.<br>
<br>
So... If you transfer addresses to another region, keeping them in the same organization, no penalty. However, you are not allowed to subsequently transfer them (or other addresses in that region) to an external party for at least 12 months.<br>
<span class="HOEnZb"><font color="#888888"><br>
Owen<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
> On May 27, 2015, at 9:27 PM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:<br>
><br>
> Owen,<br>
><br>
> I am trying to understand your suggestion... is it:<br>
><br>
> Draft Policy ARIN-2015-2<br>
> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)<br>
><br>
> Date: 26 May 2015<br>
><br>
> Problem Statement:<br>
><br>
> Organizations that obtain a 24 month supply of IP addresses via the<br>
> transfer market and then have an unexpected change in business plan<br>
> are unable to move IP addresses to the proper RIR within the first 12<br>
> months of receipt.<br>
><br>
> Policy statement:<br>
><br>
> Replace 8.4, bullet 4, to read:<br>
><br>
> "> Source entities within the ARIN region must not have received a<br>
> transfer, allocation, or assignment of<br>
>    IPv4 number resources from ARIN for the 12 months prior to the<br>
> approval of a transfer request.<br>
>    This restriction does not include M&A transfers.<br>
>    This restriction does not include a transfer to a wholly owned<br>
> subsidiary out side of the ARIN service region<br>
>    if the recipient org will be required to not transfer the IP space<br>
> for the remaining balance of 12 month window."<br>
><br>
> Comments:<br>
><br>
> The intention of this change is to allow organizations to perform<br>
> inter-RIR transfers of space received via an 8.3 transfer regardless<br>
> of the date transferred to ARIN . A common example is that an<br>
> organization acquires a block located in the ARIN region, transfers it<br>
> to ARIN, then 3 months later, the organization announces that it wants<br>
> to launch new services out of region. Under current policy, the<br>
> organization is prohibited from moving some or all of those addresses<br>
> to that region's Whois; the numbers are locked in ARIN's Whois. It's<br>
> important to note that 8.3 transfers are approved for a 24 month<br>
> supply, and it would not be unheard of for a business model to change<br>
> within the first 12 months after approval. In addition this will not<br>
> affect the assignments and allocations issued by ARIN they will still<br>
> be subject to the 12 month restriction.<br>
><br>
> a. Timetable for implementation: Immediate<br>
><br>
> b. Anything else<br>
><br>
>> On Wed, May 27, 2015 at 8:03 AM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
>> I could support a policy that allows you to transfer them to your own entity out of region for this purpose if there were some language that prevented subsequent flipping.<br>
>><br>
>> However, the policy as proposed creates too much opportunity for unintended consequences that the original anti-flip language is intended to prevent.<br>
>><br>
>> Owen<br>
>><br>
>>>> On May 26, 2015, at 10:30 PM, David Huberman <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>> wrote:<br>
>>>><br>
>>>> Why is another region's policy problem or restrictions something that needs<br>
>>>> fixing through ARIN policy?<br>
>>><br>
>>> Two answers:<br>
>>><br>
>>> Because ARIN-region networks, subject to ARIN's NRPM, need to be able to move IP addresses out of region where and when they're needed.<br>
>>> AND<br>
>>> Because ARIN policy currently prohibits staff from counting out-of-region use as part of justification for a request.<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" rel="noreferrer" 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" rel="noreferrer" 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>
><br>
> --<br>
> _______________________________________________________<br>
> Jason Schiller|NetOps|<a href="mailto:jschiller@google.com">jschiller@google.com</a>|<a href="tel:571-266-0006" value="+15712660006">571-266-0006</a><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" rel="noreferrer" 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>
</div></div></blockquote></div><br></div>