[db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database

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
>
>