[arin-ppml] Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A

Wed Oct 16 11:17:26 EDT 2019

On Wed, Oct 16, 2019 at 10:53 Owen DeLong <owen at delong.com> wrote:

>
>
> > On Oct 14, 2019, at 11:17 AM, Fernando Frediani <fhfrediani at gmail.com>
> wrote:
> >
> > On 14/10/2019 14:49, Owen DeLong wrote:
> >> You have the control relationship backwards. IANA is a function
> performed by  PTI under a contract controlled by the NRO (Number Resource
> Organization). The NRO is the five RIRs and they tell ICANN how to perform
> the IANA function, not the other way around.
> >
> > That's correct, however for a Global Policy to pass it takes quiet a
> while on all five RIRs and in some of them proposals with similar content
> have not reached consensus yet or were denied by a significant portion of
> the participants therefore I doubt this would be different for a Global
> Policy with this intent.
>
> Global policy is not needed here. Global policies direct IANA on how it
> functions in relation to the RIRs.
>
> A transfer from one RIR to another does not involve IANA. It is strictly
> between the RIRs. The only policy needed is that of the cooperating RIRs in
> question.
>
> Owen

Correct. Thought someone could take the coordinated approach and end up
with a ‘similar’ policy region by region. That is “faster” than the organic
approach and will elicit immediate up or downs across the regions. In my
experience, the coordinated approach is a long shot. The best part of it is
the early warning system indicating to save time and avoid. #IMHO

YMMV,

Best,

Martin

>
> >
> > Fernando
> >
> >>
> >> I’m still on the fence about allowing this, but the argument that it is
> not permitted by IANA/ICANN/PTI is completely hollow.
> >>
> >> Owen
> >>
> >>
> >>> On Oct 14, 2019, at 13:00, hostmaster at uneedus.com wrote:
> >>>
> >>> The process of IPv6 is that IANA, which is a function of ICANN
> provides blocks of IPv6 numbers to the RIR's for allocation and assignment.
> >>>
> >>> Due to the shortage of IPv4 numbers and 16 bit ASN numbers, ICANN and
> IANA has permitted inter RIR transfers to happen with these resources.
> However this consent has never extended to IPv6 addresses.
> >>>
> >>> I am unaware that IANA/ICANN has EVER voted to permit ARIN or any
> other RIR to give control of portions of the blocks of IPv6 numbers
> assigned to ARIN to a different RIR, which is what an inter-RIR transfer of
> IPv6 resources is.
> >>>
> >>> In the IPv6 space there are no legacy addresses.  Every Block of IPv6
> space was assigned to a specific RIR.  That includes every address within
> that block.  Transfers would require a policy at IANA/ICANN to permit these
> actions.  Does such permission exist, and can anyone point me towards it?
> >>>
> >>> In any case, even if it is possible, does not mean that it is a good
> idea. I still maintain that every IPv6 registrant knew the rules of the
> road when they received their block.  Those rules were that they were not
> transferable between RIR's.  If they later choose a different RIR, I say
> let them renumber.
> >>>
> >>> Albert Erdmann
> >>> Network Administrator
> >>> Paradise On Line Inc.
> >>>
> >>>> On Mon, 14 Oct 2019, William Herrin wrote:
> >>>>
> >>>> On Mon, Oct 14, 2019 at 7:50 AM Fernando Frediani <
> fhfrediani at gmail.com> wrote:
> >>>>> On 12/10/2019 13:58, William Herrin wrote:
> >>>>>> On Sat, Oct 12, 2019 at 6:29 AM <hostmaster at uneedus.com> wrote:
> >>>>>>>> I agree.  The only reason for this transfer thing was the
> shortage of IPv4
> >>>>>>>> addresses and 16 bit ASN numbers.  There is no shortage of IPv6
> addresses
> >>>>>>>> or 32 bit ASN.
> >>>>>>> Therefore, I agree that IPv6 transfers and 32 bit ASN transfers
> should not
> >>>>>>> be permitted, even for M&A.
> >>>>>> I have almost exactly the opposite opinion. No shortage means no
> cause to game the system. No gaming of the system means the transfer is
> requested for
> >>>> reasonable, pragmatic causes. Like avoiding renumbering pain. Why
> should this be prevented?
> >>>>> Because this is not a strong enough reason to allow IPV6 and 32-bit
> ASN be moved from one region to another. Although there are costs to do
> renumbering
> >>>> this is part of the business and anyone in such situation must be
> prepared to do so.
> >>>> Respectfully, I think you have it backwards. We shouldn't need a
> reason to allow something, we should need a reason to prevent it. Maybe not
> a great reason
> >>>> (that probably sets the bar too high) but at least a plausible reason.
> >>>>> The type of scenario that is being proposed here is not something
> that happens so frequently, in some cases may be very specific and is not
> very
> >>>> productive to change such an important thing like allowing IPv6 and
> 32-bits ASN to be moved between regions with the impacts it causes in the
> whole global
> >>>> registering system just to accomplish the need of a few which have
> workable plausible option available. Therefore the need of a few cannot
> overcome the
> >>>> interest of the whole system.
> >>>> Like what? What malfunctions or functions inefficiently if with the
> receiving registry's consent we allow a registrant to move their IPv6
> addresses and AS
> >>>> numbers from ARIN to a different registry?
> >>>> Regards,
> >>>> Bill Herrin
> >>>> --
> >>>> William Herrin
> >>>> bill at herrin.us
> >>>> https://bill.herrin.us/
> >>> _______________________________________________
> >>> ARIN-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:
> >>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> >> _______________________________________________
> >> ARIN-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:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > ARIN-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:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> ARIN-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:
> https://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/20191016/f87a1a29/attachment.htm>