On Tue, Mar 15, 2022 at 1:23 PM Randy Bush <randy@xxxxxxx> wrote: > > hi kyle > > > Can one of the authors cite a specific reference to the problem that > > this draft is trying to address? A written example of where this > > "false notion" exists? > > let be be lazy and quote the response to a similar question in an > artart review Heh... serves me right. I did read the artart review, but not any follow-ups. > a few years back, two of the co-authors of a lot of sidr rfcs, working > ... > yes, this is depressing and a bit shocking. sad to say, those terms can > be applied to a fair bit of RPKI deployment. Ok, so I appreciate the problem. I'm still not sure this is quite the right way to address it. This feels a bit too "protocol police"-ish to me. Publishing a new RFC to reiterate something that is already covered by an earlier spec in the hopes that it will deter willfulness seems like trying to fix something by repeatedly banging on it. Do we need a "No, we *really* mean it" track in the series? It seems like vigilance around implementations will be required either way. ISTM that the best way to address this particular problem is to make sure the folks in industries that develop RPKI implementations understand this, which probably means contacting them directly and pointing them at the existing text that already makes clear that this is a bad idea, whether in 6480 or in a mailing list archive someplace. To be clear, I don't feel *especially* strongly about this; I'm mostly just expressing skepticism of the degree of value in this approach. Kyle -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
