IETF Logo Mail Archive

Re: [Sidrops] Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist

gengnan <gengnan@huawei.com> Tue, 10 October 2023 09:25 UTC

Return-Path: <gengnan@huawei.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 A525CC151090 for <sidrops@ietfa.amsl.com>; Tue, 10 Oct 2023 02:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTIRQyvDEQru for <sidrops@ietfa.amsl.com>; Tue, 10 Oct 2023 02:25:30 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D15C14CE5F for <sidrops@ietf.org>; Tue, 10 Oct 2023 02:25:30 -0700 (PDT)
Received: from lhrpeml500004.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S4VqS5zBdz6K7GH for <sidrops@ietf.org>; Tue, 10 Oct 2023 17:25:08 +0800 (CST)
Received: from dggpemm500005.china.huawei.com (7.185.36.74) by lhrpeml500004.china.huawei.com (7.191.163.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 10 Oct 2023 10:25:27 +0100
Received: from kwepemm000009.china.huawei.com (7.193.23.227) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 10 Oct 2023 17:25:25 +0800
Received: from kwepemm000009.china.huawei.com ([7.193.23.227]) by kwepemm000009.china.huawei.com ([7.193.23.227]) with mapi id 15.01.2507.031; Tue, 10 Oct 2023 17:25:24 +0800
From: gengnan <gengnan@huawei.com>
To: Russ Housley <housley@vigilsec.com>, SIDR Operations WG <sidrops@ietf.org>
Thread-Topic: [Sidrops] Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist
Thread-Index: AQHZ9xGqfSZOYs13L0y64jdeDsdNtrBCsR/g
Date: Tue, 10 Oct 2023 09:25:24 +0000
Message-ID: <31299507980d4993999d5afe00c6f611@huawei.com>
References: <SA1PR09MB8142D5B0AFE288F6494E27E68403A@SA1PR09MB8142.namprd09.prod.outlook.com> <4FBF5BF5-3D0F-4FF2-82E9-C2F542C90E5D@vigilsec.com> <ZMBkDwMIN3Fg8HSO@snel> <0AC6301E-9C37-4DF6-9F22-D86D085724B6@vigilsec.com>
In-Reply-To: <0AC6301E-9C37-4DF6-9F22-D86D085724B6@vigilsec.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qvH9310ctfqPuvzlqFYPE6E4_SQ>
Subject: Re: [Sidrops] Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 10 Oct 2023 09:25:34 -0000

Hi,

I support the adoption of the draft. There exist valuable scenarios of prefixList. 

Repeat my comments in previous emails:
What can we do when data conflicts between ROA and prefixList are detected? (The problem is interesting although it is not the focus of the draft.)
For example, ROA authorizes prefix P1 only to AS1, but AS2 includes P1 in its prefixList. Either ROA or prefixList is wrong. 
Both ROA and prefixList are "one-way" authority. Are there any operational considerations about that?

Best,
Nan

> -----Original Message-----
> From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Russ Housley
> Sent: Thursday, October 5, 2023 6:24 AM
> To: SIDR Operations WG <sidrops@ietf.org>
> Subject: [Sidrops] Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist
> 
> There was discussion of draft-spaghetti-sidrops-rpki-prefixlist at IETF 117 and
> some discussion on the mail list.  This message starts a two-week call for
> adoption of that document. Please say whether you support adoption by
> Wednesday, 18 October 2023.
> 
> For the SIDRops WG Chairs,
>   Russ
> 
> 
> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.46.0 | Report a Bug | By Email | System Status