Reviewer: Mirja Kühlewind Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document described an architecture to manage assurance graphs. The architecture consists of an orchestrator, a collector, and agents, that collect and share measurement data. Measurements rely on existing protocols. Measurement load is not discussed in the document but there might be an underlying assumption that no additional measures are deployed for this architecture beyond those already used today. Communication between the different entities relies on YANG but is otherwise not further discussed in the document. However, there seems to be an underlying assumption that events trigger updates, rather than e.g. regular polling or frequent pushing of updates. But this might be out of scope for this architectural document. Still, additional network loads due to measurement and signalling traffic between the different entities could potentially at least be discussed in the security considerations section. Otherwise there are no transport related aspects in this document. Some minor general comments: - It seems the document relies on RFC8309 for the definition of service model and RFC8969 for the definition of network model. Therefore these document could be considered as normative reference. Alternatively, these terms could be added to the Terminology section. - In section 3.1.1 in the third paragraph "https://kubernetes.io"; appears suddenly in the text. Is that supposed to be a footnote? Why does the example need to talk about one specific product at all? It could just say "a cloud-based computing cluster" or something. - The sentence in the security consideration section "As such, it should not cause any security threats." seems nonsensical to me. I guess nothing that we develop "should" cause any security threats. Recommend to remove that sentence. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
