idnits 2.17.1 draft-ietf-netconf-subscribed-notifications-03.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 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 352 has weird spacing: '...er-type eve...' == Line 367 has weird spacing: '...er-type eve...' == Line 429 has weird spacing: '...er-type eve...' == Line 449 has weird spacing: '...er-type eve...' == Line 453 has weird spacing: '...-result sub...' == (9 more instances...) -- The document date (July 2, 2017) is 2482 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) == Outdated reference: A later version (-09) exists of draft-ietf-netconf-rfc6536bis-01 -- Possible downref: Normative reference to a draft: ref. 'RFC6536bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPATH' -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF E. Voit 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Clemm 5 Expires: January 3, 2018 Huawei 6 A. Gonzalez Prieto 7 VMWare 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 July 2, 2017 13 Custom Subscription to Event Notifications 14 draft-ietf-netconf-subscribed-notifications-03 16 Abstract 18 This document defines capabilities and operations for the customized 19 establishment of subscriptions upon a publisher's event streams. 20 Also defined are delivery mechanisms for instances of the resulting 21 events. Effectively this allows a subscriber to request and receive 22 a continuous, custom influx of publisher generated information. 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 January 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 62 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Event Streams . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Subscription State Model at the Publisher . . . . . . . . 7 66 3. Data Model Trees . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Establishing a Subscription . . . . . . . . . . . . . . . 12 69 4.2. Modifying a Subscription . . . . . . . . . . . . . . . . 13 70 4.3. Deleting a Subscription . . . . . . . . . . . . . . . . . 13 71 4.4. Killing a Subscription . . . . . . . . . . . . . . . . . 14 72 5. Configured Subscriptions . . . . . . . . . . . . . . . . . . 14 73 5.1. Establishing a Configured Subscription . . . . . . . . . 15 74 5.2. Modifying a Configured Subscription . . . . . . . . . . . 17 75 5.3. Deleting a Configured Subscription . . . . . . . . . . . 17 76 6. Event (Data Plane) Notifications . . . . . . . . . . . . . . 18 77 7. Subscription State Notifications . . . . . . . . . . . . . . 19 78 7.1. subscription-started . . . . . . . . . . . . . . . . . . 19 79 7.2. subscription-modified . . . . . . . . . . . . . . . . . . 20 80 7.3. subscription-terminated . . . . . . . . . . . . . . . . . 20 81 7.4. subscription-suspended . . . . . . . . . . . . . . . . . 20 82 7.5. subscription-resumed . . . . . . . . . . . . . . . . . . 20 83 7.6. notification-complete . . . . . . . . . . . . . . . . . . 20 84 7.7. replay-complete . . . . . . . . . . . . . . . . . . . . . 21 85 8. Administrative Functions . . . . . . . . . . . . . . . . . . 21 86 8.1. Subscription Monitoring . . . . . . . . . . . . . . . . . 21 87 8.2. Capability Advertisement . . . . . . . . . . . . . . . . 21 88 8.3. Event Stream Discovery . . . . . . . . . . . . . . . . . 22 89 9. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 10. Considerations . . . . . . . . . . . . . . . . . . . . . . . 44 91 10.1. Implementation Considerations . . . . . . . . . . . . . 44 92 10.2. Security Considerations . . . . . . . . . . . . . . . . 44 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 45 96 12.2. Informative References . . . . . . . . . . . . . . . . . 46 98 Appendix A. Relationships to other drafts . . . . . . . . . . . 47 99 A.1. ietf-netconf-netconf-event-notif . . . . . . . . . . . . 47 100 A.2. ietf-netconf-restconf-notif . . . . . . . . . . . . . . . 47 101 A.3. ietf-netconf-yang-push . . . . . . . . . . . . . . . . . 48 102 A.4. voit-notifications2 . . . . . . . . . . . . . . . . . . . 48 103 Appendix B. Issues that are currently being worked and resolved 48 104 Appendix C. Changes between revisions . . . . . . . . . . . . . 48 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 107 1. Introduction 109 This document defines capabilities and operations for the customized 110 establishment of subscriptions upon system generated event streams. 111 Also defined are asynchronous delivery mechanisms, where the 112 resulting event instances are placed within notification messages and 113 sent to targeted receivers. Effectively this enables a "Subscribe 114 then Publish" capability where the customized information needs of 115 each target receiver are understood by the publisher before events 116 are marshalled and pushed. The receiver then gets a continuous, 117 custom influx of publisher generated events. 119 While the functionality defined in this document is transport- 120 agnostic, subscription control plane operations bindings exist for 121 both NETCONF [RFC6241] and RESTCONF [RFC8040]. In addition, bindings 122 for the pushed event instances have been defined for protocols such 123 as NETCONF and HTTP2 [RFC7540]. For specifics on these bindings see 124 [I-D.ietf-netconf-event-notif]) and 125 [I-D.ietf-netconf-restconf-notif]. 127 The capabilities and operations defined in this document with 128 implemented in conjunction with [I-D.ietf-netconf-event-notif] are 129 intended to obsolete [RFC5277]. 131 1.1. Motivation 133 There are various [RFC5277] limitations, many of which have been 134 exposed in [RFC7923] which needed to be solved. Key capabilities 135 supported by this document include: 137 o multiple subscriptions on a single transport session 139 o support for dynamic and statically configured subscriptions 141 o modification of an existing subscription 143 o operational counters and instrumentation 145 o negotiation of subscription parameters 146 o promise theory based interaction model 148 o state change notifications (e.g., publisher driven suspension, 149 parameter modification) 151 o independence from transport protocol 153 1.2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 Configured subscription: A subscription installed via a configuration 160 interface which persists across reboots. 162 Dynamic subscription: A subscription agreed between subscriber and 163 publisher created via RPC subscription state signaling messages. 165 Event: An occurrence of something that may be of interest. (e.g., a 166 configuration change, a fault, a change in status, crossing a 167 threshold, or an external input to the system.) 169 Event notification: A set of information intended for a Receiver 170 indicating that one or more Event(s) have occurred. Details of the 171 Event(s) may be included within the Notification. 173 Filter: Evaluation and/or selection criteria, which may be applied 174 against a targeted set of objects or events in a subscription. 175 Information traverses the filter only if specified filter criteria 176 are met. 178 NACM: NETCONF Access Control Model. 180 Publisher: An entity responsible for streaming event notifications 181 per the terms of a Subscription. 183 Receiver: A target to which a publisher pushes event notifications. 184 For dynamic subscriptions, the receiver and subscriber are the same 185 entity. 187 Stream (also referred to as "event stream"): A continuous ordered set 188 of events grouped under an explicit criteria. 190 Subscriber: An entity able to request and negotiate a contract for 191 the generation and push of event notifications from a publisher. 193 Subscription: A contract with a publisher, stipulating which 194 information one or more receivers wish to have pushed from the 195 publisher without the need for further solicitation. 197 1.3. Solution Overview 199 This document describes a transport protocol-agnostic mechanism for 200 subscribing to and receiving event notifications from an event 201 publisher. This mechanism is through the use a subscription. 203 Two types of subscriptions are supported: 205 1. Dynamic subscriptions, where a subscriber initiates a 206 subscription negotiation with a publisher via RPC. If the 207 publisher wants to serve this request, it accepts it, and then 208 starts pushing event notifications. If the publisher does not 209 wish to serve it as requested, then an error response is 210 returned. This response may include hints at subscription 211 parameters which would have been accepted. 213 2. Configured subscriptions, which allows the management of 214 subscriptions via a configuration interface so that a publisher 215 can send event notifications to configured receiver(s). Support 216 for this capability is optional. 218 Additional characteristics differentiating configured from dynamic 219 subscriptions include: 221 o The lifetime of a dynamic subscription is bounded by transport 222 session used to establish it. For connection-oriented stateful 223 transport like NETCONF, the loss of the transport session will 224 result in the immediate termination of associated dynamic 225 subscriptions. For connectionless or stateless transports like 226 HTTP, it is the lack of receipt acknowledgement of a sequential 227 set of notification messages and/or keep-alives which will 228 terminate dynamic subscriptions. The lifetime of a configured 229 subscription is driven by relevent configuration being present on 230 the running configuration. This implies configured subscriptions 231 persist across reboots, and persist even when transport is 232 unavailable. 234 o Configured subscriptions can be modified by any configuration 235 client with write permission on the configuration of the 236 subscription. Dynamic subscriptions can only be modified via an 237 RPC request made upon the original subscribing transport session. 239 Note that there is no mixing-and-matching of dynamic and configured 240 subscriptions. Specifically, a configured subscription cannot be 241 modified or deleted using RPC. Similarly, a subscription established 242 via RPC cannot be modified through configuration operations. 244 The publisher may decide to terminate a dynamic subscription at any 245 time. Similarly, it may decide to temporarily suspend the sending of 246 event notifications for either configured or dynamic subscriptions. 247 Such termination or suspension may be driven by the publisher running 248 out of resources to serve the subscription, or by internal errors on 249 the publisher. 251 2. Solution 253 2.1. Event Streams 255 An event stream is a named entity on a publisher which exposes a 256 continuously updating set of events. Each event stream is available 257 for subscription. It is out of the scope of this document to 258 identify a) how streams are defined, b) how events are defined/ 259 generated, and c) how events are assigned to streams. 261 There are two standardized event streams within this document: 262 NETCONF and SYSLOG. The NETCONF event stream contains all NETCONF 263 XML event information supported by the publisher, except for where it 264 has been explicitly indicated that this the event must be excluded 265 from the NETCONF stream. The SYSLOG event stream mirrors the 266 discrete set entries which are concurrently being placed into a 267 device's local Syslog. Beyond these two, additional streams can be 268 added via model augmentation. 270 As events are raised by a system, they may be assigned to one or more 271 streams. The event is distributed to receivers where: (1) a 272 subscription includes the identified stream, and (2) subscription 273 filtering allows the event to traverse. 275 If access control permissions are in use to secure publisher content, 276 then for notifications to be sent to a receiver, that receiver must 277 be allowed access to all the events on the stream. If permissions 278 change during the lifecycle of the of a subscription, then events 279 must be sent or restricted accordingly. This can be be done by re- 280 establishing a subscription with the updated permissions, or by 281 seamlessly updating the permissions of an existing subscription. 283 2.2. Filters 285 A publisher implementation MUST support the ability to perform 286 filtering of notification records. Two filtering syntaxes supported 287 are [XPATH] and subtree [RFC6241]. Events which evaluate to "true", 288 or return a non-null selection as a result of the evaluation by the 289 filter must traverse the filter in their entirety. A subset of 290 information is never stripped from within the event. 292 2.3. Subscription State Model at the Publisher 294 Below is the state machine of a subscription for the publisher for a 295 dyanmic subscription. It is important to note that such a 296 subscription doesn't exist at the publisher until it is accepted and 297 made active. The mere request by a subscriber to establish a 298 subscription is insufficient for that asserted subscription to be 299 externally visible via this state machine. 301 .-------. 302 | start | 303 '-------' 304 | 305 establish 306 | 307 | .----------modify------------. 308 v v ' 309 .-----------. .-----------. 310 .--------. | |-----suspend------->| | 311 modify '| active | | suspended | 312 '--------->| |<----resume---------| | 313 '-----------' '-----------' 314 | | 315 delete/kill delete/kill 316 | | 317 v | 318 .-------. | 319 | end |<---------------------------' 320 '-------' 322 Figure 1: Subscription states at publisher 324 Of interest in this state machine are the following: 326 o Successful establish or modify RPCs put the subscription into an 327 active state. 329 o Failed modify RPCs will leave the subscription in its previous 330 state, with no visible change to any streaming updates. 332 o A delete or kill RPC will end the subscription. 334 o Suspend and resume state changes are driven by internal process 335 and prioritization. There are no external controls over suspend 336 and resume. 338 An equivalent state machine exists for configured subscriptions. 339 However the transition between states is via configuration operations 340 rather than via RPC. 342 3. Data Model Trees 344 module: ietf-subscribed-notifications 345 +--ro streams 346 | +--ro stream* stream 347 +--rw filters 348 | +--rw filter* [identifier] 349 | +--rw identifier filter-id 350 | +--rw (filter-type)? 351 | +--:(event-filter) 352 | +--rw event-filter-type event-filter-type 353 | +--rw event-filter 354 +--rw subscription-config {configured-subscriptions}? 355 | +--rw subscription* [identifier] 356 | +--rw identifier subscription-id 357 | +--rw encoding? encoding 358 | +--rw (target) 359 | | +--:(event-stream) 360 | | +--rw stream stream 361 | +--rw (applied-filter) 362 | | +--:(by-reference) 363 | | | +--rw filter-ref filter-ref 364 | | +--:(within-subscription) 365 | | +--rw (filter-type)? 366 | | +--:(event-filter) 367 | | +--rw event-filter-type event-filter-type 368 | | +--rw event-filter 369 | +--rw stop-time? yang:date-and-time 370 | +--rw receivers 371 | | +--rw receiver* [address port] 372 | | +--rw address inet:host 373 | | +--rw port inet:port-number 374 | | +--rw protocol? transport-protocol 375 | +--rw (notification-origin)? 376 | +--:(interface-originated) 377 | | +--rw source-interface? if:interface-ref 378 | +--:(address-originated) 379 | +--rw source-vrf? string 380 | +--rw source-address inet:ip-address-no-zone 381 +--ro subscriptions 382 +--ro subscription* [identifier] 383 +--ro identifier subscription-id 384 +--ro configured-subscription? 385 | empty {configured-subscriptions}? 386 +--ro encoding? encoding 387 +--ro (target) 388 | +--:(event-stream) 389 | +--ro stream stream 390 | +--ro replay-start-time? yang:date-and-time {replay}? 391 +--ro (applied-filter) 392 | +--:(by-reference) 393 | | +--ro filter-ref filter-ref 394 | +--:(within-subscription) 395 | +--ro (filter-type)? 396 | +--:(event-filter) 397 | +--ro event-filter-type event-filter-type 398 | +--ro event-filter 399 +--ro stop-time? yang:date-and-time 400 +--ro (notification-origin)? 401 | +--:(interface-originated) 402 | | +--ro source-interface? if:interface-ref 403 | +--:(address-originated) 404 | +--ro source-vrf? string 405 | +--ro source-address inet:ip-address-no-zone 406 +--ro receivers 407 +--ro receiver* [address port] 408 +--ro address inet:host 409 +--ro port inet:port-number 410 +--ro protocol? transport-protocol 411 +--ro pushed-notifications? yang:counter64 412 +--ro excluded-notifications? yang:counter64 413 +--ro status subscription-status 415 rpcs: 416 +---x establish-subscription 417 | +---w input 418 | | +---w encoding? encoding 419 | | +---w (target) 420 | | | +--:(event-stream) 421 | | | +---w stream stream 422 | | | +---w replay-start-time? yang:date-and-time {replay}? 423 | | +---w (applied-filter) 424 | | | +--:(by-reference) 425 | | | | +---w filter-ref filter-ref 426 | | | +--:(within-subscription) 427 | | | +---w (filter-type)? 428 | | | +--:(event-filter) 429 | | | +---w event-filter-type event-filter-type 430 | | | +---w event-filter 431 | | +---w stop-time? yang:date-and-time 432 | +--ro output 433 | +--ro subscription-result subscription-result 434 | +--ro (result)? 435 | +--:(no-success) 436 | | +--ro filter-failure? string 437 | | +--ro replay-start-time-hint? yang:date-and-time 438 | +--:(success) 439 | +--ro identifier subscription-id 440 +---x modify-subscription 441 | +---w input 442 | | +---w identifier? subscription-id 443 | | +---w (applied-filter) 444 | | | +--:(by-reference) 445 | | | | +---w filter-ref filter-ref 446 | | | +--:(within-subscription) 447 | | | +---w (filter-type)? 448 | | | +--:(event-filter) 449 | | | +---w event-filter-type event-filter-type 450 | | | +---w event-filter 451 | | +---w stop-time? yang:date-and-time 452 | +--ro output 453 | +--ro subscription-result subscription-result 454 | +--ro (result)? 455 | +--:(no-success) 456 | +--ro filter-failure? string 457 +---x delete-subscription 458 | +---w input 459 | | +---w identifier subscription-id 460 | +--ro output 461 | +--ro subscription-result subscription-result 462 +---x kill-subscription 463 +---w input 464 | +---w identifier subscription-id 465 +--ro output 466 +--ro subscription-result subscription-result 468 notifications: 469 +---n replay-complete 470 | +--ro identifier subscription-id 471 +---n notification-complete 472 | +--ro identifier subscription-id 473 +---n subscription-started 474 | +--ro identifier subscription-id 475 | +--ro encoding? encoding 476 | +--ro (target) 477 | | +--:(event-stream) 478 | | +--ro stream stream 479 | | +--ro replay-start-time? yang:date-and-time {replay}? 480 | +--ro (applied-filter) 481 | | +--:(by-reference) 482 | | | +--ro filter-ref filter-ref 483 | | +--:(within-subscription) 484 | | +--ro (filter-type)? 485 | | +--:(event-filter) 486 | | +--ro event-filter-type event-filter-type 487 | | +--ro event-filter 488 | +--ro stop-time? yang:date-and-time 489 +---n subscription-resumed 490 | +--ro identifier subscription-id 491 +---n subscription-modified 492 | +--ro identifier subscription-id 493 | +--ro encoding? encoding 494 | +--ro (target) 495 | | +--:(event-stream) 496 | | +--ro stream stream 497 | | +--ro replay-start-time? yang:date-and-time {replay}? 498 | +--ro (applied-filter) 499 | | +--:(by-reference) 500 | | | +--ro filter-ref filter-ref 501 | | +--:(within-subscription) 502 | | +--ro (filter-type)? 503 | | +--:(event-filter) 504 | | +--ro event-filter-type event-filter-type 505 | | +--ro event-filter 506 | +--ro stop-time? yang:date-and-time 507 +---n subscription-terminated 508 | +--ro identifier subscription-id 509 | +--ro error-id subscription-errors 510 | +--ro filter-failure? string 511 +---n subscription-suspended 512 +--ro identifier subscription-id 513 +--ro error-id subscription-errors 514 +--ro filter-failure? string 516 The top-level decompositions of data model are as follows: 518 o "Streams" contains a list of event streams that are supported by 519 the publisher and against which subscription is allowed. 521 o "Filters" contains a configurable list of filters that can be 522 applied to a subscription. This allows users to reference an 523 existing filter definition as an alternative to defining a filter 524 inline for each subscription. 526 o "Subscription-config" contains the configuration of configured 527 subscriptions. The parameters of each configured subscription are 528 a superset of the parameters of a dynamic subscription and use the 529 same groupings. In addition, the configured subscriptions must 530 also specify intended receivers and may specify the push source 531 from which to send the stream of notification messages. 533 o "Subscriptions" contains a list of all subscriptions on a 534 publisher, both configured and dynamic. It can be used to 535 retrieve information about the subscriptions which a publisher is 536 serving. 538 The data model also contains a number of notifications that allow a 539 publisher to signal information about a subscription. Finally, the 540 data model contains a number of RPC definitions that are used to 541 manage dynamic subscriptions. 543 4. Dynamic Subscriptions 545 Dynamic subscriptions are managed via RPC. 547 4.1. Establishing a Subscription 549 The operation allows a subscriber to request 550 the creation of a subscription via RPC. 552 The input parameters of the operation are: 554 o A stream which identifies the domain of events against which the 555 subscription is applied. 557 o A filter which may reduce the set of events pushed. 559 o The desired encoding for the returned events. By default, updates 560 are encoded using XML. Other encodings may be supported, such as 561 JSON. 563 o An optional stop time for the subscription. 565 o An optional start time which indicates that this subscription is 566 requesting a replay push of events previously generated. 568 If the publisher cannot satisfy the request, 569 it sends a negative element. If the subscriber 570 has no authorization to establish the subscription, the 571 indicates an authorization error. Optionally, 572 the may include one or more hints on 573 alternative input parameters and value which would have resulted in 574 an accepted subscription. 576 Subscription requests must fail if a filter with invalid syntax is 577 provided or if the name of a non-existent stream is provided. 579 4.1.1. Replay Subscription 581 Only viable for dynamic subscriptions made on event streams, if the 582 replay feature is supported, a subscription may request that 583 previously generated events be sent. These would then be followed by 584 events generated after the subscription is established. 586 The presence of a start time is the indicator that there is requested 587 replay for this subscription. The start time must be earlier than 588 the current time. If the start time points earlier than the 589 maintained history of Publisher's event buffer, then the subscription 590 must be rejected. In this case the error response to the request should include a start time supportable by the 592 Publisher. 594 4.2. Modifying a Subscription 596 The operation permits changing the terms of an 597 existing dynamic subscription previously established on that 598 transport session. Subscriptions created by configuration operations 599 cannot be modified via this RPC. Dynamic subscriptions can be 600 modified one or multiple times. If the publisher accepts the 601 requested modifications, it immediately starts sending events based 602 on the new terms, completely ignoring the previous ones. If the 603 publisher rejects the request, the subscription remains as prior to 604 the request. That is, the request has no impact whatsoever. The 605 contents of a such a rejected modification may include one or more 606 hints on alternative input parameters and value which would have 607 resulted in a successfully modified subscription. 609 Dynamic subscriptions established via RPC can only be modified via 610 RPC using the same transport session used to establish that 611 subscription. 613 4.3. Deleting a Subscription 615 The operation permits canceling an existing 616 subscription previously established on that transport session. If 617 the publisher accepts the request, it immediately stops sending 618 events for the subscription. If the publisher rejects the request, 619 all subscriptions remain as prior to the request. That is, the 620 request has no impact whatsoever. 622 Subscriptions established via RPC can only be deleted via RPC using 623 the same transport session used for subscription establishment. 624 Configured subscriptions cannot be deleted using RPCs. Instead, 625 configured subscriptions are deleted as part of regular configuration 626 operations. Publishers MUST reject any RPC attempt to delete 627 configured subscriptions. 629 4.4. Killing a Subscription 631 The operation permits an operator to end any 632 dynamic subscription. The publisher must accept the request for any 633 dynamic subscription, and immediately stop sending events. 635 Configured subscriptions cannot be kill using this RPC. Instead, 636 configured subscriptions are deleted as part of regular configuration 637 operations. Publishers MUST reject any RPC attempt to kill a 638 configured subscription. 640 5. Configured Subscriptions 642 A configured subscription is a subscription installed via a 643 configuration interface. 645 Configured subscriptions persist across reboots, and persist even 646 when transport is unavailable. 648 Configured subscriptions can be modified by any configuration client 649 with write permissions for the configuration of the subscription. 650 Subscriptions can be modified or terminated via the configuration 651 interface at any point of their lifetime. 653 Supporting configured subscriptions is optional and advertised using 654 the "configured-subscriptions" feature. 656 In addition to subscription parameters that apply to dynamic 657 subscriptions, the following additional parameters apply to 658 configured subscriptions: 660 o One or more receiver IP addresses (and corresponding ports) 661 intended as the destination for push updates for each 662 subscription. In addition, the transport protocol for each 663 destination may be defined. 665 o Optional parameters to identify an egress interface or IP address 666 / VRF where a subscription updates should be pushed from the 667 publisher. Where these are not explicitly included, push updates 668 should egress the publisher's default interface having 669 reachability to a receiver. 671 5.1. Establishing a Configured Subscription 673 Configured subscriptions are established using configuration 674 operations against the top-level subtree subscription-config. There 675 are two key differences between RPC and RPC operations 676 for subscription establishment. Firstly, operations 677 install a subscription without question, while RPCs may support 678 negotiation and rejection of requests. Secondly, while RPCs mandate 679 that the subscriber establishing the subscription is the only 680 receiver of the notifications, operations permit 681 specifying receivers independent of any tracked subscriber. Because 682 there is no explicit association with an existing transport session, 683 operations require additional parameters beyond those 684 of dynamic subscriptions to indicate the receivers of the 685 notifications and possibly the source of the notifications such as a 686 specific egress interface. 688 Immediately after a subscription is successfully established, the 689 publisher sends to identified receivers a control-plane notification 690 stating the subscription has been established (subscription-started). 692 It is quite possible that upon configuration, reboot, or even steady- 693 state operations, a transport session may not be currently available 694 to the receiver. In this case, when there is something to transport 695 for an active subscription, transport protocol specific call-home 696 operations will be used to establish the connection. 698 As an example at subscription establishment using over 699 NETCONF, a client may send: 701 704 705 706 707 708 710 711 712 1922 713 714 715 foo 716 717 718
719 1.2.3.4 720
721 722 1234 723 724 725 726 727 728 730 Figure 2: Configured subscription creation via NETCONF 732 if the request is accepted, the publisher would reply: 734 736 737 739 Figure 3: Successful NETCONF configured subscription response 741 if the request is not accepted because the publisher cannot serve it, 742 the publisher may reply: 744 745 746 application 747 resource-denied 748 error 749 750 Temporarily the publisher cannot serve this 751 subscription due to the current workload. 752 753 754 756 Figure 4: A NETCONF response for a failed configured subscription 757 creation 759 5.2. Modifying a Configured Subscription 761 Configured subscriptions can be modified using configuration 762 operations against the top-level subtree subscription-config. 764 Immediately after a subscription is successfully modified, the 765 publisher sends to the existing receivers a control-plane 766 notification stating the subscription has been modified (i.e., 767 subscription-modified). 769 If the modification involved adding and/or removing receivers, those 770 modified receivers are sent control-plane notifications, indicating 771 they have been added (i.e, subscription-started to a specific 772 receiver) or removed (i.e., subscription-terminated to a specific 773 receiver.) 775 5.3. Deleting a Configured Subscription 777 Subscriptions can be deleted using configuration operations against 778 the top-level subtree subscription-config. For example, in RESTCONF: 780 DELETE /subscription-config/subscription=1922 HTTP/1.1 781 Host: example.com 783 HTTP/1.1 204 No Content 784 Date: Sun, 24 Jul 2016 11:23:40 GMT 785 Server: example-server 787 Figure 5: Deleting a configured subscription 789 Immediately after a subscription is successfully deleted, the 790 publisher sends to all receivers of that subscription a control-plane 791 notification stating the subscription has been terminated 792 (subscription-terminated). 794 6. Event (Data Plane) Notifications 796 Once a subscription has been set up, the publisher streams 797 (asynchronously) notifications per the terms of the subscription. We 798 refer to these as event notifications. For dynamic subscriptions set 799 up via RPC operations, event notifications are sent over the session 800 used to establish the subscription. For configured subscriptions, 801 event notifications are sent over the specified connections. 803 An event notification is sent to a receiver when something of 804 interest occurs which is able to traverse all specified filtering and 805 access control criteria. At a minimum this event notification must 806 include: 808 o a subscription-id element of type uint32 which corresponds to the 809 responsible subscription in the Publisher. 811 o a timestamp indicating when event was identified and recorded by 812 the event source. This timestamp must support the indication of 813 time zone. The default timestamp is the eventTime element of type 814 dateTime and compliant to [RFC3339]. Additional timestamp 815 elements and formats are outside the scope of this document. 817 o the event notification content tagged and provided by a source in 818 the publisher. 820 Additional header and event bundling capabilities not defined in this 821 document may transparently be included within the event notification. 823 The following is an example of a compliant event notification. This 824 example extending the example within [RFC7950] section 7.16.3 to 825 include the mandatory information described above: 827 829 2007-09-01T10:00:00Z 830 500 831 832 so-1/2/3.0 833 up 834 down 835 836 838 Figure 6: Data plane notification 840 While this extended [RFC7950] section 7.16 notification provides a 841 valid method of encapsulating subscribed notifications, other 842 transport encapsulation methods are also viable. Improvements may be 843 achieved in some implementations in the following ways: 845 o transport efficiency may be gained by allowing the encapsulation 846 and bundled push of multiple events within the same event 847 notification. 849 o identifiers to designate the current and previous event 850 notification can be used to discover duplicated and dropped 851 notifications 853 o additional header types can be used to pass relevant metadata. 855 o a signature or hash can be included to verify the efficacy of the 856 Publisher 858 This is being explored in NETMOD Notifications 2.0 859 [I-D.voit-notifications2]. 861 7. Subscription State Notifications 863 In addition to data plane notifications, a publisher may send 864 subscription state notifications to indicate to receivers that an 865 event related to the subscription management has occurred. 867 Subscription state notifications are unlike other notifications in 868 that they are not general-purpose notifications. They cannot be 869 filtered out, and they are delivered only to directly impacted 870 receiver(s) of a subscription. The definition of subscription state 871 notifications is distinct from other notifications by making use of a 872 YANG extension tagging them as subscription state notification. 874 Subscription state notifications include indications that a replay of 875 events has been completed, that a subscription is done because an end 876 time has been reached, and that a subscription has started, been 877 modified, been terminated, or been suspended. They are described in 878 the following subsections. 880 7.1. subscription-started 882 This notification indicates that a configured subscription has 883 started and data updates are beginning to be sent. This notification 884 includes the parameters of the subscription, except for the 885 receiver(s) addressing information and push-source information. Note 886 that for RPC-based subscriptions, no such notifications are sent. 888 7.2. subscription-modified 890 This notification indicates that a configured subscription has been 891 modified successfully. This notification includes the parameters of 892 the subscription, except for the receiver(s) addressing information 893 and push-source information. Note that for RPC-based subscriptions, 894 no such notifications are sent. 896 7.3. subscription-terminated 898 This notification indicates that a subscription has been terminated 899 by the publisher. The notification includes the reason for the 900 termination. The publisher may decide to terminate a subscription 901 when it is running out of resources for serving it, an internal error 902 occurs, etc. Publisher-driven terminations are notified to all 903 receivers. The management plane can also terminate configured 904 subscriptions using configuration operations. 906 Subscribers can terminate via RPC subscriptions established via a 907 delete-subscription RPC. In such cases, no subscription-terminated 908 notifications are sent. However if a kill-subscription RPC is sent, 909 or some other event results in the end of a susbcription, then there 910 must be a notification that the subscription has been ended. 912 7.4. subscription-suspended 914 This notification indicates that a publisher has suspended a 915 subscription. The notification includes the reason for the 916 suspension. A possible reason is the lack of resources to serve it. 917 No further data plane notifications will be sent until the 918 subscription resumes. Suspensions are notified to the subscriber (in 919 the case of dynamic subscriptions) and all receivers (in the case of 920 configured subscriptions). 922 7.5. subscription-resumed 924 This notification indicates that a previously suspended subscription 925 has been resumed. Data plane notifications generated in the future 926 will be sent after the subscription terms. These notifications go to 927 the subscriber (in the case of dynamic subscriptions) and all 928 receivers (in the case of configured subscriptions). 930 7.6. notification-complete 932 This notification is sent to indicate that a subscription, which 933 includes a stop time, has finished passing events. 935 7.7. replay-complete 937 This notification indicates that all of the events prior to the 938 current time have been sent. This includes new events generated 939 since the start of the subscription. This notification must not be 940 sent for any other reason. 942 If subscription contains no stop time, or has a stop time which has 943 not been reached, then after the replay-complete notification has 944 been sent events will be sent in sequence as they arise naturally 945 within the system. 947 8. Administrative Functions 949 8.1. Subscription Monitoring 951 Container "subscriptions" in the YANG module below contains the state 952 of all known subscriptions. This includes subscriptions that were 953 established (and have not yet been deleted) using RPCs, as well as 954 subscriptions that have been configured as part of configuration. 955 Using the operation with NETCONF, or subscribing to this 956 information via [I-D.ietf-netconf-yang-push] allows the status of 957 subscriptions to be monitored. 959 Each subscription is represented as a list element. The associated 960 information includes an identifier for the subscription, recevier 961 counter information, the status of the subscription, as well as the 962 various subscription parameters that are in effect. The subscription 963 status indicates the subscription's state with each receiver (e.g., 964 is currently active or suspended). Leaf "configured-subscription" 965 indicates whether the subscription came into being via configuration 966 or via RPC. 968 Subscriptions that were established by RPC are removed from the list 969 once they expire (reaching stop-time) or when they are terminated. 970 Subscriptions that were established by configuration need to be 971 deleted from the configuration by a configuration editing operation 972 even if the stop time has been passed. 974 8.2. Capability Advertisement 976 Capabilities are advertised in messages sent by each peer during 977 session establishment [RFC6241]. Publishers supporting the RPCs and 978 Notifications in this document must advertise the capability 979 "urn:ietf:params:netconf:capability:notification:2.0". 981 If a subscriber only supports [RFC5277] and not this specification, 982 then they will recognize the capability 983 "urn:ietf:params:netconf:capability:notification:1.0" and ignore the 984 capability defined in this document. 986 8.3. Event Stream Discovery 988 A publisher maintains a list of available event streams as 989 operational data. This list contains both standardized and vendor- 990 specific event streams. A client can retrieve this list like any 991 other YANG-defined data, for example using the operation when 992 using NETCONF. 994 9. Data Model 996 file "ietf-subscribed-notifications.yang" 997 module ietf-subscribed-notifications { 998 namespace 999 "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"; 1001 prefix sn; 1003 import ietf-yang-types { 1004 prefix yang; 1005 } 1006 import ietf-inet-types { 1007 prefix inet; 1008 } 1009 import ietf-interfaces { 1010 prefix if; 1011 } 1013 organization "IETF"; 1014 contact 1015 "WG Web: 1016 WG List: 1018 WG Chair: Mahesh Jethanandani 1019 1021 WG Chair: Mehmet Ersue 1022 1024 Editor: Alexander Clemm 1025 1027 Editor: Eric Voit 1028 1030 Editor: Alberto Gonzalez Prieto 1031 1033 Editor: Einar Nilsen-Nygaard 1034 1036 Editor: Ambika Prasad Tripathy 1037 "; 1039 description 1040 "This module contains conceptual YANG specification for 1041 subscribing to events an receiving event notifications."; 1043 revision 2017-05-31 { 1044 description 1045 "Filtering and stream structures updated, replay a feature."; 1046 reference 1047 "draft-ietf-netconf-subscribed-notifications-03"; 1048 } 1050 /* 1051 * FEATURES 1052 */ 1054 feature json { 1055 description 1056 "This feature indicates that JSON encoding of notifications 1057 is supported."; 1058 } 1060 feature configured-subscriptions { 1061 description 1062 "This feature indicates that management plane configuration 1063 of subscription is supported."; 1064 } 1066 feature replay { 1067 description 1068 "This feature indicates that historical event replay is 1069 supported. With replay, it is possible for past events to be 1070 will be streamed in chronological order."; 1071 } 1073 /* 1074 * EXTENSIONS 1075 */ 1077 extension subscription-state-notif { 1078 description 1079 "This statement applies only to notifications. It indicates that 1080 the notification is a subscription state notification (aka OAM 1081 notification). Therefore it does not participate in a regular 1082 event stream and does not need to be specifically subscribed 1083 in order to receive notifications."; 1084 } 1086 /* 1087 * IDENTITIES 1088 */ 1090 /* Identities for streams */ 1091 identity stream { 1092 description 1093 "Base identity to represent a generic stream of event 1094 notifications exposed for subscription by a system."; 1095 } 1096 identity NETCONF { 1097 base stream; 1098 description 1099 "Default NETCONF event stream, containing events based on 1100 notifications defined as YANG modules that are supported by the 1101 system. As a historical reference, this contains the same set 1102 of events in a default RFC-5277 NETCONF stream."; 1103 } 1104 identity SYSLOG { 1105 base stream; 1106 description 1107 "A stream of events mirroring the discrete set entries 1108 concurrently being placed into a device's local Syslog."; 1109 } 1110 identity custom-stream { 1111 base stream; 1112 description 1113 "A supported stream not defined via an identity in this model"; 1114 } 1116 /* Identities for event filters */ 1118 identity event-filter { 1119 description 1120 "Evaluation criteria used as a pass/fail test against events. 1121 If a filter element is specified to look for data of a particular 1122 value, and the data item is not present within a particular event 1123 for its value to be checked against, the event will be filtered 1124 out. For example, if one were to check for 'severity=critical' in 1125 an event where this object does not exist, then the event would 1126 not traverse."; 1127 } 1128 identity subtree-event-filter { 1129 base event-filter; 1130 description 1131 "An RFC-6241 based filter which attempts to select nodes within an 1132 event. After evaluation, the return of a non-empty node set means 1133 that the filter is successully traversed."; 1134 reference "RFC-6241, #5.1"; 1135 } 1136 identity xpath-event-filter { 1137 base event-filter; 1138 description 1139 "A filter applied to an event which follows the syntax specified 1140 in yang:xpath1.0. Success is indicated by either a positive 1141 boolean result, or a non-null node selection."; 1142 reference "XPATH: http://www.w3.org/TR/1999/REC-xpath-19991116"; 1143 } 1145 /* Identities for subscription results */ 1146 identity subscription-result { 1147 description 1148 "Base identity for RPC responses and State Change Notifications 1149 providing information on the creation, modification, deletion of 1150 subscriptions."; 1151 } 1152 identity ok { 1153 base subscription-result; 1154 description 1155 "OK - RPC was successful and was performed as requested."; 1156 } 1157 identity error { 1158 base subscription-result; 1159 description 1160 "Problem with subscription. Base identity for error return 1161 codes for RPCs and State Change Notifications."; 1162 } 1164 /* Identities for subscription stream status */ 1165 identity subscription-status { 1166 description 1167 "Base identity for the status of subscriptions and datastreams."; 1168 } 1169 identity active { 1170 base subscription-status; 1171 description 1172 "Status is active and healthy."; 1173 } 1174 identity inactive { 1175 base subscription-status; 1176 description 1177 "Status is inactive, for example after the stop time, but not 1178 yet deleted from the configuration."; 1179 } 1180 identity suspended { 1181 base subscription-status; 1182 description 1183 "The status is suspended, meaning that the publisher is currently 1184 unable to provide the negotiated updates for the subscription."; 1185 } 1186 identity in-error { 1187 base subscription-status; 1188 description 1189 "The status is in error or degraded, meaning that stream and/or 1190 subscription is currently unable to provide the negotiated 1191 notifications."; 1192 } 1194 /* Identities for subscription errors */ 1196 identity internal-error { 1197 base error; 1198 description 1199 "Error within publisher prohibits operation."; 1200 } 1201 identity suspension-timeout { 1202 base error; 1203 description 1204 "Termination of previously suspended subscription. The publisher 1205 has eliminated the subscription as it exceeded a time limit for 1206 suspension."; 1207 } 1208 identity stream-unavailable { 1209 base error; 1210 description 1211 "Stream does not exist or is not available to the receiver."; 1212 } 1213 identity encoding-unavailable { 1214 base error; 1215 description 1216 "Encoding not supported"; 1217 } 1218 identity replay-unsupported { 1219 base error; 1220 description 1221 "Replay cannot be performed for this subscription. The publisher 1222 does not provide the requested historic information via replay."; 1223 } 1224 identity history-unavailable { 1225 base error; 1226 description 1227 "Replay request too far into the past. The publisher does store 1228 historic information for all parts of requested subscription, but 1229 not back to the requested timestamp."; 1230 } 1231 identity filter-unavailable { 1232 base error; 1233 description 1234 "Referenced filter does not exist"; 1235 } 1236 identity filter-type-unsupported { 1237 base error; 1238 description 1239 "Cannot parse syntax within the filter."; 1240 } 1241 identity filter-unsupported { 1242 base error; 1243 description 1244 "Failure can be from a syntax error, or a syntax too complex to be 1245 processed by the platform. The supplemental info should include 1246 the invalid part of the filter."; 1247 } 1248 identity namespace-unavailable { 1249 base error; 1250 description 1251 "Referenced namespace doesn't exist or is unavailable 1252 to the receiver."; 1253 } 1254 identity no-such-subscription { 1255 base error; 1256 description 1257 "Referenced subscription doesn't exist. This may be as a result of 1258 a non-existent subscription ID, an ID which belongs to another 1259 subscriber, or an ID for acceptable subscription which has been 1260 statically configured."; 1261 } 1262 identity error-insufficient-resources { 1263 base error; 1264 description 1265 "The server has insufficient resources to support the 1266 subscription as requested by an RPC."; 1267 } 1268 identity unsupportable-volume { 1269 base error; 1270 description 1271 "The publisher cannot support the volume of information intended 1272 to be sent for an existing subscription."; 1273 } 1274 identity error-no-such-option { 1275 base error; 1276 description 1277 "A requested parameter setting is not supported."; 1278 } 1280 /* Identities for encodings */ 1281 identity encodings { 1282 description 1283 "Base identity to represent data encodings"; 1284 } 1285 identity encode-xml { 1286 base encodings; 1287 description 1288 "Encode data using XML"; 1289 } 1290 identity encode-json { 1291 base encodings; 1292 description 1293 "Encode data using JSON"; 1294 } 1296 /* Identities for transports */ 1297 identity transport { 1298 description 1299 "An identity that represents a transport protocol for event 1300 notifications"; 1301 } 1302 identity netconf { 1303 base transport; 1304 description 1305 "Netconf notifications as a transport."; 1306 } 1307 identity http2 { 1308 base transport; 1309 description 1310 "HTTP2 notifications as a transport"; 1311 } 1313 /* 1314 * TYPEDEFs 1315 */ 1317 typedef subscription-id { 1318 type uint32; 1319 description 1320 "A type for subscription identifiers."; 1321 } 1323 typedef filter-id { 1324 type uint32; 1325 description 1326 "A type to identify filters which can be associated with a 1327 subscription."; 1328 } 1330 typedef subscription-result { 1331 type identityref { 1332 base subscription-result; 1333 } 1334 description 1335 "The result of a subscription operation"; 1336 } 1338 typedef subscription-errors { 1339 type identityref { 1340 base error; 1341 } 1342 description 1343 "The reason for the failure of an RPC request or the sending 1344 of a subscription suspension or termination notification"; 1345 } 1347 typedef encoding { 1348 type identityref { 1349 base encodings; 1350 } 1351 description 1352 "Specifies a data encoding, e.g. for a data subscription."; 1353 } 1355 typedef event-filter-type { 1356 type identityref { 1357 base event-filter; 1358 } 1359 description 1360 "Specifies a known type of event filter."; 1361 } 1363 typedef subscription-status { 1364 type identityref { 1365 base subscription-status; 1367 } 1368 description 1369 "Specifies the status of a subscription."; 1370 } 1372 typedef transport-protocol { 1373 type identityref { 1374 base transport; 1375 } 1376 description 1377 "Specifies transport protocol used to send notifications to a 1378 receiver."; 1379 } 1381 typedef notification-origin { 1382 type enumeration { 1383 enum "interface-originated" { 1384 description 1385 "Notifications will be sent from a specific interface on a 1386 publisher"; 1387 } 1388 enum "address-originated" { 1389 description 1390 "Notifications will be sent from a specific address on a 1391 publisher"; 1392 } 1393 } 1394 description 1395 "Specifies from where notifications will be sourced when 1396 being sent by the publisher."; 1397 } 1399 typedef stream { 1400 type identityref { 1401 base stream; 1402 } 1403 description 1404 "Specifies a system-provided datastream."; 1405 } 1407 typedef filter-ref { 1408 type leafref { 1409 path "/sn:filters/sn:filter/sn:identifier"; 1410 } 1411 description 1412 "This type is used to reference a filter."; 1413 } 1414 /* 1415 * GROUPINGS 1416 */ 1418 grouping base-filter { 1419 description 1420 "This grouping defines the base for filters for notification 1421 events."; 1422 choice filter-type { 1423 description 1424 "A filter needs to be a single filter of a given type. Mixing 1425 and matching of multiple filters does not occur at the level of 1426 this grouping."; 1427 case event-filter { 1428 leaf event-filter-type { 1429 type event-filter-type; 1430 mandatory true; 1431 description 1432 "A filter needs to be a known and understood syntax if it is 1433 to be interpretable by a device."; 1434 } 1435 anyxml event-filter { 1436 mandatory true; 1437 description 1438 "Event stream evaluation criteria encoded in a syntax of a 1439 supported type of filter. If the filter is applied 1440 against an event stream and there is a non-empty or 1441 positive result, the event is passed along."; 1442 } 1443 } 1444 } 1445 } 1447 grouping subscription-policy-non-modifiable { 1448 description 1449 "This grouping describes the information in a subscription which 1450 should not change during the life of the subscription."; 1451 leaf encoding { 1452 type encoding; 1453 default "encode-xml"; 1454 description 1455 "The type of encoding for the subscribed data. Default is XML"; 1456 } 1457 choice target { 1458 mandatory true; 1459 description 1460 "A filter must be applied against some source of information. 1461 This identifies the target for the filter."; 1463 case event-stream { 1464 leaf stream { 1465 type stream; 1466 mandatory true; 1467 description 1468 "Indicates a stream of events against which to apply 1469 a filter."; 1470 } 1471 } 1472 } 1473 } 1475 grouping subscription-policy-modifiable { 1476 description 1477 "This grouping describes all objects which may be changed 1478 in a subscription via an RPC."; 1479 choice applied-filter { 1480 mandatory true; 1481 description 1482 "A filter must be applied to a subscription. And that filter 1483 will come either referenced from a global list, or be provided 1484 within the subscription itself."; 1485 case by-reference { 1486 description 1487 "Incorporate a filter that has been configured separately."; 1488 leaf filter-ref { 1489 type filter-ref; 1490 mandatory true; 1491 description 1492 "References an existing filter which is to be applied to 1493 the subscription."; 1494 } 1495 } 1496 case within-subscription { 1497 uses base-filter; 1498 description 1499 "Local definition allows a filter to have the same lifecycle 1500 as the subscription."; 1501 } 1502 } 1503 leaf stop-time { 1504 type yang:date-and-time; 1505 description 1506 "Identifies a time after which notification events should not 1507 be sent. If stop-time is not present, the notifications will 1508 continue until the subscription is terminated. If 1509 replay-start-time exists, stop-time must for a subsequent time. 1510 If replay-start-time doesn't exist, stop-time must for a future 1511 time."; 1512 } 1513 } 1515 grouping subscription-policy { 1516 description 1517 "This grouping describes information concerning a subscription."; 1518 uses subscription-policy-non-modifiable { 1519 augment target/event-stream { 1520 description 1521 "Adds additional objects which must be set just by RPC."; 1522 leaf replay-start-time { 1523 if-feature "replay"; 1524 type yang:date-and-time; 1525 description 1526 "Used to trigger the replay feature and indicate that the 1527 replay should start at the time specified. If 1528 replay-start-time is not present, this is not a replay 1529 subscription and event pushes should start immediately. It 1530 is never valid to specify start times that are later than 1531 or equal to the current time."; 1532 } 1533 } 1534 } 1535 uses subscription-policy-modifiable; 1536 } 1538 grouping notification-origin-info { 1539 description 1540 "Defines the sender source from which notifications for a 1541 configured subscription are sent."; 1542 choice notification-origin { 1543 description 1544 "Identifies the egress interface on the Publisher from which 1545 notifications will or are being sent."; 1546 case interface-originated { 1547 description 1548 "When the push source is out of an interface on the 1549 Publisher established via static configuration."; 1550 leaf source-interface { 1551 type if:interface-ref; 1552 description 1553 "References the interface for notifications."; 1554 } 1555 } 1556 case address-originated { 1557 description 1558 "When the push source is out of an IP address on the 1559 Publisher established via static configuration."; 1560 leaf source-vrf { 1561 type string; 1562 description 1563 "Network instance name for the VRF. This could also have 1564 been a leafref to draft-ietf-rtgwg-ni-model, but that model 1565 is not complete, and might not be implemented on a box."; 1566 } 1567 leaf source-address { 1568 type inet:ip-address-no-zone; 1569 mandatory true; 1570 description 1571 "The source address for the notifications."; 1572 } 1573 } 1574 } 1575 } 1577 grouping receiver-info { 1578 description 1579 "Defines where and how to get notifications for a configured 1580 subscriptions to one or more targeted recipient. This includes 1581 specifying the destination addressing as well as a transport 1582 protocol acceptable to the receiver."; 1583 container receivers { 1584 description 1585 "Set of receivers in a subscription."; 1586 list receiver { 1587 key "address port"; 1588 min-elements 1; 1589 description 1590 "A single host or multipoint address intended as a target 1591 for the notifications for a subscription."; 1592 leaf address { 1593 type inet:host; 1594 mandatory true; 1595 description 1596 "Specifies the address for the traffic to reach a remote 1597 host. One of the following must be specified: an ipv4 1598 address, an ipv6 address, or a host name."; 1599 } 1600 leaf port { 1601 type inet:port-number; 1602 mandatory true; 1603 description 1604 "This leaf specifies the port number to use for messages 1605 destined for a receiver."; 1606 } 1607 leaf protocol { 1608 type transport-protocol; 1609 default "netconf"; 1610 description 1611 "This leaf specifies the transport protocol used 1612 to deliver messages destined for the receiver. Each 1613 protocol may use the address and port information 1614 differently as applicable."; 1615 } 1616 } 1617 } 1618 } 1620 grouping error-identifier { 1621 description 1622 "A code passed back within an RPC response to describe why the RFC 1623 has failed, or within a state change notification to describe why 1624 the change has occurred."; 1625 leaf error-id { 1626 type subscription-errors; 1627 mandatory true; 1628 description 1629 "Identifies the subscription error condition."; 1630 } 1631 } 1633 grouping error-hints { 1634 description 1635 "Objects passed back within an RPC response to describe why the 1636 RFC has failed, or within a state change notification to 1637 describe why the change has occurred."; 1638 leaf filter-failure { 1639 type string; 1640 description 1641 "Information describing where and/or why a provided filter was 1642 unsupportable for a subscription."; 1643 } 1644 } 1646 grouping subscription-response-with-hints { 1647 description 1648 "Defines the output for the establish-subscription and 1649 modify-subscription RPCs."; 1650 leaf subscription-result { 1651 type subscription-result; 1652 mandatory true; 1653 description 1654 "Indicates whether subscription is operational, or if a problem 1655 was encountered."; 1656 } 1657 choice result { 1658 description 1659 "Depending on the subscription result, different data is 1660 returned."; 1661 case no-success { 1662 description 1663 "This case applies when a subscription request was not 1664 successful and no subscription was created (or modified) as a 1665 result. In this case, information MAY be returned that 1666 indicates suggested parameter settings that would have a 1667 high likelihood of succeeding in a subsequent establish- 1668 subscription or modify-subscription request."; 1669 uses error-hints; 1670 } 1671 } 1672 } 1674 /* 1675 * RPCs 1676 */ 1678 rpc establish-subscription { 1679 description 1680 "This RPC allows a subscriber to create (and possibly negotiate) 1681 a subscription on its own behalf. If successful, the 1682 subscription remains in effect for the duration of the 1683 subscriber's association with the publisher, or until the 1684 subscription is terminated. In case an error (as indicated by 1685 subscription-result) is returned, the subscription is not 1686 created. In that case, the RPC output MAY include suggested 1687 parameter settings that would have a high likelihood of 1688 succeeding in a subsequent establish-subscription request."; 1689 input { 1690 uses subscription-policy; 1691 } 1692 output { 1693 uses subscription-response-with-hints { 1694 augment "result" { 1695 description 1696 "Allows information to be passed back as part of a 1697 successful subscription establishment."; 1698 case success { 1699 description 1700 "This case is used when the subscription request was 1701 successful."; 1702 leaf identifier { 1703 type subscription-id; 1704 mandatory true; 1705 description 1706 "Identifier used for this subscription."; 1707 } 1708 } 1709 } 1710 augment "result/no-success" { 1711 description 1712 "Contains establish RPC specific objects which can be 1713 returned as hints for future attempts."; 1714 leaf replay-start-time-hint { 1715 type yang:date-and-time; 1716 description 1717 "If a replay has been requested, but the requested replay 1718 time cannot be honored, this may provide a hint at an 1719 alternate time which may be supportable."; 1720 } 1721 } 1722 } 1723 } 1724 } 1726 rpc modify-subscription { 1727 description 1728 "This RPC allows a subscriber to modify a subscription that was 1729 previously created using establish-subscription. If successful, 1730 the changed subscription remains in effect for the duration of 1731 the subscriber's association with the publisher, or until the 1732 subscription is again modified or terminated. In case an error 1733 is returned (as indicated by subscription-result), the 1734 subscription is not modified and the original subscription 1735 parameters remain in effect. In that case, the rpc error 1736 response MAY include suggested parameter hints that would have 1737 a high likelihood of succeeding in a subsequent 1738 modify-subscription request."; 1739 input { 1740 leaf identifier { 1741 type subscription-id; 1742 description 1743 "Identifier to use for this subscription."; 1744 } 1745 uses subscription-policy-modifiable; 1746 } 1747 output { 1748 uses subscription-response-with-hints; 1749 } 1750 } 1751 rpc delete-subscription { 1752 description 1753 "This RPC allows a subscriber to delete a subscription that 1754 was previously created from by that same subscriber using the 1755 establish-subscription RPC."; 1756 input { 1757 leaf identifier { 1758 type subscription-id; 1759 mandatory true; 1760 description 1761 "Identifier of the subscription that is to be deleted. 1762 Only subscriptions that were created using 1763 establish-subscription can be deleted via this RPC."; 1764 } 1765 } 1766 output { 1767 leaf subscription-result { 1768 type subscription-result; 1769 mandatory true; 1770 description 1771 "Indicates whether subscription has been deleted, or if a 1772 problem was encountered."; 1773 } 1774 } 1775 } 1777 rpc kill-subscription { 1778 description 1779 "This RPC allows an operator to delete a dynamic subscription 1780 without restrictions on the originating subscriber or underlying 1781 transport session."; 1782 input { 1783 leaf identifier { 1784 type subscription-id; 1785 mandatory true; 1786 description 1787 "Identifier of the subscription that is to be deleted. Only 1788 subscriptions that were created using establish-subscription 1789 can be deleted via this RPC."; 1790 } 1791 } 1792 output { 1793 leaf subscription-result { 1794 type subscription-result; 1795 mandatory true; 1796 description 1797 "Indicates whether subscription has been killed, or if a 1798 problem was encountered."; 1800 } 1801 } 1802 } 1804 /* 1805 * NOTIFICATIONS 1806 */ 1808 notification replay-complete { 1809 sn:subscription-state-notif; 1810 description 1811 "This notification is sent to indicate that all of the replay 1812 notifications have been sent. It must not be sent for any other 1813 reason."; 1814 leaf identifier { 1815 type subscription-id; 1816 mandatory true; 1817 description 1818 "This references the affected subscription."; 1819 } 1820 } 1822 notification notification-complete { 1823 sn:subscription-state-notif; 1824 description 1825 "This notification is sent to indicate that a subscription has 1826 finished passing events."; 1827 leaf identifier { 1828 type subscription-id; 1829 mandatory true; 1830 description 1831 "This references the affected subscription."; 1832 } 1833 } 1835 notification subscription-started { 1836 sn:subscription-state-notif; 1837 description 1838 "This notification indicates that a subscription has started and 1839 notifications are beginning to be sent. This notification shall 1840 only be sent to receivers of a subscription; it does not 1841 constitute a general-purpose notification."; 1842 leaf identifier { 1843 type subscription-id; 1844 mandatory true; 1845 description 1846 "This references the affected subscription."; 1847 } 1848 uses subscription-policy; 1849 } 1851 notification subscription-resumed { 1852 sn:subscription-state-notif; 1853 description 1854 "This notification indicates that a subscription that had 1855 previously been suspended has resumed. Notifications will once 1856 again be sent."; 1857 leaf identifier { 1858 type subscription-id; 1859 mandatory true; 1860 description 1861 "This references the affected subscription."; 1862 } 1863 } 1865 notification subscription-modified { 1866 sn:subscription-state-notif; 1867 description 1868 "This notification indicates that a subscription has been 1869 modified. Notifications sent from this point on will conform to 1870 the modified terms of the subscription. For completeness, this 1871 notification includes both modified and non-modified aspects of 1872 a subscription "; 1873 leaf identifier { 1874 type subscription-id; 1875 mandatory true; 1876 description 1877 "This references the affected subscription."; 1878 } 1879 uses subscription-policy; 1880 } 1882 notification subscription-terminated { 1883 sn:subscription-state-notif; 1884 description 1885 "This notification indicates that a subscription has been 1886 terminated."; 1887 leaf identifier { 1888 type subscription-id; 1889 mandatory true; 1890 description 1891 "This references the affected subscription."; 1892 } 1893 uses error-identifier; 1894 uses error-hints; 1895 } 1896 notification subscription-suspended { 1897 sn:subscription-state-notif; 1898 description 1899 "This notification indicates that a suspension of the 1900 subscription by the publisher has occurred. No further 1901 notifications will be sent until the subscription resumes. 1902 This notification shall only be sent to receivers of a 1903 subscription; it does not constitute a general-purpose 1904 notification."; 1905 leaf identifier { 1906 type subscription-id; 1907 mandatory true; 1908 description 1909 "This references the affected subscription."; 1910 } 1911 uses error-identifier; 1912 uses error-hints; 1913 } 1915 /* 1916 * DATA NODES 1917 */ 1919 container streams { 1920 config false; 1921 description 1922 "This container contains a leaf list of built-in 1923 streams that are provided by the system."; 1924 leaf-list stream { 1925 type stream; 1926 description 1927 "Identifies the built-in streams that are supported by the 1928 system. Built-in streams are associated with their own 1929 identities, each of which carries a special semantics. 1930 In case configurable custom streams are supported, 1931 as indicated by the custom-stream identity, the configuration 1932 of those custom streams is provided separately."; 1933 } 1934 } 1936 container filters { 1937 description 1938 "This container contains a list of configurable filters 1939 that can be applied to subscriptions. This facilitates 1940 the reuse of complex filters once defined."; 1941 list filter { 1942 key "identifier"; 1943 description 1944 "A list of configurable filters that can be applied to 1945 subscriptions."; 1946 leaf identifier { 1947 type filter-id; 1948 description 1949 "An identifier to differentiate between filters."; 1950 } 1951 uses base-filter; 1952 } 1953 } 1954 container subscription-config { 1955 if-feature "configured-subscriptions"; 1956 description 1957 "Contains the list of subscriptions that are configured, 1958 as opposed to established via RPC or other means."; 1959 list subscription { 1960 key "identifier"; 1961 description 1962 "Content of a subscription."; 1963 leaf identifier { 1964 type subscription-id; 1965 description 1966 "Identifier to use for this subscription."; 1967 } 1968 uses subscription-policy-non-modifiable; 1969 uses subscription-policy-modifiable; 1970 uses receiver-info { 1971 if-feature "configured-subscriptions"; 1972 } 1973 uses notification-origin-info { 1974 if-feature "configured-subscriptions"; 1975 } 1976 } 1977 } 1978 container subscriptions { 1979 config false; 1980 description 1981 "Contains the list of currently active subscriptions, i.e. 1982 subscriptions that are currently in effect, used for subscription 1983 management and monitoring purposes. This includes subscriptions 1984 that have been setup via RPC primitives as well as subscriptions 1985 that have been established via configuration."; 1986 list subscription { 1987 key "identifier"; 1988 config false; 1989 description 1990 "Content of a subscription. Subscriptions can be created using 1991 a control channel or RPC, or be established through 1992 configuration."; 1993 leaf identifier { 1994 type subscription-id; 1995 description 1996 "Identifier of this subscription."; 1997 } 1998 leaf configured-subscription { 1999 if-feature "configured-subscriptions"; 2000 type empty; 2001 description 2002 "The presence of this leaf indicates that the subscription 2003 originated from configuration, not through a control channel 2004 or RPC."; 2005 } 2006 uses subscription-policy; 2007 uses notification-origin-info { 2008 if-feature "configured-subscriptions"; 2009 } 2010 uses receiver-info { 2011 refine receivers/receiver { 2012 min-elements "1"; 2013 } 2014 augment receivers/receiver { 2015 description 2016 "include operational data for receivers."; 2017 leaf pushed-notifications { 2018 type yang:counter64; 2019 description 2020 "Operational data which provides the number of update 2021 notifications pushed to a receiver."; 2022 } 2023 leaf excluded-notifications { 2024 type yang:counter64; 2025 description 2026 "Operational data which provides the number of non- 2027 datastore update notifications explicitly removed via 2028 filtering so that they are not sent to a receiver."; 2029 } 2030 leaf status { 2031 type subscription-status; 2032 mandatory true; 2033 description 2034 "The status of the subscription."; 2035 } 2036 } 2037 } 2038 } 2039 } 2041 } 2042 2044 10. Considerations 2046 10.1. Implementation Considerations 2048 For a deployment including both configured and dynamic subscriptions, 2049 split subscription identifiers into static and dynamic halves. That 2050 way there should not be collisions if the configured subscriptions 2051 attempt to set a subscription-id which might have already been 2052 dynamically allocated. The lower half should be used for configured 2053 subscriptions and upper half for dynamic. 2055 The elements are never sent before the transport 2056 layer, including capabilities exchange, has been established. 2058 It is left to an implementation to determine when to transition 2059 between active and suspended subscription states. However if a 2060 subscription is unable to marshal all intended updates into a 2061 transmitable message in multiple successive intervals, the 2062 subscription should be suspended with the reason "unsupportable- 2063 volume". 2065 10.2. Security Considerations 2067 For dynamic subscriptions the publisher must authenticate and 2068 authorize all RPC requests. 2070 Subscriptions could overload a publisher's CPU. For this reason, the 2071 publisher must have the ability to decline a dynamic subscription 2072 request, and provide the appropriate RPC error response to a 2073 subscriber should the proposed subscription overly deplete the 2074 publisher's resources. 2076 A publisher needs to be able to suspend an existing dynamic or 2077 configured subscription based on capacity constraints. When this 2078 occur, the subscription status must be updated accordingly and the 2079 receivers notified with subscription state notifications. 2081 If a malicious or buggy subscriber sends an unexpectedly large number 2082 of RPCs, this may use up system resources. In such a situation, 2083 subscription interactions may be terminated by terminating the 2084 transport session. 2086 For both configured and dynamic subscriptions the publisher must 2087 authenticate and authorize a receiver via some transport level 2088 mechanism before sending any updates. 2090 A secure transport is highly recommended and the publisher must 2091 ensure that the user has sufficient authorization to perform the 2092 function they are requesting against the specific subset of content 2093 involved. 2095 A publisher MUST NOT include any content in a notification for which 2096 the user has not been authorized. 2098 With configured subscriptions, one or more publishers could be used 2099 to overwhelm a receiver. No push updates should be sent to any 2100 receiver which doesn't even support subscriptions. Subscribers that 2101 do not want pushed data need only terminate or refuse any transport 2102 sessions from the publisher. 2104 The NETCONF Authorization Control Model [RFC6536bis] SHOULD be used 2105 to control and restrict authorization of subscription configuration. 2106 This control models permits specifying per-user permissions to 2107 receive events from specific streams. 2109 Where NACM is available, the NACM "very-secure" tag should be placed 2110 on the RPC so that only administrators can 2111 access. 2113 One subscription id can be used for two or more receivers of the same 2114 configured subscription. But due to the possibility of different 2115 access control permissions per receiver, it should not be assumed 2116 that each receiver is getting identical updates. 2118 11. Acknowledgments 2120 For their valuable comments, discussions, and feedback, we wish to 2121 acknowledge Andy Bierman, Tim Jenkins, Balazs Lengyel, Sharon 2122 Chisholm, Hector Trevino, Susan Hares, Kent Watsen, Michael Scharf, 2123 and Guangying Zheng. 2125 12. References 2127 12.1. Normative References 2129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2130 Requirement Levels", BCP 14, RFC 2119, 2131 DOI 10.17487/RFC2119, March 1997, 2132 . 2134 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2135 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2136 . 2138 [RFC6536bis] 2139 Bierman, A. and M. Bjorklund, "Network Configuration 2140 Protocol (NETCONF) Access Control Model", draft-ietf- 2141 netconf-rfc6536bis-01 (work in progress), March 2017. 2143 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2144 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2145 . 2147 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 2148 Version 1.0", November 1999, 2149 . 2151 12.2. Informative References 2153 [I-D.ietf-netconf-event-notif] 2154 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 2155 Nilsen-Nygaard, E., Tripathy, A., Chisholm, S., and H. 2156 Trevino, "NETCONF support for event notifications", August 2157 2016, . 2160 [I-D.ietf-netconf-restconf-notif] 2161 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- 2162 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and 2163 HTTP transport for event notifications", August 2016, 2164 . 2167 [I-D.ietf-netconf-yang-push] 2168 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 2169 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 2170 Lengyel, "Subscribing to YANG datastore push updates", 2171 June 2017, . 2174 [I-D.voit-notifications2] 2175 Voit, Eric., Clemm, Alexander., Bierman, A., and T. 2176 Jenkins, "YANG Notification Headers and Bundles", July 2177 2017, . 2180 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2181 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2182 . 2184 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2185 and A. Bierman, Ed., "Network Configuration Protocol 2186 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2187 . 2189 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2190 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2191 DOI 10.17487/RFC7540, May 2015, 2192 . 2194 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 2195 for Subscription to YANG Datastores", RFC 7923, 2196 DOI 10.17487/RFC7923, June 2016, 2197 . 2199 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2200 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2201 . 2203 Appendix A. Relationships to other drafts 2205 There are other related drafts which are progressing in the NETCONF 2206 WG. This section details the relationship of this draft to those 2207 others. 2209 A.1. ietf-netconf-netconf-event-notif 2211 The [I-D.ietf-netconf-event-notif] draft augments this subscribed- 2212 notifications specification by defining NETCONF transport specifics. 2213 Included are: 2215 o bindings for RPC communications and Event Notifications over 2216 NETCONF. 2218 o encoded examples 2220 A.2. ietf-netconf-restconf-notif 2222 The [I-D.ietf-netconf-restconf-notif] draft augments this subscribed- 2223 notifications specification by defining transport specific guidance 2224 where some form of HTTP is used underneath. Included are: 2226 o bindings for RPC communications over RESTCONF 2228 o bindings for Event Notifications over HTTP2 and HTTP1.1 2230 o encoded examples 2231 o end-to-end deployment guidance for Call Home and TLS Heartbeat 2233 A.3. ietf-netconf-yang-push 2235 The draft [I-D.ietf-netconf-yang-push] builds upon this subscribed- 2236 notifications specification in order to allow a Publisher to stream 2237 YANG datastore objects. In this case, the application of either an 2238 on-change or periodic triggers upon a YANG Datastore replace the 2239 system generated events within this document. 2241 If you wish to subscribe to a YANG datastore rather than a existing 2242 event stream on a publisher, please refer to this specification. 2244 A.4. voit-notifications2 2246 The draft [I-D.voit-notifications2] is not required to implement this 2247 subscribed-notifications specification. Instead it defines data 2248 plane notification elements which improve the delivered experience. 2249 The following capabilities are specified: 2251 o Defines common encapsulation headers objects to support 2252 functionality such as event severity, message signing, message 2253 loss discovery, message de-duplication, originating process 2254 identification. 2256 o Defines how to bundle multiple event records into a single 2257 notification message. 2259 These are the enhanced capabilies alluded to in the Event (Data 2260 Plane) Notification seciton above. This draft is not yet adopted by 2261 the NETCONF WG. 2263 Appendix B. Issues that are currently being worked and resolved 2265 (To be removed by RFC editor prior to publication) 2267 Issue #6: Data plane notifications and layered headers 2269 How to allow for seamless integration with non-standard encodings and 2270 transports (like GPB/GRPC). Specify requirements encoding and 2271 transport must meet, provide examples. 2273 Appendix C. Changes between revisions 2275 (To be removed by RFC editor prior to publication) 2277 v02 - v03 2278 o RPCs and Notification support is identified by the Notification 2279 2.0 capability. 2281 o Updates to filtering identities and text 2283 o New error type for unsupportable volume of updates 2285 o Text tweaks. 2287 v01 - v02 2289 o Subscription status moved under receiver. 2291 v00 - v01 2293 o Security considerations updated 2295 o Intro rewrite, as well as scattered text changes 2297 o Added Appendix A, to help match this to related drafts in progress 2299 o Updated filtering definitions, and filter types in yang file, and 2300 moved to identities for filter types 2302 o Added Syslog as a stream 2304 o HTTP2 moved in from YANG-Push as a transport option 2306 o Replay made an optional feature for events. Won't apply to 2307 datastores 2309 o Enabled notification timestamp to have different formats. 2311 o Two error codes added. 2313 v01 5277bis - v00 subscribed notifications 2315 o Kill subscription RPC added. 2317 o Renamed from 5277bis to Subscribed Notifications. 2319 o Changed the notification capabilities version from 1.1 to 2.0. 2321 o Extracted create-subscription and other elements of RFC5277. 2323 o Error conditions added, and made specific in return codes. 2325 o Simplified yang model structure for removal of 'basic' grouping. 2327 o Added a grouping for items which cannot be statically configured. 2329 o Operational counters per receiver. 2331 o Subscription-id and filter-id renamed to identifier 2333 o Section for replay added. Replay now cannot be configured. 2335 o Control plane notification renamed to subscription state 2336 notification 2338 o Source address: Source-vrf changed to string, default address 2339 option added 2341 o In yang model: 'info' changed to 'policy' 2343 o Scattered text clarifications 2345 v00 - v01 of 5277bis 2347 o YANG Model changes. New groupings for subscription info to allow 2348 restriction of what is changeable via RPC. Removed notifications 2349 for adding and removing receivers of configured subscriptions. 2351 o Expanded/renamed definitions from event server to publisher, and 2352 client to subscriber as applicable. Updated the definitions to 2353 include and expand on RFC 5277. 2355 o Removal of redundancy with other drafts 2357 o Many other clean-ups of wording and terminology 2359 Authors' Addresses 2361 Eric Voit 2362 Cisco Systems 2364 Email: evoit@cisco.com 2366 Alexander Clemm 2367 Huawei 2369 Email: ludwig@clemm.org 2370 Alberto Gonzalez Prieto 2371 VMWare 2373 Email: agonzalezpri@vmware.com 2375 Einar Nilsen-Nygaard 2376 Cisco Systems 2378 Email: einarnn@cisco.com 2380 Ambika Prasad Tripathy 2381 Cisco Systems 2383 Email: ambtripa@cisco.com