[Anima] Alissa Cooper's No Objection on draft-ietf-anima-autonomic-control-plane-20: (with COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-20: 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-autonomic-control-plane/



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

Thanks for addressing my DISCUSS. Original COMMENT is left below.

General:

Please address the Gen-ART reviewer's latest round of comments.

There are a bunch of places in this document where it seems like there is a
tension between specifying a limited set of functionality here and being able
to support a wider variety of deployment scenarios. This is noted in Section 1
but I think in general it would be clearer if uses of the term "future"
throughout the document could be more surgical as well as more specific about
whether they mean "people might deploy this differently in the future" or
"standards would need to be developed in the future." I've made a few
suggestions about some of these turns of phrase below but would suggest someone
do a full edit pass with this in mind because there are a large number of
mentions of "future work." Of course there is always more work to do, but every
bit of "future work" need not be mentioned in this document, and in cases where
it is mentioned I think there should be a specific reason for doing so that
bears on people implementing this specification. I don't think this fits in the
DISCUSS criteria but for a document that intends to be published on the
standards track I would expect it to be crisper about the dividing line between
the normative behavior being specified here versus changes or extensions that
may or may not be made in the future.

"Intent" is used both capitalized and in lower case throughout the document and
I'm unclear if this is meant to signify a distinction or not.

Section 2:

Please remove the -->"..."() notation.

Please use the exact boilerplate from RFC 8174, not a variation.

It seems like RFC citations should appear for IKEv2 and DTLS upon first use in
this section. Otherwise, it seems they are first cited at different future
points in the document (Section 6.3 and 6.7, respectively).

Section 3.3:

"The ACP provides reachability that is independent of the Data-Plane
   (except for the dependency discussed in Section 6.12.2 which can be
   removed through future work),"

Isn't this kind of a big exception, given that there is meant to be a secure
channel between pairs of nodes in the ACP and that developing future
encapsulations is non-trivial? It seems like phrasing this the other way around
(the ACP is dependent on the Data-Plane for <XYZ> but is otherwise independent
of it) would be more accurate.

Section 6:

"Indestructible" seems like an overstatement. Maybe "resilient" would be more
accurate?

Section 6.1.1:

s/Such methods are subject to future work though./No such methods have been
defined at the time of publication of this document./

s/to build ACP channel/to build ACP channels/

s/that intends to be equally unique/that it intends to be equally unique/

""rsub" is optional; its syntax is defined in this document,
   but its semantics are for further study.  Understanding the benefits
   of using rsub may depend on the results of future work on enhancing
   routing for the ACP."

What is the point of defining this now when it is unclear if or how it will be
used? There are already means for nodes to do error handling, so it seems like
defining a new field in the future if/when it is needed would work fine and be
cleaner. Appendix A.7 seems to assume some semantics for this field, which
makes the way it is specified here even more confusing IMO.

"In this specification, the "acp-address" field is REQUIRED, but
   future variations (see Appendix A.8) may use local information to
   derive the ACP address.  In this case, "acp-address" could be empty.
   Such a variation would be indicated by an appropriate "extension".
   If "acp-address" is empty, and "rsub" is empty too, the "local-part"
   will have the format "rfcSELF + + extension(s)".  The two plus
   characters are necessary so the node can unambiguously parse that
   both "acp-address" and "rsub" are empty."

This seems contradictory. Either "acp-address" is REQUIRED in which case there
are no exceptions, or it's not; if it's not, then the expected syntax for cases
when it's not present should be specified.

Section 6.1.2:

s/If the node certificates indicates/If the node certificate indicates/

Section 6.3:

It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS.

Section 6.4:

This is a good example of a section where the blurring between the specified
behavior and expectations for the future is unhelpful IMO. Why specify the
current default and then spend a lot of words (including Appendix A.7) talking
about how it will be different in the future?

Section 6.10.3.1:

s/We do not think this is required at this point/This is not currently required/

Section 6.12.2:

s/may specify additional layer 2 or layer encapsulations/may specify additional
layer 2 or layer 3 encapsulations/ (I think?)

Section 8.2.1:

This seems extraneous: "Future work could transform this into a YANG
([RFC7950]) data
   model."

Appendix A.8:

"Secure channels may
   even be replaced by simple neighbor authentication to create
   simplified ACP variations for environments where no real security is
   required but just protection against non-malicious misconfiguration."

I think experience has shown that even environments where it is assumed that
security is not required prove to need it. I would suggest removing this text
or changing this implication.