[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-model-automation-framework-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENT points and nits. I hope that
this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic comment: it hurts my eyes to see several occurrences of "NAT" as a
service in an IETF document in 2020...

Should there be a reference to
draft-claise-opsawg-service-assurance-architecture (albeit not yet an adopted
document) ?

There are a lot of detailed service creations with a good decomposition of all
the required steps; but, little is written on the importance of YANG models (as
opposed to any standard data exchange), so, the current title seems a little
misleading.

-- Abstract --
To be honest, I fail to understand why data models can be used to 'derive'
configuration information. Did the authors mean 'describe' or 'specify' ?

Later "This document describes an architecture" while the title of this
document if "framework" ? Slight semantic difference ;-)

And later "accommodate modules that", is it 'YANG modules' or 'data models' ?

-- Section 4 --
The complex figure 4 would benefit from some textual introduction referring to
the subsections. Also, the meaning of the arrow would gain if specified. E.g.,
why "Service Diagnosis" does not have a loop back to optimization or assurance ?

-- Section 4.2.2 --
If not mistaken, this is the first appearance of the notation "<intended>". Do
the angle brackets have a specific meaning?

-- Section 4.2.3 --
Suggestion to use the figure 4 wording as the title esp. since the wording of
MDT is not really used in the sub-section.

-- Section 6 --
Is it required/useful to have the 'standard YANG security considerations" in
this document that does not contain any YANG module?

-- Section 10.1 --
Most of the references should probably be informational only.

== NITS ==

Generic nit, I found the use of capitalized "Service Model" or "Network Models"
a little disturbing.

-- Section 1 --
"how different layer YANG data models" is rather difficult to parse, suggest to
rephrase it.

-- Section 4.4 --
Is it "service decomposing" or "service decomposition" ?