Dear all, On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
I feel sure that other IRRs have some or all of the same issues. RADB stands out however due to its continued widespread use.
The above statement is true, and the good news is that there is work under way to reduce the clutter! The largest IRRs (RADB, NTTCOM, ARIN, ALTDB, others) are either actively working on, or have added to their roadmap, a variant of this type of cleanup: https://www.ripe.net/publications/docs/ripe-731 For most of these IRR operators there is a project dependency on IRRd 4's ability to delete or suppress IRR "route:" objects that are in conflict with RPKI data. This is tracked in https://github.com/irrdnet/irrd4/issues/197 and hopefully the code can be made available in Q1 2020 as part of the "IRRd 4.1" release. This release in turn means for most organisations that they can probably deploy in Q2 or Q3 2020 (after internal software testing & customer outreach). Given that there is active work underway in the community - I would like to suggest that the topic of "stale data in IRRs" is brought up again in about 6 months. After the deployment of IRRd 4.1 we'll have a better view on what is still needs to be cleaned up and what mechanism can be used. Kind regards, Job