[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.157.22.220 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. Thanks! Alvaro. Major: 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 document. 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 rfc7159. M4.3. [minor] Please update the references according to the Nits [1]. [1] https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt Minor: 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 Assertions". Nits: N1. s/control make use of RPKI data/control use of RPKI data
- [sidr] AD Review of draft-ietf-sidr-slurm-04 Alvaro Retana
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Sriram, Kotikalapudi (Fed)
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Di Ma
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Di Ma
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Di Ma
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Alvaro Retana
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Tim Bruijnzeels
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Di Ma
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Alvaro Retana
- Re: [sidr] AD Review of draft-ietf-sidr-slurm-04 Di Ma