idnits 2.17.1 draft-gonzalez-netconf-5277bis-02.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.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 419 has weird spacing: '...ionTime yan...' == Line 432 has weird spacing: '...lter-id fil...' == Line 503 has weird spacing: '...-result sub...' == Line 530 has weird spacing: '...-result sub...' == Line 546 has weird spacing: '...tion-id sub...' == (8 more instances...) -- The document date (June 15, 2016) is 2871 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) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-13 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF A. Gonzalez Prieto 3 Internet-Draft A. Clemm 4 Intended status: Standards Track E. Voit 5 Expires: December 17, 2016 E. Nilsen-Nygaard 6 A. Tripathy 7 Cisco Systems 8 S. Chisholm 9 Ciena 10 H. Trevino 11 Cisco Systems 12 June 15, 2016 14 Subscribing to YANG-Defined Event Notifications 15 draft-gonzalez-netconf-5277bis-02 17 Abstract 19 This document defines capabilities and operations for providing 20 asynchronous message notification delivery for notifications defined 21 using YANG. Notification delivery can occur over a variety of 22 protocols used commonly in conjunction with YANG, such as NETCONF and 23 Restconf. The capabilities and operations defined in this document 24 along with their mapping onto NETCONF transport (to be specified in a 25 separate document, but still included in the current document 26 version) are intended to obsolete RFC 5277. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 17, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.3. Solution Overview . . . . . . . . . . . . . . . . . . . . 6 66 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.1. Event Streams . . . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Event Stream Discovery . . . . . . . . . . . . . . . . . 7 69 2.3. Default Event Stream . . . . . . . . . . . . . . . . . . 8 70 2.4. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.5. Subscription State Model at the Publisher . . . . . . . . 8 72 2.6. Data Model Trees for Event Notifications . . . . . . . . 9 73 2.7. Creating a Subscription . . . . . . . . . . . . . . . . . 13 74 2.8. Establishing a Subscription . . . . . . . . . . . . . . . 14 75 3. Modifying a Subscription . . . . . . . . . . . . . . . . . . 15 76 4. Deleting a Subscription . . . . . . . . . . . . . . . . . . . 16 77 5. Configured Subscriptions . . . . . . . . . . . . . . . . . . 17 78 5.1. Creating a Configured Subscription . . . . . . . . . . . 17 79 5.2. Establishing a Configured Subscription . . . . . . . . . 17 80 5.3. Modifying a Configured Subscription . . . . . . . . . . . 19 81 5.4. Deleting a Configured Subscription . . . . . . . . . . . 19 82 6. Event (Data Plane) Notifications . . . . . . . . . . . . . . 20 83 7. Control Plane Notifications . . . . . . . . . . . . . . . . . 22 84 7.1. replayComplete . . . . . . . . . . . . . . . . . . . . . 22 85 7.2. notificationComplete . . . . . . . . . . . . . . . . . . 23 86 7.3. subscription-started . . . . . . . . . . . . . . . . . . 23 87 7.4. subscription-modified . . . . . . . . . . . . . . . . . . 23 88 7.5. subscription-terminated . . . . . . . . . . . . . . . . . 23 89 7.6. subscription-suspended . . . . . . . . . . . . . . . . . 23 90 7.7. subscription-resumed . . . . . . . . . . . . . . . . . . 24 91 8. Subscription Management . . . . . . . . . . . . . . . . . . . 24 92 9. Data Models for Event Notifications . . . . . . . . . . . . . 25 93 9.1. Data Model for RFC5277 (netmod namespace) . . . . . . . . 25 94 9.2. Data Model for RFC5277 (netconf namespace) . . . . . . . 28 95 9.3. Data Model for RFC5277-bis Extensions . . . . . . . . . . 32 96 10. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 50 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 98 12. Issues that are currently being worked and resolved . . . . . 52 99 12.1. Unresolved and yet-to-be addressed issues . . . . . . . 52 100 12.2. Agreement in principal . . . . . . . . . . . . . . . . . 52 101 12.3. Resolved Issues . . . . . . . . . . . . . . . . . . . . 53 102 12.4. Editorial To-Dos . . . . . . . . . . . . . . . . . . . . 53 103 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 105 14.1. Normative References . . . . . . . . . . . . . . . . . . 53 106 14.2. Informative References . . . . . . . . . . . . . . . . . 54 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 109 1. Introduction 111 This document defines mechanisms that provide an asynchronous message 112 notification delivery service for the NETCONF protocol . This is an 113 optional capability built on top of the base NETCONF definition. 114 This document defines capabilities and operations for providing 115 asynchronous message notification delivery for notifications defined 116 using YANG, including capabilities and operations necessary to 117 establish, monitor, and support subscriptions to notification 118 delivery. 120 Notification delivery can occur over a variety of protocols used 121 commonly in conjunction with YANG, such as NETCONF [RFC6241] and 122 Restconf [I-D.ietf-netconf-restconf]. The capabilities and 123 operations defined in this document along with their mapping onto 124 NETCONF transport (to be specified in a separate document, but still 125 included in the current document version) are intended to obsolete 126 RFC 5277. 128 Editor's note: The current version of this document specifies both 129 capabilities and operations for providing asynchronous notification 130 delivery, as well as mapping of those capabilities and operations 131 onto NETCONF. The transport mapping to NETCONF will be moved into a 132 separate document and will be removed in future revisions of this 133 document. 135 1.1. Motivation 137 The motivation for this work is to enable the sending of asynchronous 138 notification messages that are consistent with the data model 139 (content) and security model used within a NETCONF implementation. 141 [RFC5277] defines a notification mechanism for NETCONF. However, 142 there are various limitations: 144 o Each subscription requires a separate NETCONF connection, which is 145 wasteful. 147 o The only mechanism to terminate a subscription is terminating the 148 underlying NETCONF connection. 150 o No ability to modify subscriptions once they have been created. 152 o No ability to notify the receiver of a subscription if the server 153 is dropping events. 155 o No mechanism to monitor subscriptions. 157 o No alternative mechanism to create subscriptions via RPCs. Thus 158 the lifetime of the subscription is limited by that of the 159 underlaying NETCONF session. 161 o Predates YANG and defines RPCs, notifications, and data nodes 162 outside of the YANG framework. 164 The scope of the work aims at meeting the following operational 165 needs: 167 o Ability to dynamically or statically subscribe to event 168 notifications available on a NETCONF agent. 170 o Ability to negotiate acceptable dynamic subscription parameters. 172 o Ability to support multiple subscriptions over a single NETCONF 173 session. 175 o Ability to filter the subset of notifications to be pushed with 176 stream-specific semantics. 178 o Ability for the notification payload to be interpreted 179 independently of the NETCONF transport protocol. (In other words, 180 the encoded notification fully describes itself.) 182 o Mechanism to communicate the notifications. 184 o Ability to replay locally logged notifications. 186 o Backwards compatible with RFC 5277 implementations. 188 o Define in YANG, the RPCs, notifications, and data nodes in RFC 189 5277. 191 1.2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 Event: Something that happens that may be of interest. (e.g., a 198 configuration change, a fault, a change in status, crossing a 199 threshold, or an external input to the system.) 201 Event notification: A message sent by a server to a receiver 202 indicating that an event (of interest to the subscriber) has 203 occurred. Events can trigger notifications if an interested party 204 has subscribed to the stream(s) it belongs to. 206 Stream (also referred to as "event stream"): A continuous flow of 207 event, status, state, or other information. 209 Subscriber: An entity able to request and negotiate a contract for 210 the receipt of event notifications from a NETCONF server. 212 Receiver: A target to which a NETCONF server pushes event 213 notifications. In many deployments, the receiver and subscriber will 214 be the same entity. 216 Subscription: A contract between a subscriber and a NETCONF server, 217 stipulating which information the receiver wishes to have pushed from 218 the server without the need for further solicitation. 220 Filter: Evaluation criteria, which may be applied against a targeted 221 set of objects/events in a subscription. Information traverses the 222 filter only if specified filter criteria are met. 224 Dynamic subscription: A subscription agreed between subscriber and 225 NETCONF server via create, establish, modify, and delete RPC control 226 plane signaling messages. 228 Configured subscription: A subscription installed via a configuration 229 interface. 231 Operation: In this document, this term refers to NETCONF protocol 232 operations [RFC6241] defined in support of NETCONF notifications. 234 NACM: NETCONF Access Control Model. 236 RPC: Remote Procedure Call. 238 1.3. Solution Overview 240 This document describes mechanisms for subscribing and receiving 241 event notifications from a NETCONF server. This document enhances 242 the capabilities of RFC 5277 while maintaining backwards capability 243 with existing implementations. It is intended that a final version 244 of this document might obsolete RFC 5277. 246 The enhancements over [RFC5277] include the ability to terminate 247 subscriptions without terminating the client session, to modify 248 existing subscriptions, and to have multiple subscriptions on a 249 NETCONF session. 251 These enhancements do not affect [RFC5277] clients that do not 252 support these particular subscription requirements. 254 The solution supports subscribing to event notifications using two 255 mechanisms. 257 1. Dynamic subscriptions, where a NETCONF client initiates a 258 subscription negotiation with a NETCONF server. Here a client 259 initiates a negotiation by issuing a subscription request. If 260 the agent wants to serve this request, it will accept it, and 261 then start pushing event notifications as negotiated. If the 262 agent does not wish to serve it as requested, it may respond with 263 subscription parameters, which it would have accepted. 265 2. Configured subscriptions, which is an optional mechanism that 266 enables managing subscriptions via a configuration interface so 267 that a NETCONF agent sends event notifications to given 268 receiver(s). 270 Some key characteristics of configured and dynamic subscriptions 271 include: 273 o The lifetime of a dynamic subscription is limited by the lifetime 274 of the subscriber session used to establish it. Typically loss of 275 the transport session tears down any dependent dynamic 276 subscriptions. 278 o The lifetime of a configured subscription is driven by 279 configuration being present on the running configuration. This 280 implies configured subscriptions persist across reboots, and 281 persists even when transport is unavailable. This also means 282 configured subscriptions do not support negotiation. 284 o Subscriptions can be modified or terminated at any point of their 285 lifetime. configured subscriptions can be modified by any 286 configuration client with write rights on the configuration of the 287 subscription. 289 o A NETCONF agent can support multiple dynamic subscriptions 290 simultaneously in the context of a single NETCONF session. (This 291 requires supporting interleaving.) The termination of any of 292 those subscriptions does not imply the termination of NETCONF 293 transport session. 295 Note that there is no mixing-and-matching of RPC and configuration 296 operations. Specifically, a configured subscription cannot be 297 modified or deleted using RPC. Similarly, a subscription created via 298 RPC cannot be modified through configuration operations. 300 The NETCONF agent may decide to terminate a dynamic subscription at 301 any time. Similarly the NETCONF agent may decide to temporarily 302 suspend the sending of event notifications for either configured or 303 dynamic subscriptions. Such termination or suspension may be driven 304 by the agent running out of resources to serve the subscription, or 305 by internal errors on the server. 307 2. Solution 309 2.1. Event Streams 311 An event stream is a set of events available for subscription from a 312 server. It is out of the scope of this document to identify a) how 313 streams are defined, b) how events are defined/generated, and c) how 314 events are assigned to streams. 316 The following is a high-level description of the flow of a 317 notification. Note that it does not mandate and/or preclude an 318 implementation. As events are raised, they are assigned to streams. 319 An event may be assigned to multiple streams. The event is 320 distributed to subscribers and receivers based on the current 321 subscriptions and access control. Access control is needed because 322 if any receiver of that subscription does not have permission to 323 receive an event, then it never makes it into a notification, and 324 processing of the event is completed for that subscription. 326 2.2. Event Stream Discovery 328 A server maintains a list of available event streams as operational 329 data. A client can retrieve this list like any other YANG-defined 330 data, for example using the operation when using NETCONF. 332 2.3. Default Event Stream 334 A NETCONF server implementation supporting the notification 335 capability MUST support the "NETCONF" notification event stream. 336 This stream contains all NETCONF XML event notifications supported by 337 the NETCONF server, except for those belonging only to streams that 338 explicitly indicate that they must be excluded from the NETCONF 339 stream. The exact string "NETCONF" is used during the advertisement 340 of stream support during the operation on and during 341 the and operations. 343 2.4. Filters 345 A NETCONF Server implementation SHOULD support the ability to perform 346 filtering of notification records per RFC 5277. 348 2.5. Subscription State Model at the Publisher 350 Below is the state machine of a subscription for the publisher. It 351 is important to note that a subscription doesn't exist at the 352 publisher until it is accepted and made active. The mere request by 353 a subscriber to establish a subscription is insufficient for that 354 asserted subscription to be externally visible via this state 355 machine. 357 .-------. 358 | start | 359 '-------' 360 | 361 establish 362 | 363 | .----------modify-------------.lex 364 v v ' 365 .-----------. .-----------. 366 .--------. | |------>suspend------->| | 367 modify '| active | | suspended | 368 '--------->| |<----resume----<------| | 369 '-----------' '-----------' 370 | | 371 delete delete 372 | | 373 v | 374 .-------. | 375 | end |<-----------------------------' 376 '-------' 378 Figure 1: Subscription states at publisher 380 Of interest in this state machine are the following: 382 o Successful or 383 requests put the subscription into an active state. 385 o Failed requests will leave the subscription 386 in its previous state, with no visible change to any streaming 387 updates. 389 o A request will delete the entire 390 subscription. 392 2.6. Data Model Trees for Event Notifications 394 The YANG data models for event notifications are depicted in the 395 following sections. 397 2.6.1. Data Model Tree for RFC5277 (netconf namespace) 399 module: ietf-5277-netconf 400 rpcs: 401 +---x create-subscription 402 +--ro input 403 +--ro stream? string 404 +--ro (filter-type)? 405 | +--:(rfc5277) 406 | +--ro filter 407 +--ro startTime? yang:date-and-time 408 +--ro stopTime? yang:date-and-time 410 2.6.2. Data Model Tree for RFC5277 (netmod namespace) 412 module: ietf-5277-netmod 413 +--rw netconf 414 +--rw streams 415 +--rw stream* [name] 416 +--rw name string 417 +--rw description string 418 +--rw replaySupport boolean 419 +--rw replayLogCreationTime yang:date-and-time 420 +--rw replayLogAgedTime yang:date-and-time 421 notifications: 422 +---n replayComplete 423 +---n notificationComplete 425 2.6.3. Data Model for RFC5277-bis Extensions 427 module: ietf-event-notifications 428 +--ro streams 429 | +--ro stream* notif:stream 430 +--rw filters 431 | +--rw filter* [filter-id] 432 | +--rw filter-id filter-id 433 | +--rw (filter-type)? 434 | +--:(rfc5277) 435 | +--rw filter 436 +--rw subscription-config {configured-subscriptions}? 437 | +--rw subscription* [subscription-id] 438 | +--rw subscription-id subscription-id 439 | +--rw stream? stream 440 | +--rw (filter-type)? 441 | | +--:(rfc5277) 442 | | | +--rw filter 443 | | +--:(by-reference) 444 | | +--rw filter-ref? filter-ref 445 | +--rw startTime? yang:date-and-time 446 | +--rw stopTime? yang:date-and-time 447 | +--rw encoding? encoding 448 | +--rw receivers 449 | | +--rw receiver* [address] 450 | | +--rw address inet:host 451 | | +--rw port inet:port-number 452 | | +--rw protocol? transport-protocol 453 | +--rw (push-source)? 454 | +--:(interface-originated) 455 | | +--rw source-interface? if:interface-ref 456 | +--:(address-originated) 457 | +--rw source-vrf? uint32 458 | +--rw source-address inet:ip-address-no-zone 459 +--ro subscriptions 460 +--ro subscription* [subscription-id] 461 +--ro subscription-id subscription-id 462 +--ro configured-subscription? empty {configured-subscriptions}? 463 +--ro subscription-status? subscription-status 464 +--ro stream? stream 465 +--ro (filter-type)? 466 | +--:(rfc5277) 467 | | +--ro filter 468 | +--:(by-reference) 469 | +--ro filter-ref? filter-ref 470 +--ro startTime? yang:date-and-time 471 +--ro stopTime? yang:date-and-time 472 +--ro encoding? encoding 473 +--ro receivers 474 | +--ro receiver* [address] 475 | +--ro address inet:host 476 | +--ro port inet:port-number 477 | +--ro protocol? transport-protocol 478 +--ro (push-source)? 479 +--:(interface-originated) 480 | +--ro source-interface? if:interface-ref 481 +--:(address-originated) 482 +--ro source-vrf? uint32 483 +--ro source-address inet:ip-address-no-zone 484 augment /netmod-notif:replayComplete: 485 +---- subscription-id? subscription-id 486 augment /netmod-notif:notificationComplete: 487 +---- subscription-id? subscription-id 488 augment /netmod-notif:netconf/netmod-notif:streams: 489 +--rw exclude-from-NETCONF-stream? empty 490 rpcs: 491 +---x establish-subscription 492 | +---w input 493 | | +---w stream? stream 494 | | +---w (filter-type)? 495 | | | +--:(rfc5277) 496 | | | | +---w filter 497 | | | +--:(by-reference) 498 | | | +---w filter-ref? filter-ref 499 | | +---w startTime? yang:date-and-time 500 | | +---w stopTime? yang:date-and-time 501 | | +---w encoding? encoding 502 | +--ro output 503 | +--ro subscription-result subscription-result 504 | +--ro (result)? 505 | +--:(success) 506 | | +--ro subscription-id subscription-id 507 | +--:(no-success) 508 | +--ro stream? stream 509 | +--ro (filter-type)? 510 | | +--:(rfc5277) 511 | | | +--ro filter 512 | | +--:(by-reference) 513 | | +--ro filter-ref? filter-ref 514 | +--ro startTime? yang:date-and-time 515 | +--ro stopTime? yang:date-and-time 516 | +--ro encoding? encoding 517 +---x modify-subscription 518 | +---w input 519 | | +---w subscription-id? subscription-id 520 | | +---w stream? stream 521 | | +---w (filter-type)? 522 | | | +--:(rfc5277) 523 | | | | +---w filter 524 | | | +--:(by-reference) 525 | | | +---w filter-ref? filter-ref 526 | | +---w startTime? yang:date-and-time 527 | | +---w stopTime? yang:date-and-time 528 | | +---w encoding? encoding 529 | +--ro output 530 | +--ro subscription-result subscription-result 531 | +--ro (result)? 532 | +--:(success) 533 | | +--ro subscription-id subscription-id 534 | +--:(no-success) 535 | +--ro stream? stream 536 | +--ro (filter-type)? 537 | | +--:(rfc5277) 538 | | | +--ro filter 539 | | +--:(by-reference) 540 | | +--ro filter-ref? filter-ref 541 | +--ro startTime? yang:date-and-time 542 | +--ro stopTime? yang:date-and-time 543 | +--ro encoding? encoding 544 +---x delete-subscription 545 +---w input 546 | +---w subscription-id subscription-id 547 +--ro output 548 +--ro subscription-result subscription-result 549 notifications: 550 +---n subscription-started 551 | +--ro subscription-id subscription-id 552 | +--ro stream? stream 553 | +--ro (filter-type)? 554 | | +--:(rfc5277) 555 | | | +--ro filter 556 | | +--:(by-reference) 557 | | +--ro filter-ref? filter-ref 558 | +--ro startTime? yang:date-and-time 559 | +--ro stopTime? yang:date-and-time 560 | +--ro encoding? encoding 561 +---n subscription-suspended 562 | +--ro subscription-id subscription-id 563 | +--ro reason? subscription-susp-reason 564 +---n subscription-resumed 565 | +--ro subscription-id subscription-id 566 +---n subscription-modified 567 | +--ro subscription-id subscription-id 568 | +--ro stream? stream 569 | +--ro (filter-type)? 570 | | +--:(rfc5277) 571 | | | +--ro filter 572 | | +--:(by-reference) 573 | | +--ro filter-ref? filter-ref 574 | +--ro startTime? yang:date-and-time 575 | +--ro stopTime? yang:date-and-time 576 | +--ro encoding? encoding 577 +---n subscription-terminated 578 | +--ro subscription-id subscription-id 579 | +--ro reason? subscription-term-reason 580 +---n added-to-subscription 581 | +--ro subscription-id subscription-id 582 | +--ro stream? stream 583 | +--ro (filter-type)? 584 | | +--:(rfc5277) 585 | | | +--ro filter 586 | | +--:(by-reference) 587 | | +--ro filter-ref? filter-ref 588 | +--ro startTime? yang:date-and-time 589 | +--ro stopTime? yang:date-and-time 590 | +--ro encoding? encoding 591 +---n removed-from-subscription 592 +--ro subscription-id subscription-id 594 2.7. Creating a Subscription 596 Editor's note: The following section needs updating. NETCONF mapping 597 will move to a separate document. 599 This operation is fully defined in [RFC5277]. It allows a subscriber 600 to request the creation of a dynamic subscription. If successful, 601 the subscription remains in effect for the duration of the NETCONF 602 session. 604 This operation is included in the document for supporting backwards 605 compatibility with [RFC5277] clients. New clients are expected not 606 to use this operation, but establish subscriptions as defined in 607 Section 2.8 609 2.7.1. Parameters 611 The input parameters of the operation are: 613 o stream: An optional parameter that indicates which stream of 614 events is of interest. If not present, events in the default 615 NETCONF stream will be sent. 617 o filter: An optional parameter that indicates which subset of all 618 possible events is of interest. The format of this parameter is 619 the same as that of the filter parameter in the NETCONF protocol 620 operations. If not present, all events not precluded by other 621 parameters will be sent. 623 o startTime: An optional parameter used to trigger the replay 624 feature and indicate that the replay should start at the time 625 specified. If startTime is not present, this is not a replay 626 subscription. It is not valid to specify start times that are 627 later than the current time. If the startTime specified is 628 earlier than the log can support, the replay will begin with the 629 earliest available notification. Implementations must support 630 time zones. 632 o stopTime: An optional parameter used with the optional replay 633 feature to indicate the newest notifications of interest. If 634 stopTime is not present, the notifications will continue until the 635 subscription is terminated. Must be used with and be later than 636 startTime. Implementations must support time zones. 638 If the server can satisfy the request, it sends a positive 639 acknowledgement. 641 If the request cannot be completed for any reason, an error is 642 returned along with an error reason. Subscription requests can fail 643 for several reasons, including if a filter with invalid syntax is 644 provided or if the name of a non-existent stream is provided. Other 645 errors include: 647 o The optional replay feature is requested but the server does not 648 support it 650 o A stopTime is requested that is earlier than the specified 651 startTime 653 o A startTime is requested that is later than the current time 655 2.8. Establishing a Subscription 657 Editor's note: The following section needs updating. NETCONF mapping 658 will move to a separate document. 660 This operation is an evolution of the create subscription operation. 661 It allows a subscriber to request the creation of a subscription both 662 via RPC and configuration operations. When invoking the RPC, 663 establish-subscription permits negotiating the subscription terms, 664 changing them dynamically and enabling multiple subscriptions overs a 665 single NETCONF session (if interleaving [RFC6241] is supported), and 666 canceling subscriptions without terminating the NETCONF session. 668 The input parameters of the operation are those of create 669 subscription plus: 671 o filter-ref: filters that have been previously (and separately) 672 configured can be referenced by a subscription. This mechanism 673 enables the reuse of filters. 675 o encoding: by default, updates are encoded using XML. Other 676 encodings may be supported, such as JSON. 678 If the NETCONF server cannot satisfy the request, the server sends a 679 negative element. 681 If the client has no authorization to establish the subscription, the 682 indicates an authorization error. If the 683 request is rejected because the server is not able to serve it, the 684 server SHOULD include in the returned error what subscription 685 parameters would have been accepted for the request when it was 686 processed. However, they is no guarantee that subsequent requests 687 with those parameters for this client or others will be accepted. 688 For instance, consider a subscription from 689 [I-D.ietf-netconf-yang-push], which augments the establish- 690 subscription with some additional parameters, including "period". 692 Subscription requests will fail if a filter with invalid syntax is 693 provided or if the name of a non-existent stream is provided. 695 3. Modifying a Subscription 697 Editor's note: The following section needs updating. NETCONF mapping 698 will move to a separate document. 700 This operation permits modifying the terms of a subscription 701 previously established. Subscriptions created by configuration 702 cannot be modified. Dynamic subscriptions can be modified one or 703 multiple times. If the server accepts the request, it immediately 704 starts sending events based on the new terms, completely ignoring the 705 previous ones. If the server rejects the request, the subscription 706 remains as prior to the request. That is, the request has no impact 707 whatsoever. The contents of negative responses to modify- 708 subscription requests are the same as in establish subscription 709 requests. 711 Dynamic subscriptions established via RPC can only be modified (or 712 deleted) via RPC using the same session used to establish it. 714 Configured subscriptions cannot be modified (or deleted) using RPCs. 715 Instead, configured subscriptions are modified (or deleted) as part 716 of regular configuration operations. Servers MUST reject any 717 attempts to modify (or delete) configured subscriptions via RPC. 719 The parameters to modify-subscription are those of establish- 720 subscription plus a mandatory subscription-id. 722 If the NETCONF server can satisfy the request, the server sends a 723 positive subscription-result. This response is like that to an 724 establish-subscription request without the subscription-id, which 725 would be redundant. 727 If the NETCONF server cannot satisfy the request, the server sends a 728 negative subscription-result. Its contents and semantics are 729 identical to those to an establish-subscription request. 731 4. Deleting a Subscription 733 Editor's note: The following section needs updating. NETCONF mapping 734 will move to a separate document. 736 This operation permits canceling a subscription previously 737 established. Created subscriptions cannot be explicitly deleted. If 738 the server accepts the request, it immediately stops sending events 739 for the subscription. If the server rejects the request, all 740 subscriptions remain as prior to the request. That is, the request 741 has no impact whatsoever. A request may be rejected because the 742 provided subscription identifier is incorrect. 744 Subscriptions created via RPC can only be deleted via RPC using the 745 same session used for establishment. Configured subscriptions cannot 746 be deleted using RPCs. Instead, configured subscriptions are deleted 747 as part of regular configuration operations. Servers MUST reject any 748 RPC attempt to delete configured subscriptions. 750 The only parameter to delete-subscription is the identifier of the 751 subscription to delete. 753 If the NETCONF server can satisfy the request, the server sends an OK 754 element. 756 If the NETCONF server cannot satisfy the request, the server sends an 757 error-rpc element. 759 5. Configured Subscriptions 761 A configured subscription is a subscription installed via a 762 configuration interface. 764 Configured subscriptions persist across reboots, and persist even 765 when transport is unavailable. This also means configured 766 subscriptions do not support negotiation. 768 Configured subscriptions can be modified by any configuration client 769 with write rights on the configuration of the subscription. 770 Subscriptions can be modified or terminated at any point of their 771 lifetime. 773 Supporting configured subscriptions is optional and advertised using 774 the "configured-subscriptions" feature. 776 In addition to subscription parameters that apply to dynamic 777 subscriptions, the following additional parameters apply to 778 configured subscriptions: 780 o One or more receiver IP addresses (and corresponding ports) 781 intended as the destination for push updates for each 782 subscription. In addition the transport protocol for each 783 destination may be defined. 785 o Optional parameters to identify an egress interface or IP address 786 / VRF where a subscription updates should be pushed from the 787 publisher. 789 5.1. Creating a Configured Subscription 791 Configured subscriptions cannot be created via configuration 792 operations. New clients should use the mechanisms described in 793 Section 5.2 for establishing configured subscriptions. 795 5.2. Establishing a Configured Subscription 797 Subscriptions can be established using configuration operations 798 against the top-level subtree subscription-config. There are two key 799 differences between RPC and configuration operations for subscription 800 establishment. Firstly, configuration operations do not support 801 negotiation while RPCs do. Secondly, while RPCs mandate that the 802 client establishing the subscription is the only receiver of the 803 notifications, configuration operations permit specifying receivers 804 independent of any tracked subscriber. Immediately after a 805 subscription is successfully established, the server sends to the 806 receivers a control-plane notification stating the subscription has 807 been established (subscription-started). 809 Because there is no explicit association with an existing transport 810 session, configured configuration operations require additional 811 parameters to indicate the receivers of the notifications and 812 possibly the source of the notifications (i.e., a specific interface 813 or server address). 815 For example at subscription establishment, a NETCONF client may send: 817 820 821 822 823 824 826 827 828 1922 829 830 831 foo 832 833 834
835 1.2.3.4 836
837 838 1234 839 840 841 842 843 844 846 Figure 2: Establish configured subscription 848 if the request is accepted, the server would reply: 850 852 853 855 Figure 3: Response to a successful configured subscription 856 establishment 858 if the request is not accepted because the server cannot serve it, 859 the server may reply: 861 862 863 application 864 resource-denied 865 error 866 867 Temporarily the server cannot serve this 868 subscription due to the current workload. 869 870 871 873 Figure 4: Response to a failed configured subscription establishment 875 5.3. Modifying a Configured Subscription 877 Configured subscriptions can be modified using configuration 878 operations against the top-level subtree subscription-config. 880 Immediately after a subscription is successfully modified, the server 881 sends to the existing receivers a control-plane notification stating 882 the subscription has been modified (i.e., subscription-modified). 884 If the modification involved adding and/or removing receivers, those 885 modified receivers are sent control-plane notifications, indicating 886 they have been added (i.e, added-to-subscription, with the same 887 contents as a modified-subscription) or removed (i.e., removed-from- 888 subscription) 890 5.4. Deleting a Configured Subscription 892 Subscriptions can be deleted using configuration operations against 893 the top-level subtree subscription-config. For example, in NETCONF: 895 897 898 899 900 901 903 904 905 1922 906 907 908 909 910 912 914 915 917 Figure 5: Deleting a configured subscription 919 Immediately after a subscription is successfully deleted, the server 920 sends to the receivers a control-plane notification stating the 921 subscription has been terminated (subscription-terminated). 923 6. Event (Data Plane) Notifications 925 Once a subscription has been set up, the NETCONF server sends 926 (asynchronously) the event notifications from the subscribed stream. 927 We refer to these as data plane notifications. For dynamic 928 subscriptions set up via RPC operations, event notifications are sent 929 over the NETCONF session used to create or establish the 930 subscription. For configured subscriptions, event notifications are 931 sent over the specified connections. 933 An event notification is sent to the receiver(s) when an event of 934 interest (i.e., meeting the specified filtering criteria) has 935 occurred. An event notification is a complete and well-formed XML 936 document. Note that is not a Remote Procedure Call 937 (RPC) method but rather the top-level element identifying the one-way 938 message as a notification. Note that event notifications never 939 trigger responses. 941 The event notification always includes an element. It is 942 the time the event was generated by the event source. This parameter 943 is of type dateTime and compliant to [RFC3339]. Implementations must 944 support time zones. 946 The event notification also contains notification-specific tagged 947 content, if any. With the exception of , the content of 948 the notification is beyond the scope of this document. 950 For the encodings other than XML, notifications include an additional 951 XML element so that the notification is a well-formed XML. The 952 element is , E.g., . That element contains the notification contents in 954 the desired encoding 956 The following is an example of an event notification from [RFC6020]: 958 notification link-failure { 959 description "A link failure has been detected"; 960 leaf if-name { 961 type leafref { 962 path "/interface/name"; 963 } 964 } 965 leaf if-admin-status { 966 type admin-status; 967 } 968 leaf if-oper-status { 969 type oper-status; 970 } 971 } 973 Figure 6: Definition of a data plane notification 975 977 2007-09-01T10:00:00Z 978 979 so-1/2/3.0 980 up 981 down 982 983 985 Figure 7: Data plane notification 987 The equivalent using json encoding would be 988 990 2007-09-01T10:00:00Z 991 992 { 993 "acme-system:link-failure": { 994 "if-name": "so-1/2/3.0", 995 "if-admin-status": "up", 996 "if-oper-status": "down " 997 } 998 } 999 1000 1002 Figure 8: Data plane notification using JSON encoding 1004 7. Control Plane Notifications 1006 In addition to data plane notifications, a server may send control 1007 plane notifications to indicate to receivers that an event related to 1008 the subscription management has occurred. 1010 Control plane notifications are unlike other notifications in that 1011 they are not general-purpose notifications. They cannot be filtered 1012 out, and they are delivered only to the receiver of a subscription. 1013 They are thus not part of the regular NETCONF event stream. The 1014 definition of control plane notifications is distinct from other 1015 notifications by making use of a YANG extension tagging them as 1016 control plane notification. 1018 Control plane notifications include indications that a replay of 1019 notifications has been completed, that a subscription is done sending 1020 notifications because an end time has been reached, and that a 1021 subscription has started, been modified, been terminated, or been 1022 suspended. They are described in the following subsections. 1024 7.1. replayComplete 1026 This notification is originally defined in [RFC5277]. It is sent to 1027 indicate that all of the replay notifications have been sent and must 1028 not be sent for any other reason. 1030 In the case of a subscription without a stop time, after the 1031 notification has been sent, it can be expected that 1032 any notifications generated since the start of the subscription 1033 creation will be sent, followed by notifications as they arise 1034 naturally within the system. 1036 7.2. notificationComplete 1038 This notification is originally defined in [RFC5277]. It is sent to 1039 indicate that a subscription, which includes a stop time, has 1040 finished passing events. 1042 7.3. subscription-started 1044 This notification indicates that a configured subscription has 1045 started and data updates are beginning to be sent. This notification 1046 includes the parameters of the subscription, except for the 1047 receiver(s) addressing information and push-source information. Note 1048 that for RPC-based subscriptions, no such notifications are sent. 1050 7.4. subscription-modified 1052 This notification indicates that a configured subscription has been 1053 modified successfully. This notification includes the parameters of 1054 the subscription, except for the receiver(s) addressing information 1055 and push-source information. Note that for RPC-based subscriptions, 1056 no such notifications are sent. 1058 7.5. subscription-terminated 1060 This notification indicates that a subscription has been terminated. 1061 The notification includes the reason for the termination. A 1062 subscription may be terminated by a server or by a client. The 1063 server may decide to terminate a subscription when it is running out 1064 of resources for serving it, an internal error occurs, etc. Server- 1065 driven terminations are notified to all receivers. The management 1066 plane can also terminate configured subscriptions using configuration 1067 operations. 1069 Clients can terminate via RPC subscriptions established via RPC. In 1070 such cases, no subscription-terminated notifications are sent. 1072 7.6. subscription-suspended 1074 This notification indicates that a server has suspended a 1075 subscription. The notification includes the reason for the 1076 suspension. A possible reason is the lack of resources to serve it. 1077 No further data plane notifications will be sent until the 1078 subscription resumes. Suspensions are notified to the subscriber (in 1079 the case of dynamic subscriptions) and all receivers (in the case of 1080 configured subscriptions). 1082 7.7. subscription-resumed 1084 This notification indicates that a previously suspended dubscription 1085 has been resumed. Data plane notifications generated in the future 1086 will be sent after the subscription terms. Resumptions are notified 1087 to the subscriber (in the case of dynamic subscriptions) and all 1088 receivers (in the case of configured subscriptions). 1090 8. Subscription Management 1092 Below is the state machine for the server. It is important to note 1093 that a subscription does not exist at the agent until it is accepted 1094 and made active. 1096 .-------. 1097 | start | 1098 '-------' 1099 | 1100 create | establish 1101 | 1102 | .----------modify-------------. 1103 v v ' 1104 .-----------. .-----------. 1105 .--------. | |------>suspend------->| | 1106 modify '| active | | suspended | 1107 '--------->| |<----reactivate<------| | 1108 '-----------' '-----------' 1109 | | 1110 delete delete 1111 | | 1112 v | 1113 .-------. | 1114 | end |<-----------------------------' 1115 '-------' 1117 Of interest in this state machine are the following: 1119 o Successful , or 1120 actions must put the subscription into an 1121 active state. 1123 o Failed actions will leave the subscription 1124 in its previous state, with no visible change to any 1125 notifications. 1127 o A action will delete the entire 1128 subscription. 1130 9. Data Models for Event Notifications 1132 9.1. Data Model for RFC5277 (netmod namespace) 1134 1135 file "ietf-5277-netmod@2016-06-15.yang" 1136 module ietf-5277-netmod { 1137 namespace 1138 "urn:ietf:params:xml:ns:yang:ietf-5277-netmod"; 1139 // TODO: examples in the draft consider the namespace below 1140 // which follows the namespace format in 5277 1141 // "urn:ietf:params:xml:ns:netmod:notification"; 1142 prefix netmod-notif; 1144 import ietf-yang-types { 1145 prefix yang; 1146 } 1148 organization "IETF"; 1149 contact 1150 "WG Web: 1151 WG List: 1153 WG Chair: Juergen Schoenwaelder 1154 1155 WG Chair: Tom Nadeau 1156 1158 Editor: Alberto Gonzalez Prieto 1159 1161 Editor: Alexander Clemm 1162 1164 Editor: Eric Voit 1165 1167 Editor: Einar Nilsen-Nygaard 1168 1170 Editor: Ambika Prasad Tripathy 1171 "; 1173 description 1174 "Model for RPC in RFC 5277: NETCONF Event Notifications"; 1176 revision 2016-06-15 { 1177 description 1178 "Model for data nodes and notifications in RFC 5277: 1179 NETCONF Event Notifications"; 1180 reference 1181 "RFC 5277: NETCONF Event Notifications"; 1182 } 1184 /* 1185 * EXTENSIONS 1186 */ 1188 extension control-plane-notif { 1189 description 1190 "This statement applies only to notifications. 1191 It indicates that the notification is a control-plane 1192 notification and therefore it does not generate an 1193 event stream."; 1194 } 1196 /* 1197 * DATA NODES 1198 */ 1199 container netconf { 1200 description 1201 "Netconf container as defined in RFC 5277."; 1202 reference 1203 "RFC 5277: NETCONF Event Notifications"; 1205 container streams { 1206 // TODO: should be config false?. That breaks the leafref 1207 // from the config subscriptions config false; 1208 description 1209 "The container with the set of available event streams."; 1210 reference 1211 "RFC 5277: NETCONF Event Notifications"; 1213 list stream { 1214 must "1 = count(./name == 'NETCONF')" { 1215 description 1216 "The list must contain a NETCONF stream. 1217 A NETCONF server implementation supporting the 1218 notification capability MUST support the 1219 'NETCONF' notification event stream. This stream 1220 contains all NETCONF XML event notifications supported 1221 by the NETCONF server. 1222 The exact string 'NETCONF' is used during the 1223 advertisement of stream support during the 1224 operation on and during the 1225 operation."; 1226 } 1227 key "name"; 1228 description 1229 "The list available event streams."; 1230 leaf name { 1231 type string; 1232 description 1233 "The name of the event stream. 1234 If this is the default NETCONF stream, this must have 1235 the value 'NETCONF'."; 1236 } 1237 leaf description { 1238 type string; 1239 mandatory true; 1240 description 1241 "A description of the event stream, including such 1242 information as the type of events that are sent over 1243 this stream."; 1244 } 1245 leaf replaySupport { 1246 type boolean; 1247 mandatory true; 1248 description 1249 "An indication of whether or not event replay is 1250 available on this stream."; 1251 } 1252 leaf replayLogCreationTime { 1253 when "../replaySupport" { 1254 description 1255 "This object MUST be present if replay is supported."; 1256 } 1257 type yang:date-and-time; 1258 mandatory true; 1259 description 1260 "The timestamp of the creation of the log used to 1261 support the replay function on this stream. 1262 Note that this might be earlier then the earliest 1263 available notification in the log. This object 1264 is updated if the log resets for some reason. 1265 This object MUST be present if replay is supported."; 1266 } 1267 leaf replayLogAgedTime { 1268 when "current()/../replaySupport" { 1269 description 1270 "This object MUST be present if replay is supported 1271 and any notifications have been aged out of the log."; 1272 } 1273 type yang:date-and-time; 1274 mandatory true; 1275 description 1276 "The timestamp of the last notification aged 1277 out of the log. This object MUST be present 1278 if replay is supported and any notifications 1279 have been aged out of the log."; 1280 } 1281 } // list stream 1282 } // container streams 1283 } // container netconf 1285 /* 1286 * NOTIFICATIONS 1287 */ 1289 notification replayComplete { 1290 netmod-notif:control-plane-notif; 1291 description 1292 "This notification is sent to signal the end of a replay 1293 portion of a subscription."; 1294 } 1296 notification notificationComplete { 1297 netmod-notif:control-plane-notif; 1298 description 1299 "This notification is sent to signal the end of a notification 1300 subscription. It is sent in the case that stopTime was 1301 specified during the creation of the subscription."; 1302 } 1303 } 1305 1307 9.2. Data Model for RFC5277 (netconf namespace) 1309 1310 file "ietf-5277-netconf@2016-06-15.yang" 1311 module ietf-5277-netconf { 1312 namespace 1313 "urn:ietf:params:xml:ns:yang:ietf-5277-netconf"; 1314 // TODO: examples in the draft consider the namespace below 1315 // which follows the namespace format in 5277 1316 // "urn:ietf:params:xml:ns:netconf:notification:1.0"; 1317 prefix notif; 1318 import ietf-yang-types { 1319 prefix yang; 1320 } 1322 organization "IETF"; 1323 contact 1324 "WG Web: 1325 WG List: 1327 WG Chair: Mahesh Jethanandani 1328 1330 WG Chair: Mehmet Ersue 1331 1333 Editor: Alberto Gonzalez Prieto 1334 1336 Editor: Alexander Clemm 1337 1339 Editor: Eric Voit 1340 1342 Editor: Einar Nilsen-Nygaard 1343 1345 Editor: Ambika Prasad Tripathy 1346 "; 1348 description 1349 "Model for RPCs and Notifications in RFC 5277: NETCONF Event 1350 Notifications"; 1352 revision 2016-06-15 { 1353 description 1354 "Model for RPC in RFC 5277: NETCONF Event Notifications"; 1355 reference 1356 "RFC 5277: NETCONF Event Notifications"; 1357 } 1359 /* 1360 * IDENTITIES 1361 */ 1363 identity stream { 1364 description 1365 "Base identity to represent a generic stream of event 1366 notifications."; 1367 } 1369 identity NETCONF { 1370 base stream; 1371 description 1372 "Default NETCONF event stream, containing events based on 1373 notifications defined as YANG modules that are supported 1374 by the system."; 1375 } 1377 /* 1378 * TYPEDEFS 1379 */ 1381 typedef stream { 1382 type identityref { 1383 base stream; 1384 } 1385 description 1386 "Specifies a system-provided datastream."; 1387 } 1389 /* 1390 * GROUPINGS 1391 */ 1393 grouping base-filter { 1394 description 1395 "This grouping defines the base for filters for 1396 notification events. 1397 It includes the filter defined in 5277 and 1398 it enables extending filtering to other 1399 types of filters"; 1400 choice filter-type { 1401 description 1402 "A filter needs to be a single filter of a given type. 1403 Mixing and matching of multiple filters does not occur 1404 at the level of this grouping."; 1405 case rfc5277 { 1406 anyxml filter { 1407 description 1408 "Filter per RFC 5277. Notification filter. 1409 If a filter element is specified to look for data of a 1410 particular value, and the data item is not present 1411 within a particular event notification for its value to 1412 be checked against, the notification will be filtered 1413 out. For example, if one were to check for 1414 'severity=critical' in a configuration event 1415 notification where this field was not supported, then 1416 the notification would be filtered out. For subtree 1417 filtering, a non-empty node set means that the filter 1418 matches. For XPath filtering, the mechanisms defined 1419 in [XPATH] should be used to convert the returned 1420 value to boolean."; 1421 } 1422 } 1423 } 1424 } 1426 grouping subscription-info-5277 { 1427 description 1428 "This grouping describes the information in a 5277 1429 subscription."; 1430 leaf stream { 1431 type stream; 1432 default "NETCONF"; 1433 description 1434 "Indicates which stream of events is of interest. 1435 If not present, events in the default NETCONF stream 1436 will be sent."; 1437 } 1438 uses base-filter; 1439 leaf startTime { 1440 type yang:date-and-time; 1441 description 1442 "Used to trigger the replay feature 1443 and indicate that the replay should start at the time 1444 specified. If is not present, this is not a 1445 replay subscription. It is not valid to specify start 1446 times that are later than the current time. If the 1447 specified is earlier than the log can support, 1448 the replay will begin with the earliest available 1449 notification. This parameter is of type dateTime and 1450 compliant to [RFC3339]. Implementations must 1451 support time zones."; 1452 } 1453 leaf stopTime { 1454 type yang:date-and-time; 1455 must "current() > ../startTime" { 1456 description 1457 "stopTime must be used with and be later than "; 1458 } 1459 description 1460 "Used with the optional replay feature to indicate the 1461 newest notifications of interest. If is 1462 not present, the notifications will continue until the 1463 subscription is terminated. Must be used with and be 1464 later than . Values of in the 1465 future are valid. This parameter is of type dateTime and 1466 compliant to [RFC3339]. Implementations must support time 1467 zones."; 1468 } 1469 } 1471 /* 1472 * RPCs 1473 */ 1475 rpc create-subscription { 1476 description 1477 "This operation initiates an event notification subscription 1478 that will send asynchronous event notifications to the 1479 initiator of the command until the subscription terminates."; 1480 input { 1481 uses subscription-info-5277; 1482 } 1483 } 1484 } 1486 1488 9.3. Data Model for RFC5277-bis Extensions 1490 1491 file "ietf-event-notifications@2016-06-15.yang" 1492 module ietf-event-notifications { 1493 namespace 1494 "urn:ietf:params:xml:ns:yang:ietf-event-notifications"; 1495 // TODO: examples in the draft consider the namespace below 1496 // which follows the namespace format in 5277 1497 // "urn:ietf:params:xml:ns:netconf:notification:1.1"; 1498 prefix notif-bis; 1500 import ietf-inet-types { 1501 prefix inet; 1502 } 1503 import ietf-5277-netmod { 1504 prefix netmod-notif; 1505 } 1506 import ietf-5277-netconf { 1507 prefix notif; 1509 } 1510 import ietf-interfaces { 1511 prefix if; 1512 } 1514 organization "IETF"; 1515 contact 1516 "WG Web: 1517 WG List: 1519 WG Chair: Mahesh Jethanandani 1520 1522 WG Chair: Mehmet Ersue 1523 1525 Editor: Alberto Gonzalez Prieto 1526 1528 Editor: Alexander Clemm 1529 1531 Editor: Eric Voit 1532 1534 Editor: Einar Nilsen-Nygaard 1535 1537 Editor: Ambika Prasad Tripathy 1538 "; 1540 description 1541 "This module contains conceptual YANG specifications 1542 for NETCONF Event Notifications."; 1544 revision 2016-06-15 { 1545 description 1546 "Initial version. Model for NETCONF Notifications (bis)"; 1547 reference 1548 "RFC XXXX: NETCONF Event Notifications"; 1549 } 1551 /* 1552 * FEATURES 1553 */ 1555 feature json { 1556 description 1557 "This feature indicates that JSON encoding of notifications 1558 is supported."; 1559 } 1561 feature configured-subscriptions { 1562 description 1563 "This feature indicates that management plane configuration 1564 of subscription is supported."; 1565 } 1567 /* 1568 * IDENTITIES 1569 */ 1571 /* Identities for subscription results */ 1572 identity subscription-result { 1573 description 1574 "Base identity for RPC responses to requests surrounding 1575 management (e.g. creation, modification, deletion) of 1576 subscriptions."; 1577 } 1579 identity ok { 1580 base subscription-result; 1581 description 1582 "OK - RPC was successful and was performed as requested."; 1583 } 1585 identity error { 1586 base subscription-result; 1587 description 1588 "RPC was not successful. 1589 Base identity for error return codes."; 1590 } 1592 identity error-no-such-subscription { 1593 base error; 1594 description 1595 "A subscription with the requested subscription ID 1596 does not exist."; 1597 } 1599 identity error-no-such-option { 1600 base error; 1601 description 1602 "A requested parameter setting is not supported."; 1603 } 1604 identity error-insufficient-resources { 1605 base error; 1606 description 1607 "The server has insufficient resources to support the 1608 subscription as requested."; 1609 } 1611 identity error-configured-subscription { 1612 base error; 1613 description 1614 "Cannot apply RPC to a configured subscription, i.e. 1615 to a subscription that was not established via RPC."; 1616 } 1618 identity error-other { 1619 base error; 1620 description 1621 "An unspecified error has occurred (catch all)."; 1622 } 1624 /* Identities for subscription stream status */ 1625 identity subscription-stream-status { 1626 description 1627 "Base identity for the status of subscriptions and 1628 datastreams."; 1629 } 1631 identity active { 1632 base subscription-stream-status; 1633 description 1634 "Status is active and healthy."; 1635 } 1637 identity inactive { 1638 base subscription-stream-status; 1639 description 1640 "Status is inactive, for example outside the 1641 interval between start time and stop time."; 1642 } 1644 identity suspended { 1645 base subscription-stream-status; 1646 description 1647 "The status is suspended, meaning that the push server 1648 is currently unable to provide the negotiated updates 1649 for the subscription."; 1650 } 1651 identity in-error { 1652 base subscription-stream-status; 1653 description 1654 "The status is in error or degraded, meaning that 1655 stream and/or subscription is currently unable to provide 1656 the negotiated notifications."; 1657 } 1659 /* Identities for subscription errors */ 1660 identity subscription-errors { 1661 description 1662 "Base identity for subscription error status. 1663 This identity is not to be confused with error return 1664 codes for RPCs"; 1665 } 1667 identity internal-error { 1668 base subscription-errors; 1669 description 1670 "Subscription failures caused by server internal error."; 1671 } 1673 identity no-resources { 1674 base subscription-errors; 1675 description 1676 "Lack of resources, e.g. CPU, memory, bandwidth"; 1677 } 1679 identity subscription-deleted { 1680 base subscription-errors; 1681 description 1682 "The subscription was terminated because the subscription 1683 was deleted."; 1684 } 1686 identity other { 1687 base subscription-errors; 1688 description 1689 "Fallback reason - any other reason"; 1690 } 1692 /* Identities for encodings */ 1693 identity encodings { 1694 description 1695 "Base identity to represent data encodings"; 1696 } 1698 identity encode-xml { 1699 base encodings; 1700 description 1701 "Encode data using XML"; 1702 } 1704 identity encode-json { 1705 base encodings; 1706 description 1707 "Encode data using JSON"; 1708 } 1710 /* Identities for transports */ 1711 identity transport { 1712 description 1713 "An identity that represents a transport protocol for event 1714 notifications"; 1715 } 1717 identity netconf { 1718 base transport; 1719 description 1720 "Netconf notifications as a transport."; 1721 } 1723 /* 1724 * TYPEDEFs 1725 */ 1727 typedef subscription-id { 1728 type uint32; 1729 description 1730 "A type for subscription identifiers."; 1731 } 1733 typedef filter-id { 1734 type uint32; 1735 description 1736 "A type to identify filters which can be associated with a 1737 subscription."; 1738 } 1740 typedef subscription-result { 1741 type identityref { 1742 base subscription-result; 1743 } 1744 description 1745 "The result of a subscription operation"; 1746 } 1747 typedef subscription-term-reason { 1748 type identityref { 1749 base subscription-errors; 1750 } 1751 description 1752 "Reason for a server to terminate a subscription."; 1753 } 1755 typedef subscription-susp-reason { 1756 type identityref { 1757 base subscription-errors; 1758 } 1759 description 1760 "Reason for a server to suspend a subscription."; 1761 } 1763 typedef encoding { 1764 type identityref { 1765 base encodings; 1766 } 1767 description 1768 "Specifies a data encoding, e.g. for a data subscription."; 1769 } 1771 typedef subscription-status { 1772 type identityref { 1773 base subscription-stream-status; 1774 } 1775 description 1776 "Specifies the status of a subscription or datastream."; 1777 } 1779 typedef transport-protocol { 1780 type identityref { 1781 base transport; 1782 } 1783 description 1784 "Specifies transport protocol used to send notifications to a 1785 receiver."; 1786 } 1788 typedef push-source { 1789 type enumeration { 1790 enum "interface-originated" { 1791 description 1792 "Notifications will be sent from a specific interface on a 1793 NETCONF server"; 1794 } 1795 enum "address-originated" { 1796 description 1797 "Notifications will be sent from a specific address on a 1798 NETCONF server"; 1799 } 1800 } 1801 description 1802 "Specifies from where notifications will be sourced when 1803 being sent by the NETCONF server."; 1804 } 1806 typedef filter-ref { 1807 type leafref { 1808 path "/notif-bis:filters/notif-bis:filter/notif-bis:filter-id"; 1809 } 1810 description 1811 "This type is used to reference a filter."; 1812 } 1814 /* 1815 * GROUPINGS 1816 */ 1818 grouping subscription-info { 1819 description 1820 "This grouping describes basic information concerning a 1821 subscription."; 1822 uses notif:subscription-info-5277 { 1823 augment "filter-type" { 1824 description 1825 "Post-5277 subscriptions allow references to existing 1826 filters"; 1827 case by-reference { 1828 description 1829 "Incorporate a filter that has been configured 1830 separately."; 1831 leaf filter-ref { 1832 type filter-ref; 1833 description 1834 "References filter which is associated with the 1835 subscription."; 1836 } 1837 } 1838 } 1839 } 1840 leaf encoding { 1841 type encoding; 1842 default "encode-xml"; 1843 description 1844 "The type of encoding for the subscribed data. 1845 Default is XML"; 1846 } 1847 } 1849 grouping push-source-info { 1850 description 1851 "Defines the sender source from which notifications 1852 for a configured subscription are sent."; 1853 choice push-source { 1854 description 1855 "Identifies the egress interface on the Publisher from 1856 which notifications will or are being sent."; 1857 case interface-originated { 1858 description 1859 "When the push source is out of an interface on the 1860 Publisher established via static configuration."; 1861 leaf source-interface { 1862 type if:interface-ref; 1863 description 1864 "References the interface for notifications."; 1865 } 1866 } 1867 case address-originated { 1868 description 1869 "When the push source is out of an IP address on the 1870 Publisher established via static configuration."; 1871 leaf source-vrf { 1872 type uint32 { 1873 range "16..1048574"; 1874 } 1875 description 1876 "Label of the vrf."; 1877 } 1878 leaf source-address { 1879 type inet:ip-address-no-zone; 1880 mandatory true; 1881 description 1882 "The source address for the notifications."; 1883 } 1884 } 1885 } 1886 } 1888 grouping receiver-info { 1889 description 1890 "Defines where and how to deliver notifications for a 1891 configured subscription. This includes 1892 specifying the receiver, as well as defining 1893 any network and transport aspects when sending of 1894 notifications occurs outside of Netconf."; 1895 container receivers { 1896 description 1897 "Set of receivers in a subscription."; 1898 list receiver { 1899 key "address"; 1900 min-elements 1; 1901 description 1902 "A single host or multipoint address intended as a target 1903 for the notifications for a subscription."; 1904 leaf address { 1905 type inet:host; 1906 mandatory true; 1907 description 1908 "Specifies the address for the traffic to reach a 1909 remote host. One of the following must be 1910 specified: an ipv4 address, an ipv6 address, 1911 or a host name."; 1912 } 1913 leaf port { 1914 type inet:port-number; 1915 mandatory true; 1916 description 1917 "This leaf specifies the port number to use for messages 1918 destined for a receiver."; 1919 } 1920 leaf protocol { 1921 type transport-protocol; 1922 default "netconf"; 1923 description 1924 "This leaf specifies the transport protocol used 1925 to deliver messages destined for the receiver."; 1926 } 1927 } 1928 } 1929 } 1931 grouping subscription-response { 1932 description 1933 "Defines the output to the rpc's establish-subscription 1934 and modify-subscription."; 1935 leaf subscription-result { 1936 type subscription-result; 1937 mandatory true; 1938 description 1939 "Indicates whether subscription is operational, 1940 or if a problem was encountered."; 1941 } 1942 choice result { 1943 description 1944 "Depending on the subscription result, different 1945 data is returned."; 1946 case success { 1947 description 1948 "This case is used when the subscription request 1949 was successful and a subscription was created/modified 1950 as a result"; 1951 leaf subscription-id { 1952 type subscription-id; 1953 mandatory true; 1954 description 1955 "Identifier used for this subscription."; 1956 } 1957 } 1958 case no-success { 1959 description 1960 "This case applies when a subscription request 1961 was not successful and no subscription was 1962 created (or modified) as a result. In this case, 1963 information MAY be returned that indicates 1964 suggested parameter settings that would have a 1965 high likelihood of succeeding in a subsequent 1966 establish-subscription or modify-subscription 1967 request."; 1968 uses subscription-info; 1969 } 1970 } 1971 } 1973 /* 1974 * RPCs 1975 */ 1977 rpc establish-subscription { 1978 description 1979 "This RPC allows a subscriber to create 1980 (and possibly negotiate) a subscription on its own behalf. 1981 If successful, the subscription 1982 remains in effect for the duration of the subscriber's 1983 association with the publisher, or until the subscription 1984 is terminated by virtue of a delete-subscription request. 1985 In case an error (as indicated by subscription-result) 1986 is returned, the subscription is 1987 not created. In that case, the RPC output 1988 MAY include suggested parameter settings 1989 that would have a high likelihood of succeeding in a 1990 subsequent create-subscription request."; 1991 input { 1992 uses subscription-info; 1993 } 1994 output { 1995 uses subscription-response; 1996 } 1997 } 1999 rpc modify-subscription { 2000 description 2001 "This RPC allows a subscriber to modify a subscription 2002 that was previously created using create-subscription. 2003 If successful, the subscription 2004 remains in effect for the duration of the subscriber's 2005 association with the publisher, or until the subscription 2006 is terminated by virtue of a delete-subscription request. 2007 In case an error is returned (as indicated by 2008 subscription-result), the subscription is 2009 not modified and the original subscription parameters 2010 remain in effect. In that case, the rpc error response 2011 MAY include suggested parameter settings 2012 that would have a high likelihood of succeeding in a 2013 subsequent modify-subscription request."; 2014 input { 2015 leaf subscription-id { 2016 type subscription-id; 2017 description 2018 "Identifier to use for this subscription."; 2019 } 2020 uses subscription-info; 2021 } 2022 output { 2023 uses subscription-response; 2024 } 2025 } 2027 rpc delete-subscription { 2028 description 2029 "This RPC allows a subscriber to delete a subscription that 2030 was previously created using create-subscription."; 2031 input { 2032 leaf subscription-id { 2033 type subscription-id; 2034 mandatory true; 2035 description 2036 "Identifier of the subscription that is to be deleted. 2037 Only subscriptions that were created using 2038 create-subscription can be deleted via this RPC."; 2039 } 2040 } 2041 output { 2042 leaf subscription-result { 2043 type subscription-result; 2044 mandatory true; 2045 description 2046 "Indicates whether subscription is operational, 2047 or if a problem was encountered."; 2048 } 2049 } 2050 } 2052 /* 2053 * NOTIFICATIONS 2054 */ 2056 notification subscription-started { 2057 netmod-notif:control-plane-notif; 2058 description 2059 "This notification indicates that a subscription has 2060 started and notifications are beginning to be sent. 2061 This notification shall only be sent to receivers 2062 of a subscription; it does not constitute a general-purpose 2063 notification."; 2064 leaf subscription-id { 2065 type subscription-id; 2066 mandatory true; 2067 description 2068 "This references the affected subscription."; 2069 } 2070 uses subscription-info; 2071 } 2073 notification subscription-suspended { 2074 netmod-notif:control-plane-notif; 2075 description 2076 "This notification indicates that a suspension of the 2077 subscription by the server has occurred. No further 2078 notifications will be sent until subscription 2079 resumes. 2080 This notification shall only be sent to receivers 2081 of a subscription; it does not constitute a general-purpose 2082 notification."; 2083 leaf subscription-id { 2084 type subscription-id; 2085 mandatory true; 2086 description 2087 "This references the affected subscription."; 2088 } 2089 leaf reason { 2090 type subscription-susp-reason; 2091 description 2092 "Provides a reason for why the subscription was 2093 suspended."; 2094 } 2095 } 2097 notification subscription-resumed { 2098 netmod-notif:control-plane-notif; 2099 description 2100 "This notification indicates that a subscription that had 2101 previously been suspended has resumed. Notifications 2102 will once again be sent."; 2103 leaf subscription-id { 2104 type subscription-id; 2105 mandatory true; 2106 description 2107 "This references the affected subscription."; 2108 } 2109 } 2111 notification subscription-modified { 2112 netmod-notif:control-plane-notif; 2113 description 2114 "This notification indicates that a subscription has 2115 been modified. Notifications sent from this point 2116 on will conform to the modified terms of the 2117 subscription."; 2118 leaf subscription-id { 2119 type subscription-id; 2120 mandatory true; 2121 description 2122 "This references the affected subscription."; 2123 } 2124 uses subscription-info; 2125 } 2127 notification subscription-terminated { 2128 netmod-notif:control-plane-notif; 2129 description 2130 "This notification indicates that a subscription has been 2131 terminated."; 2132 leaf subscription-id { 2133 type subscription-id; 2134 mandatory true; 2135 description 2136 "This references the affected subscription."; 2137 } 2138 leaf reason { 2139 type subscription-term-reason; 2140 description 2141 "Provides a reason for why the subscription was 2142 terminated."; 2143 } 2144 } 2146 notification added-to-subscription { 2147 netmod-notif:control-plane-notif; 2148 description 2149 "This notification is sent to a receiver when it has been 2150 added to an existing subscription. 2151 Note that if the receiver is added when the subscription 2152 is created, it will receive a subscription-started 2153 notification and no added-to-subscription."; 2154 leaf subscription-id { 2155 type subscription-id; 2156 mandatory true; 2157 description 2158 "This references the affected subscription."; 2159 } 2160 uses subscription-info; 2161 } 2163 notification removed-from-subscription { 2164 netmod-notif:control-plane-notif; 2165 description 2166 "This notification is sent to a receiver when it has been 2167 removed from an existing subscription. 2168 Note that if the subscription is terminated, the receiver 2169 will receive a subscription-terminated notification 2170 and no removed-from-subscription."; 2171 leaf subscription-id { 2172 type subscription-id; 2173 mandatory true; 2174 description 2175 "This references the affected subscription."; 2176 } 2177 } 2178 augment /netmod-notif:replayComplete { 2179 description 2180 "Augmenting the definition in RFC-5277 to include the 2181 subscription identifier defined in 5277-bis"; 2182 leaf subscription-id { 2183 type subscription-id; 2184 description 2185 "This references the affected subscription. 2186 Not present for created subscriptions for backwards 2187 compatibility."; 2188 } 2189 } 2191 augment /netmod-notif:notificationComplete { 2192 description 2193 "Augmenting the definition in RFC-5277 to include the 2194 subscription identifier defined in 5277-bis"; 2195 leaf subscription-id { 2196 type subscription-id; 2197 description 2198 "This references the affected subscription. 2199 Not present for created subscriptions for backwards 2200 compatibility."; 2201 } 2202 } 2204 /* 2205 * DATA NODES 2206 */ 2208 container streams { 2209 config false; 2210 description 2211 "This container contains a leaf list of built-in 2212 streams that are provided by the system."; 2213 leaf-list stream { 2214 type notif:stream; 2215 description 2216 "Identifies the built-in streams that are supported by the 2217 system. Built-in streams are associated with their own 2218 identities, each of which carries a special semantics. 2219 In case configurable custom streams are supported, 2220 as indicated by the custom-stream identity, the configuration 2221 of those custom streams is provided separately."; 2222 } 2223 } 2224 container filters { 2225 description 2226 "This container contains a list of configurable filters 2227 that can be applied to subscriptions. This facilitates 2228 the reuse of complex filters once defined."; 2229 list filter { 2230 key "filter-id"; 2231 description 2232 "A list of configurable filters that can be applied to 2233 subscriptions."; 2234 leaf filter-id { 2235 type filter-id; 2236 description 2237 "An identifier to differentiate between filters."; 2238 } 2239 uses notif:base-filter; 2240 } 2241 } 2242 container subscription-config { 2243 if-feature "configured-subscriptions"; 2244 description 2245 "Contains the list of subscriptions that are configured, 2246 as opposed to established via RPC or other means."; 2247 list subscription { 2248 key "subscription-id"; 2249 description 2250 "Content of a subscription."; 2251 leaf subscription-id { 2252 type subscription-id; 2253 description 2254 "Identifier to use for this subscription."; 2255 } 2256 uses subscription-info; 2257 uses receiver-info { 2258 if-feature "configured-subscriptions"; 2259 } 2260 uses push-source-info { 2261 if-feature "configured-subscriptions"; 2262 } 2263 } 2264 } 2265 container subscriptions { 2266 config false; 2267 description 2268 "Contains the list of currently active subscriptions, 2269 i.e. subscriptions that are currently in effect, 2270 used for subscription management and monitoring purposes. 2271 This includes subscriptions that have been setup via RPC 2272 primitives, e.g. create-subscription, delete-subscription, 2273 and modify-subscription, as well as subscriptions that 2274 have been established via configuration."; 2275 list subscription { 2276 key "subscription-id"; 2277 config false; 2278 description 2279 "Content of a subscription. 2280 Subscriptions can be created using a control channel 2281 or RPC, or be established through configuration."; 2282 leaf subscription-id { 2283 type subscription-id; 2284 description 2285 "Identifier of this subscription."; 2286 } 2288 leaf configured-subscription { 2289 if-feature "configured-subscriptions"; 2290 type empty; 2291 description 2292 "The presence of this leaf indicates that the 2293 subscription originated from configuration, not 2294 through a control channel or RPC."; 2295 } 2297 leaf subscription-status { 2298 type subscription-status; 2299 description 2300 "The status of the subscription."; 2301 } 2302 uses subscription-info; 2303 uses receiver-info { 2304 if-feature "configured-subscriptions"; 2305 } 2306 uses push-source-info { 2307 if-feature "configured-subscriptions"; 2308 } 2309 } 2310 } 2312 augment /netmod-notif:netconf/netmod-notif:streams { 2313 description 2314 "Augmenting the definition in RFC-5277 to so that streams 2315 can opt out the default stream."; 2316 leaf exclude-from-NETCONF-stream { 2317 type empty; 2318 description 2319 "Indicates that the stream should not be part of the 2320 default stream."; 2322 } 2323 } 2325 } 2327 2329 10. Backwards Compatibility 2331 Capabilities are advertised in messages sent by each peer during 2332 session establishment [RFC6241]. Servers supporting the features in 2333 this document must advertise both capabilities 2334 "urn:ietf:params:netconf:capability:notification:1.0" and 2335 "urn:ietf:params:netconf:capability:notification:1.1". 2337 An example of a hello message by a server during session 2338 establishment would be: 2340 2341 2342 2343 urn:ietf:params:xml:ns:netconf:base:1.0 2344 2345 2346 urn:ietf:params:netconf:capability:startup:1.0 2347 2348 2349 urn:ietf:params:netconf:capability:notification:1.0 2350 2351 2352 urn:ietf:params:netconf:capability:notification:1.1 2353 2354 2355 4 2356 2358 Figure 9: Hello message 2360 Clients that only support [RFC5277] recognize capability 2361 "urn:ietf:params:netconf:capability:notification:1.0" and ignore 2362 capability "urn:ietf:params:netconf:capability:notification:1.1". 2363 This allows them interacting with the server as per [RFC5277]. 2364 Clients that support the features in this document recognize both 2365 capabilities. This allows them interacting with the server as per 2366 this document. 2368 Note that to support backwards compatibility, the yang models in this 2369 document include two types of naming conventions. That used in 2371 [RFC5277], e.g., replayComplete; and that commonly used in yang 2372 models, e.g., subscription-started. 2374 11. Security Considerations 2376 The security considerations from the base NETCONF document [RFC6241] 2377 also apply to the notification capability. 2379 The elements are never sent before the transport layer 2380 and the NETCONF layer, including capabilities exchange, have been 2381 established and the manager has been identified and authenticated. 2383 A secure transport must be used and the server must ensure that the 2384 user has sufficient authorization to perform the function they are 2385 requesting against the specific subset of NETCONF content involved. 2386 When a is received that refers to the content defined in this 2387 memo, clients should only be able to view the content for which they 2388 have sufficient privileges. and operations can be considered like deferred , and 2390 the content that different users can access may vary. This different 2391 access is reflected in the that different users are 2392 able to subscribe to. 2394 The contents of notifications, as well as the names of event streams, 2395 may contain sensitive information and care should be taken to ensure 2396 that they are viewed only by authorized users. The NETCONF server 2397 MUST NOT include any content in a notification that the user is not 2398 authorized to view. 2400 If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may 2402 use up system resources. In such a situation, subscriptions can be 2403 terminated by terminating the suspect underlying NETCONF sessions 2404 using the operation. If the client uses , the server can also suspend or terminate subscriptions 2406 with per-subscription granularity. 2408 A subscription could be configured on another receiver's behalf, with 2409 the goal of flooding that receiver with updates. One or more 2410 publishers could be used to overwhelm a receiver, which doesn't even 2411 support subscriptions. Clients that do not want pushed data need 2412 only terminate or refuse any transport sessions from the publisher. 2413 In addition, the NETCONF Authorization Control Model [RFC6536] SHOULD 2414 be used to control and restrict authorization of subscription 2415 configuration. This control models permits specifying per-user 2416 permissions to receive specific event notification types. The 2417 permissions are specified as a set of access control rules. 2419 Note that streams can define additional authorization requirements. 2420 For instance, in [I-D.ietf-netconf-yang-push], each of the elements 2421 in its data plane notifications must also go through access control. 2423 12. Issues that are currently being worked and resolved 2425 12.1. Unresolved and yet-to-be addressed issues 2427 EN1 - Definition of basic set of Stream types. What streams are 2428 provided and what do they contain (includes default 5277 stream). 2430 EN2 - Clarify interplay between filter definitions and different 2431 streams. Includes information in subtrees of event payloads. 2433 EN3 - Mechanisms for diagnostics, e.g. deal with dropped updates, 2434 monitoring when they occur, etc 2436 EN4 - How to allow for seamless integration with non-standard 2437 encodings and transports (like GPB/GRPC). Specify requirements 2438 encoding and transport must meet, provide examples. 2440 EN5 - Along with Netconf-notif, should this draft obsolete 5277 or be 2441 in parallel with it? 2443 EN6 - Stream discovery. Are adjustments needed for maximal transport 2444 independence? 2446 EN7 - Detecting loss of a sequential update notification, and 2447 mechanisms to resend. Implications to transports must be thought 2448 through. 2450 EN8 - Should we have a mandatory transport? 2452 12.2. Agreement in principal 2454 EN9 - Multiple receivers per Configured Subscription is ok. 2456 EN10 - Replay support will be provided for selected stream types 2457 (modify vs. delete) 2459 EN11 - Required layering security requirements/considerations will be 2460 added into the YANG model for Configured Subscriptions. It will be 2461 up to the transport to meet these requirements. 2463 EN12 - Test-only option for a subscription is desired. But it still 2464 needs to be defined. 2466 EN13 - RFC6241 Subtree-filter definition in 5277bis cannot apply to 2467 elements of an event. Must explicitly define how 6241 doesn't apply 2468 filtering within a 5277bis event. 2470 EN14 - Ensure that Configured Subscriptions are fully defined in YANG 2471 model. 2473 12.3. Resolved Issues 2475 EN15 - Term for Dynamic and Static Subscriptions (move to 2476 "Configured") 2478 12.4. Editorial To-Dos 2480 Update examples. Examples are not in synch with the current model. 2482 Remove overlap with transport specifics, specifically NETCONF. The 2483 current draft revision is "self-contained" and assumes NETCONF as a 2484 transport. It does not yet reflect the breakout of transport 2485 mappings into a separate draft. 2487 13. Acknowledgments 2489 For their valuable comments, discussions, and feedback, we wish to 2490 acknowledge Andy Bierman, Yang Geng, Peipei Guo, Susan Hares, Tim 2491 Jenkins, Balazs Lengyel, Kent Watsen, and Guangying Zheng. 2493 14. References 2495 14.1. Normative References 2497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2498 Requirement Levels", BCP 14, RFC 2119, 2499 DOI 10.17487/RFC2119, March 1997, 2500 . 2502 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2503 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2504 . 2506 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2507 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2508 . 2510 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2511 the Network Configuration Protocol (NETCONF)", RFC 6020, 2512 DOI 10.17487/RFC6020, October 2010, 2513 . 2515 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2516 and A. Bierman, Ed., "Network Configuration Protocol 2517 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2518 . 2520 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2521 Protocol (NETCONF) Access Control Model", RFC 6536, 2522 DOI 10.17487/RFC6536, March 2012, 2523 . 2525 14.2. Informative References 2527 [I-D.ietf-netconf-restconf] 2528 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2529 Protocol", I-D draft-ietf-netconf-restconf-13, April 2016. 2531 [I-D.ietf-netconf-yang-push] 2532 Clemm, Alexander., Gonzalez Prieto, Alberto., Voit, Eric., 2533 Tripathy, A., and E. Nilsen-Nygaard, "Subscribing to YANG 2534 datastore push updates", June 2016, 2535 . 2538 Authors' Addresses 2540 Alberto Gonzalez Prieto 2541 Cisco Systems 2543 Email: albertgo@cisco.com 2545 Alexander Clemm 2546 Cisco Systems 2548 Email: alex@cisco.com 2550 Eric Voit 2551 Cisco Systems 2553 Email: evoit@cisco.com 2555 Einar Nilsen-Nygaard 2556 Cisco Systems 2558 Email: einarnn@cisco.com 2559 Ambika Prasad Tripathy 2560 Cisco Systems 2562 Email: ambtripa@cisco.com 2564 Sharon Chisholm 2565 Ciena 2567 Email: schishol@ciena.com 2569 Hector Trevino 2570 Cisco Systems 2572 Email: htrevino@cisco.com