IETF Logo Mail Archive

Re: [Sidrops] [WG ADOPTION] draft-va-sidrops-deploy-reconsidered-01 - ENDS 08/11/2019 (Aug 11)

Tim Bruijnzeels <tim@nlnetlabs.nl> Sun, 15 September 2019 20:46 UTC

Return-Path: <tim@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 11F6512008F for <sidrops@ietfa.amsl.com>; Sun, 15 Sep 2019 13:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 Ksrj44PAz89n for <sidrops@ietfa.amsl.com>; Sun, 15 Sep 2019 13:46:31 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB971200B5 for <sidrops@ietf.org>; Sun, 15 Sep 2019 13:46:31 -0700 (PDT)
Received: from node-1w7jr9qt27svf000hkf8gjsln.ipv6.telus.net (node-1w7jr9qt27svf000hkf8gjsln.ipv6.telus.net [IPv6:2001:569:7bf2:6400:885d:59ac:785d:378b]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 535AA2AB85; Sun, 15 Sep 2019 22:46:21 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1568580388; bh=/rMkXy7jcsy9ts7IaEzcAOVwLXOVDD16sdAZd+NRikU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=roMPcVBATnWbqvWd96aZWt6MI8hpLx0OxOwAyg69dOTYiYEvjH3nT+s7VHkCYyX0p gW+VsxW3JWGr6GMRTN0IMeXdDr6XONlO17ljgMKt5uIyZiwmJjInOioNYR5iaSwLSM 7IMvX8pg8Q+no/dweyBNwVa37aE+J9DIejNbclXs=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m2tv9dwj77.wl-randy@psg.com>
Date: Sun, 15 Sep 2019 13:46:13 -0700
Cc: Nick Hilliard <nick@foobar.org>, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0AAA353-B3F5-409D-A949-15E5CB053694@nlnetlabs.nl>
References: <yj9o7e8bjdaj.wl-morrowc@ops-netman.net> <aed96e4a-0ba3-20e3-7412-c7d62cd6d193@foobar.org> <1d35c5cd-7303-3ac5-49c8-87f478a61a4e@verizon.net> <2f64752b-40df-892a-5c31-d460f147c264@foobar.org> <6062D822-A075-43DC-B7E0-841F824BDF80@nlnetlabs.nl> <m2tv9dwj77.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/4_etYCndYIvyfol7YZzTOj6itNY>
Subject: Re: [Sidrops] [WG ADOPTION] draft-va-sidrops-deploy-reconsidered-01 - ENDS 08/11/2019 (Aug 11)
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: Sun, 15 Sep 2019 20:46:33 -0000

Hi Randy, all,

> On 15 Sep 2019, at 10:41, Randy Bush <randy@psg.com> wrote:
> 
>> I think the real tragedy here is not the use of the term "Certificate
>> Authority"
> 
> i strongly agree.  imiho, this whole validation reconsidered path is of
> no brnefit and, through complexity, offers opportunity for harm.

While I do not agree with this, I respect that you bring this up. In fact I think that establishing that there is no consensus for having a discussion about the deployment of RFC8630 is much more constructive to the adoption question.

> this document tries to sugar coat a vile pill.

What this document tries to do, is to make it clear how, by example, RFC8630 could be deployed into the existing RPKI infrastructure, and what the consequences would be, so that we can have a constructive debate about how and why this would offer benefits and/or risks.

That being said, if there can be no consensus that we can even have that discussion because the goal of deploying RFC8630 in itself is rejected, then I don't see much point in spending more energy on this.


Tim



> 
> randy

v2.23.0 | Report a Bug | By Email