[db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request

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-holders
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 at instituut.net>
 To: denis walker <ripedenis at yahoo.co.uk> 
Cc: Tim Bruijnzeels <tim at ripe.net>; Database WG <db-wg at 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


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20180111/7f1f2d3a/attachment.html>