this change means that NTT's IRR mirror service will now use RPKI Validated ROAs to filter out invalid IRR objects! This filtering strategy is similar to RIPE-731.

Creation of RPKI ROAs will trigger deletion of conflicting IRR objects, this helps clean up stale objects. Existing RPKI ROAs help prevent future creation of unauthorized IRR objects.

cool! what stands between my current world and when i can remove my irrd instance and when i can remove (which) objects from the ripe whois? < psa > 15-20 years back, when designing early rpki deployment, folk wanted the irr to be equally if not more authoritative than the rpki. trust what you are already familiar with. some where downright rabid about irr / whois rulz. the pendulum swings. while i confess to helping to create this rpki origin validation thingie, i would warn that it is pretty rigid. notice how many xnog threads we see about broken dnssec or just dns meaning my.mtv is mot reachable? this is analogous, except it is at the routing layer. recommended actions: get your roas correct and monitor their correctness use an external service which ensures your roa data are propagating correctly globally use reliable and correct relying party softweare; there is crap out there monitor your routers to ensure that they are getting current relying party data familiarize your noc and engs with a toolset to provide assurance of and debug all of the above i am sure there are more things to do; and hope that wiser folk will expand, comment, and correct. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery