On Wed, Oct 16, 2019 at 10:53 Owen DeLong <[email protected]> wrote: > > > > 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
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, [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. >
_______________________________________________ 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.
