[要約] RFC 10016は、ネットワーク管理データストアアーキテクチャ（NMDA、RFC 8342）を拡張し、サーバーが稼働するシステム自体によって制御されるシステム構成データストア（<system>）を導入する仕様です。クライアントがシステム提供の事前定義ノードを明示的に参照したり、一部の値を上書きしたり、子孫ノードを設定したりできるメカニズムを定義します。デバイス固有の設定の可視化と制御性を高め、NMDA環境におけるシステム構成の扱いを明確化します。
Internet Engineering Task Force (IETF) Q. Ma, Ed.
Request for Comments: 10016 Q. Wu
Updates: 8342 Huawei
Category: Standards Track C. Feng
ISSN: 2070-1721 September 2026
The Network Management Datastore Architecture (NMDA) in RFC 8342 defines several configuration datastores holding configuration. The contents of these configuration datastores are controlled by clients. This document introduces the concept of a system configuration datastore holding configuration controlled by the system on which a server is running. The system configuration can be referenced (e.g., leafref) by configuration explicitly created by clients.
RFC 8342 の Network Management Datastore Architecture (NMDA) では、構成を保持するいくつかの構成データストアが定義されています。これらの構成データストアの内容はクライアントによって制御されます。このドキュメントでは、サーバーが実行されているシステムによって制御される構成を保持するシステム構成データストアの概念を紹介します。システム構成は、クライアントによって明示的に作成された構成によって参照できます (leafref など)。
This document updates RFC 8342.
この文書は RFC 8342 を更新します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10016.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10016 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.2. Requirements Language
1.3. Updates to RFC 8342
2. Kinds of System Configuration
2.1. Always Present
2.2. Conditionally Present
3. The System Configuration Datastore (<system>)
4. Conceptual Model of Datastores
5. Static Characteristics
5.1. Read-Only to Clients
5.2. No Changes to <operational>
6. Dynamic Behaviors
6.1. May Change via Software Upgrades or Resource Changes
6.2. Referencing System Configuration
6.3. Overriding System Configuration
6.4. Configuring Descendant Nodes of System Configuration
7. The "ietf-system-datastore" Module
7.1. Data Model Overview
7.2. YANG Module
7.3. Example Usage
8. IANA Considerations
8.1. The IETF XML Registry
8.2. The YANG Module Names Registry
9. Operational Considerations
10. Security Considerations
10.1. Considerations for the "ietf-system-datastore" YANG Module
10.2. Considerations for System Configuration
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Example of Dynamic Behaviors (Informative)
A.1. Referencing System-Defined Nodes
A.2. Modifying a System-Instantiated Leaf's Value
A.3. Configuring Descendant Nodes of a System-Defined Node
Appendix B. Key Use Cases (Informative)
B.1. Device Powers On
B.2. Client Commits Configuration
B.3. Operator Installs Card into a Chassis
B.4. Client Further Commits Configuration
Acknowledgements
Contributors
Authors' Addresses
The Network Management Datastore Architecture (NMDA) [RFC8342] defines system configuration as the configuration that is supplied by the device itself and appears in <operational> when it is in use (see Figure 2 in [RFC8342]).
Network Management Datastore Architecture (NMDA) [RFC8342] では、システム構成を、デバイス自体によって提供され、使用中に <operational> に表示される構成として定義しています ([RFC8342] の図 2 を参照)。
However, there is a desire from operators to enable a server to better expose the system configuration, regardless of whether it is in use. For example, some implementations define the system configuration that must be referenced to be active. Network Configuration Protocol (NETCONF) / RESTCONF clients can benefit from a standard mechanism to retrieve what system configuration is available on a server.
ただし、運用者からは、使用中かどうかに関係なく、サーバーがシステム構成をより適切に公開できるようにしたいという要望があります。たとえば、一部の実装では、アクティブになるために参照する必要があるシステム構成を定義します。ネットワーク構成プロトコル (NETCONF) / RESTCONF クライアントは、サーバー上で利用可能なシステム構成を取得する標準メカニズムの恩恵を受けることができます。
Some servers allow the descendant nodes of system-defined configuration to be configured or modified. For example, the system configuration may contain an almost empty physical interface, whose existence in the system configuration is tied to the presence of particular hardware, while the client needs to be able to add, modify, or remove a number of descendant nodes. Some descendant nodes may not be modifiable (e.g., the interface "type" set by the system).
一部のサーバーでは、システム定義構成の子孫ノードを構成または変更できます。たとえば、システム構成にはほとんど空の物理インターフェイスが含まれている場合がありますが、システム構成内でのその存在は特定のハードウェアの存在に関連付けられていますが、クライアントは多数の子孫ノードを追加、変更、または削除できる必要があります。一部の子孫ノードは変更できない場合があります (システムによって設定されたインターフェイスの「タイプ」など)。
This document updates the NMDA defined in [RFC8342] with a read-only conventional configuration datastore called "system" to expose system-defined configuration. The solution enables configuration explicitly created by the clients to reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration.
この文書は、システム定義の設定を公開するために、「system」と呼ばれる読み取り専用の従来の設定データストアを使用して [RFC8342] で定義されている NMDA を更新します。このソリューションにより、クライアントによって明示的に作成された構成で、<system> で定義されたノードを参照し、システム提供の値をオーバーライドし、システム定義の構成の子孫ノードを構成できるようになります。
The solution defined in this document requires the use of NMDA for both clients and servers. Conformance to this document requires NMDA servers implement the "ietf-system-datastore" YANG module (Section 7).
このドキュメントで定義されているソリューションでは、クライアントとサーバーの両方で NMDA を使用する必要があります。この文書に準拠するには、NMDA サーバーが「ietf-system-datastore」YANG モジュール (セクション 7) を実装する必要があります。
This document assumes that the reader is familiar with the contents of [RFC6241], [RFC7950], [RFC8342], and [RFC8525] and uses terminologies from those documents. The terms "device" and "server" are used interchangeably in this document.
この文書は、読者が [RFC6241]、[RFC7950]、[RFC8342]、および [RFC8525] の内容に精通しており、それらの文書の用語を使用していることを前提としています。「デバイス」と「サーバー」という用語は、このドキュメントでは同じ意味で使用されます。
The following terms are defined in this document:
この文書では次の用語が定義されています。
system configuration:
システム構成:
[RFC8342] defines it as "Configuration that is supplied by the device itself". The definition herein refines that definition to represent configuration present in the system configuration datastore (regardless of whether it is applied or referenced). It may also be referred to as "system-defined configuration" or "system-provided configuration" throughout this document. The system configuration discussed in this document cannot be deletable; configuration provided by the server that is deletable is outside the scope of this document.
[RFC8342] では、「デバイス自体によって提供される設定」と定義されています。ここでの定義は、(適用されるか参照されるかに関係なく) システム構成データストアに存在する構成を表すようにその定義を改良します。このドキュメント全体では、「システム定義の構成」または「システム提供の構成」と呼ばれることもあります。この文書で説明されているシステム構成は削除できません。サーバーによって提供される削除可能な構成については、このドキュメントの範囲外です。
system configuration datastore:
システム構成データストア:
This is a configuration datastore holding configuration provided by the system itself. This datastore is referred to as "<system>".
これは、システム自体が提供する構成を保持する構成データストアです。このデータストアは「<システム>」と呼ばれます。
This document redefines the term "conventional configuration datastore" in Section 3 of [RFC8342] to add "system" to the list of conventional configuration datastores:
この文書は、[RFC8342] のセクション 3 で「従来の構成データストア」という用語を再定義し、従来の構成データストアのリストに「システム」を追加します。
conventional configuration datastore:
従来の構成データストア:
One of the following set of configuration datastores: <running>, <startup>, <candidate>, <system>, 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. Note that while protocol operations allow copying data between conventional datastores, the read-only nature of datastores such as <system> and <intended> restricts clients from copying data into them.
次の構成データストアのセットのいずれか: <running>、<startup>、<candidate>、<system>、および <intended>。これらのデータストアは共通のデータストア スキーマを共有しており、プロトコル操作によりこれらのデータストア間でデータをコピーできます。「従来型」という用語は、これらのデータストアの総称として選択されています。プロトコル操作では従来のデータストア間でデータをコピーできますが、<system> や <intended> などのデータストアの読み取り専用の性質により、クライアントによるデータストアへのデータのコピーが制限されることに注意してください。
system node:
システムノード:
This is an instance in the data tree that is provided by the system itself. System node may also be called "system-defined node" or "system-provided node" throughout this document.
これは、システム自体によって提供されるデータ ツリー内のインスタンスです。システム ノードは、本書全体を通じて「システム定義ノード」または「システム提供ノード」と呼ばれることもあります。
referenced node:
参照ノード:
A referenced node is one of the following:
参照されるノードは次のいずれかです。
* Targets of leafref values defined via the "path" statement.
* 「path」ステートメントによって定義されたleafref値のターゲット。
* Targets of "instance-identifier" type values.
* 「インスタンス識別子」タイプの値のターゲット。
* Nodes present in an XPath expression of "when" constraints.
* ノードは、「when」制約の XPath 式に存在します。
* Nodes present in an XPath expression of "must" constraints.
* ノードは「must」制約の XPath 式に存在します。
* Nodes defined to satisfy the "mandatory true" constraints.
* 「必須の true」制約を満たすように定義されたノード。
* Nodes defined to satisfy the "min-elements" constraints.
* 「min-elements」制約を満たすように定義されたノード。
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] で説明されているように解釈されます。
This document updates [RFC8342] to define a configuration datastore called "system" that holds system configuration (Section 3). It also redefines the term "conventional configuration datastore" from [RFC8342] to include "system" in the list.
この文書は、システム構成を保持する「system」と呼ばれる構成データストアを定義するために [RFC8342] を更新します (セクション 3)。また、[RFC8342] の「従来の構成データストア」という用語を再定義して、リストに「システム」を含めます。
To ensure the validity of <intended> when clients interact with system configuration (e.g., configuration provided by clients references system configuration) and allow the existence of system-defined templates and inactive system configuration, configuration in <running> is merged with <system> to create the contents of <intended> after the configuration transformations (e.g., template expansion or removal of inactive configuration defined in [RFC8342]) have been performed, as described in Section 4. Specifications in [RFC8342] related to the processing of system configuration are updated by the mechanism defined in this document.
クライアントがシステム設定と対話するときの <intended> の有効性を保証し (例: クライアントによって提供された設定がシステム設定を参照する)、システム定義のテンプレートと非アクティブなシステム設定の存在を許可するために、セクション 4. の仕様で説明されているように、設定変換 (例: [RFC8342] で定義されているテンプレートの拡張または非アクティブな設定の削除) が実行された後、<running> の設定は <system> とマージされ、<intended> の内容が作成されます。システム構成の処理に関連する[RFC8342]は、この文書で定義されたメカニズムによって更新されます。
Additionally, this document also updates the definition of the "intended" origin metadata annotation identity defined in Section 5.3.4 of [RFC8342]. The "intended" identity of the origin value defined in [RFC8342] represents the origin of configuration provided by <intended>. This document updates that definition as the origin source of configuration explicitly provided by clients and allows a subset of configuration in <intended> that flows from <system> yet is not configured or overridden explicitly in <running> to use "system" as its origin value. As per Section 5.3.4 of [RFC8342], all configuration with the origin value being reported as "intended" MUST originate from <running>, which includes any configuration in <system> that has been copied into <running>. Configuration that is in <system> and not also present in <running> MUST be reported as origin "system" in <operational>.
さらに、この文書は、[RFC8342] のセクション 5.3.4 で定義されている「意図された」オリジンメタデータアノテーションアイデンティティの定義も更新します。[RFC8342] で定義されている原点値の「意図された」アイデンティティは、<intended> によって提供される設定の原点を表します。このドキュメントでは、クライアントによって明示的に提供される構成の元のソースとしてその定義を更新し、<system> からフローするが、<running> で明示的に構成またはオーバーライドされていない <intended> の構成のサブセットが、元の値として "system" を使用できるようにします。[RFC8342] のセクション 5.3.4 に従って、「意図された」として報告される元の値を持つすべての設定は、<running> にコピーされた <system> 内の設定を含む、<running> から発信されなければなりません (MUST)。<system> にあり、<running> にも存在しない構成は、<operational> の元の "system" として報告されなければなりません。
This document defines two types of system configuration: configuration that is always present and configuration that is conditionally present. These types of system configuration are described in Sections 2.1 and 2.2, respectively.
この文書では、常に存在する構成と条件付きで存在する構成の 2 種類のシステム構成を定義します。これらのタイプのシステム構成については、それぞれセクション 2.1 と 2.2 で説明します。
The always-present system configuration is generated in <system> when the device is powered on, irrespective of whether physical resources are present or whether a special functionality is enabled. An example of an always-present system configuration is an always-existing loopback interface.
物理リソースが存在するかどうか、または特別な機能が有効になっているかどうかに関係なく、デバイスの電源がオンになると、常に存在するシステム構成が <system> に生成されます。常時存在するシステム構成の例としては、常時存在するループバック インターフェイスがあります。
The conditionally present system configuration is generated in <system> based on specific conditions being met in a system. For example, if a physical resource is present (e.g., an interface card is inserted), the system automatically detects it and loads the associated configuration; when the physical resource is not present (an interface card is removed), the system configuration will automatically be removed from <system>. Another example is when a special functionality (e.g., a license or feature) is enabled, specific configuration may be created by the system.
条件付きで存在するシステム構成は、システム内で満たされる特定の条件に基づいて <system> で生成されます。たとえば、物理リソースが存在する場合 (インターフェイス カードが挿入されている場合など)、システムはそれを自動的に検出し、関連する構成をロードします。物理リソースが存在しない場合 (インターフェイス カードが取り外された場合)、システム構成は <system> から自動的に削除されます。別の例としては、特別な機能 (ライセンスや機能など) が有効になっている場合、システムによって特定の構成が作成される場合があります。
Following guidelines for defining datastores in Appendix A of [RFC8342], this document introduces a new datastore resource named "system" that represents the system configuration. NMDA servers compliant with this document MUST implement a system configuration datastore, and they SHOULD also implement <intended>.
[RFC8342] の付録 A のデータストア定義のガイドラインに従って、この文書では、システム構成を表す「system」という名前の新しいデータストア リソースを紹介します。この文書に準拠する NMDA サーバーはシステム構成データストアを実装しなければならず (MUST)、また <intended> も実装すべきである (SHOULD)。
Name:
名前：
"system"
"システム"
YANG modules:
YANG モジュール:
all
全て
YANG nodes:
YANG ノード:
all "config true" data nodes up to the root node, generated by the system.
システムによって生成された、ルート ノードまでのすべての「config true」データ ノード。
Management operations:
管理業務:
The datastore can be read using network management protocols such as NETCONF and RESTCONF, but its contents cannot be changed by management operations via NETCONF and RESTCONF protocols.
データストアは、NETCONF や RESTCONF などのネットワーク管理プロトコルを使用して読み取ることができますが、NETCONF や RESTCONF プロトコルを介した管理操作によってその内容を変更することはできません。
Origin:
起源：
This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item provided in <system>.
この文書は、新しいオリジン ID を定義しません。オリジンメタデータアノテーション [RFC7952] の「システム」アイデンティティは、<system> で提供されるデータ項目のオリジンを示すために使用されます。
Protocols:
プロトコル:
YANG-driven management protocols, such as NETCONF and RESTCONF.
NETCONF や RESTCONF などの YANG 主導の管理プロトコル。
Defining YANG module:
YANG モジュールの定義:
"ietf-system-datastore" (Section 7).
「ietf-system-datastore」 (セクション 7)。
The system configuration datastore does not persist across reboots.
システム構成データストアは再起動後は保持されません。
Clients may provide configuration nodes that reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration in <running>, as detailed in Section 6.
セクション 6 で詳述するように、クライアントは、<system> で定義されたノードを参照する構成ノードを提供し、システム提供の値をオーバーライドし、<running> でシステム定義の構成の子孫ノードを構成できます。
To ensure the validity of <intended>, configuration in <running> is merged with <system> to become <intended>, in which process, configuration appearing in <running> takes precedence over the same node in <system>. Since it is unspecified how to merge configuration before transformations, if <system> or <running> includes configuration that requires further transformation (e.g., template expansion or removal of inactive configuration defined in [RFC8342]) before it can be applied, configuration transformations MUST be performed independently on each datastore before <running> is merged with <system>.
<intended> の有効性を保証するために、<running> の構成は <system> とマージされて <intended> になります。このプロセスでは、<running> に表示される構成が <system> の同じノードよりも優先されます。変換前に設定をマージする方法は未指定であるため、<system> または <running> に適用前にさらなる変換 ([RFC8342] で定義されているテンプレートの拡張や非アクティブな設定の削除など) を必要とする設定が含まれている場合、<running> が <system> とマージされる前に、各データストアで設定変換を個別に実行しなければなりません (MUST)。
Whenever configuration in <system> changes, the server MUST also immediately update and validate <intended>.
<system> の設定が変更されるたびに、サーバーはすぐに <intended> を更新して検証しなければなりません (MUST)。
As a result, Figure 2 in Section 5 of [RFC8342] is updated with the below conceptual model of datastores that incorporates the system configuration datastore. For completeness, this model also includes <factory-default> introduced in [RFC8808].
その結果、[RFC8342] のセクション 5 の図 2 は、システム構成データストアを組み込んだ以下のデータストアの概念モデルで更新されました。完全を期すために、このモデルには [RFC8808] で導入された <factory-default> も含まれています。
+-----------------+
|<factory-default>|
+-----| (ct, ro) |-----+
| +-----------------+ |
//"factory-reset" RPC| | |
v | v
+-------------+ | +-----------+
| <candidate> | | | <startup> |
| (ct, rw) |<---+ | +---->| (ct, rw) |
+-------------+ | | | +-----------+
| | v | |
+-----------+ | +-----------+ |
| <system> | +------->| <running> |<--------+
| (ct, ro) | | (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 |
configuration | +-------- learned 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 1: Architectural Model of Datastores
図 1: データストアのアーキテクチャ モデル
Configuration in <system> cannot be deleted by clients (e.g., a list entry can never be removed from <system> through protocol operations), even though a node defined in <system> may be overridden in <running>. If the system initializes a value for a particular leaf that is overridden by the client with a different value in <running> (Section 6.3), and if the node in <running> is removed at a later time, the system-initialized value defined in <system> appears in <intended> and may come into use eventually if applied successfully.
<system> で定義されたノードが <running> でオーバーライドされる場合でも、<system> の構成はクライアントによって削除できません (たとえば、プロトコル操作を通じてリスト エントリを <system> から削除することはできません)。システムが、クライアントによって <running> (セクション 6.3) の別の値でオーバーライドされる特定のリーフの値を初期化し、後で <running> のノードが削除された場合、 <system> で定義されたシステム初期化値が <intended> に表示され、正常に適用されれば最終的に使用される可能性があります。
Configuration may disappear from <system> due to, e.g., resources no longer available. In such cases, configuration for missing resources can still remain in <running> and <intended>, but it will not be applied and appear in <operational>. This is further clarified in Section 5.3.2 of [RFC8342].
リソースが利用できなくなったなどの理由で、構成が <system> から消える可能性があります。このような場合、不足しているリソースの構成は <running> および <intended> に残る可能性がありますが、適用されず、<operational> に表示されます。これは、[RFC8342] のセクション 5.3.2 でさらに明確にされています。
The system datastore is read-only (i.e., edits towards <system> directly MUST be denied), though the client may be allowed to provide configuration that overrides the value of a system-initialized node (see Section 6.3).
システム データストアは読み取り専用です (つまり、<system> への直接の編集は拒否されなければなりません) が、クライアントはシステムで初期化されたノードの値をオーバーライドする構成を提供することが許可される場合があります (セクション 6.3 を参照)。
This work does not change the definition of <operational> nor does it impact the contents of <operational>, as specified in [RFC8342]. It clarifies origin reporting, i.e., the origin of nodes sourced from <system> is reported as "system" unless explicitly configured or overridden in <running>. <system> enables system-defined nodes to be defined like configuration, i.e., made visible to clients in order for being referenced or configurable prior to present in <operational>. "config false" nodes are out of scope; hence, existing "config false" nodes are not impacted by this work.
この作業は、[RFC8342] で規定されている <operational> の定義を変更するものではなく、また <operational> の内容に影響を与えるものでもありません。これは、起点レポートを明確にします。つまり、<system> をソースとするノードの起点は、<running> で明示的に構成またはオーバーライドされない限り、「システム」として報告されます。<system> を使用すると、システム定義のノードを構成と同様に定義できます。つまり、<operational> に存在する前に参照または構成できるようにするためにクライアントに表示されます。「config false」ノードは範囲外です。したがって、既存の「config false」ノードはこの作業の影響を受けません。
The contents of <system> MAY change dynamically under various conditions, such as license change, software upgrade, and system-controlled resources change (see Section 2.2). The updates of system configuration may be obtained through YANG notifications [RFC8639] [RFC8641] (e.g., on-change notification).
<system> の内容は、ライセンスの変更、ソフトウェアのアップグレード、システム制御のリソースの変更など、さまざまな条件下で動的に変更される可能性があります (セクション 2.2 を参照)。システム構成の更新は、YANG 通知 [RFC8639] [RFC8641] (変更時通知など) を通じて取得できます。
If system configuration changes (e.g., during a software upgrade), <running> SHOULD remain a valid configuration data tree. Any mechanisms to achieve this are outside the scope of this document.
システム構成が変更された場合 (例: ソフトウェアのアップグレード中)、<running> は有効な構成データ ツリーのままであるべきです(SHOULD)。これを実現するメカニズムは、このドキュメントの範囲外です。
Clients may create configuration data in <running> that references nodes in <system>. Some implementations may define system nodes solely as a convenience for clients to reference. It is also possible for the clients to define their customized nodes for reference.
クライアントは、<system> 内のノードを参照する構成データを <running> に作成できます。実装によっては、クライアントが参照できるようにするためだけにシステム ノードを定義する場合があります。クライアントが参照用にカスタマイズしたノードを定義することも可能です。
Appendix A.1 provides an example of a client referencing system-defined nodes.
付録 A.1 では、システム定義ノードを参照するクライアントの例を示します。
Although <system> is read-only, in some cases, a server may allow some parts of system configuration (e.g., a leaf's value) to be overridden (note the distinction between <system> and system configuration). Overriding of system configuration is achieved by the client writing configuration data in <running>, which overrides the values of matched configuration nodes at the corresponding level in <system>. Configurations defined in <running> take precedence over system configuration nodes in <system> if the server allows the nodes to be overridden (some implementations may have immutable system configuration that is identified by the server using an immutable metadata annotation; see [YANG-FLAG] for details), regardless of whether a system-instantiated value changes subsequently.
<system> は読み取り専用ですが、場合によっては、サーバーによってシステム設定の一部 (リーフの値など) を上書きできる場合があります (<system> とシステム設定の区別に注意してください)。システム構成の上書きは、クライアントが構成データを <running> に書き込むことによって実現されます。これにより、<system> の対応するレベルで一致した構成ノードの値が上書きされます。<running> で定義された設定は、サーバーがノードの上書きを許可している場合 (一部の実装では、不変のメタデータ アノテーションを使用してサーバーによって識別される不変のシステム設定を持つ場合があります。詳細は [YANG-FLAG] を参照)、システムでインスタンス化された値が後で変更されるかどうかに関係なく、<system> のシステム設定ノードよりも優先されます。
Appendix A.2 provides an example of a client overriding a system-instantiated leaf's value.
付録 A.2 では、システムによってインスタンス化されたリーフの値をクライアントが上書きする例を示します。
A server may also allow a client to add nodes to a list entry in <system> by writing those additional nodes in <running>. Those additional data nodes may not exist in <system> (i.e., an addition rather than an override).
サーバーは、クライアントが <running> に追加のノードを書き込むことで、<system> のリスト エントリにノードを追加できるようにすることもできます。これらの追加データ ノードは <system> に存在しない可能性があります (つまり、オーバーライドではなく追加)。
Appendix A.3 provides an example of a client configuring descendant nodes of a system-defined node.
付録 A.3 に、システム定義ノードの子孫ノードを構成するクライアントの例を示します。
This YANG module defines a new YANG identity named "system", which uses the "ds:conventional" identity defined in [RFC8342] as its base. A client can discover the system configuration datastore support on the server by reading the YANG library information from the operational state datastore.
この YANG モジュールは、[RFC8342] で定義されている "ds:conventional" アイデンティティをベースとして使用する、「system」という名前の新しい YANG アイデンティティを定義します。クライアントは、動作状態データストアから YANG ライブラリ情報を読み取ることで、サーバー上のシステム構成データストアのサポートを検出できます。
The system datastore is defined as a conventional configuration datastore and shares a common datastore schema with other conventional datastores.
システム データストアは従来の構成データストアとして定義され、他の従来のデータストアと共通のデータストア スキーマを共有します。
The following diagram illustrates the relationship amongst the "identity" statements defined in the "ietf-system-datastore" and "ietf-datastores" YANG modules:
次の図は、「ietf-system-datastore」および「ietf-datastores」YANG モジュールで定義された「identity」ステートメント間の関係を示しています。
Identities:
+--- datastore
| +--- conventional
| | +--- running
| | +--- candidate
| | +--- startup
| | +--- system
| | +--- intended
| +--- dynamic
| +--- operational
The diagram above uses syntax that is similar to but not defined in [RFC8340].
上の図は、[RFC8340] に似ていますが、[RFC8340] では定義されていない構文を使用しています。
module ietf-system-datastore {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-system-datastore";
prefix sysds;
import ietf-datastores {
prefix ds;
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
organization
"IETF NETMOD (Network Modeling) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Qiufang Ma
<mailto:maqiufang1@huawei.com>
Author: Qin Wu
<mailto:bill.wu@huawei.com>
Author: Chong Feng
<mailto:fengchongllly@gmail.com>";
description
"This module defines a new YANG identity that uses the
ds:conventional identity defined in RFC 8342.
Copyright (c) 2026 IETF Trust and the persons identified
as authors of the code. All rights reserved.
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 Revised
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).
This version of this YANG module is part of RFC 10016
(https://www.rfc-editor.org/info/rfc10016); see the RFC
itself for full legal notices.";
revision 2026-09-16 {
description
"Initial version.";
reference
"RFC 10016: System-Defined Configuration";
}
identity system {
base ds:conventional;
description
"This read-only datastore contains the configuration
provided by the system itself.";
}
}
The following example shows how the configuration in <system> could be retrieved in a NETCONF <get-data> RPC operation. The example uses the "example-application" fictional data model defined in Appendix A.1 and the Extensible Markup Language (XML) [W3C.XML1.0] encoding.
次の例は、NETCONF <get-data> RPC 操作で <system> の構成を取得する方法を示しています。この例では、付録 A.1 で定義されている「example-application」架空のデータ モデルと拡張マークアップ言語 (XML) [W3C.XML1.0] エンコーディングを使用します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:sysds="urn:ietf:params:xml:ns:yang:ietf-system-datastore">
<datastore>sysds:system</datastore>
<subtree-filter>
<applications xmlns="urn:example:application"/>
</subtree-filter>
</get-data>
</rpc>
When using the RESTCONF protocol, the system configuration datastore can be accessed via the resource: {+restconf}/ds/ietf-system-datastore:system. The following example uses an HTTP GET method to request "applications" configuration:
RESTCONF プロトコルを使用する場合、システム構成データストアにはリソース: {+restconf}/ds/ietf-system-datastore:system 経由でアクセスできます。次の例では、HTTP GET メソッドを使用して「アプリケーション」構成をリクエストします。
GET /restconf/ds/ietf-system-datastore:system/\
example-application:applications HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
IANA has registered the following XML namespace URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:
IANA は、「IETF XML Registry」グループ [RFC3688] 内の「ns」レジストリに次の XML 名前空間 URI を登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-system-datastore
urn:ietf:params:xml:ns:yang:ietf-system-datastore
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URIs are XML namespaces.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group. [RFC6020].
IANA は、「YANG Parameters」レジストリ グループ内の「YANG Module Names」レジストリに次の YANG モジュールを登録しました。[RFC6020]。
Name:
名前：
ietf-system-datastore
ietf システム データストア
Maintained by IANA?
IANAによって保守されていますか？
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-system-datastore
urn:ietf:params:xml:ns:yang:ietf-system-datastore
Prefix:
プレフィックス:
sysds
システム
Reference:
参照：
RFC 10016
RFC 10016
System configuration exists regardless of whether the server implements <system> or not. The introduction of <system> provides a standardized way to expose system configuration within NMDA.
システム構成は、サーバーが <system> を実装しているかどうかに関係なく存在します。<system> の導入により、NMDA 内でシステム構成を公開する標準化された方法が提供されます。
NMDA clients that are not aware of <system> will continue to operate correctly. They will interact only with datastores such as <running>, <candidate>, <intended>, and <operational> as before. The presence of <system> does not change the fundamental behavior for such legacy clients. Operators should be aware that to fully leverage the capabilities defined in this document, client applications need to be updated to recognize and interact with <system>.
<system> を認識しない NMDA クライアントは引き続き正しく動作します。これらは、以前と同様に、<running>、<candidate>、<intended>、<operational> などのデータストアとのみ対話します。<system> が存在しても、そのようなレガシー クライアントの基本的な動作は変わりません。オペレーターは、この文書で定義されている機能を最大限に活用するには、<system> を認識して対話できるようにクライアント アプリケーションを更新する必要があることに注意してください。
This section is modeled after the template described in Section 3.7.1 of [RFC9907].
このセクションは、[RFC9907] のセクション 3.7.1 で説明されているテンプレートをモデルにしています。
The "ietf-system-datastore" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer and (2) have to use mutual authentication (e.g., Secure Shell (SSH) [RFC4252], TLS [TLS1.3], and QUIC [RFC9000]).
「ietf-system-datastore」YANG モジュールは、ネットワーク構成プロトコル (NETCONF) [RFC6241] や RESTCONF [RFC8040] などの YANG ベースの管理プロトコルを介してアクセスできるように設計されたデータ モデルを定義します。これらの YANG ベースの管理プロトコルは、(1) 安全なトランスポート層を使用する必要があり、(2) 相互認証 (たとえば、Secure Shell (SSH) [RFC4252]、TLS [TLS1.3]、および QUIC [RFC9000]) を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Network Configuration Access Control Model (NACM) [RFC8341] は、特定の NETCONF または RESTCONF ユーザーのアクセスを、利用可能なすべての NETCONF または RESTCONF プロトコルの操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
The YANG module only defines an identity that uses the "ds:conventional" identity as its base. The module by itself does not expose any sensitive data nodes that are writable or that contain read-only state, and there are no particularly sensitive RPC or action operations. As such, there are no additional security issues related to the YANG module that need to be considered.
YANG モジュールは、「ds:conventional」アイデンティティをベースとして使用するアイデンティティのみを定義します。このモジュール自体は、書き込み可能な機密データ ノードや読み取り専用状態を含む機密データ ノードを公開せず、特に機密性の高い RPC 操作やアクション操作もありません。そのため、YANG モジュールに関連して考慮する必要のある追加のセキュリティ問題はありません。
The system datastore, while read-only to clients, may contain sensitive information such as hardware identifiers, security policies, and critical system resources. Read access to sensitive system nodes and subtrees within the datastore MUST be controlled to prevent unauthorized disclosure. Implementations are strongly advised to log all access attempts to sensitive system configuration for audit purposes.
システム データストアはクライアントに対して読み取り専用ですが、ハードウェア識別子、セキュリティ ポリシー、重要なシステム リソースなどの機密情報が含まれる場合があります。データストア内の機密システム ノードおよびサブツリーへの読み取りアクセスは、不正な開示を防ぐために制御されなければなりません。実装では、監査の目的で、機密性の高いシステム構成へのすべてのアクセス試行をログに記録することを強くお勧めします。
Furthermore, while <system> cannot be modified directly, system configuration may be overridden as a merging result (Section 6.3). An attacker may configure a leaf that shadows a sensitive node in <system>. Misconfiguration in <running> could lead to unintended system behavior, including security policy bypass and availability risks. Unauthorized modification to sensitive contents MUST be prevented to avoid those negative effects on the network.
さらに、<system> を直接変更することはできませんが、システム設定はマージ結果としてオーバーライドされる可能性があります (セクション 6.3)。攻撃者は、<system> 内の機密ノードをシャドウするリーフを構成する可能性があります。<running> の構成が間違っていると、セキュリティ ポリシーのバイパスや可用性のリスクなど、意図しないシステム動作が発生する可能性があります。ネットワークへの悪影響を避けるために、機密コンテンツへの不正な変更を防止しなければなりません。
[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>.
[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>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
RFC 7952, DOI 10.17487/RFC7952, August 2016,
<https://www.rfc-editor.org/info/rfc7952>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[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>.
[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>.
[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>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for
Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808,
August 2020, <https://www.rfc-editor.org/info/rfc8808>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[W3C.XML1.0]
Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M.,
Ed., Maler, E., Ed., and F. Yergeau, Ed., "Extensible
Markup Language (XML) 1.0 (Fifth Edition)", W3C
Recommendation, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>. Latest
version available at <https://www.w3.org/TR/xml/>.
[YANG-FLAG]
Ma, Q., Ed., Wu, Q., Lengyel, B., Ed., and H. Li, "YANG
Metadata Annotation for Immutable Flag", Work in Progress,
Internet-Draft, draft-ietf-netmod-immutable-flag-08, 26
February 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-netmod-immutable-flag-08>.
This section presents some sample data models and corresponding contents of various datastores with different dynamic behaviors described in Section 6. The XML snippets are used only for illustration purposes. Note that this section does not show the contents of <intended> as they are related to the configuration in <operational>, assuming the intended configuration is applied successfully. Also note that if the "origin" metadata annotation for configuration is unspecified in snippets, it is inherited from its parent node.
このセクションでは、いくつかのサンプル データ モデルと、セクション 6 で説明したさまざまな動的動作を持つさまざまなデータストアの対応するコンテンツを示します。XML スニペットは、説明のみを目的として使用されています。意図した構成が正常に適用されていることを前提として、このセクションでは <intended> の内容は <operational> の構成に関連しているため、その内容は示していないことに注意してください。また、構成の「元の」メタデータ アノテーションがスニペットで指定されていない場合、そのアノテーションは親ノードから継承されることにも注意してください。
In this subsection, the following fictional module is used:
このサブセクションでは、次の架空のモジュールが使用されます。
module example-application {
yang-version 1.1;
namespace "urn:example:application";
prefix ex-app;
import ietf-inet-types {
prefix inet;
}
container applications {
list application {
key "name";
leaf name {
type string;
}
leaf app-id {
type string;
}
leaf protocol {
type enumeration {
enum tcp;
enum udp;
}
mandatory true;
}
leaf destination-port {
default "0";
type inet:port-number;
}
leaf description {
type string;
}
container security-protection {
presence "Indicates that security protection is enabled.";
leaf risk-level {
type enumeration {
enum high;
enum low;
}
}
//additional leafs for security-specific configuration...
}
}
}
}
A fictional Access Control List (ACL) YANG module is used as follows, which defines a leafref for the leaf-list "application" data node to refer to an existing application name.
架空のアクセス制御リスト (ACL) YANG モジュールは次のように使用されます。これは、既存のアプリケーション名を参照するリーフリスト「アプリケーション」データ ノードのリーフ参照を定義します。
module example-acl {
yang-version 1.1;
namespace "urn:example:acl";
prefix ex-acl;
import example-application {
prefix ex-app;
}
import ietf-inet-types {
prefix inet;
}
container acl {
list acl-rule {
key "name";
leaf name {
type string;
}
container matches {
choice l3 {
container ipv4 {
leaf src-address {
type inet:ipv4-prefix;
}
leaf dst-address {
type inet:ipv4-prefix;
}
}
}
choice applications {
leaf-list application {
type leafref {
path "/ex-app:applications/ex-app:application"
+ "/ex-app:name";
}
}
}
}
leaf packet-action {
type enumeration {
enum forward;
enum drop;
enum redirect;
}
}
}
}
}
The server may predefine some applications as a convenience for clients; these applications are immediately present system configuration. When the device is powered on, the system-instantiated application entries may be present in <system> as follows:
サーバーは、クライアントの便宜のために一部のアプリケーションを事前定義する場合があります。これらのアプリケーションは、すぐに存在するシステム構成になります。デバイスの電源がオンになると、システムによってインスタンス化されたアプリケーション エントリが次のように <system> に存在する可能性があります。
<applications xmlns="urn:example:application">
<application>
<name>ftp</name>
<app-id>001</app-id>
<protocol>tcp</protocol>
<destination-port>21</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
<application>
<name>tftp</name>
<app-id>002</app-id>
<protocol>udp</protocol>
<destination-port>69</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
<application>
<name>smtp</name>
<app-id>003</app-id>
<protocol>tcp</protocol>
<destination-port>25</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
</applications>
The client may also define customized applications. Those applications may be present in <running> as follows:
クライアントはカスタマイズされたアプリケーションを定義することもできます。これらのアプリケーションは、次のように <running> に存在する可能性があります。
<applications xmlns="urn:example:application">
<application>
<name>my-smtp</name>
<app-id>101</app-id>
<protocol>tcp</protocol>
<destination-port>2345</destination-port>
<description>customized smtp application</description>
<security-protection>
<risk-level>high</risk-level>
</security-protection>
</application>
<application>
<name>my-foo</name>
<app-id>102</app-id>
<protocol>udp</protocol>
<destination-port>1024</destination-port>
<description>customized application</description>
</application>
</applications>
If a client configures an ACL rule referencing some system-provided or customized applications, the configuration of the ACL rule may be shown as follows:
クライアントがシステム提供またはカスタマイズされたアプリケーションを参照する ACL ルールを設定する場合、ACL ルールの設定は次のように表示される場合があります。
<acl xmlns="urn:example:acl">
<acl-rule>
<name>allow-access-to-ftp-tftp</name>
<matches>
<ipv4>
<src-address>198.51.100.0/24</src-address>
<dst-address>192.0.2.0/24</dst-address>
</ipv4>
<application>ftp</application>
<application>tftp</application>
<application>my-smtp</application>
</matches>
<packet-action>forward</packet-action>
</acl-rule>
</acl>
As different entries of application configuration in <system> and <running> are merged to create <intended>, and there are no merging conflicts in the contents between <system> and <running>, <operational> might contain the configuration of applications with the values of origin reflecting the source of entries as follows:
<system> と <running> 内のアプリケーション構成の異なるエントリがマージされて <intended> が作成され、<system> と <running> の間の内容にマージの競合がないため、<operational> には、次のようにエントリのソースを反映するorigin の値を持つアプリケーションの構成が含まれる可能性があります。
<applications xmlns="urn:example:application"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<application>
<name>my-smtp</name>
<app-id>101</app-id>
<protocol>tcp</protocol>
<destination-port>2345</destination-port>
<description>customized smtp application</description>
<security-protection>
<risk-level>high</risk-level>
</security-protection>
</application>
<application>
<name>my-foo</name>
<app-id>102</app-id>
<protocol>udp</protocol>
<destination-port>1024</destination-port>
<description>customized application</description>
</application>
<application or:origin="or:system">
<name>ftp</name>
<app-id>001</app-id>
<protocol>tcp</protocol>
<destination-port>21</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
<application or:origin="or:system">
<name>tftp</name>
<app-id>002</app-id>
<protocol>udp</protocol>
<destination-port>69</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
<application or:origin="or:system">
<name>smtp</name>
<app-id>003</app-id>
<protocol>tcp</protocol>
<destination-port>25</destination-port>
<security-protection>
<risk-level>low</risk-level>
</security-protection>
</application>
</applications>
This subsection uses the following fictional interface YANG module:
このサブセクションでは、次の架空のインターフェイス YANG モジュールを使用します。
module example-interface {
yang-version 1.1;
namespace "urn:example:interface";
prefix ex-if;
import ietf-inet-types {
prefix inet;
}
container interfaces {
list interface {
key "name";
leaf name {
type string;
}
leaf description {
type string;
}
leaf mtu {
type uint32;
}
leaf-list ip-address {
type inet:ip-address;
}
}
}
}
Suppose the system provides an always-present loopback interface (named "lo0") with an MTU value "65536", a default IPv4 address of "127.0.0.1", and a default IPv6 address of "::1". The configuration of the "lo0" interface may be present in <system> as follows:
システムが、MTU 値「65536」、デフォルトの IPv4 アドレス「127.0.0.1」、およびデフォルトの IPv6 アドレス「::1」を持つ常時存在するループバック インターフェイス (「lo0」という名前) を提供するとします。「lo0」インターフェイスの構成は、次のように <system> に存在する場合があります。
<interfaces xmlns="urn:example:interface">
<interface>
<name>lo0</name>
<mtu>65536</mtu>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface>
</interfaces>
A client modifies the value of MTU to 9216 by adding the following configuration into <running>:
クライアントは、次の構成を <running> に追加することで、MTU の値を 9216 に変更します。
<interfaces xmlns="urn:example:interface">
<interface>
<name>lo0</name>
<mtu>9216</mtu>
</interface>
</interfaces>
Since the MTU value provided by the client takes precedence over the system-provided value, and the "origin" value of configuration provided by the client is set to "intended", the configuration of interfaces that is present in <operational> may be as follows:
クライアントによって提供される MTU 値はシステムによって提供される値よりも優先され、クライアントによって提供される構成の「origin」値は「intended」に設定されるため、<operational> に存在するインターフェイスの構成は次のようになります。
<interfaces xmlns="urn:example:interface"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>lo0</name>
<mtu>9216</mtu>
<ip-address or:origin="or:system">127.0.0.1</ip-address>
<ip-address or:origin="or:system">::1</ip-address>
</interface>
</interfaces>
Based on the example in Appendix A.2, imagine the client further adds the description node of a "lo0" interface in <running> as follows:
付録 A.2 の例に基づいて、クライアントが次のように <running> に「lo0」インターフェイスの記述ノードをさらに追加すると想像します。
<interfaces xmlns="urn:example:interface">
<interface>
<name>lo0</name>
<description>loopback</description>
</interface>
</interfaces>
The configuration of interface "lo0" is present in <operational> as follows:
インターフェイス「lo0」の設定は、次のように <operational> に存在します。
<interfaces xmlns="urn:example:interface"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface>
<name>lo0</name>
<description>loopback</description>
<mtu>9216</mtu>
<ip-address or:origin="or:system">127.0.0.1</ip-address>
<ip-address or:origin="or:system">::1</ip-address>
</interface>
</interfaces>
This section updates the "Interface Example" supplied in Appendix C.3 of [RFC8342].
このセクションは、[RFC8342] の付録 C.3 で提供される「インターフェイスの例」を更新します。
This section provides several use cases related to how <system> interacts with other datastores (e.g., <candidate>, <running>, <intended>, and <operational>). The following fictional interface data model is used:
このセクションでは、<system> が他のデータストアと対話する方法 (<candidate>、<running>、<intended>、<operational> など) に関連するいくつかの使用例を示します。次の架空のインターフェイス データ モデルが使用されます。
module example-interface-management {
yang-version 1.1;
namespace "urn:example:interfacemgmt";
prefix ex-ifm;
import ietf-inet-types {
prefix inet;
}
container interfaces {
list interface {
key "name";
leaf name {
type string;
}
leaf type {
type enumeration {
enum ethernet;
enum atm;
enum loopback;
}
}
leaf enabled {
type boolean;
default "true";
}
leaf-list ip-address {
type inet:ip-address;
}
leaf speed {
when "../type = 'ethernet'";
type enumeration {
enum 10Mb;
enum 100Mb;
}
}
leaf description {
type string;
}
}
}
}
For each use case, corresponding sample configuration in <running>, <system>, <intended>, and <operational> is shown. The XML snippets are used only for illustration purposes.
ユースケースごとに、<running>、<system>、<intended>、および <operational> の対応するサンプル構成が示されています。XML スニペットは、説明のみを目的として使用されています。
When the device is powered on, assume the system provides an always-present loopback interface named "lo0" that is not explicitly configured in <running>. As a result, no interface configuration appears in <running>, and the content of <system> is as follows:
デバイスの電源が入っているとき、システムは、<running> で明示的に構成されていない「lo0」という名前の常時存在するループバック インターフェイスを提供すると想定します。その結果、<running> にはインターフェイス設定は表示されず、<system> の内容は次のようになります。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
</interfaces>
In this case, the configuration of loopback interface is only present in <system>, and the configuration of interface in <intended> would be identical to the one in <system> shown above.
この場合、ループバック インターフェイスの構成は <system> にのみ存在し、<intended> のインターフェイスの構成は、上記の <system> の構成と同じになります。
In addition, <operational> will show the system-provided loopback interface. Note that <operational> also includes the default value specified in the YANG module:
さらに、<operational> には、システムが提供するループバック インターフェイスが表示されます。<operational> には、YANG モジュールで指定されたデフォルト値も含まれることに注意してください。
<interfaces xmlns="urn:example:interfacemgmt"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:system">
<interface>
<name>lo0</name>
<type>loopback</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
</interfaces>
If a client creates an interface "et-0/0/0" but the interface does not physically exist at this point, the content of <running> appears as follows:
クライアントがインターフェイス「et-0/0/0」を作成したが、そのインターフェイスがこの時点で物理的に存在しない場合、<running> の内容は次のように表示されます。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>et-0/0/0</name>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
And the content of <system> remains unchanged, only containing the "lo0" loopback interface since the interface "et-0/0/0" is not physically present:
また、<system> の内容は変更されず、インターフェイス "et-0/0/0" が物理的に存在しないため、"lo0" ループバック インターフェイスのみが含まれます。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
</interfaces>
The content of <intended> represents the merged data of <system> and <running>:
<intended> の内容は、<system> と <running> のマージされたデータを表します。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
Since the interface named "et-0/0/0" does not exist, the associated configuration is not present in <operational>, which appears as follows:
「et-0/0/0」という名前のインターフェイスが存在しないため、関連する設定は <operational> に存在しません。これは次のように表示されます。
<interfaces xmlns="urn:example:interfacemgmt"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<type>loopback</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
</interfaces>
When the interface is installed by the operator, the system will detect it and generate the associated conditionally present interface configuration in <system>. The content of <running> remains unchanged:
インターフェースがオペレータによってインストールされると、システムはそれを検出し、関連する条件付きで存在するインターフェース構成を <system> に生成します。<running> の内容は変更されません。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>et-0/0/0</name>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
And <system> might appear as follows:
<system> は次のように表示される場合があります。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type>ethernet</type>
<description>system-defined interface</description>
</interface>
</interfaces>
Then, <intended> contains the merged configuration of <system> and <running>:
次に、<intended> には、<system> と <running> のマージされた構成が含まれます。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type>ethernet</type>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
And the content of <operational> appears as follows:
<operational> の内容は次のようになります。
<interfaces xmlns="urn:example:interfacemgmt"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<type>loopback</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type or:origin="or:system">ethernet</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
If the client further sets the speed of interface "et-0/0/0" in <running>:
クライアントが <running> でインターフェイス「et-0/0/0」の速度をさらに設定した場合:
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>et-0/0/0</name>
<speed>10Mb</speed>
</interface>
</interfaces>
The content of <system> remains unchanged:
<system> の内容は変更されません。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type>ethernet</type>
<description>system-defined interface</description>
</interface>
</interfaces>
And the content of <intended>, which represents the merged result of <running> and <system>, is as follows:
また、<running> と <system> のマージ結果を表す <intended> の内容は次のとおりです。
<interfaces xmlns="urn:example:interfacemgmt">
<interface>
<name>lo0</name>
<type>loopback</type>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type>ethernet</type>
<ip-address>192.168.10.10</ip-address>
<speed>10Mb</speed>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
And <operational> would appear as follows:
<operational> は次のように表示されます。
<interfaces xmlns="urn:example:interfacemgmt"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<type>loopback</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type or:origin="or:system">ethernet</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>192.168.10.10</ip-address>
<speed>10Mb</speed>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
The authors would like to thank the following for discussions and providing input to this document: Balázs Lengyel, Robert Wilton, Jürgen Schönwälder, Andy Bierman, Martin Björklund, Mohamed Boucadair, Michal Vaško, Alexander Clemm, and Timothy Carey.
著者らは、この文書について議論し、意見を提供してくださった以下の方々に感謝いたします: Balázs Lengyel、Robert Wilton、Jürgen Schönwälder、Andy Bierman、Martin Björklund、Mohamed Boucadair、Michal Vaško、Alexander Clemm、Timothy Carey。
Kent Watsen
Watsen Networks
Email: kent+ietf@watsen.net
Jan Lindblad
Cisco Systems
Email: jlindbla@cisco.com
Jason Sterne
Nokia
Email: jason.sterne@nokia.com
Chongfeng Xie
China Telecom
Beijing
China
Email: xiechf@chinatelecom.cn
Qiufang Ma (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: maqiufang1@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Chong Feng
Email: fengchongllly@gmail.com