idnits 2.17.1 draft-ietf-netconf-yang-push-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 409: '... the server SHOULD include in the re...' RFC 2119 keyword, line 437: '...cription request MUST be rejected. As...' RFC 2119 keyword, line 472: '... MUST support XML encoding and MAY s...' RFC 2119 keyword, line 875: '... Implementations MAY therefore choose,...' RFC 2119 keyword, line 1268: '... it, the server SHOULD include in the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1823 has weird spacing: '...n event to...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2015) is 3109 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 384, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1157 -- Duplicate reference: RFC5277, mentioned in 'RFC6470', was also mentioned in 'RFC5277'. ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-06) exists of draft-clemm-netmod-mount-03 == Outdated reference: A later version (-09) exists of draft-ietf-i2rs-pub-sub-requirements-03 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-07 == Outdated reference: A later version (-14) exists of draft-ietf-netconf-yang-patch-05 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-06 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft A. Gonzalez Prieto 4 Intended status: Standards Track E. Voit 5 Expires: April 17, 2016 Cisco Systems 6 October 15, 2015 8 Subscribing to YANG datastore push updates 9 draft-ietf-netconf-yang-push-00.txt 11 Abstract 13 This document defines a subscription and push mechanism for YANG 14 datastores. This mechanism allows client applications to request 15 updates from a YANG datastore, which are then pushed by the server to 16 the client per a subscription policy, without requiring additional 17 client requests. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 17, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5 67 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Subscription Model . . . . . . . . . . . . . . . . . . . 7 69 3.2. Negotiation of Subscription Policies . . . . . . . . . . 9 70 3.3. On-Change Considerations . . . . . . . . . . . . . . . . 9 71 3.4. Data Encodings . . . . . . . . . . . . . . . . . . . . . 10 72 3.4.1. Periodic Subscriptions . . . . . . . . . . . . . . . 11 73 3.4.2. On-Change Subscriptions . . . . . . . . . . . . . . . 11 74 3.5. Subscription Filters . . . . . . . . . . . . . . . . . . 12 75 3.6. Push Data Stream and Transport Mapping . . . . . . . . . 12 76 3.7. Subscription management . . . . . . . . . . . . . . . . . 16 77 3.7.1. Subscription management by RPC . . . . . . . . . . . 16 78 3.7.2. Subscription management by configuration . . . . . . 18 79 3.8. Other considerations . . . . . . . . . . . . . . . . . . 18 80 3.8.1. Authorization . . . . . . . . . . . . . . . . . . . . 18 81 3.8.2. Additional subscription primitives . . . . . . . . . 19 82 3.8.3. Robustness and reliability considerations . . . . . . 19 83 3.8.4. Update size and fragmentation considerations . . . . 19 84 3.8.5. Additional data streams . . . . . . . . . . . . . . . 19 85 3.8.6. Implementation considerations . . . . . . . . . . . . 20 86 4. A YANG data model for management of datastore push 87 subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 89 4.2. System streams . . . . . . . . . . . . . . . . . . . . . 23 90 4.3. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 4.4. Subscription configuration . . . . . . . . . . . . . . . 23 92 4.5. Subscription monitoring . . . . . . . . . . . . . . . . . 25 93 4.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 94 4.7. RPCs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 4.7.1. Create-subscription RPC . . . . . . . . . . . . . . . 26 96 4.7.2. Modify-subscription RPC . . . . . . . . . . . . . . . 29 97 4.7.3. Delete-subscription RPC . . . . . . . . . . . . . . . 32 98 5. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 50 103 8.2. Informative References . . . . . . . . . . . . . . . . . 50 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 106 1. Introduction 108 YANG [RFC6020] was originally designed for the Netconf protocol 109 [RFC6241], which originally put most emphasis on configuration. 110 However, YANG is not restricted to configuration data. YANG 111 datastores, i.e. datastores that contain data modeled according using 112 YANG, can contain configuration as well as operational data. It is 113 therefore reasonable to expect that data in YANG datastores will 114 increasingly be used to support applications that are not focused on 115 managing configurations but that are, for example, related to service 116 assurance. 118 Service assurance applications typically involve monitoring 119 operational state of networks and devices; of particular interest are 120 changes that this data undergoes over time. Likewise, there are 121 applications in which data and objects from one datastore need to be 122 made available both to applications in other systems and to remote 123 datastores [I-D.voit-netmod-peer-mount-requirements] 124 [I-D.clemm-netmod-mount]. This requires mechanisms that allow remote 125 systems to become quickly aware of any updates to allow to validate 126 and maintain cross-network integrity and consistency. 128 Traditional approaches to remote network state visibility rely 129 heavily on polling. With polling, data is periodically explicitly 130 retrieved by a client from a server to stay up-to-date. 132 There are various issues associated with polling-based management: 134 o It introduces additional load on network, devices, and 135 applications. Each polling cycle requires a separate yet arguably 136 redundant request that results in an interrupt, requires parsing, 137 consumes bandwidth. 139 o It lacks robustness. Polling cycles may be missed, requests may 140 be delayed or get lost, often particularly in cases when the 141 network is under stress and hence exactly when the need for the 142 data is the greatest. 144 o Data may be difficult to calibrate and compare. Polling requests 145 may undergo slight fluctuations, resulting in intervals of 146 different lengths which makes data hard to compare. Likewise, 147 pollers may have difficulty issuing requests that reach all 148 devices at the same time, resulting in offset polling intervals 149 which again make data hard to compare. 151 A more effective alternative is when an application can request to be 152 automatically updated as necessary of current content of the 153 datastore (such as a subtree, or data in a subtree that meets a 154 certain filter condition), and in which the server that maintains the 155 datastore subsequently pushes those updates. However, such a 156 solution does not currently exist. 158 The need to perform polling-based management is typically considered 159 an important shortcoming of management applications that rely on MIBs 160 polled using SNMP [RFC1157]. However, without a provision to support 161 a push-based alternative, there is no reason to believe that 162 management applications that operate on YANG datastores using 163 protocols such as NETCONF or Restconf [I-D.ietf-netconf-restconf] 164 will be any more effective, as they would follow the same request/ 165 response pattern. 167 While YANG allows the definition of notifications, such notifications 168 are generally intended to indicate the occurrence of certain well- 169 specified event conditions, such as a the onset of an alarm condition 170 or the occurrence of an error. A capability to subscribe to and 171 deliver event notifications has been defined in [RFC5277]. In 172 addition, configuration change notifications have been defined in 173 [RFC6470]. These change notifications pertain only to configuration 174 information, not to operational state, and convey the root of the 175 subtree to which changes were applied along with the edits, but not 176 the modified data nodes and their values. 178 Accordingly, there is a need for a service that allows client 179 applications to subscribe to updates of a YANG datastore and that 180 allows the server to push those updates. The requirements for such a 181 service are documented in [I-D.i2rs-pub-sub-requirements]. This 182 document proposes a solution that features the following 183 capabilities: 185 o A mechanism that allows clients to subscribe to automatic 186 datastore updates, and the means to manage those subscription. 187 The subscription allows clients to specify which data they are 188 interested in, and to provide optional filters with criteria that 189 data must meet for updates to be sent. Furthermore, subscription 190 can specify a policy that directs when updates are provided. For 191 example, a client may request to be updated periodically in 192 certain intervals, or whenever data changes occur. 194 o The ability for a server to push back on requested subscription 195 parameters. Because not every server may support every requested 196 interval for every piece of data, it is necessary for a server to 197 be able to indicate whether or not it is capable of supporting a 198 requested subscription, and possibly allow to negotiate 199 subscription parameters. 201 o A mechanism to communicate the updates themselves. For this, the 202 proposal leverages and extends existing YANG/Netconf/Restconf 203 mechanisms, defining special notifications that carry updates. 205 This document specifies a YANG data model to manage subscriptions to 206 data in YANG datastores, and to configure associated filters and data 207 streams. It defines extensions to RPCs defined in [RFC5277] that 208 allow to extend notification subscriptions to subscriptions for 209 datastore updates. It also defines a notification that can be used 210 to carry data updates and thus serve as push mechanism. 212 2. Definitions and Acronyms 214 Data node: An instance of management information in a YANG datastore. 216 Data record: A record containing a set of one or more data node 217 instances and their associated values. 219 Datastore: A conceptual store of instantiated management information, 220 with individual data items represented by data nodes which are 221 arranged in hierarchical manner. 223 Datastream: A continuous stream of data records, each including a set 224 of updates, i.e. data node instances and their associated values. 226 Data subtree: An instantiated data node and the data nodes that are 227 hierarchically contained within it. 229 NACM: NETCONF Access Control Model 231 NETCONF: Network Configuration Protocol 233 Push-update stream: A conceptual data stream of a datastore that 234 streams the entire datastore contents continuously and perpetually. 236 RPC: Remote Procedure Call 238 SNMP: Simple Network Management Protocol 239 Subscription: A contract between a client ("subscriber") and a server 240 ("publisher"), stipulating which information the client wishes to 241 receive from the server (and which information the server has to 242 provide to the client) without the need for further solicitation. 244 Subscription filter: A filter that contains evaluation criteria which 245 are evaluated against YANG objects of a subscription. An update is 246 only published if the object meets the specified filter criteria. 248 Subscription policy: A policy that specifies under what circumstances 249 to push an update, e.g. whether updates are to be provided 250 periodically or only whenever changes occur. 252 Update: A data item containing the current value of a data node. 254 Update trigger: A trigger, as specified by a subscription policy, 255 that causes an update to be sent, respectively a data record to be 256 generated. An example of a trigger is a change trigger, invoked when 257 the value of a data node changes or a data node is created or 258 deleted, or a time trigger, invoked after the laps of a periodic time 259 interval. 261 URI: Uniform Resource Identifier 263 YANG: A data definition language for NETCONF 265 Yang-push: The subscription and push mechanism for YANG datastores 266 that is specified in this document. 268 3. Solution Overview 270 This document specifies a solution that allows clients to subscribe 271 to information updates in a YANG datastore, which are subsequently 272 pushed from the server to the client. 274 Subscriptions are initiated by clients. Servers respond to a 275 subscription request explicitly positively or negatively. Negative 276 responses include information about why the subscription was not 277 accepted, in order to facilitate converging on an acceptable set of 278 subscription parameters. Once a subscription has been established, 279 datastore push updates are pushed from the server to the subscribing 280 client until the subscription ends. 282 Accordingly, the solution encompasses several components: 284 o The subscription model for configuration and management of the 285 subscriptions, with a set of associated services. 287 o The ability to provide hints for acceptable subscription 288 parameters, in cases where a subscription desired by a client 289 cannot currently be served. 291 o The stream of datastore push updates. 293 In addition, there are a number of additional considerations, such as 294 the tie-in of the mechanisms with security mechanisms. Each of those 295 aspects will be discussed in the following subsections. 297 3.1. Subscription Model 299 Yang-push subscriptions are defined using a data model that is itself 300 defined in YANG. This model is based on the subscriptions defined in 301 [RFC5277], which are also reused in Restconf. The model is extended 302 with several parameters, including a subscription type and a 303 subscription ID. 305 The subscription model assumes the presence of a conceptual perpetual 306 datastream "push-update" of continuous datastore updates that can be 307 subscribed to, although other datastreams may be supported as well. 308 A subscription refers to a datastream and specifies filters that are 309 to be applied to, it for example, to provide only those subsets of 310 the information that match a filter criteria. In addition, a 311 subscription specifies a set of subscription parameters that define 312 the trigger when data records should be sent, for example at periodic 313 intervals or whenever underlying data items change. 315 The complete set of subscription parameters is as follows: 317 o The stream being subscribed to. The subscription model assumes 318 the presence of perpetual and continuous streams of updates. The 319 stream "push-update" is always available and covers the entire set 320 of YANG data in the server, but a system may provide other streams 321 to choose from. 323 o The datastore to target. By default, the datastore will always be 324 "running". However, it is conceivable that implementations want 325 to also support subscriptions to updates to other datastores. 327 o An encoding for the data updates. By default, updates are encoded 328 using XML, but JSON can be requested as an option and other 329 encodings may be supported in the future. 331 o An optional start time for the subscription. If the specified 332 start time is in the past, the subscription goes into effect 333 immediately. The start time also serves as anchor time for 334 periodic subscriptions, from which intervals at which to send 335 updates are calculated (see also below). 337 o An optional stop time for the subscription. Once the stop time is 338 reached, the subscription is automatically terminated. 340 o A subscription policy definition regarding the update trigger when 341 to send new updates. The trigger can be periodic or based on 342 change. 344 * For periodic subscriptions, the trigger is defined by a 345 parameter that defines the interval with which updates are to 346 be pushed. The start time of the subscription serves as anchor 347 time, defining one specific point in time at which an update 348 needs to be sent. Update intervals always fall on the points 349 in time that are a multiple of a period after the start time. 351 * For on-change subscriptions, the trigger occurs whenever a 352 change in the subscribed information is detected. On-change 353 subscriptions have more complex semantics that can be guided by 354 additional parameters. Please refer also to Section 3.3. 356 + One parameter is needed to specify the dampening period, 357 i.e. the interval that must pass before a successive update 358 for the same data node is sent. The first time a change is 359 detected, the update is sent immediately. If a subsequent 360 change is detected, another update is only sent once the 361 dampening period has passed, containing the value of the 362 data node that is then valid. 364 + Another parameter allows to restrict the types of changes 365 for which updates are sent (changes to object values, object 366 creation or deletion events). It is conceivable to augment 367 the data model with additional parameters in the future to 368 specify even more refined policies, such as parameters that 369 specify the magnitude of a change that must occur before an 370 update is triggered. 372 + A third parameter specifies whether or not a complete update 373 with all the subscribed data should be sent at the beginning 374 of a subscription. 376 o Optionally, a filter, or set of filters, describing the subset of 377 data items in the stream's data records that are of interest to 378 the subscriber. The server should only send to the subscriber the 379 data items that match the filter(s), when present. The absence of 380 a filter indicates that all data items from the stream are of 381 interest to the subscriber and all data records must be sent in 382 their entirety to the subscriber. Two types of filters are 383 support: subtree filter, with the same semantics as defined in 384 [RFC 6241], and XPath filters. Additional filter types can be 385 added through augmentations. Filters can be specified "inline" as 386 part of the subscription, or can be configured separately and 387 referenced by a subscription, in order to facilitate reuse of 388 complex filters. 390 The subscription data model is specified as part of the YANG data 391 model described later in this specification. Specifically, the 392 subscription parameters are defined in the "subscription-info" 393 grouping. It is conceivable that additional subscription parameters 394 might be added in the future. This can be accomplished through 395 augmentation of the subscription data model. 397 3.2. Negotiation of Subscription Policies 399 A subscription rejection can be caused by the inability of the server 400 to provide a stream with the requested semantics. For example, a 401 server may not be able to support "on-change" updates for operational 402 data, or only support them for a limited set of data nodes. 403 Likewise, a server may not be able to support a requested updated 404 frequency, or a requested encoding. 406 Yang-push supports a simple negotiation between clients and servers 407 for subscription parameters. The negotiation is limited to a single 408 pair of subscription request and response. For negative responses, 409 the server SHOULD include in the returned error what subscription 410 parameters would have been accepted for the request. The returned 411 acceptable parameters constitute suggestions that, when followed, 412 increase the likelihood of success for subsequent requests. However, 413 they are no guarantee that subsequent requests for this client or 414 others will in fact be accepted. 416 In case a subscriber requests an encoding other than XML, and this 417 encoding is not supported by the server, the server simply indicates 418 in the response that the encoding is not supported. 420 3.3. On-Change Considerations 422 On-change subscriptions allow clients to subscribe to updates 423 whenever changes to objects occur. As such, on-change subscriptions 424 are of particular interest for data that changes relatively 425 infrequently, yet that require applications to be notified with 426 minimal delay when changes do occur. 428 On-change subscriptions tend to be more difficult to implement than 429 periodic subscriptions. Specifically, on-change subscriptions may 430 involve a notion of state to see if a change occurred between past 431 and current state, or the ability to tap into changes as they occur 432 in the underlying system. Accordingly, on-change subscriptions may 433 not be supported by all implementations or for every object. 435 When an on-change subscription is requested for a datastream with a 436 given subtree filter, where not all objects support on-change update 437 triggers, the subscription request MUST be rejected. As a result, 438 on-change subscription requests will tend to be directed at very 439 specific, targeted subtrees with only few objects. 441 Any updates for an on-change subscription will include only objects 442 for which a change was detected. To avoid flooding clients with 443 repeated updates for fast-changing objects, or objects with 444 oscillating values, an on-change subscription allows for the 445 definition of a dampening period. Once an update for a given object 446 is sent, no other updates for this particular object are sent until 447 the end of the dampening period. In addition, updates include 448 information about objects that were deleted and ones that were newly 449 created. 451 On-change subscriptions can be refined to let users subscribe only to 452 certain types of changes, for example, only to object creations and 453 deletions, but not to modifications of object values. 455 Additional refinements are conceivable. For example, in order to 456 avoid sending updates on objects whose values undergo only a 457 negligible change, additional parameters might be added to an on- 458 change subscription specifying a policy that states how large or 459 "significant" a change has to be before an update is sent. A simple 460 policy is a "delta-policy" that states, for integer-valued data 461 nodes, the minimum difference between the current value and the value 462 that was last reported that triggers an update. Also more 463 sophisticated policies are conceivable, such as policies specified in 464 percentage terms or policies that take into account the rate of 465 change. While not specified as part of this draft, such policies can 466 be accommodated by augmenting the subscription data model 467 accordingly. 469 3.4. Data Encodings 471 Subscribed data is encoded in either XML or JSON format. A server 472 MUST support XML encoding and MAY support JSON encoding. 474 It is conceivable that additional encodings may be supported as 475 options in the future. This can be accomplished by augmenting the 476 subscription data model with additional identity statements used to 477 refer to requested encodings. 479 3.4.1. Periodic Subscriptions 481 In a periodic subscription, the data included as part of an update 482 corresponds to data that could have been simply retrieved using a get 483 operation and is encoded in the same way. XML encoding rules for 484 data nodes are defined in [RFC6020]. JSON encoding rules are defined 485 in [I-D.ietf-netmod-yang-json]. This encoding is valid JSON, but 486 also has special encoding rules to identify module namespaces and 487 provide consistent type processing of YANG data. 489 3.4.2. On-Change Subscriptions 491 In an on-change subscription, updates need to allow to differentiate 492 between data nodes that were newly created since the last update, 493 data nodes that were deleted, and data nodes whose value changed. 495 XML encoding rules correspond to how data would be encoded in input 496 to Netconf edit-config operations as specified in [RFC6241] section 497 7.2, adding "operation" attributes to elements in the data subtree. 498 Specifically, the following values will be utilized: 500 o create: The data identified by the element has been added since 501 the last update. 503 o delete: The data identified by the element has been deleted since 504 the last update. 506 o merge: The data identified by the element has been changed since 507 the last update. 509 o replace: The data identified by the element has been replaced with 510 the update contents since the last update. 512 The remove value will not be utilized. 514 Contrary to edit-config operations, the data is sent from the server 515 to the client, not from the client to the server, and will not be 516 restricted to configuration data. 518 JSON encoding rules are roughly analogous to how data would be 519 encoded in input to a YANG-patch operation, as specified in 520 [I-D.ietf-netconf-yang-patch] section 2.2. However, no edit-ids will 521 be needed. Specifically, changes will be grouped under respective 522 "operation" containers for creations, deletions, and modifications. 524 3.5. Subscription Filters 526 Subscriptions can specify filters for subscribed data. The following 527 filters are supported: 529 o subtree-filter: A subtree filter specifies a subtree that the 530 subscription refers to. When specified, updates will only concern 531 data nodes from this subtree. Syntax and semantics correspond to 532 that specified for [RFC6241] section 6. 534 o xpath-filter: An XPath filter specifies an XPath expression 535 applied to the data in an update, assuming XML-encoded data. 537 If multiple subscription filters are specified, all of them are 538 applied. In other words, it is possible to (for example) apply an 539 XPath filter on top of a subtree filter. 541 It is conceivable for implementations to support other filters. For 542 example, an on-change filter might specify that changes in values 543 should be sent only when the magnitude of the change since previous 544 updates exceeds a certain threshold. It is possible to augment the 545 subscription data model with additional filter types. 547 3.6. Push Data Stream and Transport Mapping 549 Pushing data based on a subscription could be considered analogous to 550 a response to a data retrieval request, e.g. a "get" request. 551 However, contrary to such a request, multiple responses to the same 552 request may get sent over a longer period of time. 554 A more suitable mechanism is therefore that of a notification. 555 Contrary to notifications associated with alarms and unexpected event 556 occurrences, push updates are solicited, i.e. tied to a particular 557 subscription which triggered the notification. (An alternative 558 conceptual model would consider a subscription an "opt-in" filter on 559 a continuous stream of updates.) 561 The notification contains several parameters: 563 o A subscription correlator, referencing the name of the 564 subscription on whose behalf the notification is sent. 566 o A data node that contains a representation of the datastore 567 subtree containing the updates. The subtree is filtered per 568 access control rules to contain only data that the subscriber is 569 authorized to see. Also, depending on the subscription type, 570 i.e., specifically for on-change subscriptions, the subtree 571 contains only the data nodes that contain actual changes. (This 572 can be simply a node of type string or, for XML-based encoding, 573 anyxml.) 575 Notifications are sent using elements as defined in 576 [RFC5277]. Alternative transports are conceivable but outside the 577 scope of this specification. 579 The solution specified in this document uses notifications to 580 communicate datastore updates. The contents of the notification 581 includes a set of explicitly defined data nodes. For this purpose, 582 two new generic notifications are introduced, "push-update" and 583 "push-change-update". Both notifications are used to define how to 584 carry data records with updates of datastore contents as specified by 585 a subscription. 587 Push-update notification defines updates for a periodic subscription, 588 as well as for the initial update of an on-change subscription used 589 to synchronize the receiver at the start of a new subscription. The 590 update record contains a data snippet that contains an instantiated 591 subtree with the subscribed contents. The content of the update 592 record is equivalent to the contents that would be obtained had the 593 same data been explicitly retrieved using e.g. a Netconf "get"- 594 operation, with the same filters applied. 596 The contents of the notification conceptually represents the union of 597 all data nodes in the yang modules supported by the server. However, 598 in a YANG data model, it is not practical to model the precise data 599 contained in the updates as part of the notification. This is 600 because the specific data nodes supported depend on the implementing 601 system and may even vary dynamically. Therefore, to capture this 602 data, a single parameter that can represent any datastore contents is 603 used, not parameters that represent data nodes one at a time. 605 Push-change-update notification defines updates for on-change 606 subscriptions. The update record here contains a data snippet that 607 indicates the changes that data nodes have undergone, i.e. that 608 indicates which data nodes have been created, deleted, or had changes 609 to their values. The format follows the same format that operations 610 that apply changes to a data tree would apply, indicating the 611 creates, deletes, and modifications of data nodes. 613 The following is an example of push notification. It contains an 614 update for subscription my-sub, including a subtree with root foo 615 that contains a leaf, bar: 617 618 620 622 my-sub 623 624 2015-03-09T19:14:56Z 625 627 628 some_string 629 630 631 633 Figure 1: Push example 635 The following is an example of an on-change notification. It 636 contains an update for subscription my-on-change-sub, including a new 637 value for a leaf called beta, which is a child of a top-level 638 container called alpha: 640 641 643 645 my-on-change-sub 646 647 2015-10-13T12:13:02Z 648 650 651 1500 652 653 654 656 Figure 2: Push example for on change 658 The equivalent update when requesting json encoding: 660 661 663 665 my-on-change-sub 666 667 2015-10-13T12:13:02Z 668 670 { 671 "ietf-yang-patch:yang-patch": { 672 "patch-id": [ 673 null 674 ], 675 "edit": [ 676 { 677 "edit-id": "edit1", 678 "operation": "merge", 679 "target": "/alpha/beta", 680 "value": { 681 "beta": 1500 682 } 683 } 684 ] 685 } 686 } 687 688 690 Figure 3: Push example for on change with JSON 692 When the beta leaf is deleted, the server may send 693 694 696 698 my-on-change-sub 699 700 2015-10-13T12:13:02Z 701 703 704 705 706 707 709 Figure 4: 2nd push example for on change update 711 3.7. Subscription management 713 There are two ways in which subscriptions can be managed: RPC-based, 714 and configuration based. 716 3.7.1. Subscription management by RPC 718 RPC-based subscription allows a subscriber to create a subscription 719 via an RPC call. The subscriber and the receiver are the same 720 entity, i.e. a subscriber cannot subscribe or in other ways interfere 721 with a subscription on another receiver's behalf. The lifecycle of 722 the subscription is dependent on the lifecyle of the transport 723 session over which the subscription was requested. For example, when 724 a Netconf session over which a subscription was created is torn down, 725 the subscription is automatically terminated (and needs to be re- 726 initiated when a new session is established). Alternatively, a 727 subscriber can also decide to delete a subscription via another RPC. 729 When a create-subscription request is successful, the subscription 730 identifier of the freshly created subscription is returned. 732 A subscription can be rejected for multiple reasons, including the 733 lack of authorization to create a subscription, the lack of read 734 authorization on the requested data node, or the inability of the 735 server to provide a stream with the requested semantics. Rejections 736 trigger the generation of an rpc-reply with an rpc-error element, 737 which indicates why the subscription was rejected and, possibly, 738 negotiation information to facilitate the generation of subscription 739 requests that can be served. The contents of the rpc-error element 740 follow the specification in [RFC6241]. Datastore-push-specific 741 content is included under . When the requester is not 742 authorized to read the requested data node, the returned 743 indicates an authorization error and the requested node. For 744 instance, for the following request: 746 748 750 push-update 751 754 755 500 756 757 759 encode-xml 760 761 762 764 Figure 5: Create-Subscription example 766 the server may return: 768 770 771 application 772 access-denied 773 error 774 775 777 /ex:foo 778 779 780 781 783 Figure 6: Error response example 785 When the requester is not authorized to execute a subscription 786 request, no element should be included in the response. 788 3.7.2. Subscription management by configuration 790 Configuration-based subscription allows a subscription to be 791 established as part of a server's configuration. This allows to 792 persist subscriptions. As part of a configured subscription, a 793 receiver needs to be specified. It is thus possible to have a 794 different system acting as subscriber (the client creating the 795 subscription) and as receiver (the client receiving the updates). 797 3.8. Other considerations 799 3.8.1. Authorization 801 A receiver of subscription data may only be sent updates for which 802 they have proper authorization. Data that is being pushed therefore 803 needs to be subjected to a filter that applies all corresponding 804 rules applicable at the time of a specific pushed update, removing 805 any non-authorized data as applicable. 807 The authorization model for data in YANG datastores is described in 808 the Netconf Access Control Model [RFC6536]. However, some 809 clarifications to that RFC are needed so that the desired access 810 control behavior is applied to pushed updates. 812 One of these clarifications is that a subscription may only be 813 established if the Receiver has read access to the target data node. 815 +-------------+ +-------------+ 816 subscription | protocol | | target | 817 request --> | operation | -------------> | data node | 818 | allowed? | datastore | access | 819 +-------------+ or state | allowed? | 820 data access +-------------+ 822 Figure 7: Access control for subscription 824 Likewise if a receiver no longer has read access permission to a 825 target data node, the subscription must be abnormally terminated 826 (with loss of access permission as the reason provided). 828 Another clarification to [RFC6536] is that each of the individual 829 nodes in a pushed update must also go through access control 830 filtering. This includes new nodes added since the last push update, 831 as well as existing nodes. For each of these read access must be 832 verified. The methods of doing this efficiently are left to 833 implementation. 835 +-------------+ +-------------------+ 836 subscription | data node | yes | | 837 update --> | access | ---> | add data node | 838 | allowed? | | to update message | 839 +-------------+ +-------------------+ 841 Figure 8: Access control for push updates 843 If there are read access control changes applied under the target 844 node, no notifications indicating the fact that this has occurred 845 need to be provided. 847 3.8.2. Additional subscription primitives 849 Other possible operations include the ability for a Subscriber to 850 request the suspension/resumption of a Subscription with a Publisher. 851 However, subscriber driven suspension is not viewed as essential at 852 this time, as a simpler alternative is to remove a subscription and 853 recreate it when needed. 855 It should be noted that this does not affect the ability of the 856 Publisher to suspend a subscription. This can occur in cases the 857 server is not able to serve the subscription for a certain period of 858 time, and indicated by a corresponding notification. 860 3.8.3. Robustness and reliability considerations 862 Particularly in the case of on-change push updates, it is important 863 that push updates do not get lost. However, datastore-push uses a 864 secure and reliable transport. Notifications are not getting 865 reordered, and in addition contain a time stamp. For those reasons, 866 we believe that additional reliability mechanisms at the application 867 level, such as sequence numbers for push updates, are not required. 869 3.8.4. Update size and fragmentation considerations 871 Depending on the subscription, the volume of updates can become quite 872 large. There is no inherent limitation to the amount of data that 873 can be included in a notification. That said, it may not always be 874 practical to send the entire update in a single chunk. 875 Implementations MAY therefore choose, at their discretion, to "chunk" 876 updates and break them out into several update notifications. 878 3.8.5. Additional data streams 880 The conceptual data stream introduced in this specification, 881 datastore-push, includes the entire YANG datastore in its scope. It 882 is conceivable to introduce other data streams with more limited 883 scope, for example: 885 o operdata-push, a datastream containing all operational (read-only) 886 data of a YANG datastore 888 o operdata-nocounts-push, a datastream containing all operational 889 (read-only) data with the exception of counters 891 Those data streams make particular sense for use cases involving 892 service assurance (not relying on operational data), and for use 893 cases requiring on-change update triggers which make no sense to 894 support in conjunction with fast-changing counters. While it is 895 possible to specify subtree filters on datastore-push to the same 896 effect, having those data streams greatly simplifies articulating 897 subscriptions in such scenarios. 899 3.8.6. Implementation considerations 901 Implementation specifics are outside the scope of this specification. 902 That said,it should be noted that monitoring of operational state 903 changes inside a system can be associated with significant 904 implementation challenges. 906 Even periodic retrieval of operational state alone, to be able to 907 push it, can consume considerable system resources. Configuration 908 data may in many cases be persisted in an actual database or a 909 configuration file, where retrieval of the database content or the 910 file itself is reasonably straightforward and computationally 911 inexpensive. However, retrieval of operational data may, depending 912 on the implementation, require invocation of APIs, possibly on an 913 object-by-object basis, possibly involving additional internal 914 interrupts, etc. 916 For those reasons, if is important for an implementation to 917 understand what subscriptions it can or cannot support. It is far 918 preferrable to decline a subscription request, than to accept it only 919 to result in subsequent failure later. 921 Whether or not a subscription can be supported will in general be 922 determined by a combination of several factors, including the 923 subscription policy (on-change or periodic, with on-change in general 924 being the more challenging of the two), the period in which to report 925 changes (1 second periods will consume more resources than 1 hour 926 periods), the amount of data in the subtree that is being subscribed 927 to, and the number and combination of other subscriptions that are 928 concurrently being serviced. 930 When providing access control to every node in a pushed update, it is 931 possible to make and update efficient access control filters for an 932 update. These filters can be set upon subscription and applied 933 against a stream of updates. These filters need only be updated when 934 (a) there is a new node added/removed from the subscribed tree with 935 different permissions than its parent, or (b) read access permissions 936 have been changed on nodes under the target node for the subscriber. 938 4. A YANG data model for management of datastore push subscriptions 940 4.1. Overview 942 The YANG data model for datastore push subscriptions is depicted in 943 the following figure. 945 module: ietf-datastore-push 946 +--ro system-streams 947 | +--ro system-stream* system-stream 948 +--rw filters 949 | +--rw filter* [filter-id] 950 | +--rw filter-id filter-id 951 | +--rw (filter-type)? 952 | +--:(subtree) 953 | | +--rw subtree-filter? subtree-filter 954 | +--:(xpath) 955 | +--rw xpath-filter? yang:xpath1.0 956 +--rw subscription-config 957 | +--rw datastore-push-subscription* [subscription-id] 958 | +--rw subscription-id subscription-id 959 | +--rw target-datastore? datastore 960 | +--rw stream? system-stream 961 | +--rw encoding? encoding 962 | +--rw start-time? yang:date-and-time 963 | +--rw stop-time? yang:date-and-time 964 | +--rw (update-trigger)? 965 | | +--:(periodic) 966 | | | +--rw period? yang:timeticks 967 | | +--:(on-change) 968 | | +--rw no-synch-on-start? empty 969 | | +--rw dampening-period yang:timeticks 970 | | +--rw excluded-change* change-type 971 | +--rw (filterspec)? 972 | | +--:(inline) 973 | | | +--rw (filter-type)? 974 | | | +--:(subtree) 975 | | | | +--rw subtree-filter? subtree-filter 976 | | | +--:(xpath) 977 | | | +--rw xpath-filter? yang:xpath1.0 978 | | +--:(by-reference) 979 | | +--rw filter-ref? filter-ref 980 | +--rw receiver-address 981 | +--rw (push-base-transport)? 982 | +--:(tcpudp) 983 | +--rw tcpudp 984 | +--rw address? inet:host 985 | +--rw port? inet:port-number 986 +--ro subscriptions 987 +--ro datastore-push-subscription* [subscription-id] 988 +--ro subscription-id subscription-id 989 +--ro configured-subscription? empty 990 +--ro subscription-status? identityref 991 +--ro target-datastore? datastore 992 +--ro stream? system-stream 993 +--ro encoding? encoding 994 +--ro start-time? yang:date-and-time 995 +--ro stop-time? yang:date-and-time 996 +--ro (update-trigger)? 997 | +--:(periodic) 998 | | +--ro period? yang:timeticks 999 | +--:(on-change) 1000 | +--ro no-synch-on-start? empty 1001 | +--ro dampening-period yang:timeticks 1002 | +--ro excluded-change* change-type 1003 +--ro (filterspec)? 1004 | +--:(inline) 1005 | | +--ro (filter-type)? 1006 | | +--:(subtree) 1007 | | | +--ro subtree-filter? subtree-filter 1008 | | +--:(xpath) 1009 | | +--ro xpath-filter? yang:xpath1.0 1010 | +--:(by-reference) 1011 | +--ro filter-ref? filter-ref 1012 +--ro receiver-address 1013 +--ro (push-base-transport)? 1014 +--:(tcpudp) 1015 +--ro tcpudp 1016 +--ro address? inet:host 1017 +--ro port? inet:port-number 1019 Figure 9: Model structure 1021 The components of the model are described in the following 1022 subsections. 1024 4.2. System streams 1026 Container "system-streams" is used to indicate which data streams are 1027 provided by the system and can be subscribed to. For this purpose, 1028 it contains a leaf list of data nodes identifying the supported 1029 streams. 1031 4.3. Filters 1033 Container "filters" contains a list of configurable data filters, 1034 each specified in its own list element. This allows users to 1035 configure filters separately from an actual subscription, which can 1036 then be referenced from a subscription. This facilitates the reuse 1037 of filter definitions, which can be important in case of complex 1038 filter conditions. 1040 Two types of filters can be specified as part of a filter list 1041 element. Subtree filters follow syntax and semantics of RFC 6241 and 1042 allow to specify which subtree(s) to subscribe to. In addition, 1043 XPath filters can be specified for more complex filter conditions. 1044 If several filters are specified. When both types of filters are 1045 included, a logical "and" applies. 1047 It is conceivable to introduce other types of filters; in that case, 1048 the data model needs to be augmented accordingly. 1050 4.4. Subscription configuration 1052 Container "subscription-config" allows for the static configuration 1053 of subscriptions, i.e. subscriptions that are created via 1054 configuration as opposed to RPC. Each subscription is represented 1055 through its own list element, including the following components: 1057 o "subscription-id" is an identifier used to refer to the 1058 subscription. 1060 o "target-datastore" is used to refer to the datastore the 1061 subscription refer to. By default, the datastore will always be 1062 "running". 1064 o "stream" refers to the stream being subscribed to. The 1065 subscription model assumes the presence of perpetual and 1066 continuous streams of updates. Various streams are defined: 1067 "push-update" covers the entire set of YANG data in the server. 1068 "operational-push" covers all operational data, while "config- 1069 push" covers all configuration data. Other streams could be 1070 introduced in augmentations to the model by introducing additional 1071 identities. 1073 o "encoding" refers to the encoding requested for the data updates. 1074 By default, updates are encoded using XML. However, JSON can be 1075 requested as an option and other encodings may be supported in the 1076 future. 1078 o "start-time" specifies when the subscription is supposed to start. 1079 The start time also serves as anchor time for periodic 1080 subscriptions (see below). 1082 o "stop-time" specifies a stop time for the subscription. Once the 1083 stop time is reached, the subscription is automatically 1084 terminated. However, even when terminated, the subscription entry 1085 remains part of the configuration unless explicity deleted from 1086 the configuration. It is possible to effectively "resume" a 1087 stopped subscription by reconfiguring the stop time. 1089 o A choice of subscription policies allows to define when to send 1090 new updates - periodic or on change. 1092 * For periodic subscriptions, the trigger is defined by a 1093 "period", a parameter that defines the interval with which 1094 updates are to be pushed. The start time of the subscription 1095 serves as anchor time, defining one specific point in time at 1096 which an update needs to be sent. Update intervals always fall 1097 on the points in time that are a multiple of a period after the 1098 start time. 1100 * For on-change subscriptions, the trigger occurs whenever a 1101 change in the subscribed information is detected. On-change 1102 subscriptions have more complex semantics that is guided by 1103 additional parameters. "dampening-period" specifies the 1104 interval that must pass before a successive update for the same 1105 data node is sent. The first time a change is detected, the 1106 update is sent immediately. If a subsequent change is 1107 detected, another update is only sent once the dampening period 1108 has passed, containing the value of the data node that is then 1109 valid. "excluded-change" allows to restrict the types of 1110 changes for which updates are sent (changes to object values, 1111 object creation or deletion events). "no-synch-on-start" is a 1112 flag that allows to specify whether or not a complete update 1113 with all the subscribed data should be sent at the beginning of 1114 a subscription; if the flag is omitted, a complete update is 1115 sent to facilitate synchronization. It is conceivable to 1116 augment the data model with additional parameters in the future 1117 to specify even more refined policies, such as parameters that 1118 specify the magnitude of a change that must occur before an 1119 update is triggered. 1121 o Filters for a subscription can be specified using a choice, 1122 allowing to either reference a filter that has been separately 1123 configured or entering its definition inline. 1125 o Finally, a receiver for the subscription can be specified. The 1126 receiver does not have to be the same system that configures the 1127 subscription. 1129 It should be noted that a subscription created through configuration 1130 cannot be deleted using an RPC. Likewise, subscriptions created 1131 through RPC cannot be deleted through configuration. 1133 4.5. Subscription monitoring 1135 Subscriptions can be subjected to management themselves. For 1136 example, it is possible that a server may no longer be able to serve 1137 a subscription that it had previously accepted. Perhaps it has run 1138 out of resources, or internal errors may have occurred. When this is 1139 the case, a server needs to be able to temporarily suspend the 1140 subscription, or even to terminate it. More generally, the server 1141 should provide a means by which the status of subscriptions can be 1142 monitored. 1144 Container "subscriptions", contains operational data for all 1145 subscriptions that are currently active. This includes subscriptions 1146 that were created using RPC, as well as subscriptions created as part 1147 of the configuration when current time is between start and stop 1148 time. 1150 Each subscription is represented as a list element "datastore-push- 1151 subscription". The associated information includes an identifier for 1152 the subscription, a subscription status, as well as the various 1153 subscription parameters that are in effect. The subscription status 1154 indicates whether the subscription is currently active and healthy, 1155 or if it is degraded in some form. 1157 Subscriptions are automatically removed from the list once they 1158 expire (reaching stop-time )or are terminated, whether through RPC or 1159 deletion from the configuration. 1161 4.6. Notifications 1163 A server needs to indicate any changes in status of a subscription to 1164 the receiver through a notification. Specifically, subscribers need 1165 to be informed of the following: 1167 o A subscription has been temporarily suspended (including the 1168 reason) 1170 o A subscription (that had been suspended earlier) is once again 1171 operational 1173 o A subscription has been terminated (including the reason) 1175 o A subscription has been modified (including the current set of 1176 subscription parameters in effect) 1178 Finally, a server might provide additional information about 1179 subscriptions, such as statistics about the number of data updates 1180 that were sent. However, such information is currently outside the 1181 scope of this specification. 1183 4.7. RPCs 1185 Yang-push subscriptions are created, modified, and deleted using 1186 three RPCs. 1188 4.7.1. Create-subscription RPC 1190 The subscriber sends a create-subscription RPC with the parameters in 1191 section 3.1. For instance 1193 1195 1197 push-update 1198 1201 1203 500 1204 1205 1207 encode-xml 1208 1209 1210 1212 Figure 10: Create-subscription RPC 1214 The server must respond explicitly positively (i.e., subscription 1215 accepted) or negatively (i.e., subscription rejected) to the request. 1216 Positive responses include the subscription-id of the accepted 1217 subscription. In that case a server may respond: 1219 1221 1222 1224 my-sub 1225 1226 1227 1229 Figure 11: Create-subscription positive RPC response 1231 A subscription can be rejected for multiple reasons, including the 1232 lack of authorization to create a subscription, the lack of read 1233 authorization on the requested data node, or the inability of the 1234 server to provide a stream with the requested semantics. Rejections 1235 trigger the generation of an rpc-reply with an rpc-error element, 1236 which indicates why the subscription was rejected and, possibly, 1237 negotiation information to facilitate the generation of subscription 1238 requests that can be served. The contents of the rpc-error element 1239 follow the specification in [RFC6241]. Datastore-push-specific 1240 content is included under . 1242 When the requester is not authorized to read the requested data node, 1243 the returned indicates an authorization error and the 1244 requested node. For instance, if the above request was unauthorized 1245 to read node "ex:foo" the server may return: 1247 1249 1250 application 1251 access-denied 1252 error 1253 1254 1256 /ex:foo 1257 1258 1259 1260 1262 Figure 12: Create-subscription access denied response 1264 When the requester is not authorized to execute a subscription 1265 request, no element should be included in the response. 1267 If a request is rejected because the server is not capable to serve 1268 it, the server SHOULD include in the returned error what request 1269 parameters were not supported and what subscription parameters would 1270 have been accepted for the request. This information is included in 1271 the , which is split into two sections. First, 1272 , which includes the parameters in the 1273 request the server cannot serve. Second , 1274 which constitute suggestions that, when followed; increase the 1275 likelihood of success for subsequent requests. However, they are no 1276 guarantee that subsequent requests for this client or others will in 1277 fact be accepted. 1279 For example, for the following request: 1281 1283 1285 push-update 1286 1289 1291 10 1292 1293 1295 encode-xml 1296 1297 1298 1300 Figure 13: Create-subscription request example 2 1302 A server that cannot serve on-change updates may return the 1303 following: 1305 1307 1308 application 1309 operation-not-supported 1310 error 1311 1312 1314 1317 10 1318 1319 1320 1322 3000 1323 1324 1325 1326 1328 Figure 14: Create-subscription error response example 2 1330 4.7.2. Modify-subscription RPC 1332 The subscriber may send a modify-subscription for a previously 1333 accepted subscription that has not been deleted. The subscriber may 1334 change any subscription parameters by including the new values in the 1335 modifys-subscription rpc. Parameters not included in the rpc should 1336 remain unmodified. For illustration purposes we include an exchange 1337 example where a subscriber modifies the period of the subscription. 1339 1341 1343 push-update 1344 1346 my-sub 1347 1348 1351 1353 500 1354 1355 1357 encode-xml 1358 1359 1360 1362 Figure 15: Modify subscription request 1364 The server must respond explicitly positively (i.e., subscription 1365 accepted) or negatively (i.e., subscription rejected) to the request. 1366 Positive responses include the subscription-id of the accepted 1367 subscription. In that case a server may respond: 1369 1371 1372 1374 my-sub 1375 1376 1377 1379 1381 1383 1385 my-sub 1386 1387 1388 100 1389 1390 1392 encode-xml 1393 1394 1395 1397 1399 1401 my-sub 1402 1403 1405 Figure 16: Modify subscription response 1407 If the subscription modification is rejected, the server must send a 1408 response like it does for a create-subscription and maintain the 1409 subscription as it was before the modification request. A 1410 subscription may be modified multiple times. 1412 4.7.3. Delete-subscription RPC 1414 To stop receiving updates from a subscription and effectively 1415 eliminate the subscription, it can send a delete-subscription RPC, 1416 which takes as only input the subscription-id. For example 1418 1420 1422 1424 my-sub 1425 1426 1427 1429 1431 1432 1434 Figure 17: Delete subscription 1436 5. YANG module 1438 1439 file "ietf-datastore-push@2015-10-15.yang" 1441 module ietf-datastore-push { 1442 namespace "urn:ietf:params:xml:ns:yang:ietf-datastore-push"; 1443 prefix yp; 1445 import ietf-inet-types { 1446 prefix inet; 1447 } 1448 import ietf-yang-types { 1449 prefix yang; 1450 } 1452 organization "IETF"; 1453 contact 1454 "WG Web: 1455 WG List: 1457 WG Chair: Mahesh Jethanandani 1458 1460 WG Chair: Mehmet Ersue 1461 1463 Editor: Alexander Clemm 1464 1466 Editor: Alberto Gonzalez Prieto 1467 1469 Editor: Eric Voit 1470 "; 1471 description 1472 "This module contains conceptual YANG specifications 1473 for datastore push."; 1475 revision 2015-10-15 { 1476 description 1477 "Initial revision."; 1478 reference 1479 "YANG Datastore Push, draft-ietf-netconf-yang-push-00"; 1480 } 1482 feature on-change { 1483 description 1484 "This feature indicates that on-change updates are supported."; 1485 } 1487 feature json { 1488 description 1489 "This feature indicates that JSON encoding of push updates is 1490 supported."; 1491 } 1493 identity subscription-stream-status { 1494 description 1495 "Base identity for the status of subscriptions and 1496 datastreams."; 1497 } 1499 identity active { 1500 base subscription-stream-status; 1501 description 1502 "Status is active and healthy."; 1503 } 1505 identity inactive { 1506 base subscription-stream-status; 1507 description 1508 "Status is inactive, for example outside the 1509 interval between start time and stop time."; 1510 } 1512 identity in-error { 1513 base subscription-stream-status; 1514 description 1515 "The status is in error or degraded, meaning that 1516 stream and/or subscription are currently unable to provide 1517 the negotiated updates."; 1518 } 1520 identity subscription-errors { 1521 description 1522 "Base identity for subscription errors."; 1523 } 1525 identity internal-error { 1526 base subscription-errors; 1527 description 1528 "Subscription failures caused by server internal error."; 1529 } 1531 identity no-resources { 1532 base subscription-errors; 1533 description 1534 "Lack of resources, e.g. CPU, memory, bandwidth"; 1535 } 1537 identity subscription-deleted { 1538 base subscription-errors; 1539 description 1540 "The subscription was terminated because the subscription 1541 was deleted."; 1542 } 1544 identity other { 1545 base subscription-errors; 1546 description 1547 "Fallback reason - any other reason"; 1548 } 1550 identity encodings { 1551 description 1552 "Base identity to represent data encodings"; 1553 } 1555 identity encode-xml { 1556 base encodings; 1557 description 1558 "Encode data using XML"; 1559 } 1561 identity encode-json { 1562 base encodings; 1563 description 1564 "Encode data using JSON"; 1565 } 1567 identity system-streams { 1568 description 1569 "Base identity to represent a conceptual system-provided 1570 datastream of datastore updates with predefined semantics."; 1571 } 1573 identity datastore-push { 1574 base system-streams; 1575 description 1576 "A conceptual datastream consisting of all datastore 1577 updates, including operational and configuration data."; 1578 } 1580 identity operational-push { 1581 base system-streams; 1582 description 1583 "A conceptual datastream consisting of updates of all 1584 operational data."; 1585 } 1587 identity config-push { 1588 base system-streams; 1589 description 1590 "A conceptual datastream consisting of updates of all 1591 configuration data."; 1592 } 1594 identity datastore { 1595 description 1596 "An identity that represents a datastore."; 1597 } 1599 identity running { 1600 base datastore; 1601 description 1602 "Designates the running datastore"; 1603 } 1604 identity startup { 1605 base datastore; 1606 description 1607 "Designates the startup datastore"; 1608 } 1610 typedef datastore-contents-xml { 1611 type string; 1612 description 1613 "This type is be used to represent datastore contents, 1614 i.e. a set of data nodes with their values, in XML. 1615 The syntax corresponds to the syntax of the data payload 1616 returned in a corresponding Netconf get operation with the 1617 same filter parameters applied."; 1618 reference "RFC 6241 section 7.7"; 1619 } 1621 typedef datastore-changes-xml { 1622 type string; 1623 description 1624 "This type is used to represent a set of changes in a 1625 datastore encoded in XML, indicating for datanodes whether 1626 they have been created, deleted, or updated. The syntax 1627 corresponds to the syntax used to when editing a 1628 datastore using the edit-config operation in Netconf."; 1629 reference "RFC 6241 section 7.2"; 1630 } 1632 typedef datastore-contents-json { 1633 type string; 1634 description 1635 "This type is be used to represent datastore contents, 1636 i.e. a set of data nodes with their values, in JSON. 1637 The syntax corresponds to the syntax of the data 1638 payload returned in a corresponding RESTCONF get 1639 operation with the same filter parameters applied."; 1640 reference "RESTCONF Protocol"; 1641 } 1643 typedef datastore-changes-json { 1644 type string; 1645 description 1646 "This type is used to represent a set of changes in a 1647 datastore encoded in JSON, indicating for datanodes whether 1648 they have been created, deleted, or updated. The syntax 1649 corresponds to the syntax used to patch a datastore 1650 using the yang-patch operation with Restconf."; 1651 reference "draft-ietf-netconf-yang-patch"; 1653 } 1655 typedef filter-id { 1656 type string; 1657 description 1658 "This type defines an identifier for a filter."; 1659 } 1661 typedef subtree-filter { 1662 type string; 1663 description 1664 "This type is used to specify the subtree that the 1665 subscription refers to. Its syntax follows the subtree 1666 filter syntax specified for Netconf in RFC 6241, 1667 section 6."; 1668 reference "RFC 6241 section 6"; 1669 } 1671 typedef datastore { 1672 type identityref { 1673 base datastore; 1674 } 1675 description 1676 "Used to refer to a datastore, for example, to running"; 1677 } 1679 typedef subscription-id { 1680 type string { 1681 length "1 .. max"; 1682 } 1683 description 1684 "A client-provided identifier for the subscription."; 1685 } 1687 typedef subscription-term-reason { 1688 type identityref { 1689 base subscription-errors; 1690 } 1691 description 1692 "Reason for a server to terminate a subscription."; 1693 } 1695 typedef subscription-susp-reason { 1696 type identityref { 1697 base subscription-errors; 1698 } 1699 description 1700 "Reason for a server to suspend a subscription."; 1702 } 1704 typedef encoding { 1705 type identityref { 1706 base encodings; 1707 } 1708 description 1709 "Specifies a data encoding, e.g. for a data subscription."; 1710 } 1712 typedef change-type { 1713 type enumeration { 1714 enum "create" { 1715 description 1716 "A new data node was created"; 1717 } 1718 enum "delete" { 1719 description 1720 "A data node was deleted"; 1721 } 1722 enum "modify" { 1723 description 1724 "The value of a data node has changed"; 1725 } 1726 } 1727 description 1728 "Specifies different types of changes that may occur 1729 to a datastore."; 1730 } 1732 typedef system-stream { 1733 type identityref { 1734 base system-streams; 1735 } 1736 description 1737 "Specifies a system-provided datastream."; 1738 } 1740 typedef filter-ref { 1741 type leafref { 1742 path "/yp:filters/yp:filter/yp:filter-id"; 1743 } 1744 description 1745 "This type is used to reference a yang push filter."; 1746 } 1748 grouping datatree-filter { 1749 description 1750 "This grouping defines filters for a datastore tree."; 1751 choice filter-type { 1752 description 1753 "A filter needs to be a single filter of a given type. 1754 Mixing and matching of multiple filters does not occur 1755 at the level of this grouping."; 1756 case subtree { 1757 description 1758 "Subtree filter"; 1759 leaf subtree-filter { 1760 type subtree-filter; 1761 description 1762 "Datastore subtree of interest."; 1763 } 1764 } 1765 case xpath { 1766 description 1767 "XPath filter"; 1768 leaf xpath-filter { 1769 type yang:xpath1.0; 1770 description 1771 "Xpath defining the data items of interest."; 1772 } 1773 } 1774 } 1775 } 1777 grouping subscription-info { 1778 description 1779 "This grouping describes basic information concerning a 1780 subscription."; 1781 leaf target-datastore { 1782 type datastore; 1783 default "running"; 1784 description 1785 "The datastore that is the target of the subscription. 1786 If not specified, running applies."; 1787 } 1788 leaf stream { 1789 type system-stream; 1790 default "datastore-push"; 1791 description 1792 "The name of the stream subscribed to."; 1793 } 1794 leaf encoding { 1795 type encoding; 1796 default "encode-xml"; 1797 description 1798 "The type of encoding for the subscribed data. 1799 Default is XML"; 1800 } 1801 leaf start-time { 1802 type yang:date-and-time; 1803 description 1804 "Designates the time at which a subscription is supposed 1805 to start, or immediately, in case the start-time is in 1806 the past. For periodic subscription, the start time also 1807 serves as anchor time from which the time of the next 1808 update is computed. The next update will take place at the 1809 next period interval from the anchor time. 1810 For example, for an anchor time at the top of a minute 1811 and a period interval of a minute, the next update will 1812 be sent at the top of the next minute."; 1813 } 1814 leaf stop-time { 1815 type yang:date-and-time; 1816 description 1817 "Designates the time at which a subscription will end. 1818 When a subscription reaches its stop time, it will be 1819 automatically deleted."; 1820 } 1821 choice update-trigger { 1822 description 1823 "Defines necessary conditions for sending an event to 1824 the subscriber."; 1825 case periodic { 1826 description 1827 "The agent is requested to notify periodically the 1828 current values of the datastore or the subset 1829 defined by the filter."; 1830 leaf period { 1831 type yang:timeticks; 1832 description 1833 "Elapsed time between notifications."; 1834 } 1835 } 1836 case on-change { 1837 description 1838 "The agent is requested to notify changes in 1839 values in the datastore or a subset of it defined 1840 by a filter."; 1841 leaf no-synch-on-start { 1842 type empty; 1843 description 1844 "This leaf acts as a flag that determines behavior at the 1845 start of the subscription. When present, 1846 synchronization of state at the beginning of the 1847 subscription is outside the scope of the subscription. 1848 Only updates about changes that are observed from the 1849 start time, i.e. only push-change-update notifications 1850 are sent. 1851 When absent (default behavior), in order to facilitate 1852 a receiver's synchronization, a full update is sent 1853 when the subscription starts using a push-update 1854 notification, just like in the case of a periodic 1855 subscription. After that, push-change-update 1856 notifications are sent."; 1857 } 1858 leaf dampening-period { 1859 type yang:timeticks; 1860 mandatory true; 1861 description 1862 "Minimum amount of time that needs to have 1863 passed since the last time an update was 1864 provided."; 1865 } 1866 leaf-list excluded-change { 1867 type change-type; 1868 description 1869 "Use to restrict which changes trigger an update. 1870 For example, if modify is excluded, only creation and 1871 deletion of objects is reported."; 1872 } 1873 } 1874 } 1875 choice filterspec { 1876 description 1877 "Filter can be specified in-line, as part of the 1878 subscription, or configured separately and referenced 1879 here. If no filter is specified, the entire datatree 1880 is of interest."; 1881 case inline { 1882 description 1883 "Filter is defined as part of the subscription."; 1884 uses datatree-filter; 1885 } 1886 case by-reference { 1887 description 1888 "Incorporate a filter that has been configured 1889 separately."; 1890 leaf filter-ref { 1891 type filter-ref; 1892 description 1893 "References the filter to incorporate for the 1894 subscription."; 1895 } 1896 } 1897 } 1898 } 1900 grouping receiver-info { 1901 description 1902 "Defines a reusable snippet that defines the address of the 1903 intended receiver of push updates for a subscription."; 1904 container receiver-address { 1905 description 1906 "This container contains the address information of the 1907 receiver."; 1908 choice push-base-transport { 1909 description 1910 "This choice can be augmented with different options, 1911 depending on the transport underlying the push 1912 transport."; 1913 case tcpudp { 1914 description 1915 "For Netconf and Restconf, TCP is the base transport."; 1916 container tcpudp { 1917 description 1918 "Contains TCP / UDP addressing information"; 1919 leaf address { 1920 type inet:host; 1921 description 1922 "The leaf uniquely specifies the address of the 1923 remote host. One of the following must be 1924 specified: an ipv4 address, an ipv6 address, 1925 or a host name."; 1926 } 1927 leaf port { 1928 type inet:port-number; 1929 description 1930 "This leaf specifies the port number used to 1931 deliver messages to the remote server."; 1932 } 1933 } 1934 } 1935 } 1936 } 1937 } 1939 rpc create-subscription { 1940 description 1941 "This RPC allows a subscriber to create a subscription 1942 on its own behalf. If successful, the subscription 1943 remains in effect for the duration of the subscriber's 1944 association with the publisher, or until the subscription 1945 is terminated by virtue of a delete-subscription request."; 1946 input { 1947 uses subscription-info; 1948 } 1949 output { 1950 leaf subscription-id { 1951 type subscription-id; 1952 description 1953 "Identifier used for this subscription."; 1954 } 1955 } 1956 } 1957 rpc modify-subscription { 1958 description 1959 "This RPC allows a subscriber to modify a subscription 1960 that was previously created using create-subscription. 1961 If successful, the subscription 1962 remains in effect for the duration of the subscriber's 1963 association with the publisher, or until the subscription 1964 is terminated by virtue of a delete-subscription request."; 1965 input { 1966 leaf subscription-id { 1967 type subscription-id; 1968 description 1969 "Identifier to use for this subscription."; 1970 } 1971 } 1972 } 1973 rpc delete-subscription { 1974 description 1975 "This RPC allows a subscriber to delete a subscription that 1976 was previously created using create-subscription."; 1977 input { 1978 leaf subscription-id { 1979 type subscription-id; 1980 description 1981 "Identifier of the subscription that is to be deleted. 1982 Only subscriptions that were created using 1983 create-subscription can be deleted via this RPC."; 1984 } 1985 } 1986 } 1987 notification push-update { 1988 description 1989 "This notification contains a periodic push update. 1991 This notification shall only be sent to receivers 1992 of a subscription; it does not constitute a general-purpose 1993 notification."; 1994 leaf subscription-id { 1995 type subscription-id; 1996 mandatory true; 1997 description 1998 "This references the subscription because of which the 1999 notification is sent."; 2000 } 2001 leaf time-of-update { 2002 type yang:date-and-time; 2003 description 2004 "This leaf contains the time of the update."; 2005 } 2006 choice encoding { 2007 description 2008 "Distinguish between the proper encoding that was specified 2009 for the subscription"; 2010 case encode-xml { 2011 description 2012 "XML encoding"; 2013 leaf datastore-contents-xml { 2014 type datastore-contents-xml; 2015 description 2016 "This contains data encoded in XML, 2017 per the subscription."; 2018 } 2019 } 2020 case encode-json { 2021 if-feature json; 2022 description 2023 "JSON encoding"; 2024 leaf datastore-contents-json { 2025 type datastore-contents-json; 2026 description 2027 "This leaf contains data encoded in JSON, 2028 per the subscription."; 2029 } 2030 } 2031 } 2032 } 2033 notification push-change-update { 2034 description 2035 "This notification contains an on-change push update. 2036 This notification shall only be sent to the receivers 2037 of a subscription; it does not constitute a general-purpose 2038 notification."; 2040 leaf subscription-id { 2041 type subscription-id; 2042 mandatory true; 2043 description 2044 "This references the subscription because of which the 2045 notification is sent."; 2046 } 2047 leaf time-of-update { 2048 type yang:date-and-time; 2049 description 2050 "This leaf contains the time of the update, i.e. the 2051 time at which the change was observed."; 2052 } 2053 choice encoding { 2054 description 2055 "Distinguish between the proper encoding that was specified 2056 for the subscription"; 2057 case encode-xml { 2058 description 2059 "XML encoding"; 2060 leaf datastore-changes-xml { 2061 type datastore-changes-xml; 2062 description 2063 "This contains datastore contents that has changed 2064 since the previous update, per the terms of the 2065 subscription. Changes are encoded analogous to 2066 the syntax of a corresponding Netconf edit-config 2067 operation."; 2068 } 2069 } 2070 case encode-json { 2071 if-feature json; 2072 description 2073 "JSON encoding"; 2074 leaf datastore-changes-yang { 2075 type datastore-changes-json; 2076 description 2077 "This contains datastore contents that has changed 2078 since the previous update, per the terms of the 2079 subscription. Changes are encoded analogous 2080 to the syntax of a corresponding RESTCONF yang-patch 2081 operation."; 2082 } 2083 } 2084 } 2085 } 2086 notification subscription-started { 2087 description 2088 "This notification indicates that a subscription has 2089 started and data updates are beginning to be sent. 2090 This notification shall only be sent to receivers 2091 of a subscription; it does not constitute a general-purpose 2092 notification."; 2093 leaf subscription-id { 2094 type subscription-id; 2095 mandatory true; 2096 description 2097 "This references the affected subscription."; 2098 } 2099 uses subscription-info; 2100 } 2101 notification subscription-suspended { 2102 description 2103 "This notification indicates that a suspension of the 2104 subscription by the server has occurred. No further 2105 datastore updates will be sent until subscription 2106 resumes. 2107 This notification shall only be sent to receivers 2108 of a subscription; it does not constitute a general-purpose 2109 notification."; 2110 leaf subscription-id { 2111 type subscription-id; 2112 mandatory true; 2113 description 2114 "This references the affected subscription."; 2115 } 2116 leaf reason { 2117 type subscription-susp-reason; 2118 description 2119 "Provides a reason for why the subscription was 2120 suspended."; 2121 } 2122 } 2123 notification subscription-resumed { 2124 description 2125 "This notification indicates that a subscription that had 2126 previously been suspended has resumed. Datastore updates 2127 will once again be sent."; 2128 leaf subscription-id { 2129 type subscription-id; 2130 mandatory true; 2131 description 2132 "This references the affected subscription."; 2133 } 2134 } 2135 notification subscription-modified { 2136 description 2137 "This notification indicates that a subscription has 2138 been modified. Datastore updates sent from this point 2139 on will conform to the modified terms of the 2140 subscription."; 2141 leaf subscription-id { 2142 type subscription-id; 2143 mandatory true; 2144 description 2145 "This references the affected subscription."; 2146 } 2147 uses subscription-info; 2148 } 2149 notification subscription-terminated { 2150 description 2151 "This notification indicates that a subscription has been 2152 terminated."; 2153 leaf subscription-id { 2154 type subscription-id; 2155 mandatory true; 2156 description 2157 "This references the affected subscription."; 2158 } 2159 leaf reason { 2160 type subscription-term-reason; 2161 description 2162 "Provides a reason for why the subscription was 2163 terminated."; 2164 } 2165 } 2166 container system-streams { 2167 config false; 2168 description 2169 "This container contains a leaf list of built-in 2170 streams that are provided by the system."; 2171 leaf-list system-stream { 2172 type system-stream; 2173 description 2174 "Identifies a built-in stream that is supported by the 2175 system. Streams are associated with their own identities, 2176 each of which carries a special semantics."; 2177 } 2178 } 2179 container filters { 2180 description 2181 "This container contains a list of configurable filters 2182 that can be applied to subscriptions. This facilitates 2183 the reuse of complex filters once defined."; 2185 list filter { 2186 key "filter-id"; 2187 description 2188 "A list of configurable filters that can be applied to 2189 subscriptions."; 2190 leaf filter-id { 2191 type filter-id; 2192 description 2193 "An identifier to differentiate between filters."; 2194 } 2195 uses datatree-filter; 2196 } 2197 } 2198 container subscription-config { 2199 description 2200 "Contains the list of subscriptions that are configured, 2201 as opposed to established via RPC or other means."; 2202 list datastore-push-subscription { 2203 key "subscription-id"; 2204 description 2205 "Content of a yang-push subscription."; 2206 leaf subscription-id { 2207 type subscription-id; 2208 description 2209 "Identifier to use for this subscription."; 2210 } 2211 uses subscription-info; 2212 uses receiver-info; 2213 } 2214 } 2215 container subscriptions { 2216 config false; 2217 description 2218 "Contains the list of currently active subscriptions, 2219 i.e. subscriptions that are currently in effect, 2220 used for subscription management and monitoring purposes. 2221 This includes subscriptions that have been setup via RPC 2222 primitives, e.g. create-subscription, delete-subscription, 2223 and modify-subscription, as well as subscriptions that 2224 have been established via configuration."; 2225 list datastore-push-subscription { 2226 key "subscription-id"; 2227 config false; 2228 description 2229 "Content of a yang-push subscription. 2230 Subscriptions can be created using a control channel 2231 or RPC, or be established through configuration."; 2232 leaf subscription-id { 2233 type subscription-id; 2234 description 2235 "Identifier of this subscription."; 2236 } 2237 leaf configured-subscription { 2238 type empty; 2239 description 2240 "The presence of this leaf indicates that the 2241 subscription originated from configuration, not through 2242 a control channel or RPC."; 2243 } 2244 leaf subscription-status { 2245 type identityref { 2246 base subscription-stream-status; 2247 } 2248 description 2249 "The status of the subscription."; 2250 } 2251 uses subscription-info; 2252 uses receiver-info; 2253 } 2254 } 2255 } 2256 2258 6. Security Considerations 2260 Subscriptions could be used to attempt to overload servers of YANG 2261 datastores. For this reason, it is important that the server has the 2262 ability to decline a subscription request if it would deplete its 2263 resources. In addition, a server needs to be able to suspend an 2264 existing subscription when needed. When this occur, the subscription 2265 status is updated accordingly and the clients are notified. 2266 Likewise, requests for subscriptions need to be properly authorized. 2268 A subscription could be used to retrieve data in subtrees that a 2269 client has not authorized access to. Therefore it is important that 2270 data pushed based on subscriptions is authorized in the same way that 2271 regular data retrieval operations are. Data being pushed to a client 2272 needs therefore to be filtered accordingly, just like if the data 2273 were being retrieved on-demand. The Netconf Authorization Control 2274 Model applies. 2276 A subscription could be configured on another receiver's behalf, with 2277 the goal of flooding that receiver with updates. One or more 2278 publishers could be used to overwhelm a receiver which doesn't even 2279 support subscriptions. Clients which do not want pushed data need 2280 only terminate or refuse any transport sessions from the publisher. 2282 7. Acknowledgments 2284 We wish to acknowledge the helpful contributions, comments, and 2285 suggestions that were received from Ambika Prasad Tripathy and Einar 2286 Nilsen-Nygaard. 2288 8. References 2290 8.1. Normative References 2292 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 2293 "Simple Network Management Protocol (SNMP)", RFC 1157, 2294 DOI 10.17487/RFC1157, May 1990, 2295 . 2297 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2298 Notifications", RFC 5277, July 2008. 2300 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2301 the Network Configuration Protocol (NETCONF)", RFC 6020, 2302 DOI 10.17487/RFC6020, October 2010, 2303 . 2305 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2306 and A. Bierman, Ed., "Network Configuration Protocol 2307 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2308 . 2310 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 2311 Base Notifications", RFC 5277, February 2012. 2313 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2314 Protocol (NETCONF) Access Control Model", RFC 6536, 2315 DOI 10.17487/RFC6536, March 2012, 2316 . 2318 8.2. Informative References 2320 [I-D.clemm-netmod-mount] 2321 Clemm, A., Medved, J., and E. Voit, "Mounting YANG-defined 2322 information from remote datastores", draft-clemm-netmod- 2323 mount-03 (work in progress), April 2015. 2325 [I-D.i2rs-pub-sub-requirements] 2326 Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 2327 for Subscription to YANG Datastores", draft-ietf-i2rs-pub- 2328 sub-requirements-03 (work in progress), October 2015. 2330 [I-D.ietf-netconf-restconf] 2331 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2332 Protocol", I-D draft-ietf-netconf-restconf-07, July 2015. 2334 [I-D.ietf-netconf-yang-patch] 2335 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 2336 Media Type", draft-ietf-netconf-yang-patch-05 (work in 2337 progress), July 2015. 2339 [I-D.ietf-netmod-yang-json] 2340 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2341 draft-ietf-netmod-yang-json-06 (work in progress), October 2342 2015. 2344 [I-D.voit-netmod-peer-mount-requirements] 2345 Voit, E., Clemm, A., and S. Mertens, "Requirements for 2346 Peer Mounting of YANG subtrees from Remote Datastores", 2347 draft-voit-netmod-peer-mount-requirements-03 (work in 2348 progress), September 2015. 2350 Authors' Addresses 2352 Alexander Clemm 2353 Cisco Systems 2355 EMail: alex@cisco.com 2357 Alberto Gonzalez Prieto 2358 Cisco Systems 2360 EMail: albertgo@cisco.com 2362 Eric Voit 2363 Cisco Systems 2365 EMail: evoit@cisco.com