Reviewer: Thomas Fossati Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-anima-asa-guidelines-?? Reviewer: Thomas Fossati Review Date: 2021-12-06 IETF LC End Date: 2021-12-13 IESG Telechat date: Not scheduled for a telechat Summary: The document contains guidance for building ASAs. It discusses different kinds of requirements and their impact on the software architecture. It looks like an useful doc to have. In general, the document reads very well, with the exception of Section 6 - see "Minor issues" below. Major issues: Minor issues: In Section 6.3, I have followed the reference to draft-peloso-anima-autonomic-function and I noticed that the content of Section 6 has been transplanted nearly as-is from there. So, to avoid redundancy, I wonder whether that content should be given the same treatment as you do in Section 7 WRT draft-ciavaglia-anima-coordination? Or maybe you want to re-think the approach and have Section 7 do similar copy&paste from draft-ciavaglia-anima-coordination? They are both individual and expired draft after all so it's probably better doing the latter. I also wonder whether it is worth to spell out explicitly the fact that, given ASAs may need to co-exist with the actual networking application, they should be build to require minimal memory footprint &, in general, use system resources with parsimony. A related question is whether ASAs require dedicated system resources in order to continue operating in a busy system? Nits/editorial comments: Section 2. * Repeatedly flood an objective to the AN, so that any ASA can Expand "AN" on first use. These threads should all either exit after their job is done, or enter a wait state for new work, to avoid blocking others unnecessarily. "blocking others unnecessarily" is not what would typically happen, maybe "to avoid wasting system resources" ? [...] It should also do whatever is required to avoid unnecessary resource consumption, such as including an arbitrary wait time in each cycle of the main loop. I am not sure what "arbitrary wait time" refers to? Is it a "sleep(n)" at the end of each iteration of the main loop? I think it's the parsimony principle what you want to highlight here, and the first part of the sentence is sufficient for capturing that without going into concrete examples. Section 3.3 This API is intended to support the various interactions expected between most ASAs, such as the interactions outlined in Section 2. However, if ASAs require additional communication between themselves, they can do so using any desired protocol, even just a TLS session if that meets their needs. One option is to use GRASP discovery and What is the meaning of "just" in "just a TLS session"? Also it's not clear what kind of messages would flow through this additional channel and if there are any requirements in terms of their security properties. [...] As noted above, the ACP can secure such communications, unless there is a good reason to do otherwise. Maybe s/can/should/ and drop "unless ... otherwise"? Section 6.1.1. The typography used here to define inputs is a bit odd. And in general the whole section probably needs some more attention from an editorial point of view. Section 6.2 the agent piece of code (when this does not start automatically) and Maybe drop "piece of". Section 6.2.1 The operator's goal can be summarized in an instruction to the ANIMA ecosystem matching the following format: [instances of ASAs of a given type] ready to control [Instantiation_target_Infrastructure] with [Instantiation_target_parameters] Maybe better to move this at the beginning of Section 6.2.2. Section 6.2.3 As in Section 6.1.1., the typographic style used here is a bit odd / unconventional. Section 6.3 Note: This section is to be further developed in future revisions of the document, especially the implications on the design of ASAs. Is this note still valid? (I hope not :-) ) Section 10 of robustness that ASA designers should consider Maybe stick a colon at the end of the line. 1. If despite all precautions, an ASA does encounter a fatal error, it should in any case restart automatically and try again. To mitigate a hard loop in case of persistent failure, a suitable Terminology: what do you mean by "hard loop"? 8. On the other hand, the definitions of GRASP objectives are very likely to be extended, using the flexibility of CBOR or JSON. Therefore, ASAs should be able to deal gracefully with unknown components within the values of objectives. Is this in line with Section 6 of draft-iab-protocol-maintenance? I.e., has GRASP clearly defined extensibility rules, or is this a call for the ASA implementation to apply the robustness principle? At a slightly more general level, ASAs are not services in themselves, but they automate services. This has a fundamental impact on how to design robust ASAs. In general, when an ASA observes a particular state [1] of operations of the services/ "[1]" looks like a bib reference, please consider using an alternative typography, e.g., "(1)", or "A" Section 11 ASAs are intended to run in an environment that is protected by the Autonomic Control Plane [RFC8994], admission to which depends on an initial secure bootstrap process such as [RFC8995]. s/such as BRSKI [RFC8995]/ In particular, they must use secure techniques and carefully validate any incoming information. "secure techniques" could be unpacked a bit, for example: "secure coding practices" (e.g., input validation, least privilege, etc.), "secure configuration practices" (e.g., default deny). Appendix C An implementation requirement is that resource pools are kept in stable storage. Otherwise, if a delegator exits for any reason, all the resources it has obtained or delegated are lost. If an origin exits, its entire spare pool is lost. The logic for using stable storage and for crash recovery is not included in the pseudocode below. Is there a further requirement for the storage to be shared across all ASAs? What I am wondering is whether a shared global map of the current resource allocations exists to help reconstructing a partitioned topology (in case one ASA disappears)? Or is the delegated resource recall, in case the ASA delegator fails, handled by GRASP? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
