<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I feel that some people have some a bigger fear of something that
requires a chain of mistakes to happen and are not willing to take
any risks even in the aim to improve things.<br>
Some examples that have been given in this discussion (although
late as we are already in the last-call) seems rather simplistic
as if a push of single button would lead to a regional or global
Internet disaster.<br>
<br>
I think most people understand the difference between a ROA issued
by a resource holder and a ROA issues by a RIR for unallocated
space. Although RIR staff didn't detail, I find hard to believe
they will implement change processes that even with double checks
could easily lead to theoretical situations as mentioned. Also
once done for first time all the unallocated space for that RIR
the further adjustments and issues of AS0 ROA will only happen on
2 situations: 1) When some IP space is recovered 2) When IANA
allocates new space to the RIR (rarely then). In both cases the
issue of these ROAs can be done in a more simple and safe way and
more specifically.<br>
<br>
One of the upsides of this policy is to make sure organizations
will not be able to use IP space that is not allocated to it,
damage it and make it bad for a future member who receives it.<br>
Finally I am glad to see that organizations will have the option
to implement and use AS0 TAL in their infrastructure. I guess that
was one of the good points out of the proposal: to leave each one
free to choose whatever their prefer.</p>
<p>Regards<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 14/06/2021 17:24, Korsback, Fredrik
via RPD wrote:<br>
</div>
<blockquote type="cite"
cite="mid:98A81132-FBFA-4D98-94E2-443FB14DE780@amazon.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">I’ll +1 Mark here.
<br>
<br>
TL;DR - I do not support this policy proposal either. <br>
<br>
Context: AWS (AS16509) does RPKI-OV in thousands of routers
over hundreds of sites in every single corner of the world,
we have 99% coverage of ROAs on our resources and have
implemented RPKI as an integral process in for example
Bring-Your-Own-IP (BYOIP) Operations.
<br>
<br>
We, and everyone else, have designed our RPKI infrastructure
to *<b>always</b>* fail open. This is absolutely crucial to
our operations and for the safety of our network and our
customers This proposal suggest a solution which *could*
lead to the opposite, almost in a non-recoverable way. We
have already today seen examples where ROAs has been revoked
due to the fact that there has been error in the billing
process. Imagine that error, or any other similar error,
that would automatically create AS0 ROAs for space can be
disastrous. Moving away from the sentiment that a ROA always
comes from the *<b>customer</b>* of an RIR, is a very
slippery slope just in general (That I believe others have
already pointed out in detail what it could be and lead to).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"
lang="EN-US">The benefit on the other side I see as
slim-to-none. Looking at the already implemented AS0 TAL in
APNIC for example it comes with a great deal of
warning-signs and “do not use” labels attached to it
already, who in their right mind would use it? I spend a
large portion of my days to educate and inspire, especially
small ISPs in the world, to implement RPKI and other
routing-security related features, why would people
implement this? Especially since RPKI is hard-enough as it
is to get going in some networks. I can’t see the reason
for this increase in complexity and “if and buts” <br>
<br>
Why would a RIR accept this increased liability in what they
are delivering for their customers? For not apparent upside<br>
<br>
I do appreciate the effort to look for solutions for
spoofers/squatters and whatnot, but I don’t see RPKI as the
right tool to use for this but rather a One-Way door to
something we cannot change later. I much rather see the
money, time, effort and cycles to be spent on increasing
operational stability for RPKI, better APIs, better GUI and
better supporting features for lowering the bar of entry
into RPKI, not specific to AFRINIC per say but for everyone.
<br>
<br>
We, will not implement this AS0 TAL, nor any other AS0 TAL.<br>
<br>
/Fredrik @ AWS Networking <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">Mark Tinka
<a class="moz-txt-link-rfc2396E" href="mailto:mark.tinka@seacom.com"><mark.tinka@seacom.com></a><br>
<b>Organisation: </b>SEACOM<br>
<b>Date: </b>Friday, 11 June 2021 at 18:51<br>
<b>To: </b><a class="moz-txt-link-rfc2396E" href="mailto:rpd@afrinic.net">"rpd@afrinic.net"</a> <a class="moz-txt-link-rfc2396E" href="mailto:rpd@afrinic.net"><rpd@afrinic.net></a><br>
<b>Subject: </b>RE: [EXTERNAL] [rpd] Last Call - RPKI
ROAs for Unallocated and Unassigned AFRINIC Address Space
AFPUB-2019-GEN-006-DRAFT03.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<table class="MsoNormalTable" style="border-collapse:collapse"
cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr style="height:15.25pt">
<td style="width:842.35pt;border:solid #ED7D31
1.5pt;padding:0cm 5.4pt 0cm 5.4pt;height:15.25pt"
width="1123" valign="top">
<p><strong><span
style="font-family:"Calibri",sans-serif;color:black;background:#FFFF99">CAUTION</span></strong><span
style="color:black;background:#FFFF99">: This
email originated from outside of the organization.
Do not click links or open attachments unless you
can confirm the sender and know the content is
safe.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span
style="font-family:"Tahoma",sans-serif">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.</span><o:p></o:p></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>