I think the point was that you should accept the geofeed data, but only prefixes that AS is allowed to announce. -----Original Message----- From: Ryan Hamel via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 11:58 PM To: Christopher Hawker <chris@thesysadmin.au>; nanog@lists.nanog.org Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Ryan Hamel <ryan@rkhtech.org> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Christopher, Your "trust but verify" / "accept but confirm", and "not use it as one source of information along with others", completely contradicts what you're saying. What is the point of confirmation/verification if the default action is to "trust" ? Kind regards, Ryan Hamel ________________________________ From: Christopher Hawker <chris@thesysadmin.au> Sent: Tuesday, January 27, 2026 8:48 PM To: Ryan Hamel <ryan@rkhtech.org>; nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hi Ryan, It comes down to "trust but verify". If I tell you that my space is being used in and advertised from a location, you should accept this info but confirm the data is correct. Not use it as one source of information along with others.
What stops you from putting prefixes into your geofeed, potentially conflicting or overriding my geofeed?
If I have an inetnum object for 203.0.113.0/24 with a geofeed attribute listing https://example.com/geofeed.csv, and that file lists multiple prefixes such as 198.51.100.0/24 then the GeoIP operator should only be accepting the GeoIP data for the prefix in the inetnum object and discard the rest. Regards, Christopher Hawker ________________________________ From: Ryan Hamel <ryan@rkhtech.org> Sent: Wednesday, 28 January 2026 3:05 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Christopher Hawker <chris@thesysadmin.au> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Christopher, I get you, but again, when it comes to VPN providers or those who wish to cause trouble on the Internet, how does a GeoIP provider prevent bogus data from getting accepted? What stops you from putting prefixes into your geofeed, potentially conflicting or overriding my geofeed? Here's an analogy using the wording from your response: If I send you (via my BGP session) my prefixes to announce, you should be accepting it as-is. Not what you think is accurate or correct. Ryan Hamel ________________________________ From: Christopher Hawker via NANOG <nanog@lists.nanog.org> Sent: Tuesday, January 27, 2026 7:46 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com>; Christopher Hawker <chris@thesysadmin.au> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed.
If I tell you (via my Geofeed) my address space is being used in Sydney Australia, you should be presenting it as being used in Sydney Australia. Not what you think is accurate or correct. Regards, Christopher Hawker ________________________________ From: Abdullah DevRel of IPinfo via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 28 January 2026 2:34 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Abdullah DevRel of IPinfo <devrel.ipinfo@gmail.com> Subject: Re: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?) Hi Christopher, Thank you very much. We take about 24-48 hours to verify. This involves a series of checks backed by active measurement. To be honest, it is quite instantaneous. But the issue involves update cycles and cache purging. Usually it is around 24 hours. But sometimes like ASN type verification, you have to do much more extensive reviews but those are automated as well. So, to stay safe we say 24-48 hours.
Failing that, fallback to manual data submitted from the network operator. As a last record, use the Country attribute from the Whois records.
If there is noise in the active measurement data, we will definitely fall back to geofeed. That is guaranteed. We are simply comparing the best possible data we have. We ingest a lot of data. And we pick the best. We also use WHOIS country. In fact, for unallocated ranges, we use the RIR country. There is a hierarchy of fallback values that make it a good system.
This is IMO where the frustration lies with GeoIP data taking unacceptable amounts of time to update, not using it as the first method.
We do not discourage geofeed submissions nor the geofeed. It is just that our active measurement data is generally more accurate, verifiable, and granular than what we observe in geofeed, on average. However, we do ingest geofeed and will pick it up when needed. Time to update is not a bottleneck for us; users can submit their geofeed or correction via a simple form on our website. — Abdullah | DevRel, IPinfo _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GUDWVNEAABEKVGBNY34U7O4OXHVKICXL/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AUHPGK3SGFCWGJLJGSTFGNARMIEATKM2/<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AUHPGK3SGFCWGJLJGSTFGNARMIEATKM2/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OLVSZFUP...