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@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-implem...
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@eng0 ~$ grep ripe /etc/irrd.conf ! RIPE - ripe-dbm@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@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