Shepherd write-up for draft-ietf-opsawg-model-automation-framework-04
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why
> is this the proper type of RFC? Is this type of RFC indicated in
> the title page header?
This document requests publication as an Informational RFC. That is
indicated on the header page.
It is appropriate for this document because it is a framework that
describes the use of data models specified in other documents. It does
not dictate any on-wire behavior, and does not specify any
interoperablity.
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
> Recent examples can be found in the "Action" announcements for
> approved documents. The approval announcement contains the
> following sections:
>
> Technical Summary:
This document describes an architecture for service and network
management automation that takes advantage of YANG modeling
technologies. This architecture is drawn from a Network Operator
perspective irrespective of the origin of a data module; it can thus
accommodate modules that are developed outside the IETF.
Data models provide a programmatic approach to represent services and
networks. Concretely, they can be used to derive configuration
information for network and service components, and state information
that will be monitored and tracked. Data models can be used during
the service and network management life cycle, such as service
instantiation, provisioning, optimization, monitoring, diagnostic,
and assurance. Data models are also instrumental in the automation
of network management, and they can provide closed-loop control for
adaptive and deterministic service creation, delivery, and
maintenance.
> Working Group Summary:
This document ran eight versions before adoption into the working
group. The adoption poll included responses from fifteen people and
general support was indicated.
There was some debate about the filename at the time of adoption, and
the result was a name that better matched the purpose of the document.
The WG draft was presented at one physical meeting and at the IETF-107
virtual meeting. Points were raised and the draft updated.
WG last call attracted fewer commenters, but there were several detailed
reviews which were addressed.
There were no points of contention.
> Document Quality:
This document is not intended for implementation, but as a guideline for
building and deploying management systems. The involvement of four
network operators in the authorship indicates that the document has been
viewed carefully by those involved in deploying network management
systems.
> Personnel:
The document shepherd is Adrian Farrel <adrian@olddog.co.uk>
The Responsible Area Director is Rob Wilton <rwilton@cisco.com>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.
I did a cursory review of this document at the time of adoption, and a
detailed review during working group last call. All of my comments have
been addressed.
I have done a subsequent review of the document to make sure it was not
broken during updates after WG last call.
This version is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
No concerns.
As usual these days, it would have been nice to receive some more
reviews, but there were enough that it is reasonable to advance the
document.
> (5) Do portions of the document need review from a particular or from
> broader perspective.
There is no use of formal language in the document and no need for
specific targeted reviews.
As previously noted, this document concerns deployment and use of
network management systems and so can benefit from additional reviews by
network operators. However, sufficient operator input has been receieved
to give confidence about the contents.
> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?
No such concerns.
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed.
All done. IPR responses can be seen at:
Q. Wu:
https://mailarchive.ietf.org/arch/msg/opsawg/zebmEbg9lOLZy9yYCPea94LIU6k/ M.
Boucadair :
https://mailarchive.ietf.org/arch/msg/opsawg/MtYvDrUqjcSoPMSsTg_ZpvR0eTQ/ D.
Lopez:
https://mailarchive.ietf.org/arch/msg/opsawg/zNP3w3IVZkffakWyk-pxBYuRFr8/ C.
Xie:
https://mailarchive.ietf.org/arch/msg/opsawg/zyDDzrs0ZF9jBIRp1IP0CZcVBbE/ L.
Geng:
https://mailarchive.ietf.org/arch/msg/opsawg/5TUtcJ22HCVPmb3TGD7QUu1rz6A/ C.
Jacquenet:
https://mailarchive.ietf.org/arch/msg/opsawg/ugSjfI7ZH_dPa0WXeflDqpJJLmg/
Luis Miguel Contreras Murillo:
https://mailarchive.ietf.org/arch/msg/opsawg/n-9UACXuUvMmpCO6DDiIDqZrbVI/
Oscar Gonzalez de Dios:
https://mailarchive.ietf.org/arch/msg/opsawg/h-45h77DJiV7gkUpN5w3260hIqw/
Weiqiang Cheng:
https://mailarchive.ietf.org/arch/msg/opsawg/u3UKqjhZAn27R4J0Fm-eqAoC7Tc/
Young Lee:
https://mailarchive.ietf.org/arch/msg/opsawg/j06bIB8h0tuiJ1PRO5lSfnGOCy0/
> (8) Has an IPR disclosure been filed that references this document?
No.
> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with
> it?
Reasonable support with no dissent.
I would say that part of the WG is not interested in the subject matter
and so had no opinion. But with a large list of authors and contributors
this catches the mood of the WG.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
No.
> (11) Identify any ID nits the Document Shepherd has found in this
> document.
idnits is clean except for a number of referenced I-Ds that have moved
on to later revisions. That is picked up automatically the next time the
XML is processed.
> (12) Describe how the document meets any required formal review
> criteria
No formal language used. No criteria to be met.
> (13) Have all references within this document been identified as
> either normative or informative?
Yes.
> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state? If such
> normative references exist, what is the plan for their
> completion?
All normative references are to published RFCs.
> (15) Are there downward normative references references (see
> RFC 3967)?
No downrefs.
> (16) Will publication of this document change the status of any
> existing RFCs?
No.
> (17) Describe the Document Shepherd's review of the IANA
> considerations section.
The document makes no request for any IANA action.
An appropriate "null" IANA Considerations section is included.
> (18) List any new IANA registries that require Expert Review for
> future allocations.
None.
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language.
No formal language is used in this document.
> (20) If the document contains a YANG module
The document does not contain a YANG module.