<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Tahoma">Hi all.<br>
<br>
TL;DR - I do not support this policy proposal.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Suggest we focus our efforts on actually getting RPKI more widely
deployed. A case of "crawl before we can run", type-thing. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Mark.<br>
</font>
</body>
</html>