[Anima] Barry Leiba's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
Barry Leiba via Datatracker <firstname.lastname@example.org> Wed, 12 August 2020 15:42 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB353A1367; Wed, 12 Aug 2020 08:42:49 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Barry Leiba via Datatracker <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com, Sheng Jiang <firstname.lastname@example.org>, email@example.com
Reply-To: Barry Leiba <firstname.lastname@example.org>
Date: Wed, 12 Aug 2020 08:42:49 -0700
Subject: [Anima] Barry Leiba's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2020 15:42:50 -0000
Barry Leiba has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-28: Discuss 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-autonomic-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I still have more to review here -- I'm about ⅓ of the way through -- but I wanted to get this in sooner, rather than waiting. This DISCUSS should be easy to resolve: it's mostly that I find the text in Section 6.5 related to Bob and Alice to be confusing and unclear. I see that EKR also found it so and asked for the step-by-step diagram, which does help. But I find the whole Bob/Alice thing to be messy and wish you could instead use some functionally descriptive terms for the roles, rather than using arbitrary names that aren't meaningful and lead the reader to say, "Wait, which one is Bob now?" Specifically: — Section 6.5 — The node with the lower Node-ID in the ACP address of its ACP certificate becomes Bob, the one with the higher Node-ID in the certificate Alice. A peer with an empty ACP address field in its ACP certificate becomes Bob (this specification does not define such peers, only the interoperability with them). What’s with “becomes Bob” and “Alice” here? Without any introduction I don’t know what’s going on. Do you mean something like, ‘One node has a lower Node-ID in the ACP address of its ACP certificate than the other. For this discussion, we will call that node “Bob”, and the other “Alice”.’ ? Or do you mean something else? And then what does the next sentence mean? For example, originally Bob could have been the initiator of one ACP secure channel protocol that Bob prefers and the security association succeeded. The roles of Bob and Alice are then assigned and the connection setup is completed. Again I’m confused: you’re talking about Bob doing something, and *then* the role of Bob is assigned? What does that mean? How can we talk about Bob doing something before we know who Bob is? And are there no more descriptive terms to use here, as opposed to “Bob” and “Alice”? Something like “initiator” and “responder”, or whatever, which might be easier to follow? I also have an easy-to-address issue here: — Section 126.96.36.199.2 — The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), listed as a SHOULD, is to be configured, along with the 2048-bit MODP (group 14). I don’t understand the requirement level here, because I’m not sure what “is to be configured” means. You mention “SHOULD”, but then “is to be configured” seems to say that it has to be supported. And you seem to be saying that he same requirement, whatever it is, applies to both group 19 and group 14... but I’m not certain about that. Can you please rephrase this to make the requirements clearer? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- We have to use “virtual out-of-band” more often, because “VOOB” is a great acronym. — Section 1 — is therefore intended to combine as good as possible the resilience Nit: this needs an adverb rather than an adjective, “as well as possible”. the ACPs functions instead of implementing them seperately for each Nit: “separately”. In the list that follows you should also put a comma after “traffic” to make it clear what the third list item is, as there are five “and”s in there. — Section 1.1 — Infrastructure (PKI) code for the ACP certificate, the GRASP protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and Why specifically TLS 1.2? Probably this should say “TLS” without a version, and reference the now-current TLS 1.3 spec (8446), but it shouldn’t be tied to a specific TLS version. Similarly, mentions of DTLS shouldn’t be tied to the version number. Alternatively for both, they could say “version 1.2 or greater”. I do see that some places in the document mention 1.2 as a minimum, so I'm just looking for a little clean-up here to make sure it's clear that we don't want to use <1.2, but anything from 1.2 on is fine. Plane itself would not need to change, it could continue to be IPv4 only. For such IPv4 only devices, the IPv6 protocol itself would be additional implementation footprint only used for the ACP. Nit: this is a comma splice. Either change the comma to a semicolon or change “, it” to “and”. Also, “IPv4-only” should be hyphenated when it’s a modifier, as it is in the second case (but not the first). I don’t understand “would be additional implementation footprint only used for the ACP.” I think “that is only used” would help, but I also don’t think “footprint” is the right word here. The ACP design can be applicable to (cpu, memory) constrained devices and (bitrate, reliability) constrained networks This is an odd use of parentheses, and it threw me at first, before I realized it’s an attempt at grouping and shorthand. Better to avoid it, as you also need some hyphens anyway: NEW1 The ACP design can be applicable to cpu- and memory-constrained devices and to bitrate- and reliability- constrained networks END Or if you find the hyphens awkward, maybe reword to avoid using modifiers: NEW2 The ACP design can be applicable to devices constrained with respect to cpu and memory, and to networks constrained with respect to bitrate and reliability. END (And I really don’t think the rest of the sentence (“but this document...”) adds anything, and I’d just skip it.) — Section 2 — Normative sections are labelled "(Normative)" and use [RFC2119]/[RFC8174] keywords. A small thing you can ignore if you like, but I would skip the citations here and just say, “and use BCP 14 key words.” You’ll have the proper citations with the boilerplate later. A CA uses its private key to sign the certificates it issues, relying parties use the public key in the CA certificate to validate the signature. Comma splice; please split the sentences. This signing certificate can be considered to be an identifier of the CA, so the term CA is also loosely used to refer to the certificate used by the CA for signing. Really? I’ve never seen a signing cert called a “CA”. In any case, I wouldn’t like to see that usage encouraged. Does this really need to be here? — Section 4 — ACP5: The ACP must provide security: Messages coming through the ACP must be authenticated to be from a trusted node, and should (very strong should) be encrypted. That last bit feels odd; I suggest instead, “and it is very strongly recommended that they be encrypted.” written ASA could potentially all communicate exclusively via GRASP Nit: “ASAs” — Section 6.1 — The LDevID certificate is called the ACP certificate, the TA is the Certification Authority (CA) root certificate of the ACP domain. Comma splice.
- [Anima] Barry Leiba's Discuss on draft-ietf-anima… Barry Leiba via Datatracker