[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

[Nishal Goburdhan]

On 14 Jun 2021, at 22:24, Korsback, Fredrik via RPD wrote:


hello, and welcome,

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

makes me think of a cigarette analogy that was earlier mentioned..  :-)
but anyway..


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

could you please explain *how* the AS0 TAL adds to the complexity of 
_deploying_ RPKI in these networks, especially if the TAL is optional.
presumably, if you _opt_ to use this, you:
# know what a TAL is, and/or
# have been warned, and/or
# been taught, and/or
# self-selected to install this ..

one would hope that, if you took the effort to install this 
intentionally, you have read the installation screen text :-)


> Why would a RIR accept this increased liability in what they are 
> delivering for their customers? For not apparent upside

you can’t premise an argument on the basis of “why would someone 
else do this?”.  people think differently.  sure, there are non-zero 
risks attached to this, yes.  but it’s smarter to highlight and 
explain those risks;  as job did, when he pointed to a failure situation 
when going from ALLOCATED -> UNALLOCATED with no intermediate step.  
understanding that risk, and proposed mitigation if at all applicable - 
is what this working group needs to identify if this policy should pass 
or not.


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

i think you missed the other thread, and perhaps the earlier DBWG 
meetings where afrinic laid out that this is happening separately.


> We, will not implement this AS0 TAL, nor any other AS0 TAL.

as is your right  :-)

but if frank wants to use it, then we really need a better argument than 
“$ is not doing it, and therefore you shouldn’t”.  i appreciate 
that you have a wildly different perspective, and experience, and as a 
working group, we would benefit more if you could use that perspective 
and experience, and point to (a) failure case scenario(s) that is/are of 
concern, that have/has been missed in the discussion.

-n.