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 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
