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

Thu Jun 20 19:30:54 UTC 2019

Hi all,
Please see, inline, below...

Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net
<mailto: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
    <mailto:abscoco at gmail.com>> escribió:

    Hi all,

    Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net
    <mailto: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. 

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

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

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190620/4eb94bf0/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/20190620/4eb94bf0/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/20190620/4eb94bf0/attachment-0001.sig>