Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 8342 Tail-f Systems
Updates: 7950 J. Schoenwaelder
Category: Standards Track Jacobs University
ISSN: 2070-1721 P. Shafer
K. Watsen
Juniper Networks
R. Wilton
Cisco Systems
March 2018
Internet Engineering Task Force (IETF) M. Bjorklund
Request for Comments: 8342 Tail-f Systems
Updates: 7950 J. Schoenwaelder
Category: Standards Track Jacobs University
ISSN: 2070-1721 P. Shafer
K. Watsen
Juniper Networks
R. Wilton
Cisco Systems
March 2018
Network Management Datastore Architecture (NMDA)
网络管理数据存储体系结构（NMDA）
Abstract
摘要
Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.
数据存储是一个基本概念，它将用YANG数据建模语言编写的数据模型绑定到网络管理协议，如网络配置协议（NETCONF）和RESTCONF。本文档根据使用初始simpler模型获得的经验定义了数据存储的体系结构框架，解决了初始模型中未得到很好支持的需求。本文档更新了RFC 7950。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8342.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8342.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Objectives ......................................................4
3. Terminology .....................................................5
4. Background ......................................................8
4.1. Original Model of Datastores ...............................9
5. Architectural Model of Datastores ..............................11
5.1. Conventional Configuration Datastores .....................12
5.1.1. The Startup Configuration Datastore (<startup>) ....12
5.1.2. The Candidate Configuration Datastore
(<candidate>) ......................................13
5.1.3. The Running Configuration Datastore (<running>) ....13
5.1.4. The Intended Configuration Datastore (<intended>) ..13
5.2. Dynamic Configuration Datastores ..........................14
5.3. The Operational State Datastore (<operational>) ...........14
5.3.1. Remnant Configuration ..............................16
5.3.2. Missing Resources ..................................16
5.3.3. System-Controlled Resources ........................16
5.3.4. Origin Metadata Annotation .........................17
6. Implications on YANG ...........................................18
6.1. XPath Context .............................................18
6.2. Invocation of Actions and RPCs ............................19
7. YANG Modules ...................................................20
8. IANA Considerations ............................................26
8.1. Updates to the IETF XML Registry ..........................26
8.2. Updates to the YANG Module Names Registry .................27
9. Security Considerations ........................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
1. Introduction ....................................................3
2. Objectives ......................................................4
3. Terminology .....................................................5
4. Background ......................................................8
4.1. Original Model of Datastores ...............................9
5. Architectural Model of Datastores ..............................11
5.1. Conventional Configuration Datastores .....................12
5.1.1. The Startup Configuration Datastore (<startup>) ....12
5.1.2. The Candidate Configuration Datastore
(<candidate>) ......................................13
5.1.3. The Running Configuration Datastore (<running>) ....13
5.1.4. The Intended Configuration Datastore (<intended>) ..13
5.2. Dynamic Configuration Datastores ..........................14
5.3. The Operational State Datastore (<operational>) ...........14
5.3.1. Remnant Configuration ..............................16
5.3.2. Missing Resources ..................................16
5.3.3. System-Controlled Resources ........................16
5.3.4. Origin Metadata Annotation .........................17
6. Implications on YANG ...........................................18
6.1. XPath Context .............................................18
6.2. Invocation of Actions and RPCs ............................19
7. YANG Modules ...................................................20
8. IANA Considerations ............................................26
8.1. Updates to the IETF XML Registry ..........................26
8.2. Updates to the YANG Module Names Registry .................27
9. Security Considerations ........................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Guidelines for Defining Datastores ....................31
A.1. Define Which YANG Modules Can Be Used in the Datastore .....31
A.2. Define Which Subset of YANG-Modeled Data Applies ...........31
A.3. Define How Data Is Actualized ..............................31
A.4. Define Which Protocols Can Be Used .........................31
A.5. Define YANG Identities for the Datastore ...................32
Appendix B. Example of an Ephemeral Dynamic Configuration
Datastore .............................................32
Appendix C. Example Data ..........................................33
C.1. System Example .............................................34
C.2. BGP Example ................................................37
C.2.1. Datastores .............................................38
C.2.2. Adding a Peer ..........................................38
C.2.3. Removing a Peer ........................................39
C.3. Interface Example ..........................................40
C.3.1. Pre-provisioned Interfaces .............................41
C.3.2. System-Provided Interface ..............................42
Acknowledgments ...................................................43
Authors' Addresses ................................................44
Appendix A. Guidelines for Defining Datastores ....................31
A.1. Define Which YANG Modules Can Be Used in the Datastore .....31
A.2. Define Which Subset of YANG-Modeled Data Applies ...........31
A.3. Define How Data Is Actualized ..............................31
A.4. Define Which Protocols Can Be Used .........................31
A.5. Define YANG Identities for the Datastore ...................32
Appendix B. Example of an Ephemeral Dynamic Configuration
Datastore .............................................32
Appendix C. Example Data ..........................................33
C.1. System Example .............................................34
C.2. BGP Example ................................................37
C.2.1. Datastores .............................................38
C.2.2. Adding a Peer ..........................................38
C.2.3. Removing a Peer ........................................39
C.3. Interface Example ..........................................40
C.3.1. Pre-provisioned Interfaces .............................41
C.3.2. System-Provided Interface ..............................42
Acknowledgments ...................................................43
Authors' Addresses ................................................44
This document provides an architectural framework for datastores as they are used by network management protocols such as the Network Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], and the YANG data modeling language [RFC7950]. Datastores are a fundamental concept binding network management data models to network management protocols. Agreement on a common architectural model of datastores ensures that data models can be written in a way that is network management protocol agnostic. This architectural framework identifies a set of conceptual datastores, but it does not mandate that all network management protocols expose all these conceptual datastores. This architecture is agnostic with regard to the encoding used by network management protocols.
本文档为网络管理协议（如网络配置协议（NETCONF）[RFC6241]、RESTCONF[RFC8040]和YANG数据建模语言[RFC7950]使用的数据存储提供了一个体系结构框架。数据存储是将网络管理数据模型绑定到网络管理协议的基本概念。关于数据存储的通用体系结构模型的协议确保了数据模型可以以与网络管理协议无关的方式编写。该体系结构框架确定了一组概念数据存储，但并不要求所有网络管理协议公开所有这些概念数据存储。该体系结构对于网络管理协议使用的编码是不可知的。
This document updates RFC 7950 by refining the definition of the accessible tree for some XML Path Language (XPath) context (see Section 6.1) and the invocation context of operations (see Section 6.2).
本文档通过为某些XML路径语言（XPath）上下文（参见第6.1节）和操作调用上下文（参见第6.2节）细化可访问树的定义来更新RFC 7950。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Network management data objects can often take two different values: the value configured by the user or an application (configuration) and the value that the device is actually using (operational state). These two values may be different for a number of reasons, e.g., system internal interactions with hardware, interaction with protocols or other devices, or simply the time it takes to propagate a configuration change to the software and hardware components of a system. Furthermore, configuration and operational state data objects may have different lifetimes.
网络管理数据对象通常可以采用两个不同的值：用户或应用程序配置的值（配置）和设备实际使用的值（操作状态）。这两个值可能因多种原因而不同，例如，系统内部与硬件的交互、与协议或其他设备的交互，或者只是将配置更改传播到系统的软件和硬件组件所需的时间。此外，配置和操作状态数据对象可能具有不同的生存期。
The original model of datastores required these data objects to be modeled twice in the YANG schema -- as "config true" objects and as "config false" objects. The convention adopted by the interfaces data model [RFC8343] and the IP data model [RFC8344] was to use two separate branches rooted at the root of the data tree: one branch for configuration data objects and one branch for operational state data objects.
数据存储的原始模型要求在YANG模式中对这些数据对象进行两次建模——作为“config true”对象和“config false”对象。接口数据模型[RFC8343]和IP数据模型[RFC8344]采用的约定是使用两个根在数据树根上的独立分支：一个分支用于配置数据对象，另一个分支用于操作状态数据对象。
The duplication of definitions and the ad hoc separation of operational state data from configuration data lead to a number of problems. Having configuration and operational state data in separate branches in the data model is operationally complicated and impacts the readability of module definitions. Furthermore, the relationship between the branches is not machine readable, and filter expressions operating on configuration and on related operational state are different.
定义的重复和操作状态数据与配置数据的特殊分离导致了许多问题。在数据模型中，将配置和操作状态数据放在不同的分支中，操作起来很复杂，会影响模块定义的可读性。此外，分支之间的关系不是机器可读的，并且在配置和相关操作状态下操作的过滤器表达式是不同的。
With the revised architectural model of datastores defined in this document, the data objects are defined only once in the YANG schema but independent instantiations can appear in different datastores, e.g., one for a configured value and another for an operationally used value. This provides a more elegant and simpler solution to the problem.
在本文件中定义了经修订的数据存储体系结构模型后，数据对象在YANG模式中仅定义一次，但独立的实例化可以出现在不同的数据存储中，例如，一个用于配置的值，另一个用于操作使用的值。这为问题提供了一个更优雅、更简单的解决方案。
The revised architectural model of datastores supports additional datastores for systems that support more advanced processing chains converting configuration to operational state. For example, some systems support configuration that is not currently used (so-called "inactive configuration") or they support configuration templates that are used to expand configuration data via a common template.
修改后的数据存储体系结构模型为支持将配置转换为操作状态的更高级处理链的系统支持额外的数据存储。例如，一些系统支持当前未使用的配置（所谓的“非活动配置”），或者它们支持用于通过公共模板扩展配置数据的配置模板。
This document defines the following terminology. Some of the terms are revised definitions of terms originally defined in [RFC6241] and [RFC7950] (see also Section 4). The revised definitions are semantically equivalent to the definitions found in [RFC6241] and [RFC7950]. It is expected that the revised definitions provided in this section will replace the definitions in [RFC6241] and [RFC7950] when these documents are revised.
本文件定义了以下术语。其中一些术语是[RFC6241]和[RFC7950]中最初定义的术语的修订定义（另见第4节）。修订后的定义在语义上等同于[RFC6241]和[RFC7950]中的定义。预计在修订这些文件时，本节中提供的修订定义将取代[RFC6241]和[RFC7950]中的定义。
o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG data tree.
o 数据存储：存储和访问信息的概念性场所。例如，可以使用文件、数据库、闪存位置或其组合来实现数据存储。数据存储映射到实例化的数据树。
o schema node: A node in the schema tree. The formal definition is provided in RFC 7950.
o 架构节点：架构树中的节点。RFC 7950中提供了正式定义。
o datastore schema: The combined set of schema nodes for all modules supported by a particular datastore, taking into consideration any deviations and enabled features for that datastore.
o 数据存储模式：特定数据存储支持的所有模块的模式节点的组合集，考虑到该数据存储的任何偏差和启用的功能。
o configuration: Data that is required to get a device from its initial default state into a desired operational state. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources.
o 配置：使设备从初始默认状态进入所需操作状态所需的数据。该数据使用“config true”节点在YANG中建模。配置可以来自不同的源。
o configuration datastore: A datastore holding configuration.
o 配置数据存储：保存配置的数据存储。
o running configuration datastore: A configuration datastore holding the current configuration of the device. It may include configuration that requires further transformations before it can be applied. This datastore is referred to as "<running>".
o 运行配置数据存储：保存设备当前配置的配置数据存储。它可能包括需要进一步转换才能应用的配置。此数据存储被称为“<running>”。
o candidate configuration datastore: A configuration datastore that can be manipulated without impacting the device's running configuration datastore and that can be committed to the running configuration datastore. This datastore is referred to as "<candidate>".
o 候选配置数据存储：可以在不影响设备运行的配置数据存储的情况下操作的配置数据存储，并且可以提交到运行的配置数据存储。此数据存储被称为“<candidate>”。
o startup configuration datastore: A configuration datastore holding the configuration loaded by the device into the running configuration datastore when it boots. This datastore is referred to as "<startup>".
o 启动配置数据存储：一种配置数据存储，在设备启动时保存由设备加载到运行配置数据存储中的配置。此数据存储被称为“<startup>”。
o intended configuration: Configuration that is intended to be used by the device. It represents the configuration after all configuration transformations to <running> have been performed and is the configuration that the system attempts to apply.
o 预期配置：设备预期使用的配置。它表示执行到<running>的所有配置转换后的配置，并且是系统尝试应用的配置。
o intended configuration datastore: A configuration datastore holding the complete intended configuration of the device. This datastore is referred to as "<intended>".
o 预期配置数据存储：保存设备完整预期配置的配置数据存储。此数据存储被称为“<designed>”。
o configuration transformation: The addition, modification, or removal of configuration between the <running> and <intended> datastores. Examples of configuration transformations include the removal of inactive configuration and the configuration produced through the expansion of templates.
o 配置转换：在<运行>和<预期>数据存储之间添加、修改或删除配置。配置转换的示例包括删除非活动配置和通过扩展模板生成的配置。
o conventional configuration datastore: One of the following set of configuration datastores: <running>, <startup>, <candidate>, and <intended>. These datastores share a common datastore schema, and protocol operations allow copying data between these datastores. The term "conventional" is chosen as a generic umbrella term for these datastores.
o 常规配置数据存储：以下配置数据存储集之一：<running>、<startup>、<candidate>和<designed>。这些数据存储共享一个公共数据存储架构，协议操作允许在这些数据存储之间复制数据。术语“常规”被选为这些数据存储的通用总括术语。
o conventional configuration: Configuration that is stored in any of the conventional configuration datastores.
o 常规配置：存储在任何常规配置数据存储中的配置。
o dynamic configuration datastore: A configuration datastore holding configuration obtained dynamically during the operation of a device through interaction with other systems, rather than through one of the conventional configuration datastores.
o 动态配置数据存储：一种配置数据存储，保存设备运行期间通过与其他系统交互而不是通过常规配置数据存储之一动态获得的配置。
o dynamic configuration: Configuration obtained via a dynamic configuration datastore.
o 动态配置：通过动态配置数据存储获得的配置。
o learned configuration: Configuration that has been learned via protocol interactions with other systems and that is neither conventional nor dynamic configuration.
o 学习配置：通过与其他系统的协议交互学习的配置，既不是常规配置，也不是动态配置。
o system configuration: Configuration that is supplied by the device itself.
o 系统配置：由设备本身提供的配置。
o default configuration: Configuration that is not explicitly provided but for which a value defined in the data model is used.
o 默认配置：未明确提供但使用数据模型中定义的值的配置。
o applied configuration: Configuration that is actively in use by a device. Applied configuration originates from conventional, dynamic, learned, system, and default configuration.
o 应用配置：设备正在使用的配置。应用配置源于常规配置、动态配置、学习配置、系统配置和默认配置。
o system state: The additional data on a system that is not configuration, such as read-only status information and collected statistics. System state is transient and modified by interactions with internal components or other systems. System state is modeled in YANG using "config false" nodes.
o 系统状态：系统上未配置的附加数据，如只读状态信息和收集的统计信息。系统状态是瞬态的，并通过与内部组件或其他系统的交互作用进行修改。系统状态在YANG中使用“config false”节点建模。
o operational state: The combination of applied configuration and system state.
o 操作状态：应用配置和系统状态的组合。
o operational state datastore: A datastore holding the complete operational state of the device. This datastore is referred to as "<operational>".
o 操作状态数据存储：保存设备完整操作状态的数据存储。此数据存储被称为“<operational>”。
o origin: A metadata annotation indicating the origin of a data item.
o 原点：指示数据项原点的元数据注释。
o remnant configuration: Configuration that remains part of the applied configuration for a period of time after it has been removed from the intended configuration or dynamic configuration. The time period may be minimal or may last until all resources used by the newly deleted configuration (e.g., network connections, memory allocations, file handles) have been deallocated.
o 残余配置：从预期配置或动态配置中删除后，在一段时间内保留应用配置的一部分的配置。该时间段可能很短，也可能持续到新删除的配置所使用的所有资源（例如，网络连接、内存分配、文件句柄）被释放为止。
The following additional terms are not datastore specific, but they are commonly used and are thus defined here as well:
以下附加术语不是特定于数据存储的，但它们是常用的，因此也在此处定义：
o client: An entity that can access YANG-defined data on a server, over some network management protocol.
o 客户机：可以通过某种网络管理协议访问服务器上定义的数据的实体。
o server: An entity that provides access to YANG-defined data to a client, over some network management protocol.
o 服务器：通过某种网络管理协议向客户机提供对已定义数据的访问的实体。
o notification: A server-initiated message indicating that a certain event has been recognized by the server.
o 通知：服务器启动的消息，指示服务器已识别某个事件。
o remote procedure call: An operation that can be invoked by a client on a server.
o 远程过程调用：可由服务器上的客户端调用的操作。
NETCONF [RFC6241] provides the following definitions:
NETCONF[RFC6241]提供了以下定义：
o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof.
o 数据存储：存储和访问信息的概念性场所。例如，可以使用文件、数据库、闪存位置或其组合来实现数据存储。
o configuration datastore: The datastore holding the complete set of configuration that is required to get a device from its initial default state into a desired operational state.
o 配置数据存储：保存设备从初始默认状态进入所需操作状态所需的完整配置集的数据存储。
YANG 1.1 [RFC7950] provides the following refinements when NETCONF is used with YANG (which is the usual case, but note that NETCONF was defined before YANG existed):
YANG 1.1[RFC7950]在与YANG一起使用NETCONF时提供了以下改进（这是通常的情况，但请注意，NETCONF是在YANG存在之前定义的）：
o datastore: When modeled with YANG, a datastore is realized as an instantiated data tree.
o 数据存储：使用YANG建模时，数据存储实现为实例化的数据树。
o configuration datastore: When modeled with YANG, a configuration datastore is realized as an instantiated data tree with configuration.
o 配置数据存储：使用YANG建模时，配置数据存储实现为带有配置的实例化数据树。
[RFC6244] defined operational state data as follows:
[RFC6244]定义的运行状态数据如下：
o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols.
o 操作状态数据是系统在运行时获得的一组数据，它影响系统的行为，类似于配置数据。与配置数据不同，操作状态是瞬态的，通过与内部组件或其他系统的交互，通过专用协议进行修改。
Section 4.3.3 of [RFC6244] discusses operational state and mentions, among other things, the option to consider operational state as being stored in another datastore. Section 4.4 of [RFC6244] then concludes that, at the time of its writing, modeling state as distinct leafs and distinct branches is the recommended approach.
[RCF6244]第4.3.3节讨论了操作状态，并提到了将操作状态视为存储在另一数据存储区中的选项。[RFC6244]第4.4节得出结论，在撰写本文时，将状态建模为不同的叶和分支是推荐的方法。
Implementation experience and requests from operators [OpState-Reqs] [OpState-Modeling] indicate that the datastore model initially designed for NETCONF and refined by YANG needs to be extended. In particular, the notion of intended configuration and applied configuration has developed.
实施经验和运营商[OpState Reqs][OpState Modeling]的要求表明，最初为NETCONF设计并由YANG改进的数据存储模型需要扩展。特别是，预期配置和应用配置的概念已经形成。
The following drawing shows the original model of datastores as it is currently used by NETCONF [RFC6241]:
下图显示了NETCONF[RFC6241]当前使用的数据存储的原始模型：
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
v
operational state <--- control plane
(cf, ro)
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
v
operational state <--- control plane
(cf, ro)
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote datastores
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote datastores
Figure 1
图1
Note that this diagram simplifies the model: "read-only" (ro) and "read-write" (rw) are to be understood from the client's perspective, at a conceptual level. In NETCONF, for example, support for <candidate> and <startup> is optional, and <running> does not have to be writable. Furthermore, <startup> can only be modified by copying <running> to <startup> in the standardized NETCONF datastore editing model. The RESTCONF protocol does not expose these differences and instead provides only a writable unified datastore, which hides whether edits are done through <candidate>, by directly modifying <running>, or via some other implementation-specific mechanism. RESTCONF also hides how configuration is made persistent. Note that implementations may also have additional datastores that can propagate changes to <running>. NETCONF explicitly mentions so-called "named datastores".
请注意，此图简化了模型：“只读”（ro）和“读写”（rw）将从客户的角度从概念层面理解。例如，在NETCONF中，对<candidate>和<startup>的支持是可选的，并且<running>不必是可写的。此外，<startup>只能通过将<running>复制到标准化NETCONF数据存储编辑模型中的<startup>来修改。RESTCONF协议没有公开这些差异，而是只提供了一个可写的统一数据存储，它隐藏了编辑是通过<candidate>、直接修改<running>、还是通过其他特定于实现的机制完成的。RESTCONF还隐藏了如何使配置持久化。请注意，实现还可能有额外的数据存储，可以将更改传播到<running>。NETCONF明确提到了所谓的“命名数据存储”。
Some observations:
一些意见：
o Operational state has not been defined as a datastore, although there were proposals in the past to introduce an operational state datastore.
o 操作状态尚未定义为数据存储，尽管过去有人建议引入操作状态数据存储。
o The NETCONF <get> operation returns the contents of <running> together with the operational state. It is therefore necessary that "config false" data be in a different branch than the "config true" data if the operational state can have a different lifetime compared to configuration or if configuration is not immediately or successfully applied.
o NETCONF<get>操作返回<running>的内容以及操作状态。因此，如果运行状态的生存期与配置不同，或者配置未立即或成功应用，则“配置错误”数据必须位于与“配置正确”数据不同的分支中。
o Several implementations have proprietary mechanisms that allow clients to store inactive data in <running>. Inactive data is conceptually removed before validation.
o 一些实现具有专有机制，允许客户端在<running>中存储非活动数据。从概念上讲，非活动数据在验证之前被删除。
o Some implementations have proprietary mechanisms that allow clients to define configuration templates in <running>. These templates are expanded automatically by the system, and the resulting configuration is applied internally.
o 一些实现具有专有机制，允许客户端在<running>中定义配置模板。系统会自动扩展这些模板，并在内部应用生成的配置。
o Some operators have reported that it is essential for them to be able to retrieve the configuration that has actually been successfully applied, which may be a subset or a superset of the <running> configuration.
o 一些操作员报告说，他们必须能够检索实际已成功应用的配置，该配置可能是<running>配置的子集或超集。
Below is a new conceptual model of datastores, extending the original model in order to reflect the experience gained with the original model.
下面是一个新的数据存储概念模型，它扩展了原始模型，以反映使用原始模型获得的经验。
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of nodes marked as
| // "inactive", expansion of
| // templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
| // changes applied, subject to
| // local factors, e.g., missing
| // resources, delays
|
dynamic | +-------- learned configuration
configuration | +-------- system configuration
datastores -----+ | +-------- default configuration
| | |
v v v
+---------------+
| <operational> | <-- system state
| (ct + cf, ro) |
+---------------+
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of nodes marked as
| // "inactive", expansion of
| // templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
| // changes applied, subject to
| // local factors, e.g., missing
| // resources, delays
|
dynamic | +-------- learned configuration
configuration | +-------- system configuration
datastores -----+ | +-------- default configuration
| | |
v v v
+---------------+
| <operational> | <-- system state
| (ct + cf, ro) |
+---------------+
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote named datastores
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote named datastores
Figure 2
图2
The conventional configuration datastores are a set of configuration datastores that share exactly the same datastore schema, allowing data to be copied between them. The term is meant as a generic umbrella description of these datastores. If a module does not contain any configuration data nodes and it is not needed to satisfy any imports, then it MAY be omitted from the datastore schema for the conventional configuration datastores. The set of datastores include:
传统的配置数据存储是一组共享完全相同的数据存储模式的配置数据存储，允许在它们之间复制数据。该术语是对这些数据存储的通用总括性描述。如果模块不包含任何配置数据节点，并且不需要满足任何导入，则可以从传统配置数据存储的数据存储模式中省略该模块。数据存储集包括：
o <running>
o <running>
o <candidate>
o <candidate>
o <startup>
o <startup>
o <intended>
o <designed>
Other conventional configuration datastores may be defined in future documents.
其他常规配置数据存储可能在未来的文档中定义。
The flow of data between these datastores is depicted in Section 5.
第5节描述了这些数据存储之间的数据流。
The specific protocols may define explicit operations to copy between these datastores, e.g., NETCONF defines the <copy-config> operation.
特定的协议可以定义在这些数据存储之间进行复制的显式操作，例如，NETCONF定义<copy config>操作。
The startup configuration datastore (<startup>) is a configuration datastore holding the configuration loaded by the device when it boots. <startup> is only present on devices that separate the startup configuration from the running configuration datastore.
启动配置数据存储（<startup>）是一个配置数据存储，保存设备启动时加载的配置<startup>仅存在于将启动配置与运行的配置数据存储区分开的设备上。
The startup configuration datastore may not be supported by all protocols or implementations.
并非所有协议或实现都支持启动配置数据存储。
On devices that support non-volatile storage, the contents of <startup> will typically persist across reboots via that storage. At boot time, the device loads the saved startup configuration into <running>. To save a new startup configuration, data is copied to <startup> via either implicit or explicit protocol operations.
在支持非易失性存储的设备上，<startup>的内容通常会通过该存储在重新启动期间保持不变。启动时，设备将保存的启动配置加载到<running>中。要保存新的启动配置，通过隐式或显式协议操作将数据复制到<startup>。
The candidate configuration datastore (<candidate>) is a configuration datastore that can be manipulated without impacting the device's current configuration and that can be committed to <running>.
候选配置数据存储（<candidate>）是一种配置数据存储，可以在不影响设备当前配置的情况下进行操作，并且可以提交到<running>。
The candidate configuration datastore may not be supported by all protocols or implementations.
候选配置数据存储可能不受所有协议或实现的支持。
<candidate> does not typically persist across reboots, even in the presence of non-volatile storage. If <candidate> is stored using non-volatile storage, it is reset at boot time to the contents of <running>.
<candidate>通常不会在重新启动期间持续存在，即使在存在非易失性存储的情况下也是如此。如果使用非易失性存储器存储<candidate>，则在引导时将其重置为<running>的内容。
The running configuration datastore (<running>) is a configuration datastore that holds the current configuration of the device. It MAY include configuration that requires further transformation before it can be applied, e.g., inactive configuration, or template-mechanism-oriented configuration that needs further expansion. However, <running> MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950].
正在运行的配置数据存储（<running>）是保存设备当前配置的配置数据存储。它可能包括需要进一步转换才能应用的配置，例如，非活动配置，或需要进一步扩展的面向模板机制的配置。但是，<running>必须始终是有效的配置数据树，如[RFC7950]第8.1节所定义。
<running> MUST be supported if the device can be configured via conventional configuration datastores.
如果可以通过常规配置数据存储配置设备，则必须支持<running>。
If a device does not have a distinct <startup> and non-volatile storage is available, the device will typically use that non-volatile storage to allow <running> to persist across reboots.
如果设备没有独特的<startup>，且非易失性存储可用，则该设备通常会使用该非易失性存储来允许<running>在重新启动期间保持。
The intended configuration datastore (<intended>) is a read-only configuration datastore. It represents the configuration after all configuration transformations to <running> are performed (e.g., template expansion, removal of inactive configuration) and is the configuration that the system attempts to apply.
预期配置数据存储（<designed>）是只读配置数据存储。它表示执行到<running>的所有配置转换后的配置（例如，模板扩展、删除非活动配置），并且是系统尝试应用的配置。
<intended> is tightly coupled to <running>. Whenever data is written to <running>, the server MUST also immediately update and validate <intended>.
<designed>与<running>紧密耦合。每当数据写入<running>时，服务器还必须立即更新并验证<designed>。
<intended> MAY also be updated independently of <running> if the effect of a configuration transformation changes, but <intended> MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950].
如果配置转换的效果发生变化，<designed>也可以独立于<running>进行更新，但<designed>必须始终是有效的配置数据树，如[RFC7950]第8.1节所定义。
For simple implementations, <running> and <intended> are identical.
对于简单的实现，<running>和<designed>是相同的。
The contents of <intended> are also related to the "config true" subset of <operational>; hence, a client can determine to what extent the intended configuration is currently in use by checking to see whether the contents of <intended> also appear in <operational>.
<destined>的内容也与<operational>的“config true”子集相关；因此，客户机可以通过检查<designed>的内容是否也出现在<operation>中来确定当前使用的预期配置的程度。
<intended> does not persist across reboots; its relationship with <running> makes that unnecessary.
<designed>不会在重新启动期间持续存在；它与<running>的关系使得这一点变得不必要。
Currently, there are no standard mechanisms defined that affect <intended> so that it would have different content than <running>, but this architecture allows for such mechanisms to be defined.
目前，没有定义影响<destined>的标准机制，因此它将具有与<running>不同的内容，但此体系结构允许定义此类机制。
One example of such a mechanism is support for marking nodes as inactive in <running>. Inactive nodes are not copied to <intended>. A second example is support for templates, which can perform transformations on the configuration from <running> to the configuration written to <intended>.
这种机制的一个例子是支持在<running>中将节点标记为非活动。非活动节点不会复制到<designed>。第二个例子是对模板的支持，它可以对配置执行从<running>到<destined>的转换。
The model recognizes the need for dynamic configuration datastores that are, by definition, not part of the persistent configuration of a device. In some contexts, these have been termed "ephemeral datastores", since the information is ephemeral, i.e., lost upon reboot. The dynamic configuration datastores interact with the rest of the system through <operational>.
该模型认识到需要动态配置数据存储，根据定义，动态配置数据存储不是设备持久配置的一部分。在某些情况下，这些被称为“短暂的数据存储”，因为信息是短暂的，即在重新启动时丢失。动态配置数据存储通过<operational>与系统的其余部分交互。
The datastore schema for a dynamic configuration datastore MAY differ from the datastore schema used for conventional configuration datastores. If a module does not contain any configuration data nodes and it is not needed to satisfy any imports, then it MAY be omitted from the datastore schema for the dynamic configuration datastore.
动态配置数据存储的数据存储模式可能不同于用于常规配置数据存储的数据存储模式。如果模块不包含任何配置数据节点，并且不需要满足任何导入，则可以从动态配置数据存储的数据存储架构中省略该模块。
The operational state datastore (<operational>) is a read-only datastore that consists of all "config true" and "config false" nodes defined in the datastore's schema. In the original NETCONF model, the operational state only had "config false" nodes. The reason for incorporating "config true" nodes here is to be able to expose all operational settings without having to replicate definitions in the data models.
操作状态数据存储（<operational>）是一个只读数据存储，由数据存储架构中定义的所有“config true”和“config false”节点组成。在最初的NETCONF模型中，操作状态只有“config false”节点。此处合并“config true”节点的原因是能够公开所有操作设置，而无需复制数据模型中的定义。
<operational> contains system state and all configuration actually used by the system. This includes all applied configuration from <intended>, learned configuration, system-provided configuration, and default values defined by any supported data models. In addition, <operational> also contains applied configuration from dynamic configuration datastores.
<operational>包含系统状态和系统实际使用的所有配置。这包括从<预期>中应用的所有配置、学习的配置、系统提供的配置以及任何支持的数据模型定义的默认值。此外，<operational>还包含来自动态配置数据存储的应用配置。
The datastore schema for <operational> MUST be a superset of the combined datastore schema used in all configuration datastores, except that configuration data nodes supported in a configuration datastore MAY be omitted from <operational> if a server is not able to accurately report them.
<operational>的数据存储架构必须是所有配置数据存储中使用的组合数据存储架构的超集，除非如果服务器无法准确报告配置数据存储中支持的配置数据节点，则可以从<operational>中省略这些节点。
Requests to retrieve nodes from <operational> always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device.
如果节点存在，则从<operational>检索节点的请求始终返回正在使用的值，而不考虑模块中指定的任何默认值。如果给定节点未返回任何值，则表示设备未使用该节点。
The interpretation of what constitutes being "in use" by the system is dependent on both the schema definition and the device implementation. Generally, functionality that is enabled and operational on the system would be considered to be "in use". Conversely, functionality that is neither enabled nor operational on the system is considered not to be "in use"; hence, it SHOULD be omitted from <operational>.
系统“正在使用”的含义取决于模式定义和设备实现。通常，在系统上启用和运行的功能将被视为“正在使用”。相反，系统上既未启用也未运行的功能被视为未“使用中”；因此，应将其从<operation>中省略。
<operational> SHOULD conform to any constraints specified in the data model, but given the principal aim of returning "in use" values, it is possible that constraints MAY be violated under some circumstances (e.g., an abnormal value is "in use", the structure of a list is being modified, or remnant configuration (see Section 5.3.1) still exists). Note that deviations SHOULD be used when it is known in advance that a device does not fully conform to the <operational> schema.
<operational>应符合数据模型中规定的任何约束，但鉴于返回“使用中”值的主要目的，在某些情况下可能会违反约束（例如，“使用中”存在异常值，列表结构正在修改，或剩余配置（见第5.3.1节）仍然存在）。请注意，如果事先知道设备不完全符合<operational>模式，则应使用偏差。
Only semantic constraints MAY be violated. These are the YANG "when", "must", "mandatory", "unique", "min-elements", and "max-elements" statements; and the uniqueness of key values.
只能违反语义约束。这些是“何时”、“必须”、“强制”、“唯一”、“最小元素”和“最大元素”语句；以及关键值的唯一性。
Syntactic constraints MUST NOT be violated, including hierarchical organization, identifiers, and type-based constraints. If a node in <operational> does not meet the syntactic constraints, then it MUST NOT be returned, and some other mechanism should be used to flag the error.
不得违反语法约束，包括层次结构、标识符和基于类型的约束。如果<operational>中的节点不满足语法约束，则不能返回该节点，应使用其他机制来标记错误。
<operational> does not persist across reboots.
<operational>不会在重新启动期间持续存在。
Changes to configuration may take time to percolate through to <operational>. During this period, <operational> may contain nodes for both the previous and current configuration, as closely as possible tracking the current operation of the device. Such remnant configuration from the previous configuration persists until the system has released resources used by the newly deleted configuration (e.g., network connections, memory allocations, file handles).
对配置的更改可能需要一段时间才能渗透到<operational>。在此期间，<operational>可能包含先前和当前配置的节点，尽可能接近地跟踪设备的当前操作。在系统释放新删除的配置所使用的资源（例如，网络连接、内存分配、文件句柄）之前，以前配置中的这种剩余配置将一直存在。
Remnant configuration is a common example of where the semantic constraints defined in the data model cannot be relied upon for <operational>, since the system may have remnant configuration whose constraints were valid with the previous configuration and that are not valid with the current configuration. Since constraints on "config false" nodes may refer to "config true" nodes, remnant configuration may force the violation of those constraints.
残余配置是数据模型中定义的语义约束不能用于<operational>的常见示例，因为系统可能具有残余配置，其约束对以前的配置有效，而对当前配置无效。由于“config false”节点上的约束可能引用“config true”节点，所以剩余配置可能会强制违反这些约束。
Configuration in <intended> can refer to resources that are not available or otherwise not physically present. In these situations, these parts of <intended> are not applied. The data appears in <intended> but does not appear in <operational>.
<designed>中的配置可以指不可用或不存在的资源。在这些情况下，<预期>的这些部分不适用。数据显示在<预期>中，但不显示在<操作>中。
A typical example is an interface configuration that refers to an interface that is not currently present. In such a situation, the interface configuration remains in <intended> but the interface configuration will not appear in <operational>.
一个典型的例子是引用当前不存在的接口的接口配置。在这种情况下，接口配置保持在<designed>中，但接口配置不会出现在<operation>中。
Note that configuration validity cannot depend on the current state of such resources, since that would imply that removing a resource might render the configuration invalid. This is unacceptable, especially given that rebooting such a device would cause it to restart with an invalid configuration. Instead, we allow configuration for missing resources to exist in <running> and <intended>, but it will not appear in <operational>.
请注意，配置有效性不能取决于此类资源的当前状态，因为这意味着删除资源可能会导致配置无效。这是不可接受的，特别是考虑到重新启动这样的设备会导致它以无效配置重新启动。相反，我们允许在<running>和<destined>中存在缺少资源的配置，但它不会出现在<operational>中。
Sometimes, resources are controlled by the device and the corresponding system-controlled data appears in (and disappears from) <operational> dynamically. If a system-controlled resource has matching configuration in <intended> when it appears, the system will try to apply the configuration; this causes the configuration to appear in <operational> eventually (if application of the configuration was successful).
有时，资源由设备控制，相应的系统控制数据在<operational>中动态显示（并从中消失）。如果系统控制的资源出现时在<预期>中有匹配的配置，系统将尝试应用该配置；这导致配置最终出现在<operational>中（如果配置应用成功）。
As configuration flows into <operational>, it is conceptually marked with a metadata annotation [RFC7952] that indicates its origin. The origin applies to all configuration nodes except non-presence containers. The "origin" metadata annotation is defined in Section 7. The values are YANG identities. The following identities are defined:
当配置流入<operational>时，它在概念上用元数据注释[RFC7952]标记，该注释指示其来源。原点应用于除非存在容器之外的所有配置节点。第7节定义了“源”元数据注释。这些值是杨氏恒等式。定义了以下标识：
o origin: abstract base identity from which the other origin identities are derived.
o 源：从中派生其他源标识的抽象基标识。
o intended: represents configuration provided by <intended>.
o 预期：表示<预期>提供的配置。
o dynamic: represents configuration provided by a dynamic configuration datastore.
o 动态：表示动态配置数据存储提供的配置。
o system: represents configuration provided by the system itself. Examples of system configuration include applied configuration for an always-existing loopback interface, or interface configuration that is auto-created due to the hardware currently present in the device.
o 系统：表示系统本身提供的配置。系统配置的示例包括始终存在的环回接口的应用配置，或由于设备中当前存在的硬件而自动创建的接口配置。
o learned: represents configuration that has been learned via protocol interactions with other systems, including such protocols as link-layer negotiations, routing protocols, and DHCP.
o 学习：表示通过与其他系统的协议交互学习的配置，包括链路层协商、路由协议和DHCP等协议。
o default: represents configuration using a default value specified in the data model, using either values in the "default" statement or any values described in the "description" statement. The default origin is only used when the configuration has not been provided by any other source.
o 默认值：使用数据模型中指定的默认值表示配置，使用“default”语句中的值或“description”语句中描述的任何值。默认原点仅在任何其他源未提供配置时使用。
o unknown: represents configuration for which the system cannot identify the origin.
o 未知：表示系统无法识别其来源的配置。
These identities can be further refined, e.g., there could be separate identities for particular types or instances of dynamic configuration datastores derived from "dynamic".
这些标识可以进一步细化，例如，对于从“动态”派生的动态配置数据存储的特定类型或实例，可以有单独的标识。
For all configuration data nodes in <operational>, the device SHOULD report the origin that most accurately reflects the source of the configuration that is in use by the system.
对于<operational>中的所有配置数据节点，设备应报告最准确地反映系统正在使用的配置源的原点。
In cases where it could be ambiguous as to which origin should be used, i.e., where the same data node value has originated from multiple sources, the "description" statement in the YANG module SHOULD be used as guidance for choosing the appropriate origin. For example:
在使用哪个原点可能不明确的情况下，即相同的数据节点值来自多个源的情况下，应使用YANG模块中的“描述”语句作为选择适当原点的指南。例如：
If, for a particular configuration node, the associated YANG "description" statement indicates that a protocol-negotiated value overrides any configured value, then the origin would be reported as "learned", even when a learned value is the same as the configured value.
如果对于特定配置节点，关联的“描述”语句指示协议协商值覆盖任何配置值，则即使学习值与配置值相同，原点也将报告为“学习”。
Conversely, if, for a particular configuration node, the associated YANG "description" statement indicates that a protocol-negotiated value does not override an explicitly configured value, then the origin would be reported as "intended", even when a learned value is the same as the configured value.
相反，如果对于特定配置节点，关联的“描述”语句指示协议协商值未覆盖显式配置值，则即使学习值与配置值相同，原点也将报告为“预期”。
In the case that a device cannot provide an accurate origin for a particular configuration data node, it SHOULD use the origin "unknown".
如果设备无法为特定配置数据节点提供准确的原点，则应使用原点“未知”。
This section updates Section 6.4.1 of RFC 7950.
本节更新了RFC 7950第6.4.1节。
If a server implements the architecture defined in this document, the accessible trees for some XPath contexts are refined as follows:
如果服务器实现本文档中定义的体系结构，则某些XPath上下文的可访问树将细化如下：
o If the XPath expression is defined in a substatement to a data node that represents system state, the accessible tree is all operational state in the server. The root node has all top-level data nodes in all modules as children.
o 如果XPath表达式是在表示系统状态的数据节点的子状态中定义的，则可访问树是服务器中的所有操作状态。根节点将所有模块中的所有顶级数据节点作为子节点。
o If the XPath expression is defined in a substatement to a "notification" statement, the accessible tree is the notification instance and all operational state in the server. If the notification is defined on the top level in a module, then the root node has the node representing the notification being defined and all top-level data nodes in all modules as children. Otherwise, the root node has all top-level data nodes in all modules as children.
o 如果XPath表达式是在“notification”语句的子语句中定义的，那么可访问树就是通知实例和服务器中的所有操作状态。如果通知是在模块的顶层定义的，则根节点具有表示要定义的通知的节点以及所有模块中的所有顶层数据节点作为子节点。否则，根节点将所有模块中的所有顶级数据节点作为子节点。
o If the XPath expression is defined in a substatement to an "input" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance and all operational state in the server. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's input parameters as children.
o 如果XPath表达式是在“rpc”或“action”语句中的“input”语句的子语句中定义的，则可访问的树是rpc或action操作实例以及服务器中的所有操作状态。根节点在所有模块中都有顶级数据节点作为子节点。此外，对于RPC，根节点还将表示RPC操作的节点定义为子节点。表示所定义操作的节点将操作的输入参数作为子节点。
o If the XPath expression is defined in a substatement to an "output" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance and all operational state in the server. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's output parameters as children.
o 如果XPath表达式是在“rpc”或“action”语句中的“output”语句的子语句中定义的，则可访问的树是rpc或action操作实例以及服务器中的所有操作状态。根节点在所有模块中都有顶级数据节点作为子节点。此外，对于RPC，根节点还将表示RPC操作的节点定义为子节点。表示所定义操作的节点将操作的输出参数作为子级。
This section updates Section 7.15 of RFC 7950.
本节更新了RFC 7950第7.15节。
Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore.
操作总是在操作状态数据存储的上下文中调用。为其调用操作的节点必须存在于操作状态数据存储中。
Note that this document does not constrain the result of invoking an RPC or action in any way. For example, an RPC might be defined to modify the contents of some datastore.
请注意，本文档不以任何方式约束调用RPC或操作的结果。例如，可以定义RPC来修改某些数据存储的内容。
<CODE BEGINS> file "ietf-datastores@2018-02-14.yang"
<CODE BEGINS> file "ietf-datastores@2018-02-14.yang"
module ietf-datastores {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
prefix ds;
module ietf-datastores {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
prefix ds;
organization "IETF Network Modeling (NETMOD) Working Group";
组织“IETF网络建模（NETMOD）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Rob Wilton
<rwilton@cisco.com>";
Author: Rob Wilton
<rwilton@cisco.com>";
description "This YANG module defines a set of identities for identifying datastores.
description“此模块定义了一组标识数据存储的标识。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8342
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
for full legal notices.";
This version of this YANG module is part of RFC 8342
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
for full legal notices.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
/*
* Identities
*/
/*
* Identities
*/
identity datastore {
description
"Abstract base identity for datastore identities.";
}
identity datastore {
description
"Abstract base identity for datastore identities.";
}
identity conventional {
base datastore;
description
"Abstract base identity for conventional configuration
datastores.";
}
identity conventional {
base datastore;
description
"Abstract base identity for conventional configuration
datastores.";
}
identity running {
base conventional;
description
"The running configuration datastore.";
}
identity running {
base conventional;
description
"The running configuration datastore.";
}
identity candidate {
base conventional;
description
"The candidate configuration datastore.";
}
identity candidate {
base conventional;
description
"The candidate configuration datastore.";
}
identity startup {
base conventional;
description
"The startup configuration datastore.";
}
identity startup {
base conventional;
description
"The startup configuration datastore.";
}
identity intended {
base conventional;
description
"The intended configuration datastore.";
}
identity intended {
base conventional;
description
"The intended configuration datastore.";
}
identity dynamic {
base datastore;
description
"Abstract base identity for dynamic configuration datastores.";
}
identity dynamic {
base datastore;
description
"Abstract base identity for dynamic configuration datastores.";
}
identity operational {
base datastore;
description
"The operational state datastore.";
}
identity operational {
base datastore;
description
"The operational state datastore.";
}
/*
* Type definitions
*/
/*
* Type definitions
*/
typedef datastore-ref {
type identityref {
base datastore;
}
description
"A datastore identity reference.";
}
}
typedef datastore-ref {
type identityref {
base datastore;
}
description
"A datastore identity reference.";
}
}
<CODE ENDS>
<代码结束>
<CODE BEGINS> file "ietf-origin@2018-02-14.yang"
<CODE BEGINS> file "ietf-origin@2018-02-14.yang"
module ietf-origin {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
prefix or;
module ietf-origin {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
prefix or;
import ietf-yang-metadata {
prefix md;
}
import ietf-yang-metadata {
prefix md;
}
organization "IETF Network Modeling (NETMOD) Working Group";
组织“IETF网络建模（NETMOD）工作组”；
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Rob Wilton
<rwilton@cisco.com>";
Author: Rob Wilton
<rwilton@cisco.com>";
description "This YANG module defines an 'origin' metadata annotation and a set of identities for the origin value.
description“此模块定义了一个“origin”元数据注释和一组origin值的标识。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8342
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
for full legal notices.";
This version of this YANG module is part of RFC 8342
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
for full legal notices.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
/*
* Identities
*/
/*
* Identities
*/
identity origin {
description
"Abstract base identity for the origin annotation.";
}
identity origin {
description
"Abstract base identity for the origin annotation.";
}
identity intended {
base origin;
description
"Denotes configuration from the intended configuration
datastore.";
}
identity intended {
base origin;
description
"Denotes configuration from the intended configuration
datastore.";
}
identity dynamic {
base origin;
description
"Denotes configuration from a dynamic configuration
datastore.";
}
identity dynamic {
base origin;
description
"Denotes configuration from a dynamic configuration
datastore.";
}
identity system {
base origin;
description
"Denotes configuration originated by the system itself.
identity system {
base origin;
description
"Denotes configuration originated by the system itself.
Examples of system configuration include applied configuration
for an always-existing loopback interface, or interface
configuration that is auto-created due to the hardware
currently present in the device.";
}
Examples of system configuration include applied configuration
for an always-existing loopback interface, or interface
configuration that is auto-created due to the hardware
currently present in the device.";
}
identity learned {
base origin;
description
"Denotes configuration learned from protocol interactions with
other devices, instead of via either the intended
configuration datastore or any dynamic configuration
datastore.
identity learned {
base origin;
description
"Denotes configuration learned from protocol interactions with
other devices, instead of via either the intended
configuration datastore or any dynamic configuration
datastore.
Examples of protocols that provide learned configuration
include link-layer negotiations, routing protocols, and
DHCP.";
}
Examples of protocols that provide learned configuration
include link-layer negotiations, routing protocols, and
DHCP.";
}
identity default {
base origin;
description
"Denotes configuration that does not have a configured or
learned value but has a default value in use. Covers both
values defined in a 'default' statement and values defined
via an explanation in a 'description' statement.";
}
identity default {
base origin;
description
"Denotes configuration that does not have a configured or
learned value but has a default value in use. Covers both
values defined in a 'default' statement and values defined
via an explanation in a 'description' statement.";
}
identity unknown {
base origin;
description
"Denotes configuration for which the system cannot identify the
origin.";
}
identity unknown {
base origin;
description
"Denotes configuration for which the system cannot identify the
origin.";
}
/*
* Type definitions
*/
/*
* Type definitions
*/
typedef origin-ref {
type identityref {
base origin;
}
description
"An origin identity reference.";
}
typedef origin-ref {
type identityref {
base origin;
}
description
"An origin identity reference.";
}
/*
* Metadata annotations
*/
/*
* Metadata annotations
*/
md:annotation origin {
type origin-ref;
description
"The 'origin' annotation can be present on any configuration
data node in the operational state datastore. It specifies
from where the node originated. If not specified for a given
configuration data node, then the origin is the same as the
origin of its parent node in the data tree. The origin for
any top-level configuration data nodes must be specified.";
}
}
md:annotation origin {
type origin-ref;
description
"The 'origin' annotation can be present on any configuration
data node in the operational state datastore. It specifies
from where the node originated. If not specified for a given
configuration data node, then the origin is the same as the
origin of its parent node in the data tree. The origin for
any top-level configuration data nodes must be specified.";
}
}
<CODE ENDS>
<代码结束>
This document registers two URIs in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations have been made:
本文档在“IETF XML注册表”[RFC3688]中注册了两个URI。按照[RFC3688]中的格式，进行了以下注册：
URI: urn:ietf:params:xml:ns:yang:ietf-datastores Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf数据存储注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
URI: urn:ietf:params:xml:ns:yang:ietf-origin Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf来源注册人联系人：IESG。XML：不适用；请求的URI是一个XML命名空间。
This document registers two YANG modules in the "YANG Module Names" registry [RFC6020]. Following the format in [RFC6020], the following registrations have been made:
本文件在“阳模块名称”注册表[RFC6020]中注册了两个阳模块。按照[RFC6020]中的格式，进行了以下注册：
name: ietf-datastores
namespace: urn:ietf:params:xml:ns:yang:ietf-datastores
prefix: ds
reference: RFC 8342
name: ietf-datastores
namespace: urn:ietf:params:xml:ns:yang:ietf-datastores
prefix: ds
reference: RFC 8342
name: ietf-origin
namespace: urn:ietf:params:xml:ns:yang:ietf-origin
prefix: or
reference: RFC 8342
name: ietf-origin
namespace: urn:ietf:params:xml:ns:yang:ietf-origin
prefix: or
reference: RFC 8342
This document discusses an architectural model of datastores for network management using NETCONF/RESTCONF and YANG. It has no security impact on the Internet.
本文讨论了使用NETCONF/RESTCONF和YANG进行网络管理的数据存储体系结构模型。它对互联网没有安全影响。
Although this document specifies several YANG modules, these modules only define identities and a metadata annotation; hence, the "YANG module security guidelines" [YANG-SEC] do not apply.
虽然本文档指定了几个模块，但这些模块仅定义标识和元数据注释；因此，“YANG模块安全指南”[YANG-SEC]不适用。
The origin metadata annotation exposes the origin of values in the applied configuration. Origin information may provide hints that certain control-plane protocols are active on a device. Since origin information is tied to applied configuration values, it is only accessible to clients that have the permissions to read the applied configuration values. Security administrators should consider the sensitivity of origin information while defining access control rules.
源元数据注释公开应用配置中值的源。原点信息可能提供某些控制平面协议在设备上处于活动状态的提示。由于源信息与应用的配置值相关联，因此只有具有读取应用的配置值权限的客户端才能访问该信息。安全管理员应考虑源信息的敏感性，同时定义访问控制规则。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<https://www.rfc-editor.org/info/rfc7950>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.
[RFC7952]Lhotka，L.，“与YANG一起定义和使用元数据”，RFC 7952，DOI 10.17487/RFC7952，2016年8月<https://www.rfc-editor.org/info/rfc7952>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]Bray，T.，Paoli，J.，Sperberg McQueen，M.，Maler，E.，和F.Yergeau，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<https://www.w3.org/TR/2008/REC-xml-20081126>.
[NETMOD-Operational] Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF and YANG", Work in Progress, draft-bjorklund-netmod-operational-00, October 2012.
[NETMOD Operational]Bjorklund，M.和L.Lhotka，“NETCONF和YANG中的作战数据”，正在进行的工作，草稿-Bjorklund-NETMOD-Operational-00，2012年10月。
[OpState-Enhance] Watsen, K., Bierman, A., Bjorklund, M., and J. Schoenwaelder, "Operational State Enhancements for YANG, NETCONF, and RESTCONF", Work in Progress, draft-kwatsen-netmod-opstate-02, February 2016.
[OpState Enhance]Watsen，K.，Bierman，A.，Bjorklund，M.，和J.Schoenwaeld，“YANG，NETCONF和RESTCONF的运行状态增强”，正在进行的工作，草稿-kwatsen-netmod-OpState-022016年2月。
[OpState-Modeling] Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling of Operational State Data in YANG", Work in Progress, draft-openconfig-netmod-opstate-01, July 2015.
[OpState Modeling]Shakir，R.，Shaikh，A.，和M.Hines，“YANG运行状态数据的一致建模”，正在进行的工作，草稿-openconfig-netmod-OpState-01，2015年7月。
[OpState-Reqs] Watsen, K. and T. Nadeau, "Terminology and Requirements for Enhanced Handling of Operational State", Work in Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.
[操作状态要求]Watsen，K.和T.Nadeau，“增强操作状态处理的术语和要求”，正在进行的工作，草案-ietf-netmod-OpState-Reqs-04，2016年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 2011, <https://www.rfc-editor.org/info/rfc6244>.
[RFC6244]Shafer，P.“使用NETCONF和YANG的网络管理架构”，RFC 6244，DOI 10.17487/RFC6244，2011年6月<https://www.rfc-editor.org/info/rfc6244>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343]Bjorklund，M.，“用于接口管理的YANG数据模型”，RFC 8343，DOI 10.17487/RFC8343，2018年3月<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[RFC8344]Bjorklund，M.，“知识产权管理的杨氏数据模型”，RFC 8344，DOI 10.17487/RFC8344，2018年3月<https://www.rfc-editor.org/info/rfc8344>.
[With-config-state] Wilton, R., ""With-config-state" Capability for NETCONF/RESTCONF", Work in Progress, draft-wilton-netmod-opstate-yang-02, December 2015.
[具有配置状态]威尔顿，R.，“具有配置状态”NETCONF/RESTCONF的能力”，正在进行的工作，草稿-Wilton-netmod-opstate-yang-022015年12月。
[YANG-SEC] IETF, "YANG Security Guidelines", <https://trac.ietf.org/ trac/ops/wiki/yang-security-guidelines>.
[YANG-SEC]IETF，“YANG安全指南”<https://trac.ietf.org/ trac/ops/wiki/yang安全指南>。
The definition of a new datastore in this architecture should be provided in a document (e.g., an RFC) purposed for defining the datastore. When it makes sense, more than one datastore may be defined in the same document (e.g., when the datastores are logically connected). Each datastore's definition should address the points specified in the subsections below.
此体系结构中新数据存储的定义应在用于定义数据存储的文档（如RFC）中提供。如果有意义，可以在同一文档中定义多个数据存储（例如，当数据存储逻辑连接时）。每个数据存储的定义都应说明以下小节中指定的点。
Not all YANG modules may be used in all datastores. Some datastores may constrain which data models can be used in them. If it is desirable that a subset of all modules can be targeted to the datastore, then the documentation defining the datastore must indicate this.
并非所有数据存储中都可以使用所有模块。某些数据存储可能会限制哪些数据模型可以在其中使用。如果希望将所有模块的子集都指向数据存储，那么定义数据存储的文档必须指出这一点。
By default, the data in a datastore is modeled by all YANG statements in the available YANG modules. However, it is possible to specify criteria that YANG statements must satisfy in order to be present in a datastore. For instance, maybe only "config true" nodes, or "config false" nodes that also have a specific YANG extension, are present in the datastore.
默认情况下，数据存储中的数据由可用YANG模块中的所有YANG语句建模。但是，可以指定YANG语句必须满足的条件，以便出现在数据存储中。例如，数据存储中可能只存在同样具有特定扩展名的“config true”节点或“config false”节点。
The new datastore must specify how it interacts with other datastores.
新数据存储必须指定它如何与其他数据存储交互。
For example, the diagram in Section 5 depicts dynamic configuration datastores feeding into <operational>. How this interaction occurs has to be defined by the particular dynamic configuration datastores. In some cases, it may occur implicitly, as soon as the data is put into the dynamic configuration datastore, while in other cases an explicit action (e.g., an RPC) may be required to trigger the application of the datastore's data.
例如，第5节中的图表描述了馈送到<operational>的动态配置数据存储。这种交互的发生方式必须由特定的动态配置数据存储定义。在某些情况下，它可能会在数据放入动态配置数据存储后隐式发生，而在其他情况下，可能需要显式操作（例如RPC）来触发数据存储数据的应用程序。
By default, it is assumed that both the NETCONF and RESTCONF protocols can be used to interact with a datastore. However, it may be that only a specific protocol can be used (e.g., Forwarding and Control Element Separation (ForCES)) or that a subset of all protocol operations or capabilities are available (e.g., no locking or no XPath-based filtering).
默认情况下，假定NETCONF和RESTCONF协议都可以用于与数据存储交互。然而，可能只能使用特定的协议（例如，转发和控制元素分离（ForCES））或所有协议操作或功能的子集可用（例如，没有锁定或没有基于XPath的过滤）。
The datastore must be defined with a YANG identity that uses the "ds:datastore" identity, or one of its derived identities, as its base. This identity is necessary, so that the datastore can be referenced in protocol operations (e.g., <get-data>).
必须使用使用“ds:datastore”标识或其派生标识之一作为其基础的YANG标识来定义数据存储。此标识是必需的，以便数据存储可以在协议操作中引用（例如，<get data>）。
The datastore may also be defined with an identity that uses the "or:origin" identity, or one of its derived identities, as its base. This identity is needed if the datastore interacts with <operational>, so that data originating from the datastore can be identified as such via the "origin" metadata attribute defined in Section 7.
还可以使用使用“or:origin”标识或其派生标识之一作为其基础的标识来定义数据存储。如果数据存储与<operational>交互，则需要此标识，以便可以通过第7节中定义的“源”元数据属性识别来自数据存储的数据。
An example of these guidelines in use is provided in Appendix B.
附录B中提供了这些指南的使用示例。
This section defines documentation for an example dynamic configuration datastore using the guidelines provided in Appendix A. For brevity, only a terse example is provided; it is expected that a standalone RFC would be written when this type of scenario is fully considered.
本节使用附录A中提供的指南定义了示例动态配置数据存储的文档。为简洁起见，仅提供了一个简洁的示例；预计在充分考虑此类场景时，将编写一个独立的RFC。
This example defines a dynamic configuration datastore called "ephemeral", which is loosely modeled after the work done in the I2RS Working Group.
本例定义了一个名为“ephemeral”的动态配置数据存储，该数据存储松散地模仿了I2RS工作组中完成的工作。
+--------------------+----------------------------------------------+
| Name | Value |
+--------------------+----------------------------------------------+
| Name | ephemeral |
| | |
| YANG modules | all (default) |
| | |
| YANG nodes | all "config true" data nodes |
| | |
| How applied | changes automatically propagated to |
| | <operational> |
| | |
| Protocols | NETCONF/RESTCONF (default) |
| | |
| Defining YANG | "example-ds-ephemeral" |
| module | |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| Name | Value |
+--------------------+----------------------------------------------+
| Name | ephemeral |
| | |
| YANG modules | all (default) |
| | |
| YANG nodes | all "config true" data nodes |
| | |
| How applied | changes automatically propagated to |
| | <operational> |
| | |
| Protocols | NETCONF/RESTCONF (default) |
| | |
| Defining YANG | "example-ds-ephemeral" |
| module | |
+--------------------+----------------------------------------------+
Properties of the Example "ephemeral" Datastore
示例“短暂”数据存储的属性
module example-ds-ephemeral {
yang-version 1.1;
namespace "urn:example:ds-ephemeral";
prefix eph;
module example-ds-ephemeral {
yang-version 1.1;
namespace "urn:example:ds-ephemeral";
prefix eph;
import ietf-datastores {
prefix ds;
}
import ietf-origin {
prefix or;
}
import ietf-datastores {
prefix ds;
}
import ietf-origin {
prefix or;
}
// datastore identity
identity ds-ephemeral {
base ds:dynamic;
description
"The ephemeral dynamic configuration datastore.";
}
// datastore identity
identity ds-ephemeral {
base ds:dynamic;
description
"The ephemeral dynamic configuration datastore.";
}
// origin identity
identity or-ephemeral {
base or:dynamic;
description
"Denotes data from the ephemeral dynamic configuration
datastore.";
}
}
// origin identity
identity or-ephemeral {
base or:dynamic;
description
"Denotes data from the ephemeral dynamic configuration
datastore.";
}
}
The use of datastores is complex, and many of the subtle effects are more easily presented using examples. This section presents a series of example data models with some sample contents of the various datastores.
数据存储的使用是复杂的，许多细微的效果更容易通过示例呈现。本节介绍了一系列示例数据模型，以及各种数据存储的一些示例内容。
The XML [W3C.REC-xml-20081126] snippets that follow are provided as examples only.
下面的XML[W3C.REC-XML-20081126]片段仅作为示例提供。
In this example, the following fictional module is used:
在本例中，使用了以下虚构模块：
module example-system {
yang-version 1.1;
namespace urn:example:system;
prefix sys;
module example-system {
yang-version 1.1;
namespace urn:example:system;
prefix sys;
import ietf-inet-types {
prefix inet;
}
import ietf-inet-types {
prefix inet;
}
container system {
leaf hostname {
type string;
}
container system {
leaf hostname {
type string;
}
list interface {
key name;
list interface {
key name;
leaf name {
type string;
}
leaf name {
type string;
}
container auto-negotiation {
leaf enabled {
type boolean;
default true;
}
leaf speed {
type uint32;
units mbps;
description
"The advertised speed, in Mbps.";
}
}
container auto-negotiation {
leaf enabled {
type boolean;
default true;
}
leaf speed {
type uint32;
units mbps;
description
"The advertised speed, in Mbps.";
}
}
leaf speed {
type uint32;
units mbps;
config false;
description
"The speed of the interface, in Mbps.";
}
leaf speed {
type uint32;
units mbps;
config false;
description
"The speed of the interface, in Mbps.";
}
list address {
key ip;
list address {
key ip;
leaf ip {
type inet:ip-address;
}
leaf prefix-length {
type uint8;
}
}
}
}
}
leaf ip {
type inet:ip-address;
}
leaf prefix-length {
type uint8;
}
}
}
}
}
The operator has configured the hostname and two interfaces, so the contents of <intended> are:
操作员已配置主机名和两个接口，因此<designed>的内容包括：
<system xmlns="urn:example:system">
<system xmlns="urn:example:system">
<hostname>foo.example.com</hostname>
<hostname>foo.example.com</hostname>
<interface>
<name>eth0</name>
<auto-negotiation>
<speed>1000</speed>
</auto-negotiation>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
<interface>
<name>eth0</name>
<auto-negotiation>
<speed>1000</speed>
</auto-negotiation>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
<interface>
<name>eth1</name>
<address>
<ip>2001:db8::20</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
<interface>
<name>eth1</name>
<address>
<ip>2001:db8::20</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
</system>
</system>
The system has detected that the hardware for one of the configured interfaces ("eth1") is not yet present, so the configuration for that interface is not applied. Further, the system has received a hostname and an additional IP address for "eth0" over DHCP. In addition to filling in the default value for the auto-negotiation enabled leaf, a loopback interface entry is also automatically
系统检测到其中一个已配置接口（“eth1”）的硬件尚未存在，因此未应用该接口的配置。此外，系统已通过DHCP接收到“eth0”的主机名和附加IP地址。除了为启用自动协商的叶填充默认值外，还自动创建环回接口条目
instantiated by the system. All of this is reflected in <operational>. Note how the "origin" metadata attribute for several "config true" data nodes is inherited from their parent data nodes.
由系统实例化。所有这些都反映在<operation>中。请注意，多个“config true”数据节点的“origin”元数据属性是如何从其父数据节点继承的。
<system
xmlns="urn:example:system"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<system
xmlns="urn:example:system"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<hostname or:origin="or:learned">bar.example.com</hostname>
<hostname or:origin="or:learned">bar.example.com</hostname>
<interface or:origin="or:intended">
<name>eth0</name>
<auto-negotiation>
<enabled or:origin="or:default">true</enabled>
<speed>1000</speed>
</auto-negotiation>
<speed>100</speed>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
<address or:origin="or:learned">
<ip>2001:db8::1:100</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
<interface or:origin="or:intended">
<name>eth0</name>
<auto-negotiation>
<enabled or:origin="or:default">true</enabled>
<speed>1000</speed>
</auto-negotiation>
<speed>100</speed>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
<address or:origin="or:learned">
<ip>2001:db8::1:100</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
<interface or:origin="or:system">
<name>lo0</name>
<address>
<ip>::1</ip>
<prefix-length>128</prefix-length>
</address>
</interface>
<interface or:origin="or:system">
<name>lo0</name>
<address>
<ip>::1</ip>
<prefix-length>128</prefix-length>
</address>
</interface>
</system>
</system>
Consider the following fragment of a fictional BGP module:
考虑虚构的BGP模块的以下片段：
container bgp {
leaf local-as {
type uint32;
}
leaf peer-as {
type uint32;
}
list peer {
key name;
leaf name {
type inet:ip-address;
}
leaf local-as {
type uint32;
description
"... Defaults to ../local-as.";
}
leaf peer-as {
type uint32;
description
"... Defaults to ../peer-as.";
}
leaf local-port {
type inet:port;
}
leaf remote-port {
type inet:port;
default 179;
}
leaf state {
config false;
type enumeration {
enum init;
enum established;
enum closing;
}
}
}
}
container bgp {
leaf local-as {
type uint32;
}
leaf peer-as {
type uint32;
}
list peer {
key name;
leaf name {
type inet:ip-address;
}
leaf local-as {
type uint32;
description
"... Defaults to ../local-as.";
}
leaf peer-as {
type uint32;
description
"... Defaults to ../peer-as.";
}
leaf local-port {
type inet:port;
}
leaf remote-port {
type inet:port;
default 179;
}
leaf state {
config false;
type enumeration {
enum init;
enum established;
enum closing;
}
}
}
}
In this example model, both bgp/peer/local-as and bgp/peer/peer-as have complex hierarchical values, allowing the user to specify default values for all peers in a single location.
在此示例模型中，bgp/peer/local as和bgp/peer/peer as都具有复杂的层次结构值，允许用户为单个位置中的所有对等点指定默认值。
The model also follows the pattern of fully integrating state ("config false") nodes with configuration ("config true") nodes. There is no separate "bgp-state" hierarchy, with the accompanying repetition of containment and naming nodes. This makes the model simpler and more readable.
该模型还遵循将状态（“config false”）节点与配置（“config true”）节点完全集成的模式。没有单独的“bgp状态”层次结构，伴随着包含和命名节点的重复。这使得模型更简单，可读性更强。
Each datastore represents differing views of these nodes. <running> will hold the configuration provided by the operator -- for example, a single BGP peer. <intended> will conceptually hold the data as validated, after the removal of data not intended for validation and after any local template mechanisms are performed. <operational> will show data from <intended> as well as any "config false" nodes.
每个数据存储代表这些节点的不同视图<运行>将保留操作员提供的配置——例如，单个BGP对等机<在删除不用于验证的数据以及执行任何本地模板机制后，designed>将在概念上保持数据为已验证<operational>将显示来自<designed>以及任何“config false”节点的数据。
If the user configures a single BGP peer, then that peer will be visible in both <running> and <intended>. It may also appear in <candidate> if the server supports the candidate configuration datastore. Retrieving the peer will return only the user-specified values.
如果用户配置单个BGP对等点，则该对等点将在<运行>和<预期>中都可见。如果服务器支持候选配置数据存储，它也可能出现在<candidate>中。检索对等方将仅返回用户指定的值。
No time delay should exist between the appearance of the peer in <running> and <intended>.
对等机在<running>和<destined>中出现之间不应存在时间延迟。
In this scenario, we've added the following to <running>:
在此场景中，我们将以下内容添加到<running>：
<bgp>
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
</peer>
</bgp>
<bgp>
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
</peer>
</bgp>
The operational datastore will contain the fully expanded peer data, including "config false" nodes. In our example, this means that the "state" node will appear.
操作数据存储将包含完全扩展的对等数据，包括“config false”节点。在我们的示例中，这意味着“状态”节点将出现。
In addition, <operational> will contain the "currently in use" values
for all nodes. This means that local-as and peer-as will be
populated even if they are not given values in <intended>. The value
of bgp/local-as will be used if bgp/peer/local-as is not provided;
bgp/peer-as and bgp/peer/peer-as will have the same relationship. In
In addition, <operational> will contain the "currently in use" values
for all nodes. This means that local-as and peer-as will be
populated even if they are not given values in <intended>. The value
of bgp/local-as will be used if bgp/peer/local-as is not provided;
bgp/peer-as and bgp/peer/peer-as will have the same relationship. In
the operational view, this means that every peer will have values for their local-as and peer-as, even if those values are not explicitly configured but are provided by bgp/local-as and bgp/peer-as.
在操作视图中，这意味着每个对等方都将拥有其本地as和对等方as的值，即使这些值未明确配置，但由bgp/本地as和bgp/对等方as提供。
Each BGP peer has a TCP connection associated with it, using the values of local-port and remote-port from <intended>. If those values are not supplied, the system will select values. When the connection is established, <operational> will contain the current values for the local-port and remote-port nodes regardless of the origin. If the system has chosen the values, the "origin" attribute will be set to "system". Before the connection is established, one or both of the nodes may not appear, since the system may not yet have their values.
每个BGP对等机都有一个与之关联的TCP连接，使用<designed>中的本地端口和远程端口的值。如果未提供这些值，系统将选择这些值。建立连接后，<operational>将包含本地端口和远程端口节点的当前值，而不管其来源如何。如果系统选择了这些值，“原点”属性将设置为“系统”。在建立连接之前，一个或两个节点可能不会出现，因为系统可能还没有它们的值。
<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
<local-as or:origin="or:default">64501</local-as>
<peer-as or:origin="or:default">64502</peer-as>
<local-port or:origin="or:system">60794</local-port>
<remote-port or:origin="or:default">179</remote-port>
<state>established</state>
</peer>
</bgp>
<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
<local-as or:origin="or:default">64501</local-as>
<peer-as or:origin="or:default">64502</peer-as>
<local-port or:origin="or:system">60794</local-port>
<remote-port or:origin="or:default">179</remote-port>
<state>established</state>
</peer>
</bgp>
Changes to configuration may take time to percolate through the various software components involved. During this period, it is imperative to continue to give an accurate view of the working of the device. <operational> will contain nodes for both the previous and current configuration, as closely as possible tracking the current operation of the device.
对配置的更改可能需要一段时间才能渗透到所涉及的各种软件组件中。在此期间，必须继续准确了解设备的工作情况<operational>将包含先前配置和当前配置的节点，尽可能地跟踪设备的当前操作。
Consider the scenario where a client removes a BGP peer. When a peer is removed, the operational state will continue to reflect the existence of that peer until the peer's resources are released, including closing the peer's connection. During this period, the current data values will continue to be visible in <operational>, with the "origin" attribute set to indicate the origin of the original data.
考虑客户端删除BGP对等点的场景。当一个对等体被移除时，操作状态将继续反映该对等体的存在，直到该对等体的资源被释放，包括关闭该对等体的连接。在此期间，当前数据值将继续在<operation>中可见，并设置“origin”属性以指示原始数据的来源。
<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
<local-as or:origin="or:default">64501</local-as>
<peer-as or:origin="or:default">64502</peer-as>
<local-port or:origin="or:system">60794</local-port>
<remote-port or:origin="or:default">179</remote-port>
<state>closing</state>
</peer>
</bgp>
<bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<local-as>64501</local-as>
<peer-as>64502</peer-as>
<peer>
<name>2001:db8::2:3</name>
<local-as or:origin="or:default">64501</local-as>
<peer-as or:origin="or:default">64502</peer-as>
<local-port or:origin="or:system">60794</local-port>
<remote-port or:origin="or:default">179</remote-port>
<state>closing</state>
</peer>
</bgp>
Once resources are released and the connection is closed, the peer's data is removed from <operational>.
释放资源并关闭连接后，将从<operational>中删除对等方的数据。
In this section, we will use this simple interface data model:
在本节中，我们将使用以下简单的接口数据模型：
container interfaces {
list interface {
key name;
leaf name {
type string;
}
leaf description {
type string;
}
leaf mtu {
type uint16;
}
leaf-list ip-address {
type inet:ip-address;
}
}
}
container interfaces {
list interface {
key name;
leaf name {
type string;
}
leaf description {
type string;
}
leaf mtu {
type uint16;
}
leaf-list ip-address {
type inet:ip-address;
}
}
}
One common issue in networking devices is the support of Field Replaceable Units (FRUs) that can be inserted and removed from the device without requiring a reboot or interfering with normal operation. These FRUs are typically interface cards, and the devices support pre-provisioning of these interfaces.
网络设备中的一个常见问题是支持现场可更换单元（FRU），可以在不需要重新启动或干扰正常操作的情况下从设备中插入和移除这些单元。这些FRU通常是接口卡，设备支持这些接口的预配置。
If a client creates an interface "et-0/0/0" but the interface does not physically exist at this point, then <intended> might contain the following:
如果客户机创建了接口“et-0/0/0”，但此时该接口实际上不存在，则<designed>可能包含以下内容：
<interfaces>
<interface>
<name>et-0/0/0</name>
<description>Test interface</description>
</interface>
</interfaces>
<interfaces>
<interface>
<name>et-0/0/0</name>
<description>Test interface</description>
</interface>
</interfaces>
Since the interface does not exist, this data does not appear in <operational>.
由于接口不存在，因此此数据不会出现在<operational>中。
When a FRU containing this interface is inserted, the system will detect it and process the associated configuration. <operational> will contain the data from <intended>, as well as nodes added by the system, such as the current value of the interface's MTU.
插入包含此接口的FRU时，系统将检测它并处理相关配置<operational>将包含来自<designed>的数据，以及系统添加的节点，例如接口MTU的当前值。
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>et-0/0/0</name>
<description>Test interface</description>
<mtu or:origin="or:system">1500</mtu>
</interface>
</interfaces>
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>et-0/0/0</name>
<description>Test interface</description>
<mtu or:origin="or:system">1500</mtu>
</interface>
</interfaces>
If the FRU is removed, the interface data is removed from <operational>.
如果FRU被删除，接口数据将从<operational>中删除。
Imagine that the system provides a loopback interface (named "lo0") with a default IPv4 address of "127.0.0.1" and a default IPv6 address of "::1". The system will only provide configuration for this interface if there is no data for it in <intended>.
假设系统提供了一个环回接口（名为“lo0”），其默认IPv4地址为“127.0.0.1”，默认IPv6地址为“：：1”。只有在<designed>中没有此接口的数据时，系统才会提供此接口的配置。
When no configuration for "lo0" appears in <intended>, <operational> will show the system-provided data:
当<designed>中没有出现“lo0”配置时，<operation>将显示系统提供的数据：
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface>
</interfaces>
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface>
</interfaces>
When configuration for "lo0" does appear in <intended>, <operational> will show that data with the origin set to "intended". If the "ip-address" is not provided, then the system-provided value will appear as follows:
当“lo0”的配置出现在<designed>中时，<operation>将显示原点设置为“designed”的数据。如果未提供“ip地址”，则系统提供的值将显示如下：
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>lo0</name>
<description>loopback</description>
<ip-address or:origin="or:system">127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface>
</interfaces>
<interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>lo0</name>
<description>loopback</description>
<ip-address or:origin="or:system">127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface>
</interfaces>
Acknowledgments
致谢
This document grew out of many discussions that took place since 2010. Several documents ([NETMOD-Operational] [With-config-state] [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], as well as [RFC6244]), touched on some of the problems of the original datastore model. The following people were authors of these works in progress or were otherwise actively involved in the discussions that led to this document:
这份文件是在2010年以来的多次讨论中产生的。一些文档（[NETMOD Operational][With config state][OpState Reqs][OpState Enhance][OpState Modeling]以及[RFC6244]）涉及到原始数据存储模型的一些问题。以下人员是这些正在进行的工作的作者，或积极参与了导致本文件的讨论：
o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
o Lou Berger，LabN咨询公司，L.L.C<lberger@labn.net>
o Andy Bierman, YumaWorks, <andy@yumaworks.com>
o 安迪·比尔曼，尤马工厂<andy@yumaworks.com>
o Marcus Hines, Google, <hines@google.com>
o 马库斯·海恩斯，谷歌<hines@google.com>
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
o Christian Hopps，德国电信<chopps@chopps.org>
o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>
o 巴拉兹·伦杰尔，爱立信，<巴拉兹。lengyel@ericsson.com>
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
o 拉迪斯拉夫·洛特卡，CZ.NIC<lhotka@nic.cz>
o Acee Lindem, Cisco Systems, <acee@cisco.com>
o Acee Lindem，思科系统<acee@cisco.com>
o Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>
o Thomas Nadeau，Brocade Networks<tnadeau@lucidvision.com>
o Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com>
o Tom Petch，工程网络有限公司<ietfc@btconnect.com>
o Anees Shaikh, Google, <aashaikh@google.com>
o Anees Shaikh，谷歌<aashaikh@google.com>
o Rob Shakir, Google, <robjs@google.com>
o Rob Shakir，谷歌<robjs@google.com>
o Jason Sterne, Nokia, <jason.sterne@nokia.com>
o 杰森·斯特恩，诺基亚，<Jason。sterne@nokia.com>
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.
Juergen Schoenwaeld的部分资金来自Flamingo，这是一个卓越网络项目（ICT-318488），由欧盟委员会在其第七个框架计划下支持。
Authors' Addresses
作者地址
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-f系统
Email: mbj@tail-f.com
Email: mbj@tail-f.com
Juergen Schoenwaelder Jacobs University
尤尔根·舍恩瓦埃尔德·雅各布斯大学
Email: j.schoenwaelder@jacobs-university.de
Email: j.schoenwaelder@jacobs-university.de
Phil Shafer Juniper Networks
Phil Shafer Juniper网络公司
Email: phil@juniper.net
Email: phil@juniper.net
Kent Watsen Juniper Networks
肯特沃特森刺柏网络公司
Email: kwatsen@juniper.net
Email: kwatsen@juniper.net
Robert Wilton Cisco Systems
罗伯特·威尔顿思科系统公司
Email: rwilton@cisco.com
Email: rwilton@cisco.com