This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
- Previous message (by thread): [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
- Next message (by thread): [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at instituut.net
Thu Jan 11 00:42:36 CET 2018
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
- Previous message (by thread): [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
- Next message (by thread): [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]