[Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)

Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 16 October 2019 15:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1350C12002E; Wed, 16 Oct 2019 08:19:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.105.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com>
Date: Wed, 16 Oct 2019 08:19:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/NdZpgqoC1ZwdcAdCp42NU7tCu6E>
Subject: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 15:19:08 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use
this solution."  The use of Normative language seems out of place: if this
document is not applicable to constrained environments, then there's no way to
enforce (SHOULD NOT)...   s/SHOULD NOT/should not

(2) §2.1: In Figure 2, should the "rejected" action be a result of step 3
(instead of 2)?

   |                   |
   |            +------v-------+
   |            | (2) Identity |
   ^------------+              |
   | rejected   +------+-------+
   |                   |
   |            +------v-------+
   |            | (3) Request  |
   |            |     Join     |
   |            +------+-------+
   |                   |

(3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in
[IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended
field in [IDevID].   Note that SHOULD is not used properly here because it does
not have a Normative quality (as it refers to the other document).  I'm
assuming that the replacement is "recommended" (per rfc2119), but it may be
"required".

(4) [nits]

s/Bootstrapping to is complete/Bootstrapping is complete

§1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all
operations secure by default."  Satisfies the what?  Requirement, maybe?

s/explains the details applicability/explains the detailed applicability

s/out-of-band" information"/out-of-band" information

s/This section applies is normative for uses with an ANIMA ACP./This section is
normative for uses with an ANIMA ACP.

s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer
Usage Description Specification

s/might be previous deployed/might be previously deployed

s/were receives by/were received from

s/{{...}}/[...]