ISE write-up for: draft-liu-policy-based-management-framework-00
Abstract:
"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.
Minor:
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.
Editorial:
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.
- - - - - - -