Re: [Sidrops] proposed, revised text for Section 6
Jay Borkenhagen <jayb@braeburn.org> Wed, 06 May 2020 19:46 UTC
Return-Path: <jayb@oz.mt.att.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 A0E093A0AC7 for <sidrops@ietfa.amsl.com>; Wed, 6 May 2020 12:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 rAbnFghZQcnO for <sidrops@ietfa.amsl.com>; Wed, 6 May 2020 12:46:38 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1191E3A0AC2 for <sidrops@ietf.org>; Wed, 6 May 2020 12:46:38 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 89F0437D50 for <sidrops@ietf.org>; Wed, 6 May 2020 19:46:37 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 54F9856412FC; Wed, 6 May 2020 15:46:37 -0400 (EDT)
X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24243.5147.589924.749920@oz.mt.att.com>
Date: Wed, 06 May 2020 15:46:35 -0400
From: Jay Borkenhagen <jayb@braeburn.org>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@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> <m2pnbim4a3.wl-randy@psg.com> <730ce7ed-928b-19e6-cfa3-a5a2eddb03df@verizon.net>
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/56VGmgpzNYEja8QDPKiQV2nHMmc>
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: Wed, 06 May 2020 19:46:40 -0000
Stephen Kent writes: > These are all valid questions. The WG needs to decide if per-RP > variance, based on fetch timing, local cache failure, etc. meets the > goal of uniform RP processing of RPKI data. I am agnostic on this point. > Recently I had attempted to gauge if there was WG consensus along these lines: Each validation run of each RP MUST generate the same set of Validated ROA Payloads (VRPs) when presented with identical input, using unexpired records from the most recent successful retrieval to deal only with complete failure to retrieve from a PP. Now I have come around to agree with Job's perspective that coarse behavior like 'rsync --delete' is not what RPs should do. An RP should not assume that objects missing in any PP retrieval are the fault of the responsible CA. The objects could be missing due to fault of the CA, problems reaching the PP, or other potential causes, and the RP cannot know which one it was. If the RP's cached objects can fill in the gaps, that's great. Thus I now feel the straw proposal I offered above is too restrictive. I would still want different RP implementations to be 'deterministic' such that they produce the same VRPs, but only when operating on an identical local cache (including an empty cache as one important case). Thanks. Jay B.
- [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 George Michaelson
- Re: [Sidrops] proposed, revised text for Section 6 Randy Bush
- Re: [Sidrops] proposed, revised text for Section 6 Job Snijders
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Job Snijders
- Re: [Sidrops] proposed, revised text for Section 6 Randy Bush
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Oleg Muravskiy
- Re: [Sidrops] proposed, revised text for Section 6 Jay Borkenhagen
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Randy Bush
- Re: [Sidrops] proposed, revised text for Section 6 Tim Bruijnzeels
- Re: [Sidrops] proposed, revised text for Section 6 Tim Bruijnzeels
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Job Snijders
- Re: [Sidrops] proposed, revised text for Section 6 Stephen Kent
- Re: [Sidrops] proposed, revised text for Section 6 Oleg Muravskiy