<div dir="ltr"><br><div>  I would just like to concur with Job's comments and that including both sources in the same NRTM stream is not something that existing mirroring implementations expect to encounter.  Â  Separate mirror streams and database dumps will be consistent with existing practice and produce expected results in response to user queries.  Â Note that several IRRd "!" query commands and the RIPE "-K" flag do no include the source attribute which means the client software is unable to distinguish sources on it's end when using these queries.</div><div><br></div><div> -Larry Blunk</div><div>  Merit Network</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 19, 2018 at 3:48 PM Job Snijders via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Edward,<br>
<br>
On Thu, Jul 19, 2018 at 09:27:23PM +0200, Edward Shryane wrote:<br>
> we plan to return objects from both the RIPE and RIPE-NONAUTH sources<br>
> for NRTM, as it will be less disruptive when NWI-5 goes into<br>
> production.<br>
<br>
I am not convinced anyone can authoritatively make that statement. As<br>
far as I know the RIPE NCC IRR would be the first to publish multiple<br>
sources in a single stream. There is an industry convention related to<br>
IRR sources, I see no immediate reason to deviate from this standard.<br>
<br>
> - If clients do nothing, they still receive all updates.<br>
<br>
And perhaps consider them corrupted, because they requested source X and<br>
get back source Y.<br>
<br>
> - If we do not return all updates by default, then out of region<br>
> object updates will not appear (even though they will occur).<br>
<br>
The 20 NRTM clients (of which we probably know most personally) just<br>
have to configure a second source and all will be good.<br>
<br>
> - Receiving all updates will require separate queries in separate<br>
> connections, which need to be merged on the client side.<br>
<br>
The whole point is to not merge them into a single source, so that we<br>
can programmatically differentiate between the two sources. If there is<br>
merging, it happens at a different point in the pipeline, not at<br>
'ingress' (from the point of view of a mirror).<br>
<br>
> - The default behaviour for Whois queries (on port 43, REST API and Web) will be to return objects from both sources.<br>
<br>
I have no problem with that.<br>
<br>
> On the other hand, to separate NRTM streams by source:<br>
> <br>
> - The NRTM query does specify the source, this implies updates from only that source.<br>
<br>
exactly. This is a foundational assumption in all NRTM software I am<br>
aware of.<br>
<br>
> - It is straightforward to support separate sources on the server side.<br>
> - There are relatively few active NRTM clients that would need to be updated.<br>
<br>
I am happy to hear that separate sources are straight forward to<br>
implement. On the IRRd v2, v3 and v4 side of things it is not straight<br>
forward to implement.<br>
<br>
> We also do not plan to separate the database dumps by source. This can<br>
> be done, but any consumers need to make adjustments or will no longer<br>
> find out of region objects.<br>
<br>
yes, that is the point. We make a change, and people need to update if<br>
they rely on this. By splitting the NRTM and database dumps, most<br>
implementations only need to add an additional source, rather than<br>
reprogram their client software to understand that what used to be a<br>
single file containing a single source, now contains multiple sources.<br>
<br>
> I welcome discussion on these points, we will implement as the DB-WG<br>
> prefers.<br>
<br>
Because of NWI-5 the RIPE IRR is splitting into two, and we should plan<br>
accordingly. To me that means separate database dumps and separate NRTM<br>
streams.<br>
<br>
Kind regards,<br>
<br>
Job<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div style="font-family:helvetica,arial,verdana,sans-serif;line-height:16px"><span style="color:rgb(76,76,78);font-size:14px"><b>Larry Blunk</b></span><br><font color="#0069a6"><span style="font-size:13px">Senior Network Engineer</span></font><br><a href="https://www.merit.edu" style="color:rgb(76,76,78);font-size:13px" target="_blank"><img src="https://www.merit.edu/email_signatures/merit_network.png" width="80" height="27" alt="Merit.edu" style="padding:8px 0 10px 0"></a><br><a href="mailto:ljb@merit.edu" style="color:rgb(76,76,78);font-size:13px" target="_blank">ljb@merit.edu</a><span style="color:rgb(76,76,78);font-size:13px">  | 734.527.5725 p  | 734.395.4363 c |  </span><a href="http://www.merit.edu" style="color:rgb(76,76,78);font-size:13px" target="_blank">www.merit.edu</a> <br><span style="color:rgb(76,76,78);font-size:13px">1000 Oakbrook Drive, Suite 200 | Ann Arbor, MI 48104</span><br><br><a href="http://www.facebook.com/meritnetwork" style="color:rgb(76,76,78);font-size:13px" target="_blank"><img src="https://www.merit.edu/email_signatures/facebook.png" width="20" height="20" alt="Like Merit on Facebook"></a><span style="color:rgb(76,76,78);font-size:13px"> </span><a href="http://www.twitter.com/meritnetwork" style="color:rgb(76,76,78);font-size:13px" target="_blank"><img src="https://www.merit.edu/email_signatures/twitter.png" width="20" height="20" alt="Follow Merit on Twitter"></a><span style="color:rgb(76,76,78);font-size:13px"> </span><a href="http://www.linkedin.com/company/merit-network" style="color:rgb(76,76,78);font-size:13px" target="_blank"><img src="https://www.merit.edu/email_signatures/linkedin.png" width="20" height="20" alt="Connect with Merit on LinkedIn"></a><span style="color:rgb(76,76,78);font-size:13px">   </span><a href="https://www.merit.edu/professional-development/" style="color:rgb(0,105,166);font-size:13px;text-decoration:none" target="_blank"><b>Upcoming Courses and Events</b></a></div>
</div></div></div>