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]/
[anti-abuse-wg] [db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Previous message (by thread): [anti-abuse-wg] [routing-wg] [db-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [anti-abuse-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
denis
ripedenis at yahoo.co.uk
Wed Nov 11 19:04:00 CET 2015
Hi Sander On 11/11/2015 18:34, Sander Steffann wrote: > Hi Tim, > >>> STEP 3: continiously check if the block is allocated in the >>> foreign RIR database, if no longer, delete the route-object from >>> RIPE's IRR db. >> >> We share concerns raised by Job. We believe this adds a lot of >> complexity to the implementation, and introduces an unacceptable >> risk of deleting the wrong objects. Furthermore we believe that >> this step is not necessary if we implement step 5 (below). > > So what happens to route objects referring to de-registered stuff in > other databases? If nobody cleans it up manually we keep objects with > dangling pointers in our database? I understand that automatically > deleting them would be risky as e.g. an unexpected change in a remote > database might cause us to think the object has been deleted there > etc. Maybe a nice idea if all RIRs publish a timestamped list of > de-registered/reclaimed resources in a common format? :) Anyway: > maybe something to look into to prevent garbage from accumulating in > our own database. I think the main issue is when a resource is reclaimed and re-issued. If the previous registrant does not clean up the ROUTE object in the RIPE Database and the new registrant does not know it is there, it could dangle for a long time. Your suggestion of a reclaimed list would work but requires agreement from all 5 RIRs to be effective. That could take some time. Another simple option (which may not be 100% effective) is to do a daily check on the related resource objects. If they have been deleted and don't reappear within x days, delete the ROUTE object. If they do reappear notify the contacts that the ROUTE object exists. It may be a different resource holder. Again existing software can be reused for this. We don't have to invent anything from scratch. There is a system to check for unreferenced PERSON objects that runs every day. If an object has not been referenced for 90 days it is deleted. cheers denis > >> It will obviously require work. Very rough initial estimates >> indicate it can take up to a few months. We can refine these >> estimates if and when we have a clear consensus on a go-ahead. > > Thanks, always good to get an estimate from the authoritative source > ;) > > Cheers! Sander > >
- Previous message (by thread): [anti-abuse-wg] [routing-wg] [db-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
- Next message (by thread): [anti-abuse-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]