idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-13.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 189 has weird spacing: '...ription estab...' == Line 193 has weird spacing: '...ription res...' == Line 209 has weird spacing: '... stream esta...' == Line 212 has weird spacing: '...ription ret...' == Line 214 has weird spacing: '... stream modi...' -- The document date (October 4, 2018) is 2029 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 (-26) exists of draft-ietf-netconf-subscribed-notifications-17 Summary: 1 error (**), 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: April 7, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 October 4, 2018 13 NETCONF Support for Event Notifications 14 draft-ietf-netconf-netconf-event-notifications-13 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 April 7, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Compatibility with RFC-5277's create-subscription . . . . . . 3 61 4. Mandatory XML, event stream and datastore support . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 5 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 10. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 6 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 11.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 72 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 7 73 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 8 74 A.3. Subscription State Notifications . . . . . . . . . . . . 12 75 A.4. Filter Examples . . . . . . . . . . . . . . . . . . . . . 14 76 Appendix B. Changes between revisions . . . . . . . . . . . . . 15 77 B.1. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 15 78 B.2. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 16 79 B.3. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 16 80 B.4. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 16 81 B.5. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 16 82 B.6. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 16 83 B.7. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 16 84 B.8. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 16 85 B.9. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 17 86 B.10. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 This document provides a binding for events streamed over the NETCONF 92 protocol [RFC6241] for dynamic subscriptions as defined in 93 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 94 [I-D.ietf-netconf-yang-push] is itself built upon 95 [I-D.draft-ietf-netconf-subscribed-notifications], this document 96 enables a NETCONF client to request via a dynamic subscription and 97 receive updates from a YANG datastore located on a NETCONF server. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 The following terms are defined in 108 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 109 subscription, event stream, notification message, publisher, 110 receiver, subscriber, subscription. 112 3. Compatibility with RFC-5277's create-subscription 114 A publisher is allowed to concurrently support dynamic subscription 115 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 116 time as [RFC5277]'s "create-subscription" RPC. However a single 117 NETCONF transport session cannot support both this specification and 118 a subscription established by [RFC5277]'s "create-subscription" RPC. 119 To protect against any attempts to use a single NETCONF transport 120 session in this way: 122 o A solution must reply with the [RFC6241] error "operation-not- 123 supported" if a "create-subscription" RPC is received on a NETCONF 124 session where an [I-D.draft-ietf-netconf-subscribed-notifications] 125 established subscription exists. 126 o A solution must reply with the [RFC6241] error "operation-not- 127 supported" if an "establish-subscription" request is been received 128 on a NETCONF session where the "create-subscription" RPC has 129 successfully [RFC5277] created a subscription. 131 If a publisher supports this specification but not subscriptions via 132 [RFC5277], the publisher MUST NOT advertise 133 "urn:ietf:params:netconf:capability:notification:1.0". 135 4. Mandatory XML, event stream and datastore support 137 The "encode-xml" feature of 138 [I-D.draft-ietf-netconf-subscribed-notifications] is mandatory to 139 support. This indicates that XML is a valid encoding for RPCs, state 140 change notifications, and subscribed content. 142 A NETCONF publisher supporting event stream subscription via 143 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 144 "NETCONF" event stream identified in that draft. 146 5. NETCONF connectivity and the Dynamic Subscriptions 148 For a dynamic subscription, if the NETCONF session involved with the 149 "establish-subscription" terminates, the subscription MUST be 150 terminated. 152 For a dynamic subscription a "modify-subscription", "delete- 153 subscription", or "resynch-subscription" RPC MUST be sent using same 154 the NETCONF session upon which the referenced subscription was 155 established. 157 6. Notification Messages 159 Notification messages transported over the NETCONF protocol MUST be 160 encoded in a message as defined within [RFC5277], 161 Section 4. And per [RFC5277]'s "eventTime" object definition, the 162 "eventTime" MUST be populated with the event occurrence time. 164 For dynamic subscriptions, all notification messages MUST use the 165 NETCONF transport session used by the "establish-subscription" RPC. 167 7. Dynamic Subscriptions and RPC Error Responses 169 Management of dynamic subscriptions occurs via RPCs as defined in 170 [I-D.ietf-netconf-yang-push] and 171 [I-D.draft-ietf-netconf-subscribed-notifications]. When an RPC error 172 occurs, the NETCONF RPC reply MUST include an "rpc-error" element per 173 [RFC6241] with the error information populated as follows: 175 o an "error-type" node of "application". 176 o an "error-tag" node of "operation-failed". 177 o an "error-severity" of "error" (this MAY but does not have to be 178 included). 179 o an "error-app-tag" node with the value being a string that 180 corresponds to an identity associated with the error, as defined 181 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 182 for general subscriptions, and [I-D.ietf-netconf-yang-push] 183 Appendix A.1, for datastore subscriptions. The specific identity 184 to use depends on the RPC for which the error occurred. Viable 185 errors for different RPCs are as follows: 187 RPC use base identity 188 ---------------------- ---------------------------- 189 establish-subscription establish-subscription-error 190 modify-subscription modify-subscription-error 191 delete-subscription delete-subscription-error 192 kill-subscription kill-subscription-error 193 resynch-subscription resynch-subscription-error 195 Each error identity will be inserted as the "error-app-tag" using 196 JSON encoding following the form :. An 197 example of such as valid encoding would be "ietf-subscribed- 198 notifications:no-such-subscription". 200 o In case of error responses to an "establish-subscription" or 201 "modify-subscription" request there is the option of including an 202 "error-info" node. This node may contain XML-encoded data with 203 hints for parameter settings that might lead to successful RPC 204 requests in the future. Following are the yang-data structures 205 which may be returned: 207 establish-subscription returns hints in yang-data structure 208 ---------------------- ------------------------------------ 209 target: event stream establish-subscription-stream-error-info 210 target: datastore establish-subscription-datastore-error-info 212 modify-subscription returns hints in yang-data structure 213 ---------------------- ------------------------------------ 214 target: event stream modify-subscription-stream-error-info 215 target: datastore modify-subscription-datastore-error-info 217 The yang-data included within "error-info" SHOULD NOT include the 218 optional leaf "error-reason", as such a leaf would be redundant 219 with information that is already placed within the 220 "error-app-tag". 222 In case of an rpc error resulting from a "delete-subscription", 223 "kill-subscription", or "resynch-subscription" request, no 224 "error-info" needs to be included, as the "subscription-id" is 225 the only RPC input parameter and no hints regarding this RPC input 226 parameters need to be provided. 228 8. Security Considerations 230 If a malicious or buggy NETCONF subscriber sends a number of 231 establish-subscription requests, then these subscriptions accumulate 232 and may use up system resources. In such a situation, subscriptions 233 MAY be terminated by terminating the underlying NETCONF session. The 234 publisher MAY also suspend or terminate a subset of the active 235 subscriptions on that NETCONF session. 237 9. Acknowledgments 239 We wish to acknowledge the helpful contributions, comments, and 240 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 241 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 242 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, 243 and Guangying Zheng. 245 10. Notes to the RFC Editor 247 This section can be removed by the RFC editor after the requests have 248 been performed. 250 RFC 6241 need to be updated. RFC-6241 refers to RFC-5277 which says 251 that a notification message can only be sent after a successful 252 "create-subscription". This text must be modified to also allow 253 notification messages be sent after a successful "establish- 254 subscription". 256 11. References 258 11.1. Normative References 260 [I-D.draft-ietf-netconf-subscribed-notifications] 261 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 262 and E. Nilsen-Nygaard, "Customized Subscriptions to a 263 Publisher's Event Streams", draft-ietf-netconf-subscribed- 264 notifications-17 (work in progress), September 2018. 266 [I-D.ietf-netconf-yang-push] 267 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 268 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 269 Lengyel, "YANG Datastore Subscription", September 2018, 270 . 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 279 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 280 . 282 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 283 and A. Bierman, Ed., "Network Configuration Protocol 284 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 285 . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 11.2. Informative References 293 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 294 Zhang, "A YANG Data Model for the Virtual Router 295 Redundancy Protocol (VRRP)", RFC 8347, 296 DOI 10.17487/RFC8347, March 2018, 297 . 299 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 300 Version 1.0", November 1999, 301 . 303 Appendix A. Examples 305 This section is non-normative. 307 A.1. Event Stream Discovery 309 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 310 event stream exposes a continuous set of events available for 311 subscription. A NETCONF client can retrieve the list of available 312 event streams from a NETCONF publisher using the "get" operation 313 against the top-level container "/streams" defined in 314 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 316 The following example illustrates the retrieval of the list of 317 available event streams: 319 321 322 323 325 326 327 329 Figure 1: Get streams request 331 After such a request, the NETCONF publisher returns a list of event 332 streams available, as well as additional information which might 333 exist in the container. 335 A.2. Dynamic Subscriptions 337 A.2.1. Establishing Dynamic Subscriptions 339 The following figure shows two successful "establish-subscription" 340 RPC requests as per 341 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 342 is given a subscription "id" of 22, the second, an "id" of 23. 344 +------------+ +-----------+ 345 | Subscriber | | Publisher | 346 +------------+ +-----------+ 347 | | 348 | Capability Exchange | 349 |<---------------------------->| 350 | | 351 | | 352 | establish-subscription | 353 |----------------------------->| (a) 354 | RPC Reply: OK, id = 22 | 355 |<-----------------------------| (b) 356 | | 357 | notification message (for 22)| 358 |<-----------------------------| 359 | | 360 | | 361 | establish-subscription | 362 |----------------------------->| 363 | notification message (for 22)| 364 |<-----------------------------| 365 | RPC Reply: OK, id = 23 | 366 |<-----------------------------| 367 | | 368 | | 369 | notification message (for 22)| 370 |<-----------------------------| 371 | notification message (for 23)| 372 |<-----------------------------| 373 | | 375 Figure 2: Multiple subscriptions over a NETCONF session 377 To provide examples of the information being transported, example 378 messages for interactions (a) and (b) in Figure 2 are detailed below: 380 381 383 NETCONF 384 385 /ds:foo/ 386 387 10 388 389 391 Figure 3: establish-subscription request (a) 393 As NETCONF publisher was able to fully satisfy the request (a), the 394 publisher sends the subscription "id" of the accepted subscription 395 within message (b): 397 399 401 22 402 403 405 Figure 4: establish-subscription success (b) 407 If the NETCONF publisher had not been able to fully satisfy the 408 request, or subscriber has no authorization to establish the 409 subscription, the publisher would have sent an RPC error response. 410 For instance, if the "dscp" value of 10 asserted by the subscriber in 411 Figure 3 proved unacceptable, the publisher may have returned: 413 415 416 application 417 operation-failed 418 error 419 420 ietf-subscribed-notifications:dscp-unavailable 421 422 423 425 Figure 5: an unsuccessful establish subscription 427 The subscriber can use this information in future attempts to 428 establish a subscription. 430 A.2.2. Modifying Dynamic Subscriptions 432 An existing subscription may be modified. The following exchange 433 shows a negotiation of such a modification via several exchanges 434 between a subscriber and a publisher. This negotiation consists of a 435 failed RPC modification request/response, followed by a successful 436 one. 438 +------------+ +-----------+ 439 | Subscriber | | Publisher | 440 +------------+ +-----------+ 441 | | 442 | notification message (for 23)| 443 |<-----------------------------| 444 | | 445 | modify-subscription (id = 23)| 446 |----------------------------->| (c) 447 | RPC error (with hint) | 448 |<-----------------------------| (d) 449 | | 450 | modify-subscription (id = 23)| 451 |----------------------------->| 452 | RPC Reply: OK | 453 |<-----------------------------| 454 | | 455 | notification message (for 23)| 456 |<-----------------------------| 457 | | 459 Figure 6: Interaction model for successful subscription modification 461 If the subscription being modified in Figure 6 is a datastore 462 subscription as per [I-D.ietf-netconf-yang-push], the modification 463 request made in (c) may look like that shown in Figure 7. As can be 464 seen, the modifications being attempted are the application of a new 465 xpath filter as well as the setting of a new periodic time interval. 467 469 472 23 473 474 /ds:foo/ds:bar 475 476 477 500 478 479 480 482 Figure 7: Subscription modification request (c) 484 If the NETCONF publisher can satisfy both changes, the publisher 485 sends a positive result for the RPC. If the NETCONF publisher cannot 486 satisfy either of the proposed changes, the publisher sends an RPC 487 error response (d). The following is an example RPC error response 488 for (d) which includes a hint. This hint is an alternative time 489 period value which might have resulted in a successful modification: 491 493 494 application 495 operation-failed 496 error 497 498 ietf-yang-push:period-unsupported 499 500 502 503 504 3000 505 506 507 508 509 511 Figure 8: Modify subscription failure with Hint (d) 513 A.2.3. Deleting Dynamic Subscriptions 515 The following demonstrates deleting a subscription. This 516 subscription may have been to either a stream or a datastore. 518 520 522 22 523 524 526 Figure 9: Delete subscription 528 If the NETCONF publisher can satisfy the request, the publisher 529 replies with success to the RPC request. 531 If the NETCONF publisher cannot satisfy the request, the publisher 532 sends an error-rpc element indicating the modification didn't work. 533 Figure 10 shows a valid response for existing valid subscription 534 "id", but that subscription "id" was created on a different NETCONF 535 transport session: 537 539 540 application 541 operation-failed 542 error 543 544 ietf-subscribed-notifications:no-such-subscription 545 546 547 549 Figure 10: Unsuccessful delete subscription 551 A.3. Subscription State Notifications 553 A publisher will send subscription state notifications for dynamic 554 subscriptions according to the definitions within 555 [I-D.draft-ietf-netconf-subscribed-notifications]). 557 A.3.1. subscription-modified 559 As per Section 2.7.2 of 560 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 561 modified" might be sent if over NETCONF if the definition of a 562 configured filter changes. A subscription state notification encoded 563 in XML would look like: 565 566 2007-09-01T10:00:00Z 567 569 39 570 572 nsn:netconf 573 574 575 /ex:foo 576 577 NETCONF 578 579 581 Figure 11: subscription-modified subscription state notification 583 A.3.2. subscription-resumed, and replay-complete 585 A "subscription-resumed" would look like: 587 589 2007-09-01T10:00:00Z 590 592 39 593 594 596 Figure 12: subscription-resumed notification in XML 598 The "replay-complete" is virtually identical, with "subscription- 599 resumed" simply being replaced by "replay-complete". 601 A.3.3. subscription-terminated and subscription-suspended 603 A "subscription-terminated" would look like: 605 607 2007-09-01T10:00:00Z 608 610 39 611 612 suspension-timeout 613 614 615 617 Figure 13: subscription-terminated subscription state notification 619 The "subscription-suspended" is virtually identical, with 620 "subscription-terminated" simply being replaced by "subscription- 621 suspended". 623 A.4. Filter Examples 625 This section provides examples which illustrate both xpath and 626 subtree methods of filtering event record contents. The examples are 627 based on the YANG notification "vrrp-protocol-error-event" as defined 628 per the ietf-vrrp.yang model within [RFC8347]. Event records based 629 on this specification which are generated by the publisher might 630 appear as: 632 633 2018-09-14T08:22:33.44Z 634 636 checksum-error 637 638 640 Figure 14: RFC 8347 (VRRP) - Example Notification 642 Suppose a subscriber wanted to establish a subscription which only 643 passes instances of event records where there is a "checksum-error" 644 as part of a VRRP protocol event. Also assume the publisher places 645 such event records into the NETCONF stream. To get a continuous 646 series of matching event records, the subscriber might request the 647 application of an XPath filter against the NETCONF stream. An 648 "establish-subscription" RPC to meet this objective might be: 650 651 653 NETCONF 654 655 /vrrp-protocol-error-event[protocol-error-reason="checksum-error"] 656 657 658 660 Figure 15: Establishing a subscription error reason via XPATH 662 For more examples of xpath filters, see [XPATH]. 664 Suppose the "establish-subscription" in Figure 15 was accepted. And 665 suppose later a subscriber decided they wanted to broaden this 666 subscription cover to all VRRP protocol events (i.e., not just those 667 with a "checksum error"). The subscriber might attempt to modify the 668 subscription in a way which replaces the XPath filter with a subtree 669 filter which sends all VRRP protocol events to a subscriber. Such a 670 "modify-subscription" RPC might look like: 672 673 675 99 676 677 679 680 681 683 Figure 16 685 For more examples of subtree filters, see [RFC6241], section 6.4. 687 Appendix B. Changes between revisions 689 (To be removed by RFC editor prior to publication) 691 B.1. v11 to v13 693 o Subscription identifier renamed to id. 694 o Appendix A.4 for filter examples 695 o for v13, Tweak of example to /foo/bar 697 B.2. v10 to v11 699 o Configured removed. 701 B.3. v09 to v10 703 o Tweaks to examples and text. 704 o Downshifted state names. 705 o Removed address from examples. 707 B.4. v08 to v09 709 o Tweaks based on Kent's comments. 710 o Updated examples in Appendix A. And updates to some object names 711 based on changes in the subscribed-notifications draft. 712 o Added a YANG model for the NETCONF identity. 714 B.5. v07 to v08 716 o Tweaks and clarification on :interleave. 718 B.6. v06 to v07 720 o XML encoding and operational datastore mandatory. 721 o Error mechanisms and examples updated. 723 B.7. v05 to v06 725 o Moved examples to appendices 726 o All examples rewritten based on namespace learnings 727 o Normative text consolidated in front 728 o Removed all mention of JSON 729 o Call home process detailed 730 o Note: this is a major revision attempting to cover those comments 731 received from two week review. 733 B.8. v03 to v04 735 o Added additional detail to "configured subscriptions" 736 o Added interleave capability 737 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 738 notifications 739 o Corrected namespaces in examples 741 B.9. v01 to v03 743 o Text simplifications throughout 744 o v02 had no meaningful changes 746 B.10. v00 to v01 748 o Added Call Home in solution for configured subscriptions. 749 o Clarified support for multiple subscription on a single session. 750 No need to support multiple create-subscription. 751 o Added mapping between terminology in yang-push and [RFC6241] (the 752 one followed in this document). 753 o Editorial improvements. 755 Authors' Addresses 757 Eric Voit 758 Cisco Systems 760 Email: evoit@cisco.com 762 Alexander Clemm 763 Huawei 765 Email: ludwig@clemm.org 767 Alberto Gonzalez Prieto 768 Microsoft 770 Email: alberto.gonzalez@microsoft.com 772 Einar Nilsen-Nygaard 773 Cisco Systems 775 Email: einarnn@cisco.com 777 Ambika Prasad Tripathy 778 Cisco Systems 780 Email: ambtripa@cisco.com