IETF Logo Mail Archive

Re: [Sidrops] proposed, revised text for Section 6

Randy Bush <randy@psg.com> Tue, 05 May 2020 21:59 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208B43A0C24 for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 14:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 h60OKUkr4IVi for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 14:59:52 -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 185843A0C07 for <sidrops@ietf.org>; Tue, 5 May 2020 14:59:52 -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 1jW5bR-0001Uj-T3; Tue, 05 May 2020 21:59:50 +0000
Date: Tue, 05 May 2020 14:59:48 -0700
Message-ID: <m2pnbim4a3.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <CAKr6gn29namLq5qq6WhhveT+6r7vC8W9SmwPcNP_un93GWmP9A@mail.gmail.com> <7355e27e-ee58-f84b-4fed-9674ae542d94@verizon.net>
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/sidrops/T6n5JMff368PiibBgR2d4ZFgUdQ>
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 22:00:00 -0000

> I will note, in passing, that this can introduce variances in local
> processing based on local cache loss and/or differences in cache
> refresh timing by different RPs. But, if everyone is comfortable
> accepting the potential variance, I'm happy to proceed.

if i insteaad not process current fetch, than we will also have
inconsistent views, yes?

and of course, as fetch times may vary, inconsistency will be normal

the question is how much and what kinds of inconsistency the attacker
can cause

randy

v2.23.0 | Report a Bug | By Email