Re: [Sidrops] trying to limit RP processing variability

Job Snijders <job@ntt.net> Fri, 03 April 2020 16:26 UTC

Return-Path: <job@instituut.net>
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 95BF73A1AE0 for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 09:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 pokJL03-hVWh for <sidrops@ietfa.amsl.com>; Fri, 3 Apr 2020 09:26:53 -0700 (PDT)
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DD43A1ADD for <sidrops@ietf.org>; Fri, 3 Apr 2020 09:26:52 -0700 (PDT)
Received: by mail-wr1-f51.google.com with SMTP id m17so9197449wrw.11 for <sidrops@ietf.org>; Fri, 03 Apr 2020 09:26:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=1PV2BERHF6atQgHkOhGnWm9sxQ1gEGOyDtLE7bu8HzE=; b=sRk5OZ98js0us1SJNnghlkXezode42R+MiLK/r2cBy/KX04M+oojT6kRfjp2oq+QDG 5hDZ2Md/MjPt3z2bq/jADN2jhkQSqhuLOdj+rKK86EQsrVh20Fd4McV12ZH4zEcbjPJo BCooGQvFOyTsJsSFmrUNrdU15irBxdkXviJAtp9zJMjFeRPksbSKHNfImhpoFCu98jcv qrOD9u6GnrQhzR7855NpmE35fDyj/Yy+2LX/9jimUuLH7NO9kDNezcKnFXezMT7I8Y3w hAXYqYkGahJ0MuGPEfdqtKMA7tn0GQmii388OmwhKa3des5rpLBCdcbGdCg3x/VR3IdV EYhA==
X-Gm-Message-State: AGi0Pua4vkL3RouQBuKRJ+3qwYXXLqRJjvrqGnBIJxfnmpGrxlm0Fzkk wLz/60I+XMs4IdsrIIyO16ZYN0IC4Lc=
X-Google-Smtp-Source: APiQypIPXGA3gIVVsQvcw28Bq6ljao1YeG1I85iet8AZRoccJaThkqIZQmkXWdW5QKBLw7Ln3V+z/g==
X-Received: by 2002:adf:f8c1:: with SMTP id f1mr10132235wrq.345.1585931211090; Fri, 03 Apr 2020 09:26:51 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id c18sm12455204wrx.5.2020.04.03.09.26.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 09:26:50 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 12915645; Fri, 3 Apr 2020 16:26:47 +0000 (UTC)
Date: Fri, 3 Apr 2020 16:26:47 +0000
From: Job Snijders <job@ntt.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200403162647.GH60268@vurt.meerval.net>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/IMzQvQCjtCSTvQf6PjIVX3_PEF0>
Subject: Re: [Sidrops] trying to limit RP processing variability
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: Fri, 03 Apr 2020 16:26:55 -0000

Dear Stephen,

Thank you for spearheading this initiative. It is helpful to see the
various permuations for which a decision tree needs to be constructed
laid out in this way.

On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:
> *Terminology*
> 
> Valid: a signed object (other than a certificate or CRL) is deemed
> *valid* if it is encoded in a fashion consistent with the relevant
> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
> signature can be verified consistent with RFC 6488.
> 
> Current: A CRL or Manifest is *current* if the current date & time is
> before the Next Update date and the CRLNumber (or ManifestNumber) is
> greater than any prior, valid CRLs or Manifests processed by the RP.
> 
> Stale: A CRL or Manifest is stale if the current date & time is later
> than the Next Update date. A stale CRL or Manifest is not “expired”
> it’s just not as current as it is supposed to be. The case analysis
> below examines what to do when a Manifest, or CRL, or both are stale.
> 
> Missing: an object named in a Manifest, but not available for download
> from a PP, is termed *missing*. An RP has no obvious way to acquire
> missing objects, but operators SHOULD be warned about which objects
> are missing.
> 
> Corrupted: if an object named in a Manifest, is available for download
> from a PP, but it’s hash does not match the corresponding value in the
> Manifest, the object is termed *corrupted* and the object SHOULD be
> ignored.

Can you also provide a definition for your use of the word 'invalid'? I
see the phrase used in the case analysis permutations.

Kind regards,

Job