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.
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
