Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Di Ma <madi@rpstir.net> Wed, 13 May 2020 16:32 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 309023A0E01 for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 09:32:59 -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 1FLLzCc9Z3g0 for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 09:32:56 -0700 (PDT)
Received: from out20-63.mail.aliyun.com (out20-63.mail.aliyun.com [115.124.20.63]) (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 079523A0D5B for <sidrops@ietf.org>; Wed, 13 May 2020 09:32:51 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1080928|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.220448-0.000482922-0.779069; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03298; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HY5PrXY_1589387562;
Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HY5PrXY_1589387562) by smtp.aliyun-inc.com(10.147.42.241); Thu, 14 May 2020 00:32:44 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Date: Thu, 14 May 2020 00:32:20 +0800
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5994380C-4DEF-4EBC-8707-69AF0E4F1617@rpstir.net>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> <m2imh0x750.wl-randy@psg.com> <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qUMUAep0BMPH5VSq138VljBBAkI>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 13 May 2020 16:33:06 -0000

I am in favor of Steve’s preference on behalf of RPSITR 2 implementation.

If we don’t place strict constraint on the RPKI provisioning side, we will see more inconsistence among RPs.

Di

> 2020年5月14日 00:11,Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> 写道:
> 
> Guys,
>>> I will revise the text describing how to handle this case, based on WG
>>> consensus. Your approach is very robust, but also complex. Since there
>>> should be only one CRL in the manifest, and since Tim says that no
>>> RPKI CA generates more than??? one, I tend to favor a simple
>>> requirement here, but ...
>> indeed no ca SHOULD push more than one CRL.  but i do not think i would
>> recommend not defending against it.
>> 
>> randy
> 
> I think we all agree that the revised Section 6 text needs to accommodate the possibility that a manifest will list more than one CRL, even though this OUGHT NOT happen (see RFC 6919). The only question?? is how hard do we require an RP to work if it encounters more than one CRL. I prefer a simple approach to selecting one, and a mandatory warning. Rob has offered a more sophisticated, and complex approach, based on his working RP code.
> 
> I await a consensus from the WG.
> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops