idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-16.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: '...ription estab...' == Line 200 has weird spacing: '...ription res...' == Line 212 has weird spacing: '... stream esta...' == Line 215 has weird spacing: '...ription ret...' == Line 217 has weird spacing: '... stream modi...' -- The document date (January 8, 2019) is 1936 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 (~~), 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: July 12, 2019 Huawei 6 A. Gonzalez Prieto 7 Microsoft 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 January 8, 2019 13 Dynamic subscription to YANG Events and Datastores over NETCONF 14 draft-ietf-netconf-netconf-event-notifications-16 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 July 12, 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 . . . . . . . . . . . . . . . . . . . 6 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 12.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 73 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 8 74 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 8 75 A.3. Subscription State Notifications . . . . . . . . . . . . 13 76 A.4. Filter Examples . . . . . . . . . . . . . . . . . . . . . 14 77 Appendix B. Changes between revisions . . . . . . . . . . . . . 16 78 B.1. v15 to v16 . . . . . . . . . . . . . . . . . . . . . . . 16 79 B.2. v14 to v15 . . . . . . . . . . . . . . . . . . . . . . . 16 80 B.3. v13 to v14 . . . . . . . . . . . . . . . . . . . . . . . 16 81 B.4. v11 to v13 . . . . . . . . . . . . . . . . . . . . . . . 16 82 B.5. v10 to v11 . . . . . . . . . . . . . . . . . . . . . . . 16 83 B.6. v09 to v10 . . . . . . . . . . . . . . . . . . . . . . . 17 84 B.7. v08 to v09 . . . . . . . . . . . . . . . . . . . . . . . 17 85 B.8. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 17 86 B.9. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 17 87 B.10. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 17 88 B.11. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 17 89 B.12. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 17 90 B.13. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 This document provides a binding for events streamed over the NETCONF 96 protocol [RFC6241] for dynamic subscriptions as defined in 97 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as 98 [I-D.ietf-netconf-yang-push] is itself built upon 99 [I-D.draft-ietf-netconf-subscribed-notifications], this document 100 enables a NETCONF client to request via a dynamic subscription and 101 receive updates from a YANG datastore located on a NETCONF server. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 The following terms are defined in 112 [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic 113 subscription, event stream, notification message, publisher, 114 receiver, subscriber, subscription. No additional terms are defined. 116 3. Compatibility with RFC-5277's create-subscription 118 A publisher is allowed to concurrently support dynamic subscription 119 RPCs of [I-D.draft-ietf-netconf-subscribed-notifications] at the same 120 time as [RFC5277]'s "create-subscription" RPC. However a single 121 NETCONF transport session cannot support both this specification and 122 a subscription established by [RFC5277]'s "create-subscription" RPC. 123 To protect against any attempts to use a single NETCONF transport 124 session in this way: 126 o A solution must reply with the [RFC6241] error "operation-not- 127 supported" if a "create-subscription" RPC is received on a NETCONF 128 session where an [I-D.draft-ietf-netconf-subscribed-notifications] 129 established subscription exists. 130 o A solution must reply with the [RFC6241] error "operation-not- 131 supported" if an "establish-subscription" request has been 132 received on a NETCONF session where the "create-subscription" RPC 133 has successfully [RFC5277] created a subscription. 135 If a publisher supports this specification but not subscriptions via 136 [RFC5277], the publisher MUST NOT advertise 137 "urn:ietf:params:netconf:capability:notification:1.0". 139 4. Mandatory XML, event stream and datastore support 141 The "encode-xml" feature of 142 [I-D.draft-ietf-netconf-subscribed-notifications] MUST be supported. 143 This indicates that XML is a valid encoding for RPCs, state change 144 notifications, and subscribed content. 146 A NETCONF publisher supporting event stream subscription via 147 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 148 "NETCONF" event stream identified in that document. 150 5. NETCONF connectivity and the Dynamic Subscriptions 152 For a dynamic subscription, if the NETCONF session involved with the 153 "establish-subscription" terminates the subscription MUST be 154 terminated. 156 For a dynamic subscription, any "modify-subscription", "delete- 157 subscription", or "resynch-subscription" RPCs MUST be sent using the 158 same NETCONF session upon which the referenced subscription was 159 established. 161 6. Notification Messages 163 Notification messages transported over the NETCONF protocol MUST be 164 encoded in a message as defined within [RFC5277], 165 Section 4. And per [RFC5277]'s "eventTime" object definition, the 166 "eventTime" MUST be populated with the event occurrence time. 168 For dynamic subscriptions, all notification messages MUST use the 169 NETCONF transport session used by the "establish-subscription" RPC. 171 7. Dynamic Subscriptions and RPC Error Responses 173 Management of dynamic subscriptions occurs via RPCs as defined in 174 [I-D.ietf-netconf-yang-push] and 175 [I-D.draft-ietf-netconf-subscribed-notifications]. When an RPC error 176 occurs, the NETCONF RPC reply MUST include an "rpc-error" element per 177 [RFC6241] with the error information populated as follows: 179 o an "error-type" node of "application". 180 o an "error-tag" node of "operation-failed". 181 o an "error-severity" of "error" (this MAY but does not have to be 182 included). 183 o an "error-app-tag" node with the value being a string that 184 corresponds to an identity associated with the error, as defined 185 in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 186 for general subscriptions, and [I-D.ietf-netconf-yang-push] 187 Appendix A.1, for datastore subscriptions. The specific identity 188 to use depends on the RPC for which the error occurred. Each 189 error identity will be inserted as the "error-app-tag" following 190 the form :. An example of such as valid 191 encoding would be "ietf-subscribed-notifications:no-such- 192 subscription". Viable errors for different RPCs are as follows: 194 RPC use base identity 195 ---------------------- ---------------------------- 196 establish-subscription establish-subscription-error 197 modify-subscription modify-subscription-error 198 delete-subscription delete-subscription-error 199 kill-subscription kill-subscription-error 200 resynch-subscription resynch-subscription-error 202 o In case of error responses to an "establish-subscription" or 203 "modify-subscription" request there is the option of including an 204 "error-info" node. This node may contain XML-encoded data with 205 hints for parameter settings that might lead to successful RPC 206 requests in the future. Following are the yang-data structures 207 from [I-D.draft-ietf-netconf-subscribed-notifications] and 208 [I-D.ietf-netconf-yang-push] which may be returned: 210 establish-subscription returns hints in yang-data structure 211 ---------------------- ------------------------------------ 212 target: event stream establish-subscription-stream-error-info 213 target: datastore establish-subscription-datastore-error-info 215 modify-subscription returns hints in yang-data structure 216 ---------------------- ------------------------------------ 217 target: event stream modify-subscription-stream-error-info 218 target: datastore modify-subscription-datastore-error-info 220 The yang-data included within "error-info" SHOULD NOT include the 221 optional leaf "error-reason", as such a leaf would be redundant 222 with information that is already placed within the 223 "error-app-tag". 225 In case of an rpc error resulting from a "delete-subscription", 226 "kill-subscription", or "resynch-subscription" request, no "error- 227 info" needs to be included, as the "subscription-id" is the only RPC 228 input parameter and no hints regarding this RPC input parameters need 229 to be provided. 231 8. Security Considerations 233 If a malicious or buggy NETCONF subscriber sends a number of 234 establish-subscription requests, then these subscriptions accumulate 235 and may use up system resources. In such a situation, subscriptions 236 MAY be terminated by terminating the underlying NETCONF session. The 237 publisher MAY also suspend or terminate a subset of the active 238 subscriptions on that NETCONF session. 240 9. IANA Considerations 242 This document has no actions for IANA. 244 10. Acknowledgments 246 We wish to acknowledge the helpful contributions, comments, and 247 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 248 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 249 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, 250 Qin Wu, and Guangying Zheng. 252 11. Notes to the RFC Editor 254 This section can be removed by the RFC editor after the requests have 255 been performed. 257 RFC 6241 needs to be updated based on the needs of this draft. 258 RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it 259 identifies RFC 5717, but that was an error fixed after RFC 260 publication). Anyway the current phrasing in RFC-5277 says that a 261 notification message can only be sent after a successful "create- 262 subscription". Therefore the reference text must be modified to also 263 allow notification messages be sent after a successful "establish- 264 subscription". Proposed text for bullet (2) of RFC-6241 would be: 266 (2) The Messages layer provides a simple, transport-independent 267 framing mechanism for encoding RPCs and notifications. 268 Section 4 documents the RPC messages, [RFC5277] documents 269 Notifications sent as a result of a RPC, 270 and [RFC xxxx] documents Notifications sent as a result of 271 an RPC. 273 (where xxxx is replaced with this RFC number) 275 12. References 277 12.1. Normative References 279 [I-D.draft-ietf-netconf-subscribed-notifications] 280 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 281 and E. Nilsen-Nygaard, "Customized Subscriptions to a 282 Publisher's Event Streams", September 2018, 283 . 286 [I-D.ietf-netconf-yang-push] 287 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 288 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 289 Lengyel, "YANG Datastore Subscription", September 2018, 290 . 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 299 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 300 . 302 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 303 and A. Bierman, Ed., "Network Configuration Protocol 304 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 305 . 307 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 309 May 2017, . 311 12.2. Informative References 313 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. 314 Zhang, "A YANG Data Model for the Virtual Router 315 Redundancy Protocol (VRRP)", RFC 8347, 316 DOI 10.17487/RFC8347, March 2018, 317 . 319 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 320 Version 1.0", November 1999, 321 . 323 Appendix A. Examples 325 This section is non-normative. 327 A.1. Event Stream Discovery 329 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 330 event stream exposes a continuous set of events available for 331 subscription. A NETCONF client can retrieve the list of available 332 event streams from a NETCONF publisher using the "get" operation 333 against the top-level container "/streams" defined in 334 [I-D.draft-ietf-netconf-subscribed-notifications] Section 3.1. 336 The following example illustrates the retrieval of the list of 337 available event streams: 339 341 342 343 345 346 347 349 Figure 1: Get streams request 351 After such a request, the NETCONF publisher returns a list of event 352 streams available, as well as additional information which might 353 exist in the container. 355 A.2. Dynamic Subscriptions 357 A.2.1. Establishing Dynamic Subscriptions 359 The following figure shows two successful "establish-subscription" 360 RPC requests as per 361 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request 362 is given a subscription "id" of 22, the second, an "id" of 23. 364 +------------+ +-----------+ 365 | Subscriber | | Publisher | 366 +------------+ +-----------+ 367 | | 368 | Capability Exchange | 369 |<---------------------------->| 370 | | 371 | | 372 | establish-subscription | 373 |----------------------------->| (a) 374 | RPC Reply: OK, id = 22 | 375 |<-----------------------------| (b) 376 | | 377 | notification message (for 22)| 378 |<-----------------------------| 379 | | 380 | | 381 | establish-subscription | 382 |----------------------------->| 383 | notification message (for 22)| 384 |<-----------------------------| 385 | RPC Reply: OK, id = 23 | 386 |<-----------------------------| 387 | | 388 | | 389 | notification message (for 22)| 390 |<-----------------------------| 391 | notification message (for 23)| 392 |<-----------------------------| 393 | | 395 Figure 2: Multiple subscriptions over a NETCONF session 397 To provide examples of the information being transported, example 398 messages for interactions (a) and (b) in Figure 2 are detailed below: 400 401 403 NETCONF 404 405 /ds:foo/ 406 407 10 408 409 411 Figure 3: establish-subscription request (a) 413 As NETCONF publisher was able to fully satisfy the request (a), the 414 publisher sends the subscription "id" of the accepted subscription 415 within message (b): 417 419 421 22 422 423 425 Figure 4: establish-subscription success (b) 427 If the NETCONF publisher had not been able to fully satisfy the 428 request, or subscriber has no authorization to establish the 429 subscription, the publisher would have sent an RPC error response. 430 For instance, if the "dscp" value of 10 asserted by the subscriber in 431 Figure 3 proved unacceptable, the publisher may have returned: 433 435 436 application 437 operation-failed 438 error 439 440 ietf-subscribed-notifications:dscp-unavailable 441 442 443 445 Figure 5: an unsuccessful establish subscription 447 The subscriber can use this information in future attempts to 448 establish a subscription. 450 A.2.2. Modifying Dynamic Subscriptions 452 An existing subscription may be modified. The following exchange 453 shows a negotiation of such a modification via several exchanges 454 between a subscriber and a publisher. This negotiation consists of a 455 failed RPC modification request/response, followed by a successful 456 one. 458 +------------+ +-----------+ 459 | Subscriber | | Publisher | 460 +------------+ +-----------+ 461 | | 462 | notification message (for 23)| 463 |<-----------------------------| 464 | | 465 | modify-subscription (id = 23)| 466 |----------------------------->| (c) 467 | RPC error (with hint) | 468 |<-----------------------------| (d) 469 | | 470 | modify-subscription (id = 23)| 471 |----------------------------->| 472 | RPC Reply: OK | 473 |<-----------------------------| 474 | | 475 | notification message (for 23)| 476 |<-----------------------------| 477 | | 479 Figure 6: Interaction model for successful subscription modification 481 If the subscription being modified in Figure 6 is a datastore 482 subscription as per [I-D.ietf-netconf-yang-push], the modification 483 request made in (c) may look like that shown in Figure 7. As can be 484 seen, the modifications being attempted are the application of a new 485 XPath filter as well as the setting of a new periodic time interval. 487 489 492 23 493 494 /ds:foo/ds:bar 495 496 497 500 498 499 500 502 Figure 7: Subscription modification request (c) 504 If the NETCONF publisher can satisfy both changes, the publisher 505 sends a positive result for the RPC. If the NETCONF publisher cannot 506 satisfy either of the proposed changes, the publisher sends an RPC 507 error response (d). The following is an example RPC error response 508 for (d) which includes a hint. This hint is an alternative time 509 period value which might have resulted in a successful modification: 511 513 514 application 515 operation-failed 516 error 517 518 ietf-yang-push:period-unsupported 519 520 521 523 524 3000 525 526 527 528 529 531 Figure 8: Modify subscription failure with hint (d) 533 A.2.3. Deleting Dynamic Subscriptions 535 The following demonstrates deleting a subscription. This 536 subscription may have been to either a stream or a datastore. 538 540 542 22 543 544 546 Figure 9: Delete subscription 548 If the NETCONF publisher can satisfy the request, the publisher 549 replies with success to the RPC request. 551 If the NETCONF publisher cannot satisfy the request, the publisher 552 sends an error-rpc element indicating the modification didn't work. 553 Figure 10 shows a valid response for existing valid subscription 554 "id", but that subscription "id" was created on a different NETCONF 555 transport session: 557 559 560 application 561 operation-failed 562 error 563 564 ietf-subscribed-notifications:no-such-subscription 565 566 567 569 Figure 10: Unsuccessful delete subscription 571 A.3. Subscription State Notifications 573 A publisher will send subscription state notifications for dynamic 574 subscriptions according to the definitions within 575 [I-D.draft-ietf-netconf-subscribed-notifications]. 577 A.3.1. subscription-modified 579 As per Section 2.7.2 of 580 [I-D.draft-ietf-netconf-subscribed-notifications], a "subscription- 581 modified" might be sent over NETCONF if the definition of a 582 configured filter changes. A subscription state notification encoded 583 in XML would look like: 585 586 2007-09-01T10:00:00Z 587 589 39 590 591 /ex:foo 592 593 NETCONF 594 595 597 Figure 11: subscription-modified subscription state notification 599 A.3.2. subscription-resumed, and replay-complete 601 A "subscription-resumed" would look like: 603 605 2007-09-01T10:00:00Z 606 608 39 609 610 612 Figure 12: subscription-resumed notification in XML 614 The "replay-complete" is virtually identical, with "subscription- 615 resumed" simply being replaced by "replay-complete". 617 A.3.3. subscription-terminated and subscription-suspended 619 A "subscription-terminated" would look like: 621 623 2007-09-01T10:00:00Z 624 626 39 627 628 suspension-timeout 629 630 631 633 Figure 13: subscription-terminated subscription state notification 635 The "subscription-suspended" is virtually identical, with 636 "subscription-terminated" simply being replaced by "subscription- 637 suspended". 639 A.4. Filter Examples 641 This section provides examples which illustrate both XPath and 642 subtree methods of filtering event record contents. The examples are 643 based on the YANG notification "vrrp-protocol-error-event" as defined 644 per the ietf-vrrp.yang model within [RFC8347]. Event records based 645 on this specification which are generated by the publisher might 646 appear as: 648 649 2018-09-14T08:22:33.44Z 650 652 checksum-error 653 654 656 Figure 14: RFC 8347 (VRRP) - Example Notification 658 Suppose a subscriber wanted to establish a subscription which only 659 passes instances of event records where there is a "checksum-error" 660 as part of a VRRP protocol event. Also assume the publisher places 661 such event records into the NETCONF stream. To get a continuous 662 series of matching event records, the subscriber might request the 663 application of an XPath filter against the NETCONF stream. An 664 "establish-subscription" RPC to meet this objective might be: 666 667 669 NETCONF 670 671 /vrrp-protocol-error-event[ 672 vrrp:protocol-error-reason="vrrp:checksum-error"] 673 674 675 677 Figure 15: Establishing a subscription error reason via XPath 679 For more examples of XPath filters, see [XPATH]. 681 Suppose the "establish-subscription" in Figure 15 was accepted. And 682 suppose later a subscriber decided they wanted to broaden this 683 subscription cover to all VRRP protocol events (i.e., not just those 684 with a "checksum error"). The subscriber might attempt to modify the 685 subscription in a way which replaces the XPath filter with a subtree 686 filter which sends all VRRP protocol events to a subscriber. Such a 687 "modify-subscription" RPC might look like: 689 690 692 99 693 694 696 697 698 700 Figure 16 702 For more examples of subtree filters, see [RFC6241], section 6.4. 704 Appendix B. Changes between revisions 706 (To be removed by RFC editor prior to publication) 708 B.1. v15 to v16 710 o During the shepherd review, two clarifications were requested 711 which do not impact the technical details of this document. These 712 clarifications were: (a) further describing that dynamic 713 subscriptions can have state change notifications, and (b) more 714 details about the recommended text refinement desired for RFC6241. 716 B.2. v14 to v15 718 o Per Kent's request, added name attribute to artwork. This would 719 be needed for an automated extraction. 721 B.3. v13 to v14 723 o Title change. 725 B.4. v11 to v13 727 o Subscription identifier renamed to id. 728 o Appendix A.4 for filter examples 729 o for v13, Tweak of example to /foo/bar 731 B.5. v10 to v11 733 o Configured removed. 735 B.6. v09 to v10 737 o Tweaks to examples and text. 738 o Downshifted state names. 739 o Removed address from examples. 741 B.7. v08 to v09 743 o Tweaks based on Kent's comments. 744 o Updated examples in Appendix A. And updates to some object names 745 based on changes in the subscribed-notifications draft. 746 o Added a YANG model for the NETCONF identity. 748 B.8. v07 to v08 750 o Tweaks and clarification on :interleave. 752 B.9. v06 to v07 754 o XML encoding and operational datastore mandatory. 755 o Error mechanisms and examples updated. 757 B.10. v05 to v06 759 o Moved examples to appendices 760 o All examples rewritten based on namespace learnings 761 o Normative text consolidated in front 762 o Removed all mention of JSON 763 o Call home process detailed 764 o Note: this is a major revision attempting to cover those comments 765 received from two week review. 767 B.11. v03 to v04 769 o Added additional detail to "configured subscriptions" 770 o Added interleave capability 771 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 772 notifications 773 o Corrected namespaces in examples 775 B.12. v01 to v03 777 o Text simplifications throughout 778 o v02 had no meaningful changes 780 B.13. v00 to v01 782 o Added Call Home in solution for configured subscriptions. 783 o Clarified support for multiple subscription on a single session. 784 No need to support multiple create-subscription. 785 o Added mapping between terminology in yang-push and [RFC6241] (the 786 one followed in this document). 787 o Editorial improvements. 789 Authors' Addresses 791 Eric Voit 792 Cisco Systems 794 Email: evoit@cisco.com 796 Alexander Clemm 797 Huawei 799 Email: ludwig@clemm.org 801 Alberto Gonzalez Prieto 802 Microsoft 804 Email: alberto.gonzalez@microsoft.com 806 Einar Nilsen-Nygaard 807 Cisco Systems 809 Email: einarnn@cisco.com 811 Ambika Prasad Tripathy 812 Cisco Systems 814 Email: ambtripa@cisco.com