[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

NETMOD Working Group                                        M. Boucadair
Internet-Draft                                                    Orange
Intended status: Standards Track                                   Q. Wu
Expires: May 6, 2020                                             Z. Wang
                                                                  Huawei
                                                                 D. King
                                                    Lancaster University
                                                                  C. Xie
                                                           China Telecom
                                                        November 3, 2019


   Framework for Use of ECA (Event Condition Action) in Network Self
                               Management
                   draft-bwd-netmod-eca-framework-00

Abstract

   Event-driven management is meant to provide a useful method to
   monitor state change of managed objects and resources, and facilitate
   automatic triggering of a response to events, based on an established
   set of rules.  This would provide rapid autonomic responses to
   specific conditions, enabling self-management behaviors, including:
   self-configuration, self-healing, self-optimization, and self-
   protection.

   This document provides a framework that describes the architecture
   for supporting event-driven management of managed object state across
   devices.  It does not describe specific protocols or protocol
   extensions needed to realize the objectives and capabilities
   discussed in the document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 6, 2020.



Boucadair, et al.          Expires May 6, 2020                  [Page 1]


Internet-Draft                ECA Framework                November 2019


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Defining Network Event and Network Control Logic  . . . .   4
     2.2.  Delegating Network Control Logic to Network Device  . . .   4
     2.3.  Executing ECA Script in the Network Device  . . . . . . .   5
     2.4.  Event-Driven Notification Handling  . . . . . . . . . . .   6
     2.5.  Requisite State Information . . . . . . . . . . . . . . .   6
   3.  Architectural Concepts  . . . . . . . . . . . . . . . . . . .   7
     3.1.  What is Defined in ECA Policy?  . . . . . . . . . . . . .   7
     3.2.  Where is ECA Script and State Held? . . . . . . . . . . .   8
     3.3.  What State is Held? . . . . . . . . . . . . . . . . . . .   9
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Telemetry Automation in the Network Device  . . . . . . .  10
     4.2.  Detecting and Resolving Policy Conflict . . . . . . . . .  12
     4.3.  Chain Reaction of Coordinated Events  . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Network management data objects can often take two different values:
   the value configured by the administrator or an application
   (configuration) and the value that the device is actually using
   (operational state).  Particularly, these network management data
   objects can be fetched from various different YANG datastore




Boucadair, et al.          Expires May 6, 2020                  [Page 2]


Internet-Draft                ECA Framework                November 2019


   [RFC8342] by subscribing to continuous datastore updates [RFC8641]
   without needing to poll for data periodically.

   YANG-Push mechanisms are used to select which data objects are of
   interest using filters and provide frequent or prompt updates of
   remote object state, thus allowing (client) applications to maintain
   a continuous view of operational data and state and enabling a
   network operator to optimize the system behavior across the whole
   network to meet objectives and provide some performance guarantees
   for network services.

   Network management may rely upon one or multiple policies to
   influence management behavior within the system and make sure
   policies are enforced or executed correctly so that there will no
   conflict in policies and that the observed behavior is the expected
   one.  Event-driven policy (i.e., ECA Policy [RFC8328]) enables
   actions being automatically triggered based on when certain events in
   the network occur while certain conditions hold.  YANG Push
   subscription provides a source for such events.

   It is often the case that where Event Condition Action (ECA) is
   defined is decoupled from where ECA is executed.  ECA Engine in the
   management system or the network device defines one or multiple
   events corresponding to the workflow management, correlate these
   events with action triggers and create ECA policy.  ECA policy can be
   enforced either at the management system or pushed to and executed by
   the network device.  Alternative, some of these predefined events can
   be translated into filter in the YANG push subscription which is in
   turn used to select data objects that are of interest.  When these
   data objects are streamed out to the destination, both the management
   system and network device check for the condition when the event is
   observed.  If the condition is satisfied, the ECA script is executed.

   Event-driven management (of states of managed objects) across a wide
   range of devices can be used to monitor state changes of managed
   objects or resource and automatic trigger of rules in response to
   events so as to better service assurance for customers and to provide
   rapid autonomic response that can exhibit self-management properties
   including self-configuration, self-healing, self-optimization, and
   self-protection.

   This document provides a framework that describes the architecture
   for supporting such event-driven management.

   This document does not describe specific protocols or protocol
   extensions needed to realize the objectives and capabilities
   discussed in the document.




Boucadair, et al.          Expires May 6, 2020                  [Page 3]


Internet-Draft                ECA Framework                November 2019


1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Problem Statement

2.1.  Defining Network Event and Network Control Logic

   Datastores are used by network management protocols such as NETCONF
   [RFC6241] and RESTCONF [RFC8040].  Operational state data objects, in
   the operational state datastore, provide network visibility to the
   actual state of the network, and ensure the network is running
   efficiently.

   The network event are used to keep track of state of changes
   associated with one of multiple operational state data objects in the
   network device.  Typical examples of network event include a fault,
   an alarm, a change in network state, network security threat,
   hardware malfunction, buffer utilization crossing a threshold,
   network connection setup, and an external input to the system.

   To control which state a network device should be in or is allowed to
   be in at any given time, a set of conditions and actions are defined
   and correlated with network events, which constitute an event-driven
   policy or network control logic.

   YANG Push subscription allows client applications to select which
   datastore nodes are of interest and provides source of network
   events.  The NETCONF client can define event-based policy based on
   YANG Push subscription data source or some other data source.

2.2.  Delegating Network Control Logic to Network Device

   Usually the NETCONF clients subscribe to continuous datastore updates
   and rely on event notifications sent to the NETCONF client to check
   for the condition so that reaction to many network events may be very
   slow in the face of communication glitches between the client and the
   sever.  Such solution doesn't scale well.

   It is more desirable in many circumstances to delegate all event
   response behaviors (e.g., recover from network failure, instruct the
   network to control congestion) to the NETCONF server so that the
   network can react to network change as quickly as the event is
   detected.



Boucadair, et al.          Expires May 6, 2020                  [Page 4]


Internet-Draft                ECA Framework                November 2019


   The event response behaviors delegation can be done using YANG push
   subscription filter enhancements, e.g., define a new filter to allow
   the NETCONF client send updates only when the value falls within a
   certain range.  Another example is to define a filter to allow the
   NETCONF client send updates only when the value exceeds a certain
   threshold for the first time but not again until the threshold is
   cleared.  In the latter case, additional state is required.

   In addition, the event response behavior delegation can be done by
   pushing ECA policy to the network device.  Similar to YANG Push
   subscription filter, the ECA approach also includes filter and
   defines it as Event and Condition separately in the ECA policy model.
   Different from using YANG Push subscription filter, ECA allow a group
   of events to be observed, allow multiple actions to be triggered,
   e.g., sending log report notification, add or remove multiple YANG
   Push subscriptions.

2.3.  Executing ECA Script in the Network Device

   When the YANG Push subscription filter or ECA policy is pushed to the
   server, the server is expected to register the event conveyed in the
   YANG push subscription filter or Event-driven policy, generate server
   specific script.  With a server specific script, the server can
   manipulate various network resources autonomously.

   After the event registration, the server subscribes to its own
   publications encapsulated in the event notification with respect to
   all events that are associated with ECA Policy so that the
   publication is intercepted and all events specified in the ECA policy
   model are continuously monitored by the server before the publication
   is encapsluated in the event notification and sent to the YANG Push
   subscription's client.  At the moment of event detection, the server
   loads the operational state data object filtered by the YANG Push
   subscription's filters or ECA policy into the auto-configured ECA's
   event and execute the ECA's associated condition-action chain.

   The condition is associated with an ECA event and evaluated only
   within event threads triggered by the event detection, and the action
   corresponds to a set of statements that may trigger state changes in
   the device or publication content changes in the Event subscription
   and could be various different operations to be carried out by the
   server:

   o  Configuration data object reconfiguration;

   o  ECA Log report Notification;

   o  Add or remove one or multiple YANG Push Subscriptions;



Boucadair, et al.          Expires May 6, 2020                  [Page 5]


Internet-Draft                ECA Framework                November 2019


   o  Invoke another Event in the same network device or different
      network device.

2.4.  Event-Driven Notification Handling

   ECA notifications are the only ECA actions that directly interact and
   hence need to be unambiguously understood by the client.

   ECA notification can be sent when the client may find any interesting
   about the associated event with all the logic to compute said data
   (e.g., datastore content changes history, median values), and
   delegate computation task to the server via an ECA script.

   When a "Send ECA notification" action is configured as an ECA Action,
   the client may receive different ECA notification associated with the
   same event or different events, YANG Push Publication will also be
   sent through Event notification.  Therefore it is important for
   client to correlate of events and ECA notifications received from the
   server.

   When ECA notification and YANG Push Publication are both pushed to
   the client, the client can execute client specific script generated
   in the same way as the server does and manipulate various network
   resources autonomously remotely.  However the network resource can
   not be manipulated twice in both client and the server.  Therefore
   policy conflict should be avoided or resolved.

2.5.  Requisite State Information

   A ECA policy rule is read as: When event occurs in a situation where
   condition is true, then action is executed.  The ECA associated state
   is used to indicate when Events are triggered and what actions must
   be performed on the occurrence of an event.

   A simple information model for one piece of the ECA associated state
   is as follows:

      {
        event name;
        start time;
        end time;
        threshold value;
        event occurrence times
      }

   The event that is observed could be a fault, an alarm, a change in
   network state, network security threats, hardware malfunctions,




Boucadair, et al.          Expires May 6, 2020                  [Page 6]


Internet-Draft                ECA Framework                November 2019


   buffer utilization exceeding a threshold.  For any of the
   aforementioned events, multiple actions may be triggered.

3.  Architectural Concepts

3.1.  What is Defined in ECA Policy?

   ECA Event is a change of datastore operational state.  Each policy
   rule consists of a set of conditions and a set of actions.  Policy
   rules may be aggregated into policy groups.  These groups may be
   nested, to represent a hierarchy of policies.

   ECA Condition is evaluated to TRUE or FALSE logical expression.  ECA
   condition is specified as a hierarchy of comparisons and logical
   combinations of thereof, which allows for configuring logical
   hierarchies.  One of ECA condition example is logical hierarchies
   specified in a form of:

  <target><relation><arg>
  where target represent managed data object while arg represent either
  constant/enum/identity, Policy variable or pointed by XPath data store
  node or sub-tree,

      relation is one of the comparison operations from the set: ==, !=,
        >, <, >=, <=

   Logical calculation between multiple trigger conditions:

   The YANG language cannot clearly describe complex logical operations
   between different condition lists under the same event, for example,
   (condition A & condition B) or condition C.

   By default, the ECA model performs logic "AND" operation between
   different conditions in the same Event.  That is, event is triggered
   when different conditions are met at the same time.  For example,

   Event A consists of two conditions:
   o Condition A;
   o Condition B;
   If Condition A AND Condition B is met;
   Event A is triggered;
   Action A is executed.

   For the logic "OR" operation between different conditions, the
   conditions can be defined in different events.  If the corresponding
   event is triggered, the same action is executed.  For example,





Boucadair, et al.          Expires May 6, 2020                  [Page 7]


Internet-Draft                ECA Framework                November 2019


   Event A is triggered on Condition A.
   Event B is triggered on Condition B.
   If Condition A is met;
   Event A is triggered;
   Action A is executed.
   If Condition B is met;
   Event B is triggered;
   Action A is executed.

   ECA Action is one of the following operations to be carried out by a
   server:

   o  Configuration data object reconfiguration

   o  ECA Log report Notification

   o  Add or remove one or multiple YANG Push Subscriptions

   o  Invoke another Event in the same network device or different
      network device

   In case of one event triggering another event, a set of events can be
   grouped together and executed, in a coordinated manner.  The action
   associated with the event can be executed in the same network device
   or in different network devices.  In the latter case, events executed
   by different network devices need to coordinate as a group to fulfil
   a task, previously set.

3.2.  Where is ECA Script and State Held?

   The ECA state information described in Section 2.5 and associated ECA
   script has to be held somewhere.  There are two locations where this
   applies:

   o  in a central controller where decisions about resource adjustment
      are made;

   o  in the network nodes where the resources exist.

   The first of these locations have a good visibility of the whole
   network or information of the flow packets are going to take through
   the entire network, but requires a centralized, searchable repository
   of all network information that can be used for diagnostics, service
   assurance, maintenance or audit purposes.  The response to network
   event can be slow since all monitored data objects from large amount
   of network devices need to be sent and correlated at the point where
   decisions about resource adjustment are made, less alone multiple
   network event triggering a single action.



Boucadair, et al.          Expires May 6, 2020                  [Page 8]


Internet-Draft                ECA Framework                November 2019


   Conversely, if the ECA state and associated ECA script is held in the
   network nodes, it makes policing of resource adjustment easier.  It
   means many points in the network can have immediate response to
   network event.  The limitation is the configurations and state of a
   particular device does not have the visibility of the whole network
   or information of the flow packets are going to take through the
   entire network, so they provide little insight into network level
   policy-related behavior.

3.3.  What State is Held?

   As already described, the network control logic associated with ECA
   script needs access to ECA state table.  It stores network events
   pushed from YANG push subscription or ECA policy model, threshold
   value it set for observed network management data object.

   In addition, when the event needs to be continuously monitored, the
   Event scheduling information such as start time, end time can be
   included.

   In case of sending updates only when the value exceeds a certain
   threshold for the first time but not again until the threshold is
   cleared, a threshold clear flag is also needed.

   In case of monitoring the data change or data change rate, for
   example, YANG Push On-Change mode [RFC8641] or ECA Threshold Test
   [I.D-wwx-netmod-event-yang], the ECA state table need to store
   history state to check the condition to be satisfied and determine
   the current state.

4.  Architecture Overview

   The architectural considerations and conclusions described in the
   previous section lead to the architecture described in this section
   and illustrated in Figure 1.  The interfaces and interactions shown
   in the figure and labeled (a) through (f) are described in
   Section 4.1.














Boucadair, et al.          Expires May 6, 2020                  [Page 9]


Internet-Draft                ECA Framework                November 2019


      +----------------------------------------------------+
      |Management System              +----------+         |
      |                      +--------+ECA Script|         |
      |+----------+  +-------+--+     +----+-----+         |
      ||ECA Design|  |   Notif  <----------+-----------+   |
      |+-+---+----+  |Monitoring<----+     |           |   |
      |  |   |       +^------^--+    |     |           |   |
      +--+---+--------+------+-------+-----+---------- +---+
     (a) |   |(b)     |(c)   |(d)     (e)  | (f)       |(e)
     ECA |   |YANG    |      |       |Event| Config    |Event
    Model|   |Push    |Event |ECA    |Notif| Model     |Notif
         |   |Sub     |Notif |Notif  |     |           |
         |   |Filter  |      |       |     |           |
   ------+---+--------+------+-------+-----+---------- +-------------
         |   |        |      |       |     |           |      Network
      +--+---+--------+------+-------+-----V-+   +-----+-----+
      |+-V---V----+   |      |               |   |           |
      ||ECA Script+---+      |               |   |           |
      ||          |----------+               |   |           |
      |+----+-----+                          |   | Network   |
      |+----V----+                           |   | Device B  |
      ||ECA State|                           |   |           |
      |+---------+ Network Device A          |   |           |
      +--------------------------------------+   +-----------+

      Figure 1.Reference Architecture for Use of ECA and Network Self
                                Management

4.1.  Telemetry Automation in the Network Device

   As shown in Figure 1, some component in the management system defines
   and designs ECA Policy rule.  This may be invoked by a Service
   assurance application or device fault self-management application.
   We show this component on the figure as the "ECA Design", and it
   extracts Event and Condition in the ECA model and fill into YANG Push
   Subscription as filter.  When YANG Push subscription filter is pushed
   down to the network device, ECA script can be generated automatically
   from it (ECA script can also be generated in the management system
   and downloaded to the network device).  The YANG Push subscription
   request, indicated on Figure 1 by the arrow (b), includes all of the
   parameters of network management data objects that the requester
   wishes to be supplied, such as filter node, threshold value, start
   time, and end time.  Note that the requester in this case may be the
   management system shown in the figure or a distinct system such as
   data collector.

   The network device registers network event that is corresponding to
   the filter carried in the YANG Push Subscription and enters the



Boucadair, et al.          Expires May 6, 2020                 [Page 10]


Internet-Draft                ECA Framework                November 2019


   network event in its ECA state and then the server subscribes to its
   own continuous datastore updates in the operational state datastore
   that is encapsulated in the event notification as publication to the
   YANG Push subscriber.

   Upon the network event is detected, the server intercepts the
   publication of subscribed data and loads the operational state data
   object in the operational state datastore into the auto-configured
   ECA's event and execute the ECA's associated condition.  When ECA
   Condition is evaluated to TRUE, the operational state data objects
   will be filtered and the remaining data objects will be entered back
   into the publication of subscribed data and encapsulated in the event
   notification (c) and sent to notification monitoring component in the
   management system.

   The notification monitoring component may further derive some new ECA
   policy rule and fed into ECA Design component.  The remaining
   procedure is same as the procedure starting from (b).

   Alternatively, the ECA design component can push ECA model directly
   with additional actions included (a) to the network device, ECA
   script is generated automatically from ECA model.  The ECA model
   request, indicated on Figure 1 by the arrow (a), includes additional
   action parameters besides one included in the YANG Push subscription
   request.

   The network device register network event that is corresponding to
   the ECA carried in the ECA request and enter them in its ECA state
   and then the server subscribes to its own continuous datastore
   updates in the operational state datastore that is encapsulated in
   the event notification as publication to the YANG Push subscriber.

   Upon the network event is detected, the server loads the operational
   state data object in the operational state datastore into the auto-
   configured ECA's event and execute the ECA's associated condition.
   Different from YANG Push subscription filter, the server will not
   intercept the publication of subscribed data.  Instead, it allows the
   server to trigger a set of actions associated with the network event,
   e.g., send ECA log report notification, add/remove YANG push
   subscription, reconfigure the network management data object within
   the control of the server.  After all actions are executed, one or
   multiple separate ECA notifications (d) can be sent to the
   notification monitoring component in the management system, the
   remaining procedure is same as YANG Push subscription case.

   Conversely,when, network level policy-related behavior became
   necessary, once a subscription has been set up, event notification
   message associated with the subscription from different network



Boucadair, et al.          Expires May 6, 2020                 [Page 11]


Internet-Draft                ECA Framework                November 2019


   device will be sent to the notification monitoring component in the
   management system(e), which in turn trigger network behavior change
   on the network device via configuration model (f).

4.2.  Detecting and Resolving Policy Conflict

   There are two possible places where policy conflict can take places:

   1.  An event triggers multiple actions in the network device that
       cannot occur together as specified by the system administrator.

   2.  Multiple ECA notifications or multiple combination of ECA
       notification and Event notification lead to generate ECA policy
       that cannot occur together.

   In both case, policy conflict can be addressed by policy conflict
   detection mechanism and Policy validation mechanism.

4.3.  Chain Reaction of Coordinated Events

   In some cases events executed by the same or different network
   devices can be executed in a coordinated manner.  To make sure these
   network devices coordinate on some task or a group of events
   coordinate in the same network device, these events on the same or
   different network devices need to be pre-configured to work together.
   During capability negotiation phase, the management system should
   know what each network device supports, which event may take action,
   and what condition on which event.  So ECA model with multiple events
   can be configured on the network device to allow one event be
   triggered by another event configured on the same network device.

5.  Security Considerations

   The framework described in this document for supporting autonomic
   event-driven self-management will require consideration of potential
   security and operational requirements, and ensure best security
   practices and methods are applied.

   Key security considerations that will be discussed in future versions
   of this document, include:

   o  Authentication of ECA programming requests;

   o  Application of suitable authorization methods when enabling ECA
      functions;

   o  Securing ECA communication channels;




Boucadair, et al.          Expires May 6, 2020                 [Page 12]


Internet-Draft                ECA Framework                November 2019


   o  Locking ECA device config and state databases;

   o  Mitigation, and negation, of ECA functional component attacks;

   o  Logging and auditing of ECA transactions;

   o  Maintaining ECA device confidentially.

6.  Acknowledgements

   This work has benefited from the discussions of ECA Policy over the
   years.  In particular, the SUPA project [
   https://datatracker.ietf.org/wg/supa/about/ ] provided approaches to
   express high-level, possibly network-wide policies to a network
   management function (within a controller, an orchestrator, or a
   network element).

   Igor Bryskin, Xufeng Liu, Alexander Clemm, Henk Birkholz, Tianran
   Zhou contributed to an earlier version of [GNCA].  We would like to
   thank the authors of that document on event response behaviors
   delegation for material that assisted in thinking that helped develop
   this document.

   Finally, the authors would like to thank David Hutchison and Mehdi
   Bezahaf at Lancaster University, Phil Eardley and Andy Reid at
   British Telecom, for their input and applicability of ECA device self
   management to the Next Generation Converged Digital Infrastructure
   (NG-CDI) project.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.






Boucadair, et al.          Expires May 6, 2020                 [Page 13]


Internet-Draft                ECA Framework                November 2019


   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

7.2.  Informative References

   [I-D.bryskin-netconf-automation-yang]
              Bryskin, I., Liu, X., Clemm, A., Birkholz, H., and T.
              Zhou, "Generalized Network Control Automation YANG Model",
              draft-bryskin-netconf-automation-yang-03 (work in
              progress), July 2019.

   [I-D.clemm-netmod-push-smart-filters]
              Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T.,
              Zheng, G., and H. Birkholz, "Smart Filters for Push
              Updates", draft-clemm-netmod-push-smart-filters-01 (work
              in progress), October 2018.

   [I-D.clemm-nmrg-dist-intent]
              Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura,
              "Intent-Based Networking - Concepts and Overview", draft-
              clemm-nmrg-dist-intent-02 (work in progress), July 2019.

   [I-D.wwx-netmod-event-yang]
              Wang, Z., WU, Q., Xie, C., Bryskin, I., Liu, X., Clemm,
              A., Birkholz, H., and T. Zhou, "A YANG Data model for ECA
              Policy Management", draft-wwx-netmod-event-yang-04 (work
              in progress), November 2019.

   [RFC8328]  Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
              M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
              Management Framework for the Simplified Use of Policy
              Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328,
              March 2018, <https://www.rfc-editor.org/info/rfc8328>.

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/info/rfc8572>.






Boucadair, et al.          Expires May 6, 2020                 [Page 14]


Internet-Draft                ECA Framework                November 2019


Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes 35000
   France

   Email: mohamed.boucadair@orange.com


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com


   Michael Wang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: wangzitao@huawei.com


   Daniel King
   Lancaster University
   Bailrigg, Lancaster LA1 4YW
   UK

   Email: d.king@lancaster.ac.uk


   Chongfeng Xie
   China Telecom
   Beijing
   China

   Email: xiechf.bri@chinatelecom.cn









Boucadair, et al.          Expires May 6, 2020                 [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/