Re: [sidr] Current document status && directionz

Tim Bruijnzeels <> Mon, 31 October 2016 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E552F12956A; Mon, 31 Oct 2016 08:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SvT2ssFF50jA; Mon, 31 Oct 2016 08:15:58 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 677DC1294D0; Mon, 31 Oct 2016 08:15:58 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c1EJW-0003Hk-IB; Mon, 31 Oct 2016 16:15:55 +0100
Received: from ([] by with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <>) id 1c1EJW-0000gv-BS; Mon, 31 Oct 2016 16:15:54 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Mon, 31 Oct 2016 16:15:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Christopher Morrow <>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ------------
X-RIPE-Spam-Report: Spam Total Points: -12.1 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719ef0570b6e825ce9caeae154070df25d3
Archived-At: <>
Cc: Chris Morrow <>,, "" <>, "" <>
Subject: Re: [sidr] Current document status && directionz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Oct 2016 15:16:00 -0000

Hi all,

> On 26 Oct 2016, at 17:35, Christopher Morrow <> wrote:
> which leaves to be dealt with by Chicago 2 documents:
> draft-ietf-sidr-rpki-tree-validation

You may have just seen the -03 version posted.

This version now includes a scope section to make it clear that:

   This document describes how the RIPE NCC RPKI Validator version 2.23
   has been implemented.  Source code to this software can be found
   here: [github].  The purpose of this document is to provide
   transparency to users of (and contributors to) this software tool, as
   well as serve to be subjected to scrutiny by the SIDR Working Group.
   It is not intended as a document that describes a standard or best
   practices on how validation should be done in general.

The full name of the document "RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator" was always clear on the scope. And we mentioned it at various occasions. The short name "RPKI Tree Validation" may be somewhat confusing - we are open to suggestions btw.. plus, if the IETF (SIDR-OPS most likely) wants to take on the work of making a general validation document, we would be happy to contribute to it in separate document.

We really value the feedback that we got from the working on this document. Although not all feedback is reflected in the current implementation (and therefore in the main body of the document) - we have included these discussions in the Security Considerations section. We believe that none of these issues qualify as showstoppers to the software described at this time, but we may well address them in future releases.

There was some discussion at the last IETF about how to deal with a document like this. It describes a moving target. Our implementation is subject to change after all.

We prefer to tackle it by going for last call on this document describing version 2.23 as soon as is allowed by IETF, in the SIDR WG. As far as we are concerned this is done. Of course if there is any remaining unclarity we will address.

If and when future releases of our software include significant changes in the validation algorithm, we plan to document transparently. Pragmatically speaking we believe that minor things can be documented in the README of future releases (.. works like RFC-### with these exceptions). For bigger changes however, or whenever our code stabilises again, we would probably seek to either update the existing document, or create a new document. We would prefer to run any such work through SIDR-OPS once established, but individual submission is also an option.

In the end what matters to us most is that we have a clear description of how the code works, and provide full transparency on considerations.

Kind regards

Tim & Oleg