[arin-ppml] Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)

Heather Schiller heather.skanks at gmail.com
Mon Oct 5 20:59:14 EDT 2015


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 <owen at delong.com> 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 <jschiller at google.com>
> 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 <owen at delong.com> 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 <
> David.Huberman at microsoft.com> 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 (ARIN-PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > --
> > _______________________________________________________
> > Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20151005/a6c916a5/attachment.htm>


More information about the ARIN-PPML mailing list