[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:
----------------------------------------------------------------------

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 a few easy-to-address issues 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?

— Section 6.7.5 —

   A baseline ACP node MUST support IPsec natively and MAY support IPsec
   via GRE.  If GRE is supported, it MAY be preferred over native IPec.

But Section 6.7.3.2 says:

   If IKEv2 initiator and responder support IPsec over GRE, it has to be
   preferred over native IPsec.

Which is it?  “MAY” be preferred?  Or “has to be preferred”?

— Section 6.10.6 —

   IANA is asked need to assign a new "type" for each new addressing
   sub-scheme.  With the current allocations, only 2 more schemes are
   possible, so the last addressing scheme MUST provide further
   extensions (e.g., by reserving bits from it for further extensions).

I don’t understand the first sentence.  It doesn’t parse, for one thing, so
please fix that.  And it would be better to clearly match it with the
corresponding request in the IANA Considerations section.

For the second sentence (the DISCUSS part), I’m very skeptical that this is the
right approach: if you’re already acknowledging that “only” 2 schemes are
possible now, it seems time *now* to prepare the way for additional ones,
rather than waiting.  What’s the reasoning for putting in a warning rather than
just doing it, especially as you’re setting up a new registry anyway?


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

— Section 6.8.2 —

   GRASP unicast messages inside the ACP are transported
   via TLS which MUST comply with [RFC7525] execept that only TLS 1.2
   ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is RECOMMENDED.

This ties into my earlier comment about text that seems to tie this to the TLS
version.  I strongly recommend that you say early on (not here in 6.8.2) what’s
here in the quoted text and elsewhere: that, for TLS and DTLS, 1.2 is REQUIRED,
1.3 is RECOMMENDED, and 1.1 and earlier MUST NOT be used.  Include text “up
there” about backward compatibility and making sure 1.2-only situations can be
accommodated via negotiation.  Possibly add a sentence about supporting
post-1.3 versions when they are developed.  And then don’t say anything about
versions elsewhere in the document.

— Section 6.10.1 —

   o  Addresses in the ACP are not considered sensitive on privacy
      grounds because ACP nodes are not expected to be end-user host.

Is there something missing here?  This looks like an incomplete sentence.  Or
should it just be “end user hosts”?  If that’s it, I suggest wording it as
“...not expected to host end users.”  It might also help to say, “ACP nodes are
part of the data center infrastructure [or some such] and are not expected...”

— Section 6.11.1.7 —

   Global Repair: we assume stable links and ranks (metrics), so no need
   to periodically rebuild DODAG.  DODAG version only incremented under
   catastrophic events (e.g., administrative action).

This is one of the most egregious of the poor-grammar issues in the document. 
I’m generally not happy with expecting the RPC to turn text like this into
proper English, and wish that working groups would be more careful about it. 
Something like this, in this case, perhaps?:

NEW
   Global Repair: we assume stable links and ranks (metrics), so there is
   no need to periodically rebuild the DODAG.  The DODAG version is only
   incremented under catastrophic events (e.g., administrative action).
END

And is administrative action really an example of a catastrophic event?  It
would seem that administrative action would be a *response* to such an event. 
What’s an example of an event itself?  Or is it “catastrophic” that’s the wrong
word, maybe?

(The “Local Repair” paragraph also has some incomplete sentences and missing
articles.)

— Section 6.12.5.1 —

   2.  IPv6 implementations do commonly not allow to assign the same

A common English usage issue: “allow to assign” (in general, “allow
<infinitive>”) doesn’t work in English, because the infinitive needs a subject
(“allow <some entity> to assign”).  If you don’t have a subject to put there,
you can say, “IPv6 implementations commonly do not allow assignment of the
same...” (which also fixes the issue that “commonly” shouldn’t split “do not”).

— Section 8.1.1 —

   interface looks like a normal network interface (without any
   encryption/novel-signaling).

What is “novel-signaling”?

   This is sometimes called "RPF filtering".  This MAY be changed
   through administrative measures.

Two things here:  One is that this feels like a “may” (or “might” or “can”... a
statement, not a directive) rather than a BCP 14 key word.  The other is that I
don’t follow what it is that may be changed: what does “this” refer to in the
second sentence?