Re: [EXTERNAL] Continuing geolocation issues with the "ietf" network

Tommy Pauly <tpauly@apple.com> Fri, 29 July 2022 18:16 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3EC157B3A for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2022 11:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5i09VYDPoUx for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2022 11:16:17 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.rno.apple.com [17.179.253.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7ED5C14CF1E for <ietf@ietf.org>; Fri, 29 Jul 2022 11:16:17 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 26TI5okG008979; Fri, 29 Jul 2022 11:16:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=hsNH4aHoPN6mHUV3xlHfFdVCXggnLDOvhjEEb6NGL1Y=; b=PDqIFroaUu6vQAHWuPlearkcWFdJqgAfetCFuf7tonlXGTLf7CzXeKGAqtirOXQ4Dc8u dRlhTnxNSesMICHycZqS8ZJ0LW0bj9jHzK7D0prbLTE3lFAeuqK7NHd/1LAweLjXZxWD 4gwby/VJFiesNvZgRj2+QxuXlfRSAZZ7aTHhA+/+Jp21QvcWe2xPOCN72Rv0kX7eVOsz Ncz736xdXsPHwBIyX/B9zXMjHnaXND7LEJii00s/f35sObjr/GHlDmR47Khk6GaCvv2D bWVrR1mDtyC0x0rfI+s3/TgspkXWcw2m1ohXzUes56+FE/JP5k4f+Pai6YLpXhmMdDhD Tw==
Received: from ma-mailsvcp-mta-lapp02.corp.apple.com (ma-mailsvcp-mta-lapp02.corp.apple.com [10.226.18.134]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3hgdvbwk4s-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 29 Jul 2022 11:16:15 -0700
Received: from ma-mailsvcp-mmp-lapp03.apple.com (ma-mailsvcp-mmp-lapp03.apple.com [17.32.222.16]) by ma-mailsvcp-mta-lapp02.corp.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RFS00IN6O32O350@ma-mailsvcp-mta-lapp02.corp.apple.com>; Fri, 29 Jul 2022 11:16:14 -0700 (PDT)
Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp03.apple.com by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RFS00X00NWZXP00@ma-mailsvcp-mmp-lapp03.apple.com>; Fri, 29 Jul 2022 11:16:14 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 43a1126a6581cd63d903173a70428f1a
X-Va-E-CD: 2d2e633bb254f18d04f55dc98ab0a55b
X-Va-R-CD: aeec0612fd6695792099ef22ff13abe7
X-Va-CD: 0
X-Va-ID: 17074855-e7d5-4298-98ff-5497053de249
X-V-A:
X-V-T-CD: 43a1126a6581cd63d903173a70428f1a
X-V-E-CD: 2d2e633bb254f18d04f55dc98ab0a55b
X-V-R-CD: aeec0612fd6695792099ef22ff13abe7
X-V-CD: 0
X-V-ID: af97e3ec-3a1e-452c-8b0d-c9abc4edd58d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-29_19:2022-07-28, 2022-07-29 signatures=0
Received: from smtpclient.apple (unknown [17.10.79.173]) by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RFS00BDXO32DB00@ma-mailsvcp-mmp-lapp03.apple.com>; Fri, 29 Jul 2022 11:16:14 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <141AB6CC-B9F8-4367-A548-70D573F69B39@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_68C741D8-8028-4BC9-912A-46C72626C7DC"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3729.0.22.1.1\))
Subject: Re: [EXTERNAL] Continuing geolocation issues with the "ietf" network
Date: Fri, 29 Jul 2022 14:16:03 -0400
In-reply-to: <CAMGpriWp3QXR0kMfRPY926J30BO--7mOUEiHB-qy+2531R+Oxw@mail.gmail.com>
Cc: Ross Finlayson <finlayson@live555.com>, "ietf@ietf.org" <ietf@ietf.org>
To: Erik Kline <ek.ietf@gmail.com>
References: <D80797E8-30CA-48E6-AC17-8E423B1668A5@live555.com> <20220729163151.GM30255@kduck.mit.edu> <SJ0PR14MB4235B81A91AD8B03231EF92AE2999@SJ0PR14MB4235.namprd14.prod.outlook.com> <5A08DCF3-0CC7-4E11-B8E6-CADF2C4CEC04@live555.com> <CAMGpriWp3QXR0kMfRPY926J30BO--7mOUEiHB-qy+2531R+Oxw@mail.gmail.com>
X-Mailer: Apple Mail (2.3729.0.22.1.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-29_19:2022-07-28, 2022-07-29 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/c6rtZ4cJ0hnhXKCmJJZtB3_qjpo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 18:16:20 -0000

One possible long term solution to this is something we’re proposing to add hints to the correct geo IP mapping and feed to use, in HTTP:

https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-00.html

This would require that clients could learn which feed their IP comes from, but it would allow them to hint to servers that the server’s version of the feed may be out of date.

Thanks,
Tommy

> On Jul 29, 2022, at 1:43 PM, Erik Kline <ek.ietf@gmail.com> wrote:
> 
> On Fri, Jul 29, 2022 at 12:48 PM Ross Finlayson <finlayson@live555.com <mailto:finlayson@live555.com>> wrote:
>> 
>> 
>> > On Jul 29, 2022, at 12:37 PM, Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com <mailto:Glenn.Deen@nbcuni.com>> wrote:
>> > 
>> > I think that’s part of it, but it’s also getting the various sites that consume the data to update the data they are looking at.
>> 
>> Maybe - but why Switzerland?  I don’t think we’ve ever met there?
> 
> 113 was in Vienna, so that is odd.
> 
> One problem, as I understand it, is that consumers of https://noc.ietf.org/geo/google.csv might also be validating the prefix to see if it's announced anywhere.  If the prefix isn't announced early enough (whenever a geo processing cycle is underway) then consumers might discard the geo updates.  I wonder if the IETF prefixes are advertised from anywhere in between meetings, or only just before/as the conference network is coming up.
> 
> I'm not sure what standard processing cycles are, but I'm sure it is on the order of several weeks (perhaps only monthly).
> 
>