RE: Geofeeds are good — was Re: Publishing BGP communties for your network (Re: What's up with BGP communities?)

[Gary Sparkes via NANOG <nanog () lists nanog org>]

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/OLVSZFUPLUVUURLDM362ILHW7LASG2VL/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/MOJDUGXH2YUHC5377IVXIJ2DDI7GJ7K4/