idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-14.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 193 has weird spacing: '...ription estab...' == Line 197 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 23, 2018) is 2010 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: 1 error (**), 0 flaws (~~), 6 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 26, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 October 23, 2018 13 Dynamic subscription to YANG Events and Datastores over NETCONF 14 draft-ietf-netconf-netconf-event-notifications-14 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 26, 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. v13 to v14 . . . . . . . . . . . . . . . . . . . . . . . 15 78 B.2. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 16 79 B.3. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 16 80 B.4. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 16 81 B.5. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 16 82 B.6. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 16 83 B.7. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 16 84 B.8. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 16 85 B.9. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 16 86 B.10. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 17 87 B.11. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 This document provides a binding for events streamed over the NETCONF 93 protocol [RFC6241] for dynamic subscriptions as defined in 94 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 95 [I-D.ietf-netconf-yang-push] is itself built upon 96 [I-D.draft-ietf-netconf-subscribed-notifications], this document 97 enables a NETCONF client to request via a dynamic subscription and 98 receive updates from a YANG datastore located on a NETCONF server. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 The following terms are defined in 109 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 110 subscription, event stream, notification message, publisher, 111 receiver, subscriber, subscription. No additional terms are defined. 113 3. Compatibility with RFC-5277's create-subscription 115 A publisher is allowed to concurrently support dynamic subscription 116 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 117 time as [RFC5277]'s "create-subscription" RPC. However a single 118 NETCONF transport session cannot support both this specification and 119 a subscription established by [RFC5277]'s "create-subscription" RPC. 120 To protect against any attempts to use a single NETCONF transport 121 session in this way: 123 o A solution must reply with the [RFC6241] error "operation-not- 124 supported" if a "create-subscription" RPC is received on a NETCONF 125 session where an [I-D.draft-ietf-netconf-subscribed-notifications] 126 established subscription exists. 127 o A solution must reply with the [RFC6241] error "operation-not- 128 supported" if an "establish-subscription" request has been 129 received on a NETCONF session where the "create-subscription" RPC 130 has successfully [RFC5277] created a subscription. 132 If a publisher supports this specification but not subscriptions via 133 [RFC5277], the publisher MUST NOT advertise 134 "urn:ietf:params:netconf:capability:notification:1.0". 136 4. Mandatory XML, event stream and datastore support 138 The "encode-xml" feature of 139 [I-D.draft-ietf-netconf-subscribed-notifications] MUST be supported. 140 This indicates that XML is a valid encoding for RPCs, state change 141 notifications, and subscribed content. 143 A NETCONF publisher supporting event stream subscription via 144 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 145 "NETCONF" event stream identified in that document. 147 5. NETCONF connectivity and the Dynamic Subscriptions 149 For a dynamic subscription, if the NETCONF session involved with the 150 "establish-subscription" terminates the subscription MUST be 151 terminated. 153 For a dynamic subscription, any "modify-subscription", "delete- 154 subscription", or "resynch-subscription" RPCs MUST be sent using the 155 same NETCONF session upon which the referenced subscription was 156 established. 158 6. Notification Messages 160 Notification messages transported over the NETCONF protocol MUST be 161 encoded in a message as defined within [RFC5277], 162 Section 4. And per [RFC5277]'s "eventTime" object definition, the 163 "eventTime" MUST be populated with the event occurrence time. 165 For dynamic subscriptions, all notification messages MUST use the 166 NETCONF transport session used by the "establish-subscription" RPC. 168 7. Dynamic Subscriptions and RPC Error Responses 170 Management of dynamic subscriptions occurs via RPCs as defined in 171 [I-D.ietf-netconf-yang-push] and 172 [I-D.draft-ietf-netconf-subscribed-notifications]. When an RPC error 173 occurs, the NETCONF RPC reply MUST include an "rpc-error" element per 174 [RFC6241] with the error information populated as follows: 176 o an "error-type" node of "application". 177 o an "error-tag" node of "operation-failed". 178 o an "error-severity" of "error" (this MAY but does not have to be 179 included). 180 o an "error-app-tag" node with the value being a string that 181 corresponds to an identity associated with the error, as defined 182 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 183 for general subscriptions, and [I-D.ietf-netconf-yang-push] 184 Appendix A.1, for datastore subscriptions. The specific identity 185 to use depends on the RPC for which the error occurred. Each 186 error identity will be inserted as the "error-app-tag" following 187 the form :. An example of such as valid 188 encoding would be "ietf-subscribed-notifications:no-such- 189 subscription". Viable errors for different RPCs are as follows: 191 RPC use base identity 192 ---------------------- ---------------------------- 193 establish-subscription establish-subscription-error 194 modify-subscription modify-subscription-error 195 delete-subscription delete-subscription-error 196 kill-subscription kill-subscription-error 197 resynch-subscription resynch-subscription-error 199 o In case of error responses to an "establish-subscription" or 200 "modify-subscription" request there is the option of including an 201 "error-info" node. This node may contain XML-encoded data with 202 hints for parameter settings that might lead to successful RPC 203 requests in the future. Following are the yang-data structures 204 from [I-D.draft-ietf-netconf-subscribed-notifications] and 205 [I-D.ietf-netconf-yang-push] 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 "error- 224 info" needs to be included, as the "subscription-id" is the only RPC 225 input parameter and no hints regarding this RPC input parameters need 226 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", September 2018, 264 . 267 [I-D.ietf-netconf-yang-push] 268 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 269 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 270 Lengyel, "YANG Datastore Subscription", September 2018, 271 . 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 280 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 281 . 283 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 284 and A. Bierman, Ed., "Network Configuration Protocol 285 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 286 . 288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 290 May 2017, . 292 11.2. Informative References 294 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 295 Zhang, "A YANG Data Model for the Virtual Router 296 Redundancy Protocol (VRRP)", RFC 8347, 297 DOI 10.17487/RFC8347, March 2018, 298 . 300 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 301 Version 1.0", November 1999, 302 . 304 Appendix A. Examples 306 This section is non-normative. 308 A.1. Event Stream Discovery 310 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 311 event stream exposes a continuous set of events available for 312 subscription. A NETCONF client can retrieve the list of available 313 event streams from a NETCONF publisher using the "get" operation 314 against the top-level container "/streams" defined in 315 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 317 The following example illustrates the retrieval of the list of 318 available event streams: 320 322 323 324 326 327 328 330 Figure 1: Get streams request 332 After such a request, the NETCONF publisher returns a list of event 333 streams available, as well as additional information which might 334 exist in the container. 336 A.2. Dynamic Subscriptions 338 A.2.1. Establishing Dynamic Subscriptions 340 The following figure shows two successful "establish-subscription" 341 RPC requests as per 342 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 343 is given a subscription "id" of 22, the second, an "id" of 23. 345 +------------+ +-----------+ 346 | Subscriber | | Publisher | 347 +------------+ +-----------+ 348 | | 349 | Capability Exchange | 350 |<---------------------------->| 351 | | 352 | | 353 | establish-subscription | 354 |----------------------------->| (a) 355 | RPC Reply: OK, id = 22 | 356 |<-----------------------------| (b) 357 | | 358 | notification message (for 22)| 359 |<-----------------------------| 360 | | 361 | | 362 | establish-subscription | 363 |----------------------------->| 364 | notification message (for 22)| 365 |<-----------------------------| 366 | RPC Reply: OK, id = 23 | 367 |<-----------------------------| 368 | | 369 | | 370 | notification message (for 22)| 371 |<-----------------------------| 372 | notification message (for 23)| 373 |<-----------------------------| 374 | | 376 Figure 2: Multiple subscriptions over a NETCONF session 378 To provide examples of the information being transported, example 379 messages for interactions (a) and (b) in Figure 2 are detailed below: 381 382 384 NETCONF 385 386 /ds:foo/ 387 388 10 389 390 392 Figure 3: establish-subscription request (a) 394 As NETCONF publisher was able to fully satisfy the request (a), the 395 publisher sends the subscription "id" of the accepted subscription 396 within message (b): 398 400 402 22 403 404 406 Figure 4: establish-subscription success (b) 408 If the NETCONF publisher had not been able to fully satisfy the 409 request, or subscriber has no authorization to establish the 410 subscription, the publisher would have sent an RPC error response. 411 For instance, if the "dscp" value of 10 asserted by the subscriber in 412 Figure 3 proved unacceptable, the publisher may have returned: 414 416 417 application 418 operation-failed 419 error 420 421 ietf-subscribed-notifications:dscp-unavailable 422 423 424 426 Figure 5: an unsuccessful establish subscription 428 The subscriber can use this information in future attempts to 429 establish a subscription. 431 A.2.2. Modifying Dynamic Subscriptions 433 An existing subscription may be modified. The following exchange 434 shows a negotiation of such a modification via several exchanges 435 between a subscriber and a publisher. This negotiation consists of a 436 failed RPC modification request/response, followed by a successful 437 one. 439 +------------+ +-----------+ 440 | Subscriber | | Publisher | 441 +------------+ +-----------+ 442 | | 443 | notification message (for 23)| 444 |<-----------------------------| 445 | | 446 | modify-subscription (id = 23)| 447 |----------------------------->| (c) 448 | RPC error (with hint) | 449 |<-----------------------------| (d) 450 | | 451 | modify-subscription (id = 23)| 452 |----------------------------->| 453 | RPC Reply: OK | 454 |<-----------------------------| 455 | | 456 | notification message (for 23)| 457 |<-----------------------------| 458 | | 460 Figure 6: Interaction model for successful subscription modification 462 If the subscription being modified in Figure 6 is a datastore 463 subscription as per [I-D.ietf-netconf-yang-push], the modification 464 request made in (c) may look like that shown in Figure 7. As can be 465 seen, the modifications being attempted are the application of a new 466 XPath filter as well as the setting of a new periodic time interval. 468 470 473 23 474 475 /ds:foo/ds:bar 476 477 478 500 479 480 481 483 Figure 7: Subscription modification request (c) 485 If the NETCONF publisher can satisfy both changes, the publisher 486 sends a positive result for the RPC. If the NETCONF publisher cannot 487 satisfy either of the proposed changes, the publisher sends an RPC 488 error response (d). The following is an example RPC error response 489 for (d) which includes a hint. This hint is an alternative time 490 period value which might have resulted in a successful modification: 492 494 495 application 496 operation-failed 497 error 498 499 ietf-yang-push:period-unsupported 500 501 502 504 505 3000 506 507 508 509 510 512 Figure 8: Modify subscription failure with hint (d) 514 A.2.3. Deleting Dynamic Subscriptions 516 The following demonstrates deleting a subscription. This 517 subscription may have been to either a stream or a datastore. 519 521 523 22 524 525 527 Figure 9: Delete subscription 529 If the NETCONF publisher can satisfy the request, the publisher 530 replies with success to the RPC request. 532 If the NETCONF publisher cannot satisfy the request, the publisher 533 sends an error-rpc element indicating the modification didn't work. 534 Figure 10 shows a valid response for existing valid subscription 535 "id", but that subscription "id" was created on a different NETCONF 536 transport session: 538 540 541 application 542 operation-failed 543 error 544 545 ietf-subscribed-notifications:no-such-subscription 546 547 548 550 Figure 10: Unsuccessful delete subscription 552 A.3. Subscription State Notifications 554 A publisher will send subscription state notifications for dynamic 555 subscriptions according to the definitions within 556 [I-D.draft-ietf-netconf-subscribed-notifications]. 558 A.3.1. subscription-modified 560 As per Section 2.7.2 of 561 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 562 modified" might be sent over NETCONF if the definition of a 563 configured filter changes. A subscription state notification encoded 564 in XML would look like: 566 567 2007-09-01T10:00:00Z 568 570 39 571 572 /ex:foo 573 574 NETCONF 575 576 578 Figure 11: subscription-modified subscription state notification 580 A.3.2. subscription-resumed, and replay-complete 582 A "subscription-resumed" would look like: 584 586 2007-09-01T10:00:00Z 587 589 39 590 591 593 Figure 12: subscription-resumed notification in XML 595 The "replay-complete" is virtually identical, with "subscription- 596 resumed" simply being replaced by "replay-complete". 598 A.3.3. subscription-terminated and subscription-suspended 600 A "subscription-terminated" would look like: 602 604 2007-09-01T10:00:00Z 605 607 39 608 609 suspension-timeout 610 611 612 614 Figure 13: subscription-terminated subscription state notification 616 The "subscription-suspended" is virtually identical, with 617 "subscription-terminated" simply being replaced by "subscription- 618 suspended". 620 A.4. Filter Examples 622 This section provides examples which illustrate both XPath and 623 subtree methods of filtering event record contents. The examples are 624 based on the YANG notification "vrrp-protocol-error-event" as defined 625 per the ietf-vrrp.yang model within [RFC8347]. Event records based 626 on this specification which are generated by the publisher might 627 appear as: 629 630 2018-09-14T08:22:33.44Z 631 633 checksum-error 634 635 637 Figure 14: RFC 8347 (VRRP) - Example Notification 639 Suppose a subscriber wanted to establish a subscription which only 640 passes instances of event records where there is a "checksum-error" 641 as part of a VRRP protocol event. Also assume the publisher places 642 such event records into the NETCONF stream. To get a continuous 643 series of matching event records, the subscriber might request the 644 application of an XPath filter against the NETCONF stream. An 645 "establish-subscription" RPC to meet this objective might be: 647 648 650 NETCONF 651 652 /vrrp-protocol-error-event[ 653 vrrp:protocol-error-reason="vrrp:checksum-error"] 654 655 656 658 Figure 15: Establishing a subscription error reason via XPath 660 For more examples of XPath filters, see [XPATH]. 662 Suppose the "establish-subscription" in Figure 15 was accepted. And 663 suppose later a subscriber decided they wanted to broaden this 664 subscription cover to all VRRP protocol events (i.e., not just those 665 with a "checksum error"). The subscriber might attempt to modify the 666 subscription in a way which replaces the XPath filter with a subtree 667 filter which sends all VRRP protocol events to a subscriber. Such a 668 "modify-subscription" RPC might look like: 670 671 673 99 674 675 677 678 679 681 Figure 16 683 For more examples of subtree filters, see [RFC6241], section 6.4. 685 Appendix B. Changes between revisions 687 (To be removed by RFC editor prior to publication) 689 B.1. v13 to v14 691 o Title change. 693 B.2. v11 to v13 695 o Subscription identifier renamed to id. 696 o Appendix A.4 for filter examples 697 o for v13, Tweak of example to /foo/bar 699 B.3. v10 to v11 701 o Configured removed. 703 B.4. v09 to v10 705 o Tweaks to examples and text. 706 o Downshifted state names. 707 o Removed address from examples. 709 B.5. v08 to v09 711 o Tweaks based on Kent's comments. 712 o Updated examples in Appendix A. And updates to some object names 713 based on changes in the subscribed-notifications draft. 714 o Added a YANG model for the NETCONF identity. 716 B.6. v07 to v08 718 o Tweaks and clarification on :interleave. 720 B.7. v06 to v07 722 o XML encoding and operational datastore mandatory. 723 o Error mechanisms and examples updated. 725 B.8. v05 to v06 727 o Moved examples to appendices 728 o All examples rewritten based on namespace learnings 729 o Normative text consolidated in front 730 o Removed all mention of JSON 731 o Call home process detailed 732 o Note: this is a major revision attempting to cover those comments 733 received from two week review. 735 B.9. v03 to v04 737 o Added additional detail to "configured subscriptions" 738 o Added interleave capability 739 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 740 notifications 742 o Corrected namespaces in examples 744 B.10. v01 to v03 746 o Text simplifications throughout 747 o v02 had no meaningful changes 749 B.11. v00 to v01 751 o Added Call Home in solution for configured subscriptions. 752 o Clarified support for multiple subscription on a single session. 753 No need to support multiple create-subscription. 754 o Added mapping between terminology in yang-push and [RFC6241] (the 755 one followed in this document). 756 o Editorial improvements. 758 Authors' Addresses 760 Eric Voit 761 Cisco Systems 763 Email: evoit@cisco.com 765 Alexander Clemm 766 Huawei 768 Email: ludwig@clemm.org 770 Alberto Gonzalez Prieto 771 Microsoft 773 Email: alberto.gonzalez@microsoft.com 775 Einar Nilsen-Nygaard 776 Cisco Systems 778 Email: einarnn@cisco.com 780 Ambika Prasad Tripathy 781 Cisco Systems 783 Email: ambtripa@cisco.com