idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-06.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.) ** The abstract seems to contain references ([I-D.draft-ietf-netconf-subscribed-notifications]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2364 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-06 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF A. Gonzalez Prieto 3 Internet-Draft VMware 4 Intended status: Standards Track E. Voit 5 Expires: May 3, 2018 Cisco Systems 6 A. Clemm 7 Huawei 8 E. Nilsen-Nygaard 9 A. Tripathy 10 Cisco Systems 11 October 30, 2017 13 NETCONF Support for Event Notifications 14 draft-ietf-netconf-netconf-event-notifications-06 16 Abstract 18 This document provides a NETCONF binding for 19 [I-D.draft-ietf-netconf-subscribed-notifications]. Included are: 21 o Transport mappings for subscription RPCs, state change 22 notifications, and notification messages 24 o Functionality which must be supported with NETCONF 26 o Examples in appendices 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Interleave Capability . . . . . . . . . . . . . . . . . . . . 3 65 4. Mandatory stream and datastore support . . . . . . . . . . . 3 66 5. Transport connectivity . . . . . . . . . . . . . . . . . . . 4 67 5.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 4 68 5.2. Configured Subscriptions . . . . . . . . . . . . . . . . 4 69 6. Notification Messages . . . . . . . . . . . . . . . . . . . . 4 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 9.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6 76 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 6 77 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 7 78 A.3. Configured Subscriptions . . . . . . . . . . . . . . . . 12 79 A.4. Subscription State Notifications . . . . . . . . . . . . 17 80 Appendix B. Changes between revisions . . . . . . . . . . . . . 19 81 B.1. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 19 82 B.2. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 19 83 B.3. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 20 84 B.4. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 This document defines a binding for notification message delivery for 90 [I-D.draft-ietf-netconf-subscribed-notifications] transported over 91 the NETCONF protocol [RFC6241]. In addition, as 92 [I-D.ietf-netconf-yang-push] is itself built upon 94 [I-D.draft-ietf-netconf-subscribed-notifications], this document 95 enables a NETCONF client to maintain a subset/extract of an actively 96 changing YANG datastore located on a NETCONF server. 98 This document is broken into two main parts. The first contains 99 normative requirements which are incremental to 100 [I-D.draft-ietf-netconf-subscribed-notifications] when NETCONF 101 transport is used. The second are examples and are included as 102 appendices. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 The following terms are defined in 111 [I-D.draft-ietf-netconf-subscribed-notifications]: notification 112 message, stream, publisher, receiver, subscriber, subscription, 113 configured subscription. 115 3. Interleave Capability 117 To support multiple subscriptions on a single session, a NETCONF 118 publisher MUST support the :interleave capability as defined in 119 [RFC5277]. Such support MUST be indicated by the following 120 capability: "urn:ietf:params:netconf:capability:interleave:1.0". 121 Advertisement of this capability along with support 122 [I-D.draft-ietf-netconf-subscribed-notifications] will indicate that 123 a NETCONF publisher is able to receive, process, and respond to 124 NETCONF requests and 125 [I-D.draft-ietf-netconf-subscribed-notifications] subscription 126 operations on a session with active subscriptions. 128 4. Mandatory stream and datastore support 130 A NETCONF publisher supporting 131 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the 132 "NETCONF" event stream identified in that draft. 134 A NETCONF publisher supporting [I-D.ietf-netconf-yang-push] MUST 135 support the "running" datastore as defined by 136 [I.D.draft-ietf-netmod-revised-datastores]. 138 5. Transport connectivity 140 5.1. Dynamic Subscriptions 142 For dynamic subscriptions, if the NETCONF session involved with the 143 "establish-subscription" terminates, the subscription MUST be 144 deleted. 146 5.2. Configured Subscriptions 148 For a configured subscription, there is no guarantee a transport 149 session is currently in place with associated receiver(s). So where 150 a configured subscription has a receiver in the connecting state, but 151 no NETCONF transport exists to that receiver, the publisher MUST be 152 able to initiate a NETCONF transport session via NETCONF call home 153 [RFC8071], section 4.1 to that receiver. Until NETCONF connectivity 154 is established and a subscription-started state change notification 155 is successfully sent, that receiver MUST remain in its status of a 156 "connecting". 158 If the call home fails because the publisher receives receiver 159 credentials which are subsequently declined as part [RFC8071], 160 Section 4.1, step S5 authentication, then that receiver MUST be 161 assigned a "suspended" status. 163 If the call home fails to establish for any other reason, the 164 publisher MAY leave the receiver in a "connecting" status, and retry 165 the call home at a future time. Alternatively, the publisher MAY 166 place the receiver into a "suspended" status after a predetermined 167 number of call home attempts. 169 NETCONF Transport session connectivity SHOULD be verified via 170 Section 4.1, step S7. 172 Failure of an active NETCONF session MUST reset the restart the call 173 home process, and return the receiver to "connecting". 175 6. Notification Messages 177 Notification messages transported over NETCONF will be identical in 178 format and content to those encoded using one-way operations defined 179 within [RFC5277], section 4. 181 7. Security Considerations 183 Notification messages (including state change notifications) are 184 never sent before the NETCONF capabilities exchange has completed. 186 If a malicious or buggy NETCONF subscriber sends a number of 187 "establish-subscription" requests, then these subscriptions 188 accumulate and may use up system resources. In such a situation, 189 subscriptions MAY be terminated by terminating the suspect underlying 190 NETCONF sessions. The publisher MAY also suspend or terminate a 191 subset of the active subscriptions on the NETCONF session. 193 The NETCONF Authorization Control Model [RFC6536] SHOULD be used to 194 control and restrict authorization of subscription configuration. 196 8. Acknowledgments 198 We wish to acknowledge the helpful contributions, comments, and 199 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 200 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 201 Balazs Lengyel, Kent Watsen, and Guangying Zheng. 203 9. References 205 9.1. Normative References 207 [I-D.draft-ietf-netconf-subscribed-notifications] 208 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., 209 and E. Nilsen-Nygaard, "Custom Subscription to Event 210 Streams", draft-ietf-netconf-subscribed-notifications-06 211 (work in progress), October 2017. 213 [I-D.ietf-netconf-yang-push] 214 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., 215 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. 216 Lengyel, "YANG Datastore Subscription", October 2017, 217 . 220 [I.D.draft-ietf-netmod-revised-datastores] 221 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 222 and R. Wilton, "Network Management Datastore 223 Architecture", draft-ietf-netmod-revised-datastores-04 224 (work in progress), August 2017. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 232 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 233 . 235 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 236 and A. Bierman, Ed., "Network Configuration Protocol 237 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 238 . 240 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 241 Protocol (NETCONF) Access Control Model", RFC 6536, 242 DOI 10.17487/RFC6536, March 2012, 243 . 245 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 246 RFC 8071, DOI 10.17487/RFC8071, February 2017, 247 . 249 9.2. Informative References 251 [I.D.draft-ietf-netconf-notification-messages] 252 Voit, Eric., Clemm, Alexander., Bierman, A., and T. 253 Jenkins, "YANG Notification Headers and Bundles", 254 September 2017, . 257 Appendix A. Examples 259 A.1. Event Stream Discovery 261 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an 262 event stream exposes a continuous set of events available for 263 subscription. A NETCONF client can retrieve the list of available 264 event streams from a NETCONF publisher using the "get" operation 265 against the top-level container "/streams" defined in 266 [I-D.draft-ietf-netconf-subscribed-notifications]. Any reply will 267 include the stream identities supported on the NETCONF publisher 268 which may be available to that client. 270 The following example illustrates the retrieval of the list of 271 available event streams using the "get" operation. 273 275 276 277 279 280 281 283 Figure 1: Get streams request 285 After such a request, the NETCONF publisher returns a list of event 286 streams available. In the example reply below, the list contains 287 just the NETCONF stream. 289 291 292 294 NETCONF 295 296 297 299 Figure 2: Get streams response 301 A.2. Dynamic Subscriptions 303 The dynamic subscription RPCs and interactions operation are defined 304 in [I-D.draft-ietf-netconf-subscribed-notifications] and enhanced in 305 [I-D.ietf-netconf-yang-push]. 307 A.2.1. Establishing Dynamic Subscriptions 309 An example of establish-subscription interactions over NETCONF 310 transport for a sample subscription is described below: 312 314 316 317 NETCONF 318 319 /ex:foo 320 321 322 323 325 Figure 3: establish-subscription over NETCONF 327 If the NETCONF publisher can satisfy the request, the publisher sends 328 a positive "subscription-result" element, and the subscription-id of 329 the accepted subscription. 331 333 335 ok 336 337 339 22 340 341 343 Figure 4: Successful establish-subscription 345 If the NETCONF publisher cannot satisfy the request, or subscriber 346 has no authorization to establish the subscription, the publisher 347 will send a negative "subscription-result" element. For instance: 349 351 353 stream-unavailable 354 355 357 Figure 5: Unsuccessful establish subscription 359 To get an idea of the interaction model, the following figure shows 360 two separate establish subscriptions RPC being made. The first is 361 given subscription id 22, the second, id 23. 363 +------------+ +-----------+ 364 | Subscriber | | Publisher | 365 +------------+ +-----------+ 366 | | 367 | Capability Exchange | 368 |<---------------------------->| 369 | | 370 | | 371 | Establish Subscription | 372 |----------------------------->| 373 | RPC Reply: OK, id = 22 | 374 |<-----------------------------| 375 | | 376 | notification message (for 22)| 377 |<-----------------------------| 378 | | 379 | | 380 | Establish Subscription | 381 |----------------------------->| 382 | RPC Reply: OK, id = 23 | 383 |<-----------------------------| 384 | | 385 | | 386 | notification message (for 22)| 387 |<-----------------------------| 388 | notification message (for 23)| 389 |<-----------------------------| 390 | | 392 Figure 6: Multiple subscription establishments over a single NETCONF 393 session 395 In the example above, it is important to note that the subscription 396 ids of 22 and 23 are not included in the notification messages of 397 [I-D.draft-ietf-netconf-subscribed-notifications]. However because 398 [I-D.ietf-netconf-yang-push] has defined its own notifications, 399 subscription identifiers are available within those notification 400 messages. With the availability of 401 [I.D.draft-ietf-netconf-notification-messages], all notification 402 messages will be able to transport a subscription identifier. 404 A.2.2. Modifying Dynamic Subscriptions 406 The following demonstrates modifying a dynamic subscription. 407 Consider a subscription from [I-D.ietf-netconf-yang-push]. An 408 established may have a new filter applied. The desired modification 409 is the application of a new filter. 411 413 416 417 418 /interfaces-state/interface/oper-status 419 420 421 422 22 423 424 425 427 Figure 7: Subscription modification 429 If the NETCONF publisher can satisfy the request, the publisher sends 430 a positive "subscription-result". This response is like that to an 431 establish-subscription request, but without the subscription 432 identifier. 434 436 438 ok 439 440 442 Figure 8: Successful modify-subscription 444 If the NETCONF publisher cannot satisfy the request, the publisher 445 sends a negative "subscription-result" element. Its contents and 446 semantics match those from an establish-subscription request. 448 To get an idea of the interaction model, the following figure shows a 449 successful RPC modification request to subscription with an 450 identifier of 22. 452 +------------+ +-----------+ 453 | Subscriber | | Publisher | 454 +------------+ +-----------+ 455 | | 456 | notification message | 457 |<-----------------------------| 458 | | 459 | Modify Subscription | 460 |----------------------------->| 461 | RPC Reply: OK | 462 |<-----------------------------| 463 | | 464 | notification message | 465 |<-----------------------------| 466 | | 468 Figure 9: Interaction model for successful subscription modification 470 A.2.3. Deleting Dynamic Subscriptions 472 The following demonstrates deleting a subscription. 474 476 478 22 479 480 482 Figure 10: Delete subscription 484 If the NETCONF publisher can satisfy the request, the publisher sends 485 an OK element. For example: 487 489 490 492 Figure 11: Successful delete subscription 494 If the NETCONF publisher cannot satisfy the request, the publisher 495 sends an error-rpc element indicating the modification didn't work. 496 One way this could happen is if an existing valid subscription 497 identifier was given, but that subscription was created on a 498 different NETCONF transport session: 500 502 503 application 504 invalid-value 505 error 506 508 sn:identifier 509 510 511 no-such-subscription 512 513 514 516 Figure 12: Unsuccessful delete subscription 518 A.3. Configured Subscriptions 520 Configured subscriptions may be established, modified, and deleted 521 using configuration operations against the top-level subtree of 522 [I-D.draft-ietf-netconf-subscribed-notifications] or 523 [I-D.ietf-netconf-yang-push]. 525 In this section, we present examples of how to manage the 526 configuration subscriptions using a NETCONF client. Key differences 527 from dynamic subscriptions over NETCONF is that subscription 528 lifetimes are decoupled from NETCONF sessions. 530 A.3.1. Creating Configured Subscriptions 532 For subscription creation, a NETCONF client may send: 534 537 538 539 540 541 543 544 22 545 encode-xml 546 547 NETCONF 548 549
1.2.3.4
550 1234 551 552 553 554 555 556 558 Figure 13: Create a configured subscription 560 If the request is accepted, the publisher would reply: 562 564 565 567 Figure 14: Response to a successful configuration subscription 568 establishment 570 If the request is not accepted because the publisher cannot serve it, 571 no configuration is changed. In this case the publisher may reply: 573 575 576 application 577 resource-denied 578 error 579 580 Temporarily the publisher cannot serve this 581 subscription due to the current workload. 582 583 584 586 Figure 15: Response to a failed configured subscription establishment 588 After a subscription has been created, NETCONF connectivity to each 589 receiver's IP address and port will be established if it does not 590 already exist. This will be accomplished via [RFC8071]. 592 To get an idea of the interaction model, the following figure shows a 593 successful configuration based creation of a subscription. 595 +----------+ +-----------+ +---------+ 596 |Config Ops| | Publisher | | 1.2.3.4 | 597 +----------+ +-----------+ +---------+ 598 | | | 599 | Capability Exchange | | 600 |<-------------------------->| | 601 | | | 602 | | | 603 | Edit-config | | 604 |--------------------------->| | 605 | RPC Reply: OK | | 606 |<---------------------------| | 607 | | Call Home | 608 | |<-------------->| 609 | | | 610 | | Subscription | 611 | | Started | 612 | |--------------->| 613 | | | 614 | | notification | 615 | | message | 616 | |--------------->| 618 Figure 16: Interaction model for configured subscription 619 establishment 621 A.3.2. Modifying Configured Subscriptions 623 Configured subscriptions can be modified using configuration 624 operations against the top-level subtree subscription-config. 626 For example, the subscription established in the previous section 627 could be modified as follows, here a adding a second receiver: 629 632 633 634 635 636 638 639 640 1922 641 642 643
644 1.2.3.5 645
646 647 1234 648 649 650 651 652 653 655 Figure 17: Modify configured subscription 657 If the request is accepted, the publisher would reply: 659 661 662 664 Figure 18: A successful configured subscription modification 666 And the previous interaction model would be extended as follows. 668 +----------+ +-----------+ +---------+ +---------+ 669 |Config Ops| | Publisher | | 1.2.3.4 | | 1.2.3.5 | 670 +----------+ +-----------+ +---------+ +---------+ 671 | | | | 672 | | | | 673 | | notification | | 674 | | message | | 675 | |--------------->| | 676 | | | | 677 | Edit-config | | | 678 |--------------------------->| | | 679 | RPC Reply: OK | | | 680 |<---------------------------| | | 681 | | Call Home | | 682 | |<--------------------------->| 683 | | Subscription | | 684 | | Started | | 685 | |---------------------------->| 686 | | | | 687 | | notification | | 688 | | message | | 689 | |--------------->| | 690 | |---------------------------->| 691 | | | | 693 Figure 19: Interaction model for configured subscription modification 695 Note in the above that in the specific example above, modifying a 696 configured subscription actually resulted in subscription-started 697 notification. If the edit of the configuration had also added a 698 filter, a separate modify-subscription would have gone to the 699 original receiver. 701 A.3.3. Deleting Configured Subscriptions 703 Configured subscriptions can be deleted using configuration 704 operations against the top-level subtree subscription-config. 705 Deleting the subscription above would result in the following flow 706 impacting all receivers. 708 +----------+ +-----------+ +---------+ +---------+ 709 |Config Ops| | Publisher | | 1.2.3.4 | | 1.2.3.5 | 710 +----------+ +-----------+ +---------+ +---------+ 711 | | | | 712 | | notification | | 713 | | message | | 714 | |--------------->| | 715 | |---------------------------->| 716 | | | | 717 | Edit-config | | | 718 |--------------------------->| | | 719 | RPC Reply: OK | | | 720 |<---------------------------| | | 721 | | Subscription | | 722 | | Terminated | | 723 | |--------------->| | 724 | |---------------------------->| 725 | | | | 727 Figure 20: Interaction model for configured subscription deletion 729 A.4. Subscription State Notifications 731 A publisher will send subscription state notifications according to 732 the definitions within 733 [I-D.draft-ietf-netconf-subscribed-notifications]). 735 A.4.1. subscription-started and subscription-modified 737 A subscription-started over NETCONF encoded in XML would look like: 739 741 2007-09-01T10:00:00Z 742 744 39 745 encode-xml 746 747 NETCONF 748 749 /ex:foo 750 751 752 753 755 Figure 21: subscription-started subscription state notification 757 The subscription-modified is identical, with just the word "started" 758 being replaced by "modified". 760 A.4.2. subscription-completed, subscription-resumed, and replay- 761 complete 763 A subscription-completed would look like: 765 767 2007-09-01T10:00:00Z 768 770 39 771 772 774 Figure 22: subscription-completed notification in XML 776 The subscription-resumed and replay-complete are virtually identical, 777 with "subscription-completed" simply being replaced by "subscription- 778 resumed" and "replay-complete" in both encodings. 780 A.4.3. subscription-terminated and subscription-suspended 782 A subscription-terminated would look like: 784 786 2007-09-01T10:00:00Z 787 789 39 790 791 unsupportable-volume 792 793 794 796 Figure 23: subscription-terminated subscription state notification 798 The subscription-suspended is virtually identical, with 799 "subscription-terminated" simply being replaced by "subscription- 800 suspended". 802 Appendix B. Changes between revisions 804 (To be removed by RFC editor prior to publication) 806 B.1. v05 to v06 808 o Moved examples to appendices 810 o All examples rewritten based on namespace learnings 812 o Normative text consolidated in front 814 o Removed all mention of JSON 816 o Call home process detailed 818 o Note: this is a major revision attempting to cover those comments 819 received from two week review. 821 B.2. v03 to v04 823 o Added additional detail to "configured subscriptions" 825 o Added interleave capability 827 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 828 notifications 830 o Corrected namespaces in examples 832 B.3. v01 to v03 834 o Text simplifications throughout 836 o v02 had no meaningful changes 838 B.4. v00 to v01 840 o Added Call Home in solution for configured subscriptions. 842 o Clarified support for multiple subscription on a single session. 843 No need to support multiple create-subscription. 845 o Added mapping between terminology in yang-push and [RFC6241] (the 846 one followed in this document). 848 o Editorial improvements. 850 Authors' Addresses 852 Alberto Gonzalez Prieto 853 VMware 855 Email: agonzalezpri@vmware.com 857 Eric Voit 858 Cisco Systems 860 Email: evoit@cisco.com 862 Alexander Clemm 863 Huawei 865 Email: ludwig@clemm.org 867 Einar Nilsen-Nygaard 868 Cisco Systems 870 Email: einarnn@cisco.com 872 Ambika Prasad Tripathy 873 Cisco Systems 875 Email: ambtripa@cisco.com