Re: [sidr] rpki-tree-validation vs. madi-sidr-rp

Declan Ma <madi@zdns.cn> Sat, 02 July 2016 09:45 UTC

Return-Path: <madi@zdns.cn>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88B12D0F7 for <sidr@ietfa.amsl.com>; Sat, 2 Jul 2016 02:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 IOdkn1UmRFqq for <sidr@ietfa.amsl.com>; Sat, 2 Jul 2016 02:45:35 -0700 (PDT)
Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (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 BCFEC12B035 for <sidr@ietf.org>; Sat, 2 Jul 2016 02:45:34 -0700 (PDT)
X-TM-DID: 88b81b6e0460de022ccb184a2e5ddd50
Content-Type: text/plain; charset="gb2312"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Declan Ma <madi@zdns.cn>
In-Reply-To: <D0D28E42-F00F-4A8A-8158-0893543275ED@ripe.net>
Date: Sat, 02 Jul 2016 17:41:06 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D24BA225-37E5-4C36-924B-2320B7C397E6@zdns.cn>
References: <0891ea5b-6a68-581d-7f5c-0e6f71fe76d2@bbn.com> <E95FB6AF-2BF6-448A-8FF1-80CBCAAE577C@zdns.cn> <D0D28E42-F00F-4A8A-8158-0893543275ED@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/xHmskdKHk6_57RqyWyZJhygKiGY>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] rpki-tree-validation vs. madi-sidr-rp
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Jul 2016 09:45:39 -0000

Tim, 

> 在 2016年6月30日,22:46,Tim Bruijnzeels <tim@ripe.net> 写道:
> 
> Hi,
> 
> The point that I was trying to make, but maybe not clearly, is that rpki-tree-validation is indeed intended as an Informational document specifically detailing our implementation only, but that the RP implementers discussed earlier during WG sessions that we might want to create a generalised RP requirement, or even BCP validation document at a later stage. So I was just somewhat surprised to see this come up.
> 

Sorry that I did not let you know we were doing the RP I-D in advance. 

Thank you and Oleg for kicking off the topic on RP implementation by writing rpki-tree-validation :-)


> That being said, we are all busy, so I have no problem with you taking the lead in the effort to document the generalised RP requirements instead. Especially as an Informational document referencing the authoritative docs - as it seems to do.


Anyway, inputs from RP software implementers are quite important to the job of laying out the generalized RP requirements.  

Steve and I are therefore looking forwards to seeing contributions from the RP implementers.

Please let us know any improvements that should be made.

Di

> 
> Tim
> 
> 
>> On 30 Jun 2016, at 07:09, Declan Ma <madi@zdns.cn> wrote:
>> 
>> Hi, all,
>> 
>> Speaking as the co-author of ‘Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties’,
>> 
>> In addition to the clarification made by Steve, I would like to deliver a clear message here that this draft is intended to make the RP requirements well framed, which are segmented with orthogonal functionalities in different sections.
>> 
>> As such, those ‘functional components’ could be crafted and distributed across the operational timeline of an RP software . 
>> 
>> We would appreciate your comments on this document.
>> 
>> Di
>> ZDNS
>> 
>> 
>>> 在 2016年6月29日,02:19,Stephen Kent <kent@bbn.com> 写道:
>>> 
>>> Although I was not present at the BA SIDR meeting, I did participate remotely for one of the sessions. I recall the discussion of the I-D that tries to collect all of the RP requirements in one place, with cites to the sources of these requirements. It part, I recall folks at the mic arguing that this I-D was redundant relative to the existing WG document on tree validation. I don't think this is an accurate comparison of the two docs, although I agree that there is overlap between them.
>>> 
>>> RPKI tree validation describes how the RIPE RP software works. It includes references to 6 SIDR RFCs to explain why the software performs certain checks. The RP requirements doc cites 11 SIDR RFCs, plus the BGPsec (router cert) profile. Thus it appears that the requirements doc tries to address a wider set of RFCs relevant to RP requirements. More importantly, the requirements doc is generic, while the tree validation doc is expressly a description of one RP implementation. Thus it is an example of how that implementation tries to meet the RP requirements, not a general characterization of RP requirements.
>>> 
>>> 
>>> Thus I think it appropriate to proceed with both docs.
>>> 
>>> Steve
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr