Internet DRAFT - draft-wilton-netmod-refined-datastores
draft-wilton-netmod-refined-datastores
Internet Engineering Task Force R. Wilton, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track June 3, 2016
Expires: December 5, 2016
Refined YANG datastores
draft-wilton-netmod-refined-datastores-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Wilton Expires December 5, 2016 [Page 1]
Internet-Draft Refined YANG Datastores June 2016
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of a refined model of datastores . . . . . . . . . . 3
5. Definition of all datastores . . . . . . . . . . . . . . . . 6
5.1. Candidate Datastore (Optional) . . . . . . . . . . . . . 6
5.2. Startup Datastore . . . . . . . . . . . . . . . . . . . . 6
5.3. Running Configuration Datastore (Abstract) . . . . . . . 6
5.3.1. Support by non-opstate aware devices . . . . . . . . 6
5.3.2. Support by opstate aware devices . . . . . . . . . . 7
5.4. Persistent Configuration Datastore . . . . . . . . . . . 7
5.5. Ephemeral Configuration Datastore (Optional) . . . . . . 7
5.6. Intended Configuration Datastore (Abstract) . . . . . . . 8
5.7. Operational State Datastore . . . . . . . . . . . . . . . 8
5.8. Applied Configuration Datastore (Abstract) . . . . . . . 9
5.9. System Controlled Configuration Datastore (Abstract) . . 10
5.10. System State Datastore (Abstract) . . . . . . . . . . . . 10
6. Discussion points . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Missing resources . . . . . . . . . . . . . . . . . . . . 11
6.2. System controlled resources . . . . . . . . . . . . . . . 11
6.3. Auto-configured or auto-negotiated values . . . . . . . . 11
6.4. Operational State with Different Origins . . . . . . . . 12
7. Implications of the Refined Datastore Model . . . . . . . . . 12
7.1. Implications for opstate unaware clients . . . . . . . . 12
7.1.1. Upgradeability . . . . . . . . . . . . . . . . . . . 13
7.2. Implications for opstate aware clients . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document defines a similar, but alternative architectural
datastore framework to draft-schoenw-netmod-revised-datastores
[I-D.schoenw-netmod-revised-datastores]. 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
Wilton Expires December 5, 2016 [Page 2]
Internet-Draft Refined YANG Datastores June 2016
to also read draft-schoenw-netmod-revised-datastores
[I-D.schoenw-netmod-revised-datastores] which provides a good
background on why a refined NETCONF/YANG datastore model is needed.
2. Objectives
The key aims of this definition of datastores are:
to keep the existing definition of the running-configuration
completely unchanged
to provide a viable upgrade path for existing NETCONF/RESTCONF
servers
to minimize the number datastores (and amount of data) that need
to be explicitly managed by external management agents
to make explicit the meaning of the contents in each of the
datastores and how they relate to each other
This draft does not formally address the active/inactive
configuration functionality described in draft-schoenw-netmod-
revised-datastores [I-D.schoenw-netmod-revised-datastores]. 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.
3. Definitions
The following terms are defined:
opstate aware device - a device that exposes a clean separation
between intended and applied configuration
opstate unaware device - a device that does not expose a clean
separation between intended and applied configuration
4. Overview of a refined model of datastores
The following diagram illustrates how the datastores (except running)
defined in this document relate to each other:
Wilton Expires December 5, 2016 [Page 3]
Internet-Draft Refined YANG Datastores June 2016
+-------------+ +-----------+
| <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) | |
| +-----------------+ |
+---------------------+
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
Wilton Expires December 5, 2016 [Page 4]
Internet-Draft Refined YANG Datastores June 2016
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).
The ten datastores can be summarized as thus:
1. candidate ds - represents candidate configuration, unchanged
from existing implementations
2. startup ds - represents startup configuration, unchanged from
existing implementations
3. running configuration ds (abstract) - represents the combined
persistent, ephemeral, intended and applied datastores,
logically equivalent to the existing definition
4. persistent configuration ds - represents operator provided
configuration that is written to the startup datastore and is
recovered after device reboot
5. ephemeral configuration ds (optional) - represents operator
provided transient configuration that is discarded after device
reboot
6. intended configuration ds (abstract) - represents the combined
(i.e. persistent and ephemeral) desired configuration of the
device
7. 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).
8. applied configuration ds (abstract) - represents the actual
applied configuration of the device
9. system controlled configuration ds (abstract) - represents any
system created/managed configuration on the device
10. system state ds (abstract) - represents all of the non-
configuration operational state of the device
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.
Wilton Expires December 5, 2016 [Page 5]
Internet-Draft Refined YANG Datastores June 2016
5. Definition of all datastores
5.1. Candidate Datastore (Optional)
Holds candidate configuration. The definition is unchanged from
existing RFCs.
5.2. Startup Datastore
Holds the saved configuration that is used by the device after
reboot. The definition is unchanged from existing RFCs.
5.3. Running Configuration Datastore (Abstract)
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.
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.
---- Persistent configuration ds
/
----- Ephemeral configuration ds
Running configuration ds |
----- Intended configuration ds
\
---- Applied configuration ds
5.3.1. Support by non-opstate aware devices
On a non-opstate aware device, the running configuration datastore is
supported exactly as it is today by the existing NETCONF/YANG RFCs
Wilton Expires December 5, 2016 [Page 6]
Internet-Draft Refined YANG Datastores June 2016
5.3.2. Support by opstate aware devices
For an opstate aware device, the running configuration datastore is
supported as an abstract datastore.
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.
5.4. Persistent Configuration Datastore
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).
This datastore is only written by the operator.
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).
5.5. Ephemeral Configuration Datastore (Optional)
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 draft-ietf-i2rs-ephemeral-state
[I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually
how such a datastore (restricted to configuration only) might fit
into a conceptual refined datastore model.
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.
This datastore is only written by the operator.
Wilton Expires December 5, 2016 [Page 7]
Internet-Draft Refined YANG Datastores June 2016
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).
Multiple layers of ephemeral configuration in the ephemeral datastore
could be supported.
5.6. Intended Configuration Datastore (Abstract)
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.
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.
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.
5.7. Operational State Datastore
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).
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:
---- Applied configuration ds
/
Operational state ds |----- System controlled configuration ds
\
---- System state ds
Wilton Expires December 5, 2016 [Page 8]
Internet-Draft Refined YANG Datastores June 2016
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.
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).
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.
5.8. Applied Configuration Datastore (Abstract)
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.
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.
Being an abstract datastore that is part of the operational state
datastore it is read-only.
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).
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).
Wilton Expires December 5, 2016 [Page 9]
Internet-Draft Refined YANG Datastores June 2016
5.9. System Controlled Configuration Datastore (Abstract)
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.
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).
Being an abstract datastore that is part of the operational state
datastore it is read-only.
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.
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).
5.10. System State Datastore (Abstract)
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.
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.
Being an abstract datastore that is part of the operational state
datastore it is read-only.
Wilton Expires December 5, 2016 [Page 10]
Internet-Draft Refined YANG Datastores June 2016
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.
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).
6. Discussion points
6.1. Missing resources
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.
6.2. System controlled resources
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).
6.3. Auto-configured or auto-negotiated values
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.
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.
Wilton Expires December 5, 2016 [Page 11]
Internet-Draft Refined YANG Datastores June 2016
6.4. Operational State with Different Origins
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.
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.
7. Implications of the Refined Datastore Model
7.1. Implications for opstate unaware clients
This sections describes the implications for all opstate unaware
clients, which includes all existing standards compliant NETCONF/
RESTCONF clients.
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).
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:
1. 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,
Wilton Expires December 5, 2016 [Page 12]
Internet-Draft Refined YANG Datastores June 2016
this change would only affect new YANG models. No existing YANG
models would be affected by this change.
2. 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 With-defaults Capability
for NETCONF [RFC6243].
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 With-defaults Capability for NETCONF [RFC6243].
7.1.1. Upgradeability
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.
7.2. Implications for opstate aware clients
This sections describes the implications for all opstate aware
clients.
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.
In particular, depending on the protocol semantics, an opstate aware
device would be expected to support the following datastores/
requests:
o Startup configuration ds - (already supported in NETCONF, implicit
in RESTCONF)
o Persistent configuration ds - edit-config and get-config requests
only (added to NETCONF, implicit in RESTCONF)
Wilton Expires December 5, 2016 [Page 13]
Internet-Draft Refined YANG Datastores June 2016
o 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)
o Operational state ds - get request only (added to NETCONF,
optionally added to RESTCONF)
o Candidate configuration ds - optional (already supported in
NETCONF, implicit in RESTCONF)
o 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)
Support for operations on the following datastores would be optional:
o Ephemeral configuration ds - get-config requests only
o Applied configuration ds - get requests only
o System controlled configuration ds - get requests only
o System state datastore - get requests only
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.
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:
o 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).
o 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).
Wilton Expires December 5, 2016 [Page 14]
Internet-Draft Refined YANG Datastores June 2016
o 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.
8. Acknowledgements
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 draft-schoenw-netmod-
revised-datastores [I-D.schoenw-netmod-revised-datastores], and
reuses some of the structure and text from that document.
Work from the following internet drafts have helped form the basis of
the datastore solution described in this draft:
o draft-bjorklund-netmod-operational
[I-D.bjorklund-netmod-operational]
o draft-ietf-netmod-opstate-reqs [I-D.ietf-netmod-opstate-reqs]
o draft-kwatsen-netmod-opstate [I-D.kwatsen-netmod-opstate]
o draft-openconfig-netmod-opstate [I-D.openconfig-netmod-opstate]
o draft-schoenw-netmod-revised-datastores
[I-D.schoenw-netmod-revised-datastores]
o draft-wilton-netmod-opstate-yang [I-D.wilton-netmod-opstate-yang]
o draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state]
The following people were authors to these Internet-Drafts or
otherwise actively involved in the discussions that led to this
document:
o Lou Berger, Labn Consulting, <lberger@labn.net>
o Andy Biermann, YumaWorks, <andy@yumaworks.com>
o Martin Bjorklund, Tail-f Systems, <mbj@tail-f.com>
o Susan Hares, Huawei, <shares@ndzh.com>
o Jeff Haas, Juniper Networks, <jhaas@juniper.net>
Wilton Expires December 5, 2016 [Page 15]
Internet-Draft Refined YANG Datastores June 2016
o Marcus Hines, Google, <hines@google.com>
o Christian Hopps, Cisco Systems, <chopps@chopps.org>
o Acee Lindem, Cisco Systems, <acee@cisco.com>
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>
o Juergen Schoenwaelder, Jacobs University Bremen
<j.schoenwaelder@jacobs-university.de>
o Anees Shaikh, Google, <aashaikh@google.com>
o Rob Shakir, Jive Communications, <rjs@rob.sh>
o Kent Watsen, Juniper Networks, <kwatsen@juniper.net>
9. IANA Considerations
None
10. Security Considerations
This document discusses a conceptual model of datastores for network
management using NETCONF/RESTCONF and YANG. It has no security
impact on the Internet.
11. References
11.1. Normative References
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for
NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011,
<http://www.rfc-editor.org/info/rfc6243>.
11.2. Informative References
[I-D.bjorklund-netmod-operational]
Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
and YANG", draft-bjorklund-netmod-operational-00 (work in
progress), October 2012.
Wilton Expires December 5, 2016 [Page 16]
Internet-Draft Refined YANG Datastores June 2016
[I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-09 (work in
progress), May 2016.
[I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.kwatsen-netmod-opstate]
Watsen, K., Bierman, A., Bjorklund, M., and J.
Schoenwaelder, "Operational State Enhancements for YANG,
NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02
(work in progress), February 2016.
[I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG", draft-openconfig-
netmod-opstate-01 (work in progress), July 2015.
[I-D.schoenw-netmod-revised-datastores]
Schoenwaelder, J., "A Revised Conceptual Model for YANG
Datastores", draft-schoenw-netmod-revised-datastores-00
(work in progress), May 2016.
[I-D.wilton-netmod-opstate-yang]
Wilton, R., ""With-config-state" Capability for NETCONF/
RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in
progress), December 2015.
[RFC6244] Shafer, P., "An Architecture for Network Management Using
NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
2011, <http://www.rfc-editor.org/info/rfc6244>.
Author's Address
Robert Wilton (editor)
Cisco Systems
Email: rwilton@cisco.com
Wilton Expires December 5, 2016 [Page 17]
