Hi Éric, thnaks for the comments. In line...
On 19-Jan-22 06:02, Éric Vyncke via Datatracker wrote:
-- Section 1 --
Should "ANIMA" be expanded at first use ? Or should it be replaced by "ANIMA
WG" ?
Good catch. I think that both occurrences in the text should just be
"Autonomic Networking" rather than an IETF acronym.
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" ?
Warren made the same point. Will rephrase.
-- Section 3.1 and 3.2 --
Their last paragraphs would benefit if there were some explanations about their
assertions.
We could refer to specific sections of RFC8995 and RFC8994.
-- 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...
Two points. One is that strictly speaking, constrained nodes are out of
scope according to the reference model (RFC8993). The second is that yes,
you are surely correct. That's why the Introduction says:
"ASAs installed in constrained devices will have limited functionality.
In such cases, many aspects of the current document do not apply."
We should perhaps remind the reader of that in section 3.3.
-- 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 ?
Maybe the section title is wrong?
-- Section 5 --
Interesting and useful section but I wonder whether it fits a document about
ASA.
See my reply to Warren on the same point.
-- 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 ?
Won't that depend on the environment? E.g. whether an ASA is a compiled
image, or a Python script. Perhaps we should add a comment that library
updates must be considered as part of a solution design.
Should there be any linkage with SUIT WG ?
As noted above, IoT (constrained) devices are considered out of scope,
so formally, no. However, a designer would IMHO be pretty silly not
to consider SUIT, especially when designing a manifest. But I don't
see anything useful to add to the draft about this: suggestions
welcome, of course.
-- Section 8 --
Should the periodic retry include a random portion ?
Yes, and/or exponential backoff, which is recommended in a couple
of cases in the GRASP spec.
== NITS ==
-- Section 4 --
I found that 2 consecutive sentences starting with "An ASA whose purpose is to
manage" are weird.
Ack
Regards
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
