Search RPD Archives
[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.
mark.tinka at seacom.com
Fri Jun 11 16:49:26 UTC 2021
TL;DR - I do not support this policy proposal.
The purpose of this proposal is to give operators another method to
identify routes they should either ignore or filter from their routing
domain. It is, already, feasible to do this using the data available
from the AFRINIC WHOIS database. Implementing this policy does present
the potential to introduce some risk in the RPKI system operated by
AFRINIC. On the basis that the use of this policy is largely optional, I
am not convinced that the additional risk to the AFRINIC infrastructure
- and the folk who rely on it - outweighs the benefit.
Getting RPKI out there is already significantly challenging. Personally,
I would spend more time and energy on that, before we try to complicate
it with a policy proposal such as this.
I am less-than-interested in what the other RIR's have decided to do or
not to do with similar policy proposals within their regions. Speaking
purely with an African bias, I do not see how this proposal moves the
RPKI needle forward in a meaningful and impactful way. For me, it's a
nice-to-have, for which solutions that are well-documented are already
in sufficient existence. I'd prefer that we did not encourage thought
processes that could turn RPKI into a loaded gun that may very well lead
to unintended consequences.
Suggest we focus our efforts on actually getting RPKI more widely
deployed. A case of "crawl before we can run", type-thing.
I tend to prefer achieving the objective with the least amount of
effort. If it were up to me, the only command a router would ever need
is "on", but alas! Pushing multiple TAL's from a single RIR will only
escalate the confusion surface area, which is more than likely to have a
negative impact on the progression of deployment of a global RPKI, or
worse, mis-deployment that may be touted as a BCP for generations to come.
A policy such as this could set a precedent for significantly more
(well-intentioned, but) disastrous use-cases for the RPKI. I'd err on
the side of avoiding situations where centralized control of gratuitous
blackouts of part or all of the Internet, on purpose or by mistake, are
not given roots to emerge. Keeping the genie in the bottle is, for me,
far better than thinking you can cage it once it has been set free.
AS0 is unlikely to help me stop paying the annual subscription for my
anti-spam and anti-virus system. If there is some other practical
problem - for which a solution currently does not exist - that this
policy proposal is looking to fix, I'd be most obliged to hear it. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD