Colleagues There is some support for the idea that if AUT-NUM objects in RIPE-NONAUTH authorise the creation of AS-SET objects, these set objects will also be in RIPE-NONAUTH. There is also support for this to be considered as a bug from the implementation of 'NWI-5 Out of region ROUTE(6)/AUT-NUM objects'. So existing AS-SET objects whose creation was authorised by one of these RIPE-NONAUTH ASNs can be moved to RIPE-NONAUTH as part of a bug fix. Does anyone have any objections to such a 'bug fix'? cheers denis co-chair DB-WG On Thu, 1 Dec 2022 at 19:34, Nick Hilliard <nick@foobar.org> wrote:
Cynthia Revström wrote on 30/11/2022 22:59:
I am not sure if this feature is used or not however I think this is a very good reason to not go forward with a clean-up (at least until we have properly evaluated things). We will probably have to figure out some other way to deal with objects that are currently causing issues I think.
the "feature" is used, yes. Some providers have customers in different RIR service regions. Some organisations have address space registered in different RIR service regions. It's impossible to avoid in many situations.
What's important right now is to close off the option to create new unqualified as-set names, and to move the existing qualified non-RIPE ASxxxx:as-set objects from source: RIPE to source: RIPE-NONAUTH.
Denis was correct that this was a bug during the implementation of NWI-5 (not ripe-731 which I mistakenly quoted).
After that, we can afford to spend a bit of time looking at potential clean-up options. There are 1590 empty as-set objects. 700 of these haven't been updated in the last 5 years, and some going back 20 years.
I wouldn't lose too much sleep about deleting empty as-sets. Contact people, set a timeout, and then delete. Worst case, people can reference new, qualified as-sets.
Nick