Re: [Sidrops] 6486bis: referenced object validation

Benno Overeinder <benno@NLnetLabs.nl> Fri, 04 December 2020 13:13 UTC

Return-Path: <benno@NLnetLabs.nl>
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 C34BC3A0CDB for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 05:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 D9RHZ6pLpb0Q for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 05:13:46 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BF23A07DB for <sidrops@ietf.org>; Fri, 4 Dec 2020 05:13:46 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 49CD2602D8; Fri, 4 Dec 2020 13:13:44 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1607087623; bh=Ho91Wx4jst+MDdq+O2o3k/jadwFI9iUN7MZDOiHjeP8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=C7Tex+HKf+KvdbrlTVPhGN2orrk863oBKpGIPbDDgsQNCzvQaE3431I7riJg1XeOa WHzSdu5h8XLA/ezL5kW89w9/sxVxD1mU9IUkpuJ6LRI33FrZMDBB953AtquoT9RTAu WnjtTDLUMgE0fSg3tv8zZPHc5HRmJpnFgdPwKPBbzeebsxUGHWjYx65s11SSMTWxgz WlqnrX0zid3LoCacuk9umx+i187dJeRpzl/Rfby50TKcZIceEv3fb3lN9c5TCWEeAp ntsZDJhmV2DSm/i5+6U+JjEf1COh3TQplOdzdZcGbY8i/C0c8JVxYSPOVqwOhMvAdG AbpdGgO+/A81w==
To: Job Snijders <job@ntt.net>, Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <X8oSBlR1pDhX83nH@bench.sobornost.net> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <X8on7A4R63HYUnpz@bench.sobornost.net>
From: Benno Overeinder <benno@NLnetLabs.nl>
Message-ID: <d518f9de-850c-ad10-49a5-1eee4c85fa6b@NLnetLabs.nl>
Date: Fri, 04 Dec 2020 14:13:40 +0100
MIME-Version: 1.0
In-Reply-To: <X8on7A4R63HYUnpz@bench.sobornost.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/uQHudTinnMv5UDS5tdZQWlIxiPA>
Subject: Re: [Sidrops] 6486bis: referenced object validation
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, 04 Dec 2020 13:13:54 -0000

Hi Job, WG,

On 04/12/2020 13:13, Job Snijders wrote:
> On Fri, Dec 04, 2020 at 11:44:17AM +0100, Tim Bruijnzeels wrote:
>>> Indeed, I believe you've now captured the essence of why manifests
>>> exists at all. This is what rpki-client & FORT seem to have implemented.
>>
>> I suggested this in August:
>> https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk/
>>
>> I think a lot of this could have been avoided if we had this
>> discussion then, but I welcome this now..
> 
> Looking back I'm at a loss how "a lot of this" really could've been
> avoided. What additional steps or process should I have followed for
> NLNetLabs/RIPE/Cloudflare to sooner understand the problem with their
> implementation choices and encourage those organisations to provide a
> solution to their users?
> 
> As you know, I reported 'this' as a problem in February 2020 to sidrops@

</snip> timeline for brevity.

Your timeline is correct, as far as I have followed the discussions. 
The remark from Tim is meant to be constructive, not defensive.  Not 
looking back, but looking ahead, I want to focus on how we solve issues 
and discuss them in sidrops.  And indeed, if there is an impasse, 
organise a virtual meeting and discuss the matter to make progress.

> The real goal is to keep the network running, where in this context our
> role is to create software for network operators for them to securely
> validate the wishes of the Internet number resource holders.

Agree to that!

Let's keep the good spirit of collaboration and learning together.

Best regards,

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/