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

Tim Bruijnzeels <tim@nlnetlabs.nl> Mon, 06 August 2018 08:17 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7E4130DFF for <ietf@ietfa.amsl.com>; Mon, 6 Aug 2018 01:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.132
X-Spam-Level:
X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs-nl.20150623.gappssmtp.com
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 saAg862OKrSq for <ietf@ietfa.amsl.com>; Mon, 6 Aug 2018 01:17:18 -0700 (PDT)
Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C45130E10 for <ietf@ietf.org>; Mon, 6 Aug 2018 01:17:16 -0700 (PDT)
Received: by mail-ed1-f67.google.com with SMTP id s16-v6so4686661edq.12 for <ietf@ietf.org>; Mon, 06 Aug 2018 01:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs-nl.20150623.gappssmtp.com; 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; d=1e100.net; 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=Z+YYabiHLhHWGhQJX+narDdxSW7I3ao4tK1XsrWzSksKb7nErFmM0G9Pv9yKdSH3C0 lwIcZUShlfITtRtXSOFJVbFziiOT3m2UVFFdihVcj8Ecn4H1evYDXFguE6/Mnlh75Fb3 Yha3E1e/e3+DEmhnGrpxVBfuA9yNGZo0Cmz+VIcF5+6zT7pQfkFxFR9pqzx+CiGncICk 4vd5tWSOqGZr92Z2mWwS8uLWn+e49CwS9MBBKKgimrKlaG4piKf8VSnzyRpLkGjQGKXT FoEJlUhrlsSWDZqFddNt8L+XGKm0EW5+2PnVd7T72wsPe/4oYBBHMdUBm/Jru2SiZmF4 q0QQ==
X-Gm-Message-State: AOUpUlGyC9wh4M6FgSrZtf+g3EmshfbS6qWqSTwRGaKm6qs8IOESPxim tiMS4vUJ3RvUf2agjQfu/2QmHA==
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 smtp.gmail.com with ESMTPSA id p20-v6sm4478866edr.12.2018.08.06.01.17.13 (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\))
Subject: Re: Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <153332707807.18413.5304119074828612207@ietfa.amsl.com>
Date: Mon, 6 Aug 2018 10:17:12 +0200
Cc: gen-art@ietf.org, sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2FB55BF-696D-40C2-89CC-4758FC10EE7D@nlnetlabs.nl>
References: <153332707807.18413.5304119074828612207@ietfa.amsl.com>
To: Linda Dunbar <Linda.dunbar@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pJzebXqz1mtdGAsFi2V3e-G_SYI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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 <Linda.dunbar@huawei.com> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> 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
>