Hi Adam, I don't have the need to "disguise" any policy proposal. I'm a very honest and transparent person, pity that you didn't noticed it, and if I believe that IPv6 transfers outside of M&A's are required, I will submit that policy in an open and transparent manner.
I've you believe that I'm trying to cheat the community, please say so clearly and show evidences. That said, I'm happy to work on IPv6 Inter-RIR transfers at a later stage, but this is not the case with this proposal. The policies not always have cases that *already happened*. The policies should be there to prevent those cases being real needs and rejected. In fact, if they happened there may several situations: 1) The organizations that need that read the policy manual, understood they can't do it, and desisted. 2) They asked the secretariat. 3) They didn't read the policy/DBs update is managed (or not updated al all), that nobody noticed it, especially in intra-RIR situations. So the question here is, do we want to have oredered solutions for real business situations, or we prefer to ignore them and even force them to bypass the policies and hide the situation? If we don't have policies up-front problems, then problems became a huge issue, delay business, even may create losses. Some folks will just ignore policies and go ahead. We all know it. Policies have been done *always* up-front issues happening, when those possible issues where discovred, not just after we discover the issue. Some times we have policies too late, because nobody discovered the issue: that's unavoidable, because we don't have the crystal ball. I can't talk for the secretariat if there have been questions about this previously, hopefully they can say. I know it happened in other regions. By the way, my reading of the RIPE procedures is that they don't distinguish if you do an M&A with all the resources or part of it, they may confirm it (I'm sure they are in the list), if that's the case, and if already happened or there have been questions on that. Clearly the secretariat, and the same for other RIRs, should work on developing whatever the community decides is good to have. And I think it is much better to ensure that we have those developments in mind up-front of having real problems, specially if they may be complex and require coordination among different RIRs, instead of rushing when we have the problems already in our back, right? Regards, Jordi @jordipalet El 1/3/21 3:31, "[email protected] en nombre de [email protected]" <[email protected] en nombre de [email protected]> escribió: Hi all, I oppose this proposal. I am not convinced of the need for it. Are there examples of when an M&A request was refused that would be permitted by this policy change? This looks like an IPv6 Inter-RIR transfer proposal in disguise? I don't think the APNIC Secretariat should be required to do the development work to support IPv6 reverse DNS if there is no clear indication that other regions will support IPv6 reverse DNS fragments in the future. Adam On 2021-02-01 22:25, chku wrote: > Dear SIG members, > > A new version of the proposal "prop-130: Modification of transfer > policies" > has been sent to the Policy SIG for review. > > It will be presented during the Open Policy Meeting at > APRICOT2021/APNIC 51 > online-only conference on Wednesday, 03 February 2021. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC conference is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > http://www.apnic.net/policy/proposals/prop-130 > > Regards, > Bertrand and Ching-Heng > APNIC Policy SIG Chairs > > > ------------------------------------------------------- > > prop-130-v003: Modification of transfer policies > > ------------------------------------------------------- > > Proposer: Jordi Palet Martnez > [email protected] > > > 1. Problem statement > -------------------- > > Existing transfer policies for IPv4, IPv6 and ASN resources have some > differences among what is allowed and what not, if in the case of > intra-RIR and inter-RIR, and it is not clear if in case of merger and > acquisitions it is referring to a complete company, part of it, or even > if in case of a company reorganization or relocation, the policy is > supportive to that case. > > In some regions, this may not be a policy, but an administrative > procedure, but this may change in the future by means of a policy > proposal. > > In the caser of inter-RIR, the counterpart RIR need to have a > reciprocal > policy or procedure that allows it. > > Finally, there should not be differences from the APNIC perspective, on > the considerations of an M&A for different type of resources, because > there is no reason for allowing, for example, IPv4 resources to be > transferred, and instead IPv6 ones not. For example, an organization > may > be hosting services in a Data Center, by means of Virtual Machines and > moving to a different DC in another region. It is ridiculous to allow > to > keep the IPv4 addresses (so not renumber the VMs) and instead ask to > renumber IPv6. It is a big and unnecessary disruptive complexity. > > > 2. Objective of policy change > ------------------------------ > To ensure that the policy text is clarified, if those cases are > supported by the community. > > It will also facilitate companies or business units, moving or being > established in other regions. > > It will minimize legal issues in case an acquisition claiming their > rights over the acquired company and their existing assets (resources). > > > 3. Situation in other regions > ------------------------------ > There is a variety of support of all those cases in different regions. > The one more open is RIPE, followed by ARIN and LACNIC. A similar > policy > proposal is being discussed in AFRINIC. > > > 4. Proposed policy solution > ---------------------------- > Actual Text > 8.4. Mergers & acquisitions > APNIC will process and record the transfer of IPv4 resources as the > result of merger or acquisition. > > 11.0. Transfer of IPv6 resources > APNIC will only recognize the transfer or IPv6 addresses as the result > of Merger & Acquisition activity. The following conditions and > consequences apply. > > 13.3. Mergers & acquisitions > APNIC will recognize the transfer of ASNs as the result of merger or > acquisition. > > > Proposed Text > 8.4. Mergers, acquisitions and relocations > APNIC will recognize the transfer of IPv4 resources resulting from a > partial or complete merger, acquisition, reorganization or relocation. > > In the case of inter-RIR, the counterpart RIR need to have a reciprocal > policy/procedure that allows it. > > > 11.0. Transfer of IPv6 resources > APNIC will recognize the transfer or IPv6 resources resulting from a > partial or complete merger, acquisition, reorganization or relocation. > > In the case of inter-RIR, the counterpart RIR need to have a reciprocal > policy/procedure that allows it. > > > 13.3. Mergers, acquisitions and relocations > APNIC will recognize the transfer of ASNs resulting from a partial or > complete merger, acquisition, reorganization or relocation. > > In the case of inter-RIR, the counterpart RIR need to have a reciprocal > policy/procedure that allows it. > > > 5. Advantages / Disadvantages > ----------------------------- > Advantages: > Fulfilling the objectives above indicated and ensuring clarity on what > is allowed and what not. > > The proposal makes clear that this may only happen, in case of > Inter-RIR > cases, when both RIRs have a reciprocal policy. > > Minimizing possible legal issues. > > > Disadvantages: > It could be considered that it can create further disaggregation, > especially in IPv6, however, those cases are rare and only happening > from time to time, so the impact is negligible, and justified by the > documentation provided when the transfer is requested. > > In the Inter-RIR cases, coordination with the counter-part RIR is > needed, but this is already an ongoing activity because all the regions > (with the exception of AFRINIC), already have those mechanisms in place > (for both, administrative and technical aspects). > > > 6. Impact on resource holders > ------------------------------ > None. > > > 7. References > -------------- > RIPE NCC: > https://www.ripe.net/publications/docs/ripe-682 > > ARIN: > https://www.arin.net/policy/nrpm.html#eight2 > > LACNIC: > > https://politicas.lacnic.net/politicas/detail/id/LAC-2019-4/language/en > > https://politicas.lacnic.net/politicas/detail/id/LAC-2019-3/language/en > > https://politicas.lacnic.net/politicas/detail/id/LAC-2019-2/language/en > _______________________________________________ > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
