Hi Job Unless it has been modified recently there is the reclaim functionality that will allow the resource holder to delete the ROUTE(6) object.https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holde... But this does rely on the new resource holder knowing the 'potentially rogue' ROUTE(6) object exists. So maybe it is down to a procedural or administrative issue around the transfer process. cheersdenisco-chair DB WG From: Job Snijders <job@instituut.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: Tim Bruijnzeels <tim@ripe.net>; Database WG <db-wg@ripe.net> Sent: Thursday, 11 January 2018, 0:42 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request Hi Tim, Denis, On Wed, Jan 10, 2018 at 11:33:10PM +0000, denis walker via db-wg wrote:
I just noticed the comment below:"In case of inter-RIR transfers of live networks, ROUTE(6) objects are sometimes preserved for the transferred prefix(es). If so, they will be moved between the ‘RIPE’ and ‘RIPE-NONAUTH’ sections according to the direction of the transfer." Does this mean if a prefix is transferred into the RIPE region which currently has a ROUTE(6) object with the source 'RIPE-NONAUTH' this object will be re-tagged with the source 'RIPE'? If so are we giving a label of legitimacy to an object that was not properly authenticated?
I think Denis spotted a potential process bug here indeed. When a prefix moves from non-RIPE to RIPE managed, and a (partially) covering object exists in the RIPE DB, I think a number of things come to mind: a) the 'source:' tag should not change until the owner confirms that the route object is what it should be. (Of course the RIPE software can facilitate this as a step in the transfer process, in the majority of cases the 'route:' object is likely to need an update') b) if the prefix becomes RIPE managed space, the owner should have the ability to nuke whatever 'route:' objects exist in the RIPE DB with 'source: RIPE-NONAUTH' - even if the 'new' owner isn't a maintainer. I think a lot here comes down to good UI design and clear communication from RIPE NCC's systems to the end user to help conver/transition those 'nonauth' route objects into something that was sanctioned by the owner. Kind regards, Job