>
> Good question. When we identify conflicts between our measurements and a
> geofeed, we don't automatically assume the geofeed is wrong.


Abullah-

You have shared the following link in previous messages , a Google form to
request hosting of a probe server.  (
https://docs.google.com/forms/d/e/1FAIpQLScdX-RrtPdJL4Xs-Sa7kFPncq9Ooxha7AvO2kU9U3LUaNrVgA/viewform
) The top of this document, as of the writing of this email states :

IPinfo <https://ipinfo.io/> maintains a fleet of more than thousand servers
> across the globe, spanning over 150 countries. We use active measurements
> like ping and traceroute to generate precise IP location data.
>
> We appreciate geofeeds and corrections submitted to us, but active
> measurement is the primary source of data. If active measurements provide
> contradictory information to geofeed or reported data, we will prioritize
> our active measurement data. However, due to peering, networking topology,
> transit issues, etc., our active measurement can be noisy for some ASNs.
>
> We recommend hosting a probe server connected to your ASN to consistently
> produce accurate data for you.
>
> If you have any questions about this form, reach out to us directly:
>
> DevRel: [email protected]
>

The second sentence where you explicitly state that your active measurement
platform is the source of your data, and you will use that OVER a geofeed
or corrections. This statement is actually worse, that you state not only
will you ignore a geofeed, you will also ignore submitted corrections.

To summarize these many conversations :

1. You have stated in emails that you will prioritize your own measurements
over geofeeds.
2. As individuals pushed back on this method, you have walked back your
email statements on this.
3. You have linked to documents in which you *REPEAT* will prioritize your
own measurements over geofeeds or submitted corrections.
4. You have provided a link to a 'peer reviewed paper' to tout the
'accuracy of your data'. You have misrepresented what that paper actually
concludes ; It actually analyzes how much your measurement data agrees with
publishes geofeeds.

I respect that you are engaging with operators, but we are engineers who
know what we're talking about. We tend to notice discrepancies like this,
and are not shy to call them out.


On Tue, Feb 17, 2026 at 12:30 PM Abdullah DevRel of IPinfo via NANOG <
[email protected]> wrote:

> Hi John,
>
> Good question. When we identify conflicts between our measurements and a
> geofeed, we don't automatically assume the geofeed is wrong.
>
> The process is:
>
> When contacted by an ISP about a conflict, we investigate and share our
> measurement data with them. Often this reveals network architecture issues
> (anycast, aggregation points, CGNAT) that explain the discrepancy. We
> adjust our scoring based on their feedback.
>
> For systematic issues we observe across multiple prefixes from the same
> ASN, we do reach out proactively - particularly if it affects user
> experience (support tickets, access issues).
>
> For individual prefix mismatches where we haven't received complaints, we
> don't proactively contact every ASN. At global scale (analyzing millions of
> prefixes), this would be operationally challenging.
>
> The limitation you're identifying is real. We could do more proactive
> outreach when we detect conflicts. That's valuable feedback. Would you
> recommend a specific approach - perhaps flagging high-confidence conflicts
> in a report ISPs could opt into?
>
> — Abdullah | DevRel, IPinfo
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/[email protected]/message/U2KEBUKX5ITIDDHGPHPSMDQPFLEW5VSI/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/Y2UFQY6AZX3W5ZHEWY2JE4A3QLBGYXQR/

Reply via email to