Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Sylvain BAYA abscoco at
Fri Jun 21 21:05:09 UTC 2019

Hi all,

Le vendredi 21 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at
<mailto:rpd at>> a écrit :

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

:-D ...please don't expose me too much Jordi ;-)
I'm just trying to do my best...i'm not any kind of expert :'-(

     See below, in-line.








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


    Hi all,

    Please see, inline, below...

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

        Hi Sylvain,


        Sorry the email was sent before I finished it …


        Responding below, in-line.








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


        Hi all,

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



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

Go ahead on this way ! i declare my support for such an approach,
because i'm personaly sharing a similar approach.

Hopefully other participants will also share it.

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


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

        “The Inter-RIR transfers will only be enabled once AFRINIC enter
        into Exhaustion Phase 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 … 

...quite difficult for sure :-)

It's simply confirming us that to reach the *goal* of this (and other)
policy proposal, we need to think deeply on details. Other meaning : we
need more active volunteers|participants engaged with sincere contributions.

    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. 

Thanks for these clarifications.

    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. my knowledge, to better text this situation (and reach the *goal*)
we must considere that the transfer is started when the parties have
sent a request to the staff. 

What we can also do is to add a new section with advices for those who
will need to start a inter RIR transfer procedure. On that section, we
shall explain why they must not take more than one (?), two or three
months to complete the pre-process (b2b negociations). They shall know
and understand the risk to come too late to the staff to request a
transfer ; because the negociation phase took too much time... :-/

    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.

Ok, we need a clarification from the staff. But before that, i propose
something below to address the problem...

    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.

Ok you are right ! But let me try other possibility|solution i see : are
we still prioritising incoming transfers ? :-)
To be sure, i think we can include a similar (to the following) text
(about transfer procedure) : 

“Initiators of a transfer must start the procedure earlier by submitting
their request. The transfer procedure is concluded after a cycle of
$four months, devided in two periods of $two months for each. Initiators
submit their case to the staff and wait for the staff to give their
conclusion at least $two months after the "submissions period" and not
more than $four months (including the "verification period"). The staff
will collect the cases (submissions|requests) during the "submissions
period". The staff can start to study the cases immediately, after
receiving them, until the end of the "verification period" which is
coinciding with the next "submission period"; while collecting other
cases. Those in line with the CPM (policy compliant) at the end of the
correspondent "verification period". The staff should focus to the goal
: keep the in/out balance exceding. Incoming transfer submissions shall
be prioritised and treated separately.”

With this bit of text, i'm trying to solve a problem you raised above.

It does, at least, the following : 
* To change the approach in considering that 
* We can considerably diminish the risk by allowing the staff to study
the transfer submissions (cases) during the same dedicated
"verifications period" (even just during $one month if possible) and
* Inform all the requestors only after the "verifications period"
* With the *goal* balance in mind :-)
* Special treathment for incoming transfers ;-)
* A cycle of four months within two equal periods for submissions and
* More control of the balance 
* Focus : *goal* balance
* ...

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

I agree, but just a *bit of risk* :-)

I wasn't able to follow your first presentation during the PPM (Public
Policy Meeting), just the Hijacking one. Please share the slides of all
your policy proposal presentations.

    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.

 Ok it walk samely for incoming and outgoing transfers. Considering that
we have a seller and a buyer on both side transfers.

    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? what i recall [1] they still have too much unused IPv4 addresses.

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

...i'm ok with that, but let's try to find the lowest risk :-)

        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.

  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.

Can someone share an uri ?
I think we must insert this requirement to the relevant section of the
CPM, if not existent.

    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.

You are welcome ! Thanks :-)

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

Yes, transparency and more power to the community ;-)

        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

        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


        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


    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:


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

Possible solution, thanks for the effort you produced above. But there
is still more than acceptable risk on it (including point 4) ; because
the next new transfer request can come after the *few* days of suspension.

Please look how to also consider the alternative solution i have
proposed above. I don't need you to keep that text as it is, but to use
it to figure how it could be merged with yours and reduce the risk (no
suspension with it).
[1]: MIT and their 8 million IPv4 addresses –


    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?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x0387408365AC8594.asc
Type: application/pgp-keys
Size: 4826 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the RPD mailing list