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, 2 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>
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
Precedence: list

Tim,=20

> =D4=DA 2016=C4=EA6=D4=C230=C8=D5=A3=AC22:46=A3=ACTim Bruijnzeels =
<tim@ripe.net> =D0=B4=B5=C0=A3=BA
>=20
> Hi,
>=20
> 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.
>=20

Sorry that I did not let you know we were doing the RP I-D in advance.=20=


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. =20

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

>=20
> Tim
>=20
>=20
>> On 30 Jun 2016, at 07:09, Declan Ma <madi@zdns.cn> wrote:
>>=20
>> Hi, all,
>>=20
>> Speaking as the co-author of =A1=AERequirements for Resource Public =
Key Infrastructure (RPKI) Relying Parties=A1=AF,
>>=20
>> 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.
>>=20
>> As such, those =A1=AEfunctional components=A1=AF could be crafted and =
distributed across the operational timeline of an RP software .=20
>>=20
>> We would appreciate your comments on this document.
>>=20
>> Di
>> ZDNS
>>=20
>>=20
>>> =D4=DA 2016=C4=EA6=D4=C229=C8=D5=A3=AC02:19=A3=ACStephen Kent =
<kent@bbn.com> =D0=B4=B5=C0=A3=BA
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>=20
>>> Thus I think it appropriate to proceed with both docs.
>>>=20
>>> Steve
>>>=20
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>=20
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>=20
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr