[rpd] inputs on IPv4 Inter-RIR policy proposals

[JORDI PALET MARTINEZ]

Hi Sylvain,

 

El 15/7/19 5:37, "Sylvain BAYA" <abscoco at gmail.com> escribió:

 

Hi all, 

Hope you are in good health.

Please see below (inline)...

Le 7/13/2019 à 12:11 PM, JORDI PALET MARTINEZ via RPD a écrit :

[...]

(please see my presentation slides, video, etc., https://www.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2019-v4-001-002.pdf, https://www.internetsummit.africa/en/agenda/video-day-3)

 

Thanks Jordi.

 

I’m just considering ARIN here because is the bigger donor of addresses (right now) to other regions, but of course, you can make the same rational when the other regions keep increasing the IPv6 deployment level.

 

If AFRINIC “enters” in the inter-RIR transfers “system” that we have now in the other 4 regions, this is the outcome, IF and ONLY IF, we have a reciprocal policy (at least for some regions, and specially ARIN):

1)      AFRINIC will be able to get addresses from ARIN and other regions.

2)      When the other regions increase their level of IPv6 deployment, they will become “natural” donors from many of the addresses that they got from ARIN. Of course, the speed of this will be different from region to region.

3)      At the end of the history, when AFRINIC has a very good IPv6 deployment penetration, the need for IPv4 addresses and the “value”, will start decreasing.

 

Nobody has the crystal ball, that’s clear, but historical data reflects reality and trends.

 

Why this is going to be different if AFRINIC comes into the “inter-RIR” system?

 

...uncertainty ?

 

Now, all that said, I fully understand the “fear to the unknown” and that the community want to have some kind of protection, in the very strange case, that this time, the trends change suddenly what the historical data tells up to now.

 

This is why my proposal is:

1)      Amend the policy proposal with the point raised by the staff, which hopefully I can see in the impact analysis soon.

2)      Amend the policy proposal with other comments received during the presentation and the list discussion.

3)      Include as a “security belt” the measures that we discussed in the list discussion:

1.       Each time a transfer is completed, the relevant, non-confidential information will be automatically published in a specific web page, including at least: Date of the transfer, transferred addresses, source organization and RIR, destination organization and RIR.

2.       The Inter-RIR transfers will only be enabled once AFRINIC enter into Exhaustion Phase 2 (5.4.3.2).

 

 ...still ok with 1. & 2.

 

3.       The Inter-RIR transfers will be automatically suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones by six consecutive months.

 

...no need to suspend the entire policy, and no need to count the months :-)

 

I agree that there is no need to suspend the policy, and that can be done thru the board (with actual bylaws), but this is a way to have a security belt and provide clarity for the community to agree on this.

 

Regarding the months, I disagree. We can’t measure just one month or the next one, because deals can take months to happen and what it may look as outbound one month, is actually inbound in a period of time. I’ve already explained this before.

 

4.       The staff can provisionally suspend any suspicious operation that creates a big unbalance against AFRINIC, until the board takes a decision.

 

...no need for any BoD intervention here, in fact i see it otherwise, please see below ;-)

 

As said, even if we don’t say that in the policy, it is in our bylaws. I prefer to make it explicit so to provide clarity.

 

This provides: transparency to the transfers, timeline to start, an automatic check month to month and “insurance of risk” at month 6 after implementation and then every next month, a further check of any suspicious operation that can be suspended by the staff so the board can decide about it or tell the community “this or that is happening, should we do something, should we definitively cancel the policy, etc.”.

 

...again, i prefer no BoD interventions.

 

You can’t avoid it, unless you change the bylaws. Having the text or not in the policy doesn’t make a difference, but having it provides clarity.

 

If somebody thinks this is not enough, please, explain why and propose 

 

To bypass the BoD intervention (4.), i propose an amendment which consists of a provision to automatically *switch* to a *minimal state of this policy*, where only incoming inter-RIR IPv4 transfers are allowed until the in/out balance pass zero 
(exceeding by incoming transfers).

 

I don’t agree on this, because this will mean the policy turns into something which is not reciprocal with ARIN, which means is useless. Having a non-reciprocal policy means that we can’t anymore receive resources form them. If we believe the policy is doing any harm, just halt it until we take a new decision. Simple and easier.

 

...of course, the same switching approach is sufficient to remove the need to stop/suspend the whole policy (3.) in case of *panic*. 

 

This *switching approach* could do more as expected :-)

...so think of a possibility to also switch, in some cases (TBD—ToBeDefine), to the innovative alternative proposed by Souad.

 

If another proposal reach consensus, then that proposal may indicate that this one is suspended, or whatever. So no need for that.

 

an alternative solution.

 

Alternatively, the above amendment should bring more light to my previous proposition 
and approach. Let me paste its requirements here again : 

 

* This is an alternative approach 
* With it we can considerably diminish the risk of a deficitary in/out balance
* By difining a dedicated period to collect the inter-RIR transfer submissions (cases)
* By difining a dedicated period to study the inter-RIR transfer submitted
* These periods put together constitute a full cycle of inter-RIR transfer
* A cycle ends by the publication (at the same time), by the Staff, of the results|decisions 
of the cases studied during that cycle
* Cycles are continued
* Durations (cycle, submission period, study period) : TBD (To Be Define)
* Special treathment for incoming transfers ;-)
* More control on the in/out balance
* Focus : *goal* balance

I think this is creating unnecessary complexity, and adding complexity means it is much more difficult to reach consensus. The simple way is to have an reciprocal policy, and explicitly state that it can be suspended (not because it can’t be done without that text, but because that will provide clarity to the community, which may be reading this discussion and not reading at the same time the bylaws, service agreement, etc.).

 

Shalom,

--sb.

 

 

Regards,

Jordi

@jordipalet

 [...] 

------ Original message------

From: SOUAD ABIDI

Date: Fri, Jul 12, 2019 6:50 AM

To: AfriNIC List;

Cc: 

Subject:[rpd] inputs on IPv4 Inter-RIR policy proposals

 

Hello, 

 

As IPv4 are finite and if we do the transfer, our resources may run out from our region-since there is no a explicit control motioned in the policy - As some people argue.

Here what I suggest : 

 

??         Establishing a leasing contract between the seller and the buyer up to 5  years with a possibility to renew it and AfriNIC  will be the 3rd part of the          deal .

??         AfriNIC takes no money  and  makes no  approval.  

??         The buyer needs to be registered somehow in the world.

??         The contract needs to be signed by the 3 parts (afriNIC-seller-buyer)

So buy adopting  this approach and  if we notice that our resources are running out from our region, we can decide to bring them back and the companies do not renew the contract with .  

 

Best regards.

Souad

[...]
-- 
 
Regards,
Sylvain B.
<http://www.chretiennement.org> 
__
Website : <https://www.cmnog.cm>
Wiki : <https://www.cmnog.cm/dokuwiki>
_______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 



**********************************************
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190715/2a6863c9/attachment-0001.html>