>> 1. Removing the ROAs is a problem in terms of increased risk, which is a >> problem which needs to be addressed. > > I never argued with addressing the risks that might be posed; I was pointing > out that the risk does not equate (on its own) with a reachability event, as > alluded to by the paper.
That all depends on the policy undertaken by each specific provider, doesn't it? How can you tell the difference between a route with no ROA because the registry has decertified, and a route with no ROA simply because one hasn't ever been created? If the registries issue "negative ROAs," for all the address space they own, doesn't that immediately break anyone who doesn't participate? It seems, to me, that there's a problem in here that's likely to bite someone in the butt once things really start to deploy (if they ever really do start to deploy). But, it's fine, we can put our fingers in our ears, say, "lalalala" as loud as possible, and hope it's not "me" who gets the first crack as being bitten by this particular bug. As Danny said --this is a salient point in the conversation. I'll extend that to say that if I were a provider, this would be a salient point in my decision about deploying --or not-- this mechanism. :-) Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
