[db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request

Dear working group,

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:
1)    Remove the "origin:" authorization requirement
2)    Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.

We suggest the following solution as a basis for further discussion.

1) Remove the "origin:" authorization requirement

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.

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.

2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.

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”. 

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.

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.

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.

Kind regards

Tim Bruijnzeels
Assistant Manager Software Engineering and Senior Technical Officer
RIPE NCC

> On 19 Oct 2017, at 17:40, William Sylvester via db-wg <db-wg at ripe.net> wrote:
> 
> DB-WG Members,
>   
> 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.  
>   
> 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:
>   
> 1) Remove the "origin:" authorization requirement.
>  
> 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data.
>  
>   
> Thank you all for your work on this proposal!
>   
> Kind regards,
>   
> William & Denis
> DB-WG co-chairs
>