<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_54614"><span>Hi Tim</span></div><div><span><br></span></div><div id="yui_3_16_0_ym19_1_1515543859309_54675"><span>I just noticed the comment below:</span></div><div id="yui_3_16_0_ym19_1_1515543859309_54677" dir="ltr"><span id="yui_3_16_0_ym19_1_1515543859309_54682">"</span><span id="yui_3_16_0_ym19_1_1515543859309_54683">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."</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54699"><span id="yui_3_16_0_ym19_1_1515543859309_54683"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54771"><span id="yui_3_16_0_ym19_1_1515543859309_54683">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?</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54816"><span id="yui_3_16_0_ym19_1_1515543859309_54683"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54844"><span id="yui_3_16_0_ym19_1_1515543859309_54683">cheers</span></div><div dir="ltr"><span id="yui_3_16_0_ym19_1_1515543859309_54683">denis</span></div><div dir="ltr"><span id="yui_3_16_0_ym19_1_1515543859309_54683">co-chair DB WG<br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1515543859309_54615"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1515543859309_54627" 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_54626"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1515543859309_54625"> <div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54624"> <font id="yui_3_16_0_ym19_1_1515543859309_54630" face="Arial" size="2"> <hr id="yui_3_16_0_ym19_1_1515543859309_54629" size="1"> <b><span style="font-weight:bold;">From:</span></b> Tim Bruijnzeels via db-wg <db-wg@ripe.net><br> <b><span style="font-weight: bold;">To:</span></b> Database WG <db-wg@ripe.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, 5 December 2017, 10:12<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_54633"><br><div dir="ltr" id="yui_3_16_0_ym19_1_1515543859309_54635">Dear working group,<br clear="none"><br clear="none">We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5. It was suggested that the proposal should follow the suggestions done in the problem definition phase and focus on:<br clear="none">1) Remove the "origin:" authorization requirement<br clear="none">2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.<br clear="none"><br clear="none">We suggest the following solution as a basis for further discussion.<br clear="none"><br clear="none">1) Remove the "origin:" authorization requirement<br clear="none"><br clear="none">ROUTE(6) Objects can be created as authorised by matching or overlapping INET(6)NUM, or ROUTE(6) objects, but authorisation by the AUT-NUM in the “origin:” attribute is no longer required. This means these objects will be created immediately, and the ‘pending object creation’ that is currently in place can be removed. This will allow us to simplify the core whois code as well as provide users with an easier user interface to manage their ROUTE(6) objects and compare these objects to the actual announcements done in BGP - similar to the interface currently provided to manage ROAs.<br clear="none"><br clear="none">Furthermore, the "mnt-routes:" attribute on AUT-NUM objects will no longer be useful. We propose that the attribute is deprecated and removed from existing objects (of course with notification to the object holders). Finally, there will be no more need for the existence of out-of-region AUT-NUM objects in the RIPE database. We propose that these objects will be deleted.<br clear="none"><br clear="none">2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.<br clear="none"><br clear="none">ROUTE(6) Objects referring to a prefix in RIPE managed space will retain "source: RIPE”. ROUTE(6) Objects referring to a prefix outside of RIPE managed space will be moved out of the RIPE Database into a new source hosted by RIPE NCC, and will have "source: RIPE-NONAUTH”. <br clear="none"><br clear="none">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.<br clear="none"><br clear="none">If ‘--sources' is used in queries out-of-region resources will be shown only if ‘RIPE-NONAUTH’ is included explicitly. If no source is defined we propose that both "source: RIPE" and “source: RIPE-NONAUTH” ROUTE(6) objects are returned. We expect that otherwise existing scripts used to generate filter lists will no longer see the out-of-region ROUTE(6) objects, and that this will lead to unacceptably large number of issues. Operators can opt-in to discarding objects that use “source: RIPE-NONAUTH” in these scripts, or modify them to use “--sources RIPE” explicitly.<br clear="none"><br clear="none">From our point of view these changes are not hard to implement on the core whois software, and removing the “origin:” authorisation requirement in particular will allow us to simplify things which will improve maintainability and allow for an easier user interface. That said, we know that there have been different opinions on the feasibility of this in the past, so we encourage the working group to discuss this.<br clear="none"><br clear="none">Kind regards<br clear="none"><br clear="none">Tim Bruijnzeels<br clear="none">Assistant Manager Software Engineering and Senior Technical Officer<br clear="none">RIPE NCC<br clear="none"><div class="yqt9832226628" id="yqtfd92459"><br clear="none">> On 19 Oct 2017, at 17:40, William Sylvester via db-wg <<a shape="rect" ymailto="mailto:db-wg@ripe.net" href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br clear="none">> <br clear="none">> DB-WG Members,<br clear="none">> <br clear="none">> Support was shown for the proposal NWI-5 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-5 as described. <br clear="none">> <br clear="none">> This request is to remove “origin:” and flag “route:” objects as specified. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem solution of NWI-5 as follows:<br clear="none">> <br clear="none">> 1) Remove the "origin:" authorization requirement.<br clear="none">> <br clear="none">> 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.<br clear="none">> <br clear="none">> <br clear="none">> Thank you all for your work on this proposal!<br clear="none">> <br clear="none">> Kind regards,<br clear="none">> <br clear="none">> William & Denis<br clear="none">> DB-WG co-chairs<br clear="none">> <br clear="none"><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>