Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Sat, 05 September 2020 18:07 UTC

Return-Path: <stkent@verizon.net>
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 5C6713A0B9A for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 ECiuqIgtuPg2 for <sidrops@ietfa.amsl.com>; Sat, 5 Sep 2020 11:07:20 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF953A0B93 for <sidrops@ietf.org>; Sat, 5 Sep 2020 11:07:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1599329238; bh=DmDWqkIVvhFUCXSrS551BWp+vhicLybq/5JHuyLKn5w=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=IeIcjXUKiT6+STseD5SuR3UkZpINDFIJ9XWZo5CqXn9ZU6utBkxLlUN+KH/Uvjkuhs8n1jHO21DZT/BeQ968typyP7OENCIXRRwVMnS7nVOxx8dr38MKtlINPnX2lXAMpz5q9hDtyx9PkDXXuuzmpgZ8IQGH+H32LT4c9VU8yWVfply7kvmvTZnz6nX2/mDShiT+e+PaMen2zDWqQEZ/SSa/uODvRdeVe/SQCJPwzi6yPpKCfqbsatX7xLvMmShVvUR07YOAPQY5vAI3J8LHPIPMJOnGbm+Z/P3lepfCiIjv02cSizxKDHAGXnmWKShBokjx8H7xLwRwsbDgRpKaJQ==
X-YMail-OSG: NVUpvqsVM1mio979fyXpNqkBc5yJv4RdMFJwle4TE3wwTBLacG__bH6n73u6YLK J4LIwZcdi1KJbtbUz0vMfGlhLYo9.uyMlnEm4kqpjhJdOLmVEhP8qLCAGMUpcD5XswGjzQOHykpz hPVgNnIiNMS7ves4iE0Eiy6YdwwMYKOiJaccH7wOGE1h1w5shJTRhuhF125U.T8.miGre_N4nmEl WD7wRFD_0ShqgCF84CNx6i608Y6O7kHXhVgb9DcYm_Lke1Se0qOdPBuMRDshmsNPmSoenrY3xlr7 IRpfWbZfhLIvqAjo2Em3Yk.B3_JqpflymT.FzHH9dQJvMp1dBNcZcpsIj_yPbTzQlicunTaaRb15 nAseExvLTuks4dfHF658uqYY3W2pjEQLdDq1pOjQebfLLCrerQjfWum8pPkSgBQk7vuPLCvJYM2i ZAQYeLUeCM1GePyr2UQIT6mV1L7da8.9FFuB4lNPZHNXcs84RQz3HKTgqUyRtZp.lN_ecPJbc9E_ 9vWtAK9UaviyMCBu5BqSinoU7fig9WVuPcNoOU8_8Fo.eufeIHNixZXydye6BMIGZCSW.fiZ17JL N7031F7qfCPS33FigwddvXtyuI7W842V9LWtiQkCikyvG1SX1BFYtw16X9HxV8zwVBoFj2y_aA10 _Vlsc5n.TA8MB8HLb.YmYkqX1sVl9.MKzgPZDV2mja9PVG7XshJU63JczdA1t60Ck_5cN8os7SY5 V5g2CLqWz0lim7l86b7NaSzKKL_YFM7Gq.s51pwOMmCCSrx47k9t.qFNXNOE9U5o6fesS9kNNjdG jB22vdulKdMlWmHJtFpjAnP7ahdkMLJTuvCqCUB09kYopCpFQFvxg_Wx3ywqU69ZucDD.TJ91MCB 1fc8kzIKc6hk9nQsxwyZgThT5U8ml4dk37U.C6IbTCbbBrUOkmBZMCMFhg4A05iDOajX_vSxLOYk hPmFW9Jo3Al5p.7NSJui5FoNqZoXd7JZ62gAB_kHtQhmB3OOWlS9Xl4B17qEIV4BcuzBuG2CKec6 BiFJRRGZhZ3m7NTPLS64Ngay.j4GED11dAhqfuJUwpbk62D7sYUxfwk4M.DUZ2oWK6_EUpAkyxIe MGCy6jSZ8I_byCxk7MDvr4O1vcjHDv7mKzFY2Yj71Y_9QeGOmAQTImxZaUWexrPukLHE26pWMJPP UuFRtJA7IBNBWqCIW.UZ5Q7rv1rO.dVKlu7TXiUbqK6_KZW.VkZzDZPVQewU85JA1.wuTc016nkj 6_n_AyQPbhub8ClIhpgi4H8KI20lYFxTcPrMG9bj8g0EwlFwEya1w591GUSa8a86hmDqBnQ7EE8E JnFOm7CV0IpCwzgb_l7Rh6n3N3CJYLqt5pWb3OrL1pOfeYI6IaFFyN71qAxk0o92fwm7M676zUUm _yh.prLzdcpEgzqUOE0pnhcGYjBNYNr2rt2gA715MNJ85ChSzCBzgy4JBXTZ0Lyy4jtFAkYprxoZ FZDNK_YRY8g5vo1ZqV.5jfvlILhkkyUzcIYBuKFgfkq0HH6NTpIbbVrhhgnT3Oe.HHowFwGd4TVS z1n5tI1h7QUfgsJaTm4fZDTg-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Sat, 5 Sep 2020 18:07:18 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 408f46627a2546e15d319d1b4548c1fd; Sat, 05 Sep 2020 18:07:17 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: sidrops@ietf.org
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> <24399.58769.547600.368430@oz.mt.att.com>
Message-ID: <4f1dd854-3adc-e9f0-c818-186c7ac613d0@verizon.net>
Date: Sat, 5 Sep 2020 14:07:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <24399.58769.547600.368430@oz.mt.att.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/u-zSp8A8pHIN-uRflXlsvF50WQI>
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: Sat, 05 Sep 2020 18:07:22 -0000

Jay,
> ...
>
> 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.
Sorry, but I beg to differ on this point. My judgement of what is 
critical to the "best" operation of an ISP is not as valuable as that of 
an experienced network operator. On the other hand, my judgement on what 
constitutes secure operation in a PKI context, is, IMHO, more valued 
than that of most folks. We each have our strengths and limitations and 
these ought to be taken into account when valuing inputs to a standard 
like this. That's what I expect the WG chairs to do when reviewing 
comments on the list.
>   > 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.

I quickly reviewed the ASPA ID. I didn't see a description of how the 
RPKI is used to validate these newly-proposed, signed objects.  Until 
that is made clear, it isn't clear why an ASPA even belongs in the RPKI 
repository system. So, your question seems premature.

Steve