Re: [Sidrops] 6486bis: Failed Fetches
Jay Borkenhagen <jayb@braeburn.org> Wed, 02 September 2020 18:34 UTC
Return-Path: <jayb@oz.mt.att.com>
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 97F823A0CC0 for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 11:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=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 BOTvDRhy_qtA for <sidrops@ietfa.amsl.com>; Wed, 2 Sep 2020 11:33:59 -0700 (PDT)
Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C27C3A0CBE for <sidrops@ietf.org>; Wed, 2 Sep 2020 11:33:59 -0700 (PDT)
Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 268202C607 for <sidrops@ietf.org>; Wed, 2 Sep 2020 18:33:59 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id EFAF25640A3A; Wed, 2 Sep 2020 14:33:58 -0400 (EDT)
X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24399.58769.547600.368430@oz.mt.att.com>
Date: Wed, 02 Sep 2020 14:33:53 -0400
From: Jay Borkenhagen <jayb@braeburn.org>
To: sidrops@ietf.org
In-Reply-To: <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net> <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net> <24393.25181.84151.476185@oz.mt.att.com> <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net>
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/R01LYGsNgdy6hK9WpWc6bIt77fE>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Wed, 02 Sep 2020 18:34:01 -0000
Steve, Stephen Kent writes: > The crux of the issue is whether it is preferable to reject all objects > at a pub point if an error is detected (until the error is rectified), > and thus potentially treat many more routes as having an unknown > verification status, or to accept bits and pieces of data from a pub > point with the potential that some routes will be treated as valid, even > if they are invalid. To me, that is a value judgement to be made by > network operators, not by developers of RP software. [...] No, there is a bit more to it than that. I want my network's routers and those of all other networks to be fed with VRPs that represent all the verified and legitimate published origin-ASN intentions of verified, legitimate IP number resource holders. Clearly the challenge there is in determining "verified" and "legitimate." In creating the rules (to be documented in standards-track RFCs) for those determinations, I would like the input of all SIDROPS participants to be valued, including the input of the RPKI designers, the CA- and RP-implementers, the RIRs, and the network operators. To my point: if RP-implementers feel that the "bits and pieces of data" (to use your words) should be considered to best make those determinations, such input should be welcomed; conversely, if RP-implementers feel that strict publication rules and accompanying strict handling of retrieved records together create the best way to make those determinations, we all should listen to what they have to say. > Experience with X.509 cert extensions suggests that the approach I noted > is preferable. Saying that older RPs can ignore objects they don't > understand introduces ambiguity in RP behavior, which is precisely the > concern that motivated the effort to generate 6486bis. Ambiguity is bad in any technical endeavor where precision is needed. And we're here discussing this now because there was ambiguity in rfc6486 (not assigning blame -- I missed it, too). But I don't see how it follows that if/when ASPA (for example) is standardized, that older RPs should be required to throw away all records retrieved from PPs whose MFTs now cite ASPA records. Thanks. Jay B.
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- [Sidrops] 6486bis: Failed Fetches Martin Hoffmann
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Martin Hoffmann
- Re: [Sidrops] 6486bis: Failed Fetches George Michaelson
- Re: [Sidrops] 6486bis: Failed Fetches Di Ma
- Re: [Sidrops] 6486bis: Failed Fetches George Michaelson
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Martin Hoffmann
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Nick Hilliard
- Re: [Sidrops] 6486bis: Failed Fetches Randy Bush
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Jay Borkenhagen
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Di Ma
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Jay Borkenhagen
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels
- Re: [Sidrops] 6486bis: Failed Fetches Stephen Kent
- Re: [Sidrops] 6486bis: Failed Fetches Christopher Morrow
- Re: [Sidrops] 6486bis: Failed Fetches Tim Bruijnzeels