idnits 2.17.1 draft-clemm-netconf-yang-push-01.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 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 363: '... the server SHOULD include in the re...' RFC 2119 keyword, line 391: '...cription request MUST be rejected. As...' RFC 2119 keyword, line 430: '... MUST support XML encoding and MAY s...' RFC 2119 keyword, line 578: '...e push, a server MUST support the inte...' RFC 2119 keyword, line 876: '... Implementations MAY therefore choose,...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 732 has weird spacing: '...-period yan...' == Line 1160 has weird spacing: '...n event to...' == 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 (July 6, 2015) is 3216 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) == Missing Reference: 'RFC-5277' is mentioned on line 288, but not defined == Missing Reference: 'RFC 5277' is mentioned on line 327, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1157 -- Duplicate reference: RFC5277, mentioned in 'RFC6470', was also mentioned in 'RFC5277'. ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-06) exists of draft-clemm-netmod-mount-03 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-00 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-06 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-04 == Outdated reference: A later version (-03) exists of draft-voit-netmod-peer-mount-requirements-02 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). 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: Standards Track E. Voit 5 Expires: January 7, 2016 Cisco Systems 6 July 6, 2015 8 Subscribing to YANG datastore push updates 9 draft-clemm-netconf-yang-push-01.txt 11 Abstract 13 This document defines a subscription and push mechanism for YANG 14 datastores. This mechanism allows client applications to request 15 updates from a YANG datastore, which are then pushed by the server to 16 the client per a subscription policy, without requiring additional 17 client 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 January 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 67 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 7 69 3.2. Negotiation of Subscription Policies . . . . . . . . . . 8 70 3.3. On-Change Considerations . . . . . . . . . . . . . . . . 8 71 3.4. Additional on-change update triggers . . . . . . . . . . 9 72 3.5. Data Encodings . . . . . . . . . . . . . . . . . . . . . 10 73 3.6. Custom Datastreams . . . . . . . . . . . . . . . . . . . 10 74 3.7. Push Data Stream and Transport Mapping . . . . . . . . . 11 75 3.8. Subscription operations . . . . . . . . . . . . . . . . . 12 76 3.9. A YANG data model for management of datastore push 77 subscriptions . . . . . . . . . . . . . . . . . . . . . . 16 78 3.10. Other considerations . . . . . . . . . . . . . . . . . . 18 79 3.10.1. Authorization . . . . . . . . . . . . . . . . . . . 18 80 3.10.2. Additional subscription primitives . . . . . . . . . 19 81 3.10.3. Robustness and reliability considerations . . . . . 20 82 3.10.4. Update size and fragmentation considerations . . . . 20 83 3.10.5. Additional data streams . . . . . . . . . . . . . . 20 84 3.10.6. Subscription persistency . . . . . . . . . . . . . . 20 85 3.10.7. Implementation considerations . . . . . . . . . . . 21 86 4. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 88 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 6.1. Normative References . . . . . . . . . . . . . . . . . . 31 90 6.2. Informative References . . . . . . . . . . . . . . . . . 32 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 YANG [RFC6020] was originally designed for the Netconf protocol 96 [RFC6241], which originally put most emphasis on configuration. 97 However, YANG is not restricted to configuration data. YANG 98 datastores, i.e. datastores that contain data modeled according using 99 YANG, can contain configuration as well as operational data. It is 100 therefore reasonable to expect that data in YANG datastores will 101 increasingly be used to support applications that are not focused on 102 managing configurations but that are, for example, related to service 103 assurance. 105 Service assurance applications typically involve monitoring 106 operational state of networks and devices; of particular interest are 107 changes that this data undergoes over time. Likewise, there are 108 applications in which data and objects from one datastore need to be 109 made available both to applications in other systems and to remote 110 datastores [I-D.voit-netmod-peer-mount-requirements] 111 [I-D.clemm-netmod-mount]. This requires mechanisms that allow remote 112 systems to become quickly aware of any updates to allow to validate 113 and maintain cross-network integrity and consistency. 115 Traditional approaches to remote network state visibility rely 116 heavily on polling. With polling, data is periodically explicitly 117 retrieved by a client from a server to stay up-to-date. 119 There are various issues associated with polling-based management: 121 o It introduces additional load on network, devices, and 122 applications. Each polling cycle requires a separate yet arguably 123 redundant request that results in an interrupt, requires parsing, 124 consumes bandwidth. 126 o It lacks robustness. Polling cycles may be missed, requests may 127 be delayed or get lost, often particularly in cases when the 128 network is under stress and hence exactly when the need for the 129 data is the greatest. 131 o Data may be difficult to calibrate and compare. Polling requests 132 may undergo slight fluctuations, resulting in intervals of 133 different lengths which makes data hard to compare. Likewise, 134 pollers may have difficulty issuing requests that reach all 135 devices at the same time, resulting in offset polling intervals 136 which again make data hard to compare. 138 A more effective alternative is when an application can request to be 139 automatically updated as necessary of current content of the 140 datastore (such as a subtree, or data in a subtree that meets a 141 certain filter condition), and in which the server that maintains the 142 datastore subsequently pushes those updates. However, such a 143 solution does not currently exist. 145 The need to perform polling-based management is typically considered 146 an important shortcoming of management applications that rely on MIBs 147 polled using SNMP [RFC1157]. However, without a provision to support 148 a push-based alternative, there is no reason to believe that 149 management applications that operate on YANG datastores using 150 protocols such as NETCONF [RFC6241] or Restconf 151 [I-D.ietf-netconf-restconf] will be any more effective, as they would 152 follow the same request/response pattern. 154 While YANG allows the definition of notifications, such notifications 155 are generally intended to indicate the occurrence of certain well- 156 specified event conditions, such as a the onset of an alarm condition 157 or the occurrence of an error. A capability to subscribe to and 158 deliver event notifications has been defined in [RFC5277]. In 159 addition, configuration change notifications have been defined in 160 [RFC6470]. These change notifications pertain only to configuration 161 information, not to operational state, and convey the root of the 162 subtree to which changes were applied along with the edits, but not 163 the modified data nodes and their values. 165 Accordingly, there is a need for a service that allows client 166 applications to subscribe to updates of a YANG datastore and that 167 allows the server to push those updates. The requirements for such a 168 service are documented in [I-D.i2rs-pub-sub-requirements]. This 169 document proposes a solution that features the following 170 capabilities: 172 o A mechanism that allows clients to subscribe to automatic 173 datastore updates, and the means to manage those subscription. 174 The subscription allows clients to specify which data they are 175 interested in, and to provide optional filters with criteria that 176 data must meet for updates to be sent. Furthermore, subscription 177 can specify a policy that directs when updates are provided. For 178 example, a client may request to be updated periodically in 179 certain intervals, or whenever data changes occur. 181 o The ability for a server to push back on requested subscription 182 parameters. Because not every server may support every requested 183 interval for every piece of data, it is necessary for a server to 184 be able to indicate whether or not it is capable of supporting a 185 requested subscription, and possibly allow to negotiate 186 subscription parameters. 188 o A mechanism to communicate the updates themselves. For this, the 189 proposal leverages and extends existing YANG/Netconf/Restconf 190 mechanisms, defining special notifications that carry updates. 192 This document specifies a YANG data model to manage subscriptions to 193 data in YANG datastores, and to configure associated filters and data 194 streams. It defines extensions to RPCs defined in [RFC5277] that 195 allow to extend notification subscriptions to subscriptions for 196 datastore updates. It also defines a notification that can be used 197 to carry data updates and thus serve as push mechanism. 199 2. Definitions and Acronyms 201 Data node: An instance of management information in a YANG datastore. 203 Data record: A record containing a set of one or more data node 204 instances and their associated values. 206 Datastore: A conceptual store of instantiated management information, 207 with individual data items represented by data nodes which are 208 arranged in hierarchical manner. 210 Datastream: A continuous stream of data records, each including a set 211 of updates, i.e. data node instances and their associated values. 213 Data subtree: An instantiated data node and the data nodes that are 214 hierarchically contained within it. 216 NACM: NETCONF Access Control Model 218 NETCONF: Network Configuration Protocol 220 Push-update stream: A conceptual data stream of a datastore that 221 streams the entire datastore contents continuously and perpetually. 223 RPC: Remote Procedure Call 225 SNMP: Simple Network Management Protocol 227 Subscription: A contract between a client ("subscriber") and a server 228 ("publisher"), stipulating which information the client wishes to 229 receive from the server (and which information the server has to 230 provide to the client) without the need for further solicitation. 232 Subscription filter: A filter that contains evaluation criteria which 233 are evaluated against YANG objects of a subscription. An update is 234 only published if the object meets the specified filter criteria. 236 Subscription policy: A policy that specifies under what circumstances 237 to push an update, e.g. whether updates are to be provided 238 periodically or only whenever changes occur. 240 Update: A data item containing the current value of a data node. 242 Update trigger: A trigger, as specified by a subscription policy, 243 that causes an update to be sent, respectively a data record to be 244 generated. An example of a trigger is a change trigger, invoked when 245 the value of a data node changes or a data node is created or 246 deleted, or a time trigger, invoked after the laps of a periodic time 247 interval. 249 URI: Uniform Resource Identifier 251 YANG: A data definition language for NETCONF 253 Yang-push: The subscription and push mechanism for YANG datastores 254 that is specified in this document. 256 3. Solution Overview 258 This document specifies a solution that allows clients to subscribe 259 to information updates in a YANG datastore, which are subsequently 260 pushed from the server to the client. 262 Subscriptions are initiated by clients. Servers respond to a 263 subscription request explicitly positively or negatively. Negative 264 responses include information about why the subscription was not 265 accepted, in order to facilitate converging on an acceptable set of 266 subscription parameters. Once a subscription has been established, 267 datastore push updates are pushed from the server to the subscribing 268 client until the subscription ends. 270 Accordingly, the solution encompasses several components: 272 o The subscription model for configuration and management of the 273 subscriptions, with a set of associated services. 275 o The ability to provide hints for acceptable subscription 276 parameters, in cases where a subscription desired by a client 277 cannot currently be served. 279 o The stream of datastore push updates. 281 In addition, there are a number of additional considerations, such as 282 the tie-in of the mechanisms with security mechanisms. Each of those 283 aspects will be discussed in the following subsections. 285 3.1. Subscription Model 287 Yang-push subscriptions are defined using a data model. This model 288 is based on the subscriptions defined in [RFC-5277], which is also 289 reused in Restconf. The model is extended with several parameters, 290 including a subscription type and a subscription ID. 292 A subscription refers to a datastream. The subscription model 293 assumes the presence of a conceptual perpetual datastream "push- 294 update" of continuous datastore updates. A subscription refers to 295 this datastream and specifies filters that are to be applied to, it 296 for example, to provide only those subsets of the information that 297 match a filter criteria. In addition, a subscription specifies a 298 subscription policy that defines the trigger when data records should 299 be sent, for example at periodic intervals or whenever underlying 300 data items change. 302 The complete set of subscription parameters is as follows: 304 o The name of the stream being subscribe to. The subscription model 305 always assumes the presence of a perpetual and continuous stream 306 of updates. The stream is called "push-update". However, as 307 mentioned, it is possible to subscribe to other datastreams, such 308 as custom datastreams which can be separately configured. 310 o Optional filter(s), describing the subset of data items in the 311 stream's data records that are of interest to the subscriber. The 312 server should only send to the subscriber the data items that 313 match the filter(s), when present. The absence of a filter 314 indicates that all data items from the stream are of interest to 315 the subscriber and all data records must be sent in their entirety 316 to the subscriber. Two filtering mechanisms are provided: subtree 317 filtering and Xpath filtering, with the semantics described in 318 [RFC 5277 Section 3.6]. (Additional filter types can be added 319 through extensions.) 321 o An identifier for the subscription. 323 o An optional start time. Used to trigger replays starting at the 324 provided time. Its semantics are those in [RFC 5277]. 326 o An optional stop time. Used to limit temporarily the events of 327 interest. Its semantics are those in [RFC 5277]. 329 o For subscriptions to "push-update", a subscription policy 330 definition regarding the update trigger to send new updates. The 331 trigger can be periodic or based on change. For periodic 332 subscriptions, the trigger is defined by a parameter that defines 333 the interval with which updates are to be pushed. For on-change 334 subscriptions, the trigger occurs when a change in the subscribed 335 information is detected. On-change subscriptions have more 336 complex semantics that is guided by additional parameters. One 337 parameter specifies the dampening period, i.e. the interval that 338 must pass before a successive update for the same data node is 339 sent. Other parameters allow to restrict the types of changes for 340 which updates are sent (changes to object values, object creation 341 or deletion events), and to specify the magnitude of change that 342 must occur before an update is triggered. Please refer also to 343 Section 3.3 and Section 3.4. 345 o An encoding for the data in the push updates, e.g. XML or JSON. 347 It is conceivable that additional subscription parameters might be 348 added in the future. This can be accomplished through augmentation 349 of the subscription data model. 351 3.2. Negotiation of Subscription Policies 353 A subscription rejection can be caused by the inability of the server 354 to provide a stream with the requested semantics. For example, a 355 server may not be able to support "on-change" updates for operational 356 data, or only support them for a limited set of data nodes. 357 Likewise, a server may not be able to support a requested updated 358 frequency, or a requested encoding. 360 Yang-push supports a simple negotiation between clients and servers 361 for subscription parameters. The negotiation is limited to a single 362 pair of subscription request and response. For negative responses, 363 the server SHOULD include in the returned error what subscription 364 parameters would have been accepted for the request. The returned 365 acceptable parameters constitute suggestions that, when followed, 366 increase the likelihood of success for subsequent requests. However, 367 they are no guarantee that subsequent requests for this client or 368 others will in fact be accepted. 370 In case a subscriber requests an encoding other than XML, and this 371 encoding is not supported by the server, the server simply indicates 372 in the response that the encoding is not supported. 374 3.3. On-Change Considerations 376 On-change subscriptions allow clients to subscribe to updates 377 whenever changes to objects occur. As such, on-change subscriptions 378 are of particular interest for data that changes relatively 379 infrequently, yet that require applications to be notified with 380 minimal delay when changes do occur. 382 On-change subscriptions tend to be more difficult to implement than 383 periodic subscriptions. Specifically, on-change subscriptions may 384 involve a notion of state to see if a change occurred between past 385 and current state, or the ability to tap into changes as they occur 386 in the underlying system. Accordingly, on-change subscriptions may 387 not be supported by all implementation or for every object. 389 When an on-change subscription is requested for a datastream with a 390 given subtree filter, where not all objects support on-change update 391 triggers, the subscription request MUST be rejected. As a result, 392 on-change subscription requests will tend to be directed at very 393 specific, targeted subtrees with only few objects. 395 Any updates for an on-change subscription will include only objects 396 for which a change was detected. To avoid flooding clients with 397 repeated updates for fast-changing objects, or objects with 398 oscillating values, an on-change subscription allows for the 399 definition of a dampening period. Once an update for a given object 400 is sent, no other updates for this particular object are sent until 401 the end of the dampening period. 403 In order to avoid sending updates on objects whose values undergo 404 only a negligible change, it is conceivable to attach additional 405 parameters to an on-change subscription specifying a policy that 406 states how large or "significant" a change has to be before an update 407 is sent. A simple policy is a "delta-policy" that states, for 408 integer-valued data nodes, the minimum difference between the current 409 value and the value that was last reported that triggers an update. 410 More sophisticated policies are conceivable, including policies 411 specified in percentage terms or policies that take into account the 412 rate of change. While not specified as part of this draft, such 413 policies can be accommodated by augmenting the subscription data 414 model accordingly. 416 3.4. Additional on-change update triggers 418 In conjunction with on-change update triggers, it is conceivable to 419 further differentiate between the type of change, i.e. whether a 420 change involves the addition of a new data node, the removal of a 421 data node, or a value change. 423 For this purpose, an on-change qualifier is introduced that allows 424 subscribers to specify which update triggers (create, delete, modify) 425 to exclude if updates to all change types are not desired. 427 3.5. Data Encodings 429 Subscribed data is encoded in either XML or JSON format. A server 430 MUST support XML encoding and MAY support JSON encoding. XML 431 encoding rules for data nodes are defined in [RFC6020]. JSON 432 encoding rules are defined in [I-D.ietf-netmod-yang-json]. This 433 encoding is valid JSON, but also has special encoding rules to 434 identify module namespaces and provide consistent type processing of 435 YANG data. 437 It is conceivable that additional encodings may be supported as 438 options in the future. This can be accomplished by augmenting the 439 subscription data model with additional identity statements used to 440 refer to the encodings. 442 3.6. Custom Datastreams 444 Optionally, it is possible to introduce other datastreams (beyond the 445 datastore-push datastream) with custom semantics. Some datastreams 446 can be custom configured. The support of this is tied to a separate 447 feature. The configuration of a custom datastream specifies the 448 trigger conditions under which new data records for the stream are 449 generated, and which updates the corresponding data records contain. 450 For example, the configuration of a datastream can specify which 451 subsets of data nodes in a datastore the datastream should contain, 452 which filter criteria the updates need to meet, and under what 453 conditions to create updates - for example, periodically or whenever 454 a data item changes. 456 A subscription that refers to a custom datastream can specify a set 457 of filters, like for the "push-update" datastream. However, the 458 policy as to when updates are triggered (periodically or on change) 459 needs to be the same as the policy of the datastream and cannot be 460 modified. It is not possible, for example, to define a custom 461 datastream which creates on-change updates, yet subscribe to that 462 datastream with periodic updates. 464 While conceptually similar, the choice between subscribing to 465 datastream "push-update" or configuring and subscribing to a custom 466 datastream can be thought of as analogous to the choice between 467 operating a nozzle that is connected to a hose, or controlling the 468 faucet (custom datastream). Operating the nozzle is for most uses 469 simpler; however, the option to operate the faucet instead can 470 provide additional flexibility in some scenarios. 472 3.7. Push Data Stream and Transport Mapping 474 Pushing data based on a subscription could be considered analogous to 475 a response to a data retrieval request, e.g. a "get" request. 476 However, contrary to such a request, multiple responses to the same 477 request may get sent over a longer period of time. 479 A more suitable mechanism is therefore that of a notification. 480 Contrary to notifications associated with alarms and unexpected event 481 occurrences, push updates are solicited, i.e. tied tied to a 482 particular subscription which triggered the notification. (An 483 alternative conceptual model would consider a subscription an "opt- 484 in" filter on a continuous stream of updates.) 486 The notification contains several parameters: 488 o A subscription correlator, referencing the name of the 489 subscription on whose behalf the notification is sent. 491 o A data node that contains a representation of the datastore 492 subtree containing the updates. The subtree is filtered per 493 access control rules to contain only data that the subscriber is 494 authorized to see. Also, depending on the subscription type, 495 i.e., specifically for on-change subscriptions, the subtree 496 contains only the data nodes that contain actual changes. (This 497 can be simply a node of type string or, for XML-based encoding, 498 anyxml.) 500 Notifications are sent using elements as defined in 501 [RFC5277]. Alternative transports are conceivable but outside the 502 scope of this specification. 504 The solution specified in this document uses notifications to 505 communicate datastore updates. The contents of the notification 506 includes a set of explicitly defined data nodes. For this purpose, a 507 new generic notification is introduced, "push-update" notification. 508 This notification is used to carry a data record with updates of 509 datastore contents as specified by a subscription. 511 The update record consists of a data snippet that contains an 512 instantiated datastore subtree with the subscribed contents. Data 513 nodes that do not match filter criteria are removed. Likewise, in 514 the case of a subscription with "on-change" subscription policy, data 515 nodes that have not undergone change are omitted. The contents of 516 the update record is equivalent to the contents that would be 517 obtained had the same data been explicitly retrieved using e.g. a 518 Netconf "get"-operation, with the same filters applied. 520 The contents of the notification conceptually represents the union of 521 all data nodes in the yang modules supported by the server, excluding 522 the following statements: "mandatory", "must", "min-elements", "max- 523 elements", "when", and "default". However, in a YANG data model, it 524 is not practical to model the precise data contained in the updates 525 as part of the notification. This is because the specific data nodes 526 supported depend on the implementing system and may even vary 527 dynamically. Therefore, to capture this data, a single parameter 528 that can represent any datastore contents is used, not parameters 529 that represent data nodes one at a time. 531 The following is an example of push notification. It contains an 532 update for subscription my-sub, including a subtree with root foo 533 that contains a leaf, bar: 535 536 537 539 my-sub 540 541 2015-03-09T19:14:56Z 542 544 545 some_string 546 547 548 550 Figure 1: Push example 552 3.8. Subscription operations 554 There are several operations associated with subscriptions. At the 555 most basic level, clients need to be able to create subscriptions, as 556 well as delete subscriptions when they are no longer needed. 558 RFC 5277 specifies an operation to create subscriptions for event 559 streams, . This operation is leveraged and 560 extended to create datastore-push subscriptions. The corresponding 561 data model is defined in the "subscription-stream-policy" and 562 "subscription-info" groupings of the YANG module defined in 563 Section 4. Specifically: 565 o An additional parameter is added to allow for the specification of 566 trigger policy. If the trigger is periodic, a parameter specifies 567 the period with which updates are to occur. If the trigger is on 568 change, a parameter specifies a dampening period that defines how 569 much time must pass before another update for a data node is sent, 570 once an update for that data node is sent. Additional optional 571 parameters can further refine trigger behavior, such as 572 restrictions on the types of changes for which updates are to be 573 sent. 575 o An additional parameter is added to allow to specify, as an 576 option, the desired encoding of the data payload. 578 To support datastore push, a server MUST support the interleave 579 capability specified in [RFC5277]. This is required to allow for 580 modification of what data is being subscribed to without needing to 581 establish a separate Netconf session. 583 The example below illustrates a subscription for a periodic push of 584 all data under a container called foo. 586 588 590 push-update 591 593 my-sub 594 595 598 599 500 600 601 602 encode-xml 603 604 605 607 Figure 2: Subscription example 609 A success response by the server implies that the server will be able 610 to serve the subscription as requested. It constitutes a "promise" 611 of the server to push updates to the subscriber along the parameters 612 that were requested. 614 The server is not obliged to accept a request if there are any 615 aspects of the request that it would not be able to meet. This 616 includes any reason, including update interval periods that are too 617 short (requiring more resources than the server could handle), a 618 filter condition that is not supported, or a requested encoding that 619 is not supported. Other failure reasons include specification of a 620 subscription-id that is already in use (modify-subscription should be 621 used to make changes to settings of existing subscriptions), or 622 authorization failures (please refer also to section Section 3.10.1.) 624 The example below illustrates a subscription response, where an agent 625 does not support frequent periodic updates, and suggests a different 626 sampling rate to the client. 628 629 630 application 631 operation-not-supported 632 error 633 634 636 3000 637 638 639 640 642 Figure 3: Subscription negotiation example 644 RFC 5277 does not specify operations to delete subscriptions. 645 Instead, it assumes that an event subscription is associated with its 646 own Netconf session. When the session is torn down, the subscription 647 is implicitly deleted. Likewise, there is no operation to modify a 648 subscription. Modifying a subscription requires tearing down a 649 Netconf session, starting a new one, and creating a new subscription. 650 Furthermore, each session only supports a single subscription. 651 Establishing multiple subscriptions requires multiple concurrent 652 Netconf sessions. 654 To facilitate datastore-push subscriptions, an additional RPC is 655 introduced, . 657 The operation takes as parameter a subscription 658 ID. As a result of the operation, the subscription is removed and no 659 more data records will be sent. 661 663 665 667 my-sub 668 669 670 672 Figure 4: Subscription deletion 674 Finally, a separate operation to modify a subscription is introduced, 675 . This operation takes the same parameters as 676 , but refers to an existing subscription. Of 677 course, a subscription could also be deleted and another be created. 678 However, modify operation avoids issues regarding the synchronization 679 of creation and deletion operations, such as potential loss or 680 duplication of updates. Also, a modify operation allows to simply 681 extend an existing subscription beyond the initial subscription end 682 time. 684 686 688 push-update 689 691 my-sub 692 693 696 698 3000 699 700 701 703 Figure 5: Modify subscription 705 3.9. A YANG data model for management of datastore push subscriptions 707 Subscriptions as well as datastreams can be subjected to management 708 themselves. For example, it is possible that a server may no longer 709 be able to serve a subscription that it had previously accepted. 710 Perhaps it has run out of resources, or internal errors may have 711 occurred. When this is the case, a server needs to be able to 712 temporarily suspend the subscription, or even to terminate it. More 713 generally, the server should provide a means by which the status of 714 subscriptions can be monitored. When custom datastreams are 715 supported, those datastreams need to be configured and monitored as 716 well. 718 For this purpose, a YANG data model is introduced, which is depicted 719 in the following figure. 721 module: ietf-datastore-push 722 +--rw streams {custom-streams}? 723 | +--rw stream* [stream-name] 724 | +--rw stream-name string 725 | +--ro stream-status? identityref 726 | +--rw subtree-filter? subtree-filter 727 | +--rw xpath-filter? yang:xpath1.0 728 | +--rw (update-trigger)? 729 | +--:(periodic) 730 | | +--rw period? yang:timeticks 731 | +--:(on-change) 732 | +--rw dampening-period yang:timeticks 733 | +--rw excluded-change* change-type 734 | +--rw (change-policy)? 735 | +--:(delta-policy) 736 | +--rw delta? uint32 737 +--rw subscriptions 738 +--ro datastore-push-subscription* [subscription-id] 739 +--ro subscription-id subscription-identifier 740 +--ro subscription-status? identityref 741 +--ro stream? string 742 +--ro encoding? encoding 743 +--ro start-time? yang:date-and-time 744 +--ro stop-time? yang:date-and-time 745 +--ro subtree-filter? subtree-filter 746 +--ro xpath-filter? yang:xpath1.0 747 +--ro (update-trigger)? 748 +--:(periodic) 749 | +--ro period? yang:timeticks 750 +--:(on-change) 751 +--ro dampening-period yang:timeticks 752 +--ro excluded-change* change-type 753 +--ro (change-policy)? 754 +--:(delta-policy) 755 +--ro delta? uint32 757 Figure 6: Model structure 759 Each subscription is represented as a list element "datastore-push- 760 subscription". The associated information includes an identifier for 761 the subscription, a subscription status, as well as the various 762 subscription paramters. The subscription status indicates whether 763 the subscription is currently active and healthy, or if it is 764 degraded in some form. Subscriptions are automatically removed from 765 the list once they expire or are terminated. Because subscriptions 766 are managed using their own set of operation primitives, they are 767 read-only. 769 An optional feature, custom-streams, is introduced to allow for the 770 configuration of custom datastreams. Custom datastreams are 771 represented through a separate list, consisting of information used 772 to configure those datastreams. This information consititutes mostly 773 configuration information, with the exception of parameters used to 774 indicate the status and health of the datastream. 776 In addition, a server needs to indicate any changes in status to the 777 subscriber through a notification. Specifically, subscribers need to 778 be informed of the following: 780 o A subscription has been temporarily suspended (including the 781 reason) 783 o A subscription (that had been suspended earlier) is once again 784 operational 786 o A subscription has been abnormally terminated (including the 787 reason) 789 o A subscription has been modified (including the current set of 790 subscription parameters in effect) 792 Finally, a server might provide additional information about 793 subscriptions, such as statistics about the number of data updates 794 that were sent. However, such information is currently outside the 795 scope of this specification. 797 3.10. Other considerations 799 3.10.1. Authorization 801 A receiver of subscription data may only be sent updates for which 802 they have proper authorization. Data that is being pushed therefore 803 needs to be subjected to a filter that applies all corresponding 804 rules applicable at the time of a specific pushed update, removing 805 any non-authorized data as applicable. 807 The authorization model for data in YANG datastores is described in 808 the Netconf Access Control Model [RFC6536]. However, some 809 clarifications to that RFC are needed so that the desired access 810 control behavior is applied to pushed updates. 812 One of these clarifications is that a subscription may only be 813 established if the Subscriber has read access to the target data 814 node. 816 +-------------+ +-------------+ 817 subscription | protocol | | target | 818 request --> | operation | -------------> | data node | 819 | allowed? | datastore | access | 820 +-------------+ or state | allowed? | 821 data access +-------------+ 823 Figure 7: Access control for subscription 825 Likewise if a subscriber no longer has read access permission to a 826 target data node, the subscription must be abnormally terminated 827 (with loss of access permission as the reason provided). 829 Another clarification to [RFC6536] is that each of the individual 830 nodes in a pushed update must also go through access control 831 filtering. This includes new nodes added since the last push update, 832 as well as existing nodes. For each of these read access must be 833 verified. The methods of doing this efficiently are left to 834 implementation. 836 +-------------+ +-------------------+ 837 subscription | data node | yes | | 838 update --> | access | ---> | add data node | 839 | allowed? | | to update message | 840 +-------------+ +-------------------+ 842 Figure 8: Access control for push updates 844 If there are read access control changes applied under the target 845 node, no notifications indicating the fact that this has occurred 846 need to be provided. 848 3.10.2. Additional subscription primitives 850 Other possible operations include the ability for a Subscriber to 851 request the suspension/resumption of a Subscription with a Publisher. 852 However, subscriber driven suspension is not viewed as essential at 853 this time, as a simpler alternative is to remove a subscription and 854 recreate it when needed. 856 It should be noted that this does not affect the ability of the 857 Publisher to suspend a subscription. This can occur in cases the 858 server is not able to serve the subscription for a certain period of 859 time, and indicated by a corresponding notification. 861 3.10.3. Robustness and reliability considerations 863 Particularly in the case of on-change push updates, it is important 864 that push updates do not get lost. However, datastore-push uses a 865 secure and reliable transport. Notifications are not getting 866 reordered, and in addition contain a time stamp. For those reasons, 867 we believe that additional reliability mechanisms at the application 868 level, such as sequence numbers for push updates, are not required. 870 3.10.4. Update size and fragmentation considerations 872 Depending on the subscription, the volume of updates can become quite 873 large. There is no inherent limitation to the amount of data that 874 can be included in a notification. That said, it may not always be 875 practical to send the entire update in a single chunk. 876 Implementations MAY therefore choose, at their discretion, to "chunk" 877 updates and break them out into several update notifications. 879 3.10.5. Additional data streams 881 The conceptual data stream introduced in this specification, 882 datastore-push, includes the entire YANG datastore in its scope. It 883 is conceivable to introduce other data streams with more limited 884 scope, for example: 886 o operdata-push, a datastream containing all operational (read-only) 887 data of a YANG datastore 889 o operdata-nocounts-push, a datastream containing all operational 890 (read-only) data with the exception of counters 892 Those data streams make particular sense for use cases involving 893 service assurance (not relying on operational data), and for use 894 cases requiring on-change update triggers which make no sense to 895 support in conjunction with fast-changing counters. While it is 896 possible to specify subtree filters on datastore-push to the same 897 effect, having those data streams greatly simplifies articulating 898 subscriptions in such scenarios. 900 3.10.6. Subscription persistency 902 This specification assumes that a subscriber will explicitly request 903 a subscription before it receives any update. It does not foresee 904 that a subscription can be in effect without a subscriber needing to 905 enter a subscription first. 907 It is conceivable that scenarios exist in which subscriptions should 908 be persisted and in effect simply constitute a part of a device's 909 configuration, i.e. scenarios that require a device to simply start 910 sending updates without requiring a subscription to be established 911 first. While this possibility is not supported by this 912 specification, there are several ways in which it can be addressed. 913 One possibility involves adding a subscription configuration model, 914 which allows to enter subscriptions as part of a configuration. 915 Another possibility involves the introduction of a subscription 916 proxy, a subscriber which acts as intermediary between the system 917 whose updates are being subscribed to and the actual consuming 918 application. 920 3.10.7. Implementation considerations 922 Implementation specifics are outside the scope of this specification. 923 That said,it should be noted that monitoring of operational state 924 changes inside a system can be associated with significant 925 implementation challenges. 927 Even periodic retrieval of operational state alone, to be able to 928 push it, can consume considerable system resources. Configuration 929 data may in many cases be persisted in an actual database or a 930 configuration file, where retrieval of the database content or the 931 file itself is reasonably straightforward and computationally 932 inexpensive. However, retrieval of operational data may, depending 933 on the implementation, require invocation of APIs, possibly on an 934 object-by-object basis, possibly involving additional internal 935 interrupts, etc. 937 For those reasons, if is important for an implementation to 938 understand what subscriptions it can or cannot support. It is far 939 preferrable to decline a subscription request, than to accept it only 940 to result in subsequent failure later. 942 Whether or not a subscription can be supported will in general be 943 determined by a combination of several factors, including the 944 subscription policy (on-change or periodic, with on-change in general 945 being the more challenging of the two), the period in which to report 946 changes (1 second periods will consume more resources than 1 hour 947 periods), the amount of data in the subtree that is being subscribed 948 to, and the number and combination of other subscriptions that are 949 concurrently being serviced. 951 When providing access control to every node in a pushed update, it is 952 possible to make and update efficient access control filters for an 953 update. These filters can be set upon subscription and applied 954 against a stream of updates. These filters need only be updated when 955 (a) there is a new node added/removed from the subscribed tree with 956 different permissions than its parent, or (b) read access permissions 957 have been changed on nodes under the target node for the subscriber. 959 4. YANG module 961 962 file "ietf-datastore-push@2015-07-06.yang" 964 module ietf-datastore-push { 965 namespace "urn:ietf:params:xml:ns:yang:ietf-datastore-push"; 966 prefix datastore-push; 968 import ietf-yang-types { 969 prefix yang; 970 } 972 organization "IETF"; 973 contact 974 "WG Web: 975 WG List: 977 WG Chair: Juergen Schoenwaelder 978 980 WG Chair: Kent Watsen 981 983 WG Chair: Tom Nadeau 984 986 Editor: Alexander Clemm 987 989 Editor: Alberto Gonzalez Prieto 990 992 Editor: Eric Voit 993 "; 994 description 995 "This module contains conceptual YANG specifications 996 for datastore push."; 998 revision 2015-07-06 { 999 description 1000 "Initial revision."; 1001 reference "Datastore push."; 1002 } 1003 feature custom-streams { 1004 description 1005 "This feature allows users to configure datastore update 1006 streams in addition to the stream provided by default, 1007 datastore-push."; 1008 } 1010 identity subscription-stream-status { 1011 description 1012 "Base identity for the status of subscriptions and 1013 datastreams."; 1014 } 1016 identity active { 1017 base subscription-stream-status; 1018 description 1019 "Status is active and healthy."; 1020 } 1022 identity inactive { 1023 base subscription-stream-status; 1024 description 1025 "Status is inactive, for example outside the 1026 interval between start time and stop time."; 1027 } 1029 identity in-error { 1030 base subscription-stream-status; 1031 description 1032 "The status is in error or degraded, meaning that 1033 stream and/or subscription are currently unable to provide 1034 the negotiated updates."; 1035 } 1037 identity subscription-errors { 1038 description 1039 "Base identity for subscription errors."; 1040 } 1042 identity internal-error { 1043 base subscription-errors; 1044 description 1045 "Subscription failures caused by server internal error."; 1046 } 1048 identity no-resources { 1049 base subscription-errors; 1050 description 1051 "Lack of resources, e.g. CPU, memory, bandwidth"; 1052 } 1054 identity other { 1055 base subscription-errors; 1056 description 1057 "Fallback reason - any other reason"; 1058 } 1060 identity encodings { 1061 description 1062 "Base identity to represent data encodings"; 1063 } 1065 identity encode-xml { 1066 base encodings; 1067 description 1068 "Encode data using XML"; 1069 } 1071 identity encode-json { 1072 base encodings; 1073 description 1074 "Encode data using JSON"; 1075 } 1077 typedef datastore-contents { 1078 type string; 1079 description 1080 "This type is be used to represent datastore contents, 1081 including a filtered datastore subtree per a set of 1082 subscription parameters. "; 1083 } 1085 typedef subtree-filter { 1086 type string; 1087 description 1088 "This type is used to define a subtree filter. 1089 Its precise syntax is TBD."; 1090 } 1092 typedef subscription-identifier { 1093 type string { 1094 length "1 .. max"; 1095 } 1096 description 1097 "A client-provided identifier for the subscription."; 1098 } 1099 typedef subscription-term-reason { 1100 type identityref { 1101 base subscription-errors; 1102 } 1103 description 1104 "Reason for a server to terminate a subscription."; 1105 } 1107 typedef subscription-susp-reason { 1108 type identityref { 1109 base subscription-errors; 1110 } 1111 description 1112 "Reason for a server to suspend a subscription."; 1113 } 1115 typedef encoding { 1116 type identityref { 1117 base encodings; 1118 } 1119 description 1120 "Specifies a data encoding, e.g. for a data subscription."; 1121 } 1123 typedef change-type { 1124 type enumeration { 1125 enum "create" { 1126 description 1127 "A new data node was created"; 1128 } 1129 enum "delete" { 1130 description 1131 "A data node was deleted"; 1132 } 1133 enum "modify" { 1134 description 1135 "The value of a data node has changed"; 1136 } 1137 } 1138 description 1139 "Specifies different types of changes that may occur 1140 to a datastore."; 1141 } 1143 grouping subscription-stream-policy { 1144 description 1145 "This grouping contains the parameters which describe 1146 the policy which data is pushed as part of a 1147 subscription or a data stream."; 1148 leaf subtree-filter { 1149 type subtree-filter; 1150 description 1151 "Datastore subtree of interest."; 1152 } 1153 leaf xpath-filter { 1154 type yang:xpath1.0; 1155 description 1156 "Xpath defining the data items of interest."; 1157 } 1158 choice update-trigger { 1159 description 1160 "Defines necessary conditions for sending an event to 1161 the subscriber."; 1162 case periodic { 1163 description 1164 "The agent is requested to notify periodically the 1165 current values of the datastore or the subset 1166 defined by the filter."; 1167 leaf period { 1168 type yang:timeticks; 1169 description 1170 "Elapsed time between notifications."; 1171 } 1172 } 1173 case on-change { 1174 description 1175 "The agent is requested to notify changes in 1176 values in the datastore or a subset of it defined 1177 by a filter."; 1178 leaf dampening-period { 1179 type yang:timeticks; 1180 mandatory true; 1181 description 1182 "Minimum amount of time that needs to have 1183 passed since the last time an update was 1184 provided."; 1185 } 1186 leaf-list excluded-change { 1187 type change-type; 1188 description 1189 "Use to restrict which changes trigger an update. 1190 For example, if modify is excluded, only creation and 1191 deletion of objects is reported."; 1192 } 1193 choice change-policy { 1194 description 1195 "Policy describing necessary conditions for 1196 sending an event to the subscriber."; 1197 case delta-policy { 1198 leaf delta { 1199 type uint32; 1200 description 1201 "For modified values of an integer-typed object, 1202 minimum difference between current and last 1203 report values that can trigger an update."; 1204 } 1205 } 1206 } 1207 } 1208 } 1209 } 1211 grouping subscription-info { 1212 description 1213 "This grouping describes basic information concerning a 1214 subscription, without the subscription policy which is 1215 defined separately to be shareable with the definition 1216 of a datastream."; 1217 leaf stream { 1218 type string; 1219 description 1220 "The name of the stream subscribed to."; 1221 } 1222 leaf encoding { 1223 type encoding; 1224 default encode-xml; 1225 description 1226 "The type of encoding for the subscribed data. 1227 Default is XML"; 1228 } 1229 leaf start-time { 1230 type yang:date-and-time; 1231 description 1232 "Starting time for replays."; 1233 reference "RFC 5277, Section 2.1.1"; 1234 } 1235 leaf stop-time { 1236 type yang:date-and-time; 1237 description 1238 "Time limit for events of interest."; 1239 reference "RFC 5277, Section 2.1.1"; 1240 } 1241 } 1242 notification push-update { 1243 description 1244 "This notification contains an update from a datastore"; 1245 leaf subscription-id { 1246 type subscription-identifier; 1247 mandatory true; 1248 description 1249 "This references the subscription because of which the 1250 notification is sent."; 1251 } 1252 leaf datastore-contents { 1253 type datastore-contents; 1254 description 1255 "This contains datastore contents 1256 per the subscription."; 1257 } 1258 } 1259 notification subscription-suspended { 1260 description 1261 "This notification indicates that a suspension of the 1262 subscription by the server has occurred. No further 1263 datastore updates will be sent until subscription 1264 resumes."; 1265 leaf subscription-id { 1266 type subscription-identifier; 1267 mandatory true; 1268 description 1269 "This references the affected subscription."; 1270 } 1271 leaf reason { 1272 type subscription-susp-reason; 1273 description 1274 "Provides a reason for why the subscription was 1275 suspended."; 1276 } 1277 } 1278 notification subscription-resumed { 1279 description 1280 "This notification indicates that a subscription that had 1281 previously been suspended has resumed. Datastore updates 1282 will once again be sent."; 1283 leaf subscription-id { 1284 type subscription-identifier; 1285 mandatory true; 1286 description 1287 "This references the affected subscription."; 1288 } 1289 } 1290 notification subscription-modified { 1291 description 1292 "This notification indicates that a subscription has 1293 been modified. Datastore updates sent from this point 1294 on will conform to the modified terms of the 1295 subscription."; 1296 leaf subscription-id { 1297 type subscription-identifier; 1298 mandatory true; 1299 description 1300 "This references the affected subscription."; 1301 } 1302 uses subscription-info; 1303 uses subscription-stream-policy; 1304 } 1305 notification subscription-terminated { 1306 description 1307 "This notification indicates that a subscription has been 1308 terminated."; 1309 leaf subscription-id { 1310 type subscription-identifier; 1311 mandatory true; 1312 description 1313 "This references the affected subscription."; 1314 } 1315 leaf reason { 1316 type subscription-term-reason; 1317 description 1318 "Provides a reason for why the subscription was 1319 terminated."; 1320 } 1321 } 1322 container streams { 1323 if-feature custom-streams; 1324 description 1325 "This container contains management data for custom streams 1326 that are configured by a user."; 1327 list stream { 1328 key "stream-name"; 1329 description 1330 "A user-definable stream."; 1331 leaf stream-name { 1332 type string; 1333 mandatory true; 1334 description 1335 "The name assigned to the stream."; 1336 } 1337 leaf stream-status { 1338 type identityref { 1339 base subscription-stream-status; 1340 } 1341 config false; 1342 description 1343 "The current status of the stream"; 1344 } 1345 uses subscription-stream-policy; 1346 } 1347 } 1348 container subscriptions { 1349 description 1350 "Contains the list of currently active subscription, 1351 used for subscription management and monitoring purposes. 1352 Note that this concerns subscriptions that are in-effect. 1353 Configuration and setup of subscriptions occurs via separate 1354 primitives, e.g. create-subscription, delete-subscription, 1355 and modify-subscription."; 1356 list datastore-push-subscription { 1357 key "subscription-id"; 1358 config false; 1359 description 1360 "Content of a yang-push subscription. 1361 Subscriptions are created using a dedicated RPC, hence 1362 they do not constitute configuration information."; 1363 leaf subscription-id { 1364 type subscription-identifier; 1365 description 1366 "Identifier to use for this subscription."; 1367 } 1368 leaf subscription-status { 1369 type identityref { 1370 base subscription-stream-status; 1371 } 1372 description 1373 "The status of the subscription."; 1374 } 1375 uses subscription-info; 1376 uses subscription-stream-policy; 1377 } 1378 } 1379 } 1381 1383 5. Security Considerations 1385 Subscriptions could be used to attempt to overload servers of YANG 1386 datastores. For this reason, it is important that the server has the 1387 ability to decline a subscription request if it would deplete its 1388 resources. In addition, a server needs to be able to suspend an 1389 existing subscription when needed. When this occur, the subscription 1390 status is updated accordingly and the clients are notified. 1391 Likewise, requests for subscriptions need to be properly authorized. 1393 A subscription could be used to retrieve data in subtrees that a 1394 client has not authorized access to. Therefore it is important that 1395 data pushed based on subscriptions is authorized in the same way that 1396 regular data retrieval operations are. Data being pushed to a client 1397 needs therefore to be filtered accordingly, just like if the data 1398 were being retrieved on-demand. The Netconf Authorization Control 1399 Model applies. 1401 6. References 1403 6.1. Normative References 1405 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 1406 "Simple Network Management Protocol (SNMP)", STD 15, RFC 1407 1157, May 1990. 1409 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1410 Notifications", RFC 5277, July 2008. 1412 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1413 Network Configuration Protocol (NETCONF)", RFC 6020, 1414 October 2010. 1416 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1417 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1418 6241, June 2011. 1420 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 1421 Base Notifications", RFC 5277, February 2012. 1423 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1424 Protocol (NETCONF) Access Control Model", RFC 6536, March 1425 2012. 1427 6.2. Informative References 1429 [I-D.clemm-netmod-mount] 1430 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-defined 1431 information from remote datastores", draft-clemm-netmod- 1432 mount-03 (work in progress), April 2015. 1434 [I-D.i2rs-pub-sub-requirements] 1435 Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1436 for Subscription to YANG Datastores", draft-ietf-i2rs-pub- 1437 sub-requirements-00 (work in progress), March 2015. 1439 [I-D.ietf-netconf-restconf] 1440 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1441 Protocol", I-D draft-ietf-netconf-restconf-06, June 2015. 1443 [I-D.ietf-netmod-yang-json] 1444 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1445 draft-ietf-netmod-yang-json-04 (work in progress), June 1446 2015. 1448 [I-D.voit-netmod-peer-mount-requirements] 1449 Voit, E., Clemm, A., and S. Mertens, "Requirements for 1450 Peer Mounting of YANG subtrees from Remote Datastores", 1451 draft-voit-netmod-peer-mount-requirements-02 (work in 1452 progress), March 2015. 1454 Authors' Addresses 1456 Alexander Clemm 1457 Cisco Systems 1459 EMail: alex@cisco.com 1461 Alberto Gonzalez Prieto 1462 Cisco Systems 1464 EMail: albertgo@cisco.com 1466 Eric Voit 1467 Cisco Systems 1469 EMail: evoit@cisco.com