[db-wg] RIPE-NONAUTH AS-SET bug fix

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 at 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
>