[arch-d] Re: Call for Comment: <draft-iab-ip-geo-workshop-report-01> (Report from the IAB Workshop on IP Address Geolocation)

[Tommy Pauly <[e-mail]>]

Replying here to the other items (since we are updating the age assurance aspect with https://github.com/intarchboard/draft-iab-ip-geo-workshop-report/pull/18)

> On Jun 25, 2026, at 10:50 AM, Eric Rescorla <[e-mail]> wrote:
> 
> ...
> 
> S 4.2.
>    *  False specificity occurs when feeds map an address to a city, but
>       the location associated with the address is much bigger than the
>       city
> 
> Don't geoloc providers typically provide some confidence
> estimate?

Yes, this is something that the geolocation providers can and do provide, but I think this is always done in various non-standard / proprietary ways, and there are feeds that don’t have confidence levels. Basic geofeeds to tag specific cities, and have no way of indicating confidence, which is one cause of this false specificity. But there are other examples, such as location being communicated that ought to be specified more at a regional or time zone level.

> 
> S 4.5.
>    Sometimes VPNs or proxies intentionally obfuscate or change how the
>    user is represented to IP geolocation providers, but other
>    deployments of privacy services do use geofeeds to preserve the
>    general user location to avoid user experience or compliance issues.
> 
> You might mention that this is actually an advertised feature
> of a number of VPN providers, typically for geoblocking
> evasion.

Yes, this is what is intended by saying that the VPNs “intentionally obfuscate or change” the geolocation (although, yes, the document isn't going into the advertising aspect).

> 
> 
> S 5.2.
> 
>    *  More accurately represent the granularity and specificity of
>       geolocation mappings; be able to express certainty levels
> 
> As I noted above, some providers already provide confidence.
> For example, MaxMind provides an accuracy radius:
> 
> https://dev.maxmind.com/geoip/docs/web-services/responses/#location
> 
> This may not be a feature of GEOFEED, but that's different
> from providers not being able to do so.

Right, this list you’re pointing out is the areas in which the standardized geofeeds can improve.

> 
> 
>    *  Rely more on the RPKI to more reliably verify location claims
> 
> What does this mean?

As mentioned elsewhere in the document, RPKI usage to define how to authenticate geofeed information is defined in https://www.rfc-editor.org/info/rfc9632/#section-5. The workshop discussion did bring this up.

Thanks,
Tommy

> 
> -Ekr
> 
> 
> On Wed, May 20, 2026 at 2:20 PM IAB Executive Administrative Manager <[e-mail] <mailto:[e-mail]>> wrote:
>> This is an announcement of an IETF-wide Call for Comment on 
>> draft-iab-ip-geo-workshop-report-01.
>> 
>> The document is being considered for publication as an Informational 
>> RFC within the IAB stream and is available for inspection at: 
>> https://datatracker.ietf.org/doc/draft-iab-ip-geo-workshop-report/
>> 
>> The Call for Comment will last until 2026-06-17. Please send comments 
>> to [e-mail] <mailto:[e-mail]> and [e-mail] <mailto:[e-mail]>.
>> 
>> Abstract:
>> 
>>    The IAB Workshop on IP Address Geolocation (IP-GEO) was held from
>>    December 3-5, 2025, as a three-day virtual meeting.  It covered the
>>    use cases and background on using IP addresses as indicators of
>>    geolocation, explored various problems and challenges that exist in
>>    that ecosystem, and discussed future directions and opportunities to
>>    improve or replace the current practices.
>> 
>> Note:
>> 
>>    This document is a report on the proceedings of the workshop.  The 
>>    views and positions documented in this report are those of the 
>>    workshop participants and do not necessarily reflect IAB views and 
>>    positions.
>> 
>>    Furthermore, the content of the report comes from presentations 
>>    given by workshop participants and notes taken during the 
>>    discussions, without interpretation or validation.  Thus, the 
>>    content of this report follows the flow and dialogue of the workshop 
>>    but does not attempt to capture a consensus.
>> 
>> _______________________________________________
>> IETF-Announce mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> Architecture-discuss mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]