idnits 2.17.00 (12 Aug 2021) /tmp/idnits20238/draft-wilton-netmod-refined-datastores-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2137 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) == Unused Reference: 'RFC6020' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC6243' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 892, but no explicit reference was found in the text == Outdated reference: draft-ietf-netconf-restconf has been published as RFC 8040 ** Downref: Normative reference to an Informational draft: draft-ietf-netmod-opstate-reqs (ref. 'I-D.ietf-netmod-opstate-reqs') ** Downref: Normative reference to an Informational RFC: RFC 3535 ** Downref: Normative reference to an Informational RFC: RFC 6244 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: draft-ietf-i2rs-ephemeral-state has been published as RFC 8242 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Wilton, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 7, 2016 5 Expires: January 8, 2017 7 Refined YANG datastores 8 draft-wilton-netmod-refined-datastores-01 10 Abstract 12 The existing definition of YANG datastores supported by NETCONF only 13 provides a loose definition of the running datastore, and no formal 14 definition of any datastore that represents the operational state of 15 a device. This document defines a refined datastore model with new 16 concrete and abstract datastores to allow devices to provide a clean 17 separation between an operator's intended configuration of a device 18 and the actual running operational state of a device. It provides a 19 similiar, but alternative, datastore framework to the one described 20 in draft-schoenw-netmod-revised-datastores. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Overview of a refined model of datastores . . . . . . . . . . 5 60 5. Definition of all datastores . . . . . . . . . . . . . . . . 7 61 5.1. Candidate Datastore (optional) . . . . . . . . . . . . . 7 62 5.2. Startup Datastore . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Running Configuration Datastore . . . . . . . . . . . . . 7 64 5.4. Persistent Configuration Datastore . . . . . . . . . . . 8 65 5.5. Ephemeral Configuration Datastore (Optional) . . . . . . 8 66 5.6. Intended Configuration Abstract Datastore . . . . . . . . 8 67 5.7. Applied Configuration Abstract Datastore . . . . . . . . 8 68 5.8. Operational State Datastore . . . . . . . . . . . . . . . 9 69 5.8.1. Applied Configuration . . . . . . . . . . . . . . . . 9 70 5.8.2. System Controlled Configuration . . . . . . . . . . . 9 71 5.8.3. System State . . . . . . . . . . . . . . . . . . . . 10 72 5.8.4. Statistics . . . . . . . . . . . . . . . . . . . . . 10 73 5.8.5. Ephemeral State . . . . . . . . . . . . . . . . . . . 10 74 6. Discussion points . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. A complete and accurate representation of a device's 76 configuration . . . . . . . . . . . . . . . . . . . . . . 10 77 6.2. Missing resources . . . . . . . . . . . . . . . . . . . . 11 78 6.3. System controlled resources . . . . . . . . . . . . . . . 11 79 6.4. Auto-configured or auto-negotiated values . . . . . . . . 11 80 6.5. Operational State with Different Origins . . . . . . . . 12 81 6.6. Statistics . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.7. YANG Defaults Handling . . . . . . . . . . . . . . . . . 13 83 7. Implications of the Refined Datastore Model . . . . . . . . . 13 84 7.1. Implications for YANG . . . . . . . . . . . . . . . . . . 14 85 7.2. Implications for NETCONF . . . . . . . . . . . . . . . . 14 86 7.2.1. Implications for Opstate Aware Devices . . . . . . . 15 87 7.2.2. Implications for Opstate Unaware Devices . . . . . . 15 88 7.3. Implications for RESTCONF . . . . . . . . . . . . . . . . 16 89 7.3.1. Implications for Opstate Unaware Devices . . . . . . 17 90 8. Changes from previous version . . . . . . . . . . . . . . . . 17 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 12.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 This document defines a similar, but alternative, architectural 103 datastore framework to [I-D.schoenw-netmod-revised-datastores]. The 104 aim of this document is to make it easier to compare the models and 105 approaches being described in the two different drafts. The reader 106 is advised to also read [I-D.schoenw-netmod-revised-datastores] which 107 provides a good background on why a refined NETCONF/YANG datastore 108 model is needed. 110 This document defines serveral new datastores, and also introduces 111 the new concept of an abstract datastore. Despite multiple new 112 datastores being defined, the expectation is that clients and devices 113 would mainly interact with only the Persistent Configuration and 114 Operational State Datastores. Candidate and Startup datastores would 115 be used as presently defined, and the Running datastore would be 116 supported (as much as possible) for backwards compatibility purposes. 118 Abstract datastores are a new flavor of datastore that are 119 semantically equivalent to regular datastores, but without the 120 expectation that clients would be able to explicitly interact with 121 them as explicitly named datastores. Instead, clients would likely 122 infer the contents of the abstract datastores through metadata 123 annotations on the regular datastores. One of the main advantages 124 for defining these abstract datastores is to allow for a precise 125 definition of the meaning of the configuration and operational data 126 on a device, and potentially allow management agents to make 127 comparisons between the different datastores. E.g. to determine if 128 any intended configuration has not actually been applied, or perhaps 129 conversely which parts of the applied configuration do not match the 130 intended configuration. 132 This document also gives an idea of how ephemeral state could 133 potentially be represented to meet the I2RS requirements specified in 134 [I-D.ietf-i2rs-ephemeral-state]. Ephemeral configuration is treated 135 as a separate optional configuration datastore that constitutes part 136 of the intended configuration of the device. Ephemeral operational 137 state is represented as part of the Operational State Datastore 138 described in Section 5.8. Further refinement of the proposed 139 handling of ephemeral state is likely needed to ensure that all the 140 I2RS ephemeral state requirements are met. 142 2. Objectives 144 The key aims of the datastore definitions given in this document are: 146 to keep the existing definition of the running-configuration 147 unchanged, 149 to minimize the impact on existing NETCONF/RESTCONF 150 implementations, and to provide a viable upgrade path for existing 151 NETCONF/RESTCONF servers, 153 to minimize the number datastores (and amount of data) that need 154 to be explicitly managed by external management agents, 156 to make explicit the meaning of the contents of each datastores 157 and how they relate to each other. 159 3. Definitions 161 The following terms are defined in [I-D.ietf-netmod-opstate-reqs]: 163 Intended Configuration 165 Applied Configuration 167 Operational State 169 The following definition is taken from [RFC6241]: 171 running configuration datastore - A configuration datastore 172 holding the complete configuration currently active on the device. 173 The running configuration datastore always exists. 175 The following new terms are defined here: 177 opstate aware device - a device that implements the requirements 178 specified in [I-D.ietf-netmod-opstate-reqs], in particular the 179 device must expose the split between the device's 'intended 180 configuration' vs 'applied configuration'. 182 opstate unaware device - a device that is not an 'opstate aware 183 device'. In particular, it does not draw a clear distinction 184 between 'intended configuration' vs 'applied configuration', and 185 generally treats them as having exactly the same contents. 187 abstract datastore - a conceptual type of datastore that 188 represents some abstract property (e.g. 'applied configuration') 189 of the data nodes that it contains. Although devices could allow 190 an abstract datastore to be externally referenced as a named 191 datastore, this is not expected or required. 193 4. Overview of a refined model of datastores 195 This document defines a refined datstore model that can universally 196 be used for both opstate aware devices and also existing NETCONF/ 197 RESTCONF servers. The model is intended to cover both the opstate 198 requirements [I-D.ietf-netmod-opstate-reqs] and the I2RS ephemeral 199 configuration datastore requirements [I-D.ietf-i2rs-ephemeral-state]. 201 All datastores described in this document use the same YANG schema, 202 although the actual data nodes that are allowed in a particular 203 datastore can depend on statements set in the schema. For example, 204 the configuration datastores only contain datanodes for YANG schema 205 nodes that are "config=true". 207 The following diagram illustrates how the datastores (except 208 'Running') relate to each other: 210 +-------------+ +-----------+ 211 | | | | 212 | (ct, rw) |<---+ +--->| (ct, rw) | 213 +-------------+ | | +-----------+ 214 | | | | 215 | .....|........|........ | 216 | . +-----------------+ . | 217 +------->| |<---+ 218 . | (ct, rw) | . 219 Intended . +-----------------+ . 220 Config ==> . v . 221 Datastore . +-----------------+ . 222 (abstract) . | |<--- Can override persistent 223 . | (ct, rw) | . cfg. Optional 224 . +-----------------+ . 225 ..........|............ 226 | 227 +---------v-----------+ 228 | ................... | 229 | . .<--- Actual cfg in effect 230 Operational | . (ct, ro) . | 231 State ==> | ................... | 232 Datastore | + | 233 | system cfg <--- System created config 234 | + | 235 | system state <--- All config false nodes 236 +---------------------+ 238 Key 239 Solid boxes (-----) indicate normal datastores: 240 (i.e Startup, Persistent Cfg, Ephemeral Cfg, Operational State) 242 Dotted boxes (.....) indicate abstract datastores: 243 (i.e. Intended Config and Applied Config) 245 ct = config true, rw = read/write, ro = read/only 247 Three new datastores are defined: 249 o Persistent Configuration - holds the current, client provided, 250 configuration for the device that is saved to the Startup 251 Datastore and is recovered after device reboot. 253 o Ephemeral Configuration - an optional datastore that holds client 254 provided transient configuration that is discarded after device 255 reboot. 257 o Operational State - a read-only datastore that holds all of the 258 operational state of the device. Specifically it holds: the exact 259 configuration that has been applied, along with any system 260 controlled configuration, and all system state (including 261 statistics and any ephemeral state). 263 Two new abstract datastores are defined: 265 o Intended Configuration - represents the combined desired 266 configuration of the device 268 o Applied Configuration - represents the actual applied 269 configuration of the device 271 Two datastores are unchanged from the NETCONF [RFC6241] definition: 273 o Candidate - represents candidate configuration 275 o Startup - represents startup configuration 277 For opstate aware devices, the Running Configuration Datastore is 278 redefined as an abstract datastore that represents the combined 279 persistent and applied configuration. It is regarded as a logical 280 expansion of the definition in NETCONF [RFC6241]. 282 5. Definition of all datastores 284 5.1. Candidate Datastore (optional) 286 Holds candidate configuration. Unchanged from NETCONF [RFC6241]. 288 5.2. Startup Datastore 290 Holds the saved configuration that is used by the device after 291 reboot. Unchanged from NETCONF [RFC6241]. 293 5.3. Running Configuration Datastore 295 To accommodate a clean separation between configuration and state, 296 for an opstate aware device, the Running Configuration Datastore is 297 logically split into two component parts, the Persistent 298 Configuration Datastore and Applied Configuration Datastore, as 299 illustrated by the following diagram: 301 /---- Persistent Configuration ds 302 Running Configuration ds | 303 \---- Applied Configuration Abstract ds 305 The Applied Configuration Abstract Datastore is part of the 306 Operational State Datastore. 308 5.4. Persistent Configuration Datastore 310 The Persistent Configuration Datastore holds the current 311 configuration provided by a client that is expected to be persisted 312 over device reboot. The datastore can be read and written by a 313 client. Any edit operations on the datastore are validated as per 314 YANG constraints validation before being processed further. The 315 persistent configuration datastore interacts with both the Candidate 316 and Startup datastores, and forms part of the Intended Configuration 317 Abstract Datastore. 319 5.5. Ephemeral Configuration Datastore (Optional) 321 The Ephemeral Configuration Datastore may optionally be supported to 322 hold any configuration that must not persist over device reboot. 323 This writable datastore could be regarded as a pane of glass overlay 324 on the persistent configuration datastore, allowing nodes in the 325 ephemeral configuration to override, or depend on, nodes in the 326 persistent configuration if required. 328 A mechanism is required to allow a client to choose which values take 329 precendence if a leaf with different values exists in both the 330 persistent configuration and ephemeral configuration datastore. 332 Multiple layers of ephemeral configuration within the ephemeral 333 datastore could be supported. 335 5.6. Intended Configuration Abstract Datastore 337 The Intended Configuration Abstract Datastore represents the entire 338 combined intended configuration for the device. It is implemented as 339 the net combination of the Persistent Configuration Datastore 340 combined with the optional Ephemeral Configuration Datastore. 342 For devices that do not support ephemeral configuration, the Intended 343 Configuration Abstract Datastore is exactly the same as the 344 Persistent Configuration Datastore. 346 5.7. Applied Configuration Abstract Datastore 348 The Applied Configuration Abstract Datastore is the subset of the 349 config true datanodes in the Operational State Datastore that 350 represents the applied configuration on the device. 352 If the intended configuration has been completely successfully 353 applied, then the contents of the Applied Configuration Abstract 354 Datastore exactly matches the Intended Configuration Abstract 355 Datatstore, conforming to the behaviour specified in 356 [I-D.ietf-netmod-opstate-reqs]. 358 5.8. Operational State Datastore 360 The Operational State Datastore represents all of the operational 361 state of the device, and is made up of the applied configuration, 362 along with any system controlled configuration, and all of the system 363 state. It includes statistics and ephemeral state (both applied 364 configuration and operational state nodes). 366 This datastore contains all nodes defined in the YANG schema (i.e. 367 both config true and config false nodes). The contents of this 368 datastore can only be updated by the device, and as such, from a 369 client perspective this datastore is read only. 371 The data held in the Operational State Datastore can be further 372 classified into five categories: 374 5.8.1. Applied Configuration 376 The Operational State Datastore contains the applied configuration 377 that represents the configuration that the device is actual using to 378 operate the device. 380 If the intended configuration has been completely successfully 381 applied, then the applied configuration data nodes exactly matches 382 the logical contents of the Intended Configuration Abstract 383 Datatstore. 385 5.8.2. System Controlled Configuration 387 In addition to the applied configuration, the Operational State 388 Datastore also contains any System Controlled Configuration data 389 nodes. These data nodes, using the same YANG config true schema 390 nodes as for the applied configuration, represent all configuration 391 that is created and controlled by the system independently of the 392 applied configuration. E.g. this would include system created 393 interfaces, which exist in the Operational State Datastore regardless 394 of whether they have been explicitly configured by a client. 396 There is no YANG schema keyword required to identify nodes that may 397 be system controlled. Hence, a device could choose for any config 398 true node in the YANG schema to be system controlled, but a device 399 would be expected to identify to a client the data nodes in the 400 Operational State Datastore that are system controlled through a 401 mechanism such as YANG Metadata (e.g. as described in 402 [I-D.wilton-netconf-opstate-metadata]). 404 5.8.3. System State 406 System State represents all of the data nodes in the Operational 407 State Datastore that are represented by config false nodes in the 408 YANG schema. 410 5.8.4. Statistics 412 Statistics are a subset of the data nodes in the Operational State 413 Datastore. Statistics nodes are identified in the YANG schema by the 414 "statistics true" statement, that must also be identified as "config 415 false". 417 5.8.5. Ephemeral State 419 Ephemeral state is the subset of the schema in the Operational State 420 Datastore that represents ephemeral state nodes, which are identified 421 in the YANG schema by the ephemeral keyword, including both the 422 applied ephemeral configuration (config true, ephemeral true), and 423 ephemeral operational state (config false, ephemeral true). 425 6. Discussion points 427 6.1. A complete and accurate representation of a device's configuration 429 Sometimes a device cannot completely implement all of the nodes and 430 values specified by a YANG schema. Ideally a well behaved device 431 would indicate which parts of the schema it cannot completely support 432 via YANG deviations. But deviations do not work in all scenarios - 433 support for particular values of a configuration leaf may be 434 dependent on the underlying hardware that is present in the device at 435 the time. In this and other similar scenarios, to ensure that a 436 client can properly manage a device, the applied configuration must 437 be a complete and accurate representation of all of the configuration 438 that a device is actually running. This must include any features 439 that are implicitly enabled by default without any client 440 configuration, or places where the applied configuration value 441 differs from the intended configuration value (e.g. perhaps to 442 protect the system from being overloaded). 444 6.2. Missing resources 446 Configuration that cannot be applied because the system resources are 447 missing (or have been exhausted) would logically exist in the 448 intended configuration datastore but not in the applied configuration 449 datastore. 451 As defined in [I-D.ietf-netmod-opstate-reqs], by default, a NETCONF 452 or RESTCONF configuration commit would be expected to fail if some of 453 the configuration was for system resources that were not present. 454 Extensions to NETCONF and RESTCONF could be provided to allow for 455 more control over configuration operations that contain configuration 456 for system resources that are missing. 458 6.3. System controlled resources 460 System controlled resources (i.e. those resources that would exist in 461 the system regardless of configuration) always exist as nodes in the 462 Operational State Datastore as part of the "system controlled 463 configuration". If the resources have also been configured then they 464 would also be present in the abstract intended datastore, and if the 465 configuration successfully applied, the abstract applied 466 configuration datastore as well. 468 Clients could find out which nodes in the operational state datastore 469 are system controlled by using YANG Metadata, e.g. as described in 470 [I-D.wilton-netconf-opstate-metadata]. 472 6.4. Auto-configured or auto-negotiated values 474 The applied configuration in the Operational State Datastore only 475 represents the configuration that is applied, and is bound by the 476 constraint that if the configuration has been successfully applied 477 then it must exactly match the intended configuration. Hence, this 478 generally requires that separate config false leaves in the 479 Operational State Datastore are required to represent the exact 480 values programmed in the device. 482 In the specific case that the operational value meets the following 483 three constraints then no separate config false leaf is required: 485 1. it is directly controlled by configuration, 487 2. it has exactly the same schema value space as the corresponding 488 configuration leaf, and 490 3. if configured, the operational value of the system matches the 491 applied configuration. 493 This optimization is allowed because the config false leaf value in 494 the Operational State Datastore would always have exactly the same 495 lifecycle existence and value as the corresponding config true leaf 496 representing the applied configuration in the Operational State 497 Datastore. 499 6.5. Operational State with Different Origins 501 The definition of the Operational State Datastore is designed to 502 allow config false leaves to depend on either explicitly configured 503 entities (in the applied configuration datastore) or system created 504 configuration entries. This definition facilitates the merging of 505 separate configuration and state parts of YANG models into the same 506 container/lists if desired. 508 An example are IP addresses of an interface that can originate from 509 configuration, from DHCP, or may be dynamically auto-configured. In 510 this case, the operational state datastore would contain all IP 511 addresses. The explicitly configured addresses would logically exist 512 in the abstract applied configuration datastore. Addresses learned 513 through DHCP or dynamically configured would logically exist as 514 system controlled config true data nodes in the Operational State 515 Datastore. Enhanced get/notification requests with YANG metadata 516 annotations could be used to amend the reply/notification with 517 metadata information to indicate which datastore the entries 518 logically exist in. 520 6.6. Statistics 522 Both the Overview of 2002 IAB Network Management Workshop [RFC3535] 523 and NETCONF/YANG Network Management Architecture [RFC6244] 524 categorises the state of a devices separately into configuration, 525 operational state, and statistics. NETCONF and YANG have 526 historically only categorised the state of a device into 527 configuration and non-configuration. 529 This document considers statistics to be part of the Operational 530 State Datastore, which is consistent with how statistics information 531 is returned in current NETCONF/RESTCONF requests, and allows all 532 operational state to be efficiently and easily retrieved together in 533 one request. It is envisaged that YANG schema data nodes could be 534 labelled with a new "statistics true" statement to allow for easy 535 filtering of statistics data for NETCONF/RESTCONF GET/GET-CONFIG 536 requests and also YANG pub/sub. I.e. the extensions should allow for 537 requests against the Operational State Datastore that exclude 538 statistics, along with requests that only include statistics (along 539 with any necessary containing structure and keys). 541 6.7. YANG Defaults Handling 543 The protocol handling of YANG defaults is described in NETCONF With- 544 defaults [RFC3535] and RESTCONF [I-D.ietf-netconf-restconf]. These 545 documents allow a device to report how YANG defaults are normally 546 handled in requests for data resources, but with the expectation that 547 the same semantics apply to all datastores. There is no way to 548 express that the default handling semantics should depend on the 549 datastore that a request pertains to. 551 When considering operational state, the most useful semantics for 552 handling YANG defaults depend on the particular datastore and what 553 system data it represents. To allow servers to provide optimal 554 default handling, it is proposed that an extension to, or new version 555 of, With-defaults is defined to support the proposed semantics below: 557 For configuration datastores that directly represent client provided 558 configuration (i.e. the Persistent Configuration Datastore, Ephemeral 559 Configuration Datastore and Intended Configuration Abstract 560 Datastore), the most useful semantics are to return the exact data 561 nodes set by the client (i.e. this is equivalent to the With-defaults 562 "explicit" capability mode). Using this mode makes it easy for 563 clients to check that a device has received and is acting on the 564 exact desired configuration. Further, clients can always strip 565 default values out of the configuration that they send to the device 566 if they wish. 568 For the Operational State Datastore, which represents the exact 569 operational state of the device, it is most helpful if the device 570 returns the exact operational state of the device including any data 571 nodes with a value that matches the YANG schema default value (i.e. 572 this is equivalent to the With-defaults "report-all" capability 573 mode). The benefits to the client of being able to rely on the 574 values provided by the device outweigh the slight increase in data 575 and processing overhead. 577 In addition, it is desirable if that the new with-defaults semantics 578 apply to both explicit NETCONF/RESTCONF GET/GET-CONFIG requests and 579 also YANG pub/sub. In all cases, for servers that support the YANG 580 With-defaults extension, clients can overide the default handling 581 behavior to whichever semantics they desire. 583 7. Implications of the Refined Datastore Model 584 7.1. Implications for YANG 586 The proposed revised datastore definitions have the following 587 implications on YANG: 589 o A new "statistics true|false" statement is added to the YANG 590 language to label schema data nodes that only contain statistics: 592 * Only "config false" schema data nodes may be labelled 593 "statistics true". 595 * Schema data nodes that are labelled "statistics true" may not 596 have any decendent child nodes that are either labelled "config 597 true" or "statistics false". 599 o A new "ephemeral true|false" statement is added to the YANG 600 language to label schema data nodes that contain ephemeral state: 602 * Schema data nodes labelled "config true" or "config false" may 603 also be labelled "ephemeral true". 605 * Schema data nodes labelled "statistics true" or "statistics 606 false" may also be labelled "ephemeral true". 608 * Schema data nodes labelled "config true" and "ephemeral true" 609 cannot appear in the Persistent Configuration Datastore. 611 * Schema data nodes that are labelled "ephemeral true" cannot 612 have any decendent YANG schema nodes that are labelled 613 "ephemeral false". 615 7.2. Implications for NETCONF 617 The proposed revised datastore definitions have the following 618 implications on NETCONF: 620 o Support for the new configuration datastores is added to NETCONF: 622 * and requests are supported on the new 623 datastores, but both return the same data. 625 * Only the Persistent Configuration and Ephemeral Configuration 626 (along with Candidate/Startup) datastores are writable by 627 clients. 629 * It is an implementation choice whether devices support Intended 630 Config and Applied Config as named, client accessable, 631 datastores. 633 * A new NETCONF capability would indicate which new configuration 634 datastores are supported by the device. 636 o Support for the new Operational State Datastore is added to 637 NETCONF: 639 * requests return all the data from the datastore. 641 * requests only return config true data nodes 642 (applied config and system controlled config) from the 643 datastore. 645 * requests are not supported. 647 * A new NETCONF capability would indicate that the device 648 supports the Operational State Datastore. 650 7.2.1. Implications for Opstate Aware Devices 652 The following implications are specific to opstate aware devices 653 supporting NETCONF: 655 o Configuration requests on the Running Configuration Datastore are 656 handled as follows: 658 * and requests are mapped to the 659 Persistent Configuration Datastore. 661 * requests are mapped to the Operational State Datastore. 663 7.2.2. Implications for Opstate Unaware Devices 665 One of the key aims of the refined datastore model described in this 666 draft is to minimize the impact on existing (or opstate unaware) 667 NETCONF/RESTCONF clients and devices. The assumption of this model 668 is that for an opstate unaware device, the Persistent Configuration, 669 Intended Configuration and Applied Configuration Datastores all hold 670 exactly the same values, and are collectively labelled as the Running 671 Configuration Abstract Datastore). 673 An opstate unaware device does not have to make any changes, but a 674 device could add support for the following to maximize 675 interoperability: 677 o All config requests on the Persistent Configuration, Intended 678 Configuration, and Applied Configuration datastores can be mapped 679 to the Running Configuration Datastore. 681 o If new YANG modules are supported that allow configuration and 682 state nodes to be combined via the creation of system controlled 683 entries, then requests on the Running Configuration 684 Datastore would also include any system controlled configuration 685 entries along with decendent children nodes. 687 o The Operational State Datastore could be supported (for and 688 requests only) and mapped to the Running 689 Configuration Datatstore + config false nodes. 691 7.3. Implications for RESTCONF 693 The proposed revised datastore definitions have the following 694 implications on RESTCONF: 696 o Support for explicit datastores is added to RESTCONF: 698 * A new URL would be provided to allow for datastore specific 699 access (e.g. "/restconf/ds//" 701 * GET requests are supported on the new datastores, the content 702 parameter could also be supported, but is pretty meaningless. 704 * PUT, POST and PATCH are supported on the Persistent Config 705 Datastore and Ephemeral Config Datastores, which are writable 706 by clients. 708 * It is an implementation choice whether devices support Intended 709 Config and Applied Config as named, client accessable, 710 datastores. 712 * A new RESTCONF capability would indicate which new 713 configuration datastores are supported by the device. 715 o Support for the new Operational State Datastore is added to 716 RESTCONF: 718 * GET requests return all the data from the datastore, and the 719 content parameter used to choose whether config true, config 720 false, or all nodes are returned. 722 * PUT, POST and PATCH requests are not supported. 724 * A new RESTCONF capability would indicate that the device 725 supports the Operational State Datastore. 727 o Requests on the default RESTCONF datastore URL ("/restconf/data"): 729 * PUT, POST and PATCH requests are handled as if they were made 730 on the Persistent Configuration Datastore. 732 * GET requests would be handled as if they were made on the 733 Operational State Datastore. 735 7.3.1. Implications for Opstate Unaware Devices 737 An opstate unaware device does not have to make any changes, but a 738 device could add support for the following to maximize 739 interoperability: 741 o Support could be added for the named Persistent Configuration, 742 Intended Configuration, and Applied Configuration datastores which 743 would be handled as if the request was made directly on 744 "/restconf/data". 746 o If new YANG modules are supported that allow configuration and 747 state nodes to be combined via the creation of system controlled 748 entries, then GET requests on "/restconf/data" would also include 749 any system controlled configuration entries along with decendant 750 children nodes. 752 o The Operational State Datastore could be supported for GET 753 requests, and mapped to "/restconf/data". 755 8. Changes from previous version 757 Changes from previous versions: 759 o Changes from version -00: 761 * The entire draft has been quite heavily restructured with an 762 effort to make it easier to read 764 * A definition of "abstract datastores" is given, with usage 765 restricted to intended configuration, applied configuration, 766 and running configuration 768 * "System Controlled Configuration" and "System Controlled State" 769 are no longer modelled as separate abstract datastores 771 * The main diagram has been updated to make the relationship 772 between the datastores clearer and more simple 774 * Added support for schema labelling of "statistics" data nodes 775 as part of the Operational State Datastore 777 * Added support for schema labelling of "ephemeral state" data 778 nodes as part of the Operational State Datastore 780 9. Acknowledgements 782 This document is not solely the authors own work, but instead 783 represents one view from the discussions to find a consensual 784 solution to the operational state problem. It takes ideas from many 785 people and uses parts of solutions described in the various internet 786 drafts listed below. In particular, this document is an alternative 787 to the revised datastore model described in draft-schoenw-netmod- 788 revised-datastores [I-D.schoenw-netmod-revised-datastores], and 789 reuses some of the structure and text from that document. 791 Work from the following internet drafts have helped form the basis of 792 the datastore solution described in this draft: 794 o draft-bjorklund-netmod-operational 795 [I-D.bjorklund-netmod-operational] 797 o draft-ietf-netmod-opstate-reqs [I-D.ietf-netmod-opstate-reqs] 799 o draft-kwatsen-netmod-opstate [I-D.kwatsen-netmod-opstate] 801 o draft-openconfig-netmod-opstate [I-D.openconfig-netmod-opstate] 803 o draft-schoenw-netmod-revised-datastores 804 [I-D.schoenw-netmod-revised-datastores] 806 o draft-wilton-netmod-opstate-yang [I-D.wilton-netmod-opstate-yang] 808 o draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state] 810 The following people were authors to these Internet-Drafts or 811 otherwise actively involved in the discussions that led to this 812 document: 814 o Lou Berger, Labn Consulting, 816 o Andy Biermann, YumaWorks, 818 o Martin Bjorklund, Tail-f Systems, 820 o Susan Hares, Huawei, 822 o Jeff Haas, Juniper Networks, 824 o Marcus Hines, Google, 825 o Christian Hopps, Deutsche Telekom, 827 o Acee Lindem, Cisco Systems, 829 o Ladislav Lhotka, CZ.NIC, 831 o Thomas Nadeau, Brocade Networks, 833 o Juergen Schoenwaelder, Jacobs University Bremen 834 836 o Anees Shaikh, Google, 838 o Rob Shakir, Jive Communications, 840 o Kent Watsen, Juniper Networks, 842 The author would also like the thank the following people who have 843 kindly provided feedback on this draft: Matt Hall, Einar Nilsen- 844 Nygaard. 846 10. IANA Considerations 848 None 850 11. Security Considerations 852 This document discusses a conceptual model of datastores for network 853 management using NETCONF/RESTCONF and YANG. It has no security 854 impact on the Internet. 856 12. References 858 12.1. Normative References 860 [I-D.ietf-netconf-restconf] 861 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 862 Protocol", draft-ietf-netconf-restconf-14 (work in 863 progress), June 2016. 865 [I-D.ietf-netmod-opstate-reqs] 866 Watsen, K. and T. Nadeau, "Terminology and Requirements 867 for Enhanced Handling of Operational State", draft-ietf- 868 netmod-opstate-reqs-04 (work in progress), January 2016. 870 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 871 Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May 872 2003, . 874 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 875 the Network Configuration Protocol (NETCONF)", RFC 6020, 876 DOI 10.17487/RFC6020, October 2010, 877 . 879 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 880 and A. Bierman, Ed., "Network Configuration Protocol 881 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 882 . 884 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 885 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 886 . 888 [RFC6244] Shafer, P., "An Architecture for Network Management Using 889 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 890 2011, . 892 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 893 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 894 . 896 12.2. Informative References 898 [I-D.bjorklund-netmod-operational] 899 Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF 900 and YANG", draft-bjorklund-netmod-operational-00 (work in 901 progress), October 2012. 903 [I-D.ietf-i2rs-ephemeral-state] 904 Haas, J. and S. Hares, "I2RS Ephemeral State 905 Requirements", draft-ietf-i2rs-ephemeral-state-10 (work in 906 progress), June 2016. 908 [I-D.kwatsen-netmod-opstate] 909 Watsen, K., Bierman, A., Bjorklund, M., and J. 910 Schoenwaelder, "Operational State Enhancements for YANG, 911 NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 912 (work in progress), February 2016. 914 [I-D.openconfig-netmod-opstate] 915 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 916 of Operational State Data in YANG", draft-openconfig- 917 netmod-opstate-01 (work in progress), July 2015. 919 [I-D.schoenw-netmod-revised-datastores] 920 Schoenwaelder, J., "A Revised Conceptual Model for YANG 921 Datastores", draft-schoenw-netmod-revised-datastores-01 922 (work in progress), June 2016. 924 [I-D.wilton-netconf-opstate-metadata] 925 Wilton, R., "Refined YANG datastores with Meta-data", 926 draft-wilton-netconf-opstate-metadata-00 (work in 927 progress), July 2016. 929 [I-D.wilton-netmod-opstate-yang] 930 Wilton, R., ""With-config-state" Capability for NETCONF/ 931 RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in 932 progress), December 2015. 934 Author's Address 936 Robert Wilton (editor) 937 Cisco Systems 939 Email: rwilton@cisco.com