ISE write-up for: draft-liu-policy-based-management-framework-00
"Simplified Use of Policy Abstractions (SUPA) defines base YANG data
models to encode policy, which point to device-, technology-, and
service-specific YANG models developed elsewhere. Policy rules
within an operator's environment can be used to express high-level,
possibly network-wide policies to a network management function
(within a controller, an orchestrator, or a network element). The
network management function can then control the configuration and/or
monitoring of network elements and services. This document describes
the SUPA basic framework, its elements and interfaces."
During the last few weeks of the (now-closed) SUPA Working Group, this
draft (then titled draft-ietf-supa-policy-based-management-framework-03)
was reviewed by Yangyang Wang, Gunter Wang, Tony Tia and Joel Halpern,
as well as by that draft's authors.
This draft documents the work of the SUPA Working Group; it summarises
SUPA's generic Information Model, and the Event-Condition-Action (ECA)
extensions to it so that ECA policy rules can be constructed using it.
This new version of it was reviewed for my by Joel Halpern. Joel's
reviews of this earlier draft, and of the current revision derived from
it, are appended below.
This draft has no requests for IANA.
- - - - - - -
Joel Halpern's reviw of the SUPA version of this draft:
I have read the latest version of this draft.
While there is some minor cleanup that would help the document, this document is in good shape and helps explain the usage of policy. With minor repairs, this document is worth publishing as an Informational RFC.
The definition of YANG should note that it can be used to define the model for NetConf or RestConf.
The definition of OSS should be tweaked slightly to make clear that OSS are concerned with higher layer concepts, as distinct from network managements Systems. Possibly replace "manage their networks" with "control the high level behavior of the network environment above the element or network management layers."
In section 3.1, when the cardinalites of the relationships in figure 3 are given, it may make sense to indicate that the cardinalities apply when resources or Services are being controlled by policies. (Otherwise the cardinalities would have to be 0 on the Policy end, rather than 1.
Also, since any given policy may control Resources, Services, or both, the cardinality on the Resource and Service end should be 0..n.
Introduction, Paragraph 1: Add a descriptor to "variety", for example, "Meanwhile, the rapid growth of traffic and the increased variation in kinds of content being carried makes ..."
Section 3.4 beginss "An information model is abstract. As such, it cannot be directly instantiated." That is misleading phrasing, due to the fact that abstract vs concrete is a different dimension than IM vs DM. I would suggest instead "An information model is, by definition, a description of the structure independent of specific representations such as YANG or TOSCA." And remove the parenthetical.
- - - - - - -
Joel Halpern's review of this draft:
While there are some minor items, and there is the issue of the normative references to GPIM, other than that this seems ready for publication as an informational RFC.
Other review comments:
The document references, in section 3.1, in between the two figures, refers to GPIM as providing ECA policy rules and declarative policy. While various of us would like to have declarative policy model, the current documents do not include that.
- - - - - - -