[要約] RFC 8342は、ネットワーク管理データストアアーキテクチャ（NMDA）に関するものであり、ネットワークデバイスの設定と状態の管理を改善するための標準化を目的としています。
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などのネットワーク管理プロトコルにバインドする基本的な概念です。このドキュメントでは、初期の単純なモデルで得られた経験に基づいてデータストアのアーキテクチャフレームワークを定義し、初期モデルでは十分にサポートされていなかった要件に対処します。このドキュメントはRFC 7950を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
多くの場合、ネットワーク管理データオブジェクトは2つの異なる値をとることができます。ユーザーまたはアプリケーションによって構成された値（構成）と、デバイスが実際に使用している値（動作状態）です。これらの2つの値は、ハードウェアとのシステム内部の相互作用、プロトコルや他のデバイスとの相互作用、または単にシステムのソフトウェアおよびハードウェアコンポーネントに構成変更を伝達するのにかかる時間など、さまざまな理由で異なる場合があります。さらに、構成および運用状態のデータオブジェクトの有効期間は異なる場合があります。
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」オブジェクトとして2回モデル化する必要がありました。インターフェイスデータモデル[RFC8343]とIPデータモデル[RFC8344]で採用された規則は、データツリーのルートをルートとする2つの別々のブランチを使用することでした。1つは構成データオブジェクト用、もう1つは運用状態データオブジェクト用です。
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スキーマで1回だけ定義されますが、独立したインスタンス化は異なるデータストアに表示できます。たとえば、1つは設定値用で、もう1つは操作で使用される値用です。これにより、問題に対するよりエレガントでシンプルなソリューションが提供されます。
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 データストア：情報を格納してアクセスするための概念的な場所。データストアは、たとえば、ファイル、データベース、フラッシュメモリの場所、またはそれらの組み合わせを使用して実装できます。データストアは、インスタンス化されたYANGデータツリーにマップされます。
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 意図された構成データストア：デバイスの完全な意図された構成を保持する構成データストア。このデータストアは「<対象>」と呼ばれます。
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 構成変換：<running>と<intended>データストア間の構成の追加、変更、または削除。構成変換の例には、非アクティブな構成の削除や、テンプレートの拡張によって生成された構成が含まれます。
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 従来の構成データストア：次の構成データストアのセットの1つ：<running>、<startup>、<candidate>、および<intended>。これらのデータストアは共通のデータストアスキーマを共有し、プロトコル操作により、これらのデータストア間でデータをコピーできます。 「従来型」という用語は、これらのデータストアの総称として選択されています。
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 動的構成データストア：従来の構成データストアの1つではなく、他のシステムとの対話を通じてデバイスの動作中に動的に取得された構成を保持する構成データストア。
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 システム状態：読み取り専用のステータス情報や収集された統計など、構成ではないシステムの追加データ。システム状態は一時的であり、内部コンポーネントまたは他のシステムとの相互作用によって変更されます。システム状態は、「config false」ノードを使用してYANGでモデル化されています。
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 origin：データ項目の出所を示すメタデータアノテーション。
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 クライアント：ネットワーク管理プロトコルを介してサーバー上のYANG定義データにアクセスできるエンティティ。
o server: An entity that provides access to YANG-defined data to a client, over some network management protocol.
o サーバー：一部のネットワーク管理プロトコルを介して、クライアントにYANG定義のデータへのアクセスを提供するエンティティ。
o notification: A server-initiated message indicating that a certain event has been recognized by the server.
o notification：特定のイベントがサーバーによって認識されたことを示すサーバー起動メッセージ。
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]は、NETCONFがYANGと共に使用される場合に以下の改良を提供します（これは通常のケースですが、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.
[RFC6244]のセクション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)
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>は、標準化されたNETCONFデータストア編集モデルで<running>を<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>の内容を操作状態とともに返します。したがって、動作状態のライフタイムが設定と異なる場合や、設定がすぐにまたは正常に適用されない場合は、「config false」データが「config true」データとは異なるブランチにある必要があります。
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) |
+---------------+
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 <ランニング>
o <candidate>
o <候補者>
o <startup>
o <スタートアップ>
o <intended>
o <対象>
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>）は、デバイスの現在の構成を保持する構成データストアです。適用する前にさらに変換が必要な構成、たとえば、非アクティブな構成、またはさらに拡張が必要なテンプレートメカニズム指向の構成を含めることができます。ただし、[RFC7950]のセクション8.1で定義されているように、<running>は常に有効な構成データツリーである必要があります。
<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.
意図された構成データストア（<意図>）は読み取り専用の構成データストアです。これは、<running>へのすべての構成変換（テンプレートの拡張、非アクティブな構成の削除など）が実行された後の構成を表し、システムが適用しようとする構成です。
<intended> is tightly coupled to <running>. Whenever data is written to <running>, the server MUST also immediately update and validate <intended>.
<intended>は<running>と密接に関連しています。データが<running>に書き込まれるときはいつでも、サーバーは<intended>も直ちに更新して検証する必要があります。
<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].
<意図>構成変換の効果が変化した場合も、<実行>とは無関係に更新される場合がありますが、<意図>は、[RFC7950]のセクション8.1で定義されているように、常に有効な構成データツリーである必要があります。
For simple implementations, <running> and <intended> are identical.
単純な実装の場合、<running>と<intended>は同じです。
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>.
<intended>の内容は、<operational>の「config true」サブセットにも関連しています。したがって、クライアントは、<intended>の内容が<operational>にも表示されるかどうかを確認することで、目的の構成が現在どの程度使用されているかを判断できます。
<intended> does not persist across reboots; its relationship with <running> makes that unnecessary.
<意図>は再起動後は保持されません。 <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.
現在、<intended>に影響する標準メカニズムは定義されていないため、<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>.
そのようなメカニズムの1つの例は、<running>でノードを非アクティブとしてマークするためのサポートです。非アクティブノードは<intended>にコピーされません。 2番目の例は、テンプレートのサポートです。これは、<running>から<intended>に書き込まれた構成への構成の変換を実行できます。
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>からノードを取得するリクエストは、YANGモジュールで指定されたデフォルト値に関係なく、ノードが存在する場合は常に使用中の値を返します。特定のノードに対して値が返されない場合、そのノードはデバイスによって使用されていないことを意味します。
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>.
システムによる「使用中」の構成の解釈は、スキーマ定義とデバイス実装の両方に依存します。一般に、システムで有効になっていて機能する機能は、「使用中」と見なされます。逆に、システムで有効化も操作もされていない機能は、「使用中」ではないと見なされます。したがって、<operational>から省略してください。
<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.
<動作可能>データモデルで指定されたすべての制約に準拠する必要がありますが、「使用中」の値を返すという主な目的があるため、状況によっては制約に違反する可能性があります（たとえば、異常な値が「使用中」である場合）。リストの構造が変更されている、または残りの構成（セクション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.
意味上の制約のみに違反する場合があります。これらは、YANGの「いつ」、「必須」、「必須」、「一意」、「最小要素」、および「最大要素」ステートメントです。キー値の一意性。
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.
<操作可能>は再起動後は保持されません。
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>.
<対象>の設定は、利用できない、または物理的に存在しないリソースを参照できます。これらの状況では、<intended>のこれらの部分は適用されません。データは<intended>に表示されますが、<operational>には表示されません。
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>.
典型的な例は、現在存在しないインターフェースを参照するインターフェース構成です。このような状況では、インターフェース構成は<intended>のままですが、インターフェース構成は<operational>には表示されません。
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>と<intended>に存在しないリソースの構成を許可しますが、<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>に動的に表示されます（およびそこから非表示になります）。システム制御のリソースが表示されたときに<intended>に一致する構成がある場合、システムはその構成を適用しようとします。これにより、構成が最終的に<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]でマークされます。オリジンは、存在しないコンテナを除くすべての構成ノードに適用されます。 「origin」メタデータアノテーションはセクション7で定義されています。値はYANG IDです。次のIDが定義されています。
o origin: abstract base identity from which the other origin identities are derived.
o origin：他の起点IDの派生元である抽象的な基本ID。
o intended: represents configuration provided by <intended>.
o 意図：<intended>によって提供される構成を表します。
o dynamic: represents configuration provided by a dynamic configuration datastore.
o dynamic：動的構成データストアによって提供される構成を表します。
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 system：システム自体によって提供される構成を表します。システム構成の例には、常に存在するループバックインターフェイスに適用される構成や、デバイスに現在存在するハードウェアが原因で自動作成されるインターフェース構成が含まれます。
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：「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".
これらのIDはさらに改良できます。たとえば、「動的」から派生した動的構成データストアの特定のタイプまたはインスタンスに対して個別のIDが存在する可能性があります。
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>内のすべての構成データノードについて、デバイスは、システムで使用されている構成のソースを最も正確に反映するオリジンを報告する必要があります（SHOULD）。
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モジュールの「説明」ステートメントを使用する必要があります（SHOULD）。例えば：
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.
特定の構成ノードについて、関連するYANGの「説明」ステートメントが、プロトコルネゴシエートされた値が構成された値をオーバーライドすることを示している場合、学習された値が構成された値と同じであっても、オリジンは「学習済み」として報告されます。 。
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.
逆に、特定の構成ノードについて、関連付けられたYANGの「説明」ステートメントが、プロトコルネゴシエーションされた値が明示的に構成された値をオーバーライドしないことを示している場合、学習値が設定値と同じ。
In the case that a device cannot provide an accurate origin for a particular configuration data node, it SHOULD use the origin "unknown".
デバイスが特定の構成データノードの正確なオリジンを提供できない場合は、「不明」のオリジンを使用する必要があります（SHOULD）。
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式が「通知」ステートメントのサブステートメントで定義されている場合、アクセス可能なツリーは通知インスタンスであり、サーバー内のすべての動作状態です。通知がモジュールの最上位で定義されている場合、ルートノードには、定義されている通知を表すノードと、すべてのモジュールのすべての最上位のデータノードが子として含まれます。それ以外の場合、ルートノードはすべてのモジュールのすべての最上位データノードを子として持ちます。
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またはアクション操作インスタンスおよびサーバー内のすべての操作状態です。ルートノードには、すべてのモジュールで子として最上位のデータノードがあります。さらに、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またはアクション操作インスタンスおよびサーバー内のすべての操作状態です。ルートノードには、すべてのモジュールで子として最上位のデータノードがあります。さらに、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"
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/>
WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Rob Wilton
<rwilton@cisco.com>";
description "This YANG module defines a set of identities for identifying datastores.
説明「このYANGモジュールは、データストアを識別するための一連のIDを定義します。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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に記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ 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.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
/*
* Identities
*/
identity datastore {
description
"Abstract base identity for datastore identities.";
}
identity conventional {
base datastore;
description
"Abstract base identity for conventional configuration
datastores.";
}
identity running {
base conventional;
description
"The running configuration datastore.";
}
identity candidate {
base conventional;
description
"The candidate configuration datastore.";
}
identity startup {
base conventional;
description
"The startup configuration datastore.";
}
identity intended {
base conventional;
description
"The intended configuration datastore.";
}
identity dynamic {
base datastore;
description
"Abstract base identity for dynamic configuration datastores.";
}
identity operational {
base datastore;
description
"The operational state datastore.";
}
/*
* Type definitions
*/
typedef datastore-ref {
type identityref {
base datastore;
}
description
"A datastore identity reference.";
}
}
<CODE ENDS>
<コード終了>
<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;
import ietf-yang-metadata {
prefix md;
}
organization "IETF Network Modeling (NETMOD) Working Group";
組織「IETFネットワークモデリング（NETMOD）ワーキンググループ」;
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Rob Wilton
<rwilton@cisco.com>";
description "This YANG module defines an 'origin' metadata annotation and a set of identities for the origin value.
説明「このYANGモジュールは、「origin」メタデータアノテーションとorigin値のIDのセットを定義します。
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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に記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ 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.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
/*
* Identities
*/
identity origin {
description
"Abstract base identity for the origin annotation.";
}
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 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.";
}
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.";
}
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.";
}
/*
* Type definitions
*/
typedef origin-ref {
type identityref {
base origin;
}
description
"An origin identity reference.";
}
/*
* 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.";
}
}
<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]に2つの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-datastores登録者の連絡先：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-origin登録者の連絡先：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:
このドキュメントでは、「YANG Module Names」レジストリ[RFC6020]に2つのYANGモジュールを登録しています。 [RFC6020]の形式に従って、次の登録が行われました。
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
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モジュールを指定していますが、これらのモジュールはIDとメタデータアノテーションのみを定義しています。したがって、「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.
originメタデータアノテーションは、適用された構成の値のoriginを公開します。発信元情報は、特定のコントロールプレーンプロトコルがデバイスでアクティブであることを示すヒントを提供する場合があります。オリジン情報は適用された構成値に関連付けられているため、適用された構成値を読み取る権限を持つクライアントのみがアクセスできます。セキュリティ管理者は、アクセス制御ルールを定義する際に、発信元情報の機密性を考慮する必要があります。
[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。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（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。、編、「The YANG 1.1 Data Modeling Language」、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]ブレイ、T。、パオリ、J.、Sperberg-McQueen、M。、マラー、E。、およびF.イェルガウ、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation 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の運用データ」、作業中、draft-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. Schoenwaelder、「YANG、NETCONF、およびRESTCONFの運用状態の拡張」、Work in Progress、draft-kwatsen-netmod-opstate- 2016年2月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の運用状態データの一貫したモデリング」、作業中、draft-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.
[OpState-Reqs] Watsen、K。、およびT. Nadeau、「運用状態の処理を強化するための用語と要件」、作業中、draft-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。、「The IETF XML Registry」、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。、編、「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。、「An NETCONF and YANG Using Network Management for Network Management」、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。、「A YANG Data Model for Interface Management」、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。、「IP管理用のYANGデータモデル」、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.
[With-config-state] Wilton、R.、 "" With-config-state "Capability for NETCONF / RESTCONF"、Work in Progress、draft-wilton-netmod-opstate-yang-02、December 2015。
[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-security-guidelines>。
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.
すべてのYANGモジュールがすべてのデータストアで使用できるわけではありません。一部のデータストアでは、使用できるデータモデルが制限されている場合があります。すべてのモジュールのサブセットをデータストアにターゲティングできることが望ましい場合は、データストアを定義するドキュメントでこれを示す必要があります。
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」ノード、または特定のYANG拡張子を持つ「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プロトコルの両方を使用してデータストアとやり取りできると想定されています。ただし、特定のプロトコルのみを使用できる場合（Forwarding and Control Element Separation（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" IDまたはその派生IDの1つをベースとして使用するYANG IDで定義する必要があります。このIDは、プロトコルストア操作（<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」アイデンティティ、またはその派生アイデンティティの1つをベースとして使用するアイデンティティで定義することもできます。このIDは、データストアが<operational>とやり取りする場合に必要です。これにより、データストアから発信されたデータは、セクション7で定義された「origin」メタデータ属性を介してそのように識別できます。
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 | |
+--------------------+----------------------------------------------+
Properties of the Example "ephemeral" Datastore
「エフェメラル」データストアの例のプロパティ
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;
}
// 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.";
}
}
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;
import ietf-inet-types {
prefix inet;
}
container system {
leaf hostname {
type string;
}
list interface {
key name;
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.";
}
}
leaf speed {
type uint32;
units mbps;
config false;
description
"The speed of the interface, in Mbps.";
}
list address {
key ip;
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:
オペレーターはホスト名と2つのインターフェースを構成しているため、<intended>の内容は次のとおりです。
<system xmlns="urn:example:system">
<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>eth1</name>
<address>
<ip>2001:db8::20</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
</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 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.
システムは、構成されたインターフェースの1つ（「eth1」）のハードウェアがまだ存在しないことを検出したため、そのインターフェースの構成は適用されません。さらに、システムはDHCP経由で「eth0」のホスト名と追加のIPアドレスを受け取りました。自動ネゴシエーションが有効なリーフのデフォルト値を入力することに加えて、ループバックインターフェイスエントリもシステムによって自動的にインスタンス化されます。これはすべて<operational>に反映されています。いくつかの「config true」データノードの「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>
<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>
</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;
}
}
}
}
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の両方に複雑な階層値があり、ユーザーは1つの場所にあるすべてのピアのデフォルト値を指定できます。
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-state」階層はありません。これにより、モデルがよりシンプルで読みやすくなります。
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.
各データストアは、これらのノードの異なるビューを表します。 <running>は、オペレーターによって提供された構成を保持します-たとえば、単一のBGPピア。 <対象>は、検証を目的としていないデータを削除した後、ローカルテンプレートメカニズムを実行した後、データを検証済みとして概念的に保持します。 <operational>は、<intended>からのデータと「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ピアを構成する場合、そのピアは<running>と<intended>の両方に表示されます。サーバーが候補構成データストアをサポートしている場合は、<candidate>にも表示されることがあります。ピアを取得すると、ユーザー指定の値のみが返されます。
No time delay should exist between the appearance of the peer in <running> and <intended>.
<running>のピアの出現と<intended>の間に時間遅延があってはなりません。
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>
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 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.
さらに、<operational>には、すべてのノードの「現在使用中」の値が含まれます。つまり、<intended>で値が指定されていなくても、local-asおよびpeer-asが入力されます。 bgp / peer / local-asが指定されていない場合、bgp / local-asの値が使用されます。 bgp / peer-asとbgp / peer / peer-asの関係は同じです。運用ビューでは、これは、それらの値が明示的に構成されていなくても、bgp / local-asおよびbgp / peer-asによって提供されている場合でも、すべてのピアがlocal-asおよびpeer-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ピアには、<intended>のlocal-portとremote-portの値を使用して、TCP接続が関連付けられています。これらの値が指定されていない場合、システムが値を選択します。接続が確立されると、<operational>には、発信元に関係なく、ローカルポートノードとリモートポートノードの現在の値が含まれます。システムが値を選択した場合、「origin」属性は「system」に設定されます。接続が確立される前に、システムにまだ値がない可能性があるため、一方または両方のノードが表示されない場合があります。
<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ピアを削除するシナリオを考えます。ピアが削除されると、ピアの接続のクローズを含め、ピアのリソースが解放されるまで、動作状態はそのピアの存在を反映し続けます。この期間中、現在のデータ値は引き続き<operational>に表示され、「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>
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;
}
}
}
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.
ネットワーキングデバイスの一般的な問題の1つは、再起動を必要とせずに、または通常の操作を妨げることなくデバイスに挿入および削除できる現場交換可能ユニット（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」というインターフェースを作成したが、この時点でインターフェースが物理的に存在しない場合、<intended>には以下が含まれる可能性があります。
<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>には、<intended>からのデータと、インターフェースの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>
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>.
システムがデフォルトのIPv4アドレス「127.0.0.1」とデフォルトのIPv6アドレス「:: 1」を備えたループバックインターフェイス（「lo0」という名前）を提供していると想像してください。システムは、<intended>にデータがない場合にのみ、このインターフェースの構成を提供します。
When no configuration for "lo0" appears in <intended>, <operational> will show the system-provided data:
<intended>に「lo0」の構成が表示されない場合、<operational>はシステム提供のデータを表示します。
<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」の構成が<intended>に表示される場合、<operational>は、オリジンが「intended」に設定されたデータを表示します。 「ip-address」が指定されていない場合、システム提供の値は次のようになります。
<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 Consulting、L.L.C。、<lberger@labn.net>
o Andy Bierman, YumaWorks, <andy@yumaworks.com>
o Andy Bierman、YumaWorks、<andy@yumaworks.com>
o Marcus Hines, Google, <hines@google.com>
o マーカスハインズ、Google、<hines@google.com>
o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
o Christian Hopps、Deutsche Telekom、<chopps@chopps.org>
o Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>
o Balazs Lengyel、Ericsson、<balazs.lengyel@ericsson.com>
o Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>
o Ladislav Lhotka、CZ.NIC、<lhotka@nic.cz>
o Acee Lindem, Cisco Systems, <acee@cisco.com>
o ACE Lindem、Cisco Systems、<acceyscisco.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、Engineering Networks Ltd、<ietfc@btconnect.com>
o Anees Shaikh, Google, <aashaikh@google.com>
o Anees Shaikh、Google、<aashaikh@google.com>
o Rob Shakir, Google, <robjs@google.com>
o Rob Shakir、Google、<robjs@google.com>
o Jason Sterne, Nokia, <jason.sterne@nokia.com>
o Jason Sterne、Nokia、<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 Schoenwaelderは、その第7フレームワークプログラムの下で欧州委員会が支援するネットワークオブエクセレンスプロジェクト（ICT-318488）であるフラミンゴから一部資金提供を受けました。
Authors' Addresses
著者のアドレス
Martin Bjorklund Tail-f Systems
Martin Bjorklund Tail-fシステム
Email: mbj@tail-f.com
Juergen Schoenwaelder Jacobs University
ユルゲンシェーンヴェルダージェイコブス大学
Email: j.schoenwaelder@jacobs-university.de
Phil Shafer Juniper Networks
Phil Shaferジュニパーネットワークス
Email: phil@juniper.net
Kent Watsen Juniper Networks
ケントワトセンジュニパーネットワークス
Email: kwatsen@juniper.net
Robert Wilton Cisco Systems
Robert Wilton Cisco Systems
Email: rwilton@cisco.com