[rpd] [PDWG-Appeal] REPORT ON Appeal against the non-consensus determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI R

[paulos at sdnp.org.mw]

On 2 Mar 2021 at 23:13, Owen DeLong wrote:
 

> There are three attachments. The ZIP file contains what purports to be

> an XLS, but appears to be malware.

> 

> The two other attachments are harmless plain text, though the smaller

> one is just an email signature.

> 

> So I confirm Patrick´s report that the message content appears to be

> malicious.


... and targeting the Appeal Committtee.

Regards,

Paulos
=============================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD 
http://www.nic.mw
SDNP: http://www.sdnp.org.mw
Tel:  +265-(0)-882 089 166
Cell: +265-(0)-888-824787
WhatsApp: +265-(0)-887386433



> 

> Owen

> 

> 

>     On Mar 2, 2021, at 1:36 AM, Patrick Okui <pokui at psg.com> wrote:

> 

>     [Diren removed from cc but will likely get it from the list]

>     Please URGENTLY note that this is SPAM, possibly virus infected

>     and hopefully no one will click any of the attachments in the

>     various emails from Diren at . Thanks. On 2 Mar 2021, at 12:21 EAT,

>     paulos at sdnp.org.mw wrote: Diren,

> 

>     Please note that the Appeal Committee has been gagged by the

>     Afrinic Board Chair and hence is currently unable to handle such

>     requests.

> 

>     Regards,

> 

>     Paulos

>     ========================

>     Dr Paulos Nyirenda

> 

>     ------- Forwarded message follows -------

>     Date sent: Mon, 01 Mar 2021 15:13:39 +0100

>     From: diren at vanilla.co.za

>     To: pdwg-appeal at afrinic.net

>     Subject: Re: [PDWG-Appeal] [rpd] REPORT ON Appeal against the

>     non-consensus determination on proposal AFPUB-2019-GEN-006-DRAFT02

>     (RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

> 

> 

>     Good day! As you asked, I´ve collected to you several necessary

>     docs and attached them to the email. If you really will want to

>     find some info, you know, whom to ask.

> 

> 

>     On 2021-02-07 20:48, wrote:

>     Could the Appeal Committee respond to this, and reconsider the

>     work they are doing, as I just explained in my previous email,

>     taking the inputs of the Recall Committee?

> 

>     Regards,

> 

>     Jordi

> 

>     @jordipalet

> 

>     El 26/1/21 12:14, "JORDI PALET MARTINEZ via RPD"<rpd at afrinic.net>

>     escribi:

> 

>     In case the Appeal Committee is not subscribed to the RPD list.

> 

>     Waiting for your response.

> 

>     Regards,

> 

>     Jordi

> 

>     @jordipalet

> 

>     El 26/1/21 11:50, "JORDI PALET MARTINEZ"

>     <jordi.palet at consulintel.es> escribi:

> 

>     Hi Wafa, all,

> 

>     First of all, dont take anything that I say personally, but in

>     general I see a total failure of the Appeal Committee and lack of

>     compliance with the PDP.

> 

>     Your judgment must be on the grounds of a correct decision of the

>     chairs.

> 

>     In taking such decision the Appeal Committee must be based on

>     facts, never on personal opinions (from the community or the

>     chairs or the Appeal Committee itself). Being based on objective

>     facts means checking if what the policy proposal said, what were

>     the objections, and if those objections *are real*, not just

>     illusions or lack of knowledge or untrue or personal preferences.

> 

>     If the Appeal Committee doesnt have the right knowledge, as I

>     already said I believe was the reason the chairs took the wrong

>     decision, then they should ask for help to the staff or third

>     parties.

> 

>     Any objection to a policy proposal must be duly justified and that

>     justification not addressed by the authors or other community

>     members.

> 

>     Any policy proposal that has objections, the objections MUST BE

>     VALID, even if the objections come from 99% of the community. This

>     is not democracy, is not number of votes or voices, is based on

>     non-addressed objections. It is not based on untrue objections.

>     None of the objections to this policy proposal were valid. They

>     are mostly based on lack of sufficient knowledge, and never lack

>     of knowledge can be a VALID reason. Again, not only the authors,

>     but many other expert community members have confirmed that those

>     objections are invalid.

> 

>     A policy proposal never can be based in I dont like it. You need

>     to state I dont like it because it breaks this RFC (for example).

>     And even in that cases authors can respond showing why the

>     perception of breaking this RFC is wrong (so addressing the

>     objection will nullify it). Policies are not based on personal

>     preferences, but in what is the best *technically correct choice*

>     for the community.

> 

>     Last but not least, the Appeal Committee seems to be working as a

>     democratic body, which is wrong. ALL THE PDP is based in consensus

>     approach. The Appeal Committee must also follow that approach,

>     otherwise, it is breaking the ICP-2, which is the higher mandate

>     of how the policy making process works. If 3 members of the Appeal

>     Committee believe that the opposition was correct, they should

>     *demonstrate with facts why* and this must be done using the

>     responses provided by the authors and community to those

>     objections.

> 

>     If 3 members of the Appeal Committee believe that any of the

>     objections has not been addressed, they need to *demonstrate why*,

>     taking in consideration the community and author responses, and

>     those must be crystal clear in the report, which is not the case.

> 

>     The Appeal Committee must respond to the authors, in a consensus

>     based approach, not a democratic one to all what the authors

>     confirmed in the Appeal Document.

> 

>     Note also that there is a paragraph in the Appeal Report that

>     completely kills the PDP and demonstrates that the Appeal

>     Committee HAS NOT UNDERSTOOD THEIR JOB AT ALL:

> 

>     The 3 members who observed significant opposition to the policy,

>     however, also observed that it is the PDWG that builds consensus

>     and decides whether issues of opposition are addressed to the

>     satisfaction of the PDWG which is where the PDP requires that

>     consensus is assessed by the Co-Chairs.

> 

>     The PDP states clearly that the Appeal Committee need to review

>     the chairs decision. If the chairs have considered as VALID

>     objections that OBJECTIVELY ARE INVALID, it is clear that the

>     Appeal Committee must declare the lack of consensus declaration is

>     invalid, and consequently, the proposal reached consensus.

> 

>     Lets go the details and I ask the Appeal Committee to respond to

>     each of the objections included and refuted in the Appeal

>     Document:

> 

>     2.1. a. Allowing resource holders to create AS0/ ROA will lead to

>     an increase of even more invalid prefixes in the routing table

> 

>     Following RFC6483, section 4 (A ROA with a subject of AS 0 (AS 0

>     ROA) is an attestation by the holder of a prefix that the prefix

>     described in the ROA, and any more specific prefix, should not be

>     used in a routing context) resource holders, as part of the RPKI

>     system already can and actually do this (example IXPs), in fact

>     they do. This has been explained several times, including my

>     presentation at the PPM. The proposal is just adding light about

>     actual facts regarding this aspect, not changing anything, so it

>     cant be a valid objection for the policy proposal.

> 

>     2.2. b. Revocation time of AS0 state, and the time for new

>     allocation doesnt match

> 

>     This is not true, again a misunderstanding about how RPKI works.

>     The authors and other several community experts have discussed

>     this in the list. If you get number resources from AFRINIC,

>     normally you dont announce them in minutes, or hours, or even

>     days. There is some work to do in your network, you need to do

>     changes in systems and routers, and this takes hours, and normally

>     you cant touch systems during the day, but only in maintenance

>     windows in the night. That means that if AFRINIC revokes an AS0

>     certificate, it will be done in a few minutes during the day. So

>     even if the worldwide caches take hours to see that, there is no

>     negative impact.

> 

>     In addition to that, this it can be improved thru implementation,

>     as I already explained also in the list. The staff could

>     tentatively release from the AS0 the resources that they plan to

>     allocate once a week or every couple of days, etc. For example,

>     when they are processing a request, and they are pending on final

>     documentation, the RSA signature for new members, or the review

>     with the member of the justified need. Many other examples can be

>     provided about how to do it. The proposal doesnt go into any of

>     those details, because the understanding is that those are too

>     depth operational, and in fact the staff could decide an approach

>     during the implementation, and based on experience improve it

>     afterwards.

> 

>     The conclusion is that there is no such matching, neither

>     unmatching, so this cant be taken as a valid objection for the

>     proposal.

> 

>     2.3. c. Other RIRs dont have a similar the policy therefore, it

>     can not be effective

> 

>     All the policies have different discussions in different RIRs at

>     different times. This policy is already available (reached

>     consensus and implemented) in APNIC and LACNIC (reached consensus,

>     being implemented). There is work being done in ARIN and RIPE (the

>     first proposal was not accepted), not yet public. So, this is

>     untrue if you look at all the RIRs.

> 

>     The effectivity of a policy is not only related to how many RIRs

>     implement it. In this case, any RIR having this policy is actually

>     stronger than the other RIRs not having it, in terms of routing

>     security. It shows the commitment of that RIR about the RPKI usage

>     with all its possibilities. It facilitates the operators in the

>     region and outside the region to identify in a simpler and

>     automated way, what prefixes should not be in the routing tables

>     and consequently allow them in an opt-in basis, to discard them.

>     So, it is in the other way around, any RIR with this policy could

>     be said that it is more effective (even if it is not probably the

>     right wording for this topic) that the others. We should rather

>     say that a RIR with this policy is offering a more secure view of

>     their routing information.

> 

>     In addition to that, there are policies in AFRINIC which arent

>     available in other RIRs. That, clearly, doesnt make them invalid

>     (or in other words, this is an invalid objection is good that all

>     RIRs do the same, but is not always the case, or not at the same

>     time), clearly this shows that this cant be taken as a valid

>     objection against this policy proposal.

> 

>     2.4. d. This will become a uniform policy if it is not globally

>     implemented, which causes additional stress

> 

>     This is almost a duplicate of the previous one. Absolutely not. We

>     can add that the way we suggest the staff, and they confirmed,

>     with an independent TAL protects, as intended by the proposal, the

>     resources of the RIR implementing it, not creating any issues in

>     what is done in other RIRs to any operator, so it cant be taken as

>     a valid objection against this policy proposal.

> 

>     It is difficult to understand what it means additional stress in

>     this context, but clearly, it will be in the other way around. As

>     more RIRs implement it, less manual work in terms of filtering, is

>     needed to be done by operators, if they opt to use the AS0 ROA

>     service from the RIRs that have implemented it. So, it is not

>     correct and thus, not a valid objection.

> 

>     If the question is about if this policy should be a Global Policy,

>     the response has also been provided in the discussion. Ideally, a

>     Global Policy will be only able to protect the IANA unallocated

>     resources, but not the resources that IANA already allocated to

>     each RIR. In fact, Im already working (when time permits it will

>     be made public) in a Global Policy for that, but this is

>     irrelevant versus having a policy at every RIR (or a few of them),

>     so again, objectively not a valid objection.

> 

>     2.5. e. Validity period: if members decide to implement it, is it

>     not better to recover the space if it is kept unused for too long?

> 

>     This doesnt make sense, at least not as worded. This is not about

>     recovering space, no relation. It is the unused space hold by

>     AFRINIC, regardless of if it was never allocated/assigned,

>     returned by members, or recovered by AFRINIC. Once more, not a

>     valid objection.

> 

>     2.6. f. How do we revoke the ROA? How long does it take to revoke

>     it (chain/ refreshing )?

> 

>     This looks the same as 2.2 above. It doesnt matter in practice, if

>     it takes minutes or hours or even days. Community and staff

>     provided some facts about this, just to cite a couple of them:

> 

>     https://lists.afrinic.net/pipermail/rpd/2020/011335.html [1]

> 

>     https://lists.afrinic.net/pipermail/rpd/2020/011348.html [2]

> 

>     2.7. g. What happens if AFRINIC accidentally issues a ROA for an

>     address in error?

> 

>     What happens if AFRINIC accidentally issues a ROA without an

>     address already allocated to members?

> 

>     Exactly the same if the existing RPKI fails, and thats why there

>     are monitoring systems in place and as reported by the staff

>     impact analysis, this proposal will ensure that the monitoring is

>     improved, so it is actually helping on the right direction, not in

>     the other way around.

> 

>     Further to that, because the systems of operators have caches, it

>     is all depending (for the existing TAL and for the new one

>     implemented with this proposal) on how much time it takes to

>     AFRINIC to resolve the error and the specific configuration of the

>     operators and if they actually drop invalid prefixes or they only

>     create alerts, trigger some processes, etc. Note that RPKI doesnt

>     force the operators to drop the prefixes even if they are using

>     RPKI, there are different ways to take advantage of this.

> 

>     This proposal doesn't change that, it is provided as an opt-in

>     service and consequently it is not a valid objection.

> 

>     2.8. h. It also might affect the neighbours and involves

>     monitoring of unallocated spaces

> 

>     It is not clear if neighbours here is referring to BGP peering

>     ones.

> 

>     The same monitoring that right now is done AFRINIC for

>     unallocated/unassigned spaces could be improved with this

>     proposal. AFRINIC already, today, needs to make sure that they get

>     alerts if unallocated/unassigned space appears in the routing

>     tables, because that may imply that a member may be violating the

>     RSA, bylaws, policies, etc.

> 

>     Exactly the same as for operators connected to Internet with BGP.

>     The proposal allows them, as an opt-in service, to improve if they

>     wish, the automation of all that, and to use the service in the

>     way they decide. The proposal is not forcing operators any

>     specific usage for the service, it is entirely at their own

>     decision/discretion.

> 

>     This proposal ensures that the service is improved so, hijacking

>     of unused space is less prone to occur, thats the purpose of the

>     proposal and RPKI, increase the routing security, without making

>     it mandatory for any operator. Consequently, once more, this cant

>     be considered a valid objection.

> 

>     2.9. i. Possibility of it being used against a member who is yet

>     to pay dues

> 

>     According to AFRINIC bylaws and RSA, AFRINIC has the obligation to

>     avoid members not paying to stop using the resources, so they are

>     available to other members.

> 

>     It will be unfair and discriminatory to other members not doing

>     so, and thats the reason, even if we dont have this proposal,

>     AFRINIC could at any time, following the bylaws and RSA, do

>     whatever actions, including legal and technical ones, to make sure

>     that unallocated, or unassigned, or returned, or recovered

>     resources are not used. As part of those actions, AFRINIC could

>     even ask in courts to stop routing those resources, even to other

>     operators. It is AFRINIC duty, practically will probably not make

>     sense in terms of the cost (unless a major hijacking of AFRINIC

>     resources occurs). Most probably just the cooperation among

>     operators, without any legal requirement, will make that happen.

>     So, this proposal doesnt change that in the sense of adding to

>     AFRINIC any new prerogative because already have that right and

>     duty regarding the responsible use of the resources only to the

>     allocated/assigned parties and in compliance with the legal

>     bindings.

> 

>     To further explain this, if a member decides to stop paying,

>     AFRINIC, following legal bindings, will follow a procedure to try

>     to fix it, and if it doesnt succeed, will remove whois data (which

>     in turn will cause the removal of route objects that depend on

>     them), RDNS (which means the address space becomes in general

>     unusable), etc.

> 

>     Clearly, once more, this cant be considered a valid objection, on

>     the other way around is a fundamental AFRINICs right and duty.

> 

>     I urge you to respond to each of those objections, accepted by the

>     chairs to declare the lack of consensus, that the authors and

>     other community members DEMONSTRATED with OBJECTIVE information,

>     are invalid.

> 

>     Again, please, Appeal Committee members, respond OBJECTIVELY AND

>     BASED ON FACTS, NOT PERSONAL PREFERENCES. The report MUST contain

>     detailed demonstration of why the Appeal Committee (not individual

>     members) say each of those objections has not been addressed,

>     while the authors and community believe otherwise.

> 

>     This is what we expect from an Appeal Committee, to OBJECTIVELY

>     review what the chairs objserved, when the Appeal Document clearly

>     demonstrated that it is invalid and consequently the chairs took a

>     wrong decision, based on personal preferences of community members

>     or lack of knowledge, or other not objective or untrue facts.

> 

>     Regards,

> 

>     Jordi

> 

>     @jordipalet

> 

>     El 22/1/21 13:59, "wafa Dahmani" <wafatn7604 at gmail.com> escribi:

> 

>     Dear Community,

> 

>     This is to inform you that the Report on Appeal against the

>     non-consensus determination on proposal AFPUB-2019-GEN-006-DRAFT02

>     (RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

>     Draft 2) and the minutes have been published following the links

>     below:

> 

>     https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report

>     .p df

> 

>     https://afrinic.net/policy/appeal-committee#appeals

> 

>     Best Regards

> 

>     Wafa Dahmani

> 

>     Chair of the Appeal Committee

> 

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

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

> 

> 

> 

>     Links:

>     ------

>     [1] https://lists.afrinic.net/pipermail/rpd/2020/011335.html

>     [2] https://lists.afrinic.net/pipermail/rpd/2020/011348.html

>     ------- End of forwarded message -------

> 

> 

>     _______________________________________________

>     RPD mailing list

>     RPD at afrinic.net

>     https://lists.afrinic.net/mailman/listinfo/rpd

>     --

>     patrick

>     _______________________________________________

>     RPD mailing list

>     RPD at afrinic.net

>     https://lists.afrinic.net/mailman/listinfo/rpd

>