Hi Arash For most issues we would not come to such a quick conclusion. But deleting ROUTE objects for unallocated address space seems to be a very non-contentious issue. Over this last year it has been difficult to get comments, feedback or any discussion on many issues. So I think two weeks (just before a RIPE Meeting) is a reasonable time frame for objections for this, and none were received.
cheers denis co-chair DB-WG On Fri, 7 May 2021 at 12:59, Arash Naderpour <arash.naderp...@gmail.com> wrote: > > I have no objection but it looks a bit weird to me to come to this quick > conclusion. > > Regards, > > Arash > > On Fri, 7 May 2021, 22:56 denis walker via db-wg, <db-wg@ripe.net> wrote: >> >> HI Ed >> >> As no one has objected I think we can assume you can go ahead with this plan. >> >> cheers >> denis >> co-chair DB-WG >> >> On Fri, 7 May 2021 at 09:20, Edward Shryane <eshry...@ripe.net> wrote: >> > >> > Hi Cynthia, Denis, >> > >> > Thanks for your feedback. I will plan to implement a cleanup job without >> > an NWI, and will keep the DB-WG informed. >> > >> > Regards >> > Ed Shryane >> > RIPE NCC >> > >> > On 25 Apr 2021, at 13:03, Cynthia Revström <m...@cynthia.re> wrote: >> > >> > imo an NWI seems unnecessary unless we want it for purposes of referencing >> > back to in the future. >> > >> > -Cynthia >> > >> > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg@ripe.net> wrote: >> >> >> >> Colleagues >> >> >> >> How do you want to proceed with this suggestion? Do we have support >> >> for deleting these ROUTE(6) objects for deregistered space and where >> >> the objects were created before registration? Does anyone have any >> >> objections to this as an ongoing cleanup? >> >> >> >> Do we even need an NWI or can we just ask the NCC to go ahead with it? >> >> >> >> cheers >> >> denis >> >> co-chair DB-WG >> >> >> >> On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg@ripe.net> >> >> wrote: >> >> > >> >> > Dear colleagues, >> >> > >> >> > In response to the recent discussion on "196.52.0.0/14 revoked, cleanup >> >> > efforts needed", I'd like to propose a regular automated cleanup of >> >> > route(6) objects in the RIPE-NONAUTH database using unregistered space. >> >> > >> >> > Regards >> >> > Ed Shryane >> >> > RIPE NCC >> >> > >> >> > >> >> > >> >> > Problem Definition >> >> > ------------------ >> >> > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects >> >> > in the RIPE-NONAUTH database using that address space are not cleaned >> >> > up (deleted). >> >> > >> >> > >> >> > Solution Definition >> >> > ------------------- >> >> > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH >> >> > database against the combined delegated stats from all RIRs. >> >> > >> >> > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs >> >> > delegated stats should remain in the RIPE NONAUTH database. If a prefix >> >> > is "available" or "reserved" then it is considered to be unregistered, >> >> > and any associated route(6) objects will be eligible for deletion. >> >> > >> >> > If a prefix is partially "available" or "reserved" then it is also >> >> > considered to be unregistered. >> >> > >> >> > If a prefix is not listed in any RIRs delegated stats, that prefix is >> >> > skipped. >> >> > >> >> > The origin AS status is not considered, only the IPv4/IPv6 prefix. >> >> > >> >> > If a newly unregistered prefix is discovered, first allow a grace >> >> > period of 1 week. This allows time for mistakes in the delegated stats >> >> > to be corrected. >> >> > >> >> > After 1 week, contact the route(6) maintainer(s) to notify them that >> >> > the route(6) object will be deleted. >> >> > >> >> > After a further 2 weeks, delete the route(6) object. >> >> > >> >> > A maintainer can request the RIPE NCC to exclude a route(6) prefix from >> >> > deletion (for example, the deregistration of the prefix is being >> >> > disputed). For any excluded prefixes, any associated route(6) objects >> >> > will not be deleted. >> >> > >> >> > >> >> > Impact Analysis >> >> > ------------------ >> >> > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH >> >> > database using a prefix with status "available" or "reserved" in an >> >> > RIRs delegated stats, which will be eligible for deletion. >> >> > >> >> > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH >> >> > database using a prefix with status "available" or "reserved", so also >> >> > eligible for deletion. >> >> > >> >> > There are approximately 64 routes and 37 route6's with a prefix not >> >> > listed in any RIR's delegated stats. These will not be affected. >> >> > >> >> > When this cleanup is implemented, the backlog of route(6) objects >> >> > eligible for deletion will be processed at the same time, leading to a >> >> > large amount of emails to affected maintainers. Once this backlog is >> >> > processed, the number of route(6) objects affected is expected to be >> >> > low. >> >> > >> >> > >> >> > >> >> >> > >>
