[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/