<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Ronald,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 10 Jun 2021, at 23:57, Ronald F. Guilmette via db-wg <<a href="mailto:db-wg@ripe.net" class="">db-wg@ripe.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">It appears that, by and large, the route objects currently present within<br class="">the ripe-nonauth.db.gz file refer either to bogons (which I've already<br class="">provided a list of) or else they refer to out-of-region IP address blocks.<br class=""><br class="">The latter group seems at least explainable. The former group I am hoping<br class="">will disappear from the data base soon.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Correct, the route objects with an unregistered prefix will be cleaned up soon.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Checking now however I find there are a very small number of anomalous<br class="">route objects within the latest edition of the ripe-nonauth.db.gz file,<br class="">i.e. ones that refer to in-region IP blocks:<br class=""></div></div></blockquote><div><br class=""></div><div>In April I found 33 route objects in NONAUTH with a completely in-region range. I notified the maintainers and moved those routes to the RIPE database.</div><div><br class=""></div><div>The 4 cases you found are not completely in the RIPE region, so it's not clear if they should remain in NONAUTH or be (re)moved.</div><div><br class=""></div><div>None of the ranges appear to have been split by an inter-RIR transfer:</div><div><a href="https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics" class="">https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics</a></div><div><br class=""></div><div>But the route prefix falls between 2 RIR assignments</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">192.124.252.0/22<br class=""></div></div></blockquote><div><br class=""></div><div><div>This prefix is referenced from 1 NONAUTH route 192.124.252.0/22AS680</div><div><br class=""></div><div>The prefix is split between RIPE and ARIN:</div><div><br class=""></div><div>ripencc|DE|ipv4|192.124.252.0|256|19920812|assigned|472b74a8-9fd5-4837-9024-f7574bdd7f7c</div><div>ripencc|DE|ipv4|192.124.253.0|256|19931019|assigned|e68966fe-33c9-47f0-ad13-e83ca182b8bf</div><div>ripencc|DE|ipv4|192.124.254.0|256|19840101|assigned|e4626976-484a-4850-897d-d7be3e709511</div><div>arin||ipv4|192.124.255.0|256||reserved|</div><div><br class=""></div><div>I see 3 routes in the RIPE database:</div><div>192.124.252.0/24AS3320</div><div>192.124.253.0/24AS680</div><div>192.124.254.0/24AS680</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">192.70.0.0/17<br class=""></div></div></blockquote><div><br class=""></div><div><div>This prefix is referenced from 1 NONAUTH route: 192.70.0.0/17AS2200</div><div><br class=""></div><div>The prefix is mostly assigned to the RIPE region, except for a /24:</div><div><br class=""></div><div>ripencc|FR|ipv4|192.70.0.0|23552|19930901|assigned|4c5e10ae-266a-4127-84ac-04b780309b1d</div><div>ripencc|FR|ipv4|192.70.92.0|1280|20050411|assigned|b8f87e41-6e2a-427f-af98-60c978d51985</div><div>ripencc|FR|ipv4|192.70.97.0|4352|19930901|assigned|3e011729-91a0-412e-8947-1ac32eef22e2</div><div>192.70.113.0 - 192.70.113.255 not in *any* delegated stats file?</div><div><div>ripencc|FR|ipv4|192.70.114.0|256|19900315|assigned|3e219d39-a2e5-476b-bf9b-835f172f89ae</div><div>ripencc|FR|ipv4|192.70.115.0|256|19900315|assigned|4d073146-29da-45c5-a74c-e90c3963405f</div><div>ripencc|FR|ipv4|192.70.116.0|256|19900315|assigned|ef2d7312-e300-4850-83d0-e99faa095c12</div><div>ripencc|FR|ipv4|192.70.117.0|256|19930520|assigned|a4b599d8-871f-4f0a-b5c3-5b5d96a614e4</div><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div class="">192.76.32.0/21<br class=""></div></div></blockquote><div><br class=""></div><div><div>This prefix is referenced from 1 NONAUTH route: 192.76.32.0/21AS786</div><div><br class=""></div><div>The prefix is split between RIPE and ARIN:</div><div><br class=""></div><div>ripencc|GB|ipv4|192.76.24.0|3072|19900815|assigned|1ae99a59-4b02-4c77-8ce0-e7e359a12842</div><div>arin|US|ipv4|192.76.36.0|1024|19900828|allocated|eaf44477133ed73a4fc62658b886953b</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">192.108.160.0/20<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><div>This prefix is referenced from 1 NONAUTH route: 192.108.160.0/20AS2607</div><div><br class=""></div><div>The prefix is split between RIPE and ARIN:</div><div><br class=""></div><div>ripencc|SK|ipv4|192.108.134.0|10496|19910724|assigned|755273b5-19e0-4fae-95c4-0e804f714dea</div><div>arin|US|ipv4|192.108.175.0|256|19910724|assigned|c096bf755fee3dfb7b9046461595ebd0</div></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I'm not sure how these should be made to go away, but I wish they would.<br class="">They offend my personal sense of fastidiousness, and I don't like<br class="">unexplainable mysteries.<br class=""></div></div></blockquote><div><br class=""></div><div>I suggest that the RIPE NCC emails the maintainer(s) of these objects, and ask them to update the routes so they align to the assigned regions.</div><div><br class=""></div><div>They are not using unregistered space, and are not eligible to be cleaned up.</div><div><br class=""></div><div>Regards</div><div>Ed Shryane</div><div>RIPE NCC</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Note that the RIPE-NONAUTH route object 192.76.32.0/21 appears to have<br class="">some counterpart route objects for sub-blocks of that /21 and these<br class="">sub-blocks route objects are *not* marked as RIPE-NONAUTH, suggesting<br class="">that there is no compelling reason for the 192.76.32.0/21 route<br class="">object to be marked as RIPE-NONAUTH.<br class=""><br class="">The same sort of syndrome appears to apply also in the case of the<br class="">192.124.252.0/22 RIPE-NONAUTH route object, i.e. in this case also<br class="">there appear to be valid non-RIPE-NONAUTH route objects in the data<br class="">base for sub-blocks of 192.124.252.0/22, which begs the question:<br class="">Why is the 192.124.252.0/22 markes as RIPE-NONAUTH?<br class=""><br class=""><br class="">Regards,<br class="">rfg<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>