[rpd] inputs on IPv4 Inter-RIR policy proposals - AFRINIC needs this policy now!

Thu Jun 20 23:30:16 UTC 2019

Hi Sylvain,

I want to thank you, I guess we won a “strong” contributor to policy discussions! (I recall your name from previous discussions, but you’re now more active, which is what I wish from every one).

See below, in-line.

Saludos,

Jordi

@jordipalet

El 20/6/19 22:37, "Sylvain BAYA" <abscoco at gmail.com> escribió:

Hi all, 

Please see, inline, below...

Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> a écrit :

Hi Sylvain,

Sorry the email was sent before I finished it …

Responding below, in-line.

Regards,

Jordi

@jordipalet

El 20/6/19 15:05, "Sylvain BAYA" <abscoco at gmail.com> escribió:

Hi all,

Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> a écrit :

As said, this text is redundant (see specific text below my signature), but I don't mind to have explicit text if this facilitate the community to reach consensus.

Here is my proposal, again, please comment about this ASAP, so we can submit a new version already, instead of waiting to be closer to the next meeting. This way we can ensure that we get on time the staff impact analysis, in case something else need to be amended.

"The Inter-RIR transfers will be automatically suspended in case the balance between IPv4 out-going and in-coming addresses becomes cero." 

Jordi,

...typos on “zero” ?

Yeah … my spelling checker often confuses English and Spanish!

Anyway, here is a better version, because this balance is actually “cero” at the start of the implementation, so the text may be misleading, we need to define . 

Alright !

I like the new visage of this policy proposal because i really appreciate the way you are leading the discussions around it. 

Believe me, that I always try to heard everybody position and accommodate as much as possible, my own thinking/knowledge and the text to that (or convincing other if I believe they have a wrong vision). This is the way to reach consensus.

While contributing to this thread, what i want is to be sure that this policy proposal could be really beneficial to AFRINIC region|community.

Same as me, again, the right thing to do.

“The Inter-RIR transfers will only be enabled once AFRINIC enter into Exhaustion Phase 2 (5.4.3.2). The Inter-RIR transfers will be automatically suspended in case the number of out-going IPv4 addresses exceeds the in-coming ones by six consecutive months.”

This version is a good starting point. Thanks.

I understand it like this :

* This Policy Validity Starting Point : Exhaustion Phase 2

* Initial point : balance of zero (nothing in|out)

* First auto-stop point : when the in/out balance becomes down

..* After 06 consecutive months {seems to be not interesting for me}

..* Even 02 consecutive months is not really interesting, because we miss an #x amount (or %) of resource (IPv4) limit to not reach at any time (without any mention of #y consecutive months) to reduce an unwilling risk. 

This policy shall be able, maybe, to stop a transaction (in course) which could conduct us out of a specific low acceptable in/out balance. So think about it again please.

This is not possible, I believe, unless someone discovers a “magic way to write it down” (which I can’t see now). Anyway, I’m still trying to think something before ending this email …

I’ve not personally been involved in transfers, but I understand the process and transfers don’t happen “in the second”. There are documents to review, justification to be reviewed by the two RIRs, contracts to be signed, payments to be done (via an escrow), etc. It is a matter of several days or weeks.

It may happen that in the middle of a month, several “negotiations” for transfers are running, and some of them in one or the other direction may reach or not in time for the end of that month. That’s why I’m suggesting a number of months.

If the staff tries to evaluate the transfers at a single point in time, it may be misleading as some operations in the opposite direction may be being processed. The RIRs may have an “alert” of a possible transfer, depending on the direction, I don’t know if the exiting coordination systems allow them to check those (this will sort out the problem), but still will not be precise, as some other folks may be “negotiating” a transfer and have not yet informed the relevant RIRs until the parties agree.

If we stop the policy immediately the balance becomes “bad” for AFRINIC, then a transfer in the other direction will not be able to happen. You see the point.

We need to “take a bit of risk”, considering that the real risk, looking at the numbers I’ve presented is really low.

Remember that “nobody” from AFRINIC is forced to sell. Who will sell? Those that for example, reduce or close the business, or those that deploy IPv6, etc.

Who will buy? Those that go to AFRINIC, ask for more, can’t get all what they need, and try to get the rest of their needs via transfers.

What is the logic here? Why ARIN is the major donator to all the other RIRs?

If we don’t take a risk, we lose.

This means that if one month there are “more addresses going out”, it happens again the next month, and it happens again by a third month and so on, then is suspended.

...so monthly public reports should be needed (for the community to follow-up and for more transparency) ?

If yes, let's clearly state|text it also.

I believe there is already a public AFRINIC reporting of the Inter-RIR transfers, so we will see this reported ASAP any transfer is completed I think.

If this is not the case (can please the staff confirm?), I fully agree (for both Inter and Intra-RIR) and will add a specific text so they are reported, not just monthly, but with each completed transfer.

Which this web page, any member, the board, etc., can tell the staff at any point, if they don’t realize by themselves, “hey what is going on here? Are we good with the transfers?”.

I’ve also added a condition to make sure that this policy only starts once we are in the next exhaustion phase.

So, you shall consider that, if AFRINIC service|community doesn't gain anything in the balance this policy should not be needed...

And that should be clearly stated.

I agree with that, but I don’t think we need to put that in the policy text, this should be in the text of the policy justification.

...wasn't the point here. Apologize but English is not my first tongue. 

What i was (trying) advising|suggesting is to ensure to text it the clearest possible ; in order to remove any ambiguity. 

I'm glad that you have seen, by yourself, that there was a problem with the first zero state.

Got it, thanks! And nothing to excuse!

Note that in order to make it simpler, I've used a text that instead of talking about %, is stating that the balance of in/out is reached. This way we ensure that the total number of the "region IPv4 addresses" never can go down regarding the actual figures, so Africa never will lose addresses. Do you think this is good enough?

Ok after policing this, it seems to be necessary to clearly state, *“policily”*, that the staff must follow-up (automatically) the in/out balance, with regular (automated) public reports and a special (auto) stop report (for the zero state).

I'm not sure how to "policy-ze" this idea. Perhaps with a separate policy ?

I’m not completely sure to understand 100% what you mean, but let me try anyway: Staff is mandated to follow the policies. So, during the implementation the staff will make the necessary provisions so they get an alarm when the balance of in-coming vs out-going addresses becomes cero. It may be done automatically anyway, but at least they should get an “alarm”. The operational details about “how” to implement this are outside of the policy scope.

Ok i am in accord with the logic of separation between policy rules and their operational implementations. I don't want us to “policy-ze” the implementation phase of any policy :-)

But you probably miss something in my above suggestion. 

The point is that, if you don't clearly ask, via a policy, for a regular (public) report (for example) from the staff, you could not be sure to get it when it shall be needed. Because, without a specific policy provision, it will be just out of their duties...

Let’s try it again, based on all the discussion (the numbers are just to split the text now, they will be correctly placed in the relevant part of the policy proposal when we “reach consensus” about this text:

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.
The Inter-RIR transfers will only be enabled once AFRINIC enter into Exhaustion Phase 2 (5.4.3.2).
The Inter-RIR transfers will be automatically suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones by six consecutive months.
The staff can provisionally suspend any suspicious operation that creates a big unbalance against AFRINIC, until the board takes a decision.
See point 4. If there is any suspicious unbalance, the suspension temporary suspension of *that* operation protects our pool of addresses, for a few days (I guess the board in that case should call for a decision by email or by conference call), and meanwhile, it can be observed if other “incoming” operations will restore the balance.

I really believe this is not needed, it can be done applying the bylaws (very recently ARIN board suspended in emergency a policy, so it is a good demonstration that this works even if is not in the policy) but I’m happy to keep this text if this means that we are more unconcerned this way.

What do you think?

Thanks!

Hope this clarifies.

Friendly,

--sb.

Friendly,

--sb.

[...]  

-- 

Regards,
Sylvain B.
<http://www.chretiennement.org> 
__
Website : <https://www.cmnog.cm>
Wiki : <https://www.cmnog.cm/dokuwiki>
Surveys : <https://survey.cmnog.cm>
Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Last Event's Feed : <https://twitter.com/hashtag/cmNOGlab3>
<https://twitter.com/cmN0G>
<https://facebook.com/cmNOG>
<https://twitter.com/hashtag/REBOOTcmNOG>
<https://twitter.com/hashtag/cmNOG>
<https://cmnog.wordpress.com/>
_______________________________________________ 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/20190621/7c756eea/attachment-0001.html>