Jürgen,
To tell that I was skeptical about the SUPA work is just wrong.
I had great hopes for SUPA, as having consistent policy constructs in
YANG module was key. The big hope was that those SUPA constructs could
be re-used in other YANG modules
example: routing, ACL, security ...
Regardless of the location: in a network element or in a
controller/orchestrator
Regardless of the function: network element and service YANG modules
If successful, in the end, SUPA would have helped to reuse code.
Was I disappointed by the progress? Yes. The results were not there
while the rest of the world uses their YANG policy constructs. Timing
was key so, as AD, I had to pull the plug.
The world has moved on. So be it.
You can't infer skepticism from pragmatism.
Now, back to the draft.
From a network element point, I stressed the need to take have _simple
_ECA rules directly routers.
Think about RMON event/alarm but for YANG. Think about removing the RMON
event/alarm restrictions that it works only for integer/counter.
If your point is that the draft is not perfect, fair point.
Should we solve attempt to solve that issue? Yes.
A confusion comes from the abstract that implies that this work is based
on SUPA.
Abstract
RFC8328 defines a policy-based management framework that allows
definition of a data model to be used to represent high-level,
possibly network-wide policies. Policy discussed in RFC8328 are
classified into imperative policy and declarative policy, Event
Condition Action (ECA) policy is an typical example of imperative
policy. This document defines a YANG data model for the ECA policy
management. The ECA policy YANG provides the ability for the network
management function (within a network element) to control the
configuration and monitor state change and take simple and instant
action on the server when a trigger condition on the system state is
met.
Actually, in my mind, the abstract should be simplified to something
such as (and yes, it could be improved)
Abstract
This document defines a YANG data model for the ECA policy
management. The ECA policy YANG provides the ability for the network
management function (within a network element) to control the
configuration and monitor state change and take simple and instant
action on the server when a trigger condition on the system state is
met.
And then, somewhere in the introduction, the following text should be
reused:
RFC8328 defines a policy-based management framework that allows
definition of a data model to be used to represent high-level,
possibly network-wide policies. Policy discussed in RFC8328 are
classified into imperative policy and declarative policy, Event
Condition Action (ECA) policy is an typical example of imperative
policy.
Regards, Benoit.
On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:
This email begins a 2 week working group adoption poll for:
https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06
Please voice your support or objections before the poll completes on
March 3rd.
I am against adoption of this draft. I wonder whether Benoit will
explain his contributions to this document; Benoit was added as a
co-author in -06 and he used to be rather sceptical about the SUPA
work (and this is essentially part of the SUPA work resubmitted to the
NETMOD WG). Despite this, the YANG definitions are clearly not up to
the level one would expect for WG adoption. Many descriptions are
just repetition of leaf names and there are obvious errors such as
leaf-list day-of-month {
type uint8 {
range "0..59";
}
description
"A set of days of the month at which this
scheduling timing will trigger.";
}
Despite the strange range, it is unclear how a number will in the
range will identify a set. Note, this is an example, there are lots of
them in the document. The examples provides are not convincing and
technically wrong (how can <interval>10m</interval> match
leaf interval {
type uint32 {
range "1..max";
}
units "seconds";
mandatory true;
description
"The number of seconds between two triggers
generated by this periodic timing object.";
}
and I have serious doubts that the design is anywhere close to be
practically usable. There need to be mechanisms to bind 'variables'
while matching conditions that and be reused in action definitions, it
is not scalable to have constants such as interface names in the
examples hard-coded in policy rules - this would lead to a huge number
of rules if you want to apply policy rules to all interfaces.
There is also a lack of extensibility, which is important for a core
policy language, and definitions like:
identity function-type {
description
"Possible values are:
plus, minus, mult, divide, remain.";
}
without ever defining these operators feels strange. I also not
convinced that the resulting expressions are expressive enough for
real-world use.
This document is in a state that requires way too much effort to fix
in a WG process. I also doubt that expressing policies in such a
low-level format is usable in practice. Policy languages for network
management have a long history and this proposal seems to ignore the
lessons learned in the past.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
