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.