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