[sidr] AD Review of draft-ietf-sidr-slurm-04

Alvaro Retana <aretana.ietf@gmail.com> Mon, 29 January 2018 18:21 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3571712D7F1; Mon, 29 Jan 2018 10:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WkaKb1Aktt2C; Mon, 29 Jan 2018 10:21:22 -0800 (PST)
Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 5D44912D7EC; Mon, 29 Jan 2018 10:21:14 -0800 (PST)
Received: by mail-ot0-x243.google.com with SMTP id p36so7420854otd.10; Mon, 29 Jan 2018 10:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=4Q3DyewObuN/Uz4IeJtZGJzJLlbpwPbDsaPgMq8k2g4=; b=o3BgMm1Nj43lx8f0ZUmfKvc4PvWhYFVoiWhbYlEzp29Lj4RC2AQ1F83GZnSYnacHFC yv/bjJD42Pm93GBddezQdCvnf6Ug8lHL0cv6/tCUifA5FyEn/4SEv4/FQozs0BmASgKm LTNviFv8n6I8yQv0CDTz9QOOLmt3/GYRy3NRloZyw3jghheBATgEWvHC+J7u/cBfRfPS MF05+bblyr0svHTXywl4tICEGd9yzzxG+xChpANNkH2pJ2wmru4Di3iRGAuclnzS3gpW miRzRZixJt2cOb5eTHpH3FZ8TGTZ+Yme0XKpGd1O9Qsp7AbTIr1jvMniAjO3mXTNH8us pKaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=4Q3DyewObuN/Uz4IeJtZGJzJLlbpwPbDsaPgMq8k2g4=; b=ar/Y3sbk++YI5HQ7+iJWwvnW7Wsch3Oi9vmzLCgE00BbjgT6oTLomxmAU24o2Mwemt rIayc45zZpOHEXipIaiabY1OqocJKZliVk2fa6TL1U1u60JO5fUb8HN5FFs9BDBRsZ/w r8TmIBfbAnYKDzZzgEFjJp+RBsHH2jV0OWKiPMgex904bp9q+Kdr3E/ZOh3zqkJJNWi1 CdaKRmCGeflJ1oPkYSlY0F7SPPa9ECJ/SqkcxmUkcToZR5E452VBrxEawzxqYDnrRSv7 g4s+/dYHu3MT+DSV+BE59Ha54Yml3H+MO8bSj22wjuFSYBHi2QQEFyJdE8uNBL9Em5Gx TgOA==
X-Gm-Message-State: AKwxytcwTWrhhPtje3vQsJj8JTAlVcACUqB6S9G19FBb1xcfJFJN3dnx +g7FlL+zJvrF7y1TE9LQe5HJVEPkacnoTLcL8eE=
X-Google-Smtp-Source: AH8x227IaAqNKCx/+e5e3DYA8pjujOuMijVtjAsQjHcQJwjbRlgW/HB7A2uhTZixywktVMKwYIPPvBrY+/h0HFlLXRA=
X-Received: by with SMTP id s28mr19018464ots.317.1517250073509; Mon, 29 Jan 2018 10:21:13 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Jan 2018 10:21:13 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Mon, 29 Jan 2018 10:21:13 -0800
Message-ID: <CAMMESsw1i_Am0UOS0Tx6yfz7kb_jsaxhMZtu5rcsoM4cDeVfkw@mail.gmail.com>
To: draft-ietf-sidr-slurm@ietf.org
Cc: sidr@ietf.org, sidr-chairs@ietf.org, Chris Morrow <morrowc@ops-netman.net>
Content-Type: multipart/alternative; boundary="001a113e4d2aaac6740563ee4f2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/K7y1URe1tkh78vjHhZHAIJJ6L4M>
Subject: [sidr] AD Review of draft-ietf-sidr-slurm-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 29 Jan 2018 18:21:25 -0000

Dear authors:

I just finished reading this document.

I have some comments (below) that should be easy to address — please take a
look.  I need you to address the References before I start the IETF Last
Call because of the DownRef to rfc6483.




M1. Section 3.1:  I'm not sure what the Normative result is form this piece
of text: "JSON members that are not defined here MUST not be used in SLURM
Files, however Relying Parties SHOULD ignore such unrecognized JSON members
at the top level, while any deviations from the specification at lower
levels MUST be considered an error."  (s/MUST not/MUST NOT)  If the not
defined members MUST NOT be used, when would the RPs not ignore (or even
better, treat as errors) them?  IOW, why use SHOULD instead of MUST?

M2. Section 4.2: "Before an RP configures SLURM files from different source
it MUST make sure there is no internal conflict among the INR assertions in
these SLURM files.  To do so, the RP SHOULD check the entries of SLURM
file..."  I think there's a Normative mismatch: "MUST make
sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the
door open to not always checking -- are there cases when the entries
wouldn't be checked *and* the MUST can still be guaranteed?  It seems to me
like both keywords should be MUST.

M3. Section 6: "...but if the RP updates its SLURM file over the network,
it MUST verify the authenticity and integrity of the updated SLURM file."
 Please indicate that the mechanism to update files, and the
authentication/integrity verification are outside the scope of this

M4. References:

M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.

M4.2. I believe the following references should also be Normative:
ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and

M4.3. [minor] Please update the references according to the Nits [1].



P1. "Relying party software MAY modify other forms of output in comparable
ways, but that is outside the scope of this document."  If it's out of
scope, then there shouldn't be any Normative language. s/MAY/may

P2. "Locally Added Assertions" are sometimes called "Locally Adding


N1. s/control make use of RPKI data/control use of RPKI data