Re: [Sidrops] trying to limit RP processing variability

Job Snijders <> Fri, 03 April 2020 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95BF73A1AE0 for <>; Fri, 3 Apr 2020 09:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pokJL03-hVWh for <>; Fri, 3 Apr 2020 09:26:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67DD43A1ADD for <>; Fri, 3 Apr 2020 09:26:52 -0700 (PDT)
Received: by with SMTP id m17so9197449wrw.11 for <>; Fri, 03 Apr 2020 09:26:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( []) by with ESMTPSA id c18sm12455204wrx.5.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2020 09:26:50 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id 12915645; Fri, 3 Apr 2020 16:26:47 +0000 (UTC)
Date: Fri, 03 Apr 2020 16:26:47 +0000
From: Job Snijders <>
To: Stephen Kent <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] trying to limit RP processing variability
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,