One document matched: draft-wilton-netmod-refined-datastores-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. --><!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">--><!--<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">--><!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY RFC7224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7224.xml">
<!ENTITY RFC6244 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6244.xml">
<!ENTITY RFC6243 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6243.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-wilton-netmod-refined-datastores-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Refined YANG Datastores">Refined YANG datastores</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Robert Wilton" initials="R.G." role="editor" surname="Wilton">
<organization>Cisco Systems</organization>
<address>
<email>rwilton@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- uri and facsimile elements may also be added -->
<date month="June" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The existing definition of YANG datastores supported by NETCONF only provides a loose definition of the running datastore, and no formal definition of any datastore that represents the operational state of a device. This document defines a refined datastore model with new concrete and abstract datastores to allow devices to provide a clean separation between the operator's intended configuration of a device and the actual running operational state of a device. It provides a similiar, but alternative, datastore framework to the one described in draft-schoenw-netmod-revised-datastores.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines a similar, but alternative architectural datastore framework to <xref target="I-D.schoenw-netmod-revised-datastores">draft-schoenw-netmod-revised-datastores</xref>. This purpose of this document is to make it easier to compare the models and approaches being described in the two different drafts. The reader is advised to also read <xref target="I-D.schoenw-netmod-revised-datastores">draft-schoenw-netmod-revised-datastores</xref> which provides a good background on why a refined NETCONF/YANG datastore model is needed.</t>
</section>
<section title="Objectives">
<t>The key aims of this definition of datastores are:
<list><t>to keep the existing definition of the running-configuration completely unchanged</t>
<t>to provide a viable upgrade path for existing NETCONF/RESTCONF servers</t>
<t>to minimize the number datastores (and amount of data) that need to be explicitly managed by external management agents</t>
<t>to make explicit the meaning of the contents in each of the datastores and how they relate to each other</t></list>
</t>
<t>This draft does not formally address the active/inactive configuration functionality described in <xref target="I-D.schoenw-netmod-revised-datastores">draft-schoenw-netmod-revised-datastores</xref>. If supporting this functionality is required, then it is envisaged that this would be a separate optional datastore that exists between the persistent configuration datastore and the ephemeral configuration datastore.</t>
</section>
<section title="Definitions">
<t>The following terms are defined:
<list><t>opstate aware device - a device that exposes a clean separation between intended and applied configuration</t>
<t>opstate unaware device - a device that does not expose a clean separation between intended and applied configuration</t>
</list>
</t>
</section>
<section title="Overview of a refined model of datastores">
<t>The following diagram illustrates how the datastores (except running) defined in this document relate to each other:</t>
<figure><artwork><![CDATA[
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +---------------+ |
+-------->| <persistent> |<-----+
| (ct, rw) | // subject to validation
+---------------+
|
v
+---------------+
| <ephemeral> |
| (ct, rw) |
+---------------+
|
v
+---------------+
| <intended> | // subject to validation
| (ct, ro) |
+---------------+
|
v
+---------------------+
| +---------------+ |
| | <applied cfg> | <--- actual cfg in effect
| | (ct, ro) | |
| +---------------+ |
| | |
| v |
Operational | +---------------+ |
State ==> | | <system cfg> | <--- System created config
Datastore | | (ct, ro) | |
| +---------------+ |
| | |
| v |
| +-----------------+ |
| | <system state> | <--- Config false nodes
| | (cf, ro) | |
| +-----------------+ |
+---------------------+
]]></artwork></figure>
<t>This document defines seven additional datastores beyond the three (candidate, startup, running) that are defined in existing RFCs! Many of these newly defined datastores are regarded as being entirely abstract datastores, and even opstate aware devices are not required to explicitly handle get requests (or YANG push notifications) on these named abstract datastores. One of the main reasons for defining these abstract datastores is to give a precise definition of the meaning of the configuration and operational data on a device, and potentially allow management agents to make queries between the different datastores (e.g. to determine if any intended configuration hasn't actually been applied, or perhaps conversely which parts of the applied configuration do not match the intended configuration).</t>
<t>The ten datastores can be summarized as thus:
<list style="numbers"><t>candidate ds - represents candidate configuration, unchanged from existing implementations</t>
<t>startup ds - represents startup configuration, unchanged from existing implementations</t>
<t>running configuration ds (abstract) - represents the combined persistent, ephemeral, intended and applied datastores, logically equivalent to the existing definition</t>
<t>persistent configuration ds - represents operator provided configuration that is written to the startup datastore and is recovered after device reboot</t>
<t>ephemeral configuration ds (optional) - represents operator provided transient configuration that is discarded after device reboot</t>
<t>intended configuration ds (abstract) - represents the combined (i.e. persistent and ephemeral) desired configuration of the device</t>
<t>operational state ds - a combined datastore that represents all of the operational state of the device (i.e. applied config, system controlled config & system state).</t>
<t>applied configuration ds (abstract) - represents the actual applied configuration of the device</t>
<t>system controlled configuration ds (abstract) - represents any system created/managed configuration on the device</t>
<t>system state ds (abstract) - represents all of the non-configuration operational state of the device</t></list>
</t>
<t>Only the system state datastore holds config=false nodes. All other datastores defined above only hold config=true YANG schema nodes, and are represented by the same YANG schema files.</t>
</section>
<section title="Definition of all datastores">
<section title="Candidate Datastore (Optional)">
<t>Holds candidate configuration. The definition is unchanged from existing RFCs.</t>
</section>
<section title="Startup Datastore">
<t>Holds the saved configuration that is used by the device after reboot. The definition is unchanged from existing RFCs.</t>
</section>
<section title="Running Configuration Datastore (Abstract)">
<t>This document does not try to redefine the running configuration datastore, it aims to retain its existing (loose) definition. Some implementations regard the running configuration as solely the configuration provided by the operator to the device. Other implementations regard it as something akin to the applied configuration datastore, where, on a system without ephemeral configuration, after a configuration commit has completed, the running configuration matches the configuration provided by the operator.</t>
<t>In the refined datastore model described in this draft, the running configuration datastore can be considered as being logically split into the persistent, ephemeral, intended, and applied configuration datastores as illustrated in the diagram below.</t>
<figure><artwork>
---- Persistent configuration ds
/
----- Ephemeral configuration ds
Running configuration ds |
----- Intended configuration ds
\
---- Applied configuration ds
</artwork></figure>
<section title="Support by non-opstate aware devices">
<t>On a non-opstate aware device, the running configuration datastore is supported exactly as it is today by the existing NETCONF/YANG RFCs</t>
</section>
<section title="Support by opstate aware devices">
<t>For an opstate aware device, the running configuration datastore is supported as an abstract datastore.</t>
<t>It maintain backwards compatibility, config writes to the running configuration datastore are treated as writes to the persistent configuration datastore. Config reads (e.g. get-config) from the running configuration datastore are treated as reads from the applied configuration datastore. NETCONF get requests (or equivalent) are treated as a read on the operational state datastore.</t>
</section>
</section>
<section title="Persistent Configuration Datastore">
<t>The Persistent Configuration Datastore represents the configuration provided by the operator, that is expected to be persisted over device reboot. Writes to the persistent configuration are validated to ensure that the configuration is well formed and valid, and if so, is persisted over device reboot. The persistent configuration datastore interacts with both the candidate and startup datastores (as per the running configuration datastore on a non opstate aware device).</t>
<t>This datastore is only written by the operator.</t>
<t>The default behavior for get requests (or YANG push notifications) on this datastore is to return the configuration exactly as provided by the operator (i.e. including any explicitly configured default values and excluding any implicit YANG default values).</t>
</section>
<section title="Ephemeral Configuration Datastore (Optional)">
<t>This document does not intend to formally define an Ephemeral Configuration Datastore. In particular, it must be noted that the ephemeral configuration datastore described here does not match that described in version -09 of <xref target="I-D.ietf-i2rs-ephemeral-state">draft-ietf-i2rs-ephemeral-state</xref>. Instead, it describes conceptually how such a datastore (restricted to configuration only) might fit into a conceptual refined datastore model.</t>
<t>An Ephemeral Configuration Datastore may optionally be supported to hold any configuration that must not persist over device reboot. This datastore could be regarded as a pane of glass overlay on the persistent configuration datastore, allowing nodes in the ephemeral configuration to override, or depend on, nodes in the persistent configuration if required.</t>
<t>This datastore is only written by the operator.</t>
<t>The default behavior for get requests (or YANG push notifications) on the ephemeral configuration datastore is to return the configuration exactly as written by the operator to the ephemeral datastore (i.e. including any explicitly configured default values and excluding any implicit default values).</t>
<t>Multiple layers of ephemeral configuration in the ephemeral datastore could be supported.</t>
</section>
<section title="Intended Configuration Datastore (Abstract)">
<t>The Intended Configuration datastore abstractly represents the net combination of the persistent configuration datastore overlaid with the optional ephemeral configuration datastore. It represents the entire combined configuration that the operator intends for the device.</t>
<t>This datastore is read only. It is optional as to whether the device allows the intended configuration to be directly read (or notified) as a labelled, user visible, datastore; or possibly the contents of the intended configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores.</t>
<t>If get requests (or YANG push notifications) are supported on the intended configuration datastore then the handling of default values would be consistent with both the persistent and ephemeral configuration datastores (as described previously), i.e. the explicit operator configuration is returned.</t>
</section>
<section title="Operational State Datastore">
<t>The Operational State datastore represents all of the operational state of the device. This includes the applied configuration, any system controlled configuration, and all of the system state (i.e. config=false nodes).</t>
<t>Logically, the operational state datastore can be considered as being split into the applied configuration, system controlled configuration, and system state datastores as illustrated in the following diagram:</t>
<figure><artwork>
---- Applied configuration ds
/
Operational state ds |----- System controlled configuration ds
\
---- System state ds
</artwork></figure>
<t>This datastore is read only. Performing a read of the operational state datastore returns the applied configuration overlaid with system controlled configuration and system state datastores.</t>
<t>The default behavior for get requests (or YANG push notifications) on the operational state datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default).</t>
<t>A default NETCONF GET request can be regarded as a GET request against the operational state datastore. It should also be noted that with the exception of system controlled configuration, that if the system has converged and the configuration has been applied then a GET request for an opstate aware device and a non opstate aware device return exactly the same data. This provides backwards compatibility and an upgrade path from existing NETCONF servers.</t>
</section>
<section title="Applied Configuration Datastore (Abstract)">
<t>The Applied Configuration datastore is the abstract subset of the operational state datastore that represents the actual configuration that has been applied and is in effect on the device.</t>
<t>For a well behaved device, after a config write operation has completed successfully the notional contents of the applied configuration datastore matches the intended configuration datastore.</t>
<t>Being an abstract datastore that is part of the operational state datastore it is read-only.</t>
<t>The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on one of the other datastores (e.g. persistent, intended, or operational-state datastore).</t>
<t>If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicitly set by a YANG schema default).</t>
</section>
<section title="System Controlled Configuration Datastore (Abstract)">
<t>The System Controlled Configuration Datastore is the abstract subset of the operational state datastore that represents all configuration nodes that are created by the system independently of the intended configuration. E.g. system created interfaces that hadn't been configured by the operator would logically exist in the system controlled configuration datastore whether or not they also exists in the applied configuration datastore.</t>
<t>This datastore uses the same YANG schema of config=true as for the intended or applied configuration datastores. Logically, nodes may exist in both the applied configuration and system controlled configuration datastores (e.g. if a system created interface had been configured).</t>
<t>Being an abstract datastore that is part of the operational state datastore it is read-only. </t>
<t>The contents of this datastore must be made available as part of the applied configuration datastore. It is optional as to whether the device allows the applied configuration datastore to be directly read (or notified via YANG Push) as a labelled, user visible, datastore; or possibly the contents of the applied configuration datastore may only be made available as YANG meta-data annotations on the operational-state datastore.</t>
<t>If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default).</t>
</section>
<section title="System State Datastore (Abstract)">
<t>The System State Abstract Datastore is the abstract subset of the operational state datastore that represents all of the operational state derived from configuration or other system defined values, and is represented by config=false nodes in the YANG schema.</t>
<t>Entries in this datastore can rely on the existence of entries in the applied configuration and system controlled configuration datastores, thus allowing disjoint config vs state lists to be merged together into a single list.</t>
<t>Being an abstract datastore that is part of the operational state datastore it is read-only.</t>
<t>The contents of this datastore must be made available as part of the operational state datastore. It is optional as to whether the device also allows this datastore to be directly read (or notified) as a labelled, operator visible, datastore.</t>
<t>If supported, the default behavior for get requests (or YANG push notifications) on this datastore is to explicitly return all values in effect in the system (including any values that are implicit due to a YANG schema default).</t>
</section>
</section>
<section title="Discussion points">
<section title="Missing resources">
<t>Configuration that cannot be applied because the system resources are missing (or have been exhausted) would logically exist in the intended configuration datastore but not the applied configuration datastore.</t>
</section>
<section title="System controlled resources">
<t>System controlled resources (i.e. those resources that would exist in the system regardless of configuration) always exist in the system controlled configuration datastore. They may also exist in the applied configuration datastore if they have also been configured (and the configuration successfully applied to the device).</t>
</section>
<section title="Auto-configured or auto-negotiated values">
<t>The applied configuration datastore only represents the configuration that is applied. Generally, separate config false leaves in the system state datastore are used to represent the operational state of the device.</t>
<t>In the specific case that the operational value is (i) directly controlled by configuration, (ii) has exactly the same schema value space as the corresponding configuration leaf, and (iii) if configured, the operational value of the system must be the same as the applied configuration then no separate config false leaf is needed. This optimization is valid because the system state datastore leaf value would always have exactly the same lifetime and value as the corresponding configuration leaf in the applied configuration datastore.</t>
</section>
<section title="Operational State with Different Origins">
<t>The definition of the operational state datastore is designed to allow config false leaves to depend on either explicitly configured entities (in the applied configuration datastore) or system created entries (in the system controlled configuration) datastore. This definition facilitates the merging of separate configuration and state parts of YANG models into the same container/lists if desired.</t>
<t>An example are IP addresses of an interface that can originate from configuration, from DHCP, or may be dynamically auto-configured. In this case, the operational state datastore would contain all IP addresses. The explicitly configured addresses would logically exist in the applied configuration datastore. Addresses learned through DHCP or dynamically configured would logically exist in the system controlled configuration datastore. Enhanced get/notification requests with YANG metadata annotations could be used to amend the reply/notification with metadata information to indicate which datastore the entries logically exist in.</t>
</section>
</section>
<section anchor="Implications" title="Implications of the Refined Datastore Model">
<section title="Implications for opstate unaware clients">
<t>This sections describes the implications for all opstate unaware clients, which includes all existing standards compliant NETCONF/RESTCONF clients.</t>
<t>One of the key aims of the refined datastore model described in this draft is to minimize the impact on existing (or opstate unaware) NETCONF/RESTCONF clients and devices. The assumption of this model is that for an opstate unaware device, the persistent configuration, intended configuration and applied configuration datastores all hold exactly the same values. This is also why they are collectively labelled as the abstract running configuration datastore).</t>
<t>Hence, for opstate unaware clients the key change is that NETCONF/RESTCONF get requests now only returns the state from the operational-state datastore rather than returning the running configuration datastore plus all config=false nodes. This means that there are two specific changes to how get requests are handled compared to how they would be handled by existing NETCONF/RESTCONF devices:
<list style="numbers">
<t>System created configuration entries would be included in any new YANG models that have been designed to allow configuration and state to be held in a single combined list. Given that existing YANG models are all specifically designed to avoid this scenario, this change would only affect new YANG models. No existing YANG models would be affected by this change.</t>
<t>This draft proposes different standard default handling semantics for the operational state datastore. Hence, unless the client requested otherwise, the device would be recommended to explicitly return all default values in a get request (or YANG push notification). This is exactly the same behavior as the 'report-all' retrieval mode described in <xref target="RFC6243">With-defaults Capability for NETCONF</xref>.</t>
</list></t>
<t>The other potential impact is the recommendation that the standard default handling semantics for the persistent configure datastore (which is what would be returned for a get-config request against the abstract running configuration datastore) is that the exact configuration written by the client should be returned. This is exactly the same behavior as the 'explicit' retrieval mode described in <xref target="RFC6243">With-defaults Capability for NETCONF</xref>.</t>
<section title="Upgradeability">
<t>The solution described in this document is intended to provide a viable upgrade path from an opstate unaware server to one that is opstate aware. I.e. it is feasible for an existing NETCONF/RESTCONF server to declare itself as being trivially opstate aware (treating applied configuration as the same as intended configuration) and over time refine the data it returns to provide more accurate applied configuration state.</t>
</section>
</section>
<section title="Implications for opstate aware clients">
<t>This sections describes the implications for all opstate aware clients.</t>
<t>Although this draft references a total of ten datastores, the expectation is that devices will only expose a subset as explicit named datastores. Of course, devices could also expose them all as formal externally visible datastores if desired.</t>
<t>In particular, depending on the protocol semantics, an opstate aware device would be expected to support the following datastores/requests:
<list style="symbols">
<t>Startup configuration ds - (already supported in NETCONF, implicit in RESTCONF)</t>
<t>Persistent configuration ds - edit-config and get-config requests only (added to NETCONF, implicit in RESTCONF)</t>
<t>Intended configuration ds - get-config requests only, handled as a transparent reference to the persistent configuration ds if ephemeral config datastore is not supported (added to NETCONF, optionally added to RESTCONF)</t>
<t>Operational state ds - get request only (added to NETCONF, optionally added to RESTCONF)</t>
<t>Candidate configuration ds - optional (already supported in NETCONF, implicit in RESTCONF)</t>
<t>Running configuration ds - for backwards compatibility. edit-config/get-config requests are directed to the persistent datastore, get requests are directed to the operational state datastore (already supported in NETCONF, implicit in RESTCONF) </t>
</list>
</t>
<t>Support for operations on the following datastores would be optional:
<list style="symbols">
<t>Ephemeral configuration ds - get-config requests only</t>
<t>Applied configuration ds - get requests only</t>
<t>System controlled configuration ds - get requests only</t>
<t>System state datastore - get requests only</t>
</list>
Some of the nodes in these datastores rely on the structure and existance of nodes in the preceding datastores to be valid. Hence, get requests and YANG notifications would have to include sufficient parent nodes (and list keys) to represent a valid YANG data tree.
</t>
<t>Rather that explicitly supporting and requiring management of all of these separate datastores, it is envisaged that optional YANG Metadata could be used to provide extra annotations to a subset of the datastores, allowing key additional information to be provided. A full solution is outside the scope of this draft, but it is envisaged that such annotations could be:
<list style="symbols">
<t>Persistent config datastore, with any nodes that are not also in the applied configuration datastore annotated (possibly along with the reason why they are not applied).</t>
<t>Intended config datastore, with any nodes that are not also in the applied configuration datastore annotated (possibly along with the reason why they are not applied).</t>
<t>Operational state datastore, with any applied configuration ds nodes that do not also match intended configuration ds annotated, and also any system created configuration ds nodes annotated.</t>
</list></t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is not solely the authors own work, but instead represents one view from the discussions to find a consensual solution to the operational state problem. It takes ideas from many people and uses parts of solutions described in various internet drafts listed below. In particular, this document is an alternative to the revised datastore model described in <xref target="I-D.schoenw-netmod-revised-datastores">draft-schoenw-netmod-revised-datastores</xref>, and reuses some of the structure and text from that document.</t>
<t>Work from the following internet drafts have helped form the basis of the datastore solution described in this draft:
<list style="symbols">
<t><xref target="I-D.bjorklund-netmod-operational">draft-bjorklund-netmod-operational</xref></t>
<t><xref target="I-D.ietf-netmod-opstate-reqs">draft-ietf-netmod-opstate-reqs</xref></t>
<t><xref target="I-D.kwatsen-netmod-opstate">draft-kwatsen-netmod-opstate</xref></t>
<t><xref target="I-D.openconfig-netmod-opstate">draft-openconfig-netmod-opstate</xref></t>
<t><xref target="I-D.schoenw-netmod-revised-datastores">draft-schoenw-netmod-revised-datastores</xref></t>
<t><xref target="I-D.wilton-netmod-opstate-yang">draft-wilton-netmod-opstate-yang</xref></t>
<t><xref target="I-D.ietf-i2rs-ephemeral-state">draft-ietf-i2rs-ephemeral-state</xref></t>
</list></t>
<t>
The following people were authors to these Internet-Drafts or otherwise actively involved in
the discussions that led to this document:
<list style="symbols">
<t>Lou Berger, Labn Consulting, <lberger@labn.net></t>
<t>Andy Biermann, YumaWorks, <andy@yumaworks.com></t>
<t>Martin Bjorklund, Tail-f Systems, <mbj@tail-f.com></t>
<t>Susan Hares, Huawei, <shares@ndzh.com></t>
<t>Jeff Haas, Juniper Networks, <jhaas@juniper.net></t>
<t>Marcus Hines, Google, <hines@google.com></t>
<t>Christian Hopps, Cisco Systems, <chopps@chopps.org></t>
<t>Acee Lindem, Cisco Systems, <acee@cisco.com></t>
<t>Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz></t>
<t>Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com></t>
<t>Juergen Schoenwaelder, Jacobs University Bremen <j.schoenwaelder@jacobs-university.de></t>
<t>Anees Shaikh, Google, <aashaikh@google.com></t>
<t>Rob Shakir, Jive Communications, <rjs@rob.sh></t>
<t>Kent Watsen, Juniper Networks, <kwatsen@juniper.net></t>
</list></t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>None</t>
<!-- <t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section will
be removed during conversion into an RFC by the RFC Editor.</t>-->
</section>
<section anchor="Security" title="Security Considerations">
<t>This document discusses a conceptual model of datastores for network management using NETCONF/RESTCONF and YANG. It has no security impact on the Internet.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"><!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC6020;
&RFC6243;
<!-- &RFC2119;
&RFC7223;
&RFC7224; -->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- &RFC6241;
&RFC6242; -->
&RFC6244;
<?rfc include="reference.I-D.wilton-netmod-opstate-yang.xml"?>
<?rfc include="reference.I-D.bjorklund-netmod-operational.xml"?>
<?rfc include="reference.I-D.ietf-netmod-opstate-reqs.xml"?>
<?rfc include="reference.I-D.kwatsen-netmod-opstate.xml"?>
<?rfc include="reference.I-D.openconfig-netmod-opstate.xml"?>
<?rfc include="reference.I-D.schoenw-netmod-revised-datastores.xml"?>
<?rfc include="reference.I-D.ietf-i2rs-ephemeral-state.xml"?>
</references>
<!-- <section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>-->
<!-- Change Log
v00 2015-03-02 RGW Initial version
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:11:17 |