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@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
>  


Reply via email to