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