É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. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
