I think I agree with Owen here.. to say it simply: Rather than sacrificing all the anti-flip protection by removing the word transfer from "Source entities within the ARIN region must not have received a transfer, allocation, or assignment.." *Add text* to include the exception you want. Add one line to allow transfers within the same entity to cross RIR boundaries.
--Heather On Wed, May 27, 2015 at 11:39 PM, Owen DeLong <[email protected]> wrote: > 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. > > 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. > > Owen > > > > > > On May 27, 2015, at 9:27 PM, Jason Schiller <[email protected]> > wrote: > > > > Owen, > > > > I am trying to understand your suggestion... is it: > > > > Draft Policy ARIN-2015-2 > > Modify 8.4 (Inter-RIR Transfers to Specified Recipients) > > > > Date: 26 May 2015 > > > > Problem Statement: > > > > Organizations that obtain a 24 month supply of IP addresses via the > > transfer market and then have an unexpected change in business plan > > are unable to move IP addresses to the proper RIR within the first 12 > > months of receipt. > > > > Policy statement: > > > > Replace 8.4, bullet 4, to read: > > > > "> Source entities within the ARIN region must not have received a > > transfer, allocation, or assignment of > > IPv4 number resources from ARIN for the 12 months prior to the > > approval of a transfer request. > > This restriction does not include M&A transfers. > > This restriction does not include a transfer to a wholly owned > > subsidiary out side of the ARIN service region > > if the recipient org will be required to not transfer the IP space > > for the remaining balance of 12 month window." > > > > Comments: > > > > The intention of this change is to allow organizations to perform > > inter-RIR transfers of space received via an 8.3 transfer regardless > > of the date transferred to ARIN . A common example is that an > > organization acquires a block located in the ARIN region, transfers it > > to ARIN, then 3 months later, the organization announces that it wants > > to launch new services out of region. Under current policy, the > > organization is prohibited from moving some or all of those addresses > > to that region's Whois; the numbers are locked in ARIN's Whois. It's > > important to note that 8.3 transfers are approved for a 24 month > > supply, and it would not be unheard of for a business model to change > > within the first 12 months after approval. In addition this will not > > affect the assignments and allocations issued by ARIN they will still > > be subject to the 12 month restriction. > > > > a. Timetable for implementation: Immediate > > > > b. Anything else > > > >> On Wed, May 27, 2015 at 8:03 AM, Owen DeLong <[email protected]> wrote: > >> 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. > >> > >> However, the policy as proposed creates too much opportunity for > unintended consequences that the original anti-flip language is intended to > prevent. > >> > >> Owen > >> > >>>> On May 26, 2015, at 10:30 PM, David Huberman < > [email protected]> wrote: > >>>> > >>>> Why is another region's policy problem or restrictions something that > needs > >>>> fixing through ARIN policy? > >>> > >>> Two answers: > >>> > >>> 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. > >>> AND > >>> Because ARIN policy currently prohibits staff from counting > out-of-region use as part of justification for a request. > >>> > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to > >>> the ARIN Public Policy Mailing List ([email protected]). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact [email protected] if you experience any issues. > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List ([email protected]). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact [email protected] if you experience any issues. > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|[email protected]|571-266-0006 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
