[rpd] [Community-Discuss] Call for AFRINIC’s registry service migration to other RIRs

[Owen DeLong]

> On Aug 1, 2021, at 14:57 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:

> 

> Hi Noah,

>  

> Your interpretation on this is wrong.

>  

> Read my detailed email a few days ago.

>  

> 11.4 Allows the Board to define any policy regarding Internet Resources that they believe is urgently needed.

>  

> This can be implemented ASAP the Board decides. The Board MUST also send the policy (11.5), as a policy proposal (because is the only way the PDWG works to reach consensus), to the PDWG for endorsement in the next meeting. If the PPM doesn’t endorse it, then the Policy will decay, but whatever happened meanwhile, will be “legal” in terms of the PDP.

>  

> Now the question here is:

>  

> From past experience in the other RIRs, implementing such Inter-RIR policy, takes a minimum of 6 months, probably even more (it took 12 months in other RIRs), because there is a need to coordinate all the RIR systems. AFRINIC can’t “force” other RIRs to change their own agendas and workflows to address all the changes “faster”. AFRINIC could be lucky and because all the other 4 RIRs already passed by this several times, may be the process is so much “adjusted” and fine tunned that it may be faster.


This won’t actually be the case. AFRINC would be the remaining bottleneck here. Once the first two RIRs (ARIN and APNIC IIRC) had a compatible inter-RIR policy, it took almost no time on the ARIN side for RIPE to be added to the mix. There was some time taken for RIPE to become ready for both APNIC and ARIN. Similarly, once LACNIC finally adopted such policy, the delays were all (to the best of my knowledge) on the LACNIC side of the equation. APNIC, RIPE, and ARIN were essentially already prepared to process such transfers with LACNIC by virtue of having the systems fully ironed out amongst themselves. IIRC, LACNIC was also able to come on line relatively quickly because the other three were able to help them through the process with lessons learned and experiences gained from their own processes.


> I already suggested many times the Board to do that, when I saw that the consensus was not achievable. They ignored that. So I don’t think they want to pass this now, more when there are several proposals in discussion and could be discussed in a PPM in a couple of months from now, the AC reconstituted, and the appeals resolved, etc.


I suspect you may well be correct here about what the board wants, but in either case, the fiduciary environment in which they operate at the moment may well be different from when you suggested same. Their desire or lack thereof may be subject to different considerations today.


> The Board can meanwhile, take measures so the implementation of a possible “system” for an Inter-RIR proposal is advanced, in hope that one way or the other a proposal reach consensus.


Actually, I’m not sure this is an action that the board can take… Such action would be a purely operational matter taken on by staff. I suppose the board could direct the CEO to direct staff, but this gets into a level of operational micromanagement that is not normally considered appropriate for a board. OTOH, I absolutely agree that Eddy should recognize that such a policy is eventually going to become inevitable in one form or another and that responsible preparation in order to be able to expedite implementation once that becomes reality is not a bad idea.


> All that said, I expect that if the Board decides to draft that proposal/policy, they make sure that there is a clear statement that ensures that before any transfer, there is a confirmation of the resources being transferred are following the existing conditions in the RSA, CPM, etc., otherwise.


Because such a requirement wouldn’t enable abuse of process in any way, right?

Sure. It’s not like AFRINIC has abused review processes before, right?

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210803/6cb08b16/attachment.html>