On Sun, Oct 14, 2018 at 11:32:44AM +0100, Nick Hilliard wrote: > Job Snijders wrote on 14/10/2018 07:48: > > When an operator makes a mistake, they've made a mistake. > > > When someone needs to create multiple ROAs, but only publishes one - it > > is an operator error. When one misconfigures things... they are > > misconfigured, no big deal. > > operator error happens all the time. In most cases, it's reversible > and life goes on.
Operators are free to create route/route6 objects in the appropriate validating IRR database. > As it stands, the proposal allows some types of operator error to > cause irreversible changes to their exterior routing policy, with no > notification or grace period. It may be that those changes are for > the better, but there will also be cases where it's for the worse. > The RIPE-NONAUTH data set contains garbage, but it also contains > plenty of accurate objects. Using RPKI data to purge RIPE-NONAUTH cleans up garbage. Are you suggesting that the RIPE-NONAUTH objects are more accurate than the RPKI ROAs (which semantically have a higher precedence)? We have *NO* idea who created the objects in the RIPE-NONAUTH database, we have no idea whether this was done with the consent of the resource owner. We *DO* know that any RPKI ROAs created through the 5 RIRs are created with the fully consent of the owner, why shouldn't that take precedent? > If this proposal does not provide a mechanism to notify holders of > conflicting route/route6 objects and provide a reasonable grace period > for sorting conflicts, then the proposal is harmful and should not > proceed. I disagree - the current situation is harmful. Leaving things as-is is damaging. Kind regards, Job
