Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02

Tim Bruijnzeels <> Mon, 06 August 2018 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 301C5127598 for <>; Mon, 6 Aug 2018 01:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UA7ORu0bA25Z for <>; Mon, 6 Aug 2018 01:17:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0330D130DFF for <>; Mon, 6 Aug 2018 01:17:16 -0700 (PDT)
Received: by with SMTP id e19-v6so4688863edq.7 for <>; Mon, 06 Aug 2018 01:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ut2+G5gua7O0/Kwp8TZ/RGwwpA5fgOF622jsS1BuV1k=; b=bjv8gLJFKkF1bnRngUZjYSzFuXLsl57WdjBxMs3xvB7WwGGMMQE+9UxEi0UJjYsdIT v5E6vrCbKocRkVxxgYs45XuntFTnba1d5osEccAiRN186o0/I+dWSqR/d+NpXyDh7U3B d8f/+BN+iQjqgIfyW8jQAtANh9wJKFDgQKWzDhCSSws8bZwRsJCBU4BwGrmOMJDYeVMh oXkbnVtGOubdT2pugxB8A18upjusccSflniSfpbYjG5NgIgALQNAU6Djaf/UxDmyP21b YH2nqvyQButK2OaFqEZpJ95NQI5vyl3MWY6ihhPKMo/B5mOiHQVYHdJdIxn3uTQKQ9gY VtbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ut2+G5gua7O0/Kwp8TZ/RGwwpA5fgOF622jsS1BuV1k=; b=ab2hvQ3M3CDBWyFL9jgRJGECW6JCZsMg2zNmyIircjLzVg7TzOPJ4kWJ+0AT7AOJig PwvgK+GDOM/bvTupb17eMmj0p2yu6uRyeFlKcSmFPNzMIyANbh9pDYlTancK28g2jN8/ GtNPnQOs1VC9CAFjVcsbygUmPzKHEypxax95D8Dw5I+Uf66VWJZuFcRbgVdCvxbnD7pl deVerEg4v8rcBJjnWsukeg290xU87CIDwUs4IlHnlbboK6J6peOvkawyLxt69bi7J/wN /QmLEAK1LodYpniqjlJtS7KDjjaBVijRqIRJW3a3lX6Zpygdc4ZQSZP0srDyQaS+d28J 1xdg==
X-Gm-Message-State: AOUpUlH4YB0AVoVbF3LlaB3RbmORIp0/XXeZIPaSoqK3bbbQAwc4GLHw pve+ci0nAnon7+ezoQMbTPz0Ew==
X-Google-Smtp-Source: AAOMgpcgQFl5zLKZWyNkYq5mPj1IwKB9g3OfukqTJPX7xGx2tJbFwdg9M2AL3cYytRr8mZ6H0VEB7w==
X-Received: by 2002:aa7:db09:: with SMTP id t9-v6mr17154897eds.277.1533543434545; Mon, 06 Aug 2018 01:17:14 -0700 (PDT)
Received: from ?IPv6:2a04:b900::1:7cdd:3f51:b924:7877? ([2a04:b900:0:1:7cdd:3f51:b924:7877]) by with ESMTPSA id p20-v6sm4478866edr.12.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 01:17:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Mon, 06 Aug 2018 10:17:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Linda Dunbar <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Aug 2018 08:17:19 -0000

Hi Linda,

We took this to the WG because we wanted a few things out of it:
1) get feedback and ensure that the algorithm used by our validator is correct (even if it is not the only way to do this)
2) provide transparency to our users
3) provide a reference that other Relying Party implementers might find useful

I believe that these goals were achieved. We received valuable feedback from the WG and had good discussions with other implementers.

Note that I say ‘we’ because I was involved in this while working at the RIPE NCC. By now I have a new position, and as such I don’t mind removing myself from the author list possibly in favour of someone who is going to be involved in the future of this particular implementation. Personally really I don’t mind very much whether this document becomes an RFC or not, it already served its main purposes #1 and #2, but it seems a relatively small remaining step to do and ensure #3 -> i.e. have a description of one implementation that others may find useful. Having it as an RFC rather than an expired draft, bundled with the software, will make it easier to find and it shows that others reviewed the document for clarity and correctness.

That said, it takes a lot of work and process from us, and everyone else. And by definition this is a moving target. The implementation will change (in fact v3 is just (about to be) released), and then the RFC is outdated. So, I will not opt for this full (informational) RFC path again for future implementations I am involved in. It would be nice if there were a more light-weight document track that could be used for this though! We really benefitted from the feedback and users have said that they like the transparency.

Kind regards,

Tim Bruijnzeels

> On 3 Aug 2018, at 22:11, Linda Dunbar <> wrote:
> Reviewer: Linda Dunbar
> Review result: Ready
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-sidrops-rpki-tree-validation-02
> Reviewer: Linda Dunbar
> Review Date: 2018-08-03
> IETF LC End Date: 2018-08-10
> IESG Telechat date: Not scheduled for a telechat
> Summary:
> This draft describes one sample implementation of validating the content of
> RPKI certificate Tree. The description is clear, especially clearly described
> which section of RFC6487 are based for its implementation.
> Major issues:
> None.
> Minor issues:
> None.
> Nits/editorial comments:
> Section 9.1. the Hash Collisions is more of design in-complete instead of
> "Security Considerations". So is the section 9.2 In addition, why the
> implementation description has to be an RFC? clog up the RFCs