Subject: [Anima] Éric Vyncke's No Objection on draft-ietf-anima-asa-guidelines-05: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 18 Jan 2022 09:02:09 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-anima-asa-guidelines-05: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-asa-guidelines/

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

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jan 2022 10:46:42 +1300

Hi Éric, thnaks for the comments. In line...

> Should "ANIMA" be expanded at first use ? Or should it be replaced by "ANIMA

Good catch. I think that both occurrences in the text should just be
"Autonomic Networking" rather than an IETF acronym.

> simply "operational cost" ?

Warren made the same point. Will rephrase.

> Their last paragraphs would benefit if there were some explanations about their

We could refer to specific sections of RFC8995 and RFC8994.
> about constrained devices ? I must admit that I am venturing outside of 
my

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.

> context", isn't this part more generic ? I.e., should it be stated outside of

Maybe the section title is wrong?

> Interesting and useful section but I wonder whether it fits a document about

See my reply to Warren on the same point.

> monolithic piece of software. Should there be a mention about partial (e.g.,

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

> I found that 2 consecutive sentences starting with "An ASA whose purpose is to

Ack

Regards
      Brian

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Jan 2022 12:57:56 -0800

> On 19-Jan-22 06:02, Éric Vyncke via Datatracker wrote:
[...]
> see anything useful to add to the draft about this: suggestions

For what little it's worth, I considered making a similar comment, but
decided not to, on the grounds that despite "software updates" being in the
WG name, the actual charter covers only firmware update, with the implicit
assumption that existing software lifecycle techniques are suit-able (pun
intended) for higher layers of the deployment stack.

That said, the SUIT techniques seem like they would be usable for this
purpose if someone chose to use them in that way.

-Ben