[rpd] inputs on IPv4 Inter-RIR policy proposals

[Sylvain BAYA]

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 :-)
 

>

> 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 ;-)
 

>

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

>

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

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

>

> 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


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 3^rd 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190715/af73b879/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x0387408365AC8594.asc
Type: application/pgp-keys
Size: 4826 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190715/af73b879/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190715/af73b879/attachment-0001.sig>