<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">There are three attachments. The ZIP file contains what purports to be an XLS, but appears to be malware.<div class=""><br class=""></div><div class="">The two other attachments are harmless plain text, though the smaller one is just an email signature.</div><div class=""><br class=""></div><div class="">So I confirm Patrick’s report that the message content appears to be malicious.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2021, at 1:36 AM, Patrick Okui <<a href="mailto:pokui@psg.com" class="">pokui@psg.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">[Diren removed from cc but will likely get it from the list]</p><p dir="auto" class="">Please <strong class="">URGENTLY</strong> note that this is SPAM, possibly virus infected and hopefully no one will click any of the attachments in the various emails from Diren@.</p><p dir="auto" class="">Thanks.</p><p dir="auto" class="">On 2 Mar 2021, at 12:21 EAT, <a href="mailto:paulos@sdnp.org.mw" class="">paulos@sdnp.org.mw</a> wrote:</p>
</div>
<div style="white-space:normal" class=""><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px" class=""><p dir="auto" class="">Diren,<br class="">
<br class="">
Please note that the Appeal Committee has been gagged by the Afrinic Board Chair and<br class="">
hence is currently unable to handle such requests.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Paulos<br class="">
========================<br class="">
Dr Paulos Nyirenda<br class="">
<br class="">
------- Forwarded message follows -------<br class="">
Date sent: Mon, 01 Mar 2021 15:13:39 +0100<br class="">
From: <a href="mailto:diren@vanilla.co.za" class="">diren@vanilla.co.za</a><br class="">
To: <a href="mailto:pdwg-appeal@afrinic.net" class="">pdwg-appeal@afrinic.net</a><br class="">
Subject: Re: [PDWG-Appeal] [rpd] REPORT ON Appeal against the non-consensus<br class="">
determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br class="">
Unallocated and Unassigned AFRINIC Address Space<br class="">
<br class="">
<br class="">
Good day! As you asked, I´ve collected to you several necessary<br class="">
docs and<br class="">
attached them to the email. If you really will want to find some info,<br class="">
you know, whom to ask.<br class="">
<br class="">
<br class="">
On 2021-02-07 20:48, wrote:</p>
<blockquote style="border-left:2px solid #5855D5; color:#00AFCC; margin:0 0 5px; padding-left:5px; border-left-color:#00AFCC" class=""><p dir="auto" class="">Could the Appeal Committee respond to this, and reconsider the work<br class="">
they are doing, as I just explained in my previous email, taking the<br class="">
inputs of the Recall Committee?<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 26/1/21 12:14, "JORDI PALET MARTINEZ via RPD" <<a href="mailto:rpd@afrinic.net" class="">rpd@afrinic.net</a>><br class="">
escribi:<br class="">
<br class="">
In case the Appeal Committee is not subscribed to the RPD list.<br class="">
<br class="">
Waiting for your response.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 26/1/21 11:50, "JORDI PALET MARTINEZ"<br class="">
<<a href="mailto:jordi.palet@consulintel.es" class="">jordi.palet@consulintel.es</a>> escribi:<br class="">
<br class="">
Hi Wafa, all,<br class="">
<br class="">
First of all, dont take anything that I say personally, but in<br class="">
general I see a total failure of the Appeal Committee and lack of<br class="">
compliance with the PDP.<br class="">
<br class="">
Your judgment must be on the grounds of a correct decision of the<br class="">
chairs.<br class="">
<br class="">
In taking such decision the Appeal Committee must be based on facts,<br class="">
never on personal opinions (from the community or the chairs or the<br class="">
Appeal Committee itself). Being based on objective facts means<br class="">
checking if what the policy proposal said, what were the objections,<br class="">
and if those objections *are real*, not just illusions or lack of<br class="">
knowledge or untrue or personal preferences.<br class="">
<br class="">
If the Appeal Committee doesnt have the right knowledge, as I<br class="">
already said I believe was the reason the chairs took the wrong<br class="">
decision, then they should ask for help to the staff or third<br class="">
parties.<br class="">
<br class="">
Any objection to a policy proposal must be duly justified and that<br class="">
justification not addressed by the authors or other community<br class="">
members.<br class="">
<br class="">
Any policy proposal that has objections, the objections MUST BE<br class="">
VALID, even if the objections come from 99% of the community. This<br class="">
is not democracy, is not number of votes or voices, is based on<br class="">
non-addressed objections. It is not based on untrue objections. None<br class="">
of the objections to this policy proposal were valid. They are<br class="">
mostly based on lack of sufficient knowledge, and never lack of<br class="">
knowledge can be a VALID reason. Again, not only the authors, but<br class="">
many other expert community members have confirmed that those<br class="">
objections are invalid.<br class="">
<br class="">
A policy proposal never can be based in I dont like it. You need<br class="">
to state I dont like it because it breaks this RFC (for example).<br class="">
And even in that cases authors can respond showing why the<br class="">
perception of breaking this RFC is wrong (so addressing the<br class="">
objection will nullify it). Policies are not based on personal<br class="">
preferences, but in what is the best *technically correct choice*<br class="">
for the community.<br class="">
<br class="">
Last but not least, the Appeal Committee seems to be working as a<br class="">
democratic body, which is wrong. ALL THE PDP is based in consensus<br class="">
approach. The Appeal Committee must also follow that approach,<br class="">
otherwise, it is breaking the ICP-2, which is the higher mandate of<br class="">
how the policy making process works. If 3 members of the Appeal<br class="">
Committee believe that the opposition was correct, they should<br class="">
*demonstrate with facts why* and this must be done using the<br class="">
responses provided by the authors and community to those objections.<br class="">
<br class="">
If 3 members of the Appeal Committee believe that any of the<br class="">
objections has not been addressed, they need to *demonstrate why*,<br class="">
taking in consideration the community and author responses, and<br class="">
those must be crystal clear in the report, which is not the case.<br class="">
<br class="">
The Appeal Committee must respond to the authors, in a consensus<br class="">
based approach, not a democratic one to all what the authors<br class="">
confirmed in the Appeal Document.<br class="">
<br class="">
Note also that there is a paragraph in the Appeal Report that<br class="">
completely kills the PDP and demonstrates that the Appeal Committee<br class="">
HAS NOT UNDERSTOOD THEIR JOB AT ALL:<br class="">
<br class="">
The 3 members who observed significant opposition to the policy,<br class="">
however, also observed that it is the PDWG that builds consensus and<br class="">
decides whether issues of opposition are addressed to the<br class="">
satisfaction of the PDWG which is where the PDP requires that<br class="">
consensus is assessed by the Co-Chairs.<br class="">
<br class="">
The PDP states clearly that the Appeal Committee need to review the<br class="">
chairs decision. If the chairs have considered as VALID objections<br class="">
that OBJECTIVELY ARE INVALID, it is clear that the Appeal Committee<br class="">
must declare the lack of consensus declaration is invalid, and<br class="">
consequently, the proposal reached consensus.<br class="">
<br class="">
Lets go the details and I ask the Appeal Committee to respond to<br class="">
each of the objections included and refuted in the Appeal Document:<br class="">
<br class="">
2.1. a. Allowing resource holders to create AS0/ ROA will lead to<br class="">
an increase of even more invalid prefixes in the routing table<br class="">
<br class="">
Following RFC6483, section 4 (A ROA with a subject of AS 0 (AS 0<br class="">
ROA) is an attestation by the holder of a prefix that the prefix<br class="">
described in the ROA, and any more specific prefix, should not be<br class="">
used in a routing context) resource holders, as part of the RPKI<br class="">
system already can and actually do this (example IXPs), in fact they<br class="">
do. This has been explained several times, including my presentation<br class="">
at the PPM. The proposal is just adding light about actual facts<br class="">
regarding this aspect, not changing anything, so it cant be a valid<br class="">
objection for the policy proposal.<br class="">
<br class="">
2.2. b. Revocation time of AS0 state, and the time for new<br class="">
allocation doesnt match<br class="">
<br class="">
This is not true, again a misunderstanding about how RPKI works. The<br class="">
authors and other several community experts have discussed this in<br class="">
the list. If you get number resources from AFRINIC, normally you<br class="">
dont announce them in minutes, or hours, or even days. There is<br class="">
some work to do in your network, you need to do changes in systems<br class="">
and routers, and this takes hours, and normally you cant touch<br class="">
systems during the day, but only in maintenance windows in the<br class="">
night. That means that if AFRINIC revokes an AS0 certificate, it<br class="">
will be done in a few minutes during the day. So even if the<br class="">
worldwide caches take hours to see that, there is no negative<br class="">
impact.<br class="">
<br class="">
In addition to that, this it can be improved thru implementation, as<br class="">
I already explained also in the list. The staff could tentatively<br class="">
release from the AS0 the resources that they plan to allocate once a<br class="">
week or every couple of days, etc. For example, when they are<br class="">
processing a request, and they are pending on final documentation,<br class="">
the RSA signature for new members, or the review with the member of<br class="">
the justified need. Many other examples can be provided about how to<br class="">
do it. The proposal doesnt go into any of those details, because<br class="">
the understanding is that those are too depth operational, and in<br class="">
fact the staff could decide an approach during the implementation,<br class="">
and based on experience improve it afterwards.<br class="">
<br class="">
The conclusion is that there is no such matching, neither<br class="">
unmatching, so this cant be taken as a valid objection for the<br class="">
proposal.<br class="">
<br class="">
2.3. c. Other RIRs dont have a similar the policy therefore, it<br class="">
can not be effective<br class="">
<br class="">
All the policies have different discussions in different RIRs at<br class="">
different times. This policy is already available (reached consensus<br class="">
and implemented) in APNIC and LACNIC (reached consensus, being<br class="">
implemented). There is work being done in ARIN and RIPE (the first<br class="">
proposal was not accepted), not yet public. So, this is untrue if<br class="">
you look at all the RIRs.<br class="">
<br class="">
The effectivity of a policy is not only related to how many RIRs<br class="">
implement it. In this case, any RIR having this policy is actually<br class="">
stronger than the other RIRs not having it, in terms of routing<br class="">
security. It shows the commitment of that RIR about the RPKI usage<br class="">
with all its possibilities. It facilitates the operators in the<br class="">
region and outside the region to identify in a simpler and automated<br class="">
way, what prefixes should not be in the routing tables and<br class="">
consequently allow them in an opt-in basis, to discard them. So, it<br class="">
is in the other way around, any RIR with this policy could be said<br class="">
that it is more effective (even if it is not probably the right<br class="">
wording for this topic) that the others. We should rather say that<br class="">
a RIR with this policy is offering a more secure view of their<br class="">
routing information.<br class="">
<br class="">
In addition to that, there are policies in AFRINIC which arent<br class="">
available in other RIRs. That, clearly, doesnt make them invalid<br class="">
(or in other words, this is an invalid objection is good that all<br class="">
RIRs do the same, but is not always the case, or not at the same<br class="">
time), clearly this shows that this cant be taken as a valid<br class="">
objection against this policy proposal.<br class="">
<br class="">
2.4. d. This will become a uniform policy if it is not globally<br class="">
implemented, which causes additional stress<br class="">
<br class="">
This is almost a duplicate of the previous one. Absolutely not. We<br class="">
can add that the way we suggest the staff, and they confirmed, with<br class="">
an independent TAL protects, as intended by the proposal, the<br class="">
resources of the RIR implementing it, not creating any issues in<br class="">
what is done in other RIRs to any operator, so it cant be taken as<br class="">
a valid objection against this policy proposal.<br class="">
<br class="">
It is difficult to understand what it means additional stress in<br class="">
this context, but clearly, it will be in the other way around. As<br class="">
more RIRs implement it, less manual work in terms of filtering, is<br class="">
needed to be done by operators, if they opt to use the AS0 ROA<br class="">
service from the RIRs that have implemented it. So, it is not<br class="">
correct and thus, not a valid objection.<br class="">
<br class="">
If the question is about if this policy should be a Global Policy,<br class="">
the response has also been provided in the discussion. Ideally, a<br class="">
Global Policy will be only able to protect the IANA unallocated<br class="">
resources, but not the resources that IANA already allocated to each<br class="">
RIR. In fact, Im already working (when time permits it will be made<br class="">
public) in a Global Policy for that, but this is irrelevant versus<br class="">
having a policy at every RIR (or a few of them), so again,<br class="">
objectively not a valid objection.<br class="">
<br class="">
2.5. e. Validity period: if members decide to implement it, is<br class="">
it not better to recover the space if it is kept unused for too<br class="">
long?<br class="">
<br class="">
This doesnt make sense, at least not as worded. This is not about<br class="">
recovering space, no relation. It is the unused space hold by<br class="">
AFRINIC, regardless of if it was never allocated/assigned, returned<br class="">
by members, or recovered by AFRINIC. Once more, not a valid<br class="">
objection.<br class="">
<br class="">
2.6. f. How do we revoke the ROA? How long does it take to revoke<br class="">
it (chain/ refreshing )?<br class="">
<br class="">
This looks the same as 2.2 above. It doesnt matter in practice, if<br class="">
it takes minutes or hours or even days. Community and staff provided<br class="">
some facts about this, just to cite a couple of them:<br class="">
<br class="">
<a href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html" class="">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a> [1]<br class="">
<br class="">
<a href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html" class="">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a> [2]<br class="">
<br class="">
2.7. g. What happens if AFRINIC accidentally issues a ROA for an<br class="">
address in error?<br class="">
<br class="">
What happens if AFRINIC accidentally issues a ROA without an address<br class="">
already allocated to members?<br class="">
<br class="">
Exactly the same if the existing RPKI fails, and thats why there<br class="">
are monitoring systems in place and as reported by the staff impact<br class="">
analysis, this proposal will ensure that the monitoring is improved,<br class="">
so it is actually helping on the right direction, not in the other<br class="">
way around.<br class="">
<br class="">
Further to that, because the systems of operators have caches, it is<br class="">
all depending (for the existing TAL and for the new one implemented<br class="">
with this proposal) on how much time it takes to AFRINIC to resolve<br class="">
the error and the specific configuration of the operators and if<br class="">
they actually drop invalid prefixes or they only create alerts,<br class="">
trigger some processes, etc. Note that RPKI doesnt force the<br class="">
operators to drop the prefixes even if they are using RPKI, there<br class="">
are different ways to take advantage of this.<br class="">
<br class="">
This proposal doesn't change that, it is provided as an opt-in<br class="">
service and consequently it is not a valid objection.<br class="">
<br class="">
2.8. h. It also might affect the neighbours and involves<br class="">
monitoring of unallocated spaces<br class="">
<br class="">
It is not clear if neighbours here is referring to BGP peering ones.<br class="">
<br class="">
The same monitoring that right now is done AFRINIC for<br class="">
unallocated/unassigned spaces could be improved with this proposal.<br class="">
AFRINIC already, today, needs to make sure that they get alerts if<br class="">
unallocated/unassigned space appears in the routing tables, because<br class="">
that may imply that a member may be violating the RSA, bylaws,<br class="">
policies, etc.<br class="">
<br class="">
Exactly the same as for operators connected to Internet with BGP.<br class="">
The proposal allows them, as an opt-in service, to improve if they<br class="">
wish, the automation of all that, and to use the service in the way<br class="">
they decide. The proposal is not forcing operators any specific<br class="">
usage for the service, it is entirely at their own<br class="">
decision/discretion.<br class="">
<br class="">
This proposal ensures that the service is improved so, hijacking of<br class="">
unused space is less prone to occur, thats the purpose of the<br class="">
proposal and RPKI, increase the routing security, without making it<br class="">
mandatory for any operator. Consequently, once more, this cant be<br class="">
considered a valid objection.<br class="">
<br class="">
2.9. i. Possibility of it being used against a member who is yet<br class="">
to pay dues<br class="">
<br class="">
According to AFRINIC bylaws and RSA, AFRINIC has the obligation to<br class="">
avoid members not paying to stop using the resources, so they are<br class="">
available to other members.<br class="">
<br class="">
It will be unfair and discriminatory to other members not doing so,<br class="">
and thats the reason, even if we dont have this proposal, AFRINIC<br class="">
could at any time, following the bylaws and RSA, do whatever<br class="">
actions, including legal and technical ones, to make sure that<br class="">
unallocated, or unassigned, or returned, or recovered resources are<br class="">
not used. As part of those actions, AFRINIC could even ask in courts<br class="">
to stop routing those resources, even to other operators. It is<br class="">
AFRINIC duty, practically will probably not make sense in terms of<br class="">
the cost (unless a major hijacking of AFRINIC resources occurs).<br class="">
Most probably just the cooperation among operators, without any<br class="">
legal requirement, will make that happen. So, this proposal doesnt<br class="">
change that in the sense of adding to AFRINIC any new prerogative<br class="">
because already have that right and duty regarding the responsible<br class="">
use of the resources only to the allocated/assigned parties and in<br class="">
compliance with the legal bindings.<br class="">
<br class="">
To further explain this, if a member decides to stop paying,<br class="">
AFRINIC, following legal bindings, will follow a procedure to try to<br class="">
fix it, and if it doesnt succeed, will remove whois data (which in<br class="">
turn will cause the removal of route objects that depend on them),<br class="">
RDNS (which means the address space becomes in general unusable),<br class="">
etc.<br class="">
<br class="">
Clearly, once more, this cant be considered a valid objection, on<br class="">
the other way around is a fundamental AFRINICs right and duty.<br class="">
<br class="">
I urge you to respond to each of those objections, accepted by the<br class="">
chairs to declare the lack of consensus, that the authors and other<br class="">
community members DEMONSTRATED with OBJECTIVE information, are<br class="">
invalid.<br class="">
<br class="">
Again, please, Appeal Committee members, respond OBJECTIVELY AND<br class="">
BASED ON FACTS, NOT PERSONAL PREFERENCES. The report MUST contain<br class="">
detailed demonstration of why the Appeal Committee (not individual<br class="">
members) say each of those objections has not been addressed, while<br class="">
the authors and community believe otherwise.<br class="">
<br class="">
This is what we expect from an Appeal Committee, to OBJECTIVELY<br class="">
review what the chairs objserved, when the Appeal Document clearly<br class="">
demonstrated that it is invalid and consequently the chairs took a<br class="">
wrong decision, based on personal preferences of community members<br class="">
or lack of knowledge, or other not objective or untrue facts.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 22/1/21 13:59, "wafa Dahmani" <<a href="mailto:wafatn7604@gmail.com" class="">wafatn7604@gmail.com</a>> escribi:<br class="">
<br class="">
Dear Community,<br class="">
<br class="">
This is to inform you that the Report on Appeal against the<br class="">
non-consensus determination on proposal AFPUB-2019-GEN-006-DRAFT02<br class="">
(RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space<br class="">
Draft 2) and the minutes have been published following the links<br class="">
below:<br class="">
<br class="">
<a href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p" class="">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p</a><br class="">
df<br class="">
<br class="">
<a href="https://afrinic.net/policy/appeal-committee#appeals" class="">https://afrinic.net/policy/appeal-committee#appeals</a><br class="">
<br class="">
Best Regards<br class="">
<br class="">
Wafa Dahmani<br class="">
<br class="">
Chair of the Appeal Committee<br class="">
<br class="">
_______________________________________________ RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
<br class="">
**********************************************<br class="">
IPv4 is over<br class="">
Are you ready for the new Internet ?<br class="">
<a href="http://www.theipv6company.com/" class="">http://www.theipv6company.com</a><br class="">
The IPv6 Company<br class="">
<br class="">
This electronic message contains information which may be privileged<br class="">
or confidential. The information is intended to be for the exclusive<br class="">
use of the individual(s) named above and further non-explicilty<br class="">
authorized disclosure, copying, distribution or use of the contents<br class="">
of this information, even if partially, including attached files, is<br class="">
strictly prohibited and will be considered a criminal offense. If<br class="">
you are not the intended recipient be aware that any disclosure,<br class="">
copying, distribution or use of the contents of this information,<br class="">
even if partially, including attached files, is strictly prohibited,<br class="">
will be considered a criminal offense, so you must reply to the<br class="">
original sender to inform about this communication and delete it.<br class="">
<br class="">
_______________________________________________ RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
********************************************** IPv4 is over Are you<br class="">
ready for the new Internet ? <a href="http://www.theipv6company.com/" class="">http://www.theipv6company.com</a> The IPv6<br class="">
Company<br class="">
<br class="">
This electronic message contains information which may be privileged<br class="">
or confidential. The information is intended to be for the exclusive<br class="">
use of the individual(s) named above and further non-explicilty<br class="">
authorized disclosure, copying, distribution or use of the contents<br class="">
of this information, even if partially, including attached files, is<br class="">
strictly prohibited and will be considered a criminal offense. If<br class="">
you are not the intended recipient be aware that any disclosure,<br class="">
copying, distribution or use of the contents of this information,<br class="">
even if partially, including attached files, is strictly prohibited,<br class="">
will be considered a criminal offense, so you must reply to the<br class="">
original sender to inform about this communication and delete it.<br class="">
<br class="">
<br class="">
<br class="">
Links:<br class="">
------<br class="">
[1] <a href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html" class="">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a><br class="">
[2] <a href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html" class="">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a></p>
</blockquote><p dir="auto" class="">------- End of forwarded message -------<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a></p>
</blockquote></div>
<div style="white-space:normal" class=""><p dir="auto" class="">--<br class="">
patrick</p>
</div>
</div>
</div>
_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></div></blockquote></div><br class=""></div></body></html>