Re: [OPSAWG] Finding and Using Geofeed Data

Randy Bush <randy@psg.com> Mon, 14 September 2020 17:05 UTC

Return-Path: <randy@psg.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02563A0D50 for <opsawg@ietfa.amsl.com>; Mon, 14 Sep 2020 10:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DQpXgMnInS4 for <opsawg@ietfa.amsl.com>; Mon, 14 Sep 2020 10:05:08 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A66EF3A0C62 for <opsawg@ietf.org>; Mon, 14 Sep 2020 10:05:08 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1kHruZ-0007NL-UB; Mon, 14 Sep 2020 17:05:04 +0000
Date: Mon, 14 Sep 2020 10:05:03 -0700
Message-ID: <m2d02o9tmo.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: Massimo Candela <massimo@us.ntt.net>, Joe Clarke <jclarke@cisco.com>, Ops Area WG <opsawg@ietf.org>
In-Reply-To: <CAMGpriUoWXqJq5JJSfEaKJkS_cuQeQyBtuu-D4vbrFj21gyNFA@mail.gmail.com>
References: <8450cc78-8c60-ff7a-19f5-ea7335d262cd@us.ntt.net> <m25z8kdoqb.wl-randy@psg.com> <C65C82F2-E675-4D2A-A85D-9E3DAF453D77@cisco.com> <m2sgblbngx.wl-randy@psg.com> <f860f867-a8a1-82d0-813a-5d54e2479b3c@us.ntt.net> <CAMGpriUoWXqJq5JJSfEaKJkS_cuQeQyBtuu-D4vbrFj21gyNFA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/cBbXsA3GhK3CWwoXC7kRd-zmJ9o>
Subject: Re: [OPSAWG] Finding and Using Geofeed Data
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 17:05:10 -0000

> FWIW, we tried to have some HTTP header discussion in 8805:
> https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

        An entity fetching geofeed data using these mechanisms MUST NOT
        do frequent real-time look-ups to prevent load on RPSL and
        geofeed servers.  <xref target="RFC8805"/> Section 3.4 suggests
        use of the <xref target="RFC7234"/> HTTP Expires Cacheing Header
        to signal when geofeed data should be refetched.  As the data
        change very infrequently, in the absense of such an HTTP Header
        signal, collectors MUST NOT fetch more frequently than weekly.
        It would be wise not to fetch at magic times such as midnight
        UCT, the first of the month, etc., because too many others are
        likely to do the same.