This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
- Previous message (by thread): [db-wg] [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
- Next message (by thread): [db-wg] Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Schmidt
mschmidt at ripe.net
Tue Jan 26 15:43:06 CET 2021
Dear Nick, Thanks for your email. We are planning a clean-up of these ROUTE objects. As we wanted to avoid deleting any legitimate objects of third parties, we checked with AFRINIC and they have now confirmed that these ROUTE(6) objects can be deleted. We also performed a check on all of the NONAUTH database for any ROUTE(6) objects (using the prefix only), we found 81 routes (out of 56,379) and 37 ROUTE6 (out of 1,568) that are not "allocated", "assigned", "available", "reserved" in any region. We will now inform the object holder and remove these objects. We don’t think a policy is necessary for this work, but we strongly believe we need an approach similar to NWI-5: "Inform the object holder that these IRR object(s) refer to an unallocated space. We will then delete them after a reasonable notification." This gives people time to react in cases of incorrect de-registration. We will initiate a discussion with the other RIRs to find a joint approach on how we deal with similar incidents in the future. We have also looked into publishing a list of deregistered resources and this will require some review internally if we plan to go down that route. A more straightforward approach might be for the RIRs to proactively highlight where we see objects in each others IRRs. Kind regards, Marco Schmidt Registry Services Assistant Manager RIPE NCC > From: *Nick Hilliard via db-wg* <db-wg at ripe.net <mailto:db-wg at ripe.net>> > Date: Fri, Jan 22, 2021, 17:21 > Subject: Re: [db-wg] [anti-abuse-wg] 196.52.0.0/14 > <http://196.52.0.0/14> revoked, cleanup efforts needed > To: Niall O'Reilly <niall.oreilly at ucd.ie <mailto:niall.oreilly at ucd.ie>> > Cc: Database WG <db-wg at ripe.net <mailto:db-wg at ripe.net>>, Mirjam > Kuehne <chair at ripe.net <mailto:chair at ripe.net>> > > > Niall O'Reilly wrote on 22/01/2021 09:55: > > Creating a policy seems to me to be too heavy an approach in this case. > > > > I would think that a simple request from the DB WG to the NCC > > should be enough. > > > > If a greater degree of formality were considered necessary, > > a new NWI could be created. > > there are two issues here: the immediate one relates to removal of these > particular objects, but there's a longer term issue of whether the NCC > needs to be asked by the community to delete all objects which are > deregistered from the other LIRs on an ongoing basis. Honestly I would > have thought probably not because this sounds like the sort of thing > that falls into general garbage cleanup, i.e. normal stewardship of > resources. > > Could someone from the NCC clarify what the current situation with this > is? Is this something which is currently dealt with, and if not, could > it be? > > The reverse is also relevant. I.e. the RIPE NCC probably needs to > publish lists of resources which have been deregistered so that other > RIRs / IRRDBs can delete objects which refer to those resources which > date from before the date of deregistration. > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/db-wg/attachments/20210126/9515666f/attachment.html>
- Previous message (by thread): [db-wg] [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
- Next message (by thread): [db-wg] Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]