[Anima] Barry Leiba's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

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 6.7.3.1.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.