idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-17.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 196 has weird spacing: '...pported inva...' == Line 199 has weird spacing: '...ription inva...' == Line 209 has weird spacing: '...ribable inval...' == Line 212 has weird spacing: '...pported opera...' == Line 232 has weird spacing: '...ription estab...' == (3 more instances...) -- The document date (February 13, 2019) is 1898 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: August 17, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 February 13, 2019 13 Dynamic subscription to YANG Events and Datastores over NETCONF 14 draft-ietf-netconf-netconf-event-notifications-17 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 August 17, 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. v16 to v17 . . . . . . . . . . . . . . . . . . . . . . . 17 79 B.2. v15 to v16 . . . . . . . . . . . . . . . . . . . . . . . 17 80 B.3. v14 to v15 . . . . . . . . . . . . . . . . . . . . . . . 17 81 B.4. v13 to v14 . . . . . . . . . . . . . . . . . . . . . . . 17 82 B.5. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 17 83 B.6. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 18 84 B.7. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 18 85 B.8. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 18 86 B.9. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 18 87 B.10. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 18 88 B.11. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 18 89 B.12. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 18 90 B.13. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 19 91 B.14. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 This document provides a binding for events streamed over the NETCONF 97 protocol [RFC6241] for dynamic subscriptions as defined in 98 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 99 [I-D.ietf-netconf-yang-push] is itself built upon 100 [I-D.draft-ietf-netconf-subscribed-notifications], this document 101 enables a NETCONF client to request via a dynamic subscription and 102 receive updates from a YANG datastore located on a NETCONF server. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 The following terms are defined in 113 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 114 subscription, event stream, notification message, publisher, 115 receiver, subscriber, subscription. No additional terms are defined. 117 3. Compatibility with RFC-5277's create-subscription 119 A publisher is allowed to concurrently support dynamic subscription 120 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 121 time as [RFC5277]'s "create-subscription" RPC. However a single 122 NETCONF transport session cannot support both this specification and 123 a subscription established by [RFC5277]'s "create-subscription" RPC. 124 To protect against any attempts to use a single NETCONF transport 125 session in this way: 127 o A solution MUST reply with the [RFC6241] "rpc-error" element 128 containing the "error-tag" value of "operation-not-supported" if a 129 "create-subscription" RPC is received on a NETCONF session where 130 an [I-D.draft-ietf-netconf-subscribed-notifications] established 131 subscription exists. 132 o A solution MUST reply with the [RFC6241] "rpc-error" element 133 containing the "error-tag" value of "operation-not-supported" if 134 an "establish-subscription" request has been received on a NETCONF 135 session where the "create-subscription" RPC has successfully 136 [RFC5277] created a subscription. 138 If a publisher supports this specification but not subscriptions via 139 [RFC5277], the publisher MUST NOT advertise 140 "urn:ietf:params:netconf:capability:notification:1.0". 142 4. Mandatory XML, event stream and datastore support 144 The "encode-xml" feature of 145 [I-D.draft-ietf-netconf-subscribed-notifications] MUST be supported. 146 This indicates that XML is a valid encoding for RPCs, state change 147 notifications, and subscribed content. 149 A NETCONF publisher supporting event stream subscription via 150 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 151 "NETCONF" event stream identified in that document. 153 5. NETCONF connectivity and the Dynamic Subscriptions 155 Management of dynamic subscriptions occurs via RPCs as defined in 156 [I-D.ietf-netconf-yang-push] and 157 [I-D.draft-ietf-netconf-subscribed-notifications]. For a dynamic 158 subscription, if the NETCONF session involved with the "establish- 159 subscription" terminates, the subscription MUST be terminated. 161 For a dynamic subscription, any "modify-subscription", "delete- 162 subscription", or "resync-subscription" RPCs MUST be sent using the 163 same NETCONF session upon which the referenced subscription was 164 established. 166 6. Notification Messages 168 Notification messages transported over the NETCONF protocol MUST be 169 encoded in a message as defined within [RFC5277], 170 Section 4. And per [RFC5277]'s "eventTime" object definition, the 171 "eventTime" MUST be populated with the event occurrence time. 173 For dynamic subscriptions, all notification messages MUST use the 174 NETCONF transport session used by the "establish-subscription" RPC. 176 7. Dynamic Subscriptions and RPC Error Responses 178 When an RPC error occurs as defined in 179 [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4.6 and 180 [I-D.ietf-netconf-yang-push] Appendix A, the NETCONF RPC reply MUST 181 include an "rpc-error" element per [RFC6241] with the error 182 information populated as follows: 184 o An "error-type" node of "application". 185 o An "error-tag" node with the value being a string that corresponds 186 to an identity associated with the error. This "error-tag" will 187 come from one of two places. Either it will correspond to the 188 error identities within 190 [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 191 for general subscription errors: 193 error identity uses error-tag 194 ---------------------- -------------- 195 dscp-unavailable invalid-value 196 encoding-unsupported invalid-value 197 filter-unsupported invalid-value 198 insufficient-resources resource-denied 199 no-such-subscription invalid-value 200 replay-unsupported operation-not-supported 202 Or this "error-tag" will correspond to the error identities within 203 [I-D.ietf-netconf-yang-push] Appendix A.1 for subscription errors 204 specific to YANG datastores: 206 error identity uses error-tag 207 ---------------------- -------------- 208 cant-exclude operation-not-supported 209 datastore-not-subscribable invalid-value 210 no-such-subscription-resync invalid-value 211 on-change-unsupported operation-not-supported 212 on-change-sync-unsupported operation-not-supported 213 period-unsupported invalid-value 214 update-too-big too-big 215 sync-too-big too-big 216 unchanging-selection operation-failed 218 o an "error-severity" of "error" (this MAY be included). 219 o an "error-app-tag" node with the value being a string that 220 corresponds to an identity associated with the error, as defined 221 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 222 for general subscriptions, and [I-D.ietf-netconf-yang-push] 223 Appendix A.1, for datastore subscriptions. The specific identity 224 to use depends on the RPC for which the error occurred. Each 225 error identity will be inserted as the "error-app-tag" following 226 the form :. An example of such as valid 227 encoding would be "ietf-subscribed-notifications:no-such- 228 subscription". Viable errors for different RPCs are as follows: 230 RPC use base identity 231 ---------------------- ---------------------------- 232 establish-subscription establish-subscription-error 233 modify-subscription modify-subscription-error 234 delete-subscription delete-subscription-error 235 kill-subscription delete-subscription-error 236 resync-subscription resync-subscription-error 238 o In case of error responses to an "establish-subscription" or 239 "modify-subscription" request there is the option of including an 240 "error-info" node. This node may contain XML-encoded data with 241 hints for parameter settings that might lead to successful RPC 242 requests in the future. Following are the yang-data structures 243 from [I-D.draft-ietf-netconf-subscribed-notifications] and 244 [I-D.ietf-netconf-yang-push] which may be returned: 246 establish-subscription returns hints in yang-data structure 247 ---------------------- ------------------------------------ 248 target: event stream establish-subscription-stream-error-info 249 target: datastore establish-subscription-datastore-error-info 251 modify-subscription returns hints in yang-data structure 252 ---------------------- ------------------------------------ 253 target: event stream modify-subscription-stream-error-info 254 target: datastore modify-subscription-datastore-error-info 256 The yang-data included within "error-info" SHOULD NOT include the 257 optional leaf "error-reason", as such a leaf would be redundant 258 with information that is already placed within the 259 "error-app-tag". 261 In case of an rpc error resulting from a "delete-subscription", 262 "kill-subscription", or "resync-subscription" request, no "error- 263 info" needs to be included, as the "subscription-id" is the only RPC 264 input parameter and no hints regarding this RPC input parameters need 265 to be provided. 267 8. Security Considerations 269 If a malicious or buggy NETCONF subscriber sends a number of 270 establish-subscription requests, then these subscriptions accumulate 271 and may use up system resources. In such a situation, subscriptions 272 MAY be terminated by terminating the underlying NETCONF session. The 273 publisher MAY also suspend or terminate a subset of the active 274 subscriptions on that NETCONF session. 276 9. IANA Considerations 278 This document has no actions for IANA. 280 10. Acknowledgments 282 We wish to acknowledge the helpful contributions, comments, and 283 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 284 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 285 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, 286 Qin Wu, and Guangying Zheng. 288 11. Notes to the RFC Editor 290 This section can be removed by the RFC editor after the requests have 291 been performed. 293 RFC 6241 needs to be updated based on the needs of this draft. 294 RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it 295 identifies RFC 5717, but that was an error fixed after RFC 296 publication). Anyway the current phrasing in RFC-5277 says that a 297 notification message can only be sent after a successful "create- 298 subscription". Therefore the reference text must be modified to also 299 allow notification messages be sent after a successful "establish- 300 subscription". Proposed text for bullet (2) of RFC-6241 would be: 302 (2) The Messages layer provides a simple, transport-independent 303 framing mechanism for encoding RPCs and notifications. 304 Section 4 documents the RPC messages, [RFC5277] documents 305 Notifications sent as a result of a RPC, 306 and [RFC xxxx] documents Notifications sent as a result of 307 an RPC. 309 (where xxxx is replaced with this RFC number) 311 12. References 313 12.1. Normative References 315 [I-D.draft-ietf-netconf-subscribed-notifications] 316 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 317 and E. Nilsen-Nygaard, "Customized Subscriptions to a 318 Publisher's Event Streams", September 2018, 319 . 322 [I-D.ietf-netconf-yang-push] 323 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 324 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 325 Lengyel, "YANG Datastore Subscription", September 2018, 326 . 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 335 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 336 . 338 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 339 and A. Bierman, Ed., "Network Configuration Protocol 340 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 341 . 343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 345 May 2017, . 347 12.2. Informative References 349 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 350 Zhang, "A YANG Data Model for the Virtual Router 351 Redundancy Protocol (VRRP)", RFC 8347, 352 DOI 10.17487/RFC8347, March 2018, 353 . 355 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 356 Version 1.0", November 1999, 357 . 359 Appendix A. Examples 361 This section is non-normative. 363 A.1. Event Stream Discovery 365 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 366 event stream exposes a continuous set of events available for 367 subscription. A NETCONF client can retrieve the list of available 368 event streams from a NETCONF publisher using the "get" operation 369 against the top-level container "/streams" defined in 370 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 372 The following example illustrates the retrieval of the list of 373 available event streams: 375 377 378 379 381 382 383 385 Figure 1: Get streams request 387 After such a request, the NETCONF publisher returns a list of event 388 streams available, as well as additional information which might 389 exist in the container. 391 A.2. Dynamic Subscriptions 393 A.2.1. Establishing Dynamic Subscriptions 395 The following figure shows two successful "establish-subscription" 396 RPC requests as per 397 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 398 is given a subscription "id" of 22, the second, an "id" of 23. 400 +------------+ +-----------+ 401 | Subscriber | | Publisher | 402 +------------+ +-----------+ 403 | | 404 | Capability Exchange | 405 |<---------------------------->| 406 | | 407 | | 408 | establish-subscription | 409 |----------------------------->| (a) 410 | RPC Reply: OK, id = 22 | 411 |<-----------------------------| (b) 412 | | 413 | notification message (for 22)| 414 |<-----------------------------| 415 | | 416 | | 417 | establish-subscription | 418 |----------------------------->| 419 | notification message (for 22)| 420 |<-----------------------------| 421 | RPC Reply: OK, id = 23 | 422 |<-----------------------------| 423 | | 424 | | 425 | notification message (for 22)| 426 |<-----------------------------| 427 | notification message (for 23)| 428 |<-----------------------------| 429 | | 431 Figure 2: Multiple subscriptions over a NETCONF session 433 To provide examples of the information being transported, example 434 messages for interactions (a) and (b) in Figure 2 are detailed below: 436 437 439 440 /ex:foo/ 441 442 NETCONF 443 10 444 445 447 Figure 3: establish-subscription request (a) 449 As NETCONF publisher was able to fully satisfy the request (a), the 450 publisher sends the subscription "id" of the accepted subscription 451 within message (b): 453 455 457 22 458 459 461 Figure 4: establish-subscription success (b) 463 If the NETCONF publisher had not been able to fully satisfy the 464 request, or subscriber has no authorization to establish the 465 subscription, the publisher would have sent an RPC error response. 466 For instance, if the "dscp" value of 10 asserted by the subscriber in 467 Figure 3 proved unacceptable, the publisher may have returned: 469 471 472 application 473 invalid-value 474 error 475 476 ietf-subscribed-notifications:dscp-unavailable 477 478 479 481 Figure 5: an unsuccessful establish subscription 483 The subscriber can use this information in future attempts to 484 establish a subscription. 486 A.2.2. Modifying Dynamic Subscriptions 488 An existing subscription may be modified. The following exchange 489 shows a negotiation of such a modification via several exchanges 490 between a subscriber and a publisher. This negotiation consists of a 491 failed RPC modification request/response, followed by a successful 492 one. 494 +------------+ +-----------+ 495 | Subscriber | | Publisher | 496 +------------+ +-----------+ 497 | | 498 | notification message (for 23)| 499 |<-----------------------------| 500 | | 501 | modify-subscription (id = 23)| 502 |----------------------------->| (c) 503 | RPC error (with hint) | 504 |<-----------------------------| (d) 505 | | 506 | modify-subscription (id = 23)| 507 |----------------------------->| 508 | RPC Reply: OK | 509 |<-----------------------------| 510 | | 511 | notification message (for 23)| 512 |<-----------------------------| 513 | | 515 Figure 6: Interaction model for successful subscription modification 517 If the subscription being modified in Figure 6 is a datastore 518 subscription as per [I-D.ietf-netconf-yang-push], the modification 519 request made in (c) may look like that shown in Figure 7. As can be 520 seen, the modifications being attempted are the application of a new 521 XPath filter as well as the setting of a new periodic time interval. 523 525 528 23 529 530 /ex:foo/ex:bar 531 532 533 500 534 535 536 538 Figure 7: Subscription modification request (c) 540 If the NETCONF publisher can satisfy both changes, the publisher 541 sends a positive result for the RPC. If the NETCONF publisher cannot 542 satisfy either of the proposed changes, the publisher sends an RPC 543 error response (d). The following is an example RPC error response 544 for (d) which includes a hint. This hint is an alternative time 545 period value which might have resulted in a successful modification: 547 549 550 application 551 invalid-value 552 error 553 554 ietf-yang-push:period-unsupported 555 556 557 559 560 3000 561 562 563 564 565 567 Figure 8: Modify subscription failure with hint (d) 569 A.2.3. Deleting Dynamic Subscriptions 571 The following demonstrates deleting a subscription. This 572 subscription may have been to either a stream or a datastore. 574 576 578 22 579 580 582 Figure 9: Delete subscription 584 If the NETCONF publisher can satisfy the request, the publisher 585 replies with success to the RPC request. 587 If the NETCONF publisher cannot satisfy the request, the publisher 588 sends an error-rpc element indicating the modification didn't work. 589 Figure 10 shows a valid response for existing valid subscription 590 "id", but that subscription "id" was created on a different NETCONF 591 transport session: 593 595 596 application 597 invalid-value 598 error 599 600 ietf-subscribed-notifications:no-such-subscription 601 602 603 605 Figure 10: Unsuccessful delete subscription 607 A.3. Subscription State Notifications 609 A publisher will send subscription state notifications for dynamic 610 subscriptions according to the definitions within 611 [I-D.draft-ietf-netconf-subscribed-notifications]. 613 A.3.1. subscription-modified 615 As per Section 2.7.2 of 616 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 617 modified" might be sent over NETCONF if the definition of a 618 configured filter changes. A subscription state notification encoded 619 in XML would look like: 621 622 2007-09-01T10:00:00Z 623 625 39 626 627 /ex:foo 628 629 NETCONF 630 631 633 Figure 11: subscription-modified subscription state notification 635 A.3.2. subscription-resumed, and replay-complete 637 A "subscription-resumed" would look like: 639 641 2007-09-01T10:00:00Z 642 644 39 645 646 648 Figure 12: subscription-resumed notification in XML 650 The "replay-complete" is virtually identical, with "subscription- 651 resumed" simply being replaced by "replay-complete". 653 A.3.3. subscription-terminated and subscription-suspended 655 A "subscription-terminated" would look like: 657 659 2007-09-01T10:00:00Z 660 662 39 663 664 suspension-timeout 665 666 667 669 Figure 13: subscription-terminated subscription state notification 671 The "subscription-suspended" is virtually identical, with 672 "subscription-terminated" simply being replaced by "subscription- 673 suspended". 675 A.4. Filter Examples 677 This section provides examples which illustrate both XPath and 678 subtree methods of filtering event record contents. The examples are 679 based on the YANG notification "vrrp-protocol-error-event" as defined 680 per the ietf-vrrp.yang model within [RFC8347]. Event records based 681 on this specification which are generated by the publisher might 682 appear as: 684 685 2018-09-14T08:22:33.44Z 686 688 checksum-error 689 690 692 Figure 14: RFC 8347 (VRRP) - Example Notification 694 Suppose a subscriber wanted to establish a subscription which only 695 passes instances of event records where there is a "checksum-error" 696 as part of a VRRP protocol event. Also assume the publisher places 697 such event records into the NETCONF stream. To get a continuous 698 series of matching event records, the subscriber might request the 699 application of an XPath filter against the NETCONF stream. An 700 "establish-subscription" RPC to meet this objective might be: 702 703 705 NETCONF 706 707 /vrrp-protocol-error-event[ 708 vrrp:protocol-error-reason="vrrp:checksum-error"] 709 710 711 713 Figure 15: Establishing a subscription error reason via XPath 715 For more examples of XPath filters, see [XPATH]. 717 Suppose the "establish-subscription" in Figure 15 was accepted. And 718 suppose later a subscriber decided they wanted to broaden this 719 subscription cover to all VRRP protocol events (i.e., not just those 720 with a "checksum error"). The subscriber might attempt to modify the 721 subscription in a way which replaces the XPath filter with a subtree 722 filter which sends all VRRP protocol events to a subscriber. Such a 723 "modify-subscription" RPC might look like: 725 726 728 99 729 730 732 733 734 736 Figure 16 738 For more examples of subtree filters, see [RFC6241], section 6.4. 740 Appendix B. Changes between revisions 742 (To be removed by RFC editor prior to publication) 744 B.1. v16 to v17 746 o During the SN YANG Doctor review, a suggestion was made to update 747 the error-tags to make the mechanism work with embedded NETCONF 748 and RESTCONF error reporting. 749 o Minor text tweaks from review. 751 B.2. v15 to v16 753 o During the shepherd review, two clarifications were requested 754 which do not impact the technical details of this document. These 755 clarifications were: (a) further describing that dynamic 756 subscriptions can have state change notifications, and (b) more 757 details about the recommended text refinement desired for RFC6241. 759 B.3. v14 to v15 761 o Per Kent's request, added name attribute to artwork. This would 762 be needed for an automated extraction. 764 B.4. v13 to v14 766 o Title change. 768 B.5. v11 to v13 770 o Subscription identifier renamed to id. 771 o Appendix A.4 for filter examples 772 o for v13, Tweak of example to /foo/bar 774 B.6. v10 to v11 776 o Configured removed. 778 B.7. v09 to v10 780 o Tweaks to examples and text. 781 o Downshifted state names. 782 o Removed address from examples. 784 B.8. v08 to v09 786 o Tweaks based on Kent's comments. 787 o Updated examples in Appendix A. And updates to some object names 788 based on changes in the subscribed-notifications draft. 789 o Added a YANG model for the NETCONF identity. 791 B.9. v07 to v08 793 o Tweaks and clarification on :interleave. 795 B.10. v06 to v07 797 o XML encoding and operational datastore mandatory. 798 o Error mechanisms and examples updated. 800 B.11. v05 to v06 802 o Moved examples to appendices 803 o All examples rewritten based on namespace learnings 804 o Normative text consolidated in front 805 o Removed all mention of JSON 806 o Call home process detailed 807 o Note: this is a major revision attempting to cover those comments 808 received from two week review. 810 B.12. v03 to v04 812 o Added additional detail to "configured subscriptions" 813 o Added interleave capability 814 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 815 notifications 816 o Corrected namespaces in examples 818 B.13. v01 to v03 820 o Text simplifications throughout 821 o v02 had no meaningful changes 823 B.14. v00 to v01 825 o Added Call Home in solution for configured subscriptions. 826 o Clarified support for multiple subscription on a single session. 827 No need to support multiple create-subscription. 828 o Added mapping between terminology in yang-push and [RFC6241] (the 829 one followed in this document). 830 o Editorial improvements. 832 Authors' Addresses 834 Eric Voit 835 Cisco Systems 837 Email: evoit@cisco.com 839 Alexander Clemm 840 Huawei 842 Email: ludwig@clemm.org 844 Alberto Gonzalez Prieto 845 Microsoft 847 Email: alberto.gonzalez@microsoft.com 849 Einar Nilsen-Nygaard 850 Cisco Systems 852 Email: einarnn@cisco.com 854 Ambika Prasad Tripathy 855 Cisco Systems 857 Email: ambtripa@cisco.com