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

Fri Jun 28 13:01:08 UTC 2019

On Fri, Jun 28, 2019 at 11:29 AM Andrew Alston <
Andrew.Alston at liquidtelecom.com> wrote:

> You’re asking for the impossible – because to get that you’d need to go to
> all the brokers (I assume)
>

So, we jump into the dark, with no parachute (data would have helped
somehow), all eyes closed? Keeping them open in these circumstances won't
help anyway.

Boubakar

>
> *From:* Noah <noah at neo.co.tz>
> *Sent:* Friday, 28 June 2019 14:17
> *To:* JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
> *Cc:* RPD <rpd at afrinic.net>
> *Subject:* Re: [rpd] inputs on IPv4 Inter-RIR policy proposals - AFRINIC
> needs this policy now!
>
>
>
> So Jordi,
>
> I still oppose this policy with strongest terms possible. I still believe
> IPv4 space will leave our region so fast when holders of Idle space who are
> yet to put them to good use as was allocated/assigned will trade them for
> some dollars rather than return them to AfriNIC. What we need is a policy
> that would discourage IPv4 from being transferred out of the region because
> of attractive prices of IPv$ but rather encourage more space coming into
> the region.
>
> We already have a transfer policy that can facilitate internal transfers
> withing our region and I am keen of getting a report from AfriNIC on how
> this is going.
>
> @Jordi, please also share some statistical numbers of available IPv4 space
> that would actually come into our region so that we can work with figures
> rather than assumptions.
>
> Noah
>
>
>
>
>
> On Sun, Jun 23, 2019 at 7:01 PM JORDI PALET MARTINEZ via RPD <
> rpd at afrinic.net> wrote:
>
> Hi again Sylvain,
>
>
>
> I’m very thankful for your inputs!
>
>
>
> We need to make sure that others also participate!
>
>
>
> See below in-line.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 21/6/19 23:15, "Sylvain BAYA" <abscoco at gmail.com> escribió:
>
>
>
> Hi all,
>
> Le vendredi 21 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>
> 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 :'-(
>
>
>
> Now I realized that you were not on-site, pity!
>
>
>
>  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.
>
>
>
> 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 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 …
>
>
>
> ...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.
>
>
>
> **EXACTLY!** Meetings time is precious and we aren’t allowed to modify
> the text of the proposals on-site, we need inputs way ahead!
>
> 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.
>
>
>
> ...to 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... :-/
>
>
>
> I don’t think this is possible. Transfers have a lot of “business talks”
> among the parties. Only once the parties have reached an agreement, they
> need to go into the process. You could do on the other way around, it can
> be a mix of both. I don’t think the community must provide a rule on that,
> because this has not been done in other RIRs. If we try to setup our own
> rule, then our policy will have mismatches with the other policies and then
> we may be in the situation that they are not reciprocal, or the existing
> procedures in the other regions need to be re-worked, why they are going to
> do it, now that we are the last one?.
>
> 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.”
>
>
>
> I don’t think this will work, as I just explained a few reasons above. In
> principle I will not support this.
>
>
>
> 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
> verifications
>
> * More control of the balance
>
> * Focus : *goal* balance
>
> * ...
>
>
>
> See below … it is not needed. I think, just you misunderstood my point 4.
>
>
>
> 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.
>
>
>
> And now I realize this is part of the problem for your questions. Please,
> pause this discussion until you’re able to see the video of my presentation
> and the slides! I guess then you may change a bit your view about the risk,
> etc.
>
>
>
> I already asked the staff (previous email) to make sure they are published
> tomorrow. I think they deserve the break today :-)
>
>
>
> 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?
>
>
>
> ...to 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.
>
>
>
> ...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.
>
>
>
> 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 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:
>
>
>
> 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).
>
> 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 balance.
>
>
>
> 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.
>
>
>
> The point here is that the staff is still able to suspend any suspicious
> operation. Not just one. Is not that clear my text? (any)
>
>
>
> 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 –
> https://www.techspot.com/news/69055-mit-unload-8-million-ipv4-addresses-fund-ipv6.html
>
>
>
> Friendly,
>
> --sb.
>
>
>
> 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!
>
> [...]
>
>
>
> _______________________________________________ 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.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190628/2d3be8f8/attachment-0001.html>