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