idnits 2.17.00 (12 Aug 2021) /tmp/idnits36142/draft-bwd-netmod-eca-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 3, 2019) is 923 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8641' is mentioned on line 410, but not defined == Missing Reference: 'RFC6241' is mentioned on line 159, but not defined == Missing Reference: 'RFC8040' is mentioned on line 159, but not defined == Missing Reference: 'GNCA' is mentioned on line 584, but not defined == Unused Reference: 'RFC7950' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC8341' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'I-D.bryskin-netconf-automation-yang' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-netmod-push-smart-filters' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-nmrg-dist-intent' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'I-D.wwx-netmod-event-yang' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC8572' is defined on line 653, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-clemm-nmrg-dist-intent-02 == Outdated reference: A later version (-10) exists of draft-wwx-netmod-event-yang-04 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track Q. Wu 5 Expires: May 6, 2020 Z. Wang 6 Huawei 7 D. King 8 Lancaster University 9 C. Xie 10 China Telecom 11 November 3, 2019 13 Framework for Use of ECA (Event Condition Action) in Network Self 14 Management 15 draft-bwd-netmod-eca-framework-00 17 Abstract 19 Event-driven management is meant to provide a useful method to 20 monitor state change of managed objects and resources, and facilitate 21 automatic triggering of a response to events, based on an established 22 set of rules. This would provide rapid autonomic responses to 23 specific conditions, enabling self-management behaviors, including: 24 self-configuration, self-healing, self-optimization, and self- 25 protection. 27 This document provides a framework that describes the architecture 28 for supporting event-driven management of managed object state across 29 devices. It does not describe specific protocols or protocol 30 extensions needed to realize the objectives and capabilities 31 discussed in the document. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 6, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Defining Network Event and Network Control Logic . . . . 4 71 2.2. Delegating Network Control Logic to Network Device . . . 4 72 2.3. Executing ECA Script in the Network Device . . . . . . . 5 73 2.4. Event-Driven Notification Handling . . . . . . . . . . . 6 74 2.5. Requisite State Information . . . . . . . . . . . . . . . 6 75 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 7 76 3.1. What is Defined in ECA Policy? . . . . . . . . . . . . . 7 77 3.2. Where is ECA Script and State Held? . . . . . . . . . . . 8 78 3.3. What State is Held? . . . . . . . . . . . . . . . . . . . 9 79 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 80 4.1. Telemetry Automation in the Network Device . . . . . . . 10 81 4.2. Detecting and Resolving Policy Conflict . . . . . . . . . 12 82 4.3. Chain Reaction of Coordinated Events . . . . . . . . . . 12 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 7.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Network management data objects can often take two different values: 93 the value configured by the administrator or an application 94 (configuration) and the value that the device is actually using 95 (operational state). Particularly, these network management data 96 objects can be fetched from various different YANG datastore 98 [RFC8342] by subscribing to continuous datastore updates [RFC8641] 99 without needing to poll for data periodically. 101 YANG-Push mechanisms are used to select which data objects are of 102 interest using filters and provide frequent or prompt updates of 103 remote object state, thus allowing (client) applications to maintain 104 a continuous view of operational data and state and enabling a 105 network operator to optimize the system behavior across the whole 106 network to meet objectives and provide some performance guarantees 107 for network services. 109 Network management may rely upon one or multiple policies to 110 influence management behavior within the system and make sure 111 policies are enforced or executed correctly so that there will no 112 conflict in policies and that the observed behavior is the expected 113 one. Event-driven policy (i.e., ECA Policy [RFC8328]) enables 114 actions being automatically triggered based on when certain events in 115 the network occur while certain conditions hold. YANG Push 116 subscription provides a source for such events. 118 It is often the case that where Event Condition Action (ECA) is 119 defined is decoupled from where ECA is executed. ECA Engine in the 120 management system or the network device defines one or multiple 121 events corresponding to the workflow management, correlate these 122 events with action triggers and create ECA policy. ECA policy can be 123 enforced either at the management system or pushed to and executed by 124 the network device. Alternative, some of these predefined events can 125 be translated into filter in the YANG push subscription which is in 126 turn used to select data objects that are of interest. When these 127 data objects are streamed out to the destination, both the management 128 system and network device check for the condition when the event is 129 observed. If the condition is satisfied, the ECA script is executed. 131 Event-driven management (of states of managed objects) across a wide 132 range of devices can be used to monitor state changes of managed 133 objects or resource and automatic trigger of rules in response to 134 events so as to better service assurance for customers and to provide 135 rapid autonomic response that can exhibit self-management properties 136 including self-configuration, self-healing, self-optimization, and 137 self-protection. 139 This document provides a framework that describes the architecture 140 for supporting such event-driven management. 142 This document does not describe specific protocols or protocol 143 extensions needed to realize the objectives and capabilities 144 discussed in the document. 146 1.1. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2. Problem Statement 156 2.1. Defining Network Event and Network Control Logic 158 Datastores are used by network management protocols such as NETCONF 159 [RFC6241] and RESTCONF [RFC8040]. Operational state data objects, in 160 the operational state datastore, provide network visibility to the 161 actual state of the network, and ensure the network is running 162 efficiently. 164 The network event are used to keep track of state of changes 165 associated with one of multiple operational state data objects in the 166 network device. Typical examples of network event include a fault, 167 an alarm, a change in network state, network security threat, 168 hardware malfunction, buffer utilization crossing a threshold, 169 network connection setup, and an external input to the system. 171 To control which state a network device should be in or is allowed to 172 be in at any given time, a set of conditions and actions are defined 173 and correlated with network events, which constitute an event-driven 174 policy or network control logic. 176 YANG Push subscription allows client applications to select which 177 datastore nodes are of interest and provides source of network 178 events. The NETCONF client can define event-based policy based on 179 YANG Push subscription data source or some other data source. 181 2.2. Delegating Network Control Logic to Network Device 183 Usually the NETCONF clients subscribe to continuous datastore updates 184 and rely on event notifications sent to the NETCONF client to check 185 for the condition so that reaction to many network events may be very 186 slow in the face of communication glitches between the client and the 187 sever. Such solution doesn't scale well. 189 It is more desirable in many circumstances to delegate all event 190 response behaviors (e.g., recover from network failure, instruct the 191 network to control congestion) to the NETCONF server so that the 192 network can react to network change as quickly as the event is 193 detected. 195 The event response behaviors delegation can be done using YANG push 196 subscription filter enhancements, e.g., define a new filter to allow 197 the NETCONF client send updates only when the value falls within a 198 certain range. Another example is to define a filter to allow the 199 NETCONF client send updates only when the value exceeds a certain 200 threshold for the first time but not again until the threshold is 201 cleared. In the latter case, additional state is required. 203 In addition, the event response behavior delegation can be done by 204 pushing ECA policy to the network device. Similar to YANG Push 205 subscription filter, the ECA approach also includes filter and 206 defines it as Event and Condition separately in the ECA policy model. 207 Different from using YANG Push subscription filter, ECA allow a group 208 of events to be observed, allow multiple actions to be triggered, 209 e.g., sending log report notification, add or remove multiple YANG 210 Push subscriptions. 212 2.3. Executing ECA Script in the Network Device 214 When the YANG Push subscription filter or ECA policy is pushed to the 215 server, the server is expected to register the event conveyed in the 216 YANG push subscription filter or Event-driven policy, generate server 217 specific script. With a server specific script, the server can 218 manipulate various network resources autonomously. 220 After the event registration, the server subscribes to its own 221 publications encapsulated in the event notification with respect to 222 all events that are associated with ECA Policy so that the 223 publication is intercepted and all events specified in the ECA policy 224 model are continuously monitored by the server before the publication 225 is encapsluated in the event notification and sent to the YANG Push 226 subscription's client. At the moment of event detection, the server 227 loads the operational state data object filtered by the YANG Push 228 subscription's filters or ECA policy into the auto-configured ECA's 229 event and execute the ECA's associated condition-action chain. 231 The condition is associated with an ECA event and evaluated only 232 within event threads triggered by the event detection, and the action 233 corresponds to a set of statements that may trigger state changes in 234 the device or publication content changes in the Event subscription 235 and could be various different operations to be carried out by the 236 server: 238 o Configuration data object reconfiguration; 240 o ECA Log report Notification; 242 o Add or remove one or multiple YANG Push Subscriptions; 243 o Invoke another Event in the same network device or different 244 network device. 246 2.4. Event-Driven Notification Handling 248 ECA notifications are the only ECA actions that directly interact and 249 hence need to be unambiguously understood by the client. 251 ECA notification can be sent when the client may find any interesting 252 about the associated event with all the logic to compute said data 253 (e.g., datastore content changes history, median values), and 254 delegate computation task to the server via an ECA script. 256 When a "Send ECA notification" action is configured as an ECA Action, 257 the client may receive different ECA notification associated with the 258 same event or different events, YANG Push Publication will also be 259 sent through Event notification. Therefore it is important for 260 client to correlate of events and ECA notifications received from the 261 server. 263 When ECA notification and YANG Push Publication are both pushed to 264 the client, the client can execute client specific script generated 265 in the same way as the server does and manipulate various network 266 resources autonomously remotely. However the network resource can 267 not be manipulated twice in both client and the server. Therefore 268 policy conflict should be avoided or resolved. 270 2.5. Requisite State Information 272 A ECA policy rule is read as: When event occurs in a situation where 273 condition is true, then action is executed. The ECA associated state 274 is used to indicate when Events are triggered and what actions must 275 be performed on the occurrence of an event. 277 A simple information model for one piece of the ECA associated state 278 is as follows: 280 { 281 event name; 282 start time; 283 end time; 284 threshold value; 285 event occurrence times 286 } 288 The event that is observed could be a fault, an alarm, a change in 289 network state, network security threats, hardware malfunctions, 290 buffer utilization exceeding a threshold. For any of the 291 aforementioned events, multiple actions may be triggered. 293 3. Architectural Concepts 295 3.1. What is Defined in ECA Policy? 297 ECA Event is a change of datastore operational state. Each policy 298 rule consists of a set of conditions and a set of actions. Policy 299 rules may be aggregated into policy groups. These groups may be 300 nested, to represent a hierarchy of policies. 302 ECA Condition is evaluated to TRUE or FALSE logical expression. ECA 303 condition is specified as a hierarchy of comparisons and logical 304 combinations of thereof, which allows for configuring logical 305 hierarchies. One of ECA condition example is logical hierarchies 306 specified in a form of: 308 309 where target represent managed data object while arg represent either 310 constant/enum/identity, Policy variable or pointed by XPath data store 311 node or sub-tree, 313 relation is one of the comparison operations from the set: ==, !=, 314 >, <, >=, <= 316 Logical calculation between multiple trigger conditions: 318 The YANG language cannot clearly describe complex logical operations 319 between different condition lists under the same event, for example, 320 (condition A & condition B) or condition C. 322 By default, the ECA model performs logic "AND" operation between 323 different conditions in the same Event. That is, event is triggered 324 when different conditions are met at the same time. For example, 326 Event A consists of two conditions: 327 o Condition A; 328 o Condition B; 329 If Condition A AND Condition B is met; 330 Event A is triggered; 331 Action A is executed. 333 For the logic "OR" operation between different conditions, the 334 conditions can be defined in different events. If the corresponding 335 event is triggered, the same action is executed. For example, 336 Event A is triggered on Condition A. 337 Event B is triggered on Condition B. 338 If Condition A is met; 339 Event A is triggered; 340 Action A is executed. 341 If Condition B is met; 342 Event B is triggered; 343 Action A is executed. 345 ECA Action is one of the following operations to be carried out by a 346 server: 348 o Configuration data object reconfiguration 350 o ECA Log report Notification 352 o Add or remove one or multiple YANG Push Subscriptions 354 o Invoke another Event in the same network device or different 355 network device 357 In case of one event triggering another event, a set of events can be 358 grouped together and executed, in a coordinated manner. The action 359 associated with the event can be executed in the same network device 360 or in different network devices. In the latter case, events executed 361 by different network devices need to coordinate as a group to fulfil 362 a task, previously set. 364 3.2. Where is ECA Script and State Held? 366 The ECA state information described in Section 2.5 and associated ECA 367 script has to be held somewhere. There are two locations where this 368 applies: 370 o in a central controller where decisions about resource adjustment 371 are made; 373 o in the network nodes where the resources exist. 375 The first of these locations have a good visibility of the whole 376 network or information of the flow packets are going to take through 377 the entire network, but requires a centralized, searchable repository 378 of all network information that can be used for diagnostics, service 379 assurance, maintenance or audit purposes. The response to network 380 event can be slow since all monitored data objects from large amount 381 of network devices need to be sent and correlated at the point where 382 decisions about resource adjustment are made, less alone multiple 383 network event triggering a single action. 385 Conversely, if the ECA state and associated ECA script is held in the 386 network nodes, it makes policing of resource adjustment easier. It 387 means many points in the network can have immediate response to 388 network event. The limitation is the configurations and state of a 389 particular device does not have the visibility of the whole network 390 or information of the flow packets are going to take through the 391 entire network, so they provide little insight into network level 392 policy-related behavior. 394 3.3. What State is Held? 396 As already described, the network control logic associated with ECA 397 script needs access to ECA state table. It stores network events 398 pushed from YANG push subscription or ECA policy model, threshold 399 value it set for observed network management data object. 401 In addition, when the event needs to be continuously monitored, the 402 Event scheduling information such as start time, end time can be 403 included. 405 In case of sending updates only when the value exceeds a certain 406 threshold for the first time but not again until the threshold is 407 cleared, a threshold clear flag is also needed. 409 In case of monitoring the data change or data change rate, for 410 example, YANG Push On-Change mode [RFC8641] or ECA Threshold Test 411 [I.D-wwx-netmod-event-yang], the ECA state table need to store 412 history state to check the condition to be satisfied and determine 413 the current state. 415 4. Architecture Overview 417 The architectural considerations and conclusions described in the 418 previous section lead to the architecture described in this section 419 and illustrated in Figure 1. The interfaces and interactions shown 420 in the figure and labeled (a) through (f) are described in 421 Section 4.1. 423 +----------------------------------------------------+ 424 |Management System +----------+ | 425 | +--------+ECA Script| | 426 |+----------+ +-------+--+ +----+-----+ | 427 ||ECA Design| | Notif <----------+-----------+ | 428 |+-+---+----+ |Monitoring<----+ | | | 429 | | | +^------^--+ | | | | 430 +--+---+--------+------+-------+-----+---------- +---+ 431 (a) | |(b) |(c) |(d) (e) | (f) |(e) 432 ECA | |YANG | | |Event| Config |Event 433 Model| |Push |Event |ECA |Notif| Model |Notif 434 | |Sub |Notif |Notif | | | 435 | |Filter | | | | | 436 ------+---+--------+------+-------+-----+---------- +------------- 437 | | | | | | | Network 438 +--+---+--------+------+-------+-----V-+ +-----+-----+ 439 |+-V---V----+ | | | | | 440 ||ECA Script+---+ | | | | 441 || |----------+ | | | 442 |+----+-----+ | | Network | 443 |+----V----+ | | Device B | 444 ||ECA State| | | | 445 |+---------+ Network Device A | | | 446 +--------------------------------------+ +-----------+ 448 Figure 1.Reference Architecture for Use of ECA and Network Self 449 Management 451 4.1. Telemetry Automation in the Network Device 453 As shown in Figure 1, some component in the management system defines 454 and designs ECA Policy rule. This may be invoked by a Service 455 assurance application or device fault self-management application. 456 We show this component on the figure as the "ECA Design", and it 457 extracts Event and Condition in the ECA model and fill into YANG Push 458 Subscription as filter. When YANG Push subscription filter is pushed 459 down to the network device, ECA script can be generated automatically 460 from it (ECA script can also be generated in the management system 461 and downloaded to the network device). The YANG Push subscription 462 request, indicated on Figure 1 by the arrow (b), includes all of the 463 parameters of network management data objects that the requester 464 wishes to be supplied, such as filter node, threshold value, start 465 time, and end time. Note that the requester in this case may be the 466 management system shown in the figure or a distinct system such as 467 data collector. 469 The network device registers network event that is corresponding to 470 the filter carried in the YANG Push Subscription and enters the 471 network event in its ECA state and then the server subscribes to its 472 own continuous datastore updates in the operational state datastore 473 that is encapsulated in the event notification as publication to the 474 YANG Push subscriber. 476 Upon the network event is detected, the server intercepts the 477 publication of subscribed data and loads the operational state data 478 object in the operational state datastore into the auto-configured 479 ECA's event and execute the ECA's associated condition. When ECA 480 Condition is evaluated to TRUE, the operational state data objects 481 will be filtered and the remaining data objects will be entered back 482 into the publication of subscribed data and encapsulated in the event 483 notification (c) and sent to notification monitoring component in the 484 management system. 486 The notification monitoring component may further derive some new ECA 487 policy rule and fed into ECA Design component. The remaining 488 procedure is same as the procedure starting from (b). 490 Alternatively, the ECA design component can push ECA model directly 491 with additional actions included (a) to the network device, ECA 492 script is generated automatically from ECA model. The ECA model 493 request, indicated on Figure 1 by the arrow (a), includes additional 494 action parameters besides one included in the YANG Push subscription 495 request. 497 The network device register network event that is corresponding to 498 the ECA carried in the ECA request and enter them in its ECA state 499 and then the server subscribes to its own continuous datastore 500 updates in the operational state datastore that is encapsulated in 501 the event notification as publication to the YANG Push subscriber. 503 Upon the network event is detected, the server loads the operational 504 state data object in the operational state datastore into the auto- 505 configured ECA's event and execute the ECA's associated condition. 506 Different from YANG Push subscription filter, the server will not 507 intercept the publication of subscribed data. Instead, it allows the 508 server to trigger a set of actions associated with the network event, 509 e.g., send ECA log report notification, add/remove YANG push 510 subscription, reconfigure the network management data object within 511 the control of the server. After all actions are executed, one or 512 multiple separate ECA notifications (d) can be sent to the 513 notification monitoring component in the management system, the 514 remaining procedure is same as YANG Push subscription case. 516 Conversely,when, network level policy-related behavior became 517 necessary, once a subscription has been set up, event notification 518 message associated with the subscription from different network 519 device will be sent to the notification monitoring component in the 520 management system(e), which in turn trigger network behavior change 521 on the network device via configuration model (f). 523 4.2. Detecting and Resolving Policy Conflict 525 There are two possible places where policy conflict can take places: 527 1. An event triggers multiple actions in the network device that 528 cannot occur together as specified by the system administrator. 530 2. Multiple ECA notifications or multiple combination of ECA 531 notification and Event notification lead to generate ECA policy 532 that cannot occur together. 534 In both case, policy conflict can be addressed by policy conflict 535 detection mechanism and Policy validation mechanism. 537 4.3. Chain Reaction of Coordinated Events 539 In some cases events executed by the same or different network 540 devices can be executed in a coordinated manner. To make sure these 541 network devices coordinate on some task or a group of events 542 coordinate in the same network device, these events on the same or 543 different network devices need to be pre-configured to work together. 544 During capability negotiation phase, the management system should 545 know what each network device supports, which event may take action, 546 and what condition on which event. So ECA model with multiple events 547 can be configured on the network device to allow one event be 548 triggered by another event configured on the same network device. 550 5. Security Considerations 552 The framework described in this document for supporting autonomic 553 event-driven self-management will require consideration of potential 554 security and operational requirements, and ensure best security 555 practices and methods are applied. 557 Key security considerations that will be discussed in future versions 558 of this document, include: 560 o Authentication of ECA programming requests; 562 o Application of suitable authorization methods when enabling ECA 563 functions; 565 o Securing ECA communication channels; 566 o Locking ECA device config and state databases; 568 o Mitigation, and negation, of ECA functional component attacks; 570 o Logging and auditing of ECA transactions; 572 o Maintaining ECA device confidentially. 574 6. Acknowledgements 576 This work has benefited from the discussions of ECA Policy over the 577 years. In particular, the SUPA project [ 578 https://datatracker.ietf.org/wg/supa/about/ ] provided approaches to 579 express high-level, possibly network-wide policies to a network 580 management function (within a controller, an orchestrator, or a 581 network element). 583 Igor Bryskin, Xufeng Liu, Alexander Clemm, Henk Birkholz, Tianran 584 Zhou contributed to an earlier version of [GNCA]. We would like to 585 thank the authors of that document on event response behaviors 586 delegation for material that assisted in thinking that helped develop 587 this document. 589 Finally, the authors would like to thank David Hutchison and Mehdi 590 Bezahaf at Lancaster University, Phil Eardley and Andy Reid at 591 British Telecom, for their input and applicability of ECA device self 592 management to the Next Generation Converged Digital Infrastructure 593 (NG-CDI) project. 595 7. References 597 7.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, 602 . 604 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 605 RFC 7950, DOI 10.17487/RFC7950, August 2016, 606 . 608 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 609 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 610 May 2017, . 612 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 613 Access Control Model", STD 91, RFC 8341, 614 DOI 10.17487/RFC8341, March 2018, 615 . 617 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 618 and R. Wilton, "Network Management Datastore Architecture 619 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 620 . 622 7.2. Informative References 624 [I-D.bryskin-netconf-automation-yang] 625 Bryskin, I., Liu, X., Clemm, A., Birkholz, H., and T. 626 Zhou, "Generalized Network Control Automation YANG Model", 627 draft-bryskin-netconf-automation-yang-03 (work in 628 progress), July 2019. 630 [I-D.clemm-netmod-push-smart-filters] 631 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 632 Zheng, G., and H. Birkholz, "Smart Filters for Push 633 Updates", draft-clemm-netmod-push-smart-filters-01 (work 634 in progress), October 2018. 636 [I-D.clemm-nmrg-dist-intent] 637 Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, 638 "Intent-Based Networking - Concepts and Overview", draft- 639 clemm-nmrg-dist-intent-02 (work in progress), July 2019. 641 [I-D.wwx-netmod-event-yang] 642 Wang, Z., WU, Q., Xie, C., Bryskin, I., Liu, X., Clemm, 643 A., Birkholz, H., and T. Zhou, "A YANG Data model for ECA 644 Policy Management", draft-wwx-netmod-event-yang-04 (work 645 in progress), November 2019. 647 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 648 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 649 Management Framework for the Simplified Use of Policy 650 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 651 March 2018, . 653 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 654 Touch Provisioning (SZTP)", RFC 8572, 655 DOI 10.17487/RFC8572, April 2019, 656 . 658 Authors' Addresses 660 Mohamed Boucadair 661 Orange 662 Rennes 35000 663 France 665 Email: mohamed.boucadair@orange.com 667 Qin Wu 668 Huawei 669 101 Software Avenue, Yuhua District 670 Nanjing, Jiangsu 210012 671 China 673 Email: bill.wu@huawei.com 675 Michael Wang 676 Huawei 677 101 Software Avenue, Yuhua District 678 Nanjing, Jiangsu 210012 679 China 681 Email: wangzitao@huawei.com 683 Daniel King 684 Lancaster University 685 Bailrigg, Lancaster LA1 4YW 686 UK 688 Email: d.king@lancaster.ac.uk 690 Chongfeng Xie 691 China Telecom 692 Beijing 693 China 695 Email: xiechf.bri@chinatelecom.cn