Last Call Review of draft-ietf-opsawg-service-assurance-architecture-11
review-ietf-opsawg-service-assurance-architecture-11-tsvart-lc-kuehlewind-2022-11-17-00

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@ietf.org 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.