idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 197 has weird spacing: '...pported inva...' == Line 200 has weird spacing: '...ription inva...' == Line 210 has weird spacing: '...ribable inval...' == Line 213 has weird spacing: '...pported opera...' == Line 233 has weird spacing: '...ription estab...' == (3 more instances...) -- The document date (April 29, 2019) is 1823 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: October 31, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 April 29, 2019 13 Dynamic subscription to YANG Events and Datastores over NETCONF 14 draft-ietf-netconf-netconf-event-notifications-18 16 Abstract 18 This document provides a NETCONF binding to the dynamic subscription 19 capability of both subscribed notifications and YANG-Push. 21 RFC Editor note: please replace the four references to pre-RFC 22 normative drafts with the actual assigned RFC numbers. 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 https://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 October 31, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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 (https://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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Compatibility with RFC-5277's create-subscription . . . . . . 3 61 4. Mandatory XML, event stream and datastore support . . . . . . 4 62 5. NETCONF connectivity and the Dynamic Subscriptions . . . . . 4 63 6. Notification Messages . . . . . . . . . . . . . . . . . . . . 4 64 7. Dynamic Subscriptions and RPC Error Responses . . . . . . . . 4 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 11. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 7 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 12.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 73 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 8 74 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 9 75 A.3. Subscription State Notifications . . . . . . . . . . . . 14 76 A.4. Filter Examples . . . . . . . . . . . . . . . . . . . . . 15 77 Appendix B. Changes between revisions . . . . . . . . . . . . . 17 78 B.1. v17 to v18 . . . . . . . . . . . . . . . . . . . . . . . 17 79 B.2. v16 to v17 . . . . . . . . . . . . . . . . . . . . . . . 17 80 B.3. v15 to v16 . . . . . . . . . . . . . . . . . . . . . . . 17 81 B.4. v14 to v15 . . . . . . . . . . . . . . . . . . . . . . . 17 82 B.5. v13 to v14 . . . . . . . . . . . . . . . . . . . . . . . 18 83 B.6. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 18 84 B.7. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 18 85 B.8. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 18 86 B.9. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 18 87 B.10. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 18 88 B.11. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 18 89 B.12. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 18 90 B.13. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 19 91 B.14. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 19 92 B.15. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 This document provides a binding for events streamed over the NETCONF 98 protocol [RFC6241] for dynamic subscriptions as defined in 99 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 100 [I-D.ietf-netconf-yang-push] is itself built upon 101 [I-D.draft-ietf-netconf-subscribed-notifications], this document 102 enables a NETCONF client to request via a dynamic subscription and 103 receive updates from a YANG datastore located on a NETCONF server. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 The following terms are defined in 114 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 115 subscription, event stream, notification message, publisher, 116 receiver, subscriber, subscription. No additional terms are defined. 118 3. Compatibility with RFC-5277's create-subscription 120 A publisher is allowed to concurrently support dynamic subscription 121 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 122 time as [RFC5277]'s "create-subscription" RPC. However a single 123 NETCONF transport session cannot support both this specification and 124 a subscription established by [RFC5277]'s "create-subscription" RPC. 125 To protect against any attempts to use a single NETCONF transport 126 session in this way: 128 o A solution MUST reply with the [RFC6241] "rpc-error" element 129 containing the "error-tag" value of "operation-not-supported" if a 130 "create-subscription" RPC is received on a NETCONF session where 131 an [I-D.draft-ietf-netconf-subscribed-notifications] established 132 subscription exists. 133 o A solution MUST reply with the [RFC6241] "rpc-error" element 134 containing the "error-tag" value of "operation-not-supported" if 135 an "establish-subscription" request has been received on a NETCONF 136 session where the "create-subscription" RPC has successfully 137 [RFC5277] created a subscription. 139 If a publisher supports this specification but not subscriptions via 140 [RFC5277], the publisher MUST NOT advertise 141 "urn:ietf:params:netconf:capability:notification:1.0". 143 4. Mandatory XML, event stream and datastore support 145 The "encode-xml" feature of 146 [I-D.draft-ietf-netconf-subscribed-notifications] MUST be supported. 147 This indicates that XML is a valid encoding for RPCs, state change 148 notifications, and subscribed content. 150 A NETCONF publisher supporting event stream subscription via 151 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 152 "NETCONF" event stream identified in that document. 154 5. NETCONF connectivity and the Dynamic Subscriptions 156 Management of dynamic subscriptions occurs via RPCs as defined in 157 [I-D.ietf-netconf-yang-push] and 158 [I-D.draft-ietf-netconf-subscribed-notifications]. For a dynamic 159 subscription, if the NETCONF session involved with the "establish- 160 subscription" terminates, the subscription MUST be terminated. 162 For a dynamic subscription, any "modify-subscription", "delete- 163 subscription", or "resync-subscription" RPCs MUST be sent using the 164 same NETCONF session upon which the referenced subscription was 165 established. 167 6. Notification Messages 169 Notification messages transported over the NETCONF protocol MUST be 170 encoded in a message as defined within [RFC5277], 171 Section 4. And per [RFC5277]'s "eventTime" object definition, the 172 "eventTime" MUST be populated with the event occurrence time. 174 For dynamic subscriptions, all notification messages MUST use the 175 NETCONF transport session used by the "establish-subscription" RPC. 177 7. Dynamic Subscriptions and RPC Error Responses 179 When an RPC error occurs as defined in 180 [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4.6 and 181 [I-D.ietf-netconf-yang-push] Appendix A, the NETCONF RPC reply MUST 182 include an "rpc-error" element per [RFC6241] with the error 183 information populated as follows: 185 o An "error-type" node of "application". 186 o An "error-tag" node with the value being a string that corresponds 187 to an identity associated with the error. This "error-tag" will 188 come from one of two places. Either it will correspond to the 189 error identities within 191 [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 192 for general subscription errors: 194 error identity uses error-tag 195 ---------------------- -------------- 196 dscp-unavailable invalid-value 197 encoding-unsupported invalid-value 198 filter-unsupported invalid-value 199 insufficient-resources resource-denied 200 no-such-subscription invalid-value 201 replay-unsupported operation-not-supported 203 Or this "error-tag" will correspond to the error identities within 204 [I-D.ietf-netconf-yang-push] Appendix A.1 for subscription errors 205 specific to YANG datastores: 207 error identity uses error-tag 208 ---------------------- -------------- 209 cant-exclude operation-not-supported 210 datastore-not-subscribable invalid-value 211 no-such-subscription-resync invalid-value 212 on-change-unsupported operation-not-supported 213 on-change-sync-unsupported operation-not-supported 214 period-unsupported invalid-value 215 update-too-big too-big 216 sync-too-big too-big 217 unchanging-selection operation-failed 219 o an "error-severity" of "error" (this MAY be included). 220 o an "error-app-tag" node with the value being a string that 221 corresponds to an identity associated with the error, as defined 222 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 223 for general subscriptions, and [I-D.ietf-netconf-yang-push] 224 Appendix A.1, for datastore subscriptions. The specific identity 225 to use depends on the RPC for which the error occurred. Each 226 error identity will be inserted as the "error-app-tag" following 227 the form :. An example of such as valid 228 encoding would be "ietf-subscribed-notifications:no-such- 229 subscription". Viable errors for different RPCs are as follows: 231 RPC use base identity 232 ---------------------- ---------------------------- 233 establish-subscription establish-subscription-error 234 modify-subscription modify-subscription-error 235 delete-subscription delete-subscription-error 236 kill-subscription delete-subscription-error 237 resync-subscription resync-subscription-error 239 o In case of error responses to an "establish-subscription" or 240 "modify-subscription" request there is the option of including an 241 "error-info" node. This node may contain XML-encoded data with 242 hints for parameter settings that might lead to successful RPC 243 requests in the future. Following are the yang-data structures 244 from [I-D.draft-ietf-netconf-subscribed-notifications] and 245 [I-D.ietf-netconf-yang-push] which may be returned: 247 establish-subscription returns hints in yang-data structure 248 ---------------------- ------------------------------------ 249 target: event stream establish-subscription-stream-error-info 250 target: datastore establish-subscription-datastore-error-info 252 modify-subscription returns hints in yang-data structure 253 ---------------------- ------------------------------------ 254 target: event stream modify-subscription-stream-error-info 255 target: datastore modify-subscription-datastore-error-info 257 The yang-data included within "error-info" SHOULD NOT include the 258 optional leaf "error-reason", as such a leaf would be redundant 259 with information that is already placed within the 260 "error-app-tag". 262 In case of an rpc error resulting from a "delete-subscription", 263 "kill-subscription", or "resync-subscription" request, no "error- 264 info" needs to be included, as the "subscription-id" is the only RPC 265 input parameter and no hints regarding this RPC input parameters need 266 to be provided. 268 8. Security Considerations 270 If a malicious or buggy NETCONF subscriber sends a number of 271 establish-subscription requests, then these subscriptions accumulate 272 and may use up system resources. In such a situation, subscriptions 273 MAY be terminated by terminating the underlying NETCONF session. The 274 publisher MAY also suspend or terminate a subset of the active 275 subscriptions on that NETCONF session. 277 9. IANA Considerations 279 This document has no actions for IANA. 281 10. Acknowledgments 283 We wish to acknowledge the helpful contributions, comments, and 284 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 285 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 286 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, 287 Qin Wu, and Guangying Zheng. 289 11. Notes to the RFC Editor 291 This section can be removed by the RFC editor after the requests have 292 been performed. 294 RFC 6241 needs to be updated based on the needs of this draft. 295 RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it 296 identifies RFC 5717, but that was an error fixed after RFC 297 publication). Anyway the current phrasing in RFC-5277 says that a 298 notification message can only be sent after a successful "create- 299 subscription". Therefore the reference text must be modified to also 300 allow notification messages be sent after a successful "establish- 301 subscription". Proposed text for bullet (2) of RFC-6241 would be: 303 (2) The Messages layer provides a simple, transport-independent 304 framing mechanism for encoding RPCs and notifications. 305 Section 4 documents the RPC messages, [RFC5277] documents 306 Notifications sent as a result of a RPC, 307 and [RFC xxxx] documents Notifications sent as a result of 308 an RPC. 310 (where xxxx is replaced with this RFC number) 312 12. References 314 12.1. Normative References 316 [I-D.draft-ietf-netconf-subscribed-notifications] 317 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 318 and E. Nilsen-Nygaard, "Customized Subscriptions to a 319 Publisher's Event Streams", September 2018, 320 . 323 [I-D.ietf-netconf-yang-push] 324 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 325 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 326 Lengyel, "YANG Datastore Subscription", September 2018, 327 . 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 336 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 337 . 339 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 340 and A. Bierman, Ed., "Network Configuration Protocol 341 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 12.2. Informative References 350 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 351 Zhang, "A YANG Data Model for the Virtual Router 352 Redundancy Protocol (VRRP)", RFC 8347, 353 DOI 10.17487/RFC8347, March 2018, 354 . 356 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 357 Version 1.0", November 1999, 358 . 360 Appendix A. Examples 362 This section is non-normative. 364 A.1. Event Stream Discovery 366 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 367 event stream exposes a continuous set of events available for 368 subscription. A NETCONF client can retrieve the list of available 369 event streams from a NETCONF publisher using the "get" operation 370 against the top-level container "/streams" defined in 371 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 373 The following example illustrates the retrieval of the list of 374 available event streams: 376 378 379 380 382 383 384 386 Figure 1: Get streams request 388 After such a request, the NETCONF publisher returns a list of event 389 streams available, as well as additional information which might 390 exist in the container. 392 A.2. Dynamic Subscriptions 394 A.2.1. Establishing Dynamic Subscriptions 396 The following figure shows two successful "establish-subscription" 397 RPC requests as per 398 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 399 is given a subscription "id" of 22, the second, an "id" of 23. 401 +------------+ +-----------+ 402 | Subscriber | | Publisher | 403 +------------+ +-----------+ 404 | | 405 | Capability Exchange | 406 |<---------------------------->| 407 | | 408 | | 409 | establish-subscription | 410 |----------------------------->| (a) 411 | RPC Reply: OK, id = 22 | 412 |<-----------------------------| (b) 413 | | 414 | notification message (for 22)| 415 |<-----------------------------| 416 | | 417 | | 418 | establish-subscription | 419 |----------------------------->| 420 | notification message (for 22)| 421 |<-----------------------------| 422 | RPC Reply: OK, id = 23 | 423 |<-----------------------------| 424 | | 425 | | 426 | notification message (for 22)| 427 |<-----------------------------| 428 | notification message (for 23)| 429 |<-----------------------------| 430 | | 432 Figure 2: Multiple subscriptions over a NETCONF session 434 To provide examples of the information being transported, example 435 messages for interactions (a) and (b) in Figure 2 are detailed below: 437 438 440 441 /ex:foo/ 442 443 NETCONF 444 10 445 446 448 Figure 3: establish-subscription request (a) 450 As NETCONF publisher was able to fully satisfy the request (a), the 451 publisher sends the subscription "id" of the accepted subscription 452 within message (b): 454 456 458 22 459 460 462 Figure 4: establish-subscription success (b) 464 If the NETCONF publisher had not been able to fully satisfy the 465 request, or subscriber has no authorization to establish the 466 subscription, the publisher would have sent an RPC error response. 467 For instance, if the "dscp" value of 10 asserted by the subscriber in 468 Figure 3 proved unacceptable, the publisher may have returned: 470 472 473 application 474 invalid-value 475 error 476 477 ietf-subscribed-notifications:dscp-unavailable 478 479 480 482 Figure 5: an unsuccessful establish subscription 484 The subscriber can use this information in future attempts to 485 establish a subscription. 487 A.2.2. Modifying Dynamic Subscriptions 489 An existing subscription may be modified. The following exchange 490 shows a negotiation of such a modification via several exchanges 491 between a subscriber and a publisher. This negotiation consists of a 492 failed RPC modification request/response, followed by a successful 493 one. 495 +------------+ +-----------+ 496 | Subscriber | | Publisher | 497 +------------+ +-----------+ 498 | | 499 | notification message (for 23)| 500 |<-----------------------------| 501 | | 502 | modify-subscription (id = 23)| 503 |----------------------------->| (c) 504 | RPC error (with hint) | 505 |<-----------------------------| (d) 506 | | 507 | modify-subscription (id = 23)| 508 |----------------------------->| 509 | RPC Reply: OK | 510 |<-----------------------------| 511 | | 512 | notification message (for 23)| 513 |<-----------------------------| 514 | | 516 Figure 6: Interaction model for successful subscription modification 518 If the subscription being modified in Figure 6 is a datastore 519 subscription as per [I-D.ietf-netconf-yang-push], the modification 520 request made in (c) may look like that shown in Figure 7. As can be 521 seen, the modifications being attempted are the application of a new 522 XPath filter as well as the setting of a new periodic time interval. 524 526 529 23 530 531 /ex:foo/ex:bar 532 533 534 500 535 536 537 539 Figure 7: Subscription modification request (c) 541 If the NETCONF publisher can satisfy both changes, the publisher 542 sends a positive result for the RPC. If the NETCONF publisher cannot 543 satisfy either of the proposed changes, the publisher sends an RPC 544 error response (d). The following is an example RPC error response 545 for (d) which includes a hint. This hint is an alternative time 546 period value which might have resulted in a successful modification: 548 550 551 application 552 invalid-value 553 error 554 555 ietf-yang-push:period-unsupported 556 557 558 560 561 3000 562 563 564 565 566 568 Figure 8: Modify subscription failure with hint (d) 570 A.2.3. Deleting Dynamic Subscriptions 572 The following demonstrates deleting a subscription. This 573 subscription may have been to either a stream or a datastore. 575 577 579 22 580 581 583 Figure 9: Delete subscription 585 If the NETCONF publisher can satisfy the request, the publisher 586 replies with success to the RPC request. 588 If the NETCONF publisher cannot satisfy the request, the publisher 589 sends an error-rpc element indicating the modification didn't work. 590 Figure 10 shows a valid response for existing valid subscription 591 "id", but that subscription "id" was created on a different NETCONF 592 transport session: 594 596 597 application 598 invalid-value 599 error 600 601 ietf-subscribed-notifications:no-such-subscription 602 603 604 606 Figure 10: Unsuccessful delete subscription 608 A.3. Subscription State Notifications 610 A publisher will send subscription state notifications for dynamic 611 subscriptions according to the definitions within 612 [I-D.draft-ietf-netconf-subscribed-notifications]. 614 A.3.1. subscription-modified 616 As per Section 2.7.2 of 617 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 618 modified" might be sent over NETCONF if the definition of a 619 configured filter changes. A subscription state notification encoded 620 in XML would look like: 622 623 2007-09-01T10:00:00Z 624 626 39 627 628 /ex:foo 629 630 NETCONF 631 632 634 Figure 11: subscription-modified subscription state notification 636 A.3.2. subscription-resumed, and replay-complete 638 A "subscription-resumed" would look like: 640 642 2007-09-01T10:00:00Z 643 645 39 646 647 649 Figure 12: subscription-resumed notification in XML 651 The "replay-complete" is virtually identical, with "subscription- 652 resumed" simply being replaced by "replay-complete". 654 A.3.3. subscription-terminated and subscription-suspended 656 A "subscription-terminated" would look like: 658 660 2007-09-01T10:00:00Z 661 663 39 664 665 suspension-timeout 666 667 668 670 Figure 13: subscription-terminated subscription state notification 672 The "subscription-suspended" is virtually identical, with 673 "subscription-terminated" simply being replaced by "subscription- 674 suspended". 676 A.4. Filter Examples 678 This section provides examples which illustrate both XPath and 679 subtree methods of filtering event record contents. The examples are 680 based on the YANG notification "vrrp-protocol-error-event" as defined 681 per the ietf-vrrp.yang model within [RFC8347]. Event records based 682 on this specification which are generated by the publisher might 683 appear as: 685 686 2018-09-14T08:22:33.44Z 687 689 checksum-error 690 691 693 Figure 14: RFC 8347 (VRRP) - Example Notification 695 Suppose a subscriber wanted to establish a subscription which only 696 passes instances of event records where there is a "checksum-error" 697 as part of a VRRP protocol event. Also assume the publisher places 698 such event records into the NETCONF stream. To get a continuous 699 series of matching event records, the subscriber might request the 700 application of an XPath filter against the NETCONF stream. An 701 "establish-subscription" RPC to meet this objective might be: 703 704 706 NETCONF 707 708 /vrrp-protocol-error-event[ 709 vrrp:protocol-error-reason="vrrp:checksum-error"] 710 711 712 714 Figure 15: Establishing a subscription error reason via XPath 716 For more examples of XPath filters, see [XPATH]. 718 Suppose the "establish-subscription" in Figure 15 was accepted. And 719 suppose later a subscriber decided they wanted to broaden this 720 subscription cover to all VRRP protocol events (i.e., not just those 721 with a "checksum error"). The subscriber might attempt to modify the 722 subscription in a way which replaces the XPath filter with a subtree 723 filter which sends all VRRP protocol events to a subscriber. Such a 724 "modify-subscription" RPC might look like: 726 727 729 99 730 731 733 734 735 737 Figure 16 739 For more examples of subtree filters, see [RFC6241], section 6.4. 741 Appendix B. Changes between revisions 743 (To be removed by RFC editor prior to publication) 745 B.1. v17 to v18 747 o Per Benjamin Kaduk's discuss on SN, adjusted IPR to 748 pre5378Trust200902 750 B.2. v16 to v17 752 o During the SN YANG Doctor review, a suggestion was made to update 753 the error-tags to make the mechanism work with embedded NETCONF 754 and RESTCONF error reporting. 755 o Minor text tweaks from review. 757 B.3. v15 to v16 759 o During the shepherd review, two clarifications were requested 760 which do not impact the technical details of this document. These 761 clarifications were: (a) further describing that dynamic 762 subscriptions can have state change notifications, and (b) more 763 details about the recommended text refinement desired for RFC6241. 765 B.4. v14 to v15 767 o Per Kent's request, added name attribute to artwork. This would 768 be needed for an automated extraction. 770 B.5. v13 to v14 772 o Title change. 774 B.6. v11 to v13 776 o Subscription identifier renamed to id. 777 o Appendix A.4 for filter examples 778 o for v13, Tweak of example to /foo/bar 780 B.7. v10 to v11 782 o Configured removed. 784 B.8. v09 to v10 786 o Tweaks to examples and text. 787 o Downshifted state names. 788 o Removed address from examples. 790 B.9. v08 to v09 792 o Tweaks based on Kent's comments. 793 o Updated examples in Appendix A. And updates to some object names 794 based on changes in the subscribed-notifications draft. 795 o Added a YANG model for the NETCONF identity. 797 B.10. v07 to v08 799 o Tweaks and clarification on :interleave. 801 B.11. v06 to v07 803 o XML encoding and operational datastore mandatory. 804 o Error mechanisms and examples updated. 806 B.12. v05 to v06 808 o Moved examples to appendices 809 o All examples rewritten based on namespace learnings 810 o Normative text consolidated in front 811 o Removed all mention of JSON 812 o Call home process detailed 813 o Note: this is a major revision attempting to cover those comments 814 received from two week review. 816 B.13. v03 to v04 818 o Added additional detail to "configured subscriptions" 819 o Added interleave capability 820 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 821 notifications 822 o Corrected namespaces in examples 824 B.14. v01 to v03 826 o Text simplifications throughout 827 o v02 had no meaningful changes 829 B.15. v00 to v01 831 o Added Call Home in solution for configured subscriptions. 832 o Clarified support for multiple subscription on a single session. 833 No need to support multiple create-subscription. 834 o Added mapping between terminology in yang-push and [RFC6241] (the 835 one followed in this document). 836 o Editorial improvements. 838 Authors' Addresses 840 Eric Voit 841 Cisco Systems 843 Email: evoit@cisco.com 845 Alexander Clemm 846 Huawei 848 Email: ludwig@clemm.org 850 Alberto Gonzalez Prieto 851 Microsoft 853 Email: alberto.gonzalez@microsoft.com 855 Einar Nilsen-Nygaard 856 Cisco Systems 858 Email: einarnn@cisco.com 859 Ambika Prasad Tripathy 860 Cisco Systems 862 Email: ambtripa@cisco.com