Hi Bron, Thanks for the reviews. We tried to address your comments, see answers inline. The diff is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-12 Best, Jean > -----Original Message----- > From: Bron Gondwana via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Thursday 10 November 2022 18:04 > To: art@xxxxxxxx > Cc: draft-ietf-opsawg-service-assurance-architecture.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Subject: Artart last call review of draft-ietf-opsawg-service-assurance- > architecture-11 > > Reviewer: Bron Gondwana > Review result: Ready with Nits > > I'm the assigned ARTART reviewer for this document. > > Overall comments: > > The language is very verbose and dense. I found it quite a slog to read. > By the time I was half way through the first section, I was thinking "yeah, I > get it". I'm not sure that you need quite so much pre-amble to justify why > this is important. > > I also struggled to understand some of the long flow-on sentances such as: > > * Analyze the configuration pushed to the network device(s) for > configuring the service instance and decide: which information is > needed from the device(s), such a piece of information being > called a metric, which operations to apply to the metrics for > computing the health status. Changed to: * Analyze the configuration pushed to the network device(s) for configuring the service instance. From there, determine which information (called a metric) must be collected from the device(s) and which operations to apply to the metrics to compute the health status. > > I'm not sure if which bits of that quite apply to which. I'm also not sure that a > reader needs to understand it, but I would struggle to be really clear on what > I'm doing here. > > Generally, I guess I'm not the audience for this document, so I found it hard > to judge how useful it would be and whether the level of specificity and > clarity was appropriate. > > > Specific nits: > ==== > > [...] The internals of the orchestrator are > currently out of scope of this document. > > This seems wrong for a document that's at submission to IESG and about to > become immutable. Either it's in scope or it's not, there's no "currently" once > published. > Removed "currently". > ... > > [...] status can be collected by an industry-accepted YANG module (IETF, > Openconfig https://openconfig.net), by a vendor-specific YANG module, > > This looks like an informative reference. Should it be listed in the references > section? > Yes, done. > > [...] The only valid situation where no symptoms > are returned is when the score is maximal, indicating that no issues > where detected for that service instance. > > Typo, should be: "no issues were detected". > Done > ... > > That's all I found in my read through, though I admit I glazed over some of > the longer sections when I felt I understood the gist. > > Regards, > > Bron. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
