idnits 2.17.1 draft-ietf-netconf-netconf-event-notifications-05.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.) == There are 2 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 2, 2017) is 2390 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) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 3 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 A. Clemm 5 Expires: April 5, 2018 Huawei 6 E. Voit 7 E. Nilsen-Nygaard 8 A. Tripathy 9 Cisco Systems 10 October 2, 2017 12 NETCONF Support for Event Notifications 13 draft-ietf-netconf-netconf-event-notifications-05 15 Abstract 17 This document defines how to transport network subscriptions and 18 event messages on top of the Network Configuration protocol 19 (NETCONF). This includes the full set of RPCs, subscription state 20 changes, and subscribed content needing asynchronous delivery. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 5, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 3 60 3.2. Mandatory NETCONF support . . . . . . . . . . . . . . . . 4 61 3.3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 4 62 3.4. Configured Subscriptions . . . . . . . . . . . . . . . . 11 63 4. Interleave Capability . . . . . . . . . . . . . . . . . . . . 23 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 25 68 7.2. Informative References . . . . . . . . . . . . . . . . . 25 69 Appendix A. Open Items . . . . . . . . . . . . . . . . . . . . . 26 70 Appendix B. Changes between revisions . . . . . . . . . . . . . 26 71 B.1. v04 to v05 . . . . . . . . . . . . . . . . . . . . . . . 26 72 B.2. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 26 73 B.3. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 26 74 B.4. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 26 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 77 1. Introduction 79 This document defines mechanisms that provide a subscription and 80 asynchronous message notification delivery service for the NETCONF 81 protocol [RFC6241] based on [subscribe]. This is an optional 82 capability built on top of the base NETCONF definition. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 The following terms are defined in [RFC6241]: client, server, 91 operation, RPC. 93 The following terms are defined in [subscribe]: event, event 94 notification, stream, publisher, receiver, subscriber, subscription, 95 configured subscription. 97 Note that a publisher in [subscribe] corresponds to a server in 98 [RFC6241]. Similarly, a subscriber corresponds to a client. A 99 receiver is also a client. In the remainder of this document, we 100 will use the terminology in [RFC6241]. 102 3. Solution 104 In this section, we describe and exemplify how [subscribe] is to be 105 supported over NETCONF. 107 3.1. Event Stream Discovery 109 In the context of [subscribe] an event stream exposes a continuous 110 set of events available for subscription. A NETCONF client can 111 retrieve the list of available event streams from a NETCONF server 112 using the "get" operation against the top-level container "/streams" 113 defined in [subscribe]. The reply includes the list of streams 114 supported on the NETCONF server. 116 The following example illustrates the retrieval of the list of 117 available event streams using the operation. 119 121 122 123 125 126 127 129 Figure 1: Get streams request 131 The NETCONF server returns a list of event streams available. In 132 this example, the list contains the NETCONF, SNMP, and SYSLOG 133 streams. 135 137 138 140 141 NETCONF 142 The NETCONF mandatory event stream 143 144 145 SNMP 146 The SNMP event stream 147 148 149 SYSLOG 150 The SYSLOG event stream 151 152 153 2015-03-09T19:14:55.233Z 154 155 156 157 159 Figure 2: Get streams response 161 For [yang-push], a similar get is needed to retrieve available 162 datastore names. 164 3.2. Mandatory NETCONF support 166 A NETCONF server implementation supporting [subscribe] must support 167 dynamic subscriptions and the "NETCONF" notification event stream. 168 The NETCONF event stream contains all NETCONF XML event information 169 supported by the server. 171 A NETCONF server implementation supporting [yang-push] must support 172 the "running" datastore. 174 3.3. Dynamic Subscriptions 176 3.3.1. Establishing Dynamic Subscriptions 178 The dynamic subscription RFC and interactions operation is defined in 179 [subscribe]. 181 3.3.1.1. Usage Example 183 An example of interactions over NETCONF transport for one sample 184 subscription is below: 186 188 190 NETCONF 191 xpath-event-filter 192 196 197 199 Figure 3: establish-subscription over NETCONF 201 3.3.1.2. Positive Response 203 If the NETCONF server can satisfy the request, the server sends a 204 positive element, and the subscription-id of 205 the accepted subscription. 207 209 211 ok 212 213 215 52 216 217 219 Figure 4: Successful establish-subscription 221 3.3.1.3. Negative Response 223 If the NETCONF server cannot satisfy the request, or the client has 224 no authorization to establish the subscription, the server will send 225 a negative element. For instance: 227 229 231 stream-unavailable 232 233 235 Figure 5: Unsuccessful establish subscription 237 3.3.1.4. Subscription Negotiation 239 If the client request includes parameters the NETCONF server cannot 240 serve, the negative may include hints at 241 subscription parameters which would have been accepted. For 242 instance, consider the following subscription from [yang-push], which 243 augments the establish-subscription with some additional parameters, 244 including "period". If the client requests a period which the 245 NETCONF server cannot serve, the back-and-forth exchange may be: 247 249 251 running 252 253 subtree 254 256 select="/ex:foo" /> 257 10 258 encode-xml 259 260 262 264 266 error-insufficient-resources 267 268 270 2000 271 272 274 Figure 6: Subscription establishment negotiation 276 3.3.1.5. Message Flow Examples 278 +------------+ +-----------+ 279 | Client | | Server | 280 +------------+ +-----------+ 281 | | 282 | Capability Exchange | 283 |<---------------------------->| 284 | | 285 | | 286 | Establish Subscription | 287 |----------------------------->| 288 | RPC Reply: OK, id = 22 | 289 |<-----------------------------| 290 | | 291 | Notification (id 22) | 292 |<-----------------------------| 293 | | 294 | | 295 | Establish Subscription | 296 |----------------------------->| 297 | RPC Reply: OK, id = 23 | 298 |<-----------------------------| 299 | | 300 | | 301 | Notification (id 22) | 302 |<-----------------------------| 303 | Notification (id 23) | 304 |<-----------------------------| 305 | | 306 | | 308 Figure 7: Multiple subscription establishments over a single NETCONF 309 session 311 3.3.2. Modifying a Subscription 313 This operation is defined in [subscribe]. 315 3.3.2.1. Usage Example 317 The following demonstrates modifying a subscription. Consider a 318 subscription from [yang-push], which augments the establish- 319 subscription with some additional parameters, including "period". A 320 subscription may be established and modified as follows. 322 324 326 327 running 328 subtree-event-filter 329 331 select="/ex:foo" /> 332 333 1000 334 335 336 338 340 342 ok 343 344 346 1922 347 348 350 352 354 1922 355 100 356 357 359 Figure 8: Subscription modification 361 3.3.2.2. Positive Response 363 If the NETCONF server can satisfy the request, the server sends a 364 positive element. This response is like that 365 to an establish-subscription request, but without the subscription 366 identifier. 368 370 372 ok 373 374 376 Figure 9: Successful modify subscription 378 3.3.2.3. Negative Response 380 If the NETCONF server cannot satisfy the request, the server sends a 381 negative element. Its contents and semantics 382 are identical to those in an establish-subscription request. For 383 instance: 385 387 389 period-unsupported 390 391 500 392 394 Figure 10: Unsuccessful modify subscription 396 3.3.2.4. Message Flow Example 397 +------------+ +-----------+ 398 | Client | | Server | 399 +------------+ +-----------+ 400 | | 401 | Capability Exchange | 402 |<---------------------------->| 403 | | 404 | Establish Subscription | 405 |----------------------------->| 406 | RPC Reply: OK, id = 22 | 407 |<-----------------------------| 408 | | 409 | Notification (id 22) | 410 |<-----------------------------| 411 | | 412 | Modify Subscription (id 22) | 413 |----------------------------->| 414 | RPC Reply: OK | 415 |<-----------------------------| 416 | | 417 | Notification (id 22) | 418 |<-----------------------------| 419 | | 421 Figure 11: Message flow for successful subscription modification 423 3.3.3. Deleting a Subscription 425 This operation is defined in [subscribe] for events, and enhanced in 426 [yang-push] for datastores. 428 3.3.3.1. Usage Example 430 The following demonstrates deleting a subscription. 432 434 436 1922 437 438 440 Figure 12: Delete subscription 442 3.3.3.2. Positive Response 444 If the NETCONF server can satisfy the request, the server sends a 445 positive element. For example: 447 449 451 ok 452 453 455 Figure 13: Successful delete subscription 457 3.3.3.3. Negative Response 459 If the NETCONF server cannot satisfy the request, the server sends an 460 element indicating the deletion was not 461 performed. For example: 463 465 467 no-such-subscription 468 469 471 Figure 14: Unsuccessful delete subscription 473 3.4. Configured Subscriptions 475 Configured subscriptions are established, modified, and deleted using 476 configuration operations against the top-level subtree of [subscribe] 477 or [yang-push] via configuration interface. This document covers 478 configured subscriptions where the chosen protocol to send the 479 notifications to the receivers is NETCONF. 481 Configured subscriptions are supported by NETCONF servers using 482 NETCONF Call Home [RFC8071]. 484 Any configuration interface can be used to set a configured 485 subscription that uses NETCONF to push notifications to receivers. 486 Without loss of generality, the examples in this section, use a 487 NETCONF interface to configure the subscriptions 489 3.4.1. Establishing a Configured Subscription 491 For subscription establishment, a NETCONF client may send: 493 495 496 497 498 499 501 502 503 1922 504 505 506 foo 507 508 509
510 1.2.3.4 511
512 513 1234 514 515 516 netconf 517 518 519 520 521 522 524 Figure 15: Establish configured subscription 526 if the request is accepted, the server would reply: 528 530 531 533 Figure 16: Response to a successful configuration subscription 534 establishment 536 if the request is not accepted because the server cannot serve it, no 537 configuration is changed. Int this case the server may reply: 539 540 542 error-insufficient-resources 543 544 546 Figure 17: Response to a failed configured subscription establishment 548 For every configured receiver, once NETCONF transport session between 549 the server and the receiver is recognized as active, the server will 550 issue a "subscription-started" notification. After that, the server 551 will send notifications to the receiver as per the subscription 552 notification. Note that the server assumes that the receiver is 553 ready to accept notifications on the NETCONF session. This may 554 require coordination between the client that configures the 555 subscription and the clients for which the notifications are 556 intended. This coordination is out of the scope of this document. 558 The session is only intended for pushing notifications. Client 559 requests on that session SHOULD be ignored by the server. 561 The contents sent by the server on the Call Home session, once 562 established, are identical to those in a dynamic subscription. 564 3.4.2. Call Home for Configured Subscriptions 566 Once the subscription configuration is active, if NETCONF transport 567 is needed but does not exist to one or more target IP address plus 568 port, the server initiates a transport session via [RFC8071] to those 569 receiver(s) in the subscription using the address and port specified. 571 3.4.3. Full Establish Message Flow 572 +----------+ +-----------+ +---------+ +---------+ 573 | Client | | Server | | Rcver A | | Rcver B | 574 +----------+ +-----------+ +---------+ +---------+ 575 | | | | 576 | Capability Exchange | | | 577 |<-------------------------->| | | 578 | | | | 579 | | | | 580 | Edit-config | | | 581 |--------------------------->| | | 582 | RPC Reply: OK | | | 583 |<---------------------------| | | 584 | | Call Home | | 585 | |<-------------->| | 586 | |<--------------------------->| 587 | | | | 588 | | Subscription | | 589 | | Started | | 590 | | (id 22) | | 591 | |--------------->| | 592 | |---------------------------->| 593 | | | | 594 | | Notification | | 595 | | (id 22) | | 596 | |--------------->| | 597 | |---------------------------->| 598 | | | | 600 Figure 18: Message flow for configured subscription establishment 602 3.4.4. Modifying a Configured Subscription 604 Configured subscriptions can be modified using configuration 605 operations against the top-level subtree subscription-config. 607 For example, the subscription established in the previous section 608 could be modified as follows, choosing a different receiver: 610 612 613 614 615 616 618 619 620 1922 621 622 623 foo 624 625 626
627 1.2.3.5 628
629 630 1234 631 632 633 634 635 636 638 Figure 19: Modify configured subscription 640 if the request is accepted, the server would reply: 642 644 645 647 Figure 20: A successful configured subscription modification 649 3.4.4.1. Message Flow Example 650 +----------+ +-----------+ +---------+ +---------+ 651 | Client | | Server | | Rcver A | | Rcver B | 652 +----------+ +-----------+ +---------+ +---------+ 653 | | | | 654 | Capability Exchange | | | 655 |<-------------------------->| | | 656 | | | | 657 | | | | 658 | Edit-config | | | 659 |--------------------------->| | | 660 | RPC Reply: OK | | | 661 |<---------------------------| | | 662 | | Call Home | | 663 | |<-------------->| | 664 | |<--------------------------->| 665 | | | | 666 | | Subscription | | 667 | | Started | | 668 | | (id 22) | | 669 | |--------------->| | 670 | |---------------------------->| 671 | | | | 672 | | Notification | | 673 | | (id 22) | | 674 | |--------------->| | 675 | |---------------------------->| 676 | | | | 677 | Edit-config | | | 678 |--------------------------->| | | 679 | RPC Reply: OK | | | 680 |<---------------------------| | | 681 | | Subscription | | 682 | | Modified | | 683 | | (id 22) | | 684 | |--------------->| | 685 | |---------------------------->| 686 | | | | 687 | | Notification | | 688 | | (id 22) | | 689 | |--------------->| | 690 | |---------------------------->| 691 | | | | 693 Figure 21: Message flow for subscription modification (configured 694 subscription) 696 3.4.5. Deleting a Configured Subscription 698 Subscriptions can be deleted using configuration operations against 699 the top-level subtree subscription-config. For example: 701 703 704 705 706 707 709 710 711 1922 712 713 714 715 716 718 720 721 723 Figure 22: Deleting a configured subscription 725 3.4.5.1. Message Flow Example 726 +----------+ +-----------+ +---------+ +---------+ 727 | Client | | Server | | Rcver A | | Rcver B | 728 +----------+ +-----------+ +---------+ +---------+ 729 | | | | 730 | Capability Exchange | | | 731 |<-------------------------->| | | 732 | | | | 733 | | | | 734 | Edit-config | | | 735 |--------------------------->| | | 736 | RPC Reply: OK | | | 737 |<---------------------------| | | 738 | | Call Home | | 739 | |<-------------->| | 740 | |<--------------------------->| 741 | | | | 742 | | Subscription | | 743 | | Started | | 744 | | (id 22) | | 745 | |--------------->| | 746 | |---------------------------->| 747 | | | | 748 | | | | 749 | | Notification | | 750 | | (id 22) | | 751 | |--------------->| | 752 | |---------------------------->| 753 | | | | 754 | Edit-config | | | 755 |--------------------------->| | | 756 | RPC Reply: OK | | | 757 |<---------------------------| | | 758 | | Subscription | | 759 | | Terminated | | 760 | | (id 22) | | 761 | |--------------->| | 762 | |---------------------------->| 763 | | | | 765 Figure 23: Message flow for subscription deletion (configured 766 subscription) 768 3.4.6. Event (Data Plane) Notifications 770 Once a dynamic or configured subscription has been created, the 771 NETCONF server sends (asynchronously) event notifications from the 772 subscribed stream to receiver(s) over NETCONF. We refer to these as 773 data plane notifications. The data model for Event Notifications is 774 defined in [subscribe]. 776 The following is an example of an event notification from [RFC6020]: 778 notification link-failure { 779 description "A link failure has been detected"; 780 leaf if-name { 781 type leafref { 782 path "/interface/name"; 783 } 784 } 785 leaf if-admin-status { 786 type admin-status; 787 } 788 leaf if-oper-status { 789 type oper-status; 790 } 791 } 793 Figure 24: Definition of an event notification 795 This notification might result in the following, prior to it being 796 placed into NETCONF. Note that the mandatory eventTime and 797 Subscription id have been added. 799 801 2007-09-01T10:00:00Z 802 803 so-1/2/3.0 804 up 805 down 806 807 809 Figure 25: Event notification 811 3.4.7. Subscription State Notifications 813 In addition to data plane notifications, a publisher may send 814 subscription state notifications (defined in [subscribe]) to indicate 815 to receivers that an event related to the subscription management has 816 occurred. Subscription state notifications cannot be filtered out. 817 Next we exemplify them: 819 3.4.7.1. subscription-started and subscription-modified 821 A subscription-started would look like: 823 825 2007-09-01T10:00:00Z 826 828 39 829 NETCONF 830 831 833 Figure 26: subscription-started subscription state notification 835 The subscription-modified is identical, with just the word "started" 836 being replaced by "modified". 838 3.4.7.2. subscription-completed, subscription-resumed, and replay- 839 complete 841 A subscription-completed would look like: 843 845 2007-09-01T10:00:00Z 846 848 39 849 850 852 Figure 27: subscription-completed notification in XML 854 The equivalent using JSON encoding would be: 856 858 2007-09-01T10:00:00Z 859 860 { 861 "sn:subscription-completed": { 862 "identifier" : 39 863 } 864 865 867 Figure 28: subscription-completed notification in JSON 869 The subscription-resumed and replay-complete are virtually identical, 870 with "subscription-completed" simply being replaced by "subscription- 871 resumed" and "replay-complete" in both encodings. 873 3.4.7.3. subscription-terminated and subscription-suspended 875 A subscription-terminated would look like: 877 879 2007-09-01T10:00:00Z 880 882 39 883 error-insufficient-resources 884 885 887 Figure 29: subscription-modified subscription state notification 889 The above, and the subscription-suspended are virtually identical, 890 with "subscription-terminated" simply being replaced by 891 "subscription-suspended". 893 3.4.7.4. Notification Message Flow Examples 894 +------------+ +-----------+ 895 | Client | | Server | 896 +------------+ +-----------+ 897 | | 898 | Capability Exchange | 899 |<---------------------------->| 900 | | 901 | Establish Subscription | 902 |<---------------------------->| 903 | | 904 | Notification | 905 |<-----------------------------| 906 | | 907 | | 908 | Subscription Suspended | 909 |<-----------------------------| 910 | | 911 | | 912 | | 913 | Subscription Resumed | 914 |<-----------------------------| 915 | | 916 | Notification | 917 |<-----------------------------| 918 | | 920 Figure 30: subscription-suspended and resumed notifications 922 +----------+ +-----------+ +---------+ +---------+ 923 | Client | | Server | | Rcver A | | Rcver B | 924 +----------+ +-----------+ +---------+ +---------+ 925 | | | | 926 | Capability Exchange | | | 927 |<-------------------------->| | | 928 | | | | 929 | Edit-config | | | 930 |--------------------------->| | | 931 | RPC Reply: OK | | | 932 |<---------------------------| | | 933 | | Subscription | | 934 | | Started | | 935 | |--------------->| | 936 | |---------------------------->| 937 | | | | 938 | | Notification | | 939 | |--------------->| | 940 | |---------------------------->| 941 | | | | 942 | | Subscription | | 943 | | Suspended | | 944 | |--------------->| | 945 | | | | 946 | | Notification | | 947 | |---------------------------->| 948 | | | | 949 | | Subscription | | 950 | | Resumed | | 951 | |--------------->| | 952 | | | | 953 | | Notification | | 954 | |--------------->| | 955 | |---------------------------->| 956 | | | | 958 Figure 31: Suspended and resumed notifications for a single 959 configured receiver 961 4. Interleave Capability 963 The :interleave capability is originally defined in [RFC5277]. It is 964 incorporated in this document with essentially the same semantics. 965 That is, the NETCONF server MUST receive, process, and respond to 966 NETCONF requests on a session with active notification subscriptions. 968 The :interleave capability is identified by the following string: 969 urn:ietf:params:netconf:capability:interleave:1.0 970 Note that subscription operations MUST be received, processed, and 971 responded on a session with active notification subscriptions That 972 mandatory requirement together with the :interleave capability 973 permits a client performing all operations against a server using a 974 single connection, allowing for better scalability with respect to 975 the number of NETCONF sessions required to manage an entity. 977 5. Security Considerations 979 The elements are never sent before the transport layer 980 and the NETCONF layer, including capabilities exchange, have been 981 established and the manager has been identified and authenticated. 983 A secure transport must be used and the server must ensure that the 984 user has sufficient authorization to perform the function they are 985 requesting against the specific subset of content involved. 987 The contents of notifications, as well as the names of event streams, 988 may contain sensitive information and care should be taken to ensure 989 that they are viewed only by authorized users. The NETCONF server 990 MUST NOT include any content in a notification that the user is not 991 authorized to view. 993 If a malicious or buggy NETCONF client sends a number of requests, then these subscriptions accumulate and may 995 use up system resources. In such a situation, subscriptions MAY be 996 terminated by terminating the suspect underlying NETCONF sessions. 997 The server MAY also suspend or terminate a subset of the active 998 subscriptions on the NETCONF session . 1000 Configured subscriptions from one or more publishers could be used to 1001 overwhelm a receiver, which perhaps doesn't even support 1002 subscriptions. Clients that do not want pushed data need only 1003 terminate or refuse any transport sessions from the publisher. 1005 The NETCONF Authorization Control Model [RFC6536] SHOULD be used to 1006 control and restrict authorization of subscription configuration. 1007 This control models permits specifying per-user permissions to 1008 receive specific event notification types. The permissions are 1009 specified as a set of access control rules. 1011 6. Acknowledgments 1013 We wish to acknowledge the helpful contributions, comments, and 1014 suggestions that were received from: Andy Bierman, Yan Gang, Sharon 1015 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, 1016 Balazs Lengyel, Kent Watsen, and Guangying Zheng. 1018 7. References 1020 7.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, 1024 DOI 10.17487/RFC2119, March 1997, 1025 . 1027 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1028 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 1029 . 1031 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1032 the Network Configuration Protocol (NETCONF)", RFC 6020, 1033 DOI 10.17487/RFC6020, October 2010, 1034 . 1036 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1037 and A. Bierman, Ed., "Network Configuration Protocol 1038 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1039 . 1041 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1042 Protocol (NETCONF) Access Control Model", RFC 6536, 1043 DOI 10.17487/RFC6536, March 2012, 1044 . 1046 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1047 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1048 . 1050 7.2. Informative References 1052 [subscribe] 1053 Voit, Eric., Clemm, A., Gonzalez Prieto, A., Nilsen- 1054 Nygaard, E., and A. Tripathy, "Custom Subscription to 1055 Event Notifications", September 2017, 1056 . 1059 [yang-push] 1060 Clemm, A., Gonzalez Prieto, A., Voit, Eric., Tripathy, A., 1061 Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 1062 "Subscribing to YANG datastore push updates", September 1063 2017, . 1066 Appendix A. Open Items 1068 (To be removed by RFC editor prior to publication) 1070 o Formal definition of: notification-contents-json, and 1071 incorporation of the subscription-id in the notifications. It 1072 depends on the formal definition of the notification element 1074 Appendix B. Changes between revisions 1076 (To be removed by RFC editor prior to publication) 1078 B.1. v04 to v05 1080 o Text presentation modifications throughout 1082 o Modified examples to match the namespace, prefixes, and data node 1083 identifiers in [subscribe] and [yang-push] 1085 o Modified examples to include in all RPC 1086 responses 1088 o Modified examples to include mandatory fields in [subscribe] and 1089 [yang-push] 1091 B.2. v03 to v04 1093 o Added additional detail to "configured subscriptions" 1095 o Added interleave capability 1097 o Adjusted terminology to that in draft-ietf-netconf-subscribed- 1098 notifications 1100 o Corrected namespaces in examples 1102 B.3. v01 to v03 1104 o Text simplifications throughout 1106 o v02 had no meaningful changes 1108 B.4. v00 to v01 1110 o Added Call Home in solution for configured subscriptions. 1112 o Clarified support for multiple subscription on a single session. 1113 No need to support multiple create-subscription. 1115 o Added mapping between terminology in [yang-push] and [RFC6241] 1116 (the one followed in this document). 1118 o Editorial improvements. 1120 Authors' Addresses 1122 Alberto Gonzalez Prieto 1123 VMware 1125 Email: agonzalezpri@vmware.com 1127 Alexander Clemm 1128 Huawei 1130 Email: ludwig@clemm.org 1132 Eric Voit 1133 Cisco Systems 1135 Email: evoit@cisco.com 1137 Einar Nilsen-Nygaard 1138 Cisco Systems 1140 Email: einarnn@cisco.com 1142 Ambika Prasad Tripathy 1143 Cisco Systems 1145 Email: ambtripa@cisco.com