Last Call Review of draft-ietf-opsawg-service-assurance-architecture-11
review-ietf-opsawg-service-assurance-architecture-11-artart-lc-gondwana-2022-11-10-00
Request | Review of | draft-ietf-opsawg-service-assurance-architecture |
---|---|---|
Requested revision | No specific revision (document currently at 13) | |
Type | Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2022-11-20 | |
Requested | 2022-11-06 | |
Authors | Benoît Claise , Jean Quilbeuf , Diego Lopez , Daniel Voyer , Thangam Arumugam | |
I-D last updated | 2022-11-10 | |
Completed reviews |
Artart Last Call review of -11
by Bron Gondwana
(diff)
Tsvart Last Call review of -11 by Mirja Kühlewind (diff) Genart Last Call review of -11 by Paul Kyzivat (diff) Secdir Last Call review of -11 by Christian Huitema (diff) Secdir Telechat review of -12 by Christian Huitema (diff) |
|
Assignment | Reviewer | Bron Gondwana |
State | Completed | |
Request | Last Call review on draft-ietf-opsawg-service-assurance-architecture by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/3tllFLQNDJikADobxTi6YwaRHhI | |
Reviewed revision | 11 (document currently at 13) | |
Result | Ready w/nits | |
Completed | 2022-11-10 |
review-ietf-opsawg-service-assurance-architecture-11-artart-lc-gondwana-2022-11-10-00
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. 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. ... [...] 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? ... [...] 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". ... 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.