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

From: Lou Berger <[email-masked]>
Date: Mon, 7 Dec 2020 17:27:57 -0500

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end 
of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all 
indicated that no IPR exists.  The draft will not be formally adopted 
until both the IPR and WG polls are complete.

---

From: Lou Berger <[email-masked]>
Date: Mon, 7 Dec 2020 17:33:07 -0500

I should have mentioned that this is the 2nd adoption call on this 
document.  for full context on discussion on this draft, see 
https://mailarchive.ietf.org/arch/browse/netmod/?q=draft-wwx-netmod-event-yang

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 8 Dec 2020 09:52:33 +0800

Hi, all

    I support the adoption.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Lou Berger
Date: 2020-12-08 06:27
To: NETMOD Group
CC: NetMod WG Chairs
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
This email begins a 2-week adoption poll for:

 
Thank you!
 
Netmod Chairs

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

---

From: "maqiufang (A)" <[email-masked]>
Date: Tue, 8 Dec 2020 02:02:55 +0000

Hi, all

Support as a contributor.

Best Regards,
Qiufang Ma

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2020年12月8日 6:28
收件人: NETMOD Group <[email-masked]>
抄送: NetMod WG Chairs <[email-masked]>
主题: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all indicated that no IPR exists.  The draft will not be formally adopted until both the IPR and WG polls are complete.

---

From: "Wei Wang" <[email-masked]>
Date: Tue, 8 Dec 2020 10:07:56 +0800

Hi all,
&nbsp; &nbsp; I support the adoption.

Best Regards,
Wei
China Telecom

------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Lou Berger"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Tue, Dec 8, 2020 06:27 AM
To:&nbsp;"NETMOD Group"<[email-masked]&gt;;
Cc:&nbsp;"NetMod WG Chairs"<[email-masked]&gt;;
Subject:&nbsp;[netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all 
indicated that no IPR exists.&nbsp; The draft will not be formally adopted 
until both the IPR and WG polls are complete.

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 8 Dec 2020 02:39:01 +0000

I support adoption (as a contributor).
--- Alex

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Lou Berger
Sent: Monday, December 7, 2020 2:33 PM
To: NETMOD Group <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

I should have mentioned that this is the 2nd adoption call on this document.  for full context on discussion on this draft, see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fnetmod%2F%3Fq%3Ddraft-wwx-netmod-event-yang&amp;data=04%7C01%7Calex%40futurewei.com%7C0af4f25819a2444bd87c08d89b0021bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637429772162751258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=V8FczyuaS9twtp7RatOburGx0X9foHp9k75YBf%2FDeBg%3D&amp;reserved=0

On 12/7/2020 5:27 PM, Lou Berger wrote:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-10&amp;data=04%7C01%7C
> alex%40futurewei.com%7C0af4f25819a2444bd87c08d89b0021bf%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C1%7C637429772162761250%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C2000&amp;sdata=Eje9r9WOBU%2FsoCHiBrFusGWm3VrnH2kjKm1M%2FMqurUM%3D&a
> mp;reserved=0
>
> PS Note the IPR poll is running concurrently as the private response 
> all indicated that no IPR exists.  The draft will not be formally 
> adopted until both the IPR and WG polls are complete.
>
>

_______________________________________________
netmod mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=04%7C01%7Calex%40futurewei.com%7C0af4f25819a2444bd87c08d89b0021bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637429772162761250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=QG8jxu2N9pVkdtV1NVkAzJ4wYnUek52tQuI8MLTw5Nw%3D&amp;reserved=0

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 8 Dec 2020 10:02:42 +0100

I support adoption.
/jan

> On 7 Dec 2020, at 23:27, Lou Berger <[email-masked]> wrote:
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Dec 2020 10:50:45 -0000

Hi,

I have generally been sceptical about Intention-based network operations within the IETF, and I was ambivalent about this document at the first adoption poll. 

However, I think that some good work has been done since then and the document has reached a level where the WG could adopt it and further refine it. There is clearly a body of people who want to work on it, and it seems to be within the WG scope, so I support adoption.

I also think that splitting this piece off the larger body of Intention-based work is a wise first step.

Here are a few comments for the authors based on a quick reading...

Abstract.
I appreciate the brevity of the Abstract, but I don't find it very clear. Specifically, what is "the server" and what role would it play absent this YANG model? Conversely, who/what is delegating some of the network management functions? And lastly, is the choice of which network management functions to delegate well known (I assume it is) or up to an implementation?

---

Introduction
The first mention of "ECA" comes in...
   This document defines an ECA Policy management YANG data model.
I think you need to:
- Expand the abbreviation
- Explain in one or two sentences what ECA is

---

Section 2.1
You need to update to the more recent boilerplate that mentions RFC 8174

---

Section 2.1
You use the term "Event Stream" without defining it

Cheers,
Adrian

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Lou Berger
Sent: 07 December 2020 22:28
To: NETMOD Group <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Dec 2020 14:22:59 +0800

Hello, all,
I support the adoption of this draft.

Best regards
Chongfeng

------------------ Original ------------------
From: "Lou Berger" <[email-masked]>;
Date: Tue, Dec 8, 2020 06:27 AM
To: "NETMOD Group"<[email-masked]>;
Cc: "NetMod WG Chairs"<[email-masked]>;
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Thank you!

Netmod Chairs

---

From: Xufeng Liu <[email-masked]>
Date: Sat, 19 Dec 2020 11:42:57 -0500

Support the adoption as a co-auther.
Thanks,
- Xufeng

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 21 Dec 2020 22:42:11 +0530

Hi Lou, WG,

I find the motivation in the Introduction to be focused on ECA at the
network devices (with all the talk about issues with Centralized
network management).

I see the value of ECA on the controller as well, say a customer
network controller or an orchestrator can set the ECA on a central
controller (reference ACTN in TEAS WG). Perhaps you would consider
adding a sentence to describe this as well. The client-server
terminology in the rest of the document covers it already.

And I do see value in this and support adoption.

Thanks!
Dhruv

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Dec 2020 19:27:54 -0500

Hi,

The response to this poll is sufficient for it to be adopted.  We just 
need the 3 missing IPR statements and, assuming no surprises, the 
document can be republished as a WG document.

Authors,

Please prepare a version of the draft with only the file name changed to 
draft-ietf-netmod-eca-policy-00.  The -01 version should address issues 
/ comments raised during adoption.  Note that publication of the -00 
version is gated by the completion of the IPR poll.

Thank you!

Lou (for co-chairs)

---

From: tom petch <[email-masked]>
Date: Wed, 23 Dec 2020 11:14:11 +0000

From: netmod <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Sent: 21 December 2020 17:12

Hi Lou, WG,

<tp>
My take is that the I-D is unclear on what ECA is.

ECA has been worked on in at least two IETF WG AFAICT.  It cropped up in I2RS but as I recall, it was along the lines of 'This is ECA'  'No It is not'  'Yes it is' which gave me the impression that ECA is not a well-defined, or well-understood, term.

More recently, I2NSF have produced a YANG capability-data-model which is 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear what the relationship is between the I2NSF I-D and the netmod I-D, whether or not they are using ECA in the same sense.

Tom Petch
Thanks!
Dhruv

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Dec 2020 07:05:44 -0800

On Wed, Dec 23, 2020 at 3:14 AM tom petch <[email-masked]> wrote:

> ECA has been worked on in at least two IETF WG AFAICT.  It cropped up in
> I2RS but as I recall, it was along the lines of 'This is ECA'  'No It is
> not'  'Yes it is' which gave me the impression that ECA is not a
> well-defined, or well-understood, term.
>
> More recently, I2NSF have produced a YANG capability-data-model which is
> 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear
> what the relationship is between the I2NSF I-D and the netmod I-D, whether
> or not they are using ECA in the same sense.
>
>
Hi Tom,

It usually helps to agree on the problem-space before focusing on the
solution-space.
ECA seems like a methodology (ala MVC) more than anything else.
The problem statement seems to be that some client tasks need to be handled
on the
server using ECA methodology, instead of on the client.
Which tasks? Seems to be any task of arbitrary purpose or complexity.
And now the scope is supposed to include controllers (just another client),
so the problem-stmt
is even less clear.

The traditional approach is to pick specific client tasks to move to the
server.
The example of detecting and reporting route-flaps has been used.
(No ECA example of this complexity has been provided yet).
The traditional approach would be to write a route-flap-detection YANG
module with some
configuration, monitoring data, and notification events.

The generalized approach is likely to be extremely complex to standardize
and implement.

Tom Petch

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Dec 2020 19:08:52 +0100

> The generalized approach is likely to be extremely complex to standardize

ECA work has a long 20+ year tradition in the IETF and several
specifications have been published over the years by various working
groups. As far as I can tell, none of them got traction in terms of
signifiant deployment of interoperable implementations.

I would have hoped that the next iteration of ECA work would have
started with a deep reflection about why all the previous attempts
failed to gain traction and some genuine insights how to design things
differently in order to improve the likelihood to have impact.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Dec 2020 09:24:31 +0100

> differently in order to improve the likelihood to have impact.

Let me be a bit more explicit.

I would have expected that the senior IETF people mentioned as
co-authors or contributors, who are very well familiar with the
relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have
explained here (or in the document) why this approach to create an
interoperable standard for ECA has potential to succeed given the
limited success of the prior attempts.

Adopting this work without having answered this question seems
premature. If the proponents of this work do not have an answer to
this question, the WG will likely not find one either.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Dec 2020 01:15:10 -0800

> limited success of the prior attempts.

Over-engineered and under-specified is not a recipe for success.
The IETF used to believe in rough consensus and running code.
A YANG module that sort of compiles is not running code.
Where are the server implementations of ECA?

The solution will not be a success unless the problem, architecture, client
interaction model,
server implementation strategy, and operator interface are better defined.

There has been an incorrect assumption in the past that the massive
complexity
would be magically hidden from everybody by a super-tool (that never gets
written).

Andy

---

From: tom petch <[email-masked]>
Date: Thu, 24 Dec 2020 09:46:38 +0000

From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: 24 December 2020 09:15

On Thu, Dec 24, 2020 at 12:24 AM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

<tp>
Yes, my sense is that ECA is a language and although it is rather simple yet it requires the complexity of a compiler/interpreter on the box and unless the language is kept very simple, for example integer arithmetic only, no i18n, equality and perhaps greater than tests, then it is too complex.  Is there anything comparable that is likely to be on the boxes already, by way of operator interface or some such?  I have not written a compiler and so do not know what makes it easy, what makes it hard.

Apologies for the messed up quoting - that is what http/html does to you:-(

Tom Petch

The solution will not be a success unless the problem, architecture, client interaction model,
server implementation strategy, and operator interface are better defined.

There has been an incorrect assumption in the past that the massive complexity
would be magically hidden from everybody by a super-tool (that never gets written).

/js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Dec 2020 07:48:13 -0800

> this question, the WG will likely not find one either.
I do not support adoption of this draft, but do not object if others
want to spend time working on it. The current draft is way too complex and
not implementable.
I suspect many who supported adoption meant they are happy for somebody
else to "finish"
the draft (but they do not have time for that).

IMO this is an area where running code really matters.

We should be standardizing the "trailing edge": multiple independent
non-standard solutions
exist and the IETF creates a "best-hits" standard.

We should be avoiding Ivory Tower "leading edge" standards where design
teams decide how
the world SHOULD work, and there is no running code to back up the theory.

Andy

/js

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Dec 2020 16:26:12 -0000

Hi Juergen,

What you say about learning lessons from the past is wise and valuable.

Sadly (well, it's a good thing, really) we have new people in the IETF and
the memory of events over the last 20 years are not immediately accessible
to them. Others, who are old and grey, have been around that long but were
not necessarily involved in previous ECA discussions.

Since "intent-based networking" is a big thing once again (see recent
reports of acquisitions in this sector) the excitement about ECA may be
forgiven, but it would help to ground the discussions if those who can
remember previous efforts would share their experiences or at least some
pointers.

Best,
Adrian

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: 23 December 2020 18:09
To: Andy Bierman <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>; NETMOD Group
<[email-masked]>

/js

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 29 Dec 2020 10:21:24 -0800

Hi -

On 2020-12-29 8:26 AM, Adrian Farrel wrote:
...
> remember previous efforts would share their experiences or at least some
...

E.g. ISO/IEC 10164-19 (ITU-T X.749) immediately springs to mind.  A
cursory look at my files shows that it was under active development
in 1992, but I'm sure the underlying work was older.

A few memorable concepts from that work (from my perspective) were:

   - the need to be able to specify the set of things to
     which a policy might apply both intensionally and
     extensionally

   - distinguishing the formulation of a policy from the
     formulation of its domain of applicability
     (in the mathematical sense) and from its configured
     realm of applicability (jurisdiction) and from the
     set of instances to which it actually applies at a
     given moment

   - recognition that the problem of finding policy conflicts
     is ultimately equivalent to the halting problem if policies
     can affect the managed resources, but that conflict detection
     is still of great practical value

I'm sure there's lots more, I've had plenty of time to forget stuff.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Dec 2020 19:56:16 +0100

Adrian,

some key issues when it comes to policy-based management systems:

 - What is an adequate abstraction level to express policies and intent?

   This question has no simple answer. I believe policies need to be
   readable and hence they need to be expressed at a high level of
   abstraction and in a suitable _language_. High-level policy
   expression may be compiled down into more verbose primitive
   representations that are closer to an execution abstraction. A
   common pitfall is to start somewhere in the middle of several
   layers of abstraction and then getting stuck with something awkward
   to put a clean higher layer abstract onto and to compile things
   down to _efficient_ instrumentations.

 - Where are policies executed?

   This can range from a logically centralized policy execution
   engine, which is part of what people call an orchestrator these
   days, to fully distributed policy execution models. In reality, you
   likely want to distribute functions dynamically but this makes
   solutions technically much more complicated. Given today's scalable
   computing and networking capabilities, logically centralized
   solutions are on the rise and have replaced the distributed
   approaches of the 90s.

 - When to detect and resolve policy conflicts?

   Detecting and resolving conflicts in larger collections of policies
   is non-trivial. This includes problems ranging from micro timescale
   atomicity issues to larger timescale stability issues (interacting
   policy control loops). If policy execution is distributed (or the
   event / information sources are distributed), this ultimately
   resolves to problems such as taking consistent snapshots or finding
   ways to work with inconsistent observations of a distributed system
   that are guaranteed to converge to stable states (self-stabilizing
   algorithms).

 - Who is interested in interoperable policy representations / languages?

   The IETF is about interoperability. What are the business models
   that push for interoperable policy based management standards? Who
   benefits from having an interoperable standard and how much effort
   are organizations willing to invest into engineering a reasonable
   solution addressing the other (non-trivial) questions raised above?
   Will they be implementing the solution in their products?

My position is that there are way too many difficult technical issues
to resolve for this work to be viable for the IETF. Instead, I suggest
that people go and work out solutions and once the silver bullet has
been found, bring it to the IETF. (Historically, all attempts to cast
policies into existing data models such as MIB modules or LDAP schema
led to something awkward and unusable. I believe YANG modules are no
different.)

/js

Some relevant RFCs (there may be more):

3052 Service Management Architectures Issues and Review. M. Eder, S. Nag.
     January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:
     10.17487/RFC3052)

3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson,
     D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.
     Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:
     HISTORIC) (DOI: 10.17487/RFC3084)

3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie,
     M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.
     Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)
     (DOI: 10.17487/RFC3159)

3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan,
     K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)
     (DOI: 10.17487/RFC3318)

3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed..
     January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:
     PROPOSED STANDARD) (DOI: 10.17487/RFC3460)

3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y.
     Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:
     TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

3198 Terminology for Policy-Based Management. A. Westerinen, J.
     Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.
     Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:
     TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal.
     March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:
     10.17487/RFC4011)

4104 Policy Core Extension Lightweight Directory Access Protocol Schema
     (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.
     June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED
     STANDARD) (DOI: 10.17487/RFC4104)

8328 Policy-Based Management Framework for the Simplified Use of Policy
     Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis,
     M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML)
     (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328)

WGs/RGs that at least partially related to policy-based management:

- Simplified Use of Policy Abstractions WG (supa) (2015 - 2017)

- Policy Framework WG (policy) (1998 - 2004)

- Resource Allocation Protocol WG (rap) (1997 - 2005)

- Distributed Management WG (disman) (1996 - 2006)

- Services Management RG (smrg) (2019? - 2001?)

- Network Management RG (nmrg)

  - draft-clemm-nmrg-dist-intent (2017-2019)
  - draft-irtf-nmrg-ibn-concepts-definitions-02.txt (2019-2020)

Other resources:

- https://en.wikipedia.org/wiki/Policy-based_management

- https://www.youtube.com/watch?v=E_v-of582xg

- Boutaba, R. and I. Aib, "Policy-Based Management: A
  Historical Perspective". Journal of Network and Systems
  Management (JNSM), Springer, Vol. 15 (4), December 2007.
  https://doi.org/10.1007/s10922-007-9083-8

- Pavlou, G., "On the Evolution of Management Approaches, Frameworks
  and Protocols: A Historical Perspective". Journal of Network and
  Systems Management (JNSM), Springer, Vol. 15 (4), December 2007.
  https://doi.org/10.1007/s10922-007-9082-9

- Strassner, J., "Policy-Based Network Management: Solutions for the
  Next Generation", Morgan Kaufmann, December 2003.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Dec 2020 12:31:11 -0800

> remember previous efforts would share their experiences or at least some
I am not that interested in lessons from the past because it just sounds
like an old-timer's negativity.  But I am not interested in boiling the
ocean either.

There is an invalid assumption with ECA that the current client development
logic
(which is completely unbounded in its complexity, purpose, side effects,
design,
or server interaction model) can somehow be replaced with a highly
constrained
YANG model abstraction.

IMO a script-language-based solution is needed.
The ECA framework is good progress, but Programming in YANG is not.
However the IETF is not well-suited for standardizing programming languages
Open-Source is a much better solution path for this approach.

The solution also has to do a great job of gluing the model components to
the ECA logic and actions so there is maximum reusability and scalability.

Most importantly, it has to be easy for an operator to program and debug
ECA.
There aren't going to be any magic tools to hide the complexity.

Best,

Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Dec 2020 21:22:44 -0000

Thanks Juergen and Randy,

There's plenty here to chew on. Happy New Year's Eve reading 😊

Cheers,
Adrian

-----Original Message-----
From: Juergen Schoenwaelder <[email-masked]> 
Sent: 29 December 2020 18:56
To: Adrian Farrel <[email-masked]>
Cc: 'NETMOD Group' <[email-masked]>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Adrian,

/js

Other resources:

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 29 Dec 2020 13:35:53 -0800

Hi -

On 2020-12-29 12:31 PM, Andy Bierman wrote:
...
> There is an invalid assumption with ECA that the current client 
> development logic

There's a tension between the convenience of scripting languages and the
desire to be able to reason about how policies interact, particularly if
one is approaching the problem from a perspective of goal-oriented
management.  To me that suggests that more structured (than mere
scripting) mechanisms are needed to to identify what aspects of what
resources are inputs or outputs in the operation of a given policy.
(That also has the nice side-effect of making policy formulations
vastly more re-usable.)

For the ISO/ITU work, my recollection is that the direction in which
it was headed was to use facilities of the management information
model and protocol (e.g. scoping, filtering, allomorphism, attribute
re-use, etc.) for the parameterization, but to use scripting for the
policy's "body".  I don't know if that's how things ultimately turned
out; I've been away from the work for decades.

If all the semantics, including specification of applicability,
are embodied in the script itself, one ends up with something
like the script MIB.  A potentially useful thing, but not particularly
helpful if one's goal is to be able to reason about policy interaction
or to formulate things in terms of goals.

Randy

---

From: tom petch <[email-masked]>
Date: Wed, 30 Dec 2020 12:49:30 +0000

From: netmod <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Sent: 29 December 2020 16:26

Hi Juergen,

<tp>
Adrian,
Reading Juergen's post I thought of the work of the DISMAN WG back in 2002/2003 which produced MIBs for alarms, events, alarm reporting and such like.  I thought it a great idea which chimed with proprietary work I had seen a few years earlier but the IETF work seemed not to catch on.  Randy was active in that while Juergen could say whether or not it was the kind of thing he had in mind.

With hindsight, I suspect that Andy's point about complexity of implementation was a factor.

Tom Petch

Best,
Adrian

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: 23 December 2020 18:09
To: Andy Bierman <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>; NETMOD Group
<[email-masked]>

/js