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

[JORDI PALET MARTINEZ]

Maybe I'm too naive, but I don't think so. 

It is very common that infected computers use the incomming emails to send outgoing ones with virus, bots, etc.

In fact in the last few monthts the RPD list got several of them.
 
Regards,
Jordi
@jordipalet
 
 

El 3/3/21 10:39, "paulos at sdnp.org.mw" <paulos at sdnp.org.mw> escribió:

    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
    > 



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