[db-wg] Implementation plan and dates for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.

Dear Job, DB-WG,

we plan to return objects from both the RIPE and RIPE-NONAUTH sources for NRTM, as it will be less disruptive when NWI-5 goes into production.  

- If clients do nothing, they still receive all updates.
- If we do not return all updates by default, then out of region object updates will not appear (even though they will occur).
- Receiving all updates will require separate queries in separate connections, which need to be merged on the client side.
- The default behaviour for Whois queries (on port 43, REST API and Web) will be to return objects from both sources.

On the other hand, to separate NRTM streams by source:

- The NRTM query does specify the source, this implies updates from only that source.
- It is straightforward to support separate sources on the server side.
- There are relatively few active NRTM clients that would need to be updated.

We also do not plan to separate the database dumps by source. This can be done, but any consumers need to make adjustments or will no longer find out of region objects.

I welcome discussion on these points, we will implement as the DB-WG prefers.

Regards
Ed Shryane
RIPE NCC


> On 19 Jul 2018, at 15:50, Job Snijders via db-wg <db-wg at ripe.net> wrote:
> 
> Dear Nathalie,
> 
> On Thu, Jul 19, 2018 at 03:18:37PM +0200, Nathalie Trenaman via db-wg wrote:
>> We will implement these changes in the Release Candidate environment
>> on Thursday, 2 August and go to full production on Tuesday, 4
>> September.
>> 
>> Our implementation plan can be found at:
>> https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
> 
> In section 5, the following is stated:
> 
>    """For NRTM, we don't plan to separate out the stream by source.
>    Updates from both the RIPE and RIPE-NONAUTH sources will be
>    included.
> 
>    The source is specified in the request (e.g., -g RIPE:3:11012700-LAST),
>    but updates from both RIPE and RIPE-NONAUTH will be returned. The
>    client will need to filter on the source attribute as needed."""
> 
> I'd like to ask that this aspect is reconsidered. I'd prefer to mirror
> the two data sources as two separate data streams. So "-g RIPE:3:11012700-LAST"
> should only return proper 'RIPE' objects, and additionally I can track
> RIPE-NONAUTH through the use of "-g RIPE-NONAUTH:3:1102700-LAST".
> 
> Presenting objects to NRTM clients where the objects have a different
> source than was requested by the client is undefined behaviour. Therefor
> I'd prefer Using separate streams for the two separate sources, that way
> it is business as usual for the NRTM clients.
> 
> To illustrate further: my current irrd.conf (irrd v3) is as following:
> 
> 	job at eng0 ~$ grep ripe /etc/irrd.conf
> 	! RIPE - ripe-dbm at ripe.net
> 	irr_database ripe mirror_host 193.0.6.135 4444
> 	irr_database ripe mirror_protocol 3
> 	irr_database ripe mirror-access 27
> 	irr_database ripe filter routing-registry-objects|route6
> 
> And on September 4th I'd reconfigure it as:
> 
> 	! RIPE - ripe-dbm at ripe.net
> 	irr_database ripe mirror_host 193.0.6.135 4444
> 	irr_database ripe mirror_protocol 3
> 	irr_database ripe mirror-access 27
> 	irr_database ripe filter routing-registry-objects|route6
> 	irr_database ripe-nonauth mirror_host 193.0.6.135 4444
> 	irr_database ripe-nonauth mirror_protocol 3
> 	irr_database ripe-nonauth mirror-access 27
> 	irr_database ripe-nonauth filter routing-registry-objects|route6
> 
> Similarly I'd expect that the RIPE and RIPE-NONAUTH sources are provided
> as separate dumps at https://ftp.ripe.net/ripe/dbase/ (where I'd expect
> ripe-nonauth.db.gz) and same for https://ftp.ripe.net/ripe/dbase/split/
> 
> Kind regards,
> 
> Job
>