[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]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: -
Type: application/octet-stream
Size: 18808 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210302/c34d3df9/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prepared-35.zip
Type: application/zip
Size: 14821 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210302/c34d3df9/attachment-0001.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: -
Type: application/octet-stream
Size: 158 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210302/c34d3df9/attachment-0003.obj>