> On Oct 14, 2019, at 11:17 AM, Fernando Frediani <[email protected]> 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 > > 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, [email protected] 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 <[email protected]> >>>> wrote: >>>>> On 12/10/2019 13:58, William Herrin wrote: >>>>>> On Sat, Oct 12, 2019 at 6:29 AM <[email protected]> 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 >>>> [email protected] >>>> https://bill.herrin.us/ >>> _______________________________________________ >>> ARIN-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: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] if you experience any issues. >> _______________________________________________ >> ARIN-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: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. > _______________________________________________ > ARIN-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: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-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: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
