What action type do we need to support?

[billwuqin]

Igor said: " Also we should want to introduce some basic Actions from the get go, otherwise, howdoes this work ever take off? Do you mean that we need to limit ourselves with notifications to the client at the first stage, or network re-configurations could be also ECA Actions? "

[billwuqin]

Andy's response to Igor: " I agree some basic actions are useful. I prefer that this module leverage other standard modules whenever possible "

[billwuqin]

My response to Andy and Igor as follows: " [Qin]: We have many actions type, notify-action is the basic action, in my opinion. Regarding leveraging other standard modules, take rpc-operation as an example, I think rpc-operation can use nc-action-xpath to reference rpc defined in other standard module. But the current description statement of nc-action-xpath seems not clear about this, or emphasize the difference between YANG action and YANG RPC, both can not be used at the same time. See definition of nc-action-xpath as follows: " leaf nc-action-xpath { type string; description "The location where the YANG action is defined. This is used if and only if a YANG action is called. This leaf is not set when a YANG RPC is called."; } "

[billwuqin]

Forward Andy's response: " 发件人: Andy Bierman [mailto:andy@yumaworks.com] 发送时间: 2020年5月20日 1:16 收件人: Qin Wu bill.wu@huawei.com 抄送: Igor Bryskin i_bryskin@yahoo.com; draft-wwx-netmod-event-yang@ietf.org 主题: Re: New Version Notification for draft-wwx-netmod-event-yang-07.txt

Hi,

I need to catch up on the draft details soon.

I like an architecture that relies on the NETCONF/YANG interface of the device. The device event streams (plus pseudo-events) are the ECA logic input. The device RPC requests (include YANG action) are the ECA logic output.

This allows ECA clients to use the same ECA logic on a controller platform or on a native device platform. Controller deployment is important because not all native platforms will be able to support ECA, or will not be upgraded soon enough.

The action taken by an ECA policy will rarely be as simple as sending 1 hard-wired notification or RPC request. Even a simple edit can be done about 10 different ways on an arbitrary server.

IMO there needs to be an extensible library of pseudo-commands (or scripts) that can be used by the ECA logic. e.g, a primitive called "update-config" that handles all the editing variants like :candidate, :writable-running, :startup, and even locking and NMDA.

The extensible library architecture can be standardized without picking a programming language. This allows standard and vendor pseudo-commands to be supported from the start. Binding the YANG interface to a real programming language API could be opensource or maybe standardized later.

Andy "