Thanks for the background Nick! Based on the e-mails I think the discussion is against taking action for members doing sketchy things. This is why I tried to steer this conversation towards improving the existing policy for quarantine and cleanup. We can work towards that area perhaps later.
In order to better quantify the problem, I did the following: I downloaded the aut-num RIPE DB and extracted the ASNs “created:" at or after 2026-01-01: https://paste.daknob.net/paste/sT3PHRS3faki60C_gukxF6YEU5m_uvxNwN8oDco4raQ They were 200 and it looks like 3 lucky people got 4-digit ASNs! I then used `monocle` to check for all of the ROAs of each AS that existed one day before its assignment. This is 24-48 hours *before* the end user knew which AS number they had. I think that’s a good way to capture which ROAs are leftovers from previous use. I ended up with this: https://paste.daknob.net/paste/H9HYA6DQx0xyRyPpLAY9FYp9XhEzwDzmpsCotHdAwVk I think empty “TA” is almost always RIPENCC because I used RIPE’s archives for this. You can find 96 ROAs for 36 ASNs. That means 18% of assigned ASNs come with stale ROAs. We may not be able to do much about non-RIPE ROAs but we can at least make sure that these are cleaned up. Almost 1 in 5 ASNs we assign comes with free IPv4 now ;) Would it make sense to have a policy, for example, that doesn’t allow (the creation / maintenance of) ROAs for ASes within RIPE’s pool that are currently unassigned? If this runs daily it can detect ROAs and then perhaps notify the IP resource holders. It can only work for the hosted RPKI in the beginning. Antonis > On 29 Jan 2026, at 13:14, Nick Hilliard <[email protected]> wrote: > > Peter Hessler wrote on 29/01/2026 08:25: >> Hi Antonis, >> (speaking as a member of the WG, not Co-Chair) >> Yes, I think it would be appropriate for the NCC to delete those objects >> from the RIPE database when they are returned to the NCC. > > Hi Peter, Antonis, > > This discussion comes up from time to time - the last time was in August 2024: > >> https://mailman.ripe.net/archives/list/[email protected]/thread/W2ZU43PFH4LOMKQL4V4OBLWPAGBICJK7/ > > I agree that there's an issue here that needs to be resolved. We recently > had a issue with fraudulent reference of INEX resources, and opened up a > ticket with the NCC due to inaction from the organisation that executed the > registration. The issue has now been resolved, but the NCC staff member (hi!) > handling the ticket pointed out that their hands are tied, and provided a > link to this email from the board a couple of years back: > > https://www.ripe.net/ripe/mail/archives/db-wg/2018-August/005989.html > > In other words, a change of policy is needed to allow the RIPE NCC to do > this. I.e. this is an issue for the community to resolve. > > Nick > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the > email matching your subscription before you can change your settings. More > details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
