<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Job, all<br class=""><div class=""> <div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div> </div> <div><br class=""><blockquote type="cite" class=""><div class="">On 6 Oct 2020, at 18:28, Job Snijders 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="">Dear DB-WG,<br class=""><br class="">Some colleagues are working to address the never-ending-story of 'where<br class="">the heck are IPs geographically?'. This problem space has been brought<br class="">up numerous times in the Database Working Group, but we never managed to<br class="">solve it. As with all compsci problems adding a layer of indirection can<br class="">help ;-)<br class=""><br class="">This current draft suggests overloading the RPSL 'remarks:' field with a<br class="">structured attribute value, however I suspect we would do ourselves a<br class="">disservice to overload a 'remarks:' field.<br class=""><br class="">Instead it would be better to add a 'geofeed:' attribute to the RPSL<br class="">inetnum/inetnum6 class dictionary, which as value contains a URL with<br class="">http or https scheme.<br class=""><br class="">The draft: <a href="https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds" class="">https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds</a><br class=""><br class="">The value of the attribute could be validated using something like<br class="">"org.apache.commons.validator.UrlValidator", the attribute would look<br class="">like this, only valid in the inetnum/inet6num:<br class=""><br class=""> "geofeed: [optional] [single] [ ]"<br class=""><br class="">Example object:<br class=""><br class=""> inetnum: 192.0.2.0 - 192.0.2.255<br class=""> netname: EXAMPLE<br class=""> country: NL<br class=""> geofeed: <a href="https://example.com/geofeed.csv" class="">https://example.com/geofeed.csv</a><br class=""> ... snip ...<br class=""> source: RIPE<br class=""><br class="">What do others think?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes I find this much more reasonable instead of overloading the remarks field. By default the remarks are being ignored by the parsers as it doesn’t contain any usable information that can be used in the router config generation (or other type of config). They contain information for the operator/human that reads the file on his screen. </div><div><br class=""></div><div>By enriching the RPSL dictionary and having a “geofeed” RPSL attribute (which by the way should not be mandatory) will be easier for someone to extend his parser to use that field without overloading the parser with many “if” and regex expressions. Plus the upcoming RFC specifies that "The format MUST be as in this example,“ so a verification needs to be applied later on.</div><div><br class=""></div><div>Of course it’s weird to talk about enriching RPSL on 2020 but putting this apart, I believe it’s more correct to implement it in this way.</div><div><br class=""></div> <br class=""><blockquote type="cite" class=""><div class=""><div class="">Kind regards,<br class=""><br class="">Job<br class=""><br class="">ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added<br class=""><a href="https://github.com/irrdnet/irrd/issues/396" class="">https://github.com/irrdnet/irrd/issues/396</a><br class=""></div></div></blockquote><br class=""></div><div><pre class="newpage"><span style="font-family: Helvetica; white-space: normal;" class="">Best regards,</span><br style="font-family: Helvetica; white-space: normal;" class=""><br style="font-family: Helvetica; white-space: normal;" class=""><span style="font-family: Helvetica; white-space: normal;" class="">Stavros Konstantaras | Sr. Network Engineer | AMS-IX </span><br style="font-family: Helvetica; white-space: normal;" class=""><span style="font-family: Helvetica; white-space: normal;" class="">M +31 (0) 620 89 51 04 | T +31 20 305 8999</span><br style="font-family: Helvetica; white-space: normal;" class=""><span style="font-family: Helvetica; white-space: normal;" class=""><a href="http://ams-ix.net" class="">ams-ix.net</a></span></pre></div><br class=""></body></html>