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