Hi Mirja, Thanks for your reviews, we tried to address your comments iniline. The diff is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-12 Best, Jean > -----Original Message----- > From: Mirja Kühlewind via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Thursday 17 November 2022 18:43 > To: tsv-art@xxxxxxxx > Cc: draft-ietf-opsawg-service-assurance-architecture.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Subject: Tsvart last call review of draft-ietf-opsawg-service-assurance- > architecture-11 > > 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. > Done > - 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. > Done > - 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. > > Removed -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
