[db-wg] RIPE-NONAUTH AS-SET bug fix
- Previous message (by thread): [db-wg] RIPE-NONAUTH AS-SET bug fix
- Next message (by thread): [db-wg] RIPE-NONAUTH AS-SET bug fix
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
denis walker
ripedenis at gmail.com
Fri Dec 16 10:29:50 CET 2022
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 at 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 at 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 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 > > >
- Previous message (by thread): [db-wg] RIPE-NONAUTH AS-SET bug fix
- Next message (by thread): [db-wg] RIPE-NONAUTH AS-SET bug fix
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]