Re: [Sidrops] 6486bis: Failed Fetches

Nick Hilliard <> Thu, 27 August 2020 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FD583A0DA6; Thu, 27 Aug 2020 08:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZdwZjyGnu79Q; Thu, 27 Aug 2020 08:16:35 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31CA13A0DCC; Thu, 27 Aug 2020 08:16:34 -0700 (PDT)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 07RFGW3o090024 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2020 16:16:32 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
To: Stephen Kent <>
References: <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Thu, 27 Aug 2020 16:16:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.27
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Thu, 27 Aug 2020 15:16:37 -0000

Stephen Kent wrote on 27/08/2020 16:07:
> When I the WG chairs tell me that I misunderstood the WG consensus re 
> strict correctness then I will revisit this topic. However, the recent 
> messages from Mikael and Job suggest that your perception of WG 
> consensus is not accurate. This issue is one that needs to be decided by 
> network operators, not by developers of RP software. I agree with the 
> observations made by Mikael and Job, i.e., that requiring strict 
> conformance with manifest rules is the preferred approach.

I concur - strictness is generally desirable when dealing with data 

In this case, the manifest problem was harmless and the data integrity 
was unaffected.  Speaking as an operator and rpki consumer, what I don't 
have good handle on is whether the manifest checks that would be 
required to detect the problem that happened at ARIN would also detect 
actual manifest integrity problems.  If the answer to this is yes, then 
there is no question about whether these checks should be added to the 
code bases that currently lack them.  Otherwise they are a nice-to-have, 
and I'd very much like to see them added.