idnits 2.17.1 draft-netmod-clemm-datastore-push-00.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 340: '...nses, the server SHOULD include in the...' RFC 2119 keyword, line 434: '...reason, a server SHALL maintain status...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 292 has weird spacing: '...tion-id sub...' == Line 696 has weird spacing: '...n event to...' == Line 721 has weird spacing: '...n event to th...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3440 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-5277' is mentioned on line 255, but not defined ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft A. Gonzalez Prieto 4 Intended status: Experimental E. Voit 5 Expires: April 30, 2015 Cisco Systems 6 October 27, 2014 8 Subscribing to datastore push updates 9 draft-netmod-clemm-datastore-push-00.txt 11 Abstract 13 This document defines a subscription and push mechanism for 14 datastores. This mechanism allows client applications to request 15 updates from a datastore, which are then pushed by the server to the 16 client per a subscription policy, without requiring additional client 17 requests. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 67 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 5 69 3.2. Negotiation of Subscription Policies . . . . . . . . . . 7 70 3.3. Push Data Stream and Transport Mapping . . . . . . . . . 8 71 3.4. Other considerations . . . . . . . . . . . . . . . . . . 9 72 3.4.1. Authorization . . . . . . . . . . . . . . . . . . . . 9 73 3.4.2. Subscription status and subscription monitoring . . . 9 74 3.4.3. Implementation considerations . . . . . . . . . . . . 10 75 4. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 6.2. Informative References . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 YANG datastores, i.e. datastores that contain data modeled according 84 using YANG [RFC6020], are not restricted to configuration data, but 85 can also contain operational data. It is therefore reasonable to 86 expect that data in YANG datastores will increasingly be used to 87 support applications that are not focused on managing configurations 88 but that are, for example, related to service assurance. 90 Service assurance applications typically involve monitoring 91 operational state of networks and devices; of particular interest are 92 changes that this data undergoes over time. Likewise, there are 93 applications in which data and objects from one datastore need to be 94 made available to applications in other systems and to remote 95 datastores [peermount-req], requiring mechanisms that allow remote 96 systems to become quickly aware of any updates to allow to validate 97 and maintain cross-network integrity and consistency. 99 Traditional approaches rely heavily on polling, in which data is 100 periodically explicitly retrieved by a client from a server. 102 There are various issues associated with polling-based management: 104 o It introduces additional load on network and devices. Each 105 polling cycle requires a separate yet arguably redundant request 106 that results in an interrupt, requires parsing, consumes 107 bandwidth. 109 o It lacks robustness. Polling cycles may be missed, requests may 110 be delayed or get lost, often particularly in cases when the 111 network is under stress and hence exactly when the need for the 112 data is the greatest. 114 o Data may be difficult to calibrate and compare. Polling cycles 115 may undergo slight fluctuations, resulting in intervals of 116 different lengths which makes data hard to compare. Likewise, 117 pollers may have difficulty issuing requests that reach all 118 devices at the same time, resulting in offset polling intervals 119 which again make data hard to compare. 121 More effective is an alternative in which an application can request 122 to be automatically updated of current content of the datastore (such 123 as a subtree, or data in a subtree that meets a certain filter 124 condition), and in which the server subsequently pushes those 125 updates. 127 The need to perform polling-based management is typically considered 128 an important shortcoming of management applications that rely on MIBs 129 polled using SNMP [RFC1157]. However, without a provision to support 130 a push-based alternative, there is no reason to believe that 131 management applications that operate on YANG datastores using 132 protocols such as NETCONF [RFC6241] or RESTCONF [restconf] will be 133 any more effective, as they would follow the same request/response 134 pattern. 136 While YANG allows to define notifications, such notifications are 137 generally intended to indicate the occurrence of certain well- 138 specified event conditions, such as a the onset of an alarm condition 139 or the occurrence of an error. Likewise, a capability to define 140 configuration change events has been defined in [RFC5277]. However, 141 these change events pertain only to configuration information, not to 142 operational state. RFC 5277 furthermore predates YANG and does not 143 provide tie-in with YANG-defined datastore contents. 145 Service Assurance applications are not the only applications 146 benefiting from a push- and subscription-based alternative to 147 polling. Another example is Peer Mount [peermount]. Peer Mount 148 allows a datastore to incorporate data from remote datastores by 149 reference, resulting in virtual datastores that are federated across 150 a network and offer different local views. Various use cases 151 indicate the usefulness of introducing caching in conjunction with 152 Peer Mount, which benefits greatly if updates can automatically be 153 pushed from a mount server to a mount client. 155 The way in which the updates are to occur can be directed by policy. 156 For example, a client may request to be updated periodically in 157 certain intervals, or whenever data changes occur. 159 Because not every server may support every requested interval for 160 every piece of data, it is furthermore necessary for a server to be 161 able to indicate whether or not it is capable of supporting a 162 requested subscription, and possibly allow to negotiate subscription 163 parameters. 165 Finally, a mechanism is needed to communicate the updates themselves. 166 One option is to use existing NETCONF and RESTCONF mechanisms, by 167 defining special notifications with which to carry those updates. 168 Other alternatives are conceivable, such as use of a dedicated 169 publish/subscribe mechanism that provides an alternative to a NETCONF 170 or RESTCONF transport. 172 This document specifies a YANG data model for the configuration and 173 management of subscriptions to data in YANG datastores. It also 174 defines a notification that can be used to carry data updates and 175 thus serve as push mechanism. 177 2. Definitions and Acronyms 179 Data node: An instance of management information in a YANG datastore. 181 Datastore: A conceptual store of instantiated management information, 182 with individual data items represented by data nodes which are 183 arranged in a hierarchical manner. 185 Data subtree: An instantiated data node and the data nodes that are 186 hierarchically contained within it. 188 Mount client: The system at which a mount point resides, into which 189 the remote subtree is mounted. 191 Mount point: A data node that receives the root node of the remote 192 datastore being mounted. 194 Mount server: The server with which the mount client communicates and 195 which provides the mount client with access to the mounted 196 information. Can be used synonymously with mount target. 198 Mount target: A remote server whose datastore is being mounted. 200 NACM: NETCONF Access Control Model 202 NETCONF: Network Configuration Protocol 204 Peer Mount: An extension to the YANG management framework that allows 205 local YANG datastores to incorporate data from remote (peer) YANG 206 datastores. 208 RPC: Remote Procedure Call 210 Remote datastore: A datastore residing at a remote node 212 SNMP: Simple Network Management Protocol 214 URI: Uniform Resource Identifier 216 YANG: A data definition language for NETCONF 218 3. Solution Overview 220 This document specifies a solution that allows clients to subscribe 221 to information updates in a YANG datastore, which are subsequently 222 pushed from the server to the client. The solution encompasses 223 several components: 225 o The configuration and management of the subscriptions. 227 o An ability to negotiate subscription parameters where a 228 subscription policy desired by a client cannot be supported. 230 o The datastream of the push updates. 232 In addition, there are a number of additional considerations, such as 233 the tie-in of the mechanisms with security mechanisms. Each of those 234 aspects will be discussed in the following subsections. 236 3.1. Subscription Model 238 Yang allows modeling the content of notifications. The contents are 239 a set of explicitly stated data nodes forming a hierarchy. For 240 modeling updates in a datastore, a new generic notification is 241 introduced, the "push-update". This notification has the following 242 semantics. The contents of the notification are not explicitly 243 stated. They are the union of the data nodes in the yang modules 244 supported by the server, excluding the following statements: 245 "mandatory", "must", "min-elements", "max-elements", "when", and 246 "default". Note that the notification contents are dynamic, 247 depending on the modules supported by the server. 249 Subscriptions to the "push-update" are initiated by clients. Servers 250 respond to a subscription request explicitly positively or 251 negatively. Negative responses include information describing the 252 reason for the subscription rejection. 254 Datastore-push subscriptions are defined using a data model. This 255 model is based on the subscriptions defined in [RFC-5277], which is 256 also reused in RESTCONF. The model is extended with a subscription 257 type a set of parameters for each type. The complete set of 258 subscription parameters is: 260 o The name of the stream to subscribe to. The stream is called 261 "push-update". 263 o The identity of the subscriber. 265 o An optional filter. It describes the subset of stream events of 266 interest to the subscriber. The server should only send to the 267 subscriber the events that match the filter, when present. The 268 absence of a filter indicates that all events in the stream are of 269 interest to the subscriber and all events in it must be sent to 270 the subscriber. Two filtering mechanisms are considered: subtree 271 filtering and Xpath filtering, with the semantics described in 272 [RFC5277]. 274 o An optional start time. Used to trigger replays starting at the 275 provided time. Its semantics are those in [RFC5277]. 277 o An optional stop time. Used to limit temporarily the events of 278 interest. Its semantics are those in [RFC5277]. 280 o A notification trigger definition. The trigger can be periodic or 281 based on change. For periodic subscriptions, the trigger is 282 defined by the interval with which to push updates. For on-change 283 subscriptions, the trigger is defined using the dampening interval 284 with which to push repeated changes, an indicator forthe magnitude 285 of changes, etc. 287 The following figure depicts the data model. 289 module: ietf-datastore-push 290 +--rw datastore-push-subscription 291 +--rw stream string 292 +--rw subscription-id subscription-identifier 293 +--rw (filter)? 294 | +--:(substree) 295 | | +--rw subtree-filter 296 | +--:(xpath) 297 | +--rw xpath-filter yang:xpath1.0 298 +--rw (notification-trigger) 299 | +--:(periodic) 300 | | +--rw period yang:timeticks 301 | +--:(on-change) 302 | +--rw (change-policy) 303 | +--:(delta-policy) 304 | +--rw delta uint32 305 +--rw start-time? yang:date-and-time 306 +--rw stop-time? yang:date-and-time 308 Figure 1: Model structure 310 The example below illustrates a subcription for a periodic push of 311 all data under a container called foo. 313 315 317 push-update 318 foo 319 322 500 323 324 325 327 Figure 2: Subscription example 329 3.2. Negotiation of Subscription Policies 331 A subscription rejection can be caused by the inability of the server 332 to provide a stream with the requested semantics. Providing "on- 333 change" updates for operational data can be computationally expensive 334 and an agent may decide not to support them or supporting them for a 335 small number of subscribers or for a limited set of data nodes. 337 Datastore-push supports a simple negotiation between clients and 338 servers for subscription parameters. The negotiation is limited to a 339 single pair of subscription request and response. For negative 340 responses, the server SHOULD include in the returned error what 341 subscription parameters would have been accepted for the request. 342 The returned acceptable parameters are no guarantee for subsequent 343 requests for this client or others. 345 The example below illustrates a subcription response, where an agent 346 does not support frequent periodic updates, and suggests a different 347 sampling rate to the client. 349 351 353 push-update 354 foo 355 358 500 359 360 361 363 364 365 application 366 operation-not-supported 367 error 368 369 370 3000 371 372 373 374 376 Figure 3: Subscription negotiation example 378 3.3. Push Data Stream and Transport Mapping 380 Pushing data based on a subscription could be considered analogous to 381 a response to a data retrieval request, e.g. a "get" request. 382 However, contrary to such a request, multiple responses to the same 383 request may get sent over a longer period of time. Likewise, clients 384 need to be able to distinguish between data updates and state update 385 regarding the subscription itself, for example when a subscription 386 can no longer be serviced. 388 A more suitable mechanism is therefore that of a notification. 389 Contrary to notifications associated with alarms and unexpected event 390 occurrences, push updates are solicited, i.e. tied tied to a 391 particular subscription which triggered the notification. (An 392 alternative conceptual model would consider a subscription an "opt- 393 in" filter on a continuous stream of updates.) 395 The notification contains several parameters: 397 o A subscription correlator, referencing the name of the 398 subscription on whose behalf the notification is sent. 400 o A data node that contains a representation of the datastore 401 subtree containing the updates. The subtree is filtered per 402 access control rules to contain only data that the subscriber is 403 authorized to see. Also, depending on the subscription type, 404 i.e., specifically for on-change subscriptions, the subtree 405 contains only the data nodes that contain actual changes. (This 406 can be simply a node of type string or, for XML-based encoding, 407 anyxml.) 409 Notifications are sent using elements as defined in 410 [RFC5277]. Alternative transports are conceivable but outside the 411 scope of this specification. 413 3.4. Other considerations 415 3.4.1. Authorization 417 A client may only receive updates to data that the client has proper 418 authorization for. Normal authorization rules apply. Data that is 419 being pushed therefore needs to be subjected to a filter that applies 420 the corresponding rules, removing any non-authorized data as 421 applicable. 423 The authorization model for data in YANG datastores is described in 424 the Netconf Access Control Model [RFC6536]. 426 3.4.2. Subscription status and subscription monitoring 428 It is possible that a server may no longer be able to serve a 429 subscription that had been previously accepted. For example, a 430 server may have run out of resources, or internal errors may have 431 occurred. When this is the case, a server needs to be able to 432 temporarily suspend the subscription, or even to terminate it. 434 For this reason, a server SHALL maintain status information for each 435 subscription that indicates the current status of the subscription. 437 In addition, a server needs to indicate any changes in status to the 438 subscriber through a notification. Specifically, subscribers need to 439 be informed of the following: 441 o A subscription has been temporarily suspended, including the 442 reason. (See subscription-suspended in the model below.) 444 o A subscription (that had been suspended earlier) is once again 445 operational. (See subscription-resumed in the model below.) 447 o A subscription has been abnormally terminated, including the 448 reason. (See subscription-terminated in the model below.) 450 Finally, a server might provide additional information about 451 subscriptions, such as statistics about the number of data updates 452 that were sent. However, such information is currently outside the 453 scope of this specification. 455 3.4.3. Implementation considerations 457 Implementation specifics are outside the scope of this specification. 458 That said, it should be noted that monitoring of operational state 459 changes inside a system can be associated with significant 460 implementation challenges. 462 Even periodic retrieval of operational state alone, to be able to 463 push it, can consume considerable system resources. Configuration 464 data may in many cases be persisted in an actual database or a 465 configuration file, where retrieval of the database content or the 466 file itself is reasonably straightforward and computationally 467 inexpensive. However, retrieval of operational data may, depending 468 on the implementation, require invocation of APIs, possibly on an 469 object-by-object basis, possibly involving additional internal 470 interrupts, etc. 472 For those reasons, if is important for an implementation to 473 understand what subscriptions it can or cannot support. It is far 474 preferrable to decline a subscription request, than to accept it only 475 to result in subsequent failure later. 477 Whether or not a subscription can be supported will in general be 478 determined by a combination of several factors, including the 479 subscription policy (on-change or periodic, with on-change in general 480 being the more challenging of the two), the period in which to report 481 changes (1 second periods will consume more resources than 1 hour 482 periods), the amount of data in the subtree that is being subscribed 483 to, and the number and combination of other subscriptions that are 484 concurrently being serviced. 486 4. YANG module 488 489 file "ietf-datastore-push@2014-10-27.yang" 491 module ietf-datastore-push { 492 // RFC Ed.: replace XXXX with 'ietf' and remove this note 493 namespace "urn:XXXX:params:xml:ns:yang:ietf-datastore-push"; 494 prefix "datastore-push"; 496 import ietf-yang-types { prefix yang; } 498 organization 499 "IETF"; 501 contact 502 "Editor: Alexander Clemm 503 505 Editor: Alberto Gonzalez Prieto 506 508 Editor: Eric Voit 509 "; 511 description 512 "This module contains conceptual YANG specifications 513 for datastore push."; 515 revision 2014-10-27 { 516 description 517 "Initial revision."; 518 reference 519 "Datastore push."; 520 } 522 // Typedefs 523 typedef datastore-contents { 524 type string; 525 description 526 "The encoding of the contents adheres to the subscription 527 parameters. It corresponds to the filtered datastore 528 subtree."; 529 } 531 typedef subscription-identifier { 532 type string { 533 length "1 .. max"; 534 } 535 description 536 "A client-provided identifier for the subscription."; 537 } 539 // Identities 540 // Subscription error 541 identity subscription-errors { 542 description 543 "Base identity for subscription errors."; 544 } 546 typedef subscription-term-reason { 547 type identityref { 548 base "subscription-errors"; 549 } 550 description 551 "Reason for a server to terminate a subscription."; 552 } 554 typedef subscription-susp-reason { 555 type identityref { 556 base "subscription-errors"; 557 } 558 description 559 "Reason for a server to suspend a subscription."; 560 } 562 identity internal-error { 563 base "subscription-errors"; 564 description 565 "Subscription failures caused by server internal error."; 566 } 568 identity no-resources { 569 base "subscription-errors"; 570 description 571 "Lack of resources, e.g. CPU, memory, bandwidth"; 572 } 573 identity other { 574 base "subscription-errors"; 575 description 576 "Fallback reason - any other reason"; 577 } 579 // Notifications 580 notification push-update { 581 description 582 "This notification contains an update from a datastore"; 584 leaf subscription-id { 585 type subscription-identifier; 586 mandatory true; 587 description 588 "This references the subscription because of which the 589 notification is sent."; 590 } 592 leaf datastore-contents { 593 type datastore-contents; 594 description 595 "This contains datastore contents 596 per the subscription."; 597 } 598 } 600 notification subscription-suspended { 601 description 602 "This notification indicates a suspension of the 603 subscription by the server has occurred. No further 604 datastore updates will be sent until subscription 605 resumes."; 607 leaf subscription-id { 608 type subscription-identifier; 609 mandatory true; 610 description 611 "This references the affected subscription."; 612 } 614 leaf reason { 615 type subscription-susp-reason; 616 description 617 "Provides a reason for why the subscription was 618 suspended."; 619 } 621 } 623 notification subscription-resumed { 624 description 625 "This notification indicates that a subscription that had 626 previously been suspended has resumed. Datastore updates 627 will once again be sent."; 628 leaf subscription-id { 629 type subscription-identifier; 630 mandatory true; 631 description 632 "This references the affected subscription."; 633 } 634 } 636 notification subscription-terminated { 637 description 638 "This notification indicates that a subscription has been 639 terminated."; 641 leaf subscription-id { 642 type subscription-identifier; 643 mandatory true; 644 description 645 "This references the affected subscription."; 647 } 649 leaf reason { 650 type subscription-term-reason; 651 description 652 "Provides a reason for why the subscription was 653 terminated."; 654 } 655 } 657 container datastore-push-subscription { 658 description 659 "Content of a yang-push subscription."; 661 leaf stream { 662 type string; 663 mandatory true; 664 description 665 "The name of the stream to subscribe to."; 666 } 667 leaf subscription-id { 668 type subscription-identifier; 669 mandatory true; 670 description 671 "Identifier to use for this subscription."; 672 } 673 choice filter { 674 description 675 "Subset of stream events of interest."; 676 case substree { 677 container subtree-filter { 678 description 679 "Datastore subtree of interest."; 680 } 681 } 683 case xpath { 684 leaf xpath-filter { 685 type yang:xpath1.0; 686 mandatory true; 687 description 688 "Xpath defining the events of interest."; 689 } 690 } 691 } 693 choice notification-trigger { 694 mandatory true; 695 description 696 "Defines necessary conditions for sending an event to 697 the subscriber."; 698 case periodic { 699 description 700 "The agent is requested to notify periodically the 701 current values of the datastore or the subset 702 defined by the filter."; 703 leaf period { 704 type yang:timeticks; 705 mandatory true; 706 description 707 "Elapsed time between notifications."; 708 } 709 } 711 case on-change { 712 description 713 "The agent is requested to notify changes in 714 values in the datastore or a subset of it defined 715 by a filter."; 717 choice change-policy { 718 mandatory true; 719 description 720 "Policy describing necessary conditions for 721 sending an event to the subscriber."; 722 case delta-policy { 723 leaf delta { 724 type uint32; 725 mandatory true; 726 description 727 "For integer, minimum difference 728 between current and last reports 729 values that can trigger an update."; 730 } 731 } 732 } 733 } 734 } 736 leaf start-time { 737 type yang:date-and-time; 738 description 739 "Starting time for replays."; 740 reference "RFC 5277, Section 2.1.1"; 741 } 743 leaf stop-time { 744 type yang:date-and-time; 745 description 746 "Time limit for events of interest."; 747 reference "RFC 5277, Section 2.1.1"; 748 } 749 } 750 } 752 754 5. Security Considerations 756 Subscriptions could be used to attempt to overload servers of YANG 757 datastores. For this reason, it is important that the server has the 758 ability to decline a subscription request if it would deplete its 759 resources. In addition, a server needs to be able to suspend an 760 existing subscription when needed. When this occur, the subscription 761 status is updated accordingly and the clients are notified. 762 Likewise, requests for subscriptions need to be properly authorized. 764 A subscription could be used to retrieve data in subtrees that a 765 client has not authorized access to. Therefore it is important that 766 data pushed based on subscriptions is authorized in the same way that 767 regular data retrieval operations are. Data being pushed to a client 768 needs therefore to be filtered accordingly, just like if the data 769 were being retrieved on-demand. The Netconf Authorization Control 770 Model applies. 772 6. References 774 6.1. Normative References 776 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 777 "Simple Network Management Protocol (SNMP)", STD 15, RFC 778 1157, May 1990. 780 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 781 Notifications", RFC 5277, July 2008. 783 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 784 Network Configuration Protocol (NETCONF)", RFC 6020, 785 October 2010. 787 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 788 Bierman, "Network Configuration Protocol (NETCONF)", RFC 789 6241, June 2011. 791 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 792 Protocol (NETCONF) Access Control Model", RFC 6536, March 793 2012. 795 6.2. Informative References 797 [peermount] 798 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-defined 799 information from remote datastores", draft-clemm-netmod- 800 mount-02 (work in progress), October 2014. 802 [peermount-req] 803 Voit, E., Clemm, A., Bansal, S., Tripathy, A., and P. 804 Yellai, "Requirements for Peer Mounting of YANG subtrees 805 from Remote Datastores", draft-voit-netmod-peer-mount- 806 requirements-00 (work in progress), September 2014. 808 [restconf] 809 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 810 Protocol", I-D draft-ietf-netconf-restconf-03, October 811 2014. 813 Authors' Addresses 815 Alexander Clemm 816 Cisco Systems 818 EMail: alex@cisco.com 820 Alberto Gonzalez Prieto 821 Cisco Systems 823 EMail: albertgo@cisco.com 825 Eric Voit 826 Cisco Systems 828 EMail: evoit@cisco.com