Guidelines for Autonomic Service Agents
draft-ietf-anima-asa-guidelines-07

Thank you for the work on this document.

Many thanks to Martin Dürst for the ART ART review: https://mailarchive.ietf.org/arch/msg/anima/Qs2CgHSHTiKQwsqob4K_qP3ENw8/, and thank you to the authors for addressing Martin's comments.

Francesca

Thanks for this document, which was overall informative and easy to read. I do have a couple small comments.

1. While most terminology is clearly defined, I didn’t find any definition of “the decoupled mode” first referred to in §6.1.1. It’s possible to infer what’s meant from context, after reading a bit more, but this was a speed bump in an otherwise smooth ride. “Decoupled” and “coupled” occur several places thereafter. I did go and check the normative references, and AFAICT none of them define the term either.

2. Also in §6.1.1, you mention ensuring that ASAs are “well installed”. This suggests to the reader that ASAs might also be “poorly installed” and that the installation phase might somehow return that status as well, which seems dubious. My guess is that “well” could simply be dropped?

Thank you to Martin Dürst for the ARTART review.

"Autonomic domain" is defined in the Appendix B, but doesn't appear in the document body.  Could it be removed?

Apart from that, nothing to add that my colleagues haven't already said.

Thank you for addressing my DISCUSS and COMMENTs

==[ Remaining comment discussed on list.  Only minimally required primitives will be documented.

** Section 6.1.1
   A minimum set of primitives to
   support the installation of ASAs could be: install(list of ASAs,
   Installation_target_Infrastructure, ASA placement function), and
   uninstall (list of ASAs).

Would an explicit primitive for checking if an ASA is already installed be needed – that is, how does one deal with an install() if the ASA is already installed?

Firstly, thanks to Menachem Dodge for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-anima-asa-guidelines-04-opsdir-lc-dodge-2021-12-13/ - they are always helpful.

Also, thanks to the authors and WG for such a clear and readable document. 

I do have a few (non-blocking) comments:
Introduction:
O: "The net result should be significant improvement of operational metrics."
P: "The net result should be significant improvement *in* operational metrics."
C: I suspect that my proposed change doesn't actually fix my concern :-) To me, the original wording makes it sound like the result is an improvement in the metrics *themselves*, not what the metrics are reporting / representing. Perhaps something like "The net result should be significant improvement in operational performance" would be better? It's also entirely possible that it was just that it's just me, so...


O: "In this document, we use an explicit multi-threading model to describe operations."
C: I think that adding something along the lines of "This is done to illustrate the concepts; implementations are free to use whatever features and methods achieve the results" or similar. Perhaps something like this could actually be added to the previous sentence ("Different programming environments support asynchronicity in different ways.")? I've often seen implementers look at the pseudo-code / requirements, and then just start coding from that, without stopping to consider if their tooling provides features / paradigms that do accomplish the same thing, but better (e.g complex even driven systems when goroutines / channels would be more idiomatic).

O: "5.  Design of GRASP Objectives"
C: This is sort of a meta comment (/potentially a larger topic) -- the title of the document is: "Guidelines for Autonomic Service Agents", and the abstract says "This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks." But, much of the content (including this section) feels like it isn't *really* about the design of the ASA, but more of general guidelines for AN / GRAPS / etc. 
I fully agree that it is useful content, but perhaps the title of the document should be changed, or the non-ASA guidelines bits could all just be put in a new document?). Note that, as with all of my comments, this is just a comment / thought / suggestion (I won't be sad / offended if you disagree / reject it) 

Thanks again, 
W

I didn't find any transport related issues in this specification, Thanks for the well written document.It was easy to follow with those appendixes.

Thank you for the work put into this document. I find it quite exhaustive and well explained.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education -- and after writing them, I spotted that some of them are overlapping with Warren Kumari's ballot), and some nits.

Special thanks to Toerless Eckert for the shepherd's write-up including the section about the WG consensus. 

I hope that this helps to improve the document,

Regards,

-éric

-- Section 1 --
Should "ANIMA" be expanded at first use ? Or should it be replaced by "ANIMA WG" ?

In "The net result should be significant improvement of operational metrics" is the concept of "operational metrics" well understood by the readers ? Why not simply "operational cost" ? 

-- Section 3.1 and 3.2 --
Their last paragraphs would benefit if there were some explanations about their assertions.

-- Section 3.3 --
There are some repetitions around the data structures used by ASA but this is OK.

I am more concerned by the implicit model used by the document with kernel/user space as well as the multi-threaded loop. While I understand that this is of course quite common for generic computers (and possibly high end devices), what about constrained devices ? I must admit that I am venturing outside of my comfort zone here...

-- Section 4 --
In "whether ASAs are deployed once per physical node or once per virtual context", isn't this part more generic ? I.e., should it be stated outside of section 4 ?

-- Section 5 --
Interesting and useful section but I wonder whether it fits a document about ASA.

-- Section 6 --
The way I am reading the section is that the life cycle only considers a monolithic piece of software. Should there be a mention about partial (e.g., just a library) update ?

Should there be any linkage with SUIT WG ?

-- Section 8 --
Should the periodic retry include a random portion ?

== NITS ==

-- Section 4 --
I found that 2 consecutive sentences starting with "An ASA whose purpose is to manage" are weird.

Thanks for the updates in the -06; by and large they look good
(especially the resolution to my Discuss).

I may still have some lingering confusion about Installation Hosts,
though -- in Section 6.1.1 we write:

   *  [ASA_placement_function] specifies how the installation phase will
      meet the operator's needs and objectives for the provision of the
      infrastructure.  This function is only useful in the decoupled
      mode.  It can be as simple as an explicit list of Installation
      Hosts, or it could consist of operator-defined criteria and
      constraints.

But I think, in light of the context in which this appears, it would
make more sense to say "can be as simple as an explicit list of hosts
on which the ASAs are to be installed" (or perhaps a variant that uses
the "[List_of_hosts]" spelling of the following paragraph).
On the other hand, I could just be suffering from having previously confused myself
by reading the -05, and maybe this is actually fine for someone reading
it for the first time.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

Thanks to Thomas Fossati for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ohsgWQpj39CLR4OuF6XAWQGpGpA).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.4. , paragraph 3, nit:
> iques such as network function virtualization or network slicing, there will
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ("virtualization" and "virtualisation")
within a single text.

Section 6.2. , paragraph 2, nit:
>  explained in detail in the next sub-section: [instances of ASAs of a given
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 6.3. , paragraph 5, nit:
> del; as noted in Section 5, YANG serialized as CBOR may be used directly as
>                                  ^^^^^^^^^^
Do not mix variants of the same word ("serialize" and "serialise") within a
single text.

Section 12.2. , paragraph 4, nit:
> nda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568
>                                 ^^^^^^^^^^^^^^
Do not mix variants of the same word ("virtualization" and "virtualisation")
within a single text.

Section 12.2. , paragraph 14, nit:
> ix B. Terminology This appendix summarises various acronyms and terminology
>                                 ^^^^^^^^^^
Do not mix variants of the same word ("summarise" and "summarize") within a
single text.

Document references draft-ietf-core-yang-cbor-17, but -18 is the latest
available revision.

These URLs in the document can probably be converted to HTTPS:
 * http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf

No need to respond to this, whether or not you like the suggestion:

In Sec. 2, the statement "Autonomic service agents must never fail" is jarring, and comes across as wishful thinking. The rest of the document, especially Sec. 8   explains things well. However, changing this to something like "Failure of a service agent would likely have severe consequences" might be more descriptive.