Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Fernando Frediani fhfrediani at
Thu Jan 28 12:55:02 UTC 2021

Very good email Frank !
That's it. It is a tool and people looking after routing in
organizations are free to use or not.

I encourage everyone, specially those who feared and objected this
proposal to read carefully the message below in order to understand the


On 28/01/2021 03:10, Frank Habicht wrote:

> Hi,


> in my opinion AfriNIC is providing a tool here. RPKI.


> Where "owners" of IP address space can publish statements about which

> ASNs are allowed to originate advertisements of a given address space

> (or subnets). These statements are organised so that computers and

> routers can confirm authenticity of the statement - with a certificate

> chain from a trust anchor.


> That's the tool.


> Network engineers *can* use the *tool* then to make routing decisions.

> One of the things that is generally considered useful among network

> engineers is the decision to refuse/drop all advertisements that

> correspond to "INVALID" RPKI information.


> That's the network engineer's decision. Not AfriNIC's.


> All of the above is the status quo. Existing now.


> Like some others I'm responsible for some IP space.

> Some of this is IXP peering LANs [unnecessary detail] and I want

> everyone to know that this should never be advertised and seen on the

> Internet. Also through RPKI.


> So I published a ROA with AS0.

> So everyone who wants their routers to make routing decisions based on

> RPKI data will also get this information from me that

> should not be accepted.


> Now:


> AfriNIC is also responsible for some address space.

> We know from experience that address space held at RIRs is sometimes

> advertised and used by spammers and other "bad actors".

> I don't want this to happen that easily.


> Why should AfriNIC not have the ability to publish information in a tool?

> The routing decisions are with the network engineers.

> If they want (yes, not scalable) they could tell the routers to fist

> accept a certain prefix, and then apply RPKI filtering - not sure why

> anyone would do that, but technically possible.


> There could also be tweaks applied in the validators.


> We could also ask AfriNIC to publish the ROAs for AfriNIC-held IPs with

> AS0 under a separate trust anchor. We could even leave that decision to

> AfriNIC staff - ie we allow them to do any of these two options.


> In that case the network engineers can make the informed decision

> whether to use the second trust anchor or not.


> Still: AfriNIC would be publishing information in a tool. Like I am

> publishing information in the same tool.


> Routing decisions are made by the network engineers.

> I believe that many would like to have that information in RPKI so that

> they can automatically reject advertisements of


> And what changes?

> before: network engineers decide to not accept routing information where

> the older of the address space stated that it should not be seen on the

> internet

> after this policy: network engineers decide to not accept routing

> information where the older of the address space stated that it should

> not be seen on the internet


> I believe AfriNIC have a responsibility to use the tool to avoid

> spamming and abuse through "misoriginations" of IP address space that

> AfriNIC is responsible for.


> PS: disputes.

> In case there is a dispute about address space, AfriNIC already have the

> same kind of control over IRR data like route objects.

> The root cause is the dispute and it needs to get resolved - not the

> publishing of information in a tool.



> Thanks,

> Frank

> co-author



> On 27/01/2021 17:47, Anthony Ubah wrote:

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





> _______________________________________________

> RPD mailing list

> RPD at


More information about the RPD mailing list