Great! Thanks! > On 23. Nov 2022, at 17:20, Jean Quilbeuf <jean.quilbeuf@xxxxxxxxxx> wrote: > > 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
