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.

Job