Skip to main content

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.