idnits 2.17.00 (12 Aug 2021) /tmp/idnits62727/draft-bryskin-netconf-automation-yang-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 837 has weird spacing: '...pt-name str...' -- The document date (February 21, 2018) is 1550 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7950' is defined on line 1606, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-subscribed-notifications' is defined on line 1610, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 1616, but no explicit reference was found in the text == Outdated reference: draft-ietf-teas-yang-te-topo has been published as RFC 8795 == Outdated reference: draft-ietf-netconf-subscribed-notifications has been published as RFC 8639 == Outdated reference: draft-ietf-netconf-yang-push has been published as RFC 8641 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: August 25, 2018 Jabil 6 A. Clemm 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 T. Zhou 11 Huawei 12 February 21, 2018 14 Generalized Network Control Automation YANG Model 15 draft-bryskin-netconf-automation-yang-00 17 Abstract 19 This document describes a YANG data model for the Generalized Network 20 Control Automation (GNCA), aimed to define an abstract and uniform 21 semantics for NETCONF/YANG scripts in the form of Event-Condition- 22 Action (ECA) containers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 25, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. GNCA concepts and constructs . . . . . . . . . . . . . . . . 4 61 3.1. Policy Variable (PV) . . . . . . . . . . . . . . . . . . 4 62 3.2. ECA Event . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. ECA Condition . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. ECA Action . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. ECA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Where ECA scripts are executed? . . . . . . . . . . . . . . . 11 67 5. ECA script example . . . . . . . . . . . . . . . . . . . . . 12 68 6. Complete Model Tree Structure . . . . . . . . . . . . . . . . 14 69 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 75 11.2. Informative References . . . . . . . . . . . . . . . . . 35 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 78 1. Introduction 80 NETCONF/YANG has proved to be very successful in facilitating 81 interactive network control paradigm, in which a network control 82 application (controller) requests the network server to perform 83 certain (re-)configurations, then, retrieves network states of 84 interest, then asks for more (re-)configurations and so forth. This 85 said, there are multiple use cases that require stringing network 86 configuration requests together with conditioning their order of 87 execution based on certain events detected in the network, as well as 88 current, historical or predicted network states, and pushing such 89 request batches/scripts to the network server in order to control the 90 network close loop automation processes. The Generalized Network 91 Control Automation (GNCA) YANG model introduced by this document 92 defines an abstract and uniform semantics of such NETCONF/YANG 93 scripts in the form of Event-Condition-Action (ECA) containers. 95 2. Purpose 97 The purpose of the Generalized Network Control Automation (GNCA) YANG 98 model is to enable an environment allowing for manipulation of close 99 loop network automation via configuration of abstract Event- 100 Condition-Action (ECA) scripts. The model defines the semantics of 101 said scripts; however, how the scripts are actually implemented by 102 the server is not governed by the model. The server may, for 103 example, based on pushed ECA configuration, generate and execute 104 server specific scripts. How this is done is outside of the scope of 105 this document. 107 Although not all event response behaviors could be delegated to the 108 network server, there are many circumstances where it is highly 109 desirable. For example: 111 a. Reaction to many network events is well understood and does not 112 require additional information (such as broader or higher level 113 network view or analytics input); 115 b. It is often imperative for the network to start acting as quickly 116 as the event is detected. In other words, there might simply be 117 no time for the network-controller communication; 119 c. A paradigm in which a controller micro-manages every network 120 behavior does not scale. Simply put, there are always things 121 that the network has to do autonomously (i.e. when the controller 122 is not looking), which does not mean that the controller should 123 have no say as to how said things need to be done; 125 d. Numerous important use cases and applications can benefit from 126 ability to define in an abstract and uniformly way a programmable 127 logic in one place (e.g. on the controller) and execute it 128 someplace else (e.g. on the server). 130 The main objective of the GNCA is to generalize the ECA network 131 control style, so that it could be applied to arbitrary network 132 events/conditions and manipulate network auto-control of large 133 variety of network resources. Such a generalization would allow, for 134 example, conveying to the network a coherent/ordered/prioritized 135 behavior for recovering from a network failure or failures affecting 136 simultaneously multiple services, instruct the network how to fight 137 rapidly developing congestions, what to do when power outage is 138 detected and so forth. In fact, it could be argued that without some 139 sort of close loop network control automation hierarchical network 140 control realistically could not be achieved. 142 The GNCA YANG model could be also thought of as an attempt to 143 generalize the smart filter subscription machinery by stating that 144 sending a notification is one of possibly multiple actions that 145 network could perform reacting to the specified smart trigger. 146 According to "Smart filters for Push Updates - Problem Statement" 147 [I-D.clemm-netconf-push-smart-filters-ps]: 149 "They [smart filters] are also useful for network automation, in 150 which automated actions are automatically triggered based on when 151 certain events in the network occur while certain conditions hold. A 152 YANG-Push subscription with a smart filter can in effect act as a 153 source for such events. Combined with an optional check for a 154 condition when an event is observed, this can serve as the basis of 155 action." 157 In a nutshell GNCA facilitates an environment in which the network 158 automation logic could be defined in a form of ECA scripts by a 159 client, pushed to the network before the events of interest happen, 160 and executed by the network after the events are detected. 162 Finally, according to the smart filters problem statement, the 163 following smart filters will be considered: 165 "o Filters that involve freely programmable logic" 167 ECA scripts could serve as a vehicle to associate with a smart filter 168 a complex freely programmable logic to detect the event of interest 169 in the first place. 171 3. GNCA concepts and constructs 173 3.1. Policy Variable (PV) 175 Policy Variable (PV) is a structure to keep interim results/meta data 176 during the execution of an ECA script. For example, a PV could be 177 used as an output parameter of an RPC invoked by ECA1 to be used in a 178 condition expression for ECA2. 180 With respect to ECAs the scope of a PV is either global or (ECA) 181 local. Global PVs are permanent. They are kept in the top level PV 182 container and are shared between all ECAs of the script. Local PVs 183 are kept within the internal PV container of an ECA. Local PVs could 184 be either dynamic - appear/disappear with start/stop of the ECA 185 execution, or static - exist as long as the ECA is configured. 187 Each PV has the following attributes: 189 o Globally or ECA scope unique name; 190 o type - either pre-defined (e.g. Boolea, integer, uint64,etc.) or 191 specified via XPath pointing to a data store node or a sub-tree of 192 the required structure. For example, PV named "Link" could be 193 associated with the "/TE_Topologies/TE_Links/TE_Link" XPath in 194 accordance with the TE Topology model [I-D.ietf-teas-yang-te-topo] 195 and hence be capable of accommodating the entire TE Link 196 container; 198 o value - data stored in the PV structured according to the PV type. 200 The following operations are allowed with/on a PV: 202 o initialize (with a constant/enum/identity); 204 o assign (with contents of another same type PV); 206 o read (retrieve data store contents pointed by the specified same 207 type XPath/sub-tree); 209 o write (modify same type CONFIG=TRUE data store state with the PV's 210 content/value); 212 o insert (PV's content into a same type list); 214 o iterate (copy into PV one by one same type list elements) (See 215 examples of definition of and operations with PVs in Section 5). 217 o function calls in a form of F(dst, src), where F is an identity of 218 a function from extendable function library, dst and src are 219 destination and source PVs respectively, the function's input 220 parameters, with the result returned in dst. 222 Arbitrary expressions with PVs are for future study. 224 PVs could be used as input/output of an ECA invoked RPC. PVs could 225 also be a source of information sent to the client in notification 226 messages. 228 PVs could be used in condition expressions (see Section 5). 230 The model structure for the Policy Variable is shown below: 232 +--rw policy-variables 233 | +--rw policy-variable* [name] 234 | +--rw name string 235 | +--rw (type-choice)? 236 | | +--:(common) 237 | | | +--rw type? identityref 238 | | +--:(xpath) 239 | | +--rw xpath? string 240 | +--rw value? 242 3.2. ECA Event 244 ECA Event is any subscribable event notification either explicitly 245 defined in a YANG module supported by the server or a smart filter 246 conveyed to the server via smart filter subscription. Additionally, 247 an event could be associated with a one-time or periodic timer. 249 Event notification contents become in the ECA context implicit local 250 dynamic PVs with automatically generated names. Let's assume 251 Network_Failure_Is_Detected event is defined that carries to a 252 subscriber the detected failure type (failureType), ID (failureID) 253 and the affected by the failure TE link state (teLInk). In the 254 context of the associated with the Networ_Failure_Is_Detected event 255 ECA failureType, failureID and teLink are implicit local dynamic PVs 256 that could be used in the embodied Condition and Action containers 257 along with explicitly defined global and ECA local (static and/or 258 dynamic) PVs. 260 One way to think of NETWONF/YANG Event Notification is as Remote 261 Procedure Call-back, i.e. server->client directed RPC When a 262 subscribable NETWONF/YANG Event and associated with it ECA is pushed 263 to the server within an ECA script, the server is expected to 264 interpret this as follows: take the contents of the event 265 notification and execute the logic defined by the associated 266 Condition-Action chain (as I (client) would do on receipt of the 267 notification) in order to decide how to react to the event. Recall 268 that the whole purpose of ECA scripts is to reduce as much as 269 possible the client-server communication. 271 All events (specified in at least one ECA pushed to the server) are 272 required to be constantly monitored by the server. One way to think 273 of this is that the server subscribes to its own publications with 274 respect to all events that are associated with at least one ECA. 276 3.3. ECA Condition 278 ECA Condition is evaluated to TRUE or FALSE logical expression 279 specified in a form of: 281 283 where arg1 and arg2 represent either constant/enum/identity, PV or 284 pointed by XPath data store node or sub-tree, 286 relation is one of the comparison operations from the set: ==, !=, 287 >, <, >=, <= 289 Primitive conditions could be combined hierarchically into macro- 290 conditions via && and || logical operations. 292 (Macro-)conditions are associated with events and evaluated only 293 within event threads triggered by the event detection. 295 When a (macro-)condition is evaluated to TRUE, the associated with it 296 action is executed. 298 The model structure for the ECA Condition is shown below: 300 +--rw conditions 301 | +--rw condition* [name] 302 | +--rw name string 303 | +--rw logical-operation-type? identityref 304 | +--rw comparison-operation* [name] 305 | | +--rw name string 306 | | +--rw comparision-type? identityref 307 | | +--rw arg1 308 | | | +--rw policy-argument 309 | | +--rw arg2 310 | | +--rw policy-argument 311 | +--rw sub-condition* [name] 312 | +--rw name -> /gnca/conditions/condition/name 314 The policy arguments arg1 and arg2 have the following structure: 316 +--rw policy-argument 317 +--rw type? identityref 318 +--rw (argument-choice)? 319 +--:(policy-constant) 320 | +--rw constant? string 321 +--:(policy-variable) 322 | +--rw policy-variable? leafref 323 +--:(local-policy-variable) 324 | +--rw local-policy-variable? leafref 325 +--:(xpath) 326 +--rw xpath? string 328 3.4. ECA Action 330 ECA Action is one of the following operations to be carried out by a 331 server: 333 o (-re)configuration - modifying a CONFIG=TRUE data store state 335 o (re-)configuration scheduling - scheduling one time or periodic 336 (re-)configuration in the future 338 o sending one time notification; 340 o adding/removing event notify subscription (essentially, the same 341 action as performed when a client explicitly adds/removes a 342 subscription) 344 o executing an RPC defined by a YANG module supported by the server 345 (the same action as performed when a client interactively calls 346 the RPC); 348 o performing operations and function calls on PVs (such as assign, 349 read, insert, iterate, etc); 351 o starting/stopping timers; 353 o stopping current ECA; 355 o invoking another ECA; 357 o NO-ACTION action - meaningful only within ECA's Cleanup Condition- 358 Action list to indicate that the ECA's Normal Condition-Action 359 thread must be terminated as soon as one of the required Actions 360 is rejected by the server (see more Section 3.4). 362 Two points are worth noting: 364 1. When a NETWONF/YANG RPC appears in an ECA Action body, the server 365 is expected to interpret this as follows: execute the same logic, 366 as when the client explicitly calls said RPC via NETCONF. For 367 example, when TE_Tunnel_Path_Computation RPC is found in the 368 currently executed Action, the server is expected to call its TE 369 path computation engine and pass to it the specified parameters 370 in the Action input. 372 2. When a "Send notification" action is configured as an ECA Action, 373 the notification message to be sent to the client may contain not 374 only elements of the data store (as, for example, YANG PUSH or 375 smart filter notifications do), but also the contents of global 376 and local PVs, which store results of arbitrary operations 377 performed on the data store contents (possibly over arbitrary 378 period of time) to determine, for example, history/evolution of 379 data store changes, median values, ranges and rates of the 380 changes, results of configured function calls and expressions, 381 etc. - in short, any data the client may find interesting about 382 the associated event with all the logic to compute said data 383 delegated to the server. 385 Multiple (macro-)condition/action pairs could be combined into a 386 macro-action (transaction). 388 Multiple (trans)actions could be triggered by a single event. 390 A (macro-)condition or a (trans)action could be defined once, 391 assigned with a name and specified in multiple ECAs. 393 The model structure for the ECA Action is shown below: 395 +--rw actions 396 | +--rw action* [name] 397 | +--rw name string 398 | +--rw action-element* [name] 399 | | +--rw name string 400 | | +--rw action-type? identityref 401 | | +--rw (action-operation)? 402 | | +--:(action) 403 | | | +--rw action-name? 404 | | | -> /gnca/actions/action/name 405 | | +--:(content-moving) 406 | | | +--rw content-moving 407 | | | +--rw content-moving-type? identityref 408 | | | +--rw src 409 | | | | +--rw policy-argument 410 | | | +--rw dst 411 | | | +--rw policy-argument 412 | | +--:(function-call) 413 | | | +--rw function-call 414 | | | +--rw function-type? identityref 415 | | | +--rw src 416 | | | | +--rw policy-argument 417 | | | +--rw dst 418 | | | +--rw policy-argument 419 | | +--:(rpc-operation) 420 | | | +--rw rpc-operation 421 | | | +--rw name? string 422 | | | +--rw nc-action-xpath? string 423 | | | +--rw policy-variable* [name] 424 | | | +--rw name string 425 | | | +--rw policy-argument 426 | | +--:(notify-operation) 427 | | +--rw notify-operation 428 | | +--rw name? string 429 | | +--rw policy-variable* [name] 430 | | +--rw name string 431 | | +--rw policy-argument 432 | +--rw time-schedule 433 | +--rw start? yang:date-and-time 434 | +--rw repeat-interval? string 436 3.5. ECA 438 An ECA container includes: 440 o Event name 441 o List of local PVs. As mentioned, local PVs could be configured as 442 dynamic (their instances appear/disappear with start/stop of the 443 ECA execution) or static (their instances exisr as long as the ECA 444 is configured). The ECA input (the contents of the associated 445 notification message, such as YANG PUSH or smart filter 446 notification message) are the ECA's implict local dynamic PVs with 447 automatically generated names 449 o Normal CONDITION-ACTION list: configured conditions each with 450 associated actions to be executed if the condition is evaluated to 451 TRUE 453 o Cleanup CONDITION-ACTION list: configured conditions/actions to be 454 evaluated/executed in case any Action from the Normal CONDITION- 455 ACTION list was attempted and rejected by the server. In other 456 words, this list specifies the ECA cleanup/unroll logic after 457 rejection of an Action from the Normal CONDITION-ACTION list. An 458 empty Cleanup CONDITION-ACTION list signifies that the ECA's 459 normal Actions should be executed regardless of whether the 460 previously attempted ECA Actions were rejected or not by the 461 server. Cleanup CONDITION-ACTION list containing a single NO- 462 ACTION Action signifies that the ECA thread is to be immediately 463 terminated on rejection of any attempted Action (without executing 464 any cleanup logic) 466 4. Where ECA scripts are executed? 468 It could be said that the main idea of the GNCA is decoupling the 469 place where the network control logic is defined from the place where 470 it is executed. In previous sections of this document it is assumed 471 that the network control logic is defined by a client and pushed to 472 and executed by the network (server). This is accomplished via ECA 473 scripts, which are essentially bunches of regular NETCONF style 474 operations (such as get, set, call rpc) and event notifications glued 475 together via Policy Variables, PVs. It is worth noting that said ECA 476 scripts could be easily moved around and executed by any entity 477 supporting the GNCA YANG model (i.e. capable of interpreting the ECA 478 scripts). One interesting implication of this is that the ECA 479 scripts could be executed by neither client nor server, but a 3d 480 party entity, for instance, with a special focus on the control of a 481 particular network domain or/and special availability of/proximity to 482 information/ resources that could contribute to the network control 483 decision process. For example, the ECA scripts could be pushed to a 484 Path Computation Element (PCE) adopted to support the GNCA YANG 485 model. Specialized ECA scripts could be fanned out to multiple 486 specialized controllers to take care of different aspects of a 487 network domain control. 489 Another interesting idea is to combine the GNCA with hierarchical 490 T-SDN architecture. In particular, the ECA scripts conveyed by a 491 client to a network orchestrator could be pushed (modified or 492 unmodified) hierarchically down to lower level controllers. After 493 all, the goal of the hierarchical T-SDN is to create a paradigm in 494 which the higher level of a controller in the hierarchy, the broader 495 (topologically and/or functionally) its control on the network and 496 the lesser its involvement in the network's micro-management in real 497 time. On the other hand, it is desirable for a higher level 498 controller to have a say as to how the subordinate controllers and, 499 by extension, the network under control should deal with events and 500 situations that are handled autonomously (i.e. without bothering the 501 higher level controller in real time). The ECA scripts pushed down 502 the T-SDN hierarchy may help to achieve this objective. 504 5. ECA script example 506 Consider a situation on a TE network when a network failure 507 simultaneously affecting multiple TE tunnels. Normally, the TE 508 network relies in this case on TE tunnels pre-configured protection/ 509 restoration capabilities and lets the TE tunnels to auto-recover 510 themselves independently from each other. However, this default 511 behavior may not be desired in some configurations/use cases because: 513 a. Recovery procedures of a "greedy" TE tunnel may block the 514 recovery of other TE tunnels; 516 b. Shared mesh protection/restoration schemes are in place 518 In such cases the network has to perform the recovery of failure 519 affected TE tunnels as a coordinated process. Furthermore, it is 520 quite common that network resources available for the dynamic 521 recovery procedures are limited, in which case it is desirable to 522 convey to the network the policy/order in which the TE tunnels should 523 be recovered. Different policies may be considered, to name a few: 525 1. Recover as many TE tunnels as possible; 527 2. Recover TE tunnels in accordance with their importance/priority; 529 3. Recover all unprotected TE tunnels before recovering broken 530 connections/LSPs of protected TE tunnels (because the latter can 531 tolerate the failure hopefully until it is repaired). 533 Let's describe an ECA script that could be pushed by the controller 534 application instructing the network to perform multiple TE tunnel 535 failure recovery according to policy (3) above. 537 Assumptions: it is assumed that in one or several YANG modules 538 supported by the server the following is defined: 540 o Subscribable "Network_Failure_Is_Detected" event carrying in the 541 notification message the detected failure type (failureType), ID 542 (failureID) and the affected by the failure TE link ID (linkID); 544 o RPC "PathDependsOnLink" taking as an input a TE_Path and 545 TE_Link_ID and returning in its output Boolean indicating whether 546 or not the specified path goes through the link with the specified 547 ID; 549 o RPC "ReplaceTunnelsAwayFromLink" taking as an input a list of TE 550 tunnel key leafrefs and ID of to be avoided link, performing the 551 tunnel replacement away from the link and returning no output. 553 Explicit (global) PVs: 555 o name: Yes type: Boolean 557 o name: lsp xpath: /TE_Tunnels/lsps/lsp 559 o name tunnel xpath: /TE_Tunnels/tunnels/te_tunnel 561 o name: unprotected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 562 dependent_tunnels 564 o name protected_tunnels xpath: /TE_Tunnels/tunnels/te_tunnel/ 565 dependent_tunnels 567 Actions: 569 name: PopulateTunnelLists 571 body: 573 lsp iterate xpath:/TE_Tunnels/lsps 574 { 575 rpc: PathDependsOnLink(/rro, Yes); 576 if(Yes == TRUE ) 577 { 578 tunnel = /parrent_tunnel; 579 if(/protectionType == UNPROTECTED) 580 /tunnelName insert unprotected_tunnels 581 if(/protectionType != UNPROTECTED) 582 /tunnelName insert protected_tunnels 583 } 584 } 586 name: RepairTunnels 588 Body: 590 rpc: ReplaceTunnelsAwayFromLink(unprotected_tunnels, linkID); 591 rpc: ReplaceTunnelsAwayFromLink(protected_tunnels, linkID); 593 ECA: 595 eventName: Network_Failure_Is_Detected; 597 eventParams: failureType, failureID, linkID 599 Condition: TRUE (always, every time) 601 Actions: 603 unprotected_tunnels = 0; protected_tunnels =0; 605 namedAction:PopulateTunnelLists; 607 namedAction:RepairTunnels 609 Note: RPC "PathDependsOnLink" is used in the example for simplicity. 610 The RPC could be easily replaced by a scripted named action similar 611 to PopulateTunnelListes . 613 6. Complete Model Tree Structure 615 The complete tree structure of the YANG model defined in this 616 document is as follows: 618 module: ietf-gnca 619 +--rw gnca 620 +--rw policy-variables 621 | +--rw policy-variable* [name] 622 | +--rw name string 623 | +--rw (type-choice)? 624 | | +--:(common) 625 | | | +--rw type? identityref 626 | | +--:(xpath) 627 | | +--rw xpath? string 628 | +--rw value? 629 +--rw conditions 630 | +--rw condition* [name] 631 | +--rw name string 632 | +--rw logical-operation-type? identityref 633 | +--rw comparison-operation* [name] 634 | | +--rw name string 635 | | +--rw comparision-type? identityref 636 | | +--rw arg1 637 | | | +--rw policy-argument 638 | | | +--rw type? identityref 639 | | | +--rw (argument-choice)? 640 | | | +--:(policy-constant) 641 | | | | +--rw constant? string 642 | | | +--:(policy-variable) 643 | | | | +--rw policy-variable? leafref 644 | | | +--:(local-policy-variable) 645 | | | | +--rw local-policy-variable? leafref 646 | | | +--:(xpath) 647 | | | +--rw xpath? string 648 | | +--rw arg2 649 | | +--rw policy-argument 650 | | +--rw type? identityref 651 | | +--rw (argument-choice)? 652 | | +--:(policy-constant) 653 | | | +--rw constant? string 654 | | +--:(policy-variable) 655 | | | +--rw policy-variable? leafref 656 | | +--:(local-policy-variable) 657 | | | +--rw local-policy-variable? leafref 658 | | +--:(xpath) 659 | | +--rw xpath? string 660 | +--rw sub-condition* [name] 661 | +--rw name -> /gnca/conditions/condition/name 662 +--rw actions 663 | +--rw action* [name] 664 | +--rw name string 665 | +--rw action-element* [name] 666 | | +--rw name string 667 | | +--rw action-type? identityref 668 | | +--rw (action-operation)? 669 | | +--:(action) 670 | | | +--rw action-name? 671 | | | -> /gnca/actions/action/name 672 | | +--:(content-moving) 673 | | | +--rw content-moving 674 | | | +--rw content-moving-type? identityref 675 | | | +--rw src 676 | | | | +--rw policy-argument 677 | | | | +--rw type? 678 | | | | | identityref 679 | | | | +--rw (argument-choice)? 680 | | | | +--:(policy-constant) 681 | | | | | +--rw constant? 682 | | | | | string 683 | | | | +--:(policy-variable) 684 | | | | | +--rw policy-variable? 685 leafref 686 | | | | +--:(local-policy-variable) 687 | | | | | +--rw local-policy-variable? 688 leafref 689 | | | | +--:(xpath) 690 | | | | +--rw xpath? 691 | | | | string 692 | | | +--rw dst 693 | | | +--rw policy-argument 694 | | | +--rw type? 695 | | | | identityref 696 | | | +--rw (argument-choice)? 697 | | | +--:(policy-constant) 698 | | | | +--rw constant? 699 | | | | string 700 | | | +--:(policy-variable) 701 | | | | +--rw policy-variable? 702 leafref 703 | | | +--:(local-policy-variable) 704 | | | | +--rw local-policy-variable? 705 leafref 706 | | | +--:(xpath) 707 | | | +--rw xpath? 708 | | | string 709 | | +--:(function-call) 710 | | | +--rw function-call 711 | | | +--rw function-type? identityref 712 | | | +--rw src 713 | | | | +--rw policy-argument 714 | | | | +--rw type? 715 | | | | | identityref 716 | | | | +--rw (argument-choice)? 717 | | | | +--:(policy-constant) 718 | | | | | +--rw constant? 719 | | | | | string 720 | | | | +--:(policy-variable) 721 | | | | | +--rw policy-variable? 722 leafref 723 | | | | +--:(local-policy-variable) 724 | | | | | +--rw local-policy-variable? 725 leafref 726 | | | | +--:(xpath) 727 | | | | +--rw xpath? 728 | | | | string 729 | | | +--rw dst 730 | | | +--rw policy-argument 731 | | | +--rw type? 732 | | | | identityref 733 | | | +--rw (argument-choice)? 734 | | | +--:(policy-constant) 735 | | | | +--rw constant? 736 | | | | string 737 | | | +--:(policy-variable) 738 | | | | +--rw policy-variable? 739 leafref 740 | | | +--:(local-policy-variable) 741 | | | | +--rw local-policy-variable? 742 leafref 743 | | | +--:(xpath) 744 | | | +--rw xpath? 745 | | | string 746 | | +--:(rpc-operation) 747 | | | +--rw rpc-operation 748 | | | +--rw name? string 749 | | | +--rw nc-action-xpath? string 750 | | | +--rw policy-variable* [name] 751 | | | +--rw name string 752 | | | +--rw policy-argument 753 | | | +--rw type? 754 | | | | identityref 755 | | | +--rw (argument-choice)? 756 | | | +--:(policy-constant) 757 | | | | +--rw constant? 758 | | | | string 759 | | | +--:(policy-variable) 760 | | | | +--rw policy-variable? 761 leafref 762 | | | +--:(local-policy-variable) 763 | | | | +--rw local-policy-variable? 764 leafref 765 | | | +--:(xpath) 766 | | | +--rw xpath? 767 | | | string 768 | | +--:(notify-operation) 769 | | +--rw notify-operation 770 | | +--rw name? string 771 | | +--rw policy-variable* [name] 772 | | +--rw name string 773 | | +--rw policy-argument 774 | | +--rw type? 775 | | | identityref 776 | | +--rw (argument-choice)? 777 | | +--:(policy-constant) 778 | | | +--rw constant? 779 | | | string 780 | | +--:(policy-variable) 781 | | | +--rw policy-variable? 782 leafref 783 | | +--:(local-policy-variable) 784 | | | +--rw local-policy-variable? 785 leafref 786 | | +--:(xpath) 787 | | +--rw xpath? 788 | | string 789 | +--rw time-schedule 790 | +--rw start? yang:date-and-time 791 | +--rw repeat-interval? string 792 +--rw ecas 793 | +--rw eca* [name] 794 | +--rw name string 795 | +--rw event-name string 796 | +--rw policy-variable* [name] 797 | | +--rw name string 798 | | +--rw (type-choice)? 799 | | | +--:(common) 800 | | | | +--rw type? identityref 801 | | | +--:(xpath) 802 | | | +--rw xpath? string 803 | | +--rw value? 804 | | +--rw is-static? boolean 805 | +--rw condition-action* [name] 806 | | +--rw name string 807 | | +--rw condition? -> /gnca/conditions/condition/name 808 | | +--rw action? -> /gnca/actions/action/name 809 | +--rw cleanup-condition-action* [name] 810 | | +--rw name string 811 | | +--rw condition? -> /gnca/conditions/condition/name 812 | | +--rw action? -> /gnca/actions/action/name 813 | +---x start 814 | +---x stop 815 | +---x pause 816 | +---x resume 817 | +---x next-action 818 | +--ro execution* [id] 819 | +--ro id uint32 820 | +--ro oper-status? enumeration 821 | +--ro start-time? 822 | | yang:date-and-time 823 | +--ro stop-time? 824 | | yang:date-and-time 825 | +--ro next-scheduled-time? 826 | | yang:date-and-time 827 | +--ro last-condition-action? 828 | | -> ../../condition-action/name 829 | +--ro last-condition? 830 | | -> ../../condition-action/condition 831 | +--ro last-action? 832 | | -> ../../condition-action/action 833 | +--ro last-cleanup-condition-action? 834 | -> ../../cleanup-condition-action/name 835 +--rw eca-scripts 836 | +--rw eca-script* [script-name] 837 | +--rw script-name string 838 | +--rw eca* [eca-name] 839 | +--rw eca-name -> /gnca/ecas/eca/name 840 +--rw running-script? 841 -> /gnca/eca-scripts/eca-script/script-name 843 7. YANG Module 845 file "ietf-gnca@2018-02-20.yang" 846 module ietf-gnca { 847 yang-version 1.1; 848 namespace "urn:ietf:params:xml:ns:yang:ietf-gnca"; 850 prefix "gnca"; 852 import ietf-yang-types { 853 prefix "yang"; 854 } 855 organization 856 "IETF Network Configuration (NETCONF) Working Group"; 858 contact 859 "WG Web: 860 WG List: 862 Editor: Igor Bryskin 863 865 Editor: Xufeng Liu 866 868 Editor: Alexander Clemm 869 "; 871 description 872 "Event Condition Action (ECA) model."; 874 revision 2018-02-20 { 875 description "Initial revision"; 876 reference "RFC XXXX"; 877 } 879 /* 880 * Typedefs 881 */ 882 identity argument-type { 883 description 884 "Possible values are: 885 constant, variable, or datastore state."; 886 } 888 identity comparison-type { 889 description 890 "Possible values are: 891 equal, not-equal, greater, greater-equal, less, less-equal."; 892 } 894 identity logical-operation-type { 895 description 896 "Possible values are: 897 not, or, and."; 898 } 900 identity function-type { 901 description 902 "Possible values are: 904 plus, minus, mult, divide, remain."; 905 } 907 identity content-moving-operation-type { 908 description 909 "Possible values are: 910 copy, iterate, insert."; 911 } 913 identity action-type { 914 description 915 "Possible values are: 916 action, content-move, function-call, rpc, notify."; 917 } 919 identity policy-variable-type { 920 description 921 "Possible values are: 922 boolean, int32, int64, uint32, uint64, string, etc."; 923 } 925 /* 926 * Groupings 927 */ 928 grouping policy-variable-attributes { 929 description 930 "Defining the policy variable attributes, including name, type 931 and value. These attributes are used as part of the Policy 932 Variable (PV) definition."; 933 leaf name { 934 type string; 935 description 936 "A string to uniquely identify a Policy Variable (PV), either 937 globally for a global PV, or within the soope of ECA for a 938 local PV."; 939 } 940 choice type-choice { 941 description 942 "The type of a policy variable may be either a common 943 primative type like boolean or a type from existing 944 schema node referenced by an XPath string."; 945 case common { 946 leaf type { 947 type identityref { 948 base policy-variable-type; 949 } 950 description 951 "A common policy variable type, defined as an 952 identity."; 953 } 954 } 955 case xpath { 956 leaf xpath { 957 type string; 958 description 959 "A XPath string, referencing a schema node, whose 960 type is used as the type of the policy variable"; 961 } 962 } 963 } 964 anydata value { 965 description 966 "The value of the policy variable, in a format that is 967 determined by the policy type."; 968 } 969 } // policy-variable-attributes 971 grouping policy-argument { 972 description 973 "Defining a policy argument, which can be used in a comparison 974 or an action."; 975 container policy-argument { 976 description 977 "Containing the attributes of a policy argument."; 978 leaf type { 979 type identityref { 980 base argument-type; 981 } 982 description 983 "Identifies the argument type."; 984 } 985 choice argument-choice { 986 description 987 "Argument formation options, depending on the policy 988 type."; 989 case policy-constant { 990 leaf constant { 991 type string; 992 description 993 "The constant value of the policy argument."; 994 } 995 } 996 case policy-variable { 997 leaf policy-variable { 998 type leafref { 999 path "/gnca/policy-variables/" 1000 + "policy-variable/name"; 1001 } 1002 description 1003 "A reference to a global policy variable, which 1004 is shared by all ECA scripts."; 1005 } 1006 } 1007 case local-policy-variable { 1008 leaf local-policy-variable { 1009 type leafref { 1010 path "/gnca/ecas/eca/policy-variable/name"; 1011 } 1012 description 1013 "A reference to a local policy variable, which 1014 is kept within an ECA instance, and appears/ 1015 disappears with start/stop of the ECA execution."; 1016 } 1017 } 1018 case xpath { 1019 leaf xpath { 1020 type string; 1021 description 1022 "An XPath string, referencing the data in the 1023 datastore."; 1024 } 1025 } 1026 } 1027 } 1028 } // policy-argument 1030 grouping action-element-attributes { 1031 description 1032 "Grouping of action element attributes."; 1033 leaf action-type { 1034 type identityref { 1035 base action-type; 1036 } 1037 description 1038 "Identifies the action type."; 1039 } 1040 choice action-operation { 1041 description 1042 "The operation choices that an ECA Action can take."; 1043 case action { 1044 leaf action-name { 1045 type leafref { 1046 path "/gnca/actions/action/name"; 1047 } 1048 description 1049 "The operation is to execute a configured ECA Action."; 1050 } 1051 } // action 1052 case content-moving { 1053 container content-moving { 1054 description 1055 "The operation is to move contents between two policy 1056 arguments."; 1057 leaf content-moving-type { 1058 type identityref { 1059 base content-moving-operation-type; 1060 } 1061 description 1062 "The type of moving operation, which can be copy, 1063 iterate (copy a list of elements one by one), or 1064 insert."; 1065 } 1066 container src { 1067 description 1068 "The source policy argment."; 1069 uses policy-argument; 1070 } 1071 container dst { 1072 description 1073 "The destination policy argument."; 1074 uses policy-argument; 1075 } 1076 } 1077 } // content-moving 1078 case function-call { 1079 container function-call { 1080 description 1081 "The operation is to call a function, which is of one of 1082 a few basic predefined types, such as plus, minus, 1083 multiply, devide, or remainder."; 1084 leaf function-type { 1085 type identityref { 1086 base function-type; 1087 } 1088 description 1089 "One of the predefined basic function types, such as 1090 plus, minus, multiply, devide, or remainder."; 1091 } 1092 container src { 1093 description 1094 "The source policy argument."; 1095 uses policy-argument; 1097 } 1098 container dst { 1099 description 1100 "The distination policy argument."; 1101 uses policy-argument; 1102 } 1103 } 1104 } // function-call 1105 case rpc-operation { 1106 container rpc-operation { 1107 description 1108 "The operation is to call an RPC, which is defined by 1109 a YANG module supported by the server."; 1110 leaf name { 1111 type string; 1112 description 1113 "The name of the YANG RPC or YANG action to be 1114 called."; 1115 } 1116 leaf nc-action-xpath { 1117 type string; 1118 description 1119 "The location where the YANG action is defined. 1120 This is used if and only if a YANG action is called. 1121 This leaf is not set when a YANG RPC is called."; 1122 } 1123 list policy-variable { 1124 key name; 1125 description 1126 "A list of policy arguments used as the input or output 1127 parameters passed to the RPC."; 1128 leaf name { 1129 type string; 1130 description 1131 "A string name used as the list key to form a list 1132 of policy arguments."; 1133 } 1134 uses policy-argument; 1135 } 1136 } 1137 } // rpc-operation 1138 case notify-operation { 1139 container notify-operation { 1140 description 1141 "The operation is to send a YANG notification."; 1142 leaf name { 1143 type string; 1144 description 1145 "Name of the subscribed YANG notification."; 1146 } 1147 list policy-variable { 1148 key name; 1149 description 1150 "A list of policy arguments carried in the notification 1151 message."; 1152 leaf name { 1153 type string; 1154 description 1155 "A string name used as the list key to form a list 1156 of policy arguments."; 1157 } 1158 uses policy-argument; 1159 } 1160 } 1161 } // notify-operation 1162 } 1163 } // action-element-attributes 1165 /* 1166 * Data nodes 1167 */ 1168 container gnca { 1169 description 1170 "Top level container for Generalized Network Control Automation 1171 (GNCA)."; 1173 // policy-variables 1174 container policy-variables { 1175 description 1176 "Container of global Policy Variables (PVs)."; 1177 list policy-variable { 1178 key name; 1179 description 1180 "A list of global Policy Variables (PVs), with a string 1181 name as the entry key."; 1182 uses policy-variable-attributes; 1183 } 1184 } // policy-variables 1186 container conditions { 1187 description 1188 "Container of ECA Conditions."; 1189 list condition { 1190 key name; 1191 description 1192 "A list of ECA Conditions."; 1194 leaf name { 1195 type string; 1196 description 1197 "A string name to uniquely identify an ECA Condition 1198 globally."; 1199 } 1200 leaf logical-operation-type { 1201 type identityref { 1202 base logical-operation-type; 1203 } 1204 description 1205 "The logical operation type used to combine the results 1206 from the list comparison-operation and the list 1207 sub-condition, defined below."; 1208 } 1209 list comparison-operation { 1210 key name; 1211 description 1212 "A list of comparison oprations, each of them defines a 1213 comparison in the form of , 1214 where and are policy arguments, while 1215 is the comparison-type, which can be 1216 ==, !=, >, <, >=, <="; 1217 leaf name { 1218 type string; 1219 description 1220 "A string name to uniquely identify a comparison 1221 operation."; 1222 } 1223 leaf comparision-type { 1224 type identityref { 1225 base comparison-type; 1226 } 1227 description 1228 "The comparison operation applied to the two arguments 1229 arg1 and arg2 defined blow."; 1230 } 1231 container arg1 { 1232 description 1233 "The policy argument used as the first parameter of 1234 the comparison opration. 1235 A policy argument represents either a constant, PV or 1236 data store value pointed by XPath."; 1237 uses policy-argument; 1238 } 1239 container arg2 { 1240 description 1241 "The policy argument used as the secone parameter of 1242 the comparison opration. 1243 A policy argument represents either a constant, PV or 1244 data store value pointed by XPath."; 1245 uses policy-argument; 1246 } 1247 } 1248 list sub-condition { 1249 key name; 1250 description 1251 "A list of sub conditions applied by the 1252 logical-operation-type. This list of sub conditions 1253 provides the capability of hierarchically combining 1254 conditions."; 1255 leaf name { 1256 type leafref { 1257 path "/gnca/conditions/condition/name"; 1258 } 1259 description 1260 "A reference to a defined condition, which is used 1261 as a sub-condition for the logical operation at this 1262 hierarchy level."; 1263 } 1264 } // sub-condition 1265 } // condition 1266 } // conditions 1268 container actions { 1269 description 1270 "Container of ECA Actions."; 1271 list action { 1272 key name; 1273 description 1274 "A list of ECA Actions."; 1275 leaf name { 1276 type string; 1277 description 1278 "A string name to uniquely identify an ECA Action 1279 globally."; 1280 } 1282 list action-element { 1283 key name; 1284 description 1285 "A list of elements contained in an ECA Action. "; 1286 leaf name { 1287 type string; 1288 description 1289 "A string name to uniquely identify the action element 1290 within the scope of an ECA action."; 1291 } 1292 uses action-element-attributes; 1293 } 1295 container time-schedule { 1296 description 1297 "Specifying the time schedule to execute this ECA 1298 Action. 1299 If not specified, the ECA Action is executed immediately 1300 when it is called."; 1301 leaf start { 1302 type yang:date-and-time; 1303 description 1304 "The start time of the ECA Action. 1305 If not specified, the ECA Action is executed 1306 immediately when it is called."; 1307 } 1308 leaf repeat-interval { 1309 type string { 1310 pattern 1311 '(R\d*/)?P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?' 1312 + '(\d+M)?(\d+S)?'; 1313 } 1314 description 1315 "The repeat interval to execute this ECA Action. 1316 The repeat interval is a string in ISO 8601 format, 1317 representing a delay duration or a repeated delay 1318 duration. 1319 If not specified, the ECA Action is executed without 1320 delay and without repetition."; 1321 } 1322 } // time-schedule 1323 } 1324 } // actions 1326 container ecas { 1327 description 1328 "Container of ECAs."; 1329 list eca { 1330 key name; 1331 description 1332 "A lis of ECAs"; 1333 leaf name { 1334 type string; 1335 description 1336 "A string name to uniquely identify an ECA globally."; 1337 } 1338 leaf event-name { 1339 type string; 1340 mandatory true; 1341 description 1342 "The name of an event that triggers the execution of 1343 this ECA."; 1344 } 1346 list policy-variable { 1347 key name; 1348 description 1349 "A list of ECA local Policy Variables (PVs), with a 1350 string name as the entry key."; 1351 uses policy-variable-attributes; 1352 leaf is-static { 1353 type boolean; 1354 description 1355 "'true' if the PV is static; 'false' if the PV is 1356 dynamic. 1357 A dynamic PV appears/disappears with the start/stop 1358 of the ECA execution; a static PV exists as long as 1359 the ECA is configured."; 1360 } 1361 } 1363 list condition-action { 1364 key name; 1365 description 1366 "A list of Condition-Actions, which are configured 1367 conditions each with associated actions to be executed 1368 if the condition is evaluated to TRUE"; 1369 leaf name { 1370 type string; 1371 description 1372 "A string name uniquely identify a Condition-Action 1373 within this ECA."; 1374 } 1375 leaf condition { 1376 type leafref { 1377 path "/gnca/conditions/condition/name"; 1378 } 1379 description 1380 "The reference to a configured condition."; 1381 } 1382 leaf action { 1383 type leafref { 1384 path "/gnca/actions/action/name"; 1385 } 1386 description 1387 "The reference to a configured action."; 1388 } 1389 } // condition-action 1391 list cleanup-condition-action { 1392 key name; 1393 description 1394 "A list of Condition-Actions, which are configured 1395 conditions each with associated actions to be executed 1396 if the condition is evaluated to TRUE. 1397 This is the exception handler of this ECA, and is 1398 evaluated and executed in case any Action from the 1399 normal Condition-Action list was attempted and rejected 1400 by the server."; 1401 leaf name { 1402 type string; 1403 description 1404 "A string name uniquely identify a Condition-Action 1405 within this ECA."; 1406 } 1407 leaf condition { 1408 type leafref { 1409 path "/gnca/conditions/condition/name"; 1410 } 1411 description 1412 "The reference to a configured condition."; 1413 } 1414 leaf action { 1415 type leafref { 1416 path "/gnca/actions/action/name"; 1417 } 1418 description 1419 "The reference to a configured action."; 1420 } 1421 } // cleanup-condition-action 1423 action start { 1424 description 1425 "Start to execute this ECA."; 1426 } 1427 action stop { 1428 description 1429 "Stop the execution of this ECA."; 1430 } 1431 action pause { 1432 description 1433 "Pause the execution of this ECA."; 1435 } 1436 action resume { 1437 description 1438 "Resume the execution of this ECA."; 1439 } 1440 action next-action { 1441 description 1442 "Resume the execution of this ECA to complete the next 1443 action."; 1444 } 1445 list execution { 1446 key id; 1447 config false; 1448 description 1449 "A list of executions that this ECA has completed, 1450 are currently running, and will start in the scheduled 1451 future."; 1452 leaf id { 1453 type uint32; 1454 description 1455 "The ID to uniquely identify an execution of the ECA."; 1456 } 1457 leaf oper-status { 1458 type enumeration { 1459 enum completed { 1460 description "Completed with no error."; 1461 } 1462 enum running { 1463 description "Currently with no error."; 1464 } 1465 enum sleeping { 1466 description "Sleeping because of time schedule."; 1467 } 1468 enum paused { 1469 description "Paused by the operator."; 1470 } 1471 enum stoped { 1472 description "Stopped by the operator."; 1473 } 1474 enum failed { 1475 description "Failed with errors."; 1476 } 1477 enum error-handling { 1478 description 1479 "Asking the operator to handle an error."; 1480 } 1481 } 1482 description 1483 "The running status of the execution."; 1484 } 1485 leaf start-time { 1486 type yang:date-and-time; 1487 description 1488 "The time when the ECA started."; 1489 } 1490 leaf stop-time { 1491 type yang:date-and-time; 1492 description 1493 "The time when the ECA completed or stopped."; 1494 } 1495 leaf next-scheduled-time { 1496 type yang:date-and-time; 1497 description 1498 "The next time when the ECA is scheduled to resume."; 1499 } 1500 leaf last-condition-action { 1501 type leafref { 1502 path "../../condition-action/name"; 1503 } 1504 description 1505 "The reference to a condition-action last executed 1506 or being executed."; 1507 } 1508 leaf last-condition { 1509 type leafref { 1510 path "../../condition-action/condition"; 1511 } 1512 description 1513 "The reference to a condition last executed or being 1514 executed."; 1515 } 1516 leaf last-action { 1517 type leafref { 1518 path "../../condition-action/action"; 1519 } 1520 description 1521 "The reference to aa action last executed or being 1522 executed."; 1523 } 1524 leaf last-cleanup-condition-action { 1525 type leafref { 1526 path "../../cleanup-condition-action/name"; 1527 } 1528 description 1529 "The reference to a cleanup-condition-action last 1530 executed or being executed."; 1532 } 1533 } 1534 } 1535 } // ecas 1537 container eca-scripts { 1538 description 1539 "Container of ECA Scripts."; 1540 list eca-script { 1541 key script-name; 1542 description 1543 "A list of ECA Script."; 1544 leaf script-name { 1545 type string; 1546 description 1547 "A string name to uniquely identify an ECA Script."; 1548 } 1549 list eca { 1550 key eca-name; 1551 description 1552 "A list of ECAs contained in this ECA Script."; 1553 leaf eca-name { 1554 type leafref { 1555 path "/gnca/ecas/eca/name"; 1556 } 1557 description 1558 "The reference to a configured ECA."; 1559 } 1560 } 1561 } 1562 } // eca-scripts 1564 leaf running-script { 1565 type leafref { 1566 path "/gnca/eca-scripts/eca-script/script-name"; 1567 } 1568 description 1569 "The reference to the ECA script that is currently running."; 1570 } 1571 } 1572 } 1573 1575 8. IANA Considerations 1577 TBD. 1579 9. Security Considerations 1581 TBD. 1583 10. Acknowledgements 1585 The authors would like to thank Joel Halpern and Robert Wilton for 1586 their helpful comments and valuable contributions. 1588 11. References 1590 11.1. Normative References 1592 [I-D.clemm-netconf-push-smart-filters-ps] 1593 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 1594 Zheng, G., and H. Birkholz, "Smart filters for Push 1595 Updates - Problem Statement", draft-clemm-netconf-push- 1596 smart-filters-ps-00 (work in progress), October 2017. 1598 [I-D.ietf-teas-yang-te-topo] 1599 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1600 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1601 Topologies", draft-ietf-teas-yang-te-topo-14 (work in 1602 progress), February 2018. 1604 11.2. Informative References 1606 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1607 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1608 . 1610 [I-D.ietf-netconf-subscribed-notifications] 1611 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1612 A. Tripathy, "Custom Subscription to Event Streams", 1613 draft-ietf-netconf-subscribed-notifications-09 (work in 1614 progress), January 2018. 1616 [I-D.ietf-netconf-yang-push] 1617 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1618 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 1619 Subscription", draft-ietf-netconf-yang-push-14 (work in 1620 progress), February 2018. 1622 Authors' Addresses 1624 Igor Bryskin 1625 Huawei Technologies 1627 EMail: Igor.Bryskin@huawei.com 1629 Xufeng Liu 1630 Jabil 1632 EMail: Xufeng_Liu@jabil.com 1634 Alexander Clemm 1635 Huawei 1637 EMail: ludwig@clemm.org 1639 Henk Birkholz 1640 Fraunhofer SIT 1642 EMail: henk.birkholz@sit.fraunhofer.de 1644 Tianran Zhou 1645 Huawei 1647 EMail: zhoutianran@huawei.com