Colleagues The chairs agree that we have a consensus on making this change and regarding it as a bug fix on the implementation of NWI-5. We therefore ask the RIPE NCC to implement this bug fix when it is convenient to fit it into their development plans. It can be done in two stages: 1/ Creating any new AS-SET object authorised by an ASN in RIPE-NONAUTH will also have the source RIPE-NONAUTH 2/ Any existing AS-SET object that was created with authorisation by an ASN in RIPE-NONAUTH will have it's source changed to RIPE-NONAUTH cheers denis and William co-chairs DB-WG On Wed, 14 Dec 2022 at 12:12, denis walker <ripedenis@gmail.com> wrote:
Colleagues
Just a quick reminder in case you missed the previous email. Looks like no one has any objections...
cheers denis co-chair DB-WG
On Thu, 8 Dec 2022 at 16:43, denis walker <ripedenis@gmail.com> wrote:
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