Search RPD Archives
[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
paulos at sdnp.org.mw
Wed Mar 3 09:32:27 UTC 2021
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
>
More information about the RPD
mailing list