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

[Patrick Okui]

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210302/4064796d/attachment-0001.html>