Thanks Warren, some personal responses in line...
On 18-Jan-22 04:16, Warren Kumari via Datatracker wrote:
...
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...
You're right, the metrics are a by-product! A small rephrasing would help.
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).
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).
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)
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
Thanks again,
W
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
