IETF Logo Mail Archive

Re: [Sidrops] 6486bis: Failed Fetches

Di Ma <madi@rpstir.net> Wed, 19 August 2020 12:29 UTC

Return-Path: <madi@rpstir.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 5D1033A08C7 for <sidrops@ietfa.amsl.com>; Wed, 19 Aug 2020 05:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7Byt_78-AF70 for <sidrops@ietfa.amsl.com>; Wed, 19 Aug 2020 05:29:07 -0700 (PDT)
Received: from out20-2.mail.aliyun.com (out20-2.mail.aliyun.com [115.124.20.2]) (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 C18F63A03F6 for <sidrops@ietf.org>; Wed, 19 Aug 2020 05:29:06 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08532675|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0103137-2.71311e-05-0.989659; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16378; MF=madi@rpstir.net; NM=1; PH=DS; RN=4; RT=4; SR=0; TI=SMTPD_---.IKCGVvG_1597840137;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.IKCGVvG_1597840137) by smtp.aliyun-inc.com(10.147.41.138); Wed, 19 Aug 2020 20:28:58 +0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <CAKr6gn2Ai0jM+ZPE86Nnw-Y4p7qnoY4Ce2TKqVDde5R0aC4-zw@mail.gmail.com>
Date: Wed, 19 Aug 2020 20:28:55 +0800
Cc: Martin Hoffmann <martin@opennetlabs.com>, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A06A42E-8379-4E28-8539-73B61F78A261@rpstir.net>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <CAKr6gn2Ai0jM+ZPE86Nnw-Y4p7qnoY4Ce2TKqVDde5R0aC4-zw@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FfDHV4GuNgpu1bN2bNINaTdKKzc>
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, 19 Aug 2020 12:29:09 -0000

George,

> 2020年8月19日 03:50，George Michaelson <ggm@algebras.org> 写道：
> 
> FYI we fully intend resubmitting RTA, we were waiting for the second
> implementation (the work Martin is doing) to have input of merit to
> spin the new version. It would be plausible to resubmit for the
> November IETF. Two running code!
> 
> We designed RTA to be complete outside of a repo, so it can be used
> privately between B2B partners. Not that its things cannot "be" on the
> manifest, but that there is no dependency on the repo framework beyond
> the TA, because the passed data is the chain for validation. This
> matters to people who want to conduct activity outside of the BGP
> validation problem, which is an 'all data needed' problem. B2B uses of
> RTA are not directly about all data. Its different. (provisioning is
> typically the use case here and the intent is to show the request to
> route, originate, provision is valid, because control of the resource
> can be demonstrated. its inherently a one-to-one conversation)

Do you mean RTA validator has nothing to do with RPKI repository sync, given the RTA use-case just requires the INR holder to provide all the necessary certificates to construct the validation path down to TA?

It reminds me of the similar model in RFC 6494 where the RPKI is used for IPv6 SeND. 

Di

v2.23.0 | Report a Bug | By Email