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