idnits 2.17.1 draft-ietf-netconf-yang-push-02.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 471: '... the server SHOULD include in the re...' RFC 2119 keyword, line 499: '...cription request MUST be rejected. As...' RFC 2119 keyword, line 535: '... MUST support XML encoding and MAY s...' RFC 2119 keyword, line 867: '... MAY be returned that would likely h...' RFC 2119 keyword, line 928: '...ations. Servers SHOULD reject attempt...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1364 has weird spacing: '...tion-id sub...' == Line 1367 has weird spacing: '...tion-id sub...' == Line 1396 has weird spacing: '...tion-id sub...' == 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 (March 21, 2016) is 2957 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 6241' is mentioned on line 430, but not defined == Missing Reference: 'RFC 5277' is mentioned on line 431, 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 (-06) exists of draft-clemm-netmod-mount-03 -- Duplicate reference: draft-clemm-netmod-mount, mentioned in 'I-D.gonzalez-netconf-5277bis', was also mentioned in 'I-D.clemm-netmod-mount'. == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-05 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-10 == Outdated reference: A later version (-14) exists of draft-ietf-netconf-yang-patch-08 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-07 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 3 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: September 22, 2016 A. Tripathy 6 E. Nilsen-Nygaard 7 Cisco Systems 8 March 21, 2016 10 Subscribing to YANG datastore push updates 11 draft-ietf-netconf-yang-push-02.txt 13 Abstract 15 This document defines a subscription and push mechanism for YANG 16 datastores. This mechanism allows client applications to request 17 updates from a YANG datastore, which are then pushed by the server to 18 a receiver per a subscription policy, without requiring additional 19 client requests. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 22, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 69 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 8 71 3.2. Negotiation of Subscription Policies . . . . . . . . . . 10 72 3.3. On-Change Considerations . . . . . . . . . . . . . . . . 11 73 3.4. Data Encodings . . . . . . . . . . . . . . . . . . . . . 12 74 3.4.1. Periodic Subscriptions . . . . . . . . . . . . . . . 12 75 3.4.2. On-Change Subscriptions . . . . . . . . . . . . . . . 12 76 3.5. Subscription Filters . . . . . . . . . . . . . . . . . . 13 77 3.6. Subscription State Model at the Publisher . . . . . . . . 13 78 3.7. Push Data Stream and Transport Mapping . . . . . . . . . 14 79 3.8. Subscription management . . . . . . . . . . . . . . . . . 19 80 3.8.1. Subscription management by RPC . . . . . . . . . . . 19 81 3.8.2. Subscription management by configuration . . . . . . 21 82 3.9. Other considerations . . . . . . . . . . . . . . . . . . 21 83 3.9.1. Authorization . . . . . . . . . . . . . . . . . . . . 21 84 3.9.2. Additional subscription primitives . . . . . . . . . 22 85 3.9.3. Robustness and reliability considerations . . . . . . 23 86 3.9.4. Update size and fragmentation considerations . . . . 23 87 3.9.5. Push data streams . . . . . . . . . . . . . . . . . . 23 88 3.9.6. Implementation considerations . . . . . . . . . . . . 24 89 3.9.7. Alignment with RFC 5277bis . . . . . . . . . . . . . 25 90 4. A YANG data model for management of datastore push 91 subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 25 92 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25 93 4.2. Update streams . . . . . . . . . . . . . . . . . . . . . 31 94 4.3. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 4.4. Subscription configuration . . . . . . . . . . . . . . . 32 96 4.5. Subscription monitoring . . . . . . . . . . . . . . . . . 34 97 4.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 34 98 4.7. RPCs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 99 4.7.1. Establish-subscription RPC . . . . . . . . . . . . . 35 100 4.7.2. Modify-subscription RPC . . . . . . . . . . . . . . . 37 101 4.7.3. Delete-subscription RPC . . . . . . . . . . . . . . . 39 102 5. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 39 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 62 104 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 105 7.1. Normative References . . . . . . . . . . . . . . . . . . 63 106 7.2. Informative References . . . . . . . . . . . . . . . . . 63 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 109 1. Introduction 111 YANG [RFC6020] was originally designed for the Netconf protocol 112 [RFC6241], which originally put most emphasis on configuration. 113 However, YANG is not restricted to configuration data. YANG 114 datastores, i.e. datastores that contain data modeled according using 115 YANG, can contain configuration as well as operational data. It is 116 therefore reasonable to expect that data in YANG datastores will 117 increasingly be used to support applications that are not focused on 118 managing configurations but that are, for example, related to service 119 assurance. 121 Service assurance applications typically involve monitoring 122 operational state of networks and devices; of particular interest are 123 changes that this data undergoes over time. Likewise, there are 124 applications in which data and objects from one datastore need to be 125 made available both to applications in other systems and to remote 126 datastores [I-D.voit-netmod-yang-mount-requirements] 127 [I-D.clemm-netmod-mount]. This requires mechanisms that allow remote 128 systems to become quickly aware of any updates to allow to validate 129 and maintain cross-network integrity and consistency. 131 Traditional approaches to remote network state visibility rely 132 heavily on polling. With polling, data is periodically explicitly 133 retrieved by a client from a server to stay up-to-date. 135 There are various issues associated with polling-based management: 137 o It introduces additional load on network, devices, and 138 applications. Each polling cycle requires a separate yet arguably 139 redundant request that results in an interrupt, requires parsing, 140 consumes bandwidth. 142 o It lacks robustness. Polling cycles may be missed, requests may 143 be delayed or get lost, often particularly in cases when the 144 network is under stress and hence exactly when the need for the 145 data is the greatest. 147 o Data may be difficult to calibrate and compare. Polling requests 148 may undergo slight fluctuations, resulting in intervals of 149 different lengths which makes data hard to compare. Likewise, 150 pollers may have difficulty issuing requests that reach all 151 devices at the same time, resulting in offset polling intervals 152 which again make data hard to compare. 154 A more effective alternative is when an application can request to be 155 automatically updated as necessary of current content of the 156 datastore (such as a subtree, or data in a subtree that meets a 157 certain filter condition), and in which the server that maintains the 158 datastore subsequently pushes those updates. However, such a 159 solution does not currently exist. 161 The need to perform polling-based management is typically considered 162 an important shortcoming of management applications that rely on MIBs 163 polled using SNMP [RFC1157]. However, without a provision to support 164 a push-based alternative, there is no reason to believe that 165 management applications that operate on YANG datastores using 166 protocols such as NETCONF or Restconf [I-D.ietf-netconf-restconf] 167 will be any more effective, as they would follow the same request/ 168 response pattern. 170 While YANG allows the definition of notifications, such notifications 171 are generally intended to indicate the occurrence of certain well- 172 specified event conditions, such as a the onset of an alarm condition 173 or the occurrence of an error. A capability to subscribe to and 174 deliver event notifications has been defined in [RFC5277]. In 175 addition, configuration change notifications have been defined in 176 [RFC6470]. These change notifications pertain only to configuration 177 information, not to operational state, and convey the root of the 178 subtree to which changes were applied along with the edits, but not 179 the modified data nodes and their values. 181 Accordingly, there is a need for a service that allows client 182 applications to dynamically subscribe to updates of a YANG datastore 183 and that allows the server to push those updates. Additionally, 184 support for static subscriptions configured directly on the server 185 are also useful when dynamic signaling is undesirable or unsupported. 186 The requirements for such a service are documented in 187 [I-D.i2rs-pub-sub-requirements]. This document proposes a solution 188 that features the following capabilities: 190 o A mechanism that allows clients to dynamically subscribe to 191 automatic datastore updates, and the means to manage those 192 subscription. The subscription allows clients to specify which 193 data they are interested in, and to provide optional filters with 194 criteria that data must meet for updates to be sent. Furthermore, 195 subscription can specify a policy that directs when updates are 196 provided. For example, a client may request to be updated 197 periodically in certain intervals, or whenever data changes occur. 199 o An alternative mechanism that allows for the static configuration 200 of subscriptions to automatic data store updates as part of a 201 device configuration. In addition to the aspects that are 202 configurable for a dynamic subscription (filter criteria, update 203 policy), static configuration of subscriptions allows for the 204 definition of additional aspects such as intended receivers and 205 alternative transport options. 207 o The ability for a server to push back on requested subscription 208 parameters. Because not every server may support every requested 209 interval for every piece of data, it is necessary for a server to 210 be able to indicate whether or not it is capable of supporting a 211 requested subscription, and possibly allow to negotiate 212 subscription parameters. 214 o A mechanism to communicate the updates themselves. For this, the 215 proposal leverages and extends existing YANG/Netconf/Restconf 216 mechanisms, defining special notifications that carry updates. 218 This document specifies a YANG data model to manage subscriptions to 219 data in YANG datastores, and to configure associated filters and data 220 streams. It defines extensions to RPCs defined in [RFC5277] that 221 allow to extend notification subscriptions to subscriptions for 222 datastore updates. It also defines a notification that can be used 223 to carry data updates and thus serve as push mechanism. 225 Editor's note: A new draft [I-D.gonzalez-netconf-5277bis] has just 226 been released to address many of the current Netconf Event Model's 227 limitations, as chartered by the Netconf Working Group. This draft 228 will be leveraged in future revisions of this document. 230 2. Definitions and Acronyms 232 Data node: An instance of management information in a YANG datastore. 234 Data record: A record containing a set of one or more data node 235 instances and their associated values. 237 Datastore: A conceptual store of instantiated management information, 238 with individual data items represented by data nodes which are 239 arranged in hierarchical manner. 241 Datastream: A continuous stream of data records, each including a set 242 of updates, i.e. data node instances and their associated values. 244 Data subtree: An instantiated data node and the data nodes that are 245 hierarchically contained within it. 247 Dynamic subscription: A subscription negotiated between subscriber 248 and publisher vian establish, modify, and delete RPCs respectively 249 control plane signaling messages that are part of an existing 250 management association between and publisher. Subscriber and 251 receiver are the same system. 253 NACM: NETCONF Access Control Model 255 NETCONF: Network Configuration Protocol 257 Publisher: A server that sends push updates to a receiver according 258 to the terms of a subscription. In general, the publisher is also 259 the "owner" of the subscription. 261 Push-update stream: A conceptual data stream of a datastore that 262 streams the entire datastore contents continuously and perpetually. 264 Receiver: The target of push updates of a subscription. In case of a 265 dynamic subscription, receiver and subscriber are the same system. 266 However, in the case of a static subscription, the receiver may be a 267 different system than the one that configured the subscription. 269 RPC: Remote Procedure Call 271 SNMP: Simple Network Management Protocol 273 Static subscription: A subscription installed as part of a 274 configuration datastore via a configuration interface. 276 Subscriber: A client that negotiates a subscription with a server 277 ("publisher"). A client that establishes a static subscription is 278 also considered a subscriber, even if it is not necessarily the 279 receiver of a subscription. 281 Subscription: A contract between a client ("subscriber") and a server 282 ("publisher"), stipulating which information the client wishes to 283 receive from the server (and which information the server has to 284 provide to the client) without the need for further solicitation. 286 Subscription filter: A filter that contains evaluation criteria which 287 are evaluated against YANG objects of a subscription. An update is 288 only published if the object meets the specified filter criteria. 290 Subscription policy: A policy that specifies under what circumstances 291 to push an update, e.g. whether updates are to be provided 292 periodically or only whenever changes occur. 294 Update: A data item containing the current value of a data node. 296 Update trigger: A trigger, as specified by a subscription policy, 297 that causes an update to be sent, respectively a data record to be 298 generated. An example of a trigger is a change trigger, invoked when 299 the value of a data node changes or a data node is created or 300 deleted, or a time trigger, invoked after the laps of a periodic time 301 interval. 303 URI: Uniform Resource Identifier 305 YANG: A data definition language for NETCONF 307 YANG-Push: The subscription and push mechanism for YANG datastores 308 that is specified in this document. 310 3. Solution Overview 312 This document specifies a solution for a subscription service, which 313 supports the dynamic as well as static creation of subscriptions to 314 information updates of operational or configuration YANG data which 315 are subsequently pushed from the server to the client. 317 Dynamic subscriptions are initiated by clients who want to receive 318 push updates. Servers respond to requests for the creation of 319 subscriptions positively or negatively. Negative responses include 320 information about why the subscription was not accepted, in order to 321 facilitate converging on an acceptable set of subscription 322 parameters. Similarly, static subscriptions are configured as part 323 of a device's configuration. Once a subscription has been 324 established, datastore push updates are pushed from the server to the 325 receiver until the subscription ends. 327 Accordingly, the solution encompasses several components: 329 o The subscription model for configuration and management of the 330 subscriptions, with a set of associated services. 332 o The ability to provide hints for acceptable subscription 333 parameters, in cases where a subscription desired by a client 334 cannot currently be served. 336 o The stream of push updates. 338 In addition, there are a number of additional considerations, such as 339 the tie-in of the mechanisms with security mechanisms. Each of those 340 aspects will be discussed in the following subsections. 342 3.1. Subscription Model 344 YANG-Push subscriptions are defined using a data model that is itself 345 defined in YANG. This model is based on the subscriptions defined in 346 [RFC5277], which are also reused in Restconf. The model is extended 347 with several parameters, including a subscription type and a 348 subscription ID. 350 The subscription model assumes the presence of a conceptual perpetual 351 datastream "push-update" of continuous datastore updates that can be 352 subscribed to, although other datastreams may be supported as well. 353 A subscription refers to a datastream and specifies filters that are 354 to be applied to, it for example, to provide only those subsets of 355 the information that match a filter criteria. In addition, a 356 subscription specifies a set of subscription parameters that define 357 the trigger when data records should be sent, for example at periodic 358 intervals or whenever underlying data items change. 360 The complete set of subscription parameters for both dynamic and 361 static subscriptions is as follows: 363 o The stream being subscribed to. The subscription model assumes 364 the presence of perpetual and continuous streams of updates. The 365 stream "push-update" is always available and covers the entire set 366 of YANG data in the server, but a system may provide other streams 367 to choose from. 369 o The datastore to target. By default, the datastore will always be 370 "running". However, it is conceivable that implementations want 371 to also support subscriptions to updates to other datastores. 373 o An encoding for the data updates. By default, updates are encoded 374 using XML, but JSON can be requested as an option and other 375 encodings may be supported in the future. 377 o An optional start time for the subscription. If the specified 378 start time is in the past, the subscription goes into effect 379 immediately. The start time also serves as anchor time for 380 periodic subscriptions, from which intervals at which to send 381 updates are calculated (see also below). 383 o An optional stop time for the subscription. Once the stop time is 384 reached, the subscription is automatically terminated. 386 o A subscription policy definition regarding the update trigger when 387 to send new updates. The trigger can be periodic or based on 388 change. 390 * For periodic subscriptions, the trigger is defined by a 391 parameter that defines the interval with which updates are to 392 be pushed. The start time of the subscription serves as anchor 393 time, defining one specific point in time at which an update 394 needs to be sent. Update intervals always fall on the points 395 in time that are a multiple of a period after the start time. 397 * For on-change subscriptions, the trigger occurs whenever a 398 change in the subscribed information is detected. On-change 399 subscriptions have more complex semantics that can be guided by 400 additional parameters. Please refer also to Section 3.3. 402 + One parameter is needed to specify the dampening period, 403 i.e. the interval that must pass before a successive update 404 for the same data node is sent. The first time a change is 405 detected, the update is sent immediately. If a subsequent 406 change is detected, another update is only sent once the 407 dampening period has passed, containing the value of the 408 data node that is then valid. 410 + Another parameter allows to restrict the types of changes 411 for which updates are sent (changes to object values, object 412 creation or deletion events). It is conceivable to augment 413 the data model with additional parameters in the future to 414 specify even more refined policies, such as parameters that 415 specify the magnitude of a change that must occur before an 416 update is triggered. 418 + A third parameter specifies whether or not a complete update 419 with all the subscribed data should be sent at the beginning 420 of a subscription. 422 o Optionally, a filter, or set of filters, describing the subset of 423 data items in the stream's data records that are of interest to 424 the subscriber. The server should only send to the subscriber the 425 data items that match the filter(s), when present. The absence of 426 a filter indicates that all data items from the stream are of 427 interest to the subscriber and all data records must be sent in 428 their entirety to the subscriber. Three types of filters are 429 supported: subtree filters, with the same semantics as defined in 430 [RFC 6241], XPath filters, and RFC 5277 filter, with the same 431 semantics as defined in [RFC 5277]. Additional filter types can 432 be added through augmentations. Filters can be specified "inline" 433 as part of the subscription, or can be configured separately and 434 referenced by a subscription, in order to facilitate reuse of 435 complex filters. 437 In addition, for the configuration of static subscriptions, the 438 following parameters are supported: 440 o One or more receiver IP addresses (and corresponding ports) 441 intended as the destination for push updates for each 442 subscription. In addition the transport protocol for each 443 destination may be defined. 445 o Optional parameters to identify an egress interface or IP address 446 / VRF where a subscription updates should be pushed from the 447 publisher. 449 The subscription data model is specified as part of the YANG data 450 model described later in this specification. Specifically, the 451 subscription parameters are defined in the "subscription-info" and 452 "update-policy" groupings. Receiver information is defined in the 453 "receiver-info" grouping. Information about the source address is 454 defined in the "push-source-info" grouping. It is conceivable that 455 additional subscription parameters might be added in the future. 456 This can be accomplished through augmentation of the subscription 457 data model. 459 3.2. Negotiation of Subscription Policies 461 A subscription rejection can be caused by the inability of the server 462 to provide a stream with the requested semantics. For example, a 463 server may not be able to support "on-change" updates for operational 464 data, or only support them for a limited set of data nodes. 465 Likewise, a server may not be able to support a requested updated 466 frequency, or a requested encoding. 468 YANG-Push supports a simple negotiation between clients and servers 469 for subscription parameters. The negotiation is limited to a single 470 pair of subscription request and response. For negative responses, 471 the server SHOULD include in the returned error what subscription 472 parameters would have been accepted for the request. The returned 473 acceptable parameters constitute suggestions that, when followed, 474 increase the likelihood of success for subsequent requests. However, 475 they are no guarantee that subsequent requests for this client or 476 others will in fact be accepted. 478 In case a subscriber requests an encoding other than XML, and this 479 encoding is not supported by the server, the server simply indicates 480 in the response that the encoding is not supported. 482 3.3. On-Change Considerations 484 On-change subscriptions allow clients to subscribe to updates 485 whenever changes to objects occur. As such, on-change subscriptions 486 are of particular interest for data that changes relatively 487 infrequently, yet that require applications to be notified with 488 minimal delay when changes do occur. 490 On-change subscriptions tend to be more difficult to implement than 491 periodic subscriptions. Specifically, on-change subscriptions may 492 involve a notion of state to see if a change occurred between past 493 and current state, or the ability to tap into changes as they occur 494 in the underlying system. Accordingly, on-change subscriptions may 495 not be supported by all implementations or for every object. 497 When an on-change subscription is requested for a datastream with a 498 given subtree filter, where not all objects support on-change update 499 triggers, the subscription request MUST be rejected. As a result, 500 on-change subscription requests will tend to be directed at very 501 specific, targeted subtrees with only few objects. 503 Any updates for an on-change subscription will include only objects 504 for which a change was detected. To avoid flooding clients with 505 repeated updates for fast-changing objects, or objects with 506 oscillating values, an on-change subscription allows for the 507 definition of a dampening period. Once an update for a given object 508 is sent, no other updates for this particular object are sent until 509 the end of the dampening period. Values sent at the end of the 510 dampening period are the values current when that dampening period 511 expires. In addition, updates include information about objects that 512 were deleted and ones that were newly created. 514 On-change subscriptions can be refined to let users subscribe only to 515 certain types of changes, for example, only to object creations and 516 deletions, but not to modifications of object values. 518 Additional refinements are conceivable. For example, in order to 519 avoid sending updates on objects whose values undergo only a 520 negligible change, additional parameters might be added to an on- 521 change subscription specifying a policy that states how large or 522 "significant" a change has to be before an update is sent. A simple 523 policy is a "delta-policy" that states, for integer-valued data 524 nodes, the minimum difference between the current value and the value 525 that was last reported that triggers an update. Also more 526 sophisticated policies are conceivable, such as policies specified in 527 percentage terms or policies that take into account the rate of 528 change. While not specified as part of this draft, such policies can 529 be accommodated by augmenting the subscription data model 530 accordingly. 532 3.4. Data Encodings 534 Subscribed data is encoded in either XML or JSON format. A server 535 MUST support XML encoding and MAY support JSON encoding. 537 It is conceivable that additional encodings may be supported as 538 options in the future. This can be accomplished by augmenting the 539 subscription data model with additional identity statements used to 540 refer to requested encodings. 542 3.4.1. Periodic Subscriptions 544 In a periodic subscription, the data included as part of an update 545 corresponds to data that could have been simply retrieved using a get 546 operation and is encoded in the same way. XML encoding rules for 547 data nodes are defined in [RFC6020]. JSON encoding rules are defined 548 in [I-D.ietf-netmod-yang-json]. This encoding is valid JSON, but 549 also has special encoding rules to identify module namespaces and 550 provide consistent type processing of YANG data. 552 3.4.2. On-Change Subscriptions 554 In an on-change subscription, updates need to allow to differentiate 555 between data nodes that were newly created since the last update, 556 data nodes that were deleted, and data nodes whose value changed. 558 XML encoding rules correspond to how data would be encoded in input 559 to Netconf edit-config operations as specified in [RFC6241] section 560 7.2, adding "operation" attributes to elements in the data subtree. 561 Specifically, the following values will be utilized: 563 o create: The data identified by the element has been added since 564 the last update. 566 o delete: The data identified by the element has been deleted since 567 the last update. 569 o merge: The data identified by the element has been changed since 570 the last update. 572 o replace: The data identified by the element has been replaced with 573 the update contents since the last update. 575 The remove value will not be utilized. 577 Contrary to edit-config operations, the data is sent from the server 578 to the client, not from the client to the server, and will not be 579 restricted to configuration data. 581 JSON encoding rules are roughly analogous to how data would be 582 encoded in input to a YANG-patch operation, as specified in 583 [I-D.ietf-netconf-yang-patch] section 2.2. However, no edit-ids will 584 be needed. Specifically, changes will be grouped under respective 585 "operation" containers for creations, deletions, and modifications. 587 3.5. Subscription Filters 589 Subscriptions can specify filters for subscribed data. The following 590 filters are supported: 592 o subtree-filter: A subtree filter specifies a subtree that the 593 subscription refers to. When specified, updates will only concern 594 data nodes from this subtree. Syntax and semantics correspond to 595 that specified for [RFC6241] section 6. 597 o xpath-filter: An XPath filter specifies an XPath expression 598 applied to the data in an update, assuming XML-encoded data. 600 o RFC5277 filter: A filter that allows for matching of update 601 notification records per RFC 5277. 603 Only a single filter can be applied to a subscription at a time. 605 It is conceivable for implementations to support other filters. For 606 example, an on-change filter might specify that changes in values 607 should be sent only when the magnitude of the change since previous 608 updates exceeds a certain threshold. It is possible to augment the 609 subscription data model with additional filter types. 611 3.6. Subscription State Model at the Publisher 613 Below is the state machine for the publisher. It is important to 614 note that a subscription doesn't exist at the publisher until it is 615 accepted and made active. The mere request by a subscriber to 616 establish a subscription is insufficient for that asserted 617 subscription to be externally visible via this state machine. 619 .-------. 620 | start | 621 '-------' 622 | 623 establish 624 | 625 | .----------modify-------------.lex 626 v v ' 627 .-----------. .-----------. 628 .--------. | |------>suspend------->| | 629 modify '| active | | suspended | 630 '--------->| |<----resume----<------| | 631 '-----------' '-----------' 632 | | 633 delete delete 634 | | 635 v | 636 .-------. | 637 | end |<-----------------------------' 638 '-------' 640 Figure 1: Subscription states at publisher 642 Of interest in this state machine are the following: 644 o Successful or 645 requests put the subscription into an active state. 647 o Failed requests will leave the subscription 648 in its previous state, with no visible change to any streaming 649 updates. 651 o A request will delete the entire 652 subscription. 654 3.7. Push Data Stream and Transport Mapping 656 Pushing data based on a subscription could be considered analogous to 657 a response to a data retrieval request, e.g. a "get" request. 658 However, contrary to such a request, multiple responses to the same 659 request may get sent over a longer period of time. 661 A more suitable mechanism to consider is therefore that of a 662 notification. There are however some specifics that need to be 663 considered. Contrary to other notifications that are associated with 664 alarms and unexpected event occurrences, push updates are solicited, 665 i.e. tied to a particular subscription which triggered the 666 notification, and arguably only of interest to the subscriber, 667 respectively the intended receiver of the subscription. A 668 subscription therefore needs to be able to distinguish between 669 streams that underlie push updates and streams of other 670 notifications. By the same token, notifications associated with 671 updates and subscriptions to updates need to be distinguished from 672 other notifications, in that they enter a datastream of push updates, 673 not a stream of other event notifications. 675 A push update notification contains several parameters: 677 o A subscription correlator, referencing the name of the 678 subscription on whose behalf the notification is sent. 680 o A data node that contains a representation of the datastore 681 subtree containing the updates. The subtree is filtered per 682 access control rules to contain only data that the subscriber is 683 authorized to see. Also, depending on the subscription type, 684 i.e., specifically for on-change subscriptions, the subtree 685 contains only the data nodes that contain actual changes. (This 686 can be simply a node of type string or, for XML-based encoding, 687 anyxml.) 689 Notifications are sent using elements as defined in 690 [RFC5277]. Alternative transports are conceivable but outside the 691 scope of this specification. 693 The solution specified in this document uses notifications to define 694 datastore updates. The contents of the notification includes a set 695 of explicitly defined data nodes. For this purpose, two new generic 696 notifications are introduced, "push-update" and "push-change-update". 697 Those notifications define how mechanisms that carry YANG 698 notifications (e.g. Netconf notifications and Restconf) can be used 699 to carry data records with updates of datastore contents as specified 700 by a subscription. It is possible also map notifications to other 701 transports and encodings and use the same subscription model; 702 however, the definition of such mappings is outside the scope of this 703 document. 705 Push-update notification defines updates for a periodic subscription, 706 as well as for the initial update of an on-change subscription used 707 to synchronize the receiver at the start of a new subscription. The 708 update record contains a data snippet that contains an instantiated 709 subtree with the subscribed contents. The content of the update 710 record is equivalent to the contents that would be obtained had the 711 same data been explicitly retrieved using e.g. a Netconf "get"- 712 operation, with the same filters applied. 714 The contents of the notification conceptually represents the union of 715 all data nodes in the yang modules supported by the server. However, 716 in a YANG data model, it is not practical to model the precise data 717 contained in the updates as part of the notification. This is 718 because the specific data nodes supported depend on the implementing 719 system and may even vary dynamically. Therefore, to capture this 720 data, a single parameter that can represent any datastore contents is 721 used, not parameters that represent data nodes one at a time. 723 Push-change-update notification defines updates for on-change 724 subscriptions. The update record here contains a data snippet that 725 indicates the changes that data nodes have undergone, i.e. that 726 indicates which data nodes have been created, deleted, or had changes 727 to their values. The format follows the same format that operations 728 that apply changes to a data tree would apply, indicating the 729 creates, deletes, and modifications of data nodes. 731 The following is an example of push notification. It contains an 732 update for subscription 1011, including a subtree with root foo that 733 contains a leaf, bar: 735 737 2015-03-09T19:14:56Z 738 740 1011 741 2015-03-09T19:14:56Z 742 743 744 some_string 745 746 747 748 750 Figure 2: Push example 752 The following is an example of an on-change notification. It 753 contains an update for subscription 89, including a new value for a 754 leaf called beta, which is a child of a top-level container called 755 alpha: 757 759 2015-03-09T19:14:56Z 760 762 89 763 2015-03-09T19:14:56Z 764 765 766 1500 767 768 769 770 772 Figure 3: Push example for on change 774 The equivalent update when requesting json encoding: 776 778 2015-03-09T19:14:56Z 779 781 89 782 2015-03-09T19:14:56Z 783 784 { 785 "ietf-yang-patch:yang-patch": { 786 "patch-id": [ 787 null 788 ], 789 "edit": [ 790 { 791 "edit-id": "edit1", 792 "operation": "merge", 793 "target": "/alpha/beta", 794 "value": { 795 "beta": 1500 796 } 797 } 798 ] 799 } 800 } 801 802 803 805 Figure 4: Push example for on change with JSON 807 When the beta leaf is deleted, the server may send 808 810 2015-03-09T19:14:56Z 811 813 89 814 2015-03-09T19:14:56Z 815 816 817 819 820 821 822 824 Figure 5: 2nd push example for on change update 826 3.8. Subscription management 828 There are two ways in which subscriptions can be managed: RPC-based 829 and configuration based. Any given subscription is either RPC-based 830 or configuration-based. There is no mixing-and-matching of RPC and 831 configuration operations. Specifically, a configured subscription 832 cannot be modified or deleted using RPC. Likewise, a subscription 833 established via RPC cannot be modified or deleted through 834 configuration operations. 836 Note: In order to distinguish subscribing to a stream of YANG-Push 837 updates from subscribing to a regular event stream and avoid 838 confusion with the RPC defined in RFC 5277, the 839 term "establish-subscription" is used instead of "create- 840 subscription". 842 3.8.1. Subscription management by RPC 844 RPC-based subscription allows a subscriber to establish a 845 subscription via an RPC call. The subscriber and the receiver are 846 the same entity, i.e. a subscriber cannot subscribe or in other ways 847 interfere with a subscription on another receiver's behalf. The 848 lifecycle of the subscription is dependent on the lifecyle of the 849 transport session over which the subscription was requested. For 850 example, when a Netconf session over which a subscription was 851 established is torn down, the subscription is automatically 852 terminated (and needs to be re-initiated when a new session is 853 established). Alternatively, a subscriber can also decide to delete 854 a subscription via another RPC. 856 When an establish-subscription request is successful, the 857 subscription identifier of the freshly established subscription is 858 returned. 860 A subscription can be rejected for multiple reasons, including the 861 lack of authorization to establish a subscription, the lack of read 862 authorization on the requested data node, or the inability of the 863 server to provide a stream with the requested semantics. In such 864 cases, no subscription is established. Instead, the subscription- 865 result with the failure reason is returned as part of the RPC 866 response. In addition, a set of alternative subscription parameters 867 MAY be returned that would likely have resulted in acceptance of the 868 subscription request, which the subscriber may try for a future 869 subscription attempt. 871 It should be noted that a rejected subscription does not result in 872 the generation of an rpc-reply with an rpc-error element, as neither 873 the specification of YANG-push specific errors nor the specification 874 of additional data parameters to be returned in an error case are 875 supported as part of a YANG data model. 877 For instance, for the following request: 879 881 883 push-update 884 887 500 888 encode-xml 889 890 892 Figure 6: Establish-Subscription example 894 the server might return: 896 898 900 error-insufficient-resources 901 902 2000 903 905 Figure 7: Error response example 907 A subscriber that establishes a subscription using RPC can modify or 908 delete the subscription using other RPCs. When the session between 909 subscriber and publisher is terminated, the subscription is 910 implicitly deleted. 912 3.8.2. Subscription management by configuration 914 Configuration-based subscription allows a subscription to be 915 established as part of a server's configuration. This allows to 916 persist subscriptions. Persisted subscriptions allow for a number of 917 additional options than RPC-based subscriptions. As part of a 918 configured subscription, a receiver needs to be specified. It is 919 thus possible to have a different system acting as subscriber (the 920 client creating the subscription) and as receiver (the client 921 receiving the updates). In addition, a configured subscription 922 allows to specify which transport protocol should be used, as well as 923 the sender source (for example, a particular interface or an address 924 of a specific VRF) from which updates are to be pushed. 926 Configuration-based subscriptions cannot be modified or deleted using 927 RPCs. Instead, configured subscriptions are deleted as part of 928 regular configuration operations. Servers SHOULD reject attempts to 929 modify configurations of active subscriptions. This way, race 930 conditions in which a receiver may not be aware of changed 931 subscription policies are avoided. 933 3.9. Other considerations 935 3.9.1. Authorization 937 A receiver of subscription data may only be sent updates for which 938 they have proper authorization. Data that is being pushed therefore 939 needs to be subjected to a filter that applies all corresponding 940 rules applicable at the time of a specific pushed update, removing 941 any non-authorized data as applicable. 943 The authorization model for data in YANG datastores is described in 944 the Netconf Access Control Model [RFC6536]. However, some 945 clarifications to that RFC are needed so that the desired access 946 control behavior is applied to pushed updates. 948 One of these clarifications is that a subscription may only be 949 established if the Receiver has read access to the target data node. 951 +-------------+ +-------------+ 952 subscription | protocol | | target | 953 request --> | operation | -------------> | data node | 954 | allowed? | datastore | access | 955 +-------------+ or state | allowed? | 956 data access +-------------+ 958 Figure 8: Access control for subscription 960 Likewise if a receiver no longer has read access permission to a 961 target data node, the subscription must be abnormally terminated 962 (with loss of access permission as the reason provided). 964 Another clarification to [RFC6536] is that each of the individual 965 nodes in a pushed update must also go through access control 966 filtering. This includes new nodes added since the last push update, 967 as well as existing nodes. For each of these read access must be 968 verified. The methods of doing this efficiently are left to 969 implementation. 971 +-------------+ +-------------------+ 972 subscription | data node | yes | | 973 update --> | access | ---> | add data node | 974 | allowed? | | to update message | 975 +-------------+ +-------------------+ 977 Figure 9: Access control for push updates 979 If there are read access control changes applied under the target 980 node, no notifications indicating the fact that this has occurred 981 need to be provided. 983 3.9.2. Additional subscription primitives 985 Other possible operations include the ability for a Subscriber to 986 request the suspension/resumption of a Subscription with a Publisher. 987 However, subscriber driven suspension is not viewed as essential at 988 this time, as a simpler alternative is to remove a subscription and 989 reestablish it when needed. 991 It should be noted that this does not affect the ability of the 992 Publisher to suspend a subscription. This can occur in cases the 993 server is not able to serve the subscription for a certain period of 994 time, and indicated by a corresponding notification. 996 3.9.3. Robustness and reliability considerations 998 Particularly in the case of on-change push updates, it is important 999 that push updates do not get lost. 1001 YANG-Push uses a secure and reliable transport. Notifications are 1002 not getting reordered, and in addition contain a time stamp. For 1003 those reasons, for the transport of push-updates, we believe that 1004 additional reliability mechanisms at the application level, such as 1005 sequence numbers for push updates, are not required. 1007 At the same time, it is conceivable that under certain circumstances, 1008 a push server is not able to generate the update notifications that 1009 it had committed to when accepting a subcription. In those 1010 circumstances, the server needs to inform the receiver of the 1011 situation. For this purpose, notifications are defined that a push 1012 server can use to inform subscribers/ receivers when a subscription 1013 is (temporarily) suspended, when a suspended subscription is resumed, 1014 and when a a subscription is terminated. This way, receivers will be 1015 able to rely on a subscription, knowing that they will be informed of 1016 any situations in which updates might be missed. 1018 3.9.4. Update size and fragmentation considerations 1020 Depending on the subscription, the volume of updates can become quite 1021 large. There is no inherent limitation to the amount of data that 1022 can be included in a notification. That said, it may not always be 1023 practical to send the entire update in a single chunk. 1024 Implementations MAY therefore choose, at their discretion, to "chunk" 1025 updates and break them out into several update notifications. 1027 3.9.5. Push data streams 1029 There are several conceptual data streams introduced in this 1030 specification: 1032 o yang-push includes the entirety of YANG data, including both 1033 configuration and operational data. 1035 o operational-push includes all operational (read-only) YANG data 1037 o config-push includes all YANG configuration data. 1039 It is conceivable to introduce other data streams with more limited 1040 scope, for example: 1042 o operdata-nocounts-push, a datastream containing all operational 1043 (read-only) data with the exception of counters 1045 o other custom datastreams 1047 Those data streams make particular sense for use cases involving 1048 service assurance (not relying on operational data), and for use 1049 cases requiring on-change update triggers which make no sense to 1050 support in conjunction with fast-changing counters. While it is 1051 possible to specify subtree filters on yang-push to the same effect, 1052 having those data streams greatly simplifies articulating 1053 subscriptions in such scenarios. 1055 3.9.6. Implementation considerations 1057 Implementation specifics are outside the scope of this specification. 1058 That said,it should be noted that monitoring of operational state 1059 changes inside a system can be associated with significant 1060 implementation challenges. 1062 Even periodic retrieval of operational state alone, to be able to 1063 push it, can consume considerable system resources. Configuration 1064 data may in many cases be persisted in an actual database or a 1065 configuration file, where retrieval of the database content or the 1066 file itself is reasonably straightforward and computationally 1067 inexpensive. However, retrieval of operational data may, depending 1068 on the implementation, require invocation of APIs, possibly on an 1069 object-by-object basis, possibly involving additional internal 1070 interrupts, etc. 1072 For those reasons, if is important for an implementation to 1073 understand what subscriptions it can or cannot support. It is far 1074 preferrable to decline a subscription request, than to accept it only 1075 to result in subsequent failure later. 1077 Whether or not a subscription can be supported will in general be 1078 determined by a combination of several factors, including the 1079 subscription policy (on-change or periodic, with on-change in general 1080 being the more challenging of the two), the period in which to report 1081 changes (1 second periods will consume more resources than 1 hour 1082 periods), the amount of data in the subtree that is being subscribed 1083 to, and the number and combination of other subscriptions that are 1084 concurrently being serviced. 1086 When providing access control to every node in a pushed update, it is 1087 possible to make and update efficient access control filters for an 1088 update. These filters can be set upon subscription and applied 1089 against a stream of updates. These filters need only be updated when 1090 (a) there is a new node added/removed from the subscribed tree with 1091 different permissions than its parent, or (b) read access permissions 1092 have been changed on nodes under the target node for the subscriber. 1094 3.9.7. Alignment with RFC 5277bis 1096 A new draft has been chartered by the Netconf Working Group to 1097 replace the current Netconf Event Model defined in RFC 5277. Future 1098 revisions of this document will leverage RFC 5277bis as applicable. 1099 It is anticipated that portions of the data model and subscription 1100 management that are now defined in this this document and that are 1101 not applicable only to YANG-Push, but to more general event 1102 subscriptions, will move to RFC 5277bis. 1104 4. A YANG data model for management of datastore push subscriptions 1106 4.1. Overview 1108 The YANG data model for datastore push subscriptions is depicted in 1109 the following figure. 1111 module: ietf-yang-push 1112 +--ro update-streams 1113 | +--ro update-stream* update-stream 1114 +--rw filters 1115 | +--rw filter* [filter-id] 1116 | +--rw filter-id filter-id 1117 | +--rw (filter-type)? 1118 | +--:(subtree) 1119 | | +--rw subtree-filter 1120 | +--:(xpath) 1121 | | +--rw xpath-filter? yang:xpath1.0 1122 | +--:(rfc5277) 1123 | +--rw filter 1124 +--rw subscription-config {configured-subscriptions}? 1125 | +--rw yang-push-subscription* [subscription-id] 1126 | +--rw subscription-id subscription-id 1127 | +--rw stream? update-stream 1128 | +--rw encoding? encoding 1129 | +--rw subscription-start-time? yang:date-and-time 1130 | +--rw subscription-stop-time? yang:date-and-time 1131 | +--rw (filterspec)? 1132 | | +--:(inline) 1133 | | | +--rw (filter-type)? 1134 | | | +--:(subtree) 1135 | | | | +--rw subtree-filter 1136 | | | +--:(xpath) 1137 | | | | +--rw xpath-filter? yang:xpath1.0 1138 | | | +--:(rfc5277) 1139 | | | +--rw filter 1140 | | +--:(by-reference) 1141 | | +--rw filter-ref? filter-ref 1142 | +--rw (update-trigger)? 1143 | | +--:(periodic) 1144 | | | +--rw period yang:timeticks 1145 | | +--:(on-change) {on-change}? 1146 | | +--rw no-synch-on-start? empty 1147 | | +--rw dampening-period yang:timeticks 1148 | | +--rw excluded-change* change-type 1149 | +--rw receiver* [address] 1150 | | +--rw address inet:host 1151 | | +--rw port? inet:port-number 1152 | | +--rw protocol? transport-protocol 1153 | +--rw (push-source)? 1154 | | +--:(interface-originated) 1155 | | | +--rw source-interface? if:interface-ref 1156 | | +--:(address-originated) 1157 | | +--rw source-vrf? uint32 1158 | | +--rw source-address inet:ip-address-no-zone 1159 | +--rw dscp? inet:dscp {configured-subscriptions}? 1160 | +--rw subscription-priority? uint8 1161 | +--rw subscription-dependency? string 1162 +--ro subscriptions 1163 +--ro yang-push-subscription* [subscription-id] 1164 +--ro subscription-id subscription-id 1165 +--ro configured-subscription?empty {configured-subscriptions}? 1166 +--ro subscription-status? identityref 1167 +--ro stream? update-stream 1168 +--ro encoding? encoding 1169 +--ro subscription-start-time? yang:date-and-time 1170 +--ro subscription-stop-time? yang:date-and-time 1171 +--ro (filterspec)? 1172 | +--:(inline) 1173 | | +--ro (filter-type)? 1174 | | +--:(subtree) 1175 | | | +--ro subtree-filter 1176 | | +--:(xpath) 1177 | | | +--ro xpath-filter? yang:xpath1.0 1178 | | +--:(rfc5277) 1179 | | +--ro filter 1180 | +--:(by-reference) 1181 | +--ro filter-ref? filter-ref 1182 +--ro (update-trigger)? 1183 | +--:(periodic) 1184 | | +--ro period yang:timeticks 1185 | +--:(on-change) {on-change}? 1186 | +--ro no-synch-on-start? empty 1187 | +--ro dampening-period yang:timeticks 1188 | +--ro excluded-change* change-type 1189 +--ro receiver* [address] 1190 | +--ro address inet:host 1191 | +--ro port? inet:port-number 1192 | +--ro protocol? transport-protocol 1193 +--ro (push-source)? 1194 | +--:(interface-originated) 1195 | | +--ro source-interface? if:interface-ref 1196 | +--:(address-originated) 1197 | +--ro source-vrf? uint32 1198 | +--ro source-address inet:ip-address-no-zone 1199 +--ro dscp? inet:dscp {configured-subscriptions}? 1200 +--ro subscription-priority? uint8 1201 +--ro subscription-dependency? string 1202 rpcs: 1203 +---x establish-subscription 1204 | +---w input 1205 | | +---w stream? update-stream 1206 | | +---w encoding? encoding 1207 | | +---w subscription-start-time? yang:date-and-time 1208 | | +---w subscription-stop-time? yang:date-and-time 1209 | | +---w (filterspec)? 1210 | | | +--:(inline) 1211 | | | | +---w (filter-type)? 1212 | | | | +--:(subtree) 1213 | | | | | +---w subtree-filter 1214 | | | | +--:(xpath) 1215 | | | | | +---w xpath-filter? yang:xpath1.0 1216 | | | | +--:(rfc5277) 1217 | | | | +---w filter 1218 | | | +--:(by-reference) 1219 | | | +---w filter-ref? filter-ref 1220 | | +---w (update-trigger)? 1221 | | | +--:(periodic) 1222 | | | | +---w period yang:timeticks 1223 | | | +--:(on-change) {on-change}? 1224 | | | +---w no-synch-on-start? empty 1225 | | | +---w dampening-period yang:timeticks 1226 | | | +---w excluded-change* change-type 1227 | | +---w dscp? inet:dscp {configured-subscriptions}? 1228 | | +---w subscription-priority? uint8 1229 | | +---w subscription-dependency? string 1230 | +--ro output 1231 | +--ro subscription-result subscription-result 1232 | +--ro (result)? 1233 | +--:(success) 1234 | | +--ro subscription-id subscription-id 1235 | +--:(no-success) 1236 | +--ro stream? update-stream 1237 | +--ro encoding? encoding 1238 | +--ro subscription-start-time? yang:date-and-time 1239 | +--ro subscription-stop-time? yang:date-and-time 1240 | +--ro (filterspec)? 1241 | | +--:(inline) 1242 | | | +--ro (filter-type)? 1243 | | | +--:(subtree) 1244 | | | | +--ro subtree-filter 1245 | | | +--:(xpath) 1246 | | | | +--ro xpath-filter? yang:xpath1.0 1247 | | | +--:(rfc5277) 1248 | | | +--ro filter 1249 | | +--:(by-reference) 1250 | | +--ro filter-ref? filter-ref 1251 | +--ro (update-trigger)? 1252 | | +--:(periodic) 1253 | | | +--ro period yang:timeticks 1254 | | +--:(on-change) {on-change}? 1255 | | +--ro no-synch-on-start? empty 1256 | | +--ro dampening-period yang:timeticks 1257 | | +--ro excluded-change* change-type 1258 | +--ro dscp? inet:dscp {configured-subscriptions}? 1259 | +--ro subscription-priority? uint8 1260 | +--ro subscription-dependency? string 1261 +---x modify-subscription 1262 | +---w input 1263 | | +---w subscription-id? subscription-id 1264 | | +---w stream? update-stream 1265 | | +---w encoding? encoding 1266 | | +---w subscription-start-time? yang:date-and-time 1267 | | +---w subscription-stop-time? yang:date-and-time 1268 | | +---w (filterspec)? 1269 | | | +--:(inline) 1270 | | | | +---w (filter-type)? 1271 | | | | +--:(subtree) 1272 | | | | | +---w subtree-filter 1273 | | | | +--:(xpath) 1274 | | | | | +---w xpath-filter? yang:xpath1.0 1275 | | | | +--:(rfc5277) 1276 | | | | +---w filter 1277 | | | +--:(by-reference) 1278 | | | +---w filter-ref? filter-ref 1279 | | +---w (update-trigger)? 1280 | | | +--:(periodic) 1281 | | | | +---w period yang:timeticks 1282 | | | +--:(on-change) {on-change}? 1283 | | | +---w no-synch-on-start? empty 1284 | | | +---w dampening-period yang:timeticks 1285 | | | +---w excluded-change* change-type 1286 | | +---w dscp? inet:dscp {configured-subscriptions}? 1287 | | +---w subscription-priority? uint8 1288 | | +---w subscription-dependency? string 1289 | +--ro output 1290 | +--ro subscription-result subscription-result 1291 | +--ro stream? update-stream 1292 | +--ro encoding? encoding 1293 | +--ro subscription-start-time? yang:date-and-time 1294 | +--ro subscription-stop-time? yang:date-and-time 1295 | +--ro (filterspec)? 1296 | | +--:(inline) 1297 | | | +--ro (filter-type)? 1298 | | | +--:(subtree) 1299 | | | | +--ro subtree-filter 1300 | | | +--:(xpath) 1301 | | | | +--ro xpath-filter? yang:xpath1.0 1302 | | | +--:(rfc5277) 1303 | | | +--ro filter 1304 | | +--:(by-reference) 1305 | | +--ro filter-ref? filter-ref 1306 | +--ro (update-trigger)? 1307 | | +--:(periodic) 1308 | | | +--ro period yang:timeticks 1309 | | +--:(on-change) {on-change}? 1310 | | +--ro no-synch-on-start? empty 1311 | | +--ro dampening-period yang:timeticks 1312 | | +--ro excluded-change* change-type 1313 | +--ro dscp? inet:dscp {configured-subscriptions}? 1314 | +--ro subscription-priority? uint8 1315 | +--ro subscription-dependency? string 1316 +---x delete-subscription 1317 +---w input 1318 +---w subscription-id? subscription-id 1319 notifications: 1320 +---n push-update 1321 | +--ro subscription-id subscription-id 1322 | +--ro time-of-update? yang:date-and-time 1323 | +--ro (encoding)? 1324 | +--:(encode-xml) 1325 | | +--ro datastore-contents-xml? datastore-contents-xml 1326 | +--:(encode-json) {json}? 1327 | +--ro datastore-contents-json? datastore-contents-json 1328 +---n push-change-update {on-change}? 1329 | +--ro subscription-id subscription-id 1330 | +--ro time-of-update? yang:date-and-time 1331 | +--ro (encoding)? 1332 | +--:(encode-xml) 1333 | | +--ro datastore-changes-xml? datastore-changes-xml 1334 | +--:(encode-json) {json}? 1335 | +--ro datastore-changes-yang? datastore-changes-json 1336 +---n subscription-started 1337 | +--ro subscription-id subscription-id 1338 | +--ro stream? update-stream 1339 | +--ro encoding? encoding 1340 | +--ro subscription-start-time? yang:date-and-time 1341 | +--ro subscription-stop-time? yang:date-and-time 1342 | +--ro (filterspec)? 1343 | | +--:(inline) 1344 | | | +--ro (filter-type)? 1345 | | | +--:(subtree) 1346 | | | | +--ro subtree-filter 1347 | | | +--:(xpath) 1348 | | | | +--ro xpath-filter? yang:xpath1.0 1349 | | | +--:(rfc5277) 1350 | | | +--ro filter 1351 | | +--:(by-reference) 1352 | | +--ro filter-ref? filter-ref 1353 | +--ro (update-trigger)? 1354 | | +--:(periodic) 1355 | | | +--ro period yang:timeticks 1356 | | +--:(on-change) {on-change}? 1357 | | +--ro no-synch-on-start? empty 1358 | | +--ro dampening-period yang:timeticks 1359 | | +--ro excluded-change* change-type 1360 | +--ro dscp? inet:dscp {configured-subscriptions}? 1361 | +--ro subscription-priority? uint8 1362 | +--ro subscription-dependency? string 1363 +---n subscription-suspended 1364 | +--ro subscription-id subscription-id 1365 | +--ro reason? subscription-susp-reason 1366 +---n subscription-resumed 1367 | +--ro subscription-id subscription-id 1368 +---n subscription-modified 1369 | +--ro subscription-id subscription-id 1370 | +--ro stream? update-stream 1371 | +--ro encoding? encoding 1372 | +--ro subscription-start-time? yang:date-and-time 1373 | +--ro subscription-stop-time? yang:date-and-time 1374 | +--ro (filterspec)? 1375 | | +--:(inline) 1376 | | | +--ro (filter-type)? 1377 | | | +--:(subtree) 1378 | | | | +--ro subtree-filter 1379 | | | +--:(xpath) 1380 | | | | +--ro xpath-filter? yang:xpath1.0 1381 | | | +--:(rfc5277) 1382 | | | +--ro filter 1383 | | +--:(by-reference) 1384 | | +--ro filter-ref? filter-ref 1385 | +--ro (update-trigger)? 1386 | | +--:(periodic) 1387 | | | +--ro period yang:timeticks 1388 | | +--:(on-change) {on-change}? 1389 | | +--ro no-synch-on-start? empty 1390 | | +--ro dampening-period yang:timeticks 1391 | | +--ro excluded-change* change-type 1392 | +--ro dscp? inet:dscp {configured-subscriptions}? 1393 | +--ro subscription-priority? uint8 1394 | +--ro subscription-dependency? string 1395 +---n subscription-terminated 1396 +--ro subscription-id subscription-id 1397 +--ro reason? subscription-term-reason 1399 Figure 10: Model structure 1401 The components of the model are described in the following 1402 subsections. 1404 4.2. Update streams 1406 Container "update-streams" is used to indicate which data streams are 1407 provided by the system and can be subscribed to. For this purpose, 1408 it contains a leaf list of data nodes identifying the supported 1409 streams. 1411 4.3. Filters 1413 Container "filters" contains a list of configurable data filters, 1414 each specified in its own list element. This allows users to 1415 configure filters separately from an actual subscription, which can 1416 then be referenced from a subscription. This facilitates the reuse 1417 of filter definitions, which can be important in case of complex 1418 filter conditions. 1420 One of three types of filters can be specified as part of a filter 1421 list element. Subtree filters follow syntax and semantics of RFC 1422 6241 and allow to specify which subtree(s) to subscribe to. In 1423 addition, XPath filters can be specified for more complex filter 1424 conditions. Finally, filters can be specified using syntax and 1425 semantics of RFC5277. 1427 It is conceivable to introduce other types of filters; in that case, 1428 the data model needs to be augmented accordingly. 1430 4.4. Subscription configuration 1432 As an optional feature, configured-subscriptions, allows for the 1433 static configuration of subscriptions, i.e. for subscriptions that 1434 are established via configuration as opposed to RPC. Subscriptions 1435 configurations are represented by list subscription-config. Each 1436 subscription is represented through its own list element and includes 1437 the following components: 1439 o "subscription-id" is an identifier used to refer to the 1440 subscription. 1442 o "stream" refers to the stream being subscribed to. The 1443 subscription model assumes the presence of perpetual and 1444 continuous streams of updates. Various streams are defined: 1445 "push-update" covers the entire set of YANG data in the server. 1446 "operational-push" covers all operational data, while "config- 1447 push" covers all configuration data. Other streams could be 1448 introduced in augmentations to the model by introducing additional 1449 identities. 1451 o "encoding" refers to the encoding requested for the data updates. 1452 By default, updates are encoded using XML. However, JSON can be 1453 requested as an option if the json-enconding feature is supported. 1454 Other encodings may be supported in the future. 1456 o "subscription-start-time" specifies when the subscription is 1457 supposed to start. The start time also serves as anchor time for 1458 periodic subscriptions (see below). 1460 o "subscription-stop-time" specifies a stop time for the 1461 subscription. Once the stop time is reached, the subscription is 1462 automatically terminated. However, even when terminated, the 1463 subscription entry remains part of the configuration unless 1464 explicity deleted from the configuration. It is possible to 1465 effectively "resume" a stopped subscription by reconfiguring the 1466 stop time. 1468 o Filters for a subscription can be specified using a choice, 1469 allowing to either reference a filter that has been separately 1470 configured or entering its definition inline. 1472 o A choice of subscription policies allows to define when to send 1473 new updates - periodic or on change. 1475 * For periodic subscriptions, the trigger is defined by a 1476 "period", a parameter that defines the interval with which 1477 updates are to be pushed. The start time of the subscription 1478 serves as anchor time, defining one specific point in time at 1479 which an update needs to be sent. Update intervals always fall 1480 on the points in time that are a multiple of a period after the 1481 start time. 1483 * For on-change subscriptions, the trigger occurs whenever a 1484 change in the subscribed information is detected. On-change 1485 subscriptions have more complex semantics that is guided by 1486 additional parameters. "dampening-period" specifies the 1487 interval that must pass before a successive update for the same 1488 data node is sent. The first time a change is detected, the 1489 update is sent immediately. If a subsequent change is 1490 detected, another update is only sent once the dampening period 1491 has passed, containing the value of the data node that is then 1492 valid. "excluded-change" allows to restrict the types of 1493 changes for which updates are sent (changes to object values, 1494 object creation or deletion events). "no-synch-on-start" is a 1495 flag that allows to specify whether or not a complete update 1496 with all the subscribed data should be sent at the beginning of 1497 a subscription; if the flag is omitted, a complete update is 1498 sent to facilitate synchronization. It is conceivable to 1499 augment the data model with additional parameters in the future 1500 to specify even more refined policies, such as parameters that 1501 specify the magnitude of a change that must occur before an 1502 update is triggered. 1504 o This is followed with a list of receivers for the subscription, 1505 indicating for each receiver the transport that should be used for 1506 push updates (if options other than Netconf are supported). It 1507 should be noted that the receiver does not have to be the same 1508 system that configures the subscription. 1510 o Finally, "push-source" can be used to specify the source of push 1511 updates, either a specific interface or server address. 1513 A subscription established through configuration cannot be deleted 1514 using an RPC. Likewise, subscriptions established through RPC cannot 1515 be deleted through configuration. 1517 The deletion of a subscription, whether through RPC or configuration, 1518 results in immediate termination of the subsciption. 1520 4.5. Subscription monitoring 1522 Subscriptions can be subjected to management themselves. For 1523 example, it is possible that a server may no longer be able to serve 1524 a subscription that it had previously accepted. Perhaps it has run 1525 out of resources, or internal errors may have occurred. When this is 1526 the case, a server needs to be able to temporarily suspend the 1527 subscription, or even to terminate it. More generally, the server 1528 should provide a means by which the status of subscriptions can be 1529 monitored. 1531 Container "subscriptions" contains the state of all subscriptions 1532 that are currently active. This includes subscriptions that were 1533 established (and have not yet been deleted) using RPCs, as well as 1534 subscriptions that have been configured as part of configuration. 1536 Each subscription is represented as a list element "datastore-push- 1537 subscription". The associated information includes an identifier for 1538 the subscription, a subscription status, as well as the various 1539 subscription parameters that are in effect. The subscription status 1540 indicates whether the subscription is currently active and healthy, 1541 or if it is degraded in some form. Leaf "configured-subscription" 1542 indicates whether the subscription came into being via configuration 1543 or via RPC. 1545 Subscriptions that were established by RPC are removed from the list 1546 once they expire (reaching stop-time )or when they are terminated. 1547 Subscriptions that were established by configuration need to be 1548 deleted from the configuration by a configuration editing operation. 1550 4.6. Notifications 1552 A server needs to indicate any changes in status of a subscription to 1553 the receiver through a notification. Specifically, subscribers need 1554 to be informed of the following: 1556 o A subscription has been temporarily suspended (including the 1557 reason) 1559 o A subscription (that had been suspended earlier) is once again 1560 operational 1562 o A subscription has been terminated (including the reason) 1563 o A subscription has been modified (including the current set of 1564 subscription parameters in effect) 1566 Finally, a server might provide additional information about 1567 subscriptions, such as statistics about the number of data updates 1568 that were sent. However, such information is currently outside the 1569 scope of this specification. 1571 4.7. RPCs 1573 YANG-Push subscriptions are established, modified, and deleted using 1574 three RPCs. 1576 4.7.1. Establish-subscription RPC 1578 The subscriber sends an establish-subscription RPC with the 1579 parameters in section 3.1. For instance 1581 1583 1585 push-update 1586 1589 500 1590 encode-xml 1591 1592 1594 Figure 11: Establish-subscription RPC 1596 The server must respond explicitly positively (i.e., subscription 1597 accepted) or negatively (i.e., subscription rejected) to the request. 1598 Positive responses include the subscription-id of the accepted 1599 subscription. In that case a server may respond: 1601 1603 1605 ok 1606 1607 1609 52 1610 1611 1613 Figure 12: Establish-subscription positive RPC response 1615 A subscription can be rejected for multiple reasons, including the 1616 lack of authorization to establish a subscription, the lack of read 1617 authorization on the requested data node, or the inability of the 1618 server to provide a stream with the requested semantics. . 1620 When the requester is not authorized to read the requested data node, 1621 the returned indicates an authorization error and the 1622 requested node. For instance, if the above request was unauthorized 1623 to read node "ex:foo" the server may return: 1625 1627 1629 error-data-not-authorized 1630 1631 1633 Figure 13: Establish-subscription access denied response 1635 If a request is rejected because the server is not able to serve it, 1636 the server SHOULD include in the returned error what subscription 1637 parameters would have been accepted for the request. However, they 1638 are no guarantee that subsequent requests for this client or others 1639 will in fact be accepted. 1641 For example, for the following request: 1643 1645 1647 push-update 1648 1651 10 1652 encode-xml 1653 1654 1656 Figure 14: Establish-subscription request example 2 1658 A server that cannot serve on-change updates but periodic updates 1659 might return the following: 1661 1663 1665 error-no-such-option 1666 1667 100 1668 1670 Figure 15: Establish-subscription error response example 2 1672 4.7.2. Modify-subscription RPC 1674 The subscriber may send a modify-subscription PRC for a subscription 1675 previously established using RPC The subscriber may change any 1676 subscription parameters by including the new values in the modify- 1677 subscription RPC. Parameters not included in the rpc should remain 1678 unmodified. For illustration purposes we include an exchange example 1679 where a subscriber modifies the period of the subscription. 1681 1683 1685 push-update 1686 1687 1011 1688 1689 1692 250 1693 encode-xml 1694 1695 1697 Figure 16: Modify subscription request 1699 The server must respond explicitly positively (i.e., subscription 1700 accepted) or negatively (i.e., subscription rejected) to the request. 1701 Positive responses include the subscription-id of the accepted 1702 subscription. In that case a server may respond: 1704 1706 1708 ok 1709 1710 1712 1011 1713 1714 1716 Figure 17: Modify subscription response 1718 If the subscription modification is rejected, the server must send a 1719 response like it does for an establish-subscription and maintain the 1720 subscription as it was before the modification request. A 1721 subscription may be modified multiple times. 1723 A configured subscription cannot be modified using modify- 1724 subscription RPC. Instead, the configuration needs to be edited as 1725 needed. 1727 4.7.3. Delete-subscription RPC 1729 To stop receiving updates from a subscription and effectively delete 1730 a subscription that had previously been established using an 1731 establish-subscription RPC, a subscriber can send a delete- 1732 subscription RPC, which takes as only input the subscription-id. For 1733 example 1735 1737 1739 1740 1011 1741 1742 1743 1745 1747 1748 1750 Figure 18: Delete subscription 1752 Configured subscriptions cannot be deleted via RPC, but have to be 1753 removed from the configuration. 1755 5. YANG module 1757 file "ietf-yang-push@2016-03-21.yang" 1758 module ietf-yang-push { 1759 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-push"; 1760 prefix yp; 1762 import ietf-inet-types { 1763 prefix inet; 1764 } 1765 import ietf-yang-types { 1766 prefix yang; 1767 } 1768 import ietf-interfaces { 1769 prefix if; 1770 } 1772 organization "IETF"; 1773 contact 1774 "WG Web: 1775 WG List: 1777 WG Chair: Mahesh Jethanandani 1778 1780 WG Chair: Mehmet Ersue 1781 1783 Editor: Alexander Clemm 1784 1786 Editor: Eric Voit 1787 1789 Editor: Alberto Gonzalez Prieto 1790 1792 Editor: Ambika Prasad Tripathy 1793 1795 Editor: Einar Nilsen-Nygaard 1796 "; 1798 description 1799 "This module contains conceptual YANG specifications 1800 for YANG push."; 1802 revision 2016-03-21 { 1803 description 1804 "Changes to grouping structure, RPC definitions, filter 1805 definitions, origin interface and receiver definitions."; 1806 reference "YANG Datastore Push, draft-ietf-netconf-yang-push-02"; 1807 } 1809 feature on-change { 1810 description 1811 "This feature indicates that on-change updates are 1812 supported."; 1813 } 1815 feature json { 1816 description 1817 "This feature indicates that JSON encoding of push updates 1818 is supported."; 1819 } 1821 feature configured-subscriptions { 1822 description 1823 "This feature indicates that management plane configuration 1824 of subscription is supported."; 1825 } 1827 identity subscription-result { 1828 description 1829 "Base identity for RPC responses to requests surrounding 1830 management (e.g. creation, modification) of 1831 subscriptions."; 1832 } 1834 identity ok { 1835 base subscription-result; 1836 description 1837 "OK - RPC was successful and was performed as requested."; 1838 } 1840 identity error { 1841 base subscription-result; 1842 description 1843 "RPC was not successful. 1844 Base identity for error return codes."; 1845 } 1847 identity error-no-such-subscription { 1848 base error; 1849 description 1850 "A subscription with the requested subscription ID 1851 does not exist."; 1852 } 1854 identity error-no-such-option { 1855 base error; 1856 description 1857 "A requested parameter setting is not supported."; 1858 } 1860 identity error-insufficient-resources { 1861 base error; 1862 description 1863 "The server has insufficient resources to support the 1864 subscription as requested."; 1865 } 1867 identity error-data-not-authorized { 1868 base error; 1869 description 1870 "No read authorization for a requested data node."; 1871 } 1873 identity error-configured-subscription { 1874 base error; 1875 description 1876 "Cannot apply RPC to a configured subscription, i.e. 1877 to a subscription that was not established via RPC."; 1878 } 1880 identity error-other { 1881 base error; 1882 description 1883 "An unspecified error has occurred (catch all)."; 1884 } 1886 identity subscription-stream-status { 1887 description 1888 "Base identity for the status of subscriptions and 1889 datastreams."; 1890 } 1892 identity active { 1893 base subscription-stream-status; 1894 description 1895 "Status is active and healthy."; 1896 } 1898 identity inactive { 1899 base subscription-stream-status; 1900 description 1901 "Status is inactive, for example outside the 1902 interval between start time and stop time."; 1903 } 1905 identity suspended { 1906 base subscription-stream-status; 1907 description 1908 "The status is suspended, meaning that the push server 1909 is currently unable to provide the negotiated updates 1910 for the subscription."; 1911 } 1913 identity subscription-errors { 1914 description 1915 "Base identity for subscription error status. 1916 This identity is not to be confused with error return 1917 codes for RPCs"; 1919 } 1921 identity internal-error { 1922 base subscription-errors; 1923 description 1924 "Subscription failures caused by server internal error."; 1925 } 1927 identity no-resources { 1928 base subscription-errors; 1929 description 1930 "Lack of resources, e.g. CPU, memory, bandwidth"; 1931 } 1933 identity subscription-deleted { 1934 base subscription-errors; 1935 description 1936 "The subscription was terminated because the subscription 1937 was deleted."; 1938 } 1940 identity other { 1941 base subscription-errors; 1942 description 1943 "Fallback reason - any other reason"; 1944 } 1946 identity event-stream { 1947 description 1948 "Base identity to represent a generic stream of event 1949 notifications."; 1950 } 1952 identity update-stream { 1953 base event-stream; 1954 description 1955 "Base identity to represent a conceptual system-provided 1956 datastream of datastore updates with predefined semantics."; 1957 } 1959 identity yang-push { 1960 base update-stream; 1961 description 1962 "A conceptual datastream consisting of all datastore 1963 updates, including operational and configuration data."; 1964 } 1966 identity operational-push { 1967 base update-stream; 1968 description 1969 "A conceptual datastream consisting of updates of all 1970 operational data."; 1971 } 1973 identity config-push { 1974 base update-stream; 1975 description 1976 "A conceptual datastream consisting of updates of all 1977 configuration data."; 1978 } 1980 identity custom-stream { 1981 base update-stream; 1982 description 1983 "A category of customizable datastream for datastore 1984 updates with contents that have defined by a user."; 1985 } 1987 identity netconf-stream { 1988 base event-stream; 1989 description 1990 "Default notification stream"; 1991 } 1993 identity encodings { 1994 description 1995 "Base identity to represent data encodings"; 1996 } 1998 identity encode-xml { 1999 base encodings; 2000 description 2001 "Encode data using XML"; 2002 } 2004 identity encode-json { 2005 base encodings; 2006 description 2007 "Encode data using JSON"; 2008 } 2010 identity transport { 2011 description 2012 "An identity that represents a transport protocol for event updates"; 2013 } 2014 identity netconf { 2015 base transport; 2016 description 2017 "Netconf notifications as a transport"; 2018 } 2020 identity restconf { 2021 base transport; 2022 description 2023 "Restconf notifications as a transport"; 2024 } 2026 typedef datastore-contents-xml { 2027 type string; 2028 description 2029 "This type is be used to represent datastore contents, 2030 i.e. a set of data nodes with their values, in XML. 2031 The syntax corresponds to the syntax of the data payload 2032 returned in a corresponding Netconf get operation with the 2033 same filter parameters applied."; 2034 reference "RFC 6241 section 7.7"; 2035 } 2037 typedef datastore-changes-xml { 2038 type string; 2039 description 2040 "This type is used to represent a set of changes in a 2041 datastore encoded in XML, indicating for datanodes whether 2042 they have been created, deleted, or updated. The syntax 2043 corresponds to the syntax used to when editing a 2044 datastore using the edit-config operation in Netconf."; 2045 reference "RFC 6241 section 7.2"; 2046 } 2048 typedef datastore-contents-json { 2049 type string; 2050 description 2051 "This type is be used to represent datastore contents, 2052 i.e. a set of data nodes with their values, in JSON. 2053 The syntax corresponds to the syntax of the data 2054 payload returned in a corresponding RESTCONF get 2055 operation with the same filter parameters applied."; 2056 reference "RESTCONF Protocol"; 2057 } 2059 typedef datastore-changes-json { 2060 type string; 2061 description 2062 "This type is used to represent a set of changes in a 2063 datastore encoded in JSON, indicating for datanodes whether 2064 they have been created, deleted, or updated. The syntax 2065 corresponds to the syntax used to patch a datastore 2066 using the yang-patch operation with Restconf."; 2067 reference "draft-ietf-netconf-yang-patch"; 2068 } 2070 typedef subscription-id { 2071 type uint32; 2072 description 2073 "A type for subscription identifiers."; 2074 } 2076 typedef filter-id { 2077 type uint32; 2078 description 2079 "A type to identify filters which can be associated with a 2080 subscription."; 2081 } 2083 typedef subscription-result { 2084 type identityref { 2085 base subscription-result; 2086 } 2087 description 2088 "The result of a subscription operation"; 2089 } 2091 typedef subscription-term-reason { 2092 type identityref { 2093 base subscription-errors; 2094 } 2095 description 2096 "Reason for a server to terminate a subscription."; 2097 } 2099 typedef subscription-susp-reason { 2100 type identityref { 2101 base subscription-errors; 2102 } 2103 description 2104 "Reason for a server to suspend a subscription."; 2105 } 2107 typedef encoding { 2108 type identityref { 2109 base encodings; 2111 } 2112 description 2113 "Specifies a data encoding, e.g. for a data subscription."; 2114 } 2116 typedef change-type { 2117 type enumeration { 2118 enum "create" { 2119 description 2120 "A new data node was created"; 2121 } 2122 enum "delete" { 2123 description 2124 "A data node was deleted"; 2125 } 2126 enum "modify" { 2127 description 2128 "The value of a data node has changed"; 2129 } 2130 } 2131 description 2132 "Specifies different types of changes that may occur 2133 to a datastore."; 2134 } 2136 typedef transport-protocol { 2137 type identityref { 2138 base transport; 2139 } 2140 description 2141 "Specifies transport protocol used to send updates to a 2142 receiver."; 2143 } 2145 typedef push-source { 2146 type enumeration { 2147 enum "interface-originated" { 2148 description 2149 "Pushes will be sent from a specific interface on a 2150 Publisher"; 2151 } 2152 enum "address-originated" { 2153 description 2154 "Pushes will be sent from a specific address on a 2155 Publisher"; 2156 } 2157 } 2158 description 2159 "Specifies from where objects will be sourced when being pushed 2160 off a publisher."; 2161 } 2163 typedef update-stream { 2164 type identityref { 2165 base update-stream; 2166 } 2167 description 2168 "Specifies a system-provided datastream."; 2169 } 2171 typedef filter-ref { 2172 type leafref { 2173 path "/yp:filters/yp:filter/yp:filter-id"; 2174 } 2175 description 2176 "This type is used to reference a yang push filter."; 2177 } 2179 grouping datatree-filter { 2180 description 2181 "This grouping defines filters for a datastore tree."; 2182 choice filter-type { 2183 description 2184 "A filter needs to be a single filter of a given type. 2185 Mixing and matching of multiple filters does not occur 2186 at the level of this grouping."; 2187 case subtree { 2188 description 2189 "Subtree filter."; 2190 anyxml subtree-filter { 2191 description 2192 "Subtree-filter used to specify the data nodes targeted 2193 for subscription within a subtree, or subtrees, of a 2194 conceptual YANG datastore. 2195 It may include additional criteria, 2196 allowing users to receive only updates of a limited 2197 set of data nodes that match those filter criteria. 2198 This will be used to define what 2199 updates to include in a stream of update events, i.e. 2200 to specify for which data nodes update events should be 2201 generated and specific match expressions that objects 2202 need to meet. The syntax follows the subtree filter 2203 syntax specified in RFC 6241, section 6."; 2204 reference "RFC 6241 section 6"; 2205 } 2206 } 2207 case xpath { 2208 description 2209 "XPath filter"; 2210 leaf xpath-filter { 2211 type yang:xpath1.0; 2212 description 2213 "Xpath defining the data items of interest."; 2214 } 2215 } 2216 case rfc5277 { 2217 anyxml filter { 2218 description 2219 "Subtree filter per RFC 5277"; 2220 } 2221 } 2222 } 2223 } 2225 grouping update-policy { 2226 description 2227 "This grouping describes the conditions under which an 2228 update will be sent as part of an update stream."; 2229 choice update-trigger { 2230 description 2231 "Defines necessary conditions for sending an event to 2232 the subscriber."; 2233 case periodic { 2234 description 2235 "The agent is requested to notify periodically the 2236 current values of the datastore or the subset 2237 defined by the filter."; 2238 leaf period { 2239 type yang:timeticks; 2240 mandatory true; 2241 description 2242 "Duraton of time which should occur between periodic 2243 push updates. Where the anchor of a start-time is 2244 available, the push will include the objects and their 2245 values which exist at an exact multiple of timeticks 2246 aligning to this start-time anchor."; 2247 } 2248 } 2249 case on-change { 2250 if-feature "on-change"; 2251 description 2252 "The agent is requested to notify changes in 2253 values in the datastore or a subset of it defined 2254 by a filter."; 2256 leaf no-synch-on-start { 2257 type empty; 2258 description 2259 "This leaf acts as a flag that determines behavior at the 2260 start of the subscription. When present, 2261 synchronization of state at the beginning of the 2262 subscription is outside the scope of the subscription. 2263 Only updates about changes that are observed from the 2264 start time, i.e. only push-change-update notifications 2265 are sent. 2266 When absent (default behavior), in order to facilitate 2267 a receiver's synchronization, a full update is sent 2268 when the subscription starts using a push-update 2269 notification, just like in the case of a periodic 2270 subscription. After that, push-change-update 2271 notifications are sent."; 2272 } 2273 leaf dampening-period { 2274 type yang:timeticks; 2275 mandatory true; 2276 description 2277 "Minimum amount of time that needs to have 2278 passed since the last time an update was 2279 provided."; 2280 } 2281 leaf-list excluded-change { 2282 type change-type; 2283 description 2284 "Use to restrict which changes trigger an update. 2285 For example, if modify is excluded, only creation and 2286 deletion of objects is reported."; 2287 } 2288 } 2289 } 2290 } 2292 grouping subscription-info { 2293 description 2294 "This grouping describes basic information concerning a 2295 subscription."; 2296 leaf stream { 2297 type update-stream; 2298 description 2299 "The stream being subscribed to."; 2300 } 2301 leaf encoding { 2302 type encoding; 2303 default "encode-xml"; 2304 description 2305 "The type of encoding for the subscribed data. 2306 Default is XML"; 2307 } 2308 leaf subscription-start-time { 2309 type yang:date-and-time; 2310 description 2311 "Designates the time at which a subscription is supposed 2312 to start, or immediately, in case the start-time is in 2313 the past. For periodic subscription, the start time also 2314 serves as anchor time from which the time of the next 2315 update is computed. The next update will take place at the 2316 next period interval from the anchor time. 2317 For example, for an anchor time at the top of a minute 2318 and a period interval of a minute, the next update will 2319 be sent at the top of the next minute."; 2320 } 2321 leaf subscription-stop-time { 2322 type yang:date-and-time; 2323 description 2324 "Designates the time at which a subscription will end. 2325 When a subscription reaches its stop time, it will be 2326 automatically deleted. No final push is required unless there 2327 is exact alignment with the end of a periodic subscription 2328 period."; 2329 } 2330 choice filterspec { 2331 description 2332 "The filter to be applied to the stream as part of the 2333 subscription. The filter defines which updates of the 2334 data stream are of interest to a subscriber. 2335 The filter can be specified in-line 2336 or configured separately and referenced here. 2337 If no filter is specified, the entire datatree 2338 is of interest."; 2339 case inline { 2340 description 2341 "Filter is defined as part of the subscription."; 2342 uses datatree-filter; 2343 } 2344 case by-reference { 2345 description 2346 "Incorporate a filter that has been configured 2347 separately."; 2348 leaf filter-ref { 2349 type filter-ref; 2350 description 2351 "References filter which is associated with the 2352 subscription."; 2353 } 2354 } 2355 } 2356 } 2358 grouping push-source-info { 2359 description 2360 "Defines the sender source from which push updates 2361 for a configured subscription are pushed."; 2362 choice push-source { 2363 description 2364 "Identifies the egress interface on the Publisher from 2365 which pushed updates will or are being sent."; 2366 case interface-originated { 2367 description 2368 "When the push source is out of an interface on the 2369 Publisher established via static configuration."; 2370 leaf source-interface { 2371 type if:interface-ref; 2372 description 2373 "References the interface for pushed updates."; 2374 } 2375 } 2376 case address-originated { 2377 description 2378 "When the push source is out of an IP address on the 2379 Publisher established via static configuration."; 2380 leaf source-vrf { 2381 type uint32 { 2382 range "16..1048574"; 2383 } 2384 description 2385 "Label of the vrf."; 2386 } 2387 leaf source-address { 2388 type inet:ip-address-no-zone; 2389 mandatory true; 2390 description 2391 "The source address for the pushed objects."; 2392 } 2393 } 2394 } 2395 } 2397 grouping receiver-info { 2398 description 2399 "Defines where and how to deliver push updates for a 2400 configured subscription. This includes 2401 specifying the receiver, as well as defining 2402 any network and transport aspects when pushing of 2403 updates occurs outside of Netconf or Restconf."; 2404 list receiver { 2405 key "address"; 2406 description 2407 "A single host or multipoint address intended as a target 2408 for the pushed updates for a subscription."; 2409 leaf address { 2410 type inet:host; 2411 description 2412 "Specifies the address for the traffic to reach a 2413 remote host. One of the following must be 2414 specified: an ipv4 address, an ipv6 address, 2415 or a host name."; 2416 } 2417 leaf port { 2418 type inet:port-number; 2419 description 2420 "This leaf specifies the port number to use for messages 2421 destined for a receiver."; 2422 } 2423 leaf protocol { 2424 type transport-protocol; 2425 default "netconf"; 2426 description 2427 "This leaf specifies the transport protocol used 2428 to deliver messages destined for the receiver."; 2429 } 2430 } 2431 } 2433 grouping subscription-qos { 2434 description 2435 "This grouping describes Quality of Service information 2436 concerning a subscription. This information is passed to lower 2437 layers for transport priortization and treatment"; 2438 leaf dscp { 2439 if-feature configured-subscriptions; 2440 type inet:dscp; 2441 default 0; 2442 description 2443 "The push update's IP packet transport priority. 2444 This is made visible across network hops to receiver. 2445 The transport priority is shared for all receivers of 2446 a given subscription."; 2447 } 2448 leaf subscription-priority { 2449 type uint8; 2450 description 2451 "Relative priority for a subscription. Allows an underlying 2452 transport layer perform informed load balance allocations 2453 between various subscriptions"; 2454 } 2455 leaf subscription-dependency { 2456 type string; 2457 description 2458 "Provides the Subscription ID of a parent subscription 2459 without which this subscription should not exist. In 2460 other words, there is no reason to stream these objects 2461 if another subscription is missing."; 2462 } 2463 } 2465 rpc establish-subscription { 2466 description 2467 "This RPC allows a subscriber to establish a subscription 2468 on its own behalf. If successful, the subscription 2469 remains in effect for the duration of the subscriber's 2470 association with the publisher, or until the subscription 2471 is terminated by virtue of a delete-subscription request. 2472 In case an error (as indicated by subscription-result) 2473 is returned, the subscription is 2474 not establishd. In that case, the RPC output 2475 MAY include suggested parameter settings 2476 that would have a high likelihood of succeeding in a 2477 subsequent establish-subscription request."; 2478 input { 2479 uses subscription-info; 2480 uses update-policy; 2481 uses subscription-qos; 2482 } 2483 output { 2484 leaf subscription-result { 2485 type subscription-result; 2486 mandatory true; 2487 description 2488 "Indicates whether subscription is operational, 2489 or if a problem was encountered."; 2490 } 2491 choice result { 2492 description 2493 "Depending on the subscription result, different 2494 data is returned."; 2495 case success { 2496 description 2497 "This case is used when the subscription request 2498 was successful and a subscription was established as 2499 a result"; 2500 leaf subscription-id { 2501 type subscription-id; 2502 mandatory true; 2503 description 2504 "Identifier used for this subscription."; 2505 } 2506 } 2507 case no-success { 2508 description 2509 "This case applies when a subscription request 2510 was not successful and no subscription was 2511 established as a result. In this case, 2512 information MAY be returned that indicates 2513 suggested parameter settings that would have a 2514 high likelihood of succeeding in a subsequent 2515 establish-subscription request."; 2516 uses subscription-info; 2517 uses update-policy; 2518 uses subscription-qos; 2519 } 2520 } 2521 } 2522 } 2523 rpc modify-subscription { 2524 description 2525 "This RPC allows a subscriber to modify a subscription 2526 that was previously established using establish-subscription. 2527 If successful, the subscription 2528 remains in effect for the duration of the subscriber's 2529 association with the publisher, or until the subscription 2530 is terminated by virtue of a delete-subscription request. 2531 In case an error is returned (as indicated by 2532 subscription-result), the subscription is 2533 not modified and the original subscription parameters 2534 remain in effect. In that case, the rpc error response 2535 MAY include suggested parameter settings 2536 that would have a high likelihood of succeeding in a 2537 subsequent modify-subscription request."; 2538 input { 2539 leaf subscription-id { 2540 type subscription-id; 2541 description 2542 "Identifier to use for this subscription."; 2543 } 2544 uses subscription-info; 2545 uses update-policy; 2546 uses subscription-qos; 2547 } 2548 output { 2549 leaf subscription-result { 2550 type subscription-result; 2551 mandatory true; 2552 description 2553 "Indicates whether subscription was modified 2554 or if a problem was encountered. 2555 In case the subscription-result has a value 2556 other than OK, the original subscription was not 2557 changed."; 2558 } 2559 uses subscription-info; 2560 uses update-policy; 2561 uses subscription-qos; 2562 } 2563 } 2564 rpc delete-subscription { 2565 description 2566 "This RPC allows a subscriber to delete a subscription that 2567 was previously established using establish-subscription."; 2568 input { 2569 leaf subscription-id { 2570 type subscription-id; 2571 description 2572 "Identifier of the subscription that is to be deleted. 2573 Only subscriptions that were established using 2574 establish-subscription can be deleted via this RPC."; 2575 } 2576 } 2577 } 2578 notification push-update { 2579 description 2580 "This notification contains a periodic push update. 2581 This notification shall only be sent to receivers 2582 of a subscription; it does not constitute a general-purpose 2583 notification."; 2584 leaf subscription-id { 2585 type subscription-id; 2586 mandatory true; 2587 description 2588 "This references the subscription because of which the 2589 notification is sent."; 2590 } 2591 leaf time-of-update { 2592 type yang:date-and-time; 2593 description 2594 "This leaf contains the time of the update."; 2595 } 2596 choice encoding { 2597 description 2598 "Distinguish between the proper encoding that was specified 2599 for the subscription"; 2600 case encode-xml { 2601 description 2602 "XML encoding"; 2603 leaf datastore-contents-xml { 2604 type datastore-contents-xml; 2605 description 2606 "This contains data encoded in XML, 2607 per the subscription."; 2608 } 2609 } 2610 case encode-json { 2611 if-feature "json"; 2612 description 2613 "JSON encoding"; 2614 leaf datastore-contents-json { 2615 type datastore-contents-json; 2616 description 2617 "This leaf contains data encoded in JSON, 2618 per the subscription."; 2619 } 2620 } 2621 } 2622 } 2623 notification push-change-update { 2624 if-feature "on-change"; 2625 description 2626 "This notification contains an on-change push update. 2627 This notification shall only be sent to the receivers 2628 of a subscription; it does not constitute a general-purpose 2629 notification."; 2630 leaf subscription-id { 2631 type subscription-id; 2632 mandatory true; 2633 description 2634 "This references the subscription because of which the 2635 notification is sent."; 2636 } 2637 leaf time-of-update { 2638 type yang:date-and-time; 2639 description 2640 "This leaf contains the time of the update, i.e. the 2641 time at which the change was observed."; 2642 } 2643 choice encoding { 2644 description 2645 "Distinguish between the proper encoding that was specified 2646 for the subscription"; 2647 case encode-xml { 2648 description 2649 "XML encoding"; 2650 leaf datastore-changes-xml { 2651 type datastore-changes-xml; 2652 description 2653 "This contains datastore contents that has changed 2654 since the previous update, per the terms of the 2655 subscription. Changes are encoded analogous to 2656 the syntax of a corresponding Netconf edit-config 2657 operation."; 2658 } 2659 } 2660 case encode-json { 2661 if-feature "json"; 2662 description 2663 "JSON encoding"; 2664 leaf datastore-changes-yang { 2665 type datastore-changes-json; 2666 description 2667 "This contains datastore contents that has changed 2668 since the previous update, per the terms of the 2669 subscription. Changes are encoded analogous 2670 to the syntax of a corresponding RESTCONF yang-patch 2671 operation."; 2672 } 2673 } 2674 } 2675 } 2676 notification subscription-started { 2677 description 2678 "This notification indicates that a subscription has 2679 started and data updates are beginning to be sent. 2680 This notification shall only be sent to receivers 2681 of a subscription; it does not constitute a general-purpose 2682 notification."; 2683 leaf subscription-id { 2684 type subscription-id; 2685 mandatory true; 2686 description 2687 "This references the affected subscription."; 2689 } 2690 uses subscription-info; 2691 uses update-policy; 2692 uses subscription-qos; 2693 } 2694 notification subscription-suspended { 2695 description 2696 "This notification indicates that a suspension of the 2697 subscription by the server has occurred. No further 2698 datastore updates will be sent until subscription 2699 resumes. 2700 This notification shall only be sent to receivers 2701 of a subscription; it does not constitute a general-purpose 2702 notification."; 2703 leaf subscription-id { 2704 type subscription-id; 2705 mandatory true; 2706 description 2707 "This references the affected subscription."; 2708 } 2709 leaf reason { 2710 type subscription-susp-reason; 2711 description 2712 "Provides a reason for why the subscription was 2713 suspended."; 2714 } 2715 } 2716 notification subscription-resumed { 2717 description 2718 "This notification indicates that a subscription that had 2719 previously been suspended has resumed. Datastore updates 2720 will once again be sent."; 2721 leaf subscription-id { 2722 type subscription-id; 2723 mandatory true; 2724 description 2725 "This references the affected subscription."; 2726 } 2727 } 2728 notification subscription-modified { 2729 description 2730 "This notification indicates that a subscription has 2731 been modified. Datastore updates sent from this point 2732 on will conform to the modified terms of the 2733 subscription."; 2734 leaf subscription-id { 2735 type subscription-id; 2736 mandatory true; 2737 description 2738 "This references the affected subscription."; 2739 } 2740 uses subscription-info; 2741 uses update-policy; 2742 uses subscription-qos; 2743 } 2744 notification subscription-terminated { 2745 description 2746 "This notification indicates that a subscription has been 2747 terminated."; 2748 leaf subscription-id { 2749 type subscription-id; 2750 mandatory true; 2751 description 2752 "This references the affected subscription."; 2753 } 2754 leaf reason { 2755 type subscription-term-reason; 2756 description 2757 "Provides a reason for why the subscription was 2758 terminated."; 2759 } 2760 } 2761 container update-streams { 2762 config false; 2763 description 2764 "This container contains a leaf list of built-in 2765 streams that are provided by the system."; 2766 leaf-list update-stream { 2767 type update-stream; 2768 description 2769 "Identifies a built-in stream that is supported by the 2770 system. Streams are associated with their own identities, 2771 each of which carries a special semantics."; 2772 } 2773 } 2774 container filters { 2775 description 2776 "This container contains a list of configurable filters 2777 that can be applied to subscriptions. This facilitates 2778 the reuse of complex filters once defined."; 2779 list filter { 2780 key "filter-id"; 2781 description 2782 "A list of configurable filters that can be applied to 2783 subscriptions."; 2784 leaf filter-id { 2785 type filter-id; 2786 description 2787 "An identifier to differentiate between filters."; 2788 } 2789 uses datatree-filter; 2790 } 2791 } 2792 container subscription-config { 2793 if-feature "configured-subscriptions"; 2794 description 2795 "Contains the list of subscriptions that are configured, 2796 as opposed to established via RPC or other means."; 2797 list yang-push-subscription { 2798 key "subscription-id"; 2799 description 2800 "Content of a yang-push subscription."; 2801 leaf subscription-id { 2802 type subscription-id; 2803 description 2804 "Identifier to use for this subscription."; 2805 } 2806 uses subscription-info; 2807 uses update-policy; 2808 uses receiver-info; 2809 uses push-source-info; 2810 uses subscription-qos; 2811 } 2812 } 2813 container subscriptions { 2814 config false; 2815 description 2816 "Contains the list of currently active subscriptions, 2817 i.e. subscriptions that are currently in effect, 2818 used for subscription management and monitoring purposes. 2819 This includes subscriptions that have been setup via RPC 2820 primitives, e.g. establish-subscription, delete-subscription, 2821 and modify-subscription, as well as subscriptions that 2822 have been established via configuration."; 2823 list yang-push-subscription { 2824 key "subscription-id"; 2825 config false; 2826 description 2827 "Content of a yang-push subscription. 2828 Subscriptions can be established using a control channel 2829 or RPC, or be established through configuration."; 2830 leaf subscription-id { 2831 type subscription-id; 2832 description 2833 "Identifier of this subscription."; 2834 } 2835 leaf configured-subscription { 2836 if-feature "configured-subscriptions"; 2837 type empty; 2838 description 2839 "The presence of this leaf indicates that the 2840 subscription originated from configuration, not through 2841 a control channel or RPC."; 2842 } 2843 leaf subscription-status { 2844 type identityref { 2845 base subscription-stream-status; 2846 } 2847 description 2848 "The status of the subscription."; 2849 } 2850 uses subscription-info; 2851 uses update-policy; 2852 uses receiver-info; 2853 uses push-source-info; 2854 uses subscription-qos; 2855 } 2856 } 2857 } 2859 2861 6. Security Considerations 2863 Subscriptions could be used to attempt to overload servers of YANG 2864 datastores. For this reason, it is important that the server has the 2865 ability to decline a subscription request if it would deplete its 2866 resources. In addition, a server needs to be able to suspend an 2867 existing subscription when needed. When this occur, the subscription 2868 status is updated accordingly and the clients are notified. 2869 Likewise, requests for subscriptions need to be properly authorized. 2871 A subscription could be used to retrieve data in subtrees that a 2872 client has not authorized access to. Therefore it is important that 2873 data pushed based on subscriptions is authorized in the same way that 2874 regular data retrieval operations are. Data being pushed to a client 2875 needs therefore to be filtered accordingly, just like if the data 2876 were being retrieved on-demand. The Netconf Authorization Control 2877 Model applies. 2879 A subscription could be configured on another receiver's behalf, with 2880 the goal of flooding that receiver with updates. One or more 2881 publishers could be used to overwhelm a receiver which doesn't even 2882 support subscriptions. Clients which do not want pushed data need 2883 only terminate or refuse any transport sessions from the publisher. 2884 In addition, the Netconf Authorization Control Model SHOULD be used 2885 to control and restrict authorization of subscription configuration. 2887 7. References 2889 7.1. Normative References 2891 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 2892 "Simple Network Management Protocol (SNMP)", RFC 1157, 2893 DOI 10.17487/RFC1157, May 1990, 2894 . 2896 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2897 Notifications", RFC 5277, July 2008. 2899 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2900 the Network Configuration Protocol (NETCONF)", RFC 6020, 2901 DOI 10.17487/RFC6020, October 2010, 2902 . 2904 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2905 and A. Bierman, Ed., "Network Configuration Protocol 2906 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2907 . 2909 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 2910 Base Notifications", RFC 5277, February 2012. 2912 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2913 Protocol (NETCONF) Access Control Model", RFC 6536, 2914 DOI 10.17487/RFC6536, March 2012, 2915 . 2917 7.2. Informative References 2919 [I-D.clemm-netmod-mount] 2920 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-defined 2921 information from remote datastores", draft-clemm-netmod- 2922 mount-03 (work in progress), April 2015. 2924 [I-D.gonzalez-netconf-5277bis] 2925 Gonzalez Prieto, A., Clemm, A., Voit, E., Tripathy, A., 2926 and E. Nilsen-Nygaard, "Mounting YANG-defined information 2927 from remote datastores", draft-clemm-netmod-mount-03 (work 2928 in progress), March 2016. 2930 [I-D.i2rs-pub-sub-requirements] 2931 Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 2932 for Subscription to YANG Datastores", draft-ietf-i2rs-pub- 2933 sub-requirements-05 (work in progress), February 2016. 2935 [I-D.ietf-netconf-restconf] 2936 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2937 Protocol", I-D draft-ietf-netconf-restconf-10, March 2016. 2939 [I-D.ietf-netconf-yang-patch] 2940 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 2941 Media Type", draft-ietf-netconf-yang-patch-08 (work in 2942 progress), March 2016. 2944 [I-D.ietf-netmod-yang-json] 2945 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2946 draft-ietf-netmod-yang-json-07 (work in progress), January 2947 2016. 2949 [I-D.voit-netmod-yang-mount-requirements] 2950 Voit, E., Clemm, A., and S. Mertens, "Requirements for 2951 Peer Mounting of YANG subtrees from Remote Datastores", 2952 draft-voit-netmod-yang-mount-requirements-00 (work in 2953 progress), March 2016. 2955 Authors' Addresses 2957 Alexander Clemm 2958 Cisco Systems 2960 EMail: alex@cisco.com 2962 Alberto Gonzalez Prieto 2963 Cisco Systems 2965 EMail: albertgo@cisco.com 2967 Eric Voit 2968 Cisco Systems 2970 EMail: evoit@cisco.com 2971 Ambika Prasad Tripathy 2972 Cisco Systems 2974 EMail: ambtripa@cisco.com 2976 Einar Nilsen-Nygaard 2977 Cisco Systems 2979 EMail: einarnn@cisco.com