<div dir="auto">Bonjour à tous, je pense qu'il ya des arguments dans les éléments soulevés par Anthony nécessitant une réflexion profonde afin d'élaguer certaines zones d'ombre. <div dir="auto"><br></div><div dir="auto">S'il ne considère pas l'ASO comme un opt-in service mais plutôt une obligation incontournable à tous dans le RPKI, on devrait le convaincre de mieux appréhender cela avec des meilleures approches techniques et pédagogiques. </div><div dir="auto"><br></div><div dir="auto">Les tensions ne peuvent uniquement servir en ce temps ci car un certain consensus légitime doit être atteint. </div><div dir="auto"><br></div><div dir="auto">Y'a-t-il dans la proposition un élément mentionné qui l'induit à penser de la sorte pour considérer qu'il ne s'agit par d'un service au choix à exploiter mais d'une obligation ? </div><div dir="auto"><br></div><div dir="auto">Trouvons la possibilité de demeurer cohérent et logique de sorte à aligner les argumentaires dans l'élévation de notre mission. </div><div dir="auto"><br></div><div dir="auto">Cordialement. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 27 janv. 2021 à 17:21, <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: REPORT ON Appeal against the non-consensus determination<br>
on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for Unallocated<br>
and Unassigned AFRINIC Address Space ? Draft 2). (Anthony Ubah)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 27 Jan 2021 15:47:59 +0100<br>
From: Anthony Ubah <<a href="mailto:ubah.tonyiyke@gmail.com" target="_blank" rel="noreferrer">ubah.tonyiyke@gmail.com</a>><br>
To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: Re: [rpd] REPORT ON Appeal against the non-consensus<br>
determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br>
Unallocated and Unassigned AFRINIC Address Space ? Draft 2).<br>
Message-ID:<br>
<<a href="mailto:CAHcb0ATzeB3DHJqr9qV6fDKdWFUSoEmCSx9UDhy4uAFCGPx%2B%2Bg@mail.gmail.com" target="_blank" rel="noreferrer">CAHcb0ATzeB3DHJqr9qV6fDKdWFUSoEmCSx9UDhy4uAFCGPx++g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Jordi,<br>
<br>
This is not an opt-in service; this is created as an additional element in<br>
the RPKI service and forcefully asks the operator (who accepts the RPKI) to<br>
accept it. Taking RPKI as an opt-in service, and claiming the element you<br>
have added here, are already part of that opt-in service. When the operator<br>
accepts it then, it would be misguiding as they may not admit such<br>
additional elements. However, they have no choice if this policy passes, so<br>
this is a valid objection and a critical one.<br>
<br>
The very fundamental principle which I believe you fail to understand (and<br>
the most crucial objection) is that we do not want to get AFRINIC involved<br>
in routing. This is an ideological difference, and this is no way to<br>
address it.<br>
<br>
*This is the very first policy to ask an RIR to proactively inject data<br>
into routing (something that was never done before), and this also goes<br>
beyond what we believe an RIR should be, simply offering a registration<br>
service, and if you think otherwise, that is entirely up to you. This would<br>
then constitute an ideological difference, and there is no acceptable way<br>
you can address it. This is also why this policy does not have consensus<br>
because forcing an ideology on others that fundamentally disagree with you<br>
is not how PDP works, regardless of how many appeals filed. Lastly, an<br>
ideological difference is the very definition of nonconsensus.*<br>
<br>
<br>
*Best Regards,*<br>
<br>
*UBAH ANTHONY *<br>
<br>
On Tue, Jan 26, 2021 at 4:49 PM <<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a>> wrote:<br>
<br>
> Send RPD mailing list submissions to<br>
> <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
><br>
> You can reach the person managing the list at<br>
> <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of RPD digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: REPORT ON Appeal against the non-consensus determination<br>
> on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for Unallocated<br>
> and Unassigned AFRINIC Address Space ? Draft 2).<br>
> (JORDI PALET MARTINEZ)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Tue, 26 Jan 2021 16:48:18 +0100<br>
> From: JORDI PALET MARTINEZ <<a href="mailto:jordi.palet@consulintel.es" target="_blank" rel="noreferrer">jordi.palet@consulintel.es</a>><br>
> To: <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
> Subject: Re: [rpd] REPORT ON Appeal against the non-consensus<br>
> determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br>
> Unallocated and Unassigned AFRINIC Address Space ? Draft 2).<br>
> Message-ID: <<a href="mailto:5192313B-D19C-4CF9-8D9A-423C0EC8C0C8@consulintel.es" target="_blank" rel="noreferrer">5192313B-D19C-4CF9-8D9A-423C0EC8C0C8@consulintel.es</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Hi Fernando,<br>
><br>
><br>
><br>
> Let me explain how I see it.<br>
><br>
><br>
> The PDP is not a vote, and all the processes related to the PDP must<br>
> follow the same way.<br>
> The co-chairs need to follow consensus also among them: If a proposal had<br>
> objections and they?ve been addressed: there is no way for any of the<br>
> co-chairs to disagree on that. If that happens, the co-chairs are doing a<br>
> very bad job, because they need to, during the discussion, follow it, and<br>
> ensure that an objection is:<br>
> It is clearly invalid (it is a personal viewpoint or hast not been<br>
> justified, or clearly is untrue or is a lack of understanding or knowledge)<br>
> Has been addressed by the authors (or other community members),<br>
> Has not been addressed, so it is valid. And in this case, they should<br>
> ensure that the authors or someone else in the community has the<br>
> opportunity to address it.<br>
> Consequently, if a co-chair disagrees with the other one, they need to<br>
> clarify among themselves or ask for further clarification to the community,<br>
> authors, etc. There is no need that both co-chairs ?agree?, if one of the<br>
> co-chairs can see the objection as addressed<br>
> The Appeal Committee must review if the co-chairs did the job correctly in<br>
> 2 above. For that, doesn?t matter if (in the case of 5 AC members) 4 of<br>
> them believe an objection was invalid if only one of them can see that the<br>
> objection it has been addressed: exactly the same as the community and the<br>
> co-chairs.<br>
><br>
><br>
> I fully understand that this is not so easy! But any policy proposal can<br>
> be broken in as many parts as objections raised and then resolved one by<br>
> one.<br>
><br>
><br>
><br>
> Let?s take an example with this proposal. Each objection is a different<br>
> problem and each one should be addressed. Let?s take the first one:<br>
><br>
><br>
> Allowing resource holders to create AS0/ ROA will lead to an increase of<br>
> even more invalid prefixes in the routing table?<br>
><br>
><br>
> If you look at the RFC6483, section 4 (?A ROA with a subject of AS 0 (AS 0<br>
> ROA) is an attestation by the holder of a prefix that the prefix described<br>
> in the ROA, and any more specific prefix, should not be used in a routing<br>
> context?) resource holders, as part of the RPKI system already can and<br>
> actually do this (example IXPs), in fact they do. This has been explained<br>
> several times, including my presentation at the PPM. The proposal is just<br>
> adding light about actual facts regarding this aspect, not changing<br>
> anything, so it can?t be a valid objection for the policy proposal.<br>
><br>
><br>
><br>
> There is no way that *any* of the co-chairs disagree with this. If they<br>
> disagree, they should ask to staff or experts, it shows lack of knowledge<br>
> stating that objection. Even if one co-chair agrees and the other disagree,<br>
> it is still an invalid objection and the co-chair that has no knowledge<br>
> must *consent* this is the meaning of consensus.<br>
><br>
><br>
><br>
> If the co-chairs still insist that this objection is valid, then the<br>
> Appeal Committee does the same exercise. It is a valid objection? If only<br>
> one of the AC has the knowledge to understand this, it is sufficient to<br>
> make it an invalid objection. The others must *consent* (again, meaning of<br>
> consensus).<br>
><br>
><br>
><br>
> Consensus is about only considering acceptable (or valid) those objections<br>
> that nobody can address.<br>
><br>
><br>
><br>
> If the AC makes it based in majority, IT IS NO LONGER CONSENSUS, and<br>
> basically it is basing the decision on the expertise of the different AC<br>
> members, personal opinions, etc.<br>
><br>
><br>
><br>
> Regards,<br>
><br>
> Jordi<br>
><br>
> @jordipalet<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> El 26/1/21 15:03, "Fernando Frediani" <<a href="mailto:fhfrediani@gmail.com" target="_blank" rel="noreferrer">fhfrediani@gmail.com</a>> escribi?:<br>
><br>
><br>
><br>
> Hello Jordi<br>
><br>
> I think that was a very good and detailed email.<br>
> There is however one point I differ on you: the decision taken by the AC<br>
> should be based on majority of votes of the members. Obviously they must<br>
> not take decisions based on personal opinions of the merit of the proposal<br>
> but on the facts and if all issues have been resolved.<br>
> Regarding the decisions between the 2 Co-Chairs I don't think the<br>
> consensus model applies there simply because there is not how to have a<br>
> consensus model applied between 2 persons. Either they both agree on<br>
> something or that cannot advance.<br>
><br>
> In resume: The consensus evaluation between 2 Co-Chair require both to<br>
> agree there was consensus. The consensus evaluation or analysis if the<br>
> Co-Chairs committed a mistake between all members of the AC is done via<br>
> majority and in this last case that doesn't exclude the eventual necessity<br>
> of explaining in details how every evaluation was taken for transparency<br>
> proposes. The consensus model applies only the community while the<br>
> proposals are being discussed and issues are being addressed.<br>
><br>
> Regards<br>
> Fernando<br>
><br>
> On 26/01/2021 07:50, JORDI PALET MARTINEZ via RPD wrote:<br>
><br>
> Hi Wafa, all,<br>
><br>
><br>
><br>
> First of all, don?t take anything that I say personally, but in general I<br>
> see a total failure of the Appeal Committee and lack of compliance with the<br>
> PDP.<br>
><br>
><br>
><br>
> Your judgment must be on the grounds of a correct decision of the chairs.<br>
><br>
><br>
><br>
> In taking such decision the Appeal Committee must be based on facts, never<br>
> on personal opinions (from the community or the chairs or the Appeal<br>
> Committee itself). Being based on objective facts means checking if what<br>
> the policy proposal said, what were the objections, and if those objections<br>
> *are real*, not just ?illusions? or ?lack of knowledge? or ?untrue? or<br>
> ?personal preferences?.<br>
><br>
><br>
><br>
> If the Appeal Committee doesn?t have the right knowledge, as I already<br>
> said I believe was the reason the chairs took the wrong decision, then they<br>
> should ask for help to the staff or third parties.<br>
><br>
><br>
><br>
> Any objection to a policy proposal must be duly justified and that<br>
> justification not addressed by the authors or other community members.<br>
><br>
><br>
><br>
> Any policy proposal that has objections, the objections MUST BE VALID,<br>
> even if the objections come from 99% of the community. This is not<br>
> democracy, is not number of votes or voices, is based on non-addressed<br>
> objections. It is not based on untrue objections. None of the objections to<br>
> this policy proposal were valid. They are mostly based on lack of<br>
> sufficient knowledge, and never lack of knowledge can be a VALID reason.<br>
> Again, not only the authors, but many other expert community members have<br>
> confirmed that those objections are invalid.<br>
><br>
><br>
><br>
> A policy proposal never can be based in ?I don?t like it?. You need to<br>
> state ?I don?t like it because it breaks this RFC? (for example). And even<br>
> in that cases authors can respond showing why the perception of ?breaking<br>
> this RFC? is wrong (so addressing the objection will nullify it). Policies<br>
> are not based on personal preferences, but in what is the best *technically<br>
> correct choice* for the community.<br>
><br>
><br>
><br>
> Last but not least, the Appeal Committee seems to be working as a<br>
> democratic body, which is wrong. ALL THE PDP is based in consensus<br>
> approach. The Appeal Committee must also follow that approach, otherwise,<br>
> it is breaking the ICP-2, which is the higher mandate of how the policy<br>
> making process works. If 3 members of the Appeal Committee believe that the<br>
> opposition was correct, they should *demonstrate with facts why* and this<br>
> must be done using the responses provided by the authors and community to<br>
> those objections.<br>
><br>
><br>
><br>
> If 3 members of the Appeal Committee believe that any of the objections<br>
> has not been addressed, they need to *demonstrate why*, taking in<br>
> consideration the community and author responses, and those must be crystal<br>
> clear in the report, which is not the case.<br>
><br>
><br>
><br>
> The Appeal Committee must respond to the authors, in a consensus based<br>
> approach, not a democratic one to all what the authors confirmed in the<br>
> Appeal Document.<br>
><br>
><br>
><br>
> Note also that there is a paragraph in the Appeal Report that completely<br>
> kills the PDP and demonstrates that the Appeal Committee HAS NOT UNDERSTOOD<br>
> THEIR JOB AT ALL:<br>
><br>
><br>
><br>
> ?The 3 members who observed significant opposition to the policy, however,<br>
> also observed that it is the PDWG that builds consensus and decides whether<br>
> issues of opposition are addressed to the satisfaction of the PDWG which is<br>
> where the PDP requires that consensus is assessed by the Co-Chairs.?<br>
><br>
><br>
><br>
> The PDP states clearly that the Appeal Committee need to review the chairs<br>
> decision. If the chairs have considered as VALID objections that<br>
> OBJECTIVELY ARE INVALID, it is clear that the Appeal Committee must declare<br>
> the lack of consensus declaration is invalid, and consequently, the<br>
> proposal reached consensus.<br>
><br>
><br>
><br>
> Let?s go the details and I ask the Appeal Committee to respond to each of<br>
> the objections included and refuted in the Appeal Document:<br>
><br>
><br>
><br>
> 1. ?a. Allowing resource holders to create AS0/ ROA will lead to an<br>
> increase of even more invalid prefixes in the routing table?<br>
><br>
> Following RFC6483, section 4 (?A ROA with a subject of AS 0 (AS 0 ROA) is<br>
> an attestation by the holder of a prefix that the prefix described in the<br>
> ROA, and any more specific prefix, should not be used in a routing<br>
> context?) resource holders, as part of the RPKI system already can and<br>
> actually do this (example IXPs), in fact they do. This has been explained<br>
> several times, including my presentation at the PPM. The proposal is just<br>
> adding light about actual facts regarding this aspect, not changing<br>
> anything, so it can?t be a valid objection for the policy proposal.<br>
><br>
><br>
><br>
> 2. ?b. Revocation time of AS0 state, and the time for new allocation<br>
> doesn?t match?<br>
><br>
> This is not true, again a misunderstanding about how RPKI works. The<br>
> authors and other several community experts have discussed this in the<br>
> list. If you get number resources from AFRINIC, normally you don?t announce<br>
> them in minutes, or hours, or even days. There is some work to do in your<br>
> network, you need to do changes in systems and routers, and this takes<br>
> hours, and normally you can?t ?touch? systems during the day, but only in<br>
> ?maintenance windows? in the night. That means that if AFRINIC revokes an<br>
> AS0 certificate, it will be done in a few minutes during the day. So even<br>
> if the worldwide caches take hours to see that, there is no negative impact.<br>
><br>
><br>
><br>
> In addition to that, this it can be improved thru implementation, as I<br>
> already explained also in the list. The staff could tentatively release<br>
> from the AS0 the resources that they plan to allocate once a week or every<br>
> couple of days, etc. For example, when they are processing a request, and<br>
> they are pending on final documentation, the RSA signature for new members,<br>
> or the review with the member of the justified need. Many other examples<br>
> can be provided about how to do it. The proposal doesn?t go into any of<br>
> those details, because the understanding is that those are too depth<br>
> operational, and in fact the staff could decide an approach during the<br>
> implementation, and based on experience improve it afterwards.<br>
><br>
><br>
><br>
> The conclusion is that there is no such ?matching?, neither ?unmatching?,<br>
> so this can?t be taken as a valid objection for the proposal.<br>
><br>
><br>
><br>
> 3. ?c. Other RIRs don?t have a similar the policy therefore, it can<br>
> not be effective?<br>
><br>
> All the policies have different discussions in different RIRs at different<br>
> times. This policy is already available (reached consensus and implemented)<br>
> in APNIC and LACNIC (reached consensus, being implemented). There is work<br>
> being done in ARIN and RIPE (the first proposal was not accepted), not yet<br>
> public. So, this is untrue if you look at all the RIRs.<br>
><br>
><br>
><br>
> The effectivity of a policy is not only related to how many RIRs implement<br>
> it. In this case, any RIR having this policy is actually stronger than the<br>
> other RIRs not having it, in terms of routing security. It shows the<br>
> commitment of that RIR about the RPKI usage with all its possibilities. It<br>
> facilitates the operators in the region and outside the region to identify<br>
> in a simpler and automated way, what prefixes should not be in the routing<br>
> tables and consequently allow them in an opt-in basis, to discard them. So,<br>
> it is in the other way around, any RIR with this policy could be said that<br>
> it is more ?effective? (even if it is not probably the right wording for<br>
> this topic) that the others. We should rather say that ?a RIR with this<br>
> policy is offering a more secure view of their routing information?.<br>
><br>
><br>
><br>
> In addition to that, there are policies in AFRINIC which aren?t available<br>
> in other RIRs. That, clearly, doesn?t make them invalid (or in other words,<br>
> this is an invalid objection ? is good that all RIRs do the same, but is<br>
> not always the case, or not at the same time), clearly this shows that this<br>
> can?t be taken as a valid objection against this policy proposal.<br>
><br>
><br>
><br>
> 4. ?d. This will become a uniform policy if it is not globally<br>
> implemented, which causes additional stress?<br>
><br>
> This is almost a duplicate of the previous one. Absolutely not. We can add<br>
> that the way we suggest the staff, and they confirmed, with an independent<br>
> TAL protects, as intended by the proposal, the resources of the RIR<br>
> implementing it, not creating any issues in what is done in other RIRs to<br>
> any operator, so it can?t be taken as a valid objection against this policy<br>
> proposal.<br>
><br>
><br>
><br>
> It is difficult to understand what it means ?additional stress? in this<br>
> context, but clearly, it will be in the other way around. As more RIRs<br>
> implement it, less manual work in terms of filtering, is needed to be done<br>
> by operators, if they opt to use the AS0 ROA service from the RIRs that<br>
> have implemented it. So, it is not correct and thus, not a valid objection.<br>
><br>
><br>
><br>
> If the question is about if this policy should be a Global Policy, the<br>
> response has also been provided in the discussion. Ideally, a Global Policy<br>
> will be only able to protect the IANA unallocated resources, but not the<br>
> resources that IANA already allocated to each RIR. In fact, I?m already<br>
> working (when time permits it will be made public) in a Global Policy for<br>
> that, but this is irrelevant versus having a policy at every RIR (or a few<br>
> of them), so again, objectively not a valid objection.<br>
><br>
><br>
><br>
> 5. ?e. Validity period: if members decide to implement it, is it<br>
> not better to recover the space if it is kept unused for too long??<br>
><br>
> This doesn?t make sense, at least not as worded. This is not about<br>
> recovering space, no relation. It is the unused space hold by AFRINIC,<br>
> regardless of if it was never allocated/assigned, returned by members, or<br>
> recovered by AFRINIC. Once more, not a valid objection.<br>
><br>
><br>
><br>
> 6. ?f. How do we revoke the ROA? How long does it take to revoke it<br>
> (chain/ refreshing )??<br>
><br>
> This looks the same as 2.2 above. It doesn?t matter in practice, if it<br>
> takes minutes or hours or even days. Community and staff provided some<br>
> facts about this, just to cite a couple of them:<br>
><br>
> <a href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a><br>
><br>
> <a href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a><br>
><br>
><br>
><br>
> 7. ?g. What happens if AFRINIC accidentally issues a ROA for an<br>
> address in error??<br>
><br>
> What happens if AFRINIC accidentally issues a ROA without an address<br>
> already allocated to members?<br>
><br>
><br>
><br>
> Exactly the same if the existing RPKI fails, and that?s why there are<br>
> monitoring systems in place and as reported by the staff impact analysis,<br>
> this proposal will ensure that the monitoring is improved, so it is<br>
> actually helping on the right direction, not in the other way around.<br>
><br>
><br>
><br>
> Further to that, because the systems of operators have caches, it is all<br>
> depending (for the existing TAL and for the new one implemented with this<br>
> proposal) on how much time it takes to AFRINIC to resolve the error and the<br>
> specific configuration of the operators and if they actually drop invalid<br>
> prefixes or they only create alerts, trigger some processes, etc. Note that<br>
> RPKI doesn?t force the operators to drop the prefixes even if they are<br>
> using RPKI, there are different ways to take advantage of this.<br>
><br>
><br>
><br>
> This proposal doesn't change that, it is provided as an opt-in service and<br>
> consequently it is not a valid objection.<br>
><br>
><br>
><br>
> 8. ?h. It also might affect the neighbours and involves monitoring<br>
> of unallocated spaces?<br>
><br>
> It is not clear if neighbours here is referring to BGP peering ones.<br>
><br>
><br>
><br>
> The same monitoring that right now is done AFRINIC for<br>
> unallocated/unassigned spaces could be improved with this proposal. AFRINIC<br>
> already, today, needs to make sure that they get alerts if<br>
> unallocated/unassigned space appears in the routing tables, because that<br>
> may imply that a member may be violating the RSA, bylaws, policies, etc.<br>
><br>
><br>
><br>
> Exactly the same as for operators connected to Internet with BGP. The<br>
> proposal allows them, as an opt-in service, to improve if they wish, the<br>
> automation of all that, and to use the service in the way they decide. The<br>
> proposal is not forcing operators any specific usage for the service, it is<br>
> entirely at their own decision/discretion.<br>
><br>
><br>
><br>
> This proposal ensures that the service is improved so, hijacking of unused<br>
> space is less prone to occur, that?s the purpose of the proposal and RPKI,<br>
> increase the routing security, without making it mandatory for any<br>
> operator. Consequently, once more, this can?t be considered a valid<br>
> objection.<br>
><br>
><br>
><br>
> 9. ?i. Possibility of it being used against a member who is yet to<br>
> pay dues?<br>
><br>
> According to AFRINIC bylaws and RSA, AFRINIC has the obligation to avoid<br>
> members not paying to stop using the resources, so they are available to<br>
> other members.<br>
><br>
><br>
><br>
> It will be unfair and discriminatory to other members not doing so, and<br>
> that?s the reason, even if we don?t have this proposal, AFRINIC could at<br>
> any time, following the bylaws and RSA, do whatever actions, including<br>
> legal and technical ones, to make sure that unallocated, or unassigned, or<br>
> returned, or recovered resources are not used. As part of those actions,<br>
> AFRINIC could even ask in courts to stop routing those resources, even to<br>
> other operators. It is AFRINIC duty, practically will probably not make<br>
> sense in terms of the cost (unless a major hijacking of AFRINIC resources<br>
> occurs). Most probably just the cooperation among operators, without any<br>
> legal requirement, will make that happen. So, this proposal doesn?t change<br>
> that in the sense of adding to AFRINIC any new prerogative because already<br>
> have that right and duty regarding the responsible use of the resources<br>
> only to the allocated/assigned parties and in compliance with the legal<br>
> bindings.<br>
><br>
><br>
><br>
> To further explain this, if a member decides to stop paying, AFRINIC,<br>
> following legal bindings, will follow a procedure to try to fix it, and if<br>
> it doesn?t succeed, will remove whois data (which in turn will cause the<br>
> removal of route objects that depend on them), RDNS (which means the<br>
> address space becomes in general unusable), etc.<br>
><br>
><br>
><br>
> Clearly, once more, this can?t be considered a valid objection, on the<br>
> other way around is a fundamental AFRINIC?s right and duty.<br>
><br>
><br>
><br>
> I urge you to respond to each of those objections, accepted by the chairs<br>
> to declare the lack of consensus, that the authors and other community<br>
> members DEMONSTRATED with OBJECTIVE information, are invalid.<br>
><br>
><br>
><br>
> Again, please, Appeal Committee members, respond OBJECTIVELY AND BASED ON<br>
> FACTS, NOT PERSONAL PREFERENCES. The report MUST contain detailed<br>
> demonstration of why the Appeal Committee (not individual members) say each<br>
> of those objections has not been addressed, while the authors and community<br>
> believe otherwise.<br>
><br>
><br>
><br>
> This is what we expect from an Appeal Committee, to OBJECTIVELY review<br>
> what the chairs objserved, when the Appeal Document clearly demonstrated<br>
> that it is invalid and consequently the chairs took a wrong decision, based<br>
> on personal preferences of community members or lack of knowledge, or other<br>
> not objective or untrue facts.<br>
><br>
><br>
><br>
> Regards,<br>
><br>
> Jordi<br>
><br>
> @jordipalet<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> El 22/1/21 13:59, "wafa Dahmani" <<a href="mailto:wafatn7604@gmail.com" target="_blank" rel="noreferrer">wafatn7604@gmail.com</a>> escribi?:<br>
><br>
><br>
><br>
> Dear Community,<br>
><br>
><br>
><br>
> This is to inform you that the Report on Appeal against the non-consensus<br>
> determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br>
> Unallocated and Unassigned AFRINIC Address Space ? Draft 2) and the minutes<br>
> have been published following the links below:<br>
><br>
><br>
><br>
> <a href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf" rel="noreferrer noreferrer" target="_blank">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf</a><br>
><br>
><br>
><br>
> <a href="https://afrinic.net/policy/appeal-committee#appeals" rel="noreferrer noreferrer" target="_blank">https://afrinic.net/policy/appeal-committee#appeals</a><br>
><br>
><br>
><br>
> Best Regards<br>
><br>
> Wafa Dahmani<br>
><br>
> Chair of the Appeal Committee<br>
><br>
><br>
><br>
> _______________________________________________ RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
><br>
> **********************************************<br>
> IPv4 is over<br>
> Are you ready for the new Internet ?<br>
> <a href="http://www.theipv6company.com" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
> The IPv6 Company<br>
><br>
> This electronic message contains information which may be privileged or<br>
> confidential. The information is intended to be for the exclusive use of<br>
> the individual(s) named above and further non-explicilty authorized<br>
> disclosure, copying, distribution or use of the contents of this<br>
> information, even if partially, including attached files, is strictly<br>
> prohibited and will be considered a criminal offense. If you are not the<br>
> intended recipient be aware that any disclosure, copying, distribution or<br>
> use of the contents of this information, even if partially, including<br>
> attached files, is strictly prohibited, will be considered a criminal<br>
> offense, so you must reply to the original sender to inform about this<br>
> communication and delete it.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> _______________________________________________ RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
><br>
><br>
> **********************************************<br>
> IPv4 is over<br>
> Are you ready for the new Internet ?<br>
> <a href="http://www.theipv6company.com" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
> The IPv6 Company<br>
><br>
> This electronic message contains information which may be privileged or<br>
> confidential. The information is intended to be for the exclusive use of<br>
> the individual(s) named above and further non-explicilty authorized<br>
> disclosure, copying, distribution or use of the contents of this<br>
> information, even if partially, including attached files, is strictly<br>
> prohibited and will be considered a criminal offense. If you are not the<br>
> intended recipient be aware that any disclosure, copying, distribution or<br>
> use of the contents of this information, even if partially, including<br>
> attached files, is strictly prohibited, will be considered a criminal<br>
> offense, so you must reply to the original sender to inform about this<br>
> communication and delete it.<br>
><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<br>
> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/attachment.html</a><br>
> ><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of RPD Digest, Vol 172, Issue 12<br>
> ************************************<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20210127/43f2b8ed/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20210127/43f2b8ed/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 172, Issue 13<br>
************************************<br>
</blockquote></div>