idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-20.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 209 has weird spacing: '...pported inva...' == Line 212 has weird spacing: '...ription inva...' == Line 222 has weird spacing: '...ribable inval...' == Line 225 has weird spacing: '...pported opera...' == Line 245 has weird spacing: '...ription estab...' == (3 more instances...) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2019) is 1805 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 (~~), 8 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: November 9, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 May 8, 2019 13 Dynamic subscription to YANG Events and Datastores over NETCONF 14 draft-ietf-netconf-netconf-event-notifications-20 16 Abstract 18 This document provides a Network Configuration Protocol (NETCONF) 19 binding to the dynamic subscription capability of both subscribed 20 notifications and YANG-Push. 22 RFC Editor note: please replace the references to pre-RFC normative 23 drafts with the actual assigned RFC numbers. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Compatibility with RFC-5277's create-subscription . . . . . . 3 74 4. Mandatory XML, event stream and datastore support . . . . . . 4 75 5. NETCONF connectivity and the Dynamic Subscriptions . . . . . 4 76 6. Notification Messages . . . . . . . . . . . . . . . . . . . . 4 77 7. Dynamic Subscriptions and RPC Error Responses . . . . . . . . 5 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 11.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 85 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 8 86 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 9 87 A.3. Subscription State Notifications . . . . . . . . . . . . 13 88 A.4. Filter Examples . . . . . . . . . . . . . . . . . . . . . 15 89 Appendix B. Changes between revisions . . . . . . . . . . . . . 16 90 B.1. v19 to v20 . . . . . . . . . . . . . . . . . . . . . . . 16 91 B.2. v17 to v19 . . . . . . . . . . . . . . . . . . . . . . . 17 92 B.3. v16 to v17 . . . . . . . . . . . . . . . . . . . . . . . 17 93 B.4. v15 to v16 . . . . . . . . . . . . . . . . . . . . . . . 17 94 B.5. v14 to v15 . . . . . . . . . . . . . . . . . . . . . . . 17 95 B.6. v13 to v14 . . . . . . . . . . . . . . . . . . . . . . . 17 96 B.7. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 17 97 B.8. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 17 98 B.9. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 17 99 B.10. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 18 100 B.11. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 18 101 B.12. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 18 102 B.13. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 18 103 B.14. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 18 104 B.15. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 18 105 B.16. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 18 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 108 1. Introduction 110 This document provides a binding for events streamed over the NETCONF 111 protocol [RFC6241] for dynamic subscriptions as defined in 112 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 113 [I-D.draft-ietf-netconf-yang-push] is itself built upon 114 [I-D.draft-ietf-netconf-subscribed-notifications], this document 115 enables a NETCONF client to request via a dynamic subscription and 116 receive updates from a YANG datastore located on a NETCONF server. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 The following terms are defined in 127 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 128 subscription, event stream, notification message, publisher, 129 receiver, subscriber, subscription. No additional terms are defined. 131 3. Compatibility with RFC-5277's create-subscription 133 A publisher is allowed to concurrently support dynamic subscription 134 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 135 time as [RFC5277]'s "create-subscription" RPC. However a single 136 NETCONF transport session MUST NOT support both this specification 137 and a subscription established by [RFC5277]'s "create-subscription" 138 RPC. To protect against any attempts to use a single NETCONF 139 transport session in this way: 141 o A solution MUST reply with the [RFC6241] "rpc-error" element 142 containing the "error-tag" value of "operation-not-supported" if a 143 "create-subscription" RPC is received on a NETCONF session where 144 an [I-D.draft-ietf-netconf-subscribed-notifications] established 145 subscription exists. 146 o A solution MUST reply with the [RFC6241] "rpc-error" element 147 containing the "error-tag" value of "operation-not-supported" if 148 an "establish-subscription" request has been received on a NETCONF 149 session where the "create-subscription" RPC has successfully 150 [RFC5277] created a subscription. 152 If a publisher supports this specification but not subscriptions via 153 [RFC5277], the publisher MUST NOT advertise 154 "urn:ietf:params:netconf:capability:notification:1.0". 156 4. Mandatory XML, event stream and datastore support 158 The "encode-xml" feature of 159 [I-D.draft-ietf-netconf-subscribed-notifications] MUST be supported. 160 This indicates that XML is a valid encoding for RPCs, state change 161 notifications, and subscribed content. 163 A NETCONF publisher supporting event stream subscription via 164 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 165 "NETCONF" event stream identified in that document. 167 5. NETCONF connectivity and the Dynamic Subscriptions 169 Management of dynamic subscriptions occurs via RPCs as defined in 170 [I-D.draft-ietf-netconf-yang-push] and 171 [I-D.draft-ietf-netconf-subscribed-notifications]. For a dynamic 172 subscription, if the NETCONF session involved with the "establish- 173 subscription" terminates, the subscription MUST be terminated. 175 For a dynamic subscription, any "modify-subscription", "delete- 176 subscription", or "resync-subscription" RPCs MUST be sent using the 177 same NETCONF session upon which the referenced subscription was 178 established. 180 6. Notification Messages 182 Notification messages transported over the NETCONF protocol MUST be 183 encoded in a message as defined within [RFC5277], 184 Section 4. And per [RFC5277]'s "eventTime" object definition, the 185 "eventTime" populated with the event occurrence time. 187 For dynamic subscriptions, all notification messages MUST use the 188 NETCONF transport session used by the "establish-subscription" RPC. 190 7. Dynamic Subscriptions and RPC Error Responses 192 When an RPC error occurs as defined in 193 [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4.6 and 194 [I-D.draft-ietf-netconf-yang-push] Appendix A, the NETCONF RPC reply 195 MUST include an "rpc-error" element per [RFC6241] with the error 196 information populated as follows: 198 o An "error-type" node of "application". 199 o An "error-tag" node with the value being a string that corresponds 200 to an identity associated with the error. This "error-tag" will 201 come from one of two places. Either it will correspond to the 202 error identities within 203 [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 204 for general subscription errors: 206 error identity uses error-tag 207 ---------------------- -------------- 208 dscp-unavailable invalid-value 209 encoding-unsupported invalid-value 210 filter-unsupported invalid-value 211 insufficient-resources resource-denied 212 no-such-subscription invalid-value 213 replay-unsupported operation-not-supported 215 Or this "error-tag" will correspond to the error identities within 216 [I-D.draft-ietf-netconf-yang-push] Appendix A.1 for subscription 217 errors specific to YANG datastores: 219 error identity uses error-tag 220 ---------------------- -------------- 221 cant-exclude operation-not-supported 222 datastore-not-subscribable invalid-value 223 no-such-subscription-resync invalid-value 224 on-change-unsupported operation-not-supported 225 on-change-sync-unsupported operation-not-supported 226 period-unsupported invalid-value 227 update-too-big too-big 228 sync-too-big too-big 229 unchanging-selection operation-failed 231 o an "error-severity" of "error" (this MAY be included). 232 o an "error-app-tag" node with the value being a string that 233 corresponds to an identity associated with the error, as defined 234 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 235 for general subscriptions, and [I-D.draft-ietf-netconf-yang-push] 236 Appendix A.1, for datastore subscriptions. The specific identity 237 to use depends on the RPC for which the error occurred. Each 238 error identity will be inserted as the "error-app-tag" following 239 the form :. An example of such as valid 240 encoding would be "ietf-subscribed-notifications:no-such- 241 subscription". Viable errors for different RPCs are as follows: 243 RPC use base identity 244 ---------------------- ---------------------------- 245 establish-subscription establish-subscription-error 246 modify-subscription modify-subscription-error 247 delete-subscription delete-subscription-error 248 kill-subscription delete-subscription-error 249 resync-subscription resync-subscription-error 251 o In case of error responses to an "establish-subscription" or 252 "modify-subscription" request there is the option of including an 253 "error-info" node. This node may contain XML-encoded data with 254 hints for parameter settings that might lead to successful RPC 255 requests in the future. Following are the yang-data structures 256 from [I-D.draft-ietf-netconf-subscribed-notifications] and 257 [I-D.draft-ietf-netconf-yang-push] which may be returned: 259 establish-subscription returns hints in yang-data structure 260 ---------------------- ------------------------------------ 261 target: event stream establish-subscription-stream-error-info 262 target: datastore establish-subscription-datastore-error-info 264 modify-subscription returns hints in yang-data structure 265 ---------------------- ------------------------------------ 266 target: event stream modify-subscription-stream-error-info 267 target: datastore modify-subscription-datastore-error-info 269 The yang-data included within "error-info" SHOULD NOT include the 270 optional leaf "error-reason", as such a leaf would be redundant 271 with information that is already placed within the 272 "error-app-tag". 274 In case of an rpc error resulting from a "delete-subscription", 275 "kill-subscription", or "resync-subscription" request, no "error- 276 info" needs to be included, as the "subscription-id" is the only RPC 277 input parameter and no hints regarding this RPC input parameters need 278 to be provided. 280 8. Security Considerations 282 If a malicious or buggy NETCONF subscriber sends a number of 283 establish-subscription requests, then these subscriptions accumulate 284 and may use up system resources. In such a situation, subscriptions 285 MAY be terminated by terminating the underlying NETCONF session. The 286 publisher MAY also suspend or terminate a subset of the active 287 subscriptions on that NETCONF session. 289 9. IANA Considerations 291 This document has no actions for IANA. 293 10. Acknowledgments 295 We wish to acknowledge the helpful contributions, comments, and 296 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 297 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 298 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, 299 Qin Wu, and Guangying Zheng. 301 11. References 303 11.1. Normative References 305 [I-D.draft-ietf-netconf-subscribed-notifications] 306 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 307 and E. Nilsen-Nygaard, "Customized Subscriptions to a 308 Publisher's Event Streams", September 2018, 309 . 312 [I-D.draft-ietf-netconf-yang-push] 313 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 314 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 315 Lengyel, "YANG Datastore Subscription", September 2018, 316 . 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 325 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 326 . 328 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 329 and A. Bierman, Ed., "Network Configuration Protocol 330 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 331 . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 11.2. Informative References 339 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 340 Zhang, "A YANG Data Model for the Virtual Router 341 Redundancy Protocol (VRRP)", RFC 8347, 342 DOI 10.17487/RFC8347, March 2018, 343 . 345 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 346 Version 1.0", November 1999, 347 . 349 Appendix A. Examples 351 This section is non-normative. 353 A.1. Event Stream Discovery 355 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 356 event stream exposes a continuous set of events available for 357 subscription. A NETCONF client can retrieve the list of available 358 event streams from a NETCONF publisher using the "get" operation 359 against the top-level container "/streams" defined in 360 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 362 The following example illustrates the retrieval of the list of 363 available event streams: 365 367 368 369 371 372 373 375 Figure 1: Get streams request 377 After such a request, the NETCONF publisher returns a list of event 378 streams available, as well as additional information which might 379 exist in the container. 381 A.2. Dynamic Subscriptions 383 A.2.1. Establishing Dynamic Subscriptions 385 The following figure shows two successful "establish-subscription" 386 RPC requests as per 387 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 388 is given a subscription "id" of 22, the second, an "id" of 23. 390 +------------+ +-----------+ 391 | Subscriber | | Publisher | 392 +------------+ +-----------+ 393 | | 394 | Capability Exchange | 395 |<---------------------------->| 396 | | 397 | | 398 | establish-subscription | 399 |----------------------------->| (a) 400 | RPC Reply: OK, id = 22 | 401 |<-----------------------------| (b) 402 | | 403 | notification message (for 22)| 404 |<-----------------------------| 405 | | 406 | | 407 | establish-subscription | 408 |----------------------------->| 409 | notification message (for 22)| 410 |<-----------------------------| 411 | RPC Reply: OK, id = 23 | 412 |<-----------------------------| 413 | | 414 | | 415 | notification message (for 22)| 416 |<-----------------------------| 417 | notification message (for 23)| 418 |<-----------------------------| 419 | | 421 Figure 2: Multiple subscriptions over a NETCONF session 423 To provide examples of the information being transported, example 424 messages for interactions (a) and (b) in Figure 2 are detailed below: 426 427 429 430 /ex:foo/ 431 432 NETCONF 433 10 434 435 437 Figure 3: establish-subscription request (a) 439 As NETCONF publisher was able to fully satisfy the request (a), the 440 publisher sends the subscription "id" of the accepted subscription 441 within message (b): 443 445 447 22 448 449 451 Figure 4: establish-subscription success (b) 453 If the NETCONF publisher had not been able to fully satisfy the 454 request, or subscriber has no authorization to establish the 455 subscription, the publisher would have sent an RPC error response. 456 For instance, if the "dscp" value of 10 asserted by the subscriber in 457 Figure 3 proved unacceptable, the publisher may have returned: 459 461 462 application 463 invalid-value 464 error 465 466 ietf-subscribed-notifications:dscp-unavailable 467 468 469 471 Figure 5: an unsuccessful establish subscription 473 The subscriber can use this information in future attempts to 474 establish a subscription. 476 A.2.2. Modifying Dynamic Subscriptions 478 An existing subscription may be modified. The following exchange 479 shows a negotiation of such a modification via several exchanges 480 between a subscriber and a publisher. This negotiation consists of a 481 failed RPC modification request/response, followed by a successful 482 one. 484 +------------+ +-----------+ 485 | Subscriber | | Publisher | 486 +------------+ +-----------+ 487 | | 488 | notification message (for 23)| 489 |<-----------------------------| 490 | | 491 | modify-subscription (id = 23)| 492 |----------------------------->| (c) 493 | RPC error (with hint) | 494 |<-----------------------------| (d) 495 | | 496 | modify-subscription (id = 23)| 497 |----------------------------->| 498 | RPC Reply: OK | 499 |<-----------------------------| 500 | | 501 | notification message (for 23)| 502 |<-----------------------------| 503 | | 505 Figure 6: Interaction model for successful subscription modification 507 If the subscription being modified in Figure 6 is a datastore 508 subscription as per [I-D.draft-ietf-netconf-yang-push], the 509 modification request made in (c) may look like that shown in 510 Figure 7. As can be seen, the modifications being attempted are the 511 application of a new XPath filter as well as the setting of a new 512 periodic time interval. 514 516 519 23 520 521 /ex:foo/ex:bar 522 523 524 500 525 526 527 529 Figure 7: Subscription modification request (c) 531 If the NETCONF publisher can satisfy both changes, the publisher 532 sends a positive result for the RPC. If the NETCONF publisher cannot 533 satisfy either of the proposed changes, the publisher sends an RPC 534 error response (d). The following is an example RPC error response 535 for (d) which includes a hint. This hint is an alternative time 536 period value which might have resulted in a successful modification: 538 540 541 application 542 invalid-value 543 error 544 545 ietf-yang-push:period-unsupported 546 547 548 550 551 3000 552 553 554 555 556 558 Figure 8: Modify subscription failure with hint (d) 560 A.2.3. Deleting Dynamic Subscriptions 562 The following demonstrates deleting a subscription. This 563 subscription may have been to either a stream or a datastore. 565 567 569 22 570 571 573 Figure 9: Delete subscription 575 If the NETCONF publisher can satisfy the request, the publisher 576 replies with success to the RPC request. 578 If the NETCONF publisher cannot satisfy the request, the publisher 579 sends an error-rpc element indicating the modification didn't work. 580 Figure 10 shows a valid response for existing valid subscription 581 "id", but that subscription "id" was created on a different NETCONF 582 transport session: 584 586 587 application 588 invalid-value 589 error 590 591 ietf-subscribed-notifications:no-such-subscription 592 593 594 596 Figure 10: Unsuccessful delete subscription 598 A.3. Subscription State Notifications 600 A publisher will send subscription state notifications for dynamic 601 subscriptions according to the definitions within 602 [I-D.draft-ietf-netconf-subscribed-notifications]. 604 A.3.1. subscription-modified 606 As per Section 2.7.2 of 607 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 608 modified" might be sent over NETCONF if the definition of a 609 configured filter changes. A subscription state notification encoded 610 in XML would look like: 612 613 2007-09-01T10:00:00Z 614 616 39 617 618 /ex:foo 619 620 NETCONF 621 622 624 Figure 11: subscription-modified subscription state notification 626 A.3.2. subscription-resumed, and replay-complete 628 A "subscription-resumed" would look like: 630 632 2007-09-01T10:00:00Z 633 635 39 636 637 639 Figure 12: subscription-resumed notification in XML 641 The "replay-complete" is virtually identical, with "subscription- 642 resumed" simply being replaced by "replay-complete". 644 A.3.3. subscription-terminated and subscription-suspended 646 A "subscription-terminated" would look like: 648 650 2007-09-01T10:00:00Z 651 653 39 654 655 suspension-timeout 656 657 658 660 Figure 13: subscription-terminated subscription state notification 662 The "subscription-suspended" is virtually identical, with 663 "subscription-terminated" simply being replaced by "subscription- 664 suspended". 666 A.4. Filter Examples 668 This section provides examples which illustrate both XPath and 669 subtree methods of filtering event record contents. The examples are 670 based on the YANG notification "vrrp-protocol-error-event" as defined 671 per the ietf-vrrp.yang model within [RFC8347]. Event records based 672 on this specification which are generated by the publisher might 673 appear as: 675 676 2018-09-14T08:22:33.44Z 677 679 checksum-error 680 681 683 Figure 14: RFC 8347 (VRRP) - Example Notification 685 Suppose a subscriber wanted to establish a subscription which only 686 passes instances of event records where there is a "checksum-error" 687 as part of a VRRP protocol event. Also assume the publisher places 688 such event records into the NETCONF stream. To get a continuous 689 series of matching event records, the subscriber might request the 690 application of an XPath filter against the NETCONF stream. An 691 "establish-subscription" RPC to meet this objective might be: 693 694 696 NETCONF 697 698 /vrrp-protocol-error-event[ 699 vrrp:protocol-error-reason="vrrp:checksum-error"] 700 701 702 704 Figure 15: Establishing a subscription error reason via XPath 706 For more examples of XPath filters, see [XPATH]. 708 Suppose the "establish-subscription" in Figure 15 was accepted. And 709 suppose later a subscriber decided they wanted to broaden this 710 subscription cover to all VRRP protocol events (i.e., not just those 711 with a "checksum error"). The subscriber might attempt to modify the 712 subscription in a way which replaces the XPath filter with a subtree 713 filter which sends all VRRP protocol events to a subscriber. Such a 714 "modify-subscription" RPC might look like: 716 717 719 99 720 721 723 724 725 727 Figure 16 729 For more examples of subtree filters, see [RFC6241], section 6.4. 731 Appendix B. Changes between revisions 733 (To be removed by RFC editor prior to publication) 735 B.1. v19 to v20 737 o Notes to RFC editor removed, consideration moved under Figure 10 738 in SN. 740 B.2. v17 to v19 742 o Per Benjamin Kaduk's discuss on SN, adjusted IPR to 743 pre5378Trust200902 745 B.3. v16 to v17 747 o During the SN YANG Doctor review, a suggestion was made to update 748 the error-tags to make the mechanism work with embedded NETCONF 749 and RESTCONF error reporting. 750 o Minor text tweaks from review. 752 B.4. v15 to v16 754 o During the shepherd review, two clarifications were requested 755 which do not impact the technical details of this document. These 756 clarifications were: (a) further describing that dynamic 757 subscriptions can have state change notifications, and (b) more 758 details about the recommended text refinement desired for RFC6241. 760 B.5. v14 to v15 762 o Per Kent's request, added name attribute to artwork. This would 763 be needed for an automated extraction. 765 B.6. v13 to v14 767 o Title change. 769 B.7. v11 to v13 771 o Subscription identifier renamed to id. 772 o Appendix A.4 for filter examples 773 o for v13, Tweak of example to /foo/bar 775 B.8. v10 to v11 777 o Configured removed. 779 B.9. v09 to v10 781 o Tweaks to examples and text. 782 o Downshifted state names. 783 o Removed address from examples. 785 B.10. v08 to v09 787 o Tweaks based on Kent's comments. 788 o Updated examples in Appendix A. And updates to some object names 789 based on changes in the subscribed-notifications draft. 790 o Added a YANG model for the NETCONF identity. 792 B.11. v07 to v08 794 o Tweaks and clarification on :interleave. 796 B.12. v06 to v07 798 o XML encoding and operational datastore mandatory. 799 o Error mechanisms and examples updated. 801 B.13. v05 to v06 803 o Moved examples to appendices 804 o All examples rewritten based on namespace learnings 805 o Normative text consolidated in front 806 o Removed all mention of JSON 807 o Call home process detailed 808 o Note: this is a major revision attempting to cover those comments 809 received from two week review. 811 B.14. v03 to v04 813 o Added additional detail to "configured subscriptions" 814 o Added interleave capability 815 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 816 notifications 817 o Corrected namespaces in examples 819 B.15. v01 to v03 821 o Text simplifications throughout 822 o v02 had no meaningful changes 824 B.16. v00 to v01 826 o Added Call Home in solution for configured subscriptions. 827 o Clarified support for multiple subscription on a single session. 828 No need to support multiple create-subscription. 829 o Added mapping between terminology in yang-push and [RFC6241] (the 830 one followed in this document). 831 o Editorial improvements. 833 Authors' Addresses 835 Eric Voit 836 Cisco Systems 838 Email: evoit@cisco.com 840 Alexander Clemm 841 Huawei 843 Email: ludwig@clemm.org 845 Alberto Gonzalez Prieto 846 Microsoft 848 Email: alberto.gonzalez@microsoft.com 850 Einar Nilsen-Nygaard 851 Cisco Systems 853 Email: einarnn@cisco.com 855 Ambika Prasad Tripathy 856 Cisco Systems 858 Email: ambtripa@cisco.com