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.