Search RPD Archives
[rpd] inputs on IPv4 Inter-RIR policy proposals - AFRINIC needs this policy now!
Sylvain BAYA
abscoco at gmail.com
Fri Jun 21 21:05:09 UTC 2019
Hi all,
Le vendredi 21 juin 2019, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net
<mailto: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 :'-(
See below, in-line.
Saludos,
Jordi
@jordipalet
El 20/6/19 22:37, "Sylvain BAYA" <abscoco at gmail.com
<mailto: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
<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.
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.
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... :-/
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
verifications
* 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?
...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.
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!
[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190621/4b6af79c/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/20190621/4b6af79c/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/20190621/4b6af79c/attachment-0001.sig>
More information about the RPD
mailing list