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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Mon, 17 Jan 2022 07:16:22 -0800

Warren Kumari 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:
----------------------------------------------------------------------

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2022 09:01:41 +1300

Thanks Warren, some personal responses in line...

On 18-Jan-22 04:16, Warren Kumari via Datatracker wrote:
...

> was just that it's just me, so...

You're right, the metrics are a by-product! A small rephrasing would help.
  
> when goroutines / channels would be more idiomatic).

We did go into this more explicitly in the API (RFC8991) as noted
in the following sentence. But I do agree, we should make this point
more clearly (also in the appendix with the pseudocode).

> won't be sad / offended if you disagree / reject it)

Personal opinion: Designing a GRASP Objective in the abstract, without
designing the ASA at the same time, is a Bad Idea. So, you're correct
that the reach of this document is a bit wider than its title suggests.
As it says, it's "a contribution to the description of an autonomic
networking ecosystem". IMHO, if this technology takes off, we should
be back in a few years working on a broader description of the
ecosystem, and that would probably replace this one.

Thanks again
     Brian