<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1515543859309_89948">Hi Job</div><div id="yui_3_16_0_ym19_1_1515543859309_89942"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89854">Unless it has been modified recently there is the reclaim functionality that will allow the resource holder to delete the ROUTE(6) object.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89852"><a href="https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holders" id="yui_3_16_0_ym19_1_1515543859309_89938">https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holders</a></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89850"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89876">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.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89917"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89940">cheers</div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89950">denis</div><div dir="ltr">co-chair DB WG</div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89952"><br></div><div id="yui_3_16_0_ym19_1_1515543859309_89812"><span></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1515543859309_89813"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1515543859309_89817" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1515543859309_89816"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1515543859309_89815"> <div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_89814"> <font id="yui_3_16_0_ym19_1_1515543859309_89819" face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Job Snijders <job@instituut.net><br> <b><span style="font-weight: bold;">To:</span></b> denis walker <ripedenis@yahoo.co.uk> <br><b><span style="font-weight: bold;">Cc:</span></b> Tim Bruijnzeels <tim@ripe.net>; Database WG <db-wg@ripe.net><br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, 11 January 2018, 0:42<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1515543859309_89821"><br>Hi Tim, Denis,<br clear="none"><br clear="none">On Wed, Jan 10, 2018 at 11:33:10PM +0000, denis walker via db-wg wrote:<br clear="none">> I just noticed the comment below:"In case of inter-RIR transfers of<br clear="none">> live networks, ROUTE(6) objects are sometimes preserved for the<br clear="none">> transferred prefix(es). If so, they will be moved between the ‘RIPE’<br clear="none">> and ‘RIPE-NONAUTH’ sections according to the direction of the<br clear="none">> transfer." Does this mean if a prefix is transferred into the RIPE<br clear="none">> region which currently has a ROUTE(6) object with the source<br clear="none">> 'RIPE-NONAUTH' this object will be re-tagged with the source 'RIPE'?<br clear="none">> If so are we giving a label of legitimacy to an object that was not<br clear="none">> properly authenticated? <br clear="none"><br clear="none">I think Denis spotted a potential process bug here indeed. <br clear="none"><br clear="none">When a prefix moves from non-RIPE to RIPE managed, and a (partially)<br clear="none">covering object exists in the RIPE DB, I think a number of things come<br clear="none">to mind:<br clear="none"><br clear="none"> a) the 'source:' tag should not change until the owner confirms that<br clear="none"> the route object is what it should be. (Of course the RIPE software<br clear="none"> can facilitate this as a step in the transfer process, in the<br clear="none"> majority of cases the 'route:' object is likely to need an update')<br clear="none"><br clear="none"> b) if the prefix becomes RIPE managed space, the owner should have<br clear="none"> the ability to nuke whatever 'route:' objects exist in the RIPE DB<br clear="none"> with 'source: RIPE-NONAUTH' - even if the 'new' owner isn't a<br clear="none"> maintainer.<br clear="none"><br clear="none">I think a lot here comes down to good UI design and clear communication<br clear="none">from RIPE NCC's systems to the end user to help conver/transition those<br clear="none">'nonauth' route objects into something that was sanctioned by the owner.<div class="yqt5048799730" id="yqtfd49106"><br clear="none"><br clear="none">Kind regards,</div><br clear="none"><br clear="none">Job<div class="yqt5048799730" id="yqtfd37812"><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>