[rpd] RPD Digest, Vol 172, Issue 29

[BINEMO SHADIMIADI Jean Guelord]

Chers tous félicitation pour ce grand débat et plus technique!
Je le toujours dire qu'une loi ou une politique doit tenir compte de
l'aspect technique, psychologique, sociale culturelle pour voir les
habitudes, juridique et financière s'il faut aller loi.
Voilà ma préoccupation sur ce débat utile : il faut éviter de traiter les
un ou les autres des ignorants sur le sujet mais il faut expliquer ,
d'avantage donner des arguments a convaincre pour que ceci soit accepté ou
non accepté.
Il faut éviter de comparaison des communautés car en sciences de
comparaison il ya toujours celui qui supérieur et l'autre inférieur.
Si le RPKI s'avère important pour AFRINIC et bien que Jordi puis le montre
que de
dire que les différences idéologiques sont une «objection invalide». Où
question du temps. Non mais je peux l'accepter ici de supporter le fraude.
Ce pourquoi je demande une réponse qui existe ce qui suit ci dessous et
donner un avis contraire ?
If you look at the 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 can?t be a valid objection for the policy proposal.
Cordiale
BINEMO
Le dim. 31 janv. 2021 à 11:06, <rpd-request at afrinic.net> a écrit :


> Send RPD mailing list submissions to

>         rpd at afrinic.net

>

> To subscribe or unsubscribe via the World Wide Web, visit

>         https://lists.afrinic.net/mailman/listinfo/rpd

> or, via email, send a message with subject or body 'help' to

>         rpd-request at afrinic.net

>

> You can reach the person managing the list at

>         rpd-owner at afrinic.net

>

> When replying, please edit your Subject line so it is more specific

> than "Re: Contents of RPD digest..."

>

>

> Today's Topics:

>

>    1. Re: 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).

>       (JORDI PALET MARTINEZ)

>

>

> ----------------------------------------------------------------------

>

> Message: 1

> Date: Sun, 31 Jan 2021 10:05:02 +0100

> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>

> To: rpd List <rpd at afrinic.net>

> Subject: Re: [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 ? Draft 2).

> Message-ID: <DBCD455F-4241-4CA5-999E-77FF0FDF8FD4 at consulintel.es>

> Content-Type: text/plain; charset="utf-8"

>

> ?Hi Pascal,

>

>

>

> I think the point that you?re missing is that RPKI is NOT mandatory (and

> consequently AS0 is not mandatory).

>

>

>

> Every BGP router operator need to take their own decisions:

> Do I want to run RPKI: yes or not

> Do I want to use the AS0 (if available): yes or not

>

>

> So even in the case that there is some cost involved, it is 100% optional

> for every BGP router operator. Some people update routers to new models

> every 2-3 years, for other reasons different than RPKI (lack of sufficient

> capacity, network grow, routing table is too big for my old routers, etc.,

> etc.), and they may get RPKI as an extra at no additional cost.

>

>

>

> And of course, all the elements to run RPKI are also availble in open

> source with multiple interoperable implementations, so you don?t really

> need to invest in new routers, etc.

>

>

>

> On the other side, regardless if you want to use RPKI or RPKI+AS0, if you

> want to have a healthy network, you will need to run manual filtering,

> which needs to be updated continously: THAT is also a cost.

>

>

>

> So the cost to setup RPKI (or RPKI+AS0) *ONCE* it is clearly much less

> expensive than a recurrent cost of ensuring that filtering is updated.

>

>

>

> Note also that filtering can be automated without RPKI, however, it is not

> that easy/trustable, and you can miss prefixes that may appear as valid, as

> are actually hijacked, which RPKI+AS0 will prevent.

>

>

>

> The risk of not running a healthy network is that you get more spam and

> all kind of malicius activities in your network, and even propagate them,

> so other networks may clasify your own network as non-trustable one and

> even filter you because you?re ?helping? unvoluntarely to propagate

> malicius activities. THIS is also a COST.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 31/1/21 2:48, "Paschal Ochang" <pascosoft at gmail.com> escribi?:

>

>

>

> Hello all,

>

>

>

> >From my own point of view I do think this should be available in a

> consented form and optional form. I am speaking from an economic risk point

> of view .

>

>

>

> To adopt RPKI, i think ISPs may need to deploy and maintain servers

> running as RPs, which means that ISPs have to take on more costs, including

> more responsibilities, more time and more money. Besides, the route origin

> validation in RPKI has been designed to be deployed on current BGP border

> routers. In order to realize the validation, the border routers need to be

> upgraded to accommodate some additions, such as the ?Route Validation

> Database? , which means that with the deployment of RPKI, there are

> additional costs to upgrade the network equipments.

>

>

>

> Kindly correct me if I am wrong jordi. Cheers

>

>

> On Saturday, January 30, 2021, JORDI PALET MARTINEZ via RPD <

> rpd at afrinic.net> wrote:

>

> Hi Elvis,

>

>

>

> I?m not sure to understand if you support or not this proposal, the emails

> is a bit confusing to me.

>

>

>

> *if* what the community want is to make sure that AFRINIC doesn?t provide

> any routing information, so the community can decide if they want to use it

> or not, then AFRINIC should:

>

> 1) STOP providing RPKI.

>

> 2) STOP providing by means whois and any other DBs, information about who

> are the legitimate resource holders for each block of addresses.

>

>

>

> Doing so, means we don?t need a register anymore, or the functions of the

> register should be limited to ?pay for the resource fee and you get it?.

>

>

>

> RPKI and AS0 are just one tool, one facility, to have that information in

> a trusted way, with allows automation for *those* that want to use it.

>

>

>

> IT DOESN?T enforces anyone to use that information, and still allows to

> use RPKI, without using AS0.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 31/1/21 0:06, "Ibeanusi Elvis" <ibeanusielvis at gmail.com> escribi?:

>

>

>

> Dear all,

>

>

>

> As earlier mentioned, the pivotal and fundamental principle is that

> AFRINIC organization should not be made to get involved in routing which I

> am entirely in support of and also this is not an opt-in service and should

> not be made to be so.

>

>

>

> The major purpose of the RPKI is that it serves as a security framework

> that verifies the association between the internet number resources and

> their rightful holders. Hence, this verification aspects would allow and

> give the provider or the holders an immense opportunity/right to protect

> themselves from hijacks as well as giving them the flexibility and

> independence of choice.

>

>

>

> I concur that this is not a spread of misinformation but rather it is more

> trying to stress and lay emphasize on something that might and will cause

> problems if been done.

>

>

>

> Best,

>

> Elvis.

>

> On Jan 31, 2021, at 5:11, Fernando Frediani <fhfrediani at gmail.com> wrote:

>

>

>

> There is no routing data being injected. This is not BGP !

> Please stop spreading misinformation.

>

> Once again can anyone that fears ASN0 for Unnalocated Space answer my

> questions about what is the fear of using it, what problems can it bring

> and all the points raised regarding the objectives of the RIR which all

> completely match the use of RPKI as a tool to protect its members and

> Internet in the region ?

>

> Thanks

> Fernando

>

> On 30/01/2021 17:05, Wijdane Goubi wrote:

>

> Dear community,

>

>

>

> I agree on what was mentioned before as it goes that whoever uses RPKI can

> invalidate the unallocated spaces with a code and that there is no need to

> do a completely whole policy for it as other regions such as RIPE did not

> accept to apply such approach.

>

>

>

> As for the ideology point, I totally agree because an ideology is a body

> of ideas, and those who agree with the main idea of something take an

> ideological stand to support it therefore whatever policy that is about to

> be applied should take into consideration the ideological part of it which

> makes some facts up to discussion over again.

>

>

>

> Indeed, requiring the injection of data routing data into the only

> available routing certification program makes it a violation to the RIR?s

> purpose which makes it again an ideological difference.

>

>

>

>

>

> Regards,

>

> Wijdane

>

>

>

> On Fri, Jan 29, 2021, 00:11 Anthony Ubah <ubah.tonyiyke at gmail.com> wrote:

>

>

>

> Dear Jord!

>

>

>

> I think you may be misunderstanding me when I say that they are invalid.

> It is also quite unfortunate to hear you say that ideological differences

> are an ?invalid objection?.

>

>

>

> The providers, who use RPKI, can invalidate (or AS0 as you put it) those

> unallocated spaces themselves with minimal code, so there is no need to

> have a particular policy for it. That is the exact reason why such an

> approach is not accepted in RIPE in the first place. I to also note that

> there is really no need to converting BOP (best operating practices) into

> unnecessary policies, as is slowly becominga norm. I am sure that you have

> best interests at heart, but this is not what policies are supposed to be.

>

>

>

> Contrarywise, requiring RIRs to inject routing data into the only

> available routing certification program is a violation of the RIR?s

> purpose. The RIRs are not built for regulating routing ? this is the

> ideological difference that I am talking about ? (and something I believe

> you have been told regularly in the RIPE region), including the most recent

> appeal you have filed against the contact abuse policy in RIPE.

>

>

>

> If you ask anyone here to compensate for hijacking, the chances are there

> is an inordinately high probability that most of them misunderstand an

> RIR?s fundamental functions. If you want to use RPKI to prevent hijacking,

> you can do it today; moreover, if you wish to use RPKI with AS0

> functionality, you can also do it today with just a few additional lines of

> code.

>

>

>

> Therefore, your argument that the provider can?t protect themselves from

> hijacking because they lack AS0 functionality in an RIR-provided space is

> very misleading. On the other hand, the current status quo allows the

> provider to choose whether or not they want such functionality instead of

> forcing it on them. The AS0 for unallocated space is already an optional

> function that anyone can enable independently, and enabling AS0 is a BOF

> rather than a policy issue.

>

>

>

>

>

> Kind regards,

>

>

>

>

>

> Anthony

>

>

>

>

>

> ------------------------------

>

> Date: Thu, 28 Jan 2021 10:06:13 +0100

> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>

> To: <rpd at afrinic.net>

> Subject: Re: [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 ? Draft 2).

> Message-ID: <9149D981-DD95-473D-9D59-DBB705FB712B at consulintel.es>

> Content-Type: text/plain; charset="utf-8"

>

> Hi Anthony,

>

>

>

> I don?t recall now if you were in favor or against the proposal, anyway,

> my understanding from your email is that you?re trying to explain why the

> people that don?t have the right expertise/knowledge, is opposing to the

> proposal.

>

>

>

> Your text show how wrong is the understanding of how RPKI works:

>

>

> RPKI is an opt-in service. There is no enforcement to use RPKI. As a

> consequence, this proposal doesn?t change the information already available

> in the AFRINIC database. The database already contains information of who

> is the right resource-holder for every block and what blocks should not be

> ?in use? (unallocated, recovered, or whatever are the reasons).

> RPKI is a set of tools. The AS0 is part of this set of tools. It is an

> opt-in service as well. You can use RPKI but decide not to trust/use the

> AS0. It is completely optional, but for those that want to have less

> chances of routing hijacked or invalid resources, it simplifies a lot their

> lives. They could build their own ?tools? reading the AFRINIC database and

> creating their own filters. AS0 is only simplifying that and making the

> source more trusted and more automated.

> Consequently, it is untrue what you said ?they have no choice if this

> policy passes, so this is a valid objection and a critical one? is

> technically and objectively UNTRUE. There is no way to sustain that this is

> a valid objection.

> With RPKI or anything related to this ?tool set? AFRINIC doesn?t get

> involved in routing in any *different* way than by having a database

> holding the information of what blocks are ?in use? or otherwise.

>

>

> So, I must insist. The objections are invalid. Please demonstrate your

> words, because they are UNTRUE, technically and objectively. They will

> *only* become true if we *force* all the members (and the members of all

> the other RIRs to):

> Use RPKI.

> AND

> Filter the invalids in the AS0

>

>

> As one of my author colleagues said in the discussion among us (I modify a

> bit the text to make it more explicit), accepting as valid the clearly

> *invalid* objections means that some community members, the chairs, and the

> Appeal Committee, are responsible of the ?blood of the future hijacks that

> could have been avoided by those willing to use RPKI and the AS0?.

>

>

>

> So, the question is, are you going to compensate for the damages for that?

> Because it is a violation of the PDP to declare as valid objections that

> are technically and clearly invalid. This is beyond to this policy

> proposal; it is referred to the absolute violation of the PDP when

> declaring consensus/non-consensus. Invalid objections must be demonstrated

> or non-addressed by the authors or the community, not based on personal

> preferences or opinions.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 27/1/21 15:48, "Anthony Ubah" <ubah.tonyiyke at gmail.com> escribi?:

>

>

>

> Hello Jordi,

>

>

> This is not an opt-in service; this is created as an additional element in

> the RPKI service and forcefully asks the operator (who accepts the RPKI) to

> accept it. Taking RPKI as an opt-in service, and claiming the element you

> have added here, are already part of that opt-in service. When the operator

> accepts it then, it would be misguiding as they may not admit such

> additional elements. However, they have no choice if this policy passes, so

> this is a valid objection and a critical one.

>

> The very fundamental principle which I believe you fail to understand (and

> the most crucial objection) is that we do not want to get AFRINIC involved

> in routing. This is an ideological difference, and this is no way to

> address it.

>

> This is the very first policy to ask an RIR to proactively inject data

> into routing (something that was never done before), and this also goes

> beyond what we believe an RIR should be, simply offering a registration

> service, and if you think otherwise, that is entirely up to you. This would

> then constitute an ideological difference, and there is no acceptable way

> you can address it. This is also why this policy does not have consensus

> because forcing an ideology on others that fundamentally disagree with you

> is not how PDP works, regardless of how many appeals filed. Lastly, an

> ideological difference is the very definition of nonconsensus.

>

>

>

> Best Regards,

>

> UBAH ANTHONY

>

>

>

> On Tue, Jan 26, 2021 at 4:49 PM <rpd-request at afrinic.net> wrote:

>

> Send RPD mailing list submissions to

>         rpd at afrinic.net

>

> To subscribe or unsubscribe via the World Wide Web, visit

>         https://lists.afrinic.net/mailman/listinfo/rpd

> or, via email, send a message with subject or body 'help' to

>         rpd-request at afrinic.net

>

> You can reach the person managing the list at

>         rpd-owner at afrinic.net

>

> When replying, please edit your Subject line so it is more specific

> than "Re: Contents of RPD digest..."

>

>

> Today's Topics:

>

>    1. Re: 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).

>       (JORDI PALET MARTINEZ)

>

>

> ----------------------------------------------------------------------

>

> Message: 1

> Date: Tue, 26 Jan 2021 16:48:18 +0100

> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>

> To: <rpd at afrinic.net>

> Subject: Re: [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 ? Draft 2).

> Message-ID: <5192313B-D19C-4CF9-8D9A-423C0EC8C0C8 at consulintel.es>

> Content-Type: text/plain; charset="utf-8"

>

> Hi Fernando,

>

>

>

> Let me explain how I see it.

>

>

> The PDP is not a vote, and all the processes related to the PDP must

> follow the same way.

> The co-chairs need to follow consensus also among them: If a proposal had

> objections and they?ve been addressed: there is no way for any of the

> co-chairs to disagree on that. If that happens, the co-chairs are doing a

> very bad job, because they need to, during the discussion, follow it, and

> ensure that an objection is:

> It is clearly invalid (it is a personal viewpoint or hast not been

> justified, or clearly is untrue or is a lack of understanding or knowledge)

> Has been addressed by the authors (or other community members),

> Has not been addressed, so it is valid. And in this case, they should

> ensure that the authors or someone else in the community has the

> opportunity to address it.

> Consequently, if a co-chair disagrees with the other one, they need to

> clarify among themselves or ask for further clarification to the community,

> authors, etc. There is no need that both co-chairs ?agree?, if one of the

> co-chairs can see the objection as addressed

> The Appeal Committee must review if the co-chairs did the job correctly in

> 2 above. For that, doesn?t matter if (in the case of 5 AC members) 4 of

> them believe an objection was invalid if only one of them can see that the

> objection it has been addressed: exactly the same as the community and the

> co-chairs.

>

>

> I fully understand that this is not so easy! But any policy proposal can

> be broken in as many parts as objections raised and then resolved one by

> one.

>

>

>

> Let?s take an example with this proposal. Each objection is a different

> problem and each one should be addressed. Let?s take the first one:

>

>

> Allowing resource holders to create AS0/ ROA will lead to an increase of

> even more invalid prefixes in the routing table?

>

>

> If you look at the 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 can?t be a valid objection for the policy proposal.

>

>

>

> There is no way that *any* of the co-chairs disagree with this. If they

> disagree, they should ask to staff or experts, it shows lack of knowledge

> stating that objection. Even if one co-chair agrees and the other disagree,

> it is still an invalid objection and the co-chair that has no knowledge

> must *consent* this is the meaning of consensus.

>

>

>

> If the co-chairs still insist that this objection is valid, then the

> Appeal Committee does the same exercise. It is a valid objection? If only

> one of the AC has the knowledge to understand this, it is sufficient to

> make it an invalid objection. The others must *consent* (again, meaning of

> consensus).

>

>

>

> Consensus is about only considering acceptable (or valid) those objections

> that nobody can address.

>

>

>

> If the AC makes it based in majority, IT IS NO LONGER CONSENSUS, and

> basically it is basing the decision on the expertise of the different AC

> members, personal opinions, etc.

>

>

>

> Regards,

>

> Jordi

>

> @jordipalet

>

>

>

>

>

>

>

> El 26/1/21 15:03, "Fernando Frediani" <fhfrediani at gmail.com> escribi?:

>

>

>

> Hello Jordi

>

> I think that was a very good and detailed email.

> There is however one point I differ on you: the decision taken by the AC

> should be based on majority of votes of the members. Obviously they must

> not take decisions based on personal opinions of the merit of the proposal

> but on the facts and if all issues have been resolved.

> Regarding the decisions between the 2 Co-Chairs I don't think the

> consensus model applies there simply because there is not how to have a

> consensus model applied between 2 persons. Either they both agree on

> something or that cannot advance.

>

> In resume: The consensus evaluation between 2 Co-Chair require both to

> agree there was consensus. The consensus evaluation or analysis if the

> Co-Chairs committed a mistake between all members of the AC is done via

> majority and in this last case that doesn't exclude the eventual necessity

> of explaining in details how every evaluation was taken for transparency

> proposes. The consensus model applies only the community while the

> proposals are being discussed and issues are being addressed.

>

> Regards

> Fernando

>

> On 26/01/2021 07:50, JORDI PALET MARTINEZ via RPD wrote:

>

> Hi Wafa, all,

>

>

>

> First of all, don?t 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 doesn?t 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 don?t like it?. You need to

> state ?I don?t 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.

>

>

>

> Let?s go the details and I ask the Appeal Committee to respond to each of

> the objections included and refuted in the Appeal Document:

>

>

>

> 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 can?t be a valid objection for the policy proposal.

>

>

>

> 2.       ?b. Revocation time of AS0 state, and the time for new allocation

> doesn?t 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 don?t 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 can?t ?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 doesn?t 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 can?t be taken as a valid objection for the proposal.

>

>

>

> 3.       ?c. Other RIRs don?t 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 aren?t available

> in other RIRs. That, clearly, doesn?t 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

> can?t be taken as a valid objection against this policy proposal.

>

>

>

> 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 can?t 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, I?m 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.

>

>

>

> 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 doesn?t 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.

>

>

>

> 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 doesn?t 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

>

> https://lists.afrinic.net/pipermail/rpd/2020/011348.html

>

>

>

> 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 that?s 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 doesn?t 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.

>

>

>

> 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, that?s the purpose of the proposal and RPKI,

> increase the routing security, without making it mandatory for any

> operator. Consequently, once more, this can?t be considered a valid

> objection.

>

>

>

> 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

> that?s the reason, even if we don?t 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 doesn?t 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 doesn?t 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 can?t be considered a valid objection, on the

> other way around is a fundamental AFRINIC?s 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.pdf

>

>

>

> 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

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

>

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/attachment.html

> >

>

> ------------------------------

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> ------------------------------

>

> End of RPD Digest, Vol 172, Issue 12

> ************************************

>

>

>

> **********************************************

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

>

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20210128/c89d2524/attachment.html

> >

>

> ------------------------------

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> ------------------------------

>

> End of RPD Digest, Vol 172, Issue 15

> ************************************

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> _______________________________________________ RPD mailing list

> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com

> The IPv6 Company

>

> This electronic message contains information which may be privileged or

> confidential. The information is intended to be for the exclusive use of

> the individual(s) named above and further non-explicilty authorized

> disclosure, copying, distribution or use of the contents of this

> information, even if partially, including attached files, is strictly

> prohibited and will be considered a criminal offense. If you are not the

> intended recipient be aware that any disclosure, copying, distribution or

> use of the contents of this information, even if partially, including

> attached files, is strictly prohibited, will be considered a criminal

> offense, so you must reply to the original sender to inform about this

> communication and delete it.

>

>

>

> --

> Kind regards,

>

> Paschal.

>

>

>

> **********************************************

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

>

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20210131/076ee860/attachment.html

> >

>

> ------------------------------

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> ------------------------------

>

> End of RPD Digest, Vol 172, Issue 29

> ************************************

>


Le 31 janv. 2021 11:06, <rpd-request at afrinic.net> a écrit :

Send RPD mailing list submissions to
        rpd at afrinic.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.afrinic.net/mailman/listinfo/rpd
or, via email, send a message with subject or body 'help' to
        rpd-request at afrinic.net

You can reach the person managing the list at
        rpd-owner at afrinic.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPD digest..."


Today's Topics:

   1. Re: 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).
      (JORDI PALET MARTINEZ)


----------------------------------------------------------------------

Message: 1
Date: Sun, 31 Jan 2021 10:05:02 +0100
From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
To: rpd List <rpd at afrinic.net>
Subject: Re: [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 ? Draft 2).
Message-ID: <DBCD455F-4241-4CA5-999E-77FF0FDF8FD4 at consulintel.es>
Content-Type: text/plain; charset="utf-8"

?Hi Pascal,



I think the point that you?re missing is that RPKI is NOT mandatory (and
consequently AS0 is not mandatory).



Every BGP router operator need to take their own decisions:
Do I want to run RPKI: yes or not
Do I want to use the AS0 (if available): yes or not


So even in the case that there is some cost involved, it is 100% optional
for every BGP router operator. Some people update routers to new models
every 2-3 years, for other reasons different than RPKI (lack of sufficient
capacity, network grow, routing table is too big for my old routers, etc.,
etc.), and they may get RPKI as an extra at no additional cost.



And of course, all the elements to run RPKI are also availble in open
source with multiple interoperable implementations, so you don?t really
need to invest in new routers, etc.



On the other side, regardless if you want to use RPKI or RPKI+AS0, if you
want to have a healthy network, you will need to run manual filtering,
which needs to be updated continously: THAT is also a cost.



So the cost to setup RPKI (or RPKI+AS0) *ONCE* it is clearly much less
expensive than a recurrent cost of ensuring that filtering is updated.



Note also that filtering can be automated without RPKI, however, it is not
that easy/trustable, and you can miss prefixes that may appear as valid, as
are actually hijacked, which RPKI+AS0 will prevent.



The risk of not running a healthy network is that you get more spam and all
kind of malicius activities in your network, and even propagate them, so
other networks may clasify your own network as non-trustable one and even
filter you because you?re ?helping? unvoluntarely to propagate malicius
activities. THIS is also a COST.



Regards,

Jordi

@jordipalet







El 31/1/21 2:48, "Paschal Ochang" <pascosoft at gmail.com> escribi?:



Hello all,




>From my own point of view I do think this should be available in a

consented form and optional form. I am speaking from an economic risk point
of view .



To adopt RPKI, i think ISPs may need to deploy and maintain servers running
as RPs, which means that ISPs have to take on more costs, including more
responsibilities, more time and more money. Besides, the route origin
validation in RPKI has been designed to be deployed on current BGP border
routers. In order to realize the validation, the border routers need to be
upgraded to accommodate some additions, such as the ?Route Validation
Database? , which means that with the deployment of RPKI, there are
additional costs to upgrade the network equipments.



Kindly correct me if I am wrong jordi. Cheers


On Saturday, January 30, 2021, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>
wrote:

Hi Elvis,



I?m not sure to understand if you support or not this proposal, the emails
is a bit confusing to me.



*if* what the community want is to make sure that AFRINIC doesn?t provide
any routing information, so the community can decide if they want to use it
or not, then AFRINIC should:

1) STOP providing RPKI.

2) STOP providing by means whois and any other DBs, information about who
are the legitimate resource holders for each block of addresses.



Doing so, means we don?t need a register anymore, or the functions of the
register should be limited to ?pay for the resource fee and you get it?.



RPKI and AS0 are just one tool, one facility, to have that information in a
trusted way, with allows automation for *those* that want to use it.



IT DOESN?T enforces anyone to use that information, and still allows to use
RPKI, without using AS0.



Regards,

Jordi

@jordipalet







El 31/1/21 0:06, "Ibeanusi Elvis" <ibeanusielvis at gmail.com> escribi?:



Dear all,



As earlier mentioned, the pivotal and fundamental principle is that AFRINIC
organization should not be made to get involved in routing which I am
entirely in support of and also this is not an opt-in service and should
not be made to be so.



The major purpose of the RPKI is that it serves as a security framework
that verifies the association between the internet number resources and
their rightful holders. Hence, this verification aspects would allow and
give the provider or the holders an immense opportunity/right to protect
themselves from hijacks as well as giving them the flexibility and
independence of choice.



I concur that this is not a spread of misinformation but rather it is more
trying to stress and lay emphasize on something that might and will cause
problems if been done.



Best,

Elvis.

On Jan 31, 2021, at 5:11, Fernando Frediani <fhfrediani at gmail.com> wrote:



There is no routing data being injected. This is not BGP !
Please stop spreading misinformation.

Once again can anyone that fears ASN0 for Unnalocated Space answer my
questions about what is the fear of using it, what problems can it bring
and all the points raised regarding the objectives of the RIR which all
completely match the use of RPKI as a tool to protect its members and
Internet in the region ?

Thanks
Fernando

On 30/01/2021 17:05, Wijdane Goubi wrote:

Dear community,



I agree on what was mentioned before as it goes that whoever uses RPKI can
invalidate the unallocated spaces with a code and that there is no need to
do a completely whole policy for it as other regions such as RIPE did not
accept to apply such approach.



As for the ideology point, I totally agree because an ideology is a body of
ideas, and those who agree with the main idea of something take an
ideological stand to support it therefore whatever policy that is about to
be applied should take into consideration the ideological part of it which
makes some facts up to discussion over again.



Indeed, requiring the injection of data routing data into the only
available routing certification program makes it a violation to the RIR?s
purpose which makes it again an ideological difference.





Regards,

Wijdane



On Fri, Jan 29, 2021, 00:11 Anthony Ubah <ubah.tonyiyke at gmail.com> wrote:



Dear Jord!



I think you may be misunderstanding me when I say that they are invalid. It
is also quite unfortunate to hear you say that ideological differences are
an ?invalid objection?.



The providers, who use RPKI, can invalidate (or AS0 as you put it) those
unallocated spaces themselves with minimal code, so there is no need to
have a particular policy for it. That is the exact reason why such an
approach is not accepted in RIPE in the first place. I to also note that
there is really no need to converting BOP (best operating practices) into
unnecessary policies, as is slowly becominga norm. I am sure that you have
best interests at heart, but this is not what policies are supposed to be.



Contrarywise, requiring RIRs to inject routing data into the only available
routing certification program is a violation of the RIR?s purpose. The RIRs
are not built for regulating routing ? this is the ideological difference
that I am talking about ? (and something I believe you have been told
regularly in the RIPE region), including the most recent appeal you have
filed against the contact abuse policy in RIPE.



If you ask anyone here to compensate for hijacking, the chances are there
is an inordinately high probability that most of them misunderstand an
RIR?s fundamental functions. If you want to use RPKI to prevent hijacking,
you can do it today; moreover, if you wish to use RPKI with AS0
functionality, you can also do it today with just a few additional lines of
code.



Therefore, your argument that the provider can?t protect themselves from
hijacking because they lack AS0 functionality in an RIR-provided space is
very misleading. On the other hand, the current status quo allows the
provider to choose whether or not they want such functionality instead of
forcing it on them. The AS0 for unallocated space is already an optional
function that anyone can enable independently, and enabling AS0 is a BOF
rather than a policy issue.





Kind regards,





Anthony





------------------------------

Date: Thu, 28 Jan 2021 10:06:13 +0100
From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
To: <rpd at afrinic.net>
Subject: Re: [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 ? Draft 2).
Message-ID: <9149D981-DD95-473D-9D59-DBB705FB712B at consulintel.es>
Content-Type: text/plain; charset="utf-8"

Hi Anthony,



I don?t recall now if you were in favor or against the proposal, anyway, my
understanding from your email is that you?re trying to explain why the
people that don?t have the right expertise/knowledge, is opposing to the
proposal.



Your text show how wrong is the understanding of how RPKI works:


RPKI is an opt-in service. There is no enforcement to use RPKI. As a
consequence, this proposal doesn?t change the information already available
in the AFRINIC database. The database already contains information of who
is the right resource-holder for every block and what blocks should not be
?in use? (unallocated, recovered, or whatever are the reasons).
RPKI is a set of tools. The AS0 is part of this set of tools. It is an
opt-in service as well. You can use RPKI but decide not to trust/use the
AS0. It is completely optional, but for those that want to have less
chances of routing hijacked or invalid resources, it simplifies a lot their
lives. They could build their own ?tools? reading the AFRINIC database and
creating their own filters. AS0 is only simplifying that and making the
source more trusted and more automated.
Consequently, it is untrue what you said ?they have no choice if this
policy passes, so this is a valid objection and a critical one? is
technically and objectively UNTRUE. There is no way to sustain that this is
a valid objection.
With RPKI or anything related to this ?tool set? AFRINIC doesn?t get
involved in routing in any *different* way than by having a database
holding the information of what blocks are ?in use? or otherwise.


So, I must insist. The objections are invalid. Please demonstrate your
words, because they are UNTRUE, technically and objectively. They will
*only* become true if we *force* all the members (and the members of all
the other RIRs to):
Use RPKI.
AND
Filter the invalids in the AS0


As one of my author colleagues said in the discussion among us (I modify a
bit the text to make it more explicit), accepting as valid the clearly
*invalid* objections means that some community members, the chairs, and the
Appeal Committee, are responsible of the ?blood of the future hijacks that
could have been avoided by those willing to use RPKI and the AS0?.



So, the question is, are you going to compensate for the damages for that?
Because it is a violation of the PDP to declare as valid objections that
are technically and clearly invalid. This is beyond to this policy
proposal; it is referred to the absolute violation of the PDP when
declaring consensus/non-consensus. Invalid objections must be demonstrated
or non-addressed by the authors or the community, not based on personal
preferences or opinions.



Regards,

Jordi

@jordipalet







El 27/1/21 15:48, "Anthony Ubah" <ubah.tonyiyke at gmail.com> escribi?:



Hello Jordi,


This is not an opt-in service; this is created as an additional element in
the RPKI service and forcefully asks the operator (who accepts the RPKI) to
accept it. Taking RPKI as an opt-in service, and claiming the element you
have added here, are already part of that opt-in service. When the operator
accepts it then, it would be misguiding as they may not admit such
additional elements. However, they have no choice if this policy passes, so
this is a valid objection and a critical one.

The very fundamental principle which I believe you fail to understand (and
the most crucial objection) is that we do not want to get AFRINIC involved
in routing. This is an ideological difference, and this is no way to
address it.

This is the very first policy to ask an RIR to proactively inject data into
routing (something that was never done before), and this also goes beyond
what we believe an RIR should be, simply offering a registration service,
and if you think otherwise, that is entirely up to you. This would then
constitute an ideological difference, and there is no acceptable way you
can address it. This is also why this policy does not have consensus
because forcing an ideology on others that fundamentally disagree with you
is not how PDP works, regardless of how many appeals filed. Lastly, an
ideological difference is the very definition of nonconsensus.



Best Regards,

UBAH ANTHONY



On Tue, Jan 26, 2021 at 4:49 PM <rpd-request at afrinic.net> wrote:

Send RPD mailing list submissions to
        rpd at afrinic.net

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.afrinic.net/mailman/listinfo/rpd
or, via email, send a message with subject or body 'help' to
        rpd-request at afrinic.net

You can reach the person managing the list at
        rpd-owner at afrinic.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPD digest..."


Today's Topics:

   1. Re: 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).
      (JORDI PALET MARTINEZ)


----------------------------------------------------------------------

Message: 1
Date: Tue, 26 Jan 2021 16:48:18 +0100
From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
To: <rpd at afrinic.net>
Subject: Re: [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 ? Draft 2).
Message-ID: <5192313B-D19C-4CF9-8D9A-423C0EC8C0C8 at consulintel.es>
Content-Type: text/plain; charset="utf-8"

Hi Fernando,



Let me explain how I see it.


The PDP is not a vote, and all the processes related to the PDP must follow
the same way.
The co-chairs need to follow consensus also among them: If a proposal had
objections and they?ve been addressed: there is no way for any of the
co-chairs to disagree on that. If that happens, the co-chairs are doing a
very bad job, because they need to, during the discussion, follow it, and
ensure that an objection is:
It is clearly invalid (it is a personal viewpoint or hast not been
justified, or clearly is untrue or is a lack of understanding or knowledge)
Has been addressed by the authors (or other community members),
Has not been addressed, so it is valid. And in this case, they should
ensure that the authors or someone else in the community has the
opportunity to address it.
Consequently, if a co-chair disagrees with the other one, they need to
clarify among themselves or ask for further clarification to the community,
authors, etc. There is no need that both co-chairs ?agree?, if one of the
co-chairs can see the objection as addressed
The Appeal Committee must review if the co-chairs did the job correctly in
2 above. For that, doesn?t matter if (in the case of 5 AC members) 4 of
them believe an objection was invalid if only one of them can see that the
objection it has been addressed: exactly the same as the community and the
co-chairs.


I fully understand that this is not so easy! But any policy proposal can be
broken in as many parts as objections raised and then resolved one by one.



Let?s take an example with this proposal. Each objection is a different
problem and each one should be addressed. Let?s take the first one:


Allowing resource holders to create AS0/ ROA will lead to an increase of
even more invalid prefixes in the routing table?


If you look at the 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 can?t be a valid objection for the policy proposal.



There is no way that *any* of the co-chairs disagree with this. If they
disagree, they should ask to staff or experts, it shows lack of knowledge
stating that objection. Even if one co-chair agrees and the other disagree,
it is still an invalid objection and the co-chair that has no knowledge
must *consent* this is the meaning of consensus.



If the co-chairs still insist that this objection is valid, then the Appeal
Committee does the same exercise. It is a valid objection? If only one of
the AC has the knowledge to understand this, it is sufficient to make it an
invalid objection. The others must *consent* (again, meaning of consensus).



Consensus is about only considering acceptable (or valid) those objections
that nobody can address.



If the AC makes it based in majority, IT IS NO LONGER CONSENSUS, and
basically it is basing the decision on the expertise of the different AC
members, personal opinions, etc.



Regards,

Jordi

@jordipalet







El 26/1/21 15:03, "Fernando Frediani" <fhfrediani at gmail.com> escribi?:



Hello Jordi

I think that was a very good and detailed email.
There is however one point I differ on you: the decision taken by the AC
should be based on majority of votes of the members. Obviously they must
not take decisions based on personal opinions of the merit of the proposal
but on the facts and if all issues have been resolved.
Regarding the decisions between the 2 Co-Chairs I don't think the consensus
model applies there simply because there is not how to have a consensus
model applied between 2 persons. Either they both agree on something or
that cannot advance.

In resume: The consensus evaluation between 2 Co-Chair require both to
agree there was consensus. The consensus evaluation or analysis if the
Co-Chairs committed a mistake between all members of the AC is done via
majority and in this last case that doesn't exclude the eventual necessity
of explaining in details how every evaluation was taken for transparency
proposes. The consensus model applies only the community while the
proposals are being discussed and issues are being addressed.

Regards
Fernando

On 26/01/2021 07:50, JORDI PALET MARTINEZ via RPD wrote:

Hi Wafa, all,



First of all, don?t 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 doesn?t 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 don?t like it?. You need to
state ?I don?t 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.



Let?s go the details and I ask the Appeal Committee to respond to each of
the objections included and refuted in the Appeal Document:



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 can?t be a valid objection for the policy proposal.



2.       ?b. Revocation time of AS0 state, and the time for new allocation
doesn?t 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 don?t 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 can?t ?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 doesn?t 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 can?t be taken as a valid objection for the proposal.



3.       ?c. Other RIRs don?t 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 aren?t available
in other RIRs. That, clearly, doesn?t 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
can?t be taken as a valid objection against this policy proposal.



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 can?t 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, I?m 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.



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 doesn?t 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.



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 doesn?t 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

https://lists.afrinic.net/pipermail/rpd/2020/011348.html



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 that?s 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 doesn?t 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.



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, that?s the purpose of the proposal and RPKI,
increase the routing security, without making it mandatory for any
operator. Consequently, once more, this can?t be considered a valid
objection.



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
that?s the reason, even if we don?t 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 doesn?t 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 doesn?t 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 can?t be considered a valid objection, on the
other way around is a fundamental AFRINIC?s 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.pdf



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/attachment.html

>


------------------------------

Subject: Digest Footer

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd


------------------------------

End of RPD Digest, Vol 172, Issue 12
************************************



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.afrinic.net/pipermail/rpd/attachments/20210128/c89d2524/attachment.html

>


------------------------------

Subject: Digest Footer

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd


------------------------------

End of RPD Digest, Vol 172, Issue 15
************************************

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd


_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd
_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd


_______________________________________________ RPD mailing list
RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of
the individual(s) named above and further non-explicilty authorized
disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited and will be considered a criminal offense. If you are not the
intended recipient be aware that any disclosure, copying, distribution or
use of the contents of this information, even if partially, including
attached files, is strictly prohibited, will be considered a criminal
offense, so you must reply to the original sender to inform about this
communication and delete it.



-- 
Kind regards,

Paschal.



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.afrinic.net/pipermail/rpd/attachments/20210131/076ee860/attachment.html

>


------------------------------

Subject: Digest Footer

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd


------------------------------

End of RPD Digest, Vol 172, Issue 29
************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210131/5c69780b/attachment-0001.html>