Last Call Review of draft-ietf-anima-asa-guidelines-04
review-ietf-anima-asa-guidelines-04-genart-lc-fossati-2021-12-06-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-anima-asa-guidelines-??
Reviewer: Thomas Fossati
Review Date: 2021-12-06
IETF LC End Date: 2021-12-13
IESG Telechat date: Not scheduled for a telechat

Summary:

The document contains guidance for building ASAs.  It discusses
different kinds of requirements and their impact on the software
architecture.  It looks like an useful doc to have.

In general, the document reads very well, with the exception of Section
6 - see "Minor issues" below.

Major issues:

Minor issues:

In Section 6.3, I have followed the reference to
draft-peloso-anima-autonomic-function and I noticed that the content of
Section 6 has been transplanted nearly as-is from there.  So, to avoid
redundancy, I wonder whether that content should be given the same
treatment as you do in Section 7 WRT draft-ciavaglia-anima-coordination?
Or maybe you want to re-think the approach and have Section 7 do similar
copy&paste from draft-ciavaglia-anima-coordination?  They are both
individual and expired draft after all so it's probably better doing the
latter.

I also wonder whether it is worth to spell out explicitly the fact that,
given ASAs may need to co-exist with the actual networking application,
they should be build to require minimal memory footprint &, in general,
use system resources with parsimony.  A related question is whether ASAs
require dedicated system resources in order to continue operating in a
busy system?

Nits/editorial comments:

Section 2.

   *  Repeatedly flood an objective to the AN, so that any ASA can

Expand "AN" on first use.

   These threads should all either exit after their job is done, or
   enter a wait state for new work, to avoid blocking others
   unnecessarily.

"blocking others unnecessarily" is not what would typically happen,
maybe "to avoid wasting system resources" ?

   [...] It
   should also do whatever is required to avoid unnecessary resource
   consumption, such as including an arbitrary wait time in each cycle
   of the main loop.

I am not sure what "arbitrary wait time" refers to?  Is it a "sleep(n)"
at the end of each iteration of the main loop?  I think it's the
parsimony principle what you want to highlight here, and the first part
of the sentence is sufficient for capturing that without going into
concrete examples.

Section 3.3

   This API is intended to support the various interactions expected
   between most ASAs, such as the interactions outlined in Section 2.
   However, if ASAs require additional communication between themselves,
   they can do so using any desired protocol, even just a TLS session if
   that meets their needs.  One option is to use GRASP discovery and

What is the meaning of "just" in "just a TLS session"?  Also it's not
clear what kind of messages would flow through this additional channel
and if there are any requirements in terms of their security properties.

   [...] As
   noted above, the ACP can secure such communications, unless there is
   a good reason to do otherwise.

Maybe s/can/should/ and drop "unless ... otherwise"?

Section 6.1.1.

The typography used here to define inputs is a bit odd.  And in general
the whole section probably needs some more attention from an editorial
point of view.

Section 6.2

   the agent piece of code (when this does not start automatically) and

Maybe drop "piece of".

Section 6.2.1

   The operator's goal can be summarized in an instruction to the ANIMA
   ecosystem matching the following format:

      [instances of ASAs of a given type] ready to control
      [Instantiation_target_Infrastructure] with
      [Instantiation_target_parameters]

Maybe better to move this at the beginning of Section 6.2.2.

Section 6.2.3

As in Section 6.1.1., the typographic style used here is a bit odd /
unconventional.

Section 6.3

   Note: This section is to be further developed in future revisions of
   the document, especially the implications on the design of ASAs.

Is this note still valid?  (I hope not :-) )

Section 10

   of robustness that ASA designers should consider

Maybe stick a colon at the end of the line.

   1.   If despite all precautions, an ASA does encounter a fatal error,
        it should in any case restart automatically and try again.  To
        mitigate a hard loop in case of persistent failure, a suitable

Terminology: what do you mean by "hard loop"?

   8.   On the other hand, the definitions of GRASP objectives are very
        likely to be extended, using the flexibility of CBOR or JSON.
        Therefore, ASAs should be able to deal gracefully with unknown
        components within the values of objectives.

Is this in line with Section 6 of draft-iab-protocol-maintenance?
I.e., has GRASP clearly defined extensibility rules, or is this a call
for the ASA implementation to apply the robustness principle?

   At a slightly more general level, ASAs are not services in
   themselves, but they automate services.  This has a fundamental
   impact on how to design robust ASAs.  In general, when an ASA
   observes a particular state [1] of operations of the services/

"[1]" looks like a bib reference, please consider using an alternative
typography, e.g., "(1)", or "A"

Section 11

   ASAs are intended to run in an environment that is protected by the
   Autonomic Control Plane [RFC8994], admission to which depends on an
   initial secure bootstrap process such as [RFC8995].

s/such as BRSKI [RFC8995]/

   In particular, they must use secure techniques and carefully
   validate any incoming information.

"secure techniques" could be unpacked a bit, for example: "secure coding
practices" (e.g., input validation, least privilege, etc.), "secure
configuration practices" (e.g., default deny).

Appendix C

   An implementation requirement is that resource pools are kept in
   stable storage.  Otherwise, if a delegator exits for any reason, all
   the resources it has obtained or delegated are lost.  If an origin
   exits, its entire spare pool is lost.  The logic for using stable
   storage and for crash recovery is not included in the pseudocode
   below.

Is there a further requirement for the storage to be shared across all
ASAs?  What I am wondering is whether a shared global map of the current
resource allocations exists to help reconstructing a partitioned
topology (in case one ASA disappears)?  Or is the delegated resource
recall, in case the ASA delegator fails, handled by GRASP?