Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang

From: Joel Jaeggli <[email-masked]>
Date: Tue, 18 Feb 2020 08:44:18 -0800

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.

Thanks
joel

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 18 Feb 2020 23:17:02 +0000

> Please voice your support or objections before the poll completes on

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Feb 2020 16:36:16 -0800

Hi,

I think the procedures we used to follow under Marshall Rose as AD work
better than current adoption calls. First we agreed on what problem(s) to
solve.
Then we agree on solutions.  Without the first, it is hard to achieve the
second.
I would support working on a short requirements draft first, and then
revisit the
solution if that goes well.

I agree with Juergen about the complexity level for real deployments.
Decomposing logic expressions into a bunch of YANG list entries will never
work.
Just use XPath for expressions. It has variables, functions, and
expressions in compact string form.

There seems to be overlap with RFC 8632.
I would expect to see alarms reused instead of reinvented,
and ECA visibility into the notifications in each server event stream (from
RFC 8639).

The Policy Variables and RPC calls are improvements over past solutions
but still not enough to implement an ECA platform.  A real programming
language
is required, but that may not need to be standardized. Maybe just
mechanisms are needed
to bind ECA components (like PVs) to specific languages (like Python).
Then bind scripts to conditions and actions instead of using YANG objects.
All past attempts to write scripts in SMIv2 or YANG have failed.
YANG is not a programming language.

Andy

On Tue, Feb 18, 2020 at 3:17 PM Schönwälder, Jürgen <
[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Feb 2020 11:45:39 +0100

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.

---

From: "King, Daniel" <[email-masked]>
Date: Wed, 19 Feb 2020 11:44:14 +0000

Hi All,

Expressing, and delegating base imperative policy to network nodes (regardless if it’s a switch, router, network function, or indeed “controller”) is a critical step for facilitating network automation. I support the I-D and would like to see the WG adopt the work. Yes, the I-D needs to be developed further and this would be better managed if the effort was owned by the WG.

I do agree somewhat with Jürgen that past experiences have shown a lack of willingness between vendors for expressing policy (imperative or otherwise). Major vendors have tended to implement their own policy language, or specific purpose (security, role management, et al.) language that has been based on standards (formal) or open-source project (de facto). The fact that the I-D author and contributor list already has a good mix of implementors demonstrates a willingness to develop an interoperable network-wide solution.

BR, Dan.

From: netmod <[email-masked]> On Behalf Of Benoit Claise
Sent: 19 February 2020 10:46
To: Schönwälder, Jürgen <[email-masked]>; Joel Jaeggli <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Jürgen,

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

   met.
Actually, in my mind, the abstract should be simplified to something such as (and yes, it could be improved)

Abstract

   met.
And then, somewhere in the introduction, the following text should be reused:

   policy.

Regards, Benoit.

March 3rd.

          leaf-list day-of-month {

            type uint8 {

              range "0..59";

            }

            description

          }

          leaf interval {

            type uint32 {

              range "1..max";

            }

            units "seconds";

            mandatory true;

            description

          }

  identity function-type {

    description

      "Possible values are:

  }

real-world use.

/js

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 19 Feb 2020 12:18:00 +0000

Benoit,

thanks for the clarification.

I still believe that the approach taken is wrong. I doubt that network
operators are interested in an assembly level approach for expressing
threshold triggers. I am not sure xpath is the answer either. What was
perhaps reasonable to try in the 90s (RMON, DISMAN work) may not be
reasonably today anymore.

The example starting on page 43 seems to be doing this

  every 10 minutes
  if    exists(/ietf-interfaces:interfaces='eth0')
  and   if:interface[if:name='eth0']/if:statistic/if:in-errors >= 100
  then  /if:interfaces/if:interface[if:name='eth0']/if:enable = false

but it requires 1.5 pages of XML to express this (and then the rule is
not even meaningful since comparing an absolute value of a counter is
not useful).

If we are serious about policies, I believe we need to think about a
language-based approach that can be read and understood and which does
the things that are meaningful. Let me makeup some pseudo code based
on the example that can work for all eth* interfaces and that gets the
delta calculation of the counter right.

  if = /ietf-interfaces:interfaces/interface # json style namespace binding
  dt = 600 # 10 minutes in seconds
  every dt
  foreach name in $if/name:
    this = $if/[name=$name]
    if   $name matches 'eth.*'
    and  delta($this/statistic/in-errors, dt) >= 100
    then $this/enable = false

If people are serious about doing this kind of work, start by
collecting real-world policies that need to be expressable, then
identify the "language" mechanisms that are needed (loops over lists,
bindings, variables and substitutions, pattern matching, ...) and then
find a suitable representation. Yes, this is also something that
people wanted SUPA to do and it did fail because it was already hard
to collect real-world policies that help to understand what kind of
mechanisms are needed and why.

/js

On Wed, Feb 19, 2020 at 11:45:39AM +0100, Benoit Claise wrote:
> 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
> 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.
> From a network element point, I stressed the need to take have _simple _ECA
> rules directly routers.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Feb 2020 06:16:16 -0800

> reasonably today anymore.
I agree that "plain" XPath is not that useful.
Your example of a counter delta really show why.

> not even meaningful since comparing an absolute value of a counter is
Perhaps people think that by programming in YANG this somehow makes it
universal and avoids picking a programming language.

>     then $this/enable = false

I am hopeful that complex state like an array of counter rates could be
maintained
using policy variables. Then XPath could reference the PV in an expression
that is easy to write.

> mechanisms are needed and why.
A real language is needed with local variables, functions, conditional
branching and iteration, etc.
Using YANG data nodes to "configure" policy logic seems like the most
difficult way possible
to provide this functionality.

/js

Andy

> YANG
> on
> > SUPA.

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 24 Feb 2020 13:26:50 -0500

Agree with Dan. The use case is valid, though the errors in the data model
can be fixed.
Support.
Thanks,
- Xufeng

On Wed, Feb 19, 2020 at 6:44 AM King, Daniel <[email-masked]> wrote:

> Hi All,
>
>
>
> Expressing, and delegating base imperative policy to network nodes
> (regardless if it’s a switch, router, network function, or indeed
> “controller”) is a critical step for facilitating network automation. I
> support the I-D and would like to see the WG adopt the work. Yes, the I-D
> needs to be developed further and this would be better managed if the
> effort was owned by the WG.
>
>
>
> I do agree somewhat with Jürgen that past experiences have shown a lack
> of willingness between vendors for expressing policy (imperative or
> otherwise). Major vendors have tended to implement their own policy
> language, or specific purpose (security, role management, et al.) language
> that has been based on standards (formal) or open-source project (de
> facto). The fact that the I-D author and contributor list already has a
> good mix of implementors demonstrates a willingness to develop an
> interoperable network-wide solution.
>
>
>
> BR, Dan.
>
>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Benoit Claise
> *Sent:* 19 February 2020 10:46
> *To:* Schönwälder, Jürgen <[email-masked]>; Joel
> Jaeggli <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Jürgen,
>
> module was key. The big hope was that those SUPA constructs could be
> re-used in other YANG modules
> From a network element point, I stressed the need to take have *simple *ECA
> rules directly routers.

---

From: 刘 鹏 <[email-masked]>
Date: Tue, 25 Feb 2020 09:00:31 +0000

Hi ALL,

I have read this draft and if my understanding is correct, I believe the main idea of this draft is to preconfigure the device with some policy rule, which allows the device have the capability of self control on the management behavior within the system and have a prompt rapid response to the network state changes.

This is exactly something we are looking for in the network management automation. I support adoption of this work.

BR, Peng
China Mobile

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Benoit Claise
发件人: netmod [mailto:[email-masked]] 代表 Xufeng Liu
发送时间: 2020年2月25日 2:27
收件人: King, Daniel <[email-masked]>
抄送: [email-masked]
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Agree with Dan. The use case is valid, though the errors in the data model can be fixed.
Support.
Thanks,
- Xufeng

On Wed, Feb 19, 2020 at 6:44 AM King, Daniel <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

BR, Dan.

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Benoit Claise
Sent: 19 February 2020 10:46
To: Schönwälder, Jürgen <[email-masked]<mailto:[email-masked]>>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>
Cc: netmod@ietf..org<mailto:[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Jürgen,

Now, back to the draft.

Abstract

   met.

Abstract

   met.

   policy.

Regards, Benoit.

March 3rd.

          leaf-list day-of-month {

            type uint8 {

              range "0..59";

            }

            description

          }

          leaf interval {

            type uint32 {

              range "1..max";

            }

            units "seconds";

            mandatory true;

            description

          }

  identity function-type {

    description

      "Possible values are:

       plus, minus, mult, divide, remain..";

  }

real-world use.

/js

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 25 Feb 2020 20:01:01 +0000

Hi,

I support this draft and would like to see netmod work on this, but I do think some aspects need more maturing and parts of this probably should be rescoped.  Should the draft be adopted now, or should it be improved first and adopted later?  Not sure.  I would like to see the work continue, so in that sense I would clearly like to see the work adopted; at the same  time there are a number of issues that IMHO really need to be addressed.

I share some of the concerns raised by Juergen and Andy.  Specifically, I think the precise problem needs to be defined more clearly.  In the discussion it was mentioned RMON – would it be that, or perhaps a better analogy Event MIB?  Section 3 mentions that this is to specify trigger conditions for when to send push updates.  That is perhaps consistent with an Event MIB, but a slightly different problem from ECAs.  Section 4.2 then proceeds to allow for the definition of “events” – but really only defining a “timer event”, with the ECA model omitting tie-in e.g. with notifications.  Including a threshold mechanism here is a bit distracting and should perhaps be taken out – while the crossing of a threshold might constitute an event, I don’t think this should be tied inside an ECA but be something that stands on its own.  (The prior draft on Smart Filters for Push Updates addressed this – it has layed dormant for a while and in this sense I can’t object for this work to be picked someplace else, but logically really it does not belong here but should be separate.)  The actions, finally, describe not simply management operations.  I understand the intent is to have an escape mechanism allowing to “call out” other functions / scripts deployed at a device, but this intent needs to be called out more clearly.

So, in summary, I think the WG should consider rescoping this draft a bit – maybe divided into separate drafts, each addressing a separate concern, which will provide focus and make the problem being solved clearer:  One to define an ECA framework.  In this, clarify the invocation of actions, and allow for tie-in of notifications.  This would be this draft.  Another one to allow the definition of custom events/notifications, or smart filters for push updates.  (We should bring back the earlier draft.)  A third one to perhaps allow for the definition of “custom RPCs” that allow to invoke custom scripts/functions via Netconf/Restconf operations, then tie that , which are then invoked using the regular RPC.  (This would be a new draft)

--- Alex

From: netmod <[email-masked]> On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: [email-masked]
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-06&data=02%7C01%7Calex%40futurewei.com%7Cfc49312f082d40d7c07908d7b491d2f6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637176410724720916&sdata=RowKvLkl%2BUoR9H18Ns3AX%2F%2Fe%2Fzu5t%2FqYmBVENEdiPcU%3D&reserved=0>

Please voice your support or objections before the poll completes on March 3rd.

Thanks
joel

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Feb 2020 00:43:41 +0000

Hi the authors,

>“Another one to allow the definition of custom events/notifications, or smart filters for push updates.  (We should bring back the earlier draft.)”
As we worked on the smart filter before. We want to use the ECA model.
It seems this model enabled the generic programmability. Can we just use it to program any filter or what potentially need to augment/customize for a specific model?
Thanks,
Tianran

From: netmod [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Wednesday, February 26, 2020 4:01 AM
To: Joel Jaeggli <[email-masked]>; [email-masked]
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Hi,

--- Alex

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Thanks
joel

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 26 Feb 2020 01:57:21 +0000

In my view, an ECA model allows to define rules for events – conditions – actions, i.e. what actions to perform when an event occurs and a condition met.  A smart filter filters an input stream, letting some objects pass but not others.  They are not the same.

There is a connection in that you could define the passing of an object by a smart filter as an event.  So, it is conceivable to include an ability to define events in this draft. If this is the intent it should be stated so clearly.  The question then becomes if you would want those be used also independently of the ECA model – there may be benefit in defining a new event without tying it to a rule (i.e. a condition and action) but simply emitting it.  (Same thing for the timer notification, which might have uses beyond ECA.) In the draft these things are all mashed together, but separating the ability to define an event from the ability to specify an ECA rule (which refers to / is triggered by an event) can benefit reusability.

Anyway, as mentioned I think this work is relevant and I would like to see it go forward; IMHO some reframing and perhaps splitting of the draft should be considered whether that occurs before WG adoption or afterwards.

--- Alex

From: Tianran Zhou <[email-masked]>
Sent: Tuesday, February 25, 2020 4:44 PM
To: Alexander Clemm <[email-masked]>; Joel Jaeggli <[email-masked]>; [email-masked]
Subject: RE: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Hi the authors,

From: netmod [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Wednesday, February 26, 2020 4:01 AM
To: Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Hi,

--- Alex

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-06&data=02%7C01%7Calex%40futurewei.com%7Cf00fff51c8fb423b991208d7ba54f73b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182746419078457&sdata=IVHfOxhE7fTkLJ132TEGAM7mmIxdq2546iftp%2FbU5YE%3D&reserved=0>

Thanks
joel

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Feb 2020 10:10:14 -0800

Hi,

On Tue, Feb 25, 2020 at 5:57 PM Alexander Clemm <[email-masked]> wrote:

> In my view, an ECA model allows to define rules for events – conditions –
> actions, i.e. what actions to perform when an event occurs and a condition
> met.  A smart filter filters an input stream, letting some objects pass but
> not others.  They are not the same.
>
>
>
> There is a connection in that you could define the passing of an object by
> a smart filter as an event.  So, it is conceivable to include an ability to
> define events in this draft. If this is the intent it should be stated so
> clearly.  The question then becomes if you would want those be used also
> independently of the ECA model – there may be benefit in defining a new
> event without tying it to a rule (i.e. a condition and action) but simply
> emitting it.  (Same thing for the timer notification, which might have uses
> beyond ECA.) In the draft these things are all mashed together, but
> separating the ability to define an event from the ability to specify an
> ECA rule (which refers to / is triggered by an event) can benefit
> reusability.
>
>
>
> Anyway, as mentioned I think this work is relevant and I would like to see
> it go forward; IMHO some reframing and perhaps splitting of the draft
> should be considered whether that occurs before WG adoption or afterwards.
>
>
>

I do not agree that refactoring this draft solves any adoption issues.
YANG-based management already has events (specified with notification-stmt).
The ECA data model should not duplicate other functionality such as alarms.
Any event that can be received on an event stream (RFC 8639) should
automatically
be usable in any ECA logic.  Working on a solution without agreement on
even the most
basic ECA architecture or problem scope is a recipe for failure.

Programming with YANG data models as the logic for conditions and actions
has never been proven to work.  Even the trivial examples are complex
and real-world use-cases seem near impossible. (nobody has ever provided one
so we have to speculate). Achieving interoperability with a workable
solution
will not be easy. Other solutions have got "Hello world" to work, declared
victory,
and then went away forever.  Why will this time be different?

Andy

--- Alex
>
>
>
> *From:* Tianran Zhou <[email-masked]>
> *Sent:* Tuesday, February 25, 2020 4:44 PM
> *To:* Alexander Clemm <[email-masked]>; Joel Jaeggli <[email-masked]>;
> [email-masked]
> *Subject:* RE: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Hi the authors,
>
>
>
> >“Another one to allow the definition of custom events/notifications, or
> smart filters for push updates.  (We should bring back the earlier draft.)”
>
> It seems this model enabled the generic programmability. Can we just use
> it to program any filter or what potentially need to augment/customize for
> a specific model?
>
> Thanks,
>
> Tianran
>
>
>
> *From:* netmod [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alexander Clemm
> *Sent:* Wednesday, February 26, 2020 4:01 AM
> *To:* Joel Jaeggli <[email-masked]>; [email-masked]
> I support this draft and would like to see netmod work on this, but I do
> think some aspects need more maturing and parts of this probably should be
> rescoped.  Should the draft be adopted now, or should it be improved first
> and adopted later?  Not sure.  I would like to see the work continue, so in
> that sense I would clearly like to see the work adopted; at the same  time
> there are a number of issues that IMHO really need to be addressed.
>
>
>
> I share some of the concerns raised by Juergen and Andy.  Specifically, I
> think the precise problem needs to be defined more clearly.  In the
> discussion it was mentioned RMON – would it be that, or perhaps a better
> analogy Event MIB?  Section 3 mentions that this is to specify trigger
> conditions for when to send push updates.  That is perhaps consistent with
> an Event MIB, but a slightly different problem from ECAs.  Section 4.2 then
> proceeds to allow for the definition of “events” – but really only defining
> a “timer event”, with the ECA model omitting tie-in e.g. with
> notifications.  Including a threshold mechanism here is a bit distracting
> and should perhaps be taken out – while the crossing of a threshold might
> constitute an event, I don’t think this should be tied inside an ECA but be
> something that stands on its own.  (The prior draft on Smart Filters for
> Push Updates addressed this – it has layed dormant for a while and in this
> sense I can’t object for this work to be picked someplace else, but
> logically really it does not belong here but should be separate.)  The
> actions, finally, describe not simply management operations.  I understand
> the intent is to have an escape mechanism allowing to “call out” other
> functions / scripts deployed at a device, but this intent needs to be
> called out more clearly.
>
>
>
> So, in summary, I think the WG should consider rescoping this draft a bit
> – maybe divided into separate drafts, each addressing a separate concern,
> which will provide focus and make the problem being solved clearer:  One to
> define an ECA framework.  In this, clarify the invocation of actions, and
> allow for tie-in of notifications.  This would be this draft.  Another one
> to allow the definition of custom events/notifications, or smart filters
> for push updates.  (We should bring back the earlier draft.)  A third one
> to perhaps allow for the definition of “custom RPCs” that allow to invoke
> custom scripts/functions via Netconf/Restconf operations, then tie that ,
> which are then invoked using the regular RPC.  (This would be a new draft)
>
>
>
> --- Alex
>
>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Joel Jaeggli
> *Sent:* Tuesday, February 18, 2020 8:44 AM
> *To:* [email-masked]
> *Subject:* [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-06&data=02%7C01%7Calex%40futurewei.com%7Cf00fff51c8fb423b991208d7ba54f73b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182746419078457&sdata=IVHfOxhE7fTkLJ132TEGAM7mmIxdq2546iftp%2FbU5YE%3D&reserved=0>
>
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 27 Feb 2020 14:30:25 +0000 (UTC)

Hi Andy, Jurgen, Alex and All,

I believe that YANG could be a useful participant in a successful ECA framework if the following is kept in mind:

1. It is not feasible to realize an ECA framework relying solely on YANG.  It is reasonable to expect ECA capable servers to support to a sufficient degree Xpath Expressions language and some sort of general purpose scripting  environment , such as Python, JunoScript, TCL/TKL, etc.;

2. ECA YANG model should define (and/or use definitions produced by other YANG models for) certain ECA components, such as Events, Policy Variables (PVs) and Actions (e.g. network re-configurations, client notifications, invoking of RPCs, etc.), but everything to do with Conditions and logical and mathematical expressions (which should be expected to be potentially very complex), should be left to XPath (i.e. configured as XPath expression strings). Although it is possible to define elementary micro conditions, it would be impractical (too tedious) for the clients to build conditions hierarchically (bottom up) and too cumbersome for the servers to process such constructs;

3.Likewise, it would be too demanding to expect servers implementing interpreters for specific purpose of interpretation of an ECA directly as it configured in YANG. Rather , it would be prudent to expect a server, upon receiving an ECA configuration, to generate out of it a micro-script in a locally supported scripting language and arrange said micro-script execution at the moment of the Event (or timer) firing;

4. In short, the objective of the ECA YANG configuration is to provide a universal ECA representation that could be converted into a micro-script of the server's choice.

What do you think?

Igor

    On Wednesday, February 26, 2020, 1:11:00 PM EST, Andy Bierman <[email-masked]> wrote:  
 
 Hi,

There is a connection in that you could define the passing of an object by a smart filter as an event.  So, it is conceivable to include an ability to define events in this draft. If this is the intent it should be stated so clearly.  The question then becomes if you would want those be used also independently of the ECA model – there may be benefit in defining a new event without tying it to a rule (i.e. a condition and action) but simply emitting it..  (Same thing for the timer notification, which might have uses beyond ECA.) In the draft these things are all mashed together, but separating the ability to define an event from the ability to specify an ECA rule (which refers to / is triggered by an event) can benefit reusability. 

I do not agree that refactoring this draft solves any adoption issues.YANG-based management already has events (specified with notification-stmt).The ECA data model should not duplicate other functionality such as alarms.Any event that can be received on an event stream (RFC 8639) should automaticallybe usable in any ECA logic.  Working on a solution without agreement on even the mostbasic ECA architecture or problem scope is a recipe for failure.
Programming with YANG data models as the logic for conditions and actionshas never been proven to work.  Even the trivial examples are complexand real-world use-cases seem near impossible. (nobody has ever provided oneso we have to speculate). Achieving interoperability with a workable solutionwill not be easy. Other solutions have got "Hello world" to work, declared victory,and then went away forever.  Why will this time be different?

Andy

--- Alex

Hi the authors,

Thanks,

Tianran

From: netmod [mailto:[email-masked]]On Behalf Of Alexander Clemm
Sent: Wednesday, February 26, 2020 4:01 AM
To: Joel Jaeggli <[email-masked]>;[email-masked]
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Hi,

--- Alex

From: netmod <[email-masked]>On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: netmod@ietf..org
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Thanks

joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Feb 2020 14:13:06 -0800

On Thu, Feb 27, 2020 at 6:30 AM Igor Bryskin <[email-masked]> wrote:

> I believe that YANG could be a useful participant in a successful ECA
> framework if the following is kept in mind:
>
>
> 1. It is not feasible to realize an ECA framework relying solely on YANG.
> It is reasonable to expect ECA capable servers to support to a sufficient
> degree Xpath Expressions language and some sort of general purpose
> scripting  environment , such as Python, JunoScript, TCL/TKL, etc.;
>
>
I think some constrained scripting is required.
It is important that the WG understand the boundaries between
interoperability
and implementation choice.

> 2. ECA YANG model should define (and/or use definitions produced by other
> YANG models for) certain ECA components, such as Events, Policy Variables
> (PVs) and Actions (e.g. network re-configurations, client notifications,
> invoking of RPCs, etc.), but everything to do with Conditions and logical
> and mathematical expressions (which should be expected to be potentially
> very complex), should be left to XPath (i.e. configured as XPath expression
> strings). Although it is possible to define elementary micro conditions, it
> would be impractical (too tedious) for the clients to build conditions
> hierarchically (bottom up) and too cumbersome for the servers to process
> such constructs;
>

XPath +  PVs + new XPath functions might work.
Can this be done without reinventing components like alarms?
It would be way better to integrate existing models than create new ones
within ECA.
For example:

   event == generation of RFC 8632 <alarm-notification> event
   condition == script to extract relevant fields from event and check
condition
   action == script to use extracted fields from condition to send commands
to server

If the event stream management and event field extraction is standardized
(with YANG objects)
then that would help a lot. Access to metadata from the execution
environment (e,g, server) is also
important to standardize.

> 3.Likewise, it would be too demanding to expect servers implementing
> interpreters for specific purpose of interpretation of an ECA directly as
> it configured in YANG. Rather , it would be prudent to expect a server,
> upon receiving an ECA configuration, to generate out of it a micro-script
> in a locally supported scripting language and arrange said micro-script
> execution at the moment of the Event (or timer) firing;
>
>
This approach could help.
The "send RPC command" solution is too simplistic.
Maybe psuedo-code would work better.
Even a simple "edit" can be very different on each server (e.g., candidate,
running, defaults)

> 4. In short, the objective of the ECA YANG configuration is to provide a
> universal ECA representation that could be converted into a micro-script of
> the server's choice.
>
>
The implementation details are always a server choice.
I agree that mechanisms to bind ECA components to real scripting languages
has more promise than using YANG objects entirely, or creating a new
scripting language.

What do you think?
Andy

> emitting it..  (Same thing for the timer notification, which might have
> uses beyond ECA.) In the draft these things are all mashed together, but
> *To:* netmod@ietf..org <[email-masked]>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 27 Feb 2020 22:40:57 +0000

Hi Igor,
quick responses inline.  I think we are by and large on the same page.
--- Alex

From: Igor Bryskin <[email-masked]>
Sent: Thursday, February 27, 2020 6:30 AM
To: Alexander Clemm <[email-masked]>; Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

<ALEX> I agree there is a role, even that a YANG-based ECA framework can be defined.  To be useful, this should allow leveraging and calling out other components, as you describe (e.g. invoke some scripts as actions, etc), not just invoking a Netconf/Restconf operation.
</ALEX>

<ALEX> yes, agree.  And the ECA can provide the interoperable way of tying these things together.  (This means some consideration should also be given to corner cases such as script not found, etc.)
</ALEX>
2. ECA YANG model should define (and/or use definitions produced by other YANG models for) certain ECA components, such as Events, Policy Variables (PVs) and Actions (e.g. network re-configurations, client notifications, invoking of RPCs, etc.), but everything to do with Conditions and logical and mathematical expressions (which should be expected to be potentially very complex), should be left to XPath (i.e. configured as XPath expression strings). Although it is possible to define elementary micro conditions, it would be impractical (too tedious) for the clients to build conditions hierarchically (bottom up) and too cumbersome for the servers to process such constructs;
3.Likewise, it would be too demanding to expect servers implementing interpreters for specific purpose of interpretation of an ECA directly as it configured in YANG. Rather , it would be prudent to expect a server, upon receiving an ECA configuration, to generate out of it a micro-script in a locally supported scripting language and arrange said micro-script execution at the moment of the Event (or timer) firing;
<ALEX> Sure.  (I am not clear if we should make assumptions about what an implementation would or would not support, but the framework needs to allow clients to be clear about the supported capabilities.)
</ALEX>
4. In short, the objective of the ECA YANG configuration is to provide a universal ECA representation that could be converted into a micro-script of the server's choice.

<ALEX> Fine with all that.  My point earlier was to be clear about the problem in scope, differentiating between the ECA framework itself from the way that events or actions can be defined, which could be used independent of the ECA framework.
--- Alex
</ALEX

What do you think?

Igor

On Wednesday, February 26, 2020, 1:11:00 PM EST, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On Tue, Feb 25, 2020 at 5:57 PM Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

I do not agree that refactoring this draft solves any adoption issues.
YANG-based management already has events (specified with notification-stmt).
The ECA data model should not duplicate other functionality such as alarms.
Any event that can be received on an event stream (RFC 8639) should automatically
be usable in any ECA logic.  Working on a solution without agreement on even the most
basic ECA architecture or problem scope is a recipe for failure.

Programming with YANG data models as the logic for conditions and actions
has never been proven to work.  Even the trivial examples are complex
and real-world use-cases seem near impossible. (nobody has ever provided one
so we have to speculate). Achieving interoperability with a workable solution
will not be easy. Other solutions have got "Hello world" to work, declared victory,
and then went away forever.  Why will this time be different?

Andy

--- Alex

From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 25, 2020 4:44 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [netmod] Adoption poll for draft-wwx-netmod-event-yang

Hi the authors,

Thanks,

Tianran

Hi,

--- Alex

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: netmod@ietf..org<mailto:[email-masked]>
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-06&data=02%7C01%7Calex%40futurewei.com%7C3eb2dc9fb26246712ba908d7bb9197ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184106329308347&sdata=dxrHc59JA8haDTuDoevAO16Eul3FwIpVHFc3BFlzIpk%3D&reserved=0>

Thanks

joel
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=02%7C01%7Calex%40futurewei.com%7C3eb2dc9fb26246712ba908d7bb9197ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184106329308347&sdata=x0QfkZnAwek87KXd96tgXLhR8xaseYob5sTPf468hMw%3D&reserved=0>
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=02%7C01%7Calex%40futurewei.com%7C3eb2dc9fb26246712ba908d7bb9197ce%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184106329318342&sdata=oSR8CyueB%2BgZB71ixaUbFkjb2WHkUtGomyBwVwMkm2E%3D&reserved=0>