Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 9907 YumaWorks
BCP: 216 M. Boucadair, Ed.
Obsoletes: 8407 Orange
Updates: 8126 Q. Wu
Category: Best Current Practice Huawei
ISSN: 2070-1721 March 2026
This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules.
この文書は、IANA が管理する YANG モジュールを含む、YANG データ モデルを含む仕様の作成者およびレビュー担当者向けのガイドラインを提供します。YANG モジュールを利用するネットワーク構成プロトコル (NETCONF) および RESTCONF プロトコル実装の相互運用性と使いやすさを向上させることを目的とした推奨事項と手順が定義されています。
This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.
この文書は RFC 8407 を廃止します。また、IANA が管理する YANG モジュールを指定する RFC に対する IANA の考慮事項を記述するための追加ガイドラインを提供することにより、RFC 8126 を更新します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベスト プラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。BCP の詳細については、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/rfc9907.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9907 で入手できます。
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. Changes Since RFC 8407
2. Terminology and Notation Conventions
2.1. NETCONF Terms
2.2. YANG Terms
2.3. Network Management Datastore Architecture (NMDA) Terms
2.4. Requirements Notation
2.5. YANG Data Model versus YANG Module
3. General Documentation Guidelines
3.1. Module Copyright
3.2. Code Components
3.2.1. Example Modules
3.3. Terminology Section
3.4. Tree Diagrams
3.5. Narrative Sections
3.5.1. YANG Module Classification
3.6. Definitions Section
3.7. Security Considerations Section
3.7.1. Security Considerations Section Template
3.8. IANA Considerations Section
3.8.1. Documents That Create a New Namespace
3.8.2. Documents That Extend an Existing Namespace
3.8.3. Registration Templates
3.9. References Sections
3.10. Validation Tools
3.11. Module Extraction Tools
3.12. Module Usage Examples
4. YANG Usage Guidelines
4.1. Module Naming Conventions
4.2. Prefixes
4.3. Identifiers
4.3.1. Identifier Naming Conventions
4.4. Defaults
4.5. Conditional Statements
4.6. XPath Usage
4.6.1. XPath Evaluation Contexts
4.6.2. Function Library
4.6.3. Axes
4.6.4. Types
4.6.5. Wildcards
4.6.6. Boolean Expressions
4.7. YANG Definition Lifecycle Management
4.8. Module Header, Meta, and Revision Statements
4.9. Namespace Assignments
4.10. Top-Level Data Definitions
4.11. Data Types
4.11.1. Fixed-Value Extensibility
4.11.2. Patterns and Ranges
4.11.3. Enumerations and Bits
4.11.4. Union Types
4.11.5. Empty and Boolean
4.12. Reusable Type Definitions
4.13. Reusable Groupings
4.14. Data Definitions
4.14.1. Non-Presence Containers
4.14.2. Top-Level Data Nodes
4.15. Operation Definitions
4.16. Notification Definitions
4.17. Feature Definitions
4.18. YANG Data Node Constraints
4.18.1. Controlling Quantity
4.18.2. "must" versus "when"
4.19. "augment" Statements
4.19.1. Conditional Augment Statements
4.19.2. Conditionally Mandatory Data Definition Statements
4.20. Deviation Statements
4.21. Extension Statements
4.22. Data Correlation
4.22.1. Use of "leafref" for Key Correlation
4.23. Operational State
4.23.1. Combining Operational State and Configuration Data
4.23.2. Representing Operational Values of Configuration Data
4.23.3. NMDA Transition Guidelines
4.24. Performance Considerations
4.25. Open Systems Considerations
4.26. Guidelines for Constructs Specific to YANG 1.1
4.26.1. Importing Multiple Revisions
4.26.2. Using Feature Logic
4.26.3. "anyxml" versus "anydata"
4.26.4. "action" versus "rpc"
4.27. Updating YANG Modules (Published versus Unpublished)
4.28. Defining Standard Tags
4.29. Modeling Abstract Data Structures
4.30. IANA-Maintained YANG Modules
4.30.1. Context
4.30.2. Guidelines for IANA-Maintained YANG Modules
4.30.3. Guidance for Writing the IANA Considerations for RFCs
Defining IANA-Maintained YANG Modules
5. IANA Considerations
5.1. YANG Modules
5.2. Update in YANG Parameters Registry Group
5.3. IANA-Maintained YANG Modules
5.3.1. Requirements for All Modules
5.3.2. Requirements Subject to Customization
6. Operational Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Module Review Checklist
Appendix B. Template for IETF Modules
Appendix C. Template for IANA-Maintained YANG Modules
Acknowledgments
Authors' Addresses
The standardization of network configuration interfaces for use with network configuration management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040], requires a modular set of data models that can be reused and extended over time.
ネットワーク構成プロトコル (NETCONF) [RFC6241] や RESTCONF [RFC8040] などのネットワーク構成管理プロトコルで使用するネットワーク構成インターフェイスの標準化には、再利用および長期にわたる拡張が可能なモジュール式のデータ モデル セットが必要です。
This document defines a set of guidelines for documents containing YANG 1.1 [RFC7950] and YANG 1.0 [RFC6020] data models, including IANA-maintained YANG modules. YANG is used to define the data structures, protocol operations, and notification content used within a NETCONF and/or RESTCONF server. YANG is also used to define abstract data structures [RFC8791]. A NETCONF or RESTCONF server that supports a particular YANG module will support client NETCONF and/or RESTCONF operation requests, as indicated by the specific content defined in the YANG module.
この文書は、IANA が管理する YANG モジュールを含む、YANG 1.1 [RFC7950] および YANG 1.0 [RFC6020] データ モデルを含む文書に対する一連のガイドラインを定義します。YANG は、NETCONF サーバーや RESTCONF サーバー内で使用されるデータ構造、プロトコル操作、および通知コンテンツを定義するために使用されます。YANG は、抽象データ構造 [RFC8791] を定義するためにも使用されます。特定の YANG モジュールをサポートする NETCONF または RESTCONF サーバーは、YANG モジュールで定義された特定のコンテンツによって示されるように、クライアントの NETCONF および/または RESTCONF 操作リクエストをサポートします。
Many YANG constructs are defined as optional to use, such as the "description" statement. However, in order to make YANG modules more readable and interoperable, it is desirable to define a set of descriptive usage guidelines that entails a higher level of compliance than the minimum level defined in the YANG specification [RFC7950].
多くの YANG 構造は、「description」ステートメントなど、使用がオプションとして定義されています。ただし、YANG モジュールをより読みやすく相互運用可能にするためには、YANG 仕様 [RFC7950] で定義されている最低レベルよりも高いレベルの準拠を必要とする一連の記述的な使用ガイドラインを定義することが望ましい。
In addition, YANG allows constructs such as infinite length identifiers and string values, or top-level mandatory nodes, that a compliant server is not required to support. Only constructs that all servers are required to support can be used in IETF YANG modules.
さらに、YANG では、準拠サーバーがサポートする必要のない、無限長の識別子や文字列値、またはトップレベルの必須ノードなどの構成要素を使用できます。IETF YANG モジュールでは、すべてのサーバーがサポートする必要がある構成のみを使用できます。
This document defines usage guidelines related to the NETCONF Operations layer and NETCONF Content layer, as defined in [RFC6241], and the RESTCONF methods and RESTCONF resources, as defined in [RFC8040].
この文書は、[RFC6241] で定義されている NETCONF オペレーション層と NETCONF コンテンツ層、および [RFC8040] で定義されている RESTCONF メソッドと RESTCONF リソースに関連する使用ガイドラインを定義します。
These guidelines are intended to be used by authors and reviewers to improve the readability and interoperability of published YANG data models. These guidelines can be used independent of the IETF Stream of publication or even by other organizations.
これらのガイドラインは、公開された YANG データ モデルの読みやすさと相互運用性を向上させるために、作成者とレビュー担当者が使用することを目的としています。これらのガイドラインは、IETF の出版ストリームとは独立して、または他の組織によっても使用できます。
YANG 1.0 modules have to conform to [RFC6020] while YANG 1.1 modules have to conform to [RFC7950]; this document adds usage guidelines in addition to these RFCs.
YANG 1.0 モジュールは [RFC6020] に準拠する必要があり、YANG 1.1 モジュールは [RFC7950] に準拠する必要があります。この文書では、これらの RFC に加えて使用ガイドラインを追加します。
Section 4.30.3 updates [RFC8126] by providing guidance for writing the IANA Considerations sections for RFCs that specify IANA-maintained YANG modules.
セクション 4.30.3 は、IANA が保守する YANG モジュールを指定する RFC の IANA 考慮事項セクションを記述するためのガイダンスを提供することにより、[RFC8126] を更新します。
Note that this document is not a YANG tutorial; the reader is expected to know the YANG data modeling language before implementing the guidance in this document.
このドキュメントは YANG チュートリアルではないことに注意してください。読者は、このドキュメントのガイダンスを実装する前に、YANG データ モデリング言語を理解していることが期待されます。
This RFC contains text intended for use as a template as designated below by the markers "<BEGIN TEMPLATE TEXT>" and "<END TEMPLATE TEXT>" or other clear designation. Such Template Text is subject to the provisions of Section 9(b) of the Trust Legal Provisions.
この RFC には、以下のマーカー「<BEGIN TEMPLATE TEXT>」および「<END TEMPLATE TEXT>」またはその他の明確な指定によって指定されるテンプレートとして使用することを目的としたテキストが含まれています。Such Template Text is subject to the provisions of Section 9(b) of the Trust Legal Provisions.
The following changes have been made to the guidelines published in [RFC8407]:
[RFC8407] で公開されたガイドラインに次の変更が加えられました。
* Implemented the following errata reports: [Err5693], [Err5800], [Err6899], and [Err7416].
* 次の正誤表レポートを実装しました: [Err5693]、[Err5800]、[Err6899]、および [Err7416]。
* Updated the terminology.
* 用語を更新しました。
* Added a note about notation conventions.
* 表記規則に関する注記を追加しました。
* Updated the reference information of the IETF author guidelines.
* IETF著者ガイドラインの参考情報を更新しました。
* Updated the guidance so that the "file name" after the "<CODE BEGINS>" tag is mandatory.
* 「<CODE BEGINS>」タグの後の「ファイル名」が必須となるようにガイダンスを更新しました。
* Added template markers for the security template.
* セキュリティ テンプレートのテンプレート マーカーを追加しました。
* Updated the YANG security considerations template to better insist on the key secure transport features.
* 主要な安全なトランスポート機能をより適切に主張するために、YANG セキュリティ考慮事項テンプレートを更新しました。
* Added statements that the security template is not required for modules that follow [RFC8791] or define YANG extensions such as [RFC7952].
* [RFC8791] に従うモジュール、または [RFC7952] などの YANG 拡張を定義するモジュールにはセキュリティ テンプレートは必要ないという記述を追加しました。
* Added a statement about how to cite the RFCs that are listed in the security template.
* セキュリティ テンプレートにリストされている RFC を引用する方法に関するステートメントを追加しました。
* Added a template for IANA registrations.
* IANA 登録用のテンプレートを追加しました。
* Added a note that folding of the examples should be done as per the conventions described in [RFC8792].
* [RFC8792] で説明されている規則に従ってサンプルを折りたたむ必要があるという注記を追加しました。
* Added a recommendation about long trees.
* 長い木に関する推奨事項を追加しました。
* Fixed a reference bug in Section 4.1.
* セクション 4.1 の参照バグを修正しました。
* Added a recommendation for the use of meaningful prefix values.
* 意味のあるプレフィックス値の使用に関する推奨事項が追加されました。
* Added a note that folding of YANG modules as described in RFC 8792 can be used if and only if built-in YANG features (e.g., break line, "+") are not sufficient.
* RFC 8792 で説明されている YANG モジュールの折りたたみは、組み込みの YANG 機能 (ブレークライン、「+」など) が十分ではない場合にのみ使用できるという注記を追加しました。
* Added tool validation checks to ensure that YANG modules fit into the line limits of an I-D.
* YANG モジュールが I-D のライン制限に適合することを確認するためのツール検証チェックが追加されました。
* Added tool validation checks of JSON-encoded examples.
* JSON エンコードされたサンプルのツール検証チェックを追加しました。
* Added a recommendation to ease extracting and validating examples.
* 例の抽出と検証を容易にするための推奨事項を追加しました。
* Updated many examples to be aligned with the consistent indentation recommendation (internal consistency).
* 一貫したインデントの推奨事項 (内部一貫性) に合わせて多くの例を更新しました。
* Updated the guidance for writing IANA Considerations sections to encourage registration requests to indicate whether or not a module is maintained by IANA.
* モジュールが IANA によって保守されているかどうかを示す登録リクエストを奨励するために、IANA の考慮事項セクションを作成するためのガイダンスを更新しました。
* Added guidelines for IANA-maintained YANG modules.
* IANA が管理する YANG モジュールのガイドラインを追加しました。
* Added guidelines about the use of the terms "YANG module" and "YANG data model".
* 「YANG モジュール」および「YANG データ モデル」という用語の使用に関するガイドラインを追加しました。
* Elaborated the guidance for the use of values reserved for documentation in examples.
* 例でのドキュメント用に予約されている値の使用に関するガイダンスを詳しく説明しました。
* Recommended the use of "example:" for URI examples.
* URI の例には「example:」の使用を推奨します。
* Added a new section "Defining Standard Tags" (Section 4.28) to echo the guidance in [RFC8819].
* [RFC8819] のガイダンスを反映するために、新しいセクション「標準タグの定義」(セクション 4.28) を追加しました。
* Recommended against the use of "case + when" construct in some cases.
* 場合によっては、「case + when」構造の使用を推奨しません。
* Added a discussion about the prefix pattern to use for example modules.
* モジュール例に使用するプレフィックス パターンに関する説明を追加しました。
* Updated the NMDA guidance in the narrative text to highlight modules that are not compliant with NMDA.
* NMDA に準拠していないモジュールを強調表示するために、説明テキスト内の NMDA ガイダンスを更新しました。
* Added a new section about the classification of YANG modules.
* YANG モジュールの分類に関する新しいセクションを追加しました。
* Fixed an inconsistency in Section 4.6.2 where the example mentions identities but uses them without their prefix as per Section 4.6.4.
* 例では ID について言及しているが、セクション 4.6.4 に従ってプレフィックスなしで ID を使用しているセクション 4.6.2 の不一致を修正しました。
* Fixed an inconsistency in Section 4.6.4 that failed to use "derived-from-or-self()" mentioned back in Section 4.6.2.
* セクション 4.6.2 で説明した「derived-from-or-self()」の使用に失敗するセクション 4.6.4 の不一致を修正しました。
* Added a new section for modeling abstract data structures.
* 抽象データ構造をモデル化するための新しいセクションを追加しました。
* Added a discussion about "must + error-message" constructs for state data.
* 状態データの「must + エラー メッセージ」構造に関する説明を追加しました。
* Added text about summary of changes in "revision" statements.
* 「改訂」ステートメントの変更の概要に関するテキストを追加しました。
* Added a template for IANA-maintained YANG modules.
* IANA が管理する YANG モジュールのテンプレートを追加しました。
* Updated the wiki URLs to use the new structure.
* 新しい構造を使用するように Wiki URL を更新しました。
* Added "anydata" to the list of statements with mandatory description(s) (Section 4.14).
* 必須の説明を含むステートメントのリストに「anydata」を追加しました (セクション 4.14)。
* Fixed an error (invalid statements) in Section 4.24.
* セクション 4.24 のエラー (無効なステートメント) を修正しました。
* Softened generic I-D authorship guidance.
* 一般的な I-D 著者に関するガイダンスが緩和されました。
Some of the templates defined in the document use "--" to easily identify specific instructions to the authors. Text prefixed with "--" must not be copied as such when using a template. Note that for YANG templates, "//" is used to convey such instructions.
ドキュメント内で定義されているテンプレートの一部では、作成者への具体的な指示を簡単に識別するために「--」を使用しています。テンプレートを使用する場合は、先頭に「--」が付いているテキストをそのままコピーしないでください。YANG テンプレートの場合、そのような指示を伝えるために「//」が使用されることに注意してください。
RFC IIII is used to refer to an RFC that defines an initial version of an IANA-maintained YANG module.
RFC IIII は、IANA が管理する YANG モジュールの初期バージョンを定義する RFC を参照するために使用されます。
The following terms are used throughout this document:
このドキュメントでは次の用語が使用されます。
IANA-maintained YANG module:
IANA が管理する YANG モジュール:
A YANG module that is maintained by IANA and has an IANA registry associated with it (e.g., "iana-tunnel-type" [RFC8675] or "iana-pseudowire-types" [RFC9291]).
IANA によって維持され、IANA レジストリが関連付けられている YANG モジュール (例: "iana-tunnel-type" [RFC8675] または "iana-pseudowire-types" [RFC9291])。
Once an IANA-maintained YANG module is initialized, new values are not directly added to the module. These values are instead added to the companion registry.
IANA が管理する YANG モジュールが初期化されると、新しい値はモジュールに直接追加されません。これらの値は代わりにコンパニオン レジストリに追加されます。
IETF module:
IETFモジュール:
A YANG module that is published by the IETF and that is not maintained by IANA.
IETF によって公開され、IANA によって保守されていない YANG モジュール。
published:
公開された:
A stable release of a module or submodule. For example, the Request for Comments Series described in Section 2.1 of [RFC2026] is considered a stable publication.
モジュールまたはサブモジュールの安定リリース。たとえば、[RFC2026] のセクション 2.1 に記載されている Request for Comments シリーズは、安定した出版物とみなされます。
unpublished:
未公開:
An unstable release of a module or submodule. For example, the Internet-Draft described in Section 2.2 of [RFC2026] is considered an unstable work in progress, subject to change at any time.
モジュールまたはサブモジュールの不安定なリリース。たとえば、[RFC2026] のセクション 2.2 に記載されている Internet-Draft は、進行中の不安定な作業とみなされ、いつでも変更される可能性があります。
YANG fragment:
ヤンフラグメント:
A set of YANG statements that is not intended to represent a complete YANG module or submodule. These statements are not intended for actual use, except to provide an example of YANG statement usage. The invalid syntax "..." is sometimes used to indicate that additional YANG statements would be present in a real YANG module.
完全な YANG モジュールまたはサブモジュールを表すことを目的とした一連の YANG ステートメント。これらのステートメントは、YANG ステートメントの使用例を提供することを除き、実際に使用することを目的としたものではありません。無効な構文「...」は、実際の YANG モジュールに追加の YANG ステートメントが存在することを示すために使用されることがあります。
YANG tree diagram:
ヤンツリー図:
A diagram representing the contents of a YANG module, as defined in [RFC8340]. It is also called a "tree diagram".
[RFC8340] で定義されている、YANG モジュールの内容を表す図。「樹形図」とも呼ばれます。
The following terms are defined in [RFC6241] and are not redefined here:
以下の用語は [RFC6241] で定義されており、ここでは再定義されません。
* capability
* 能力
* client
* クライアント
* protocol operation (or simply "operation")
* プロトコル操作 (または単に「操作」)
* server
* サーバ
The following terms are defined in [RFC7950] and are not redefined here:
以下の用語は [RFC7950] で定義されており、ここでは再定義されません。
* data node
* データノード
* module
* モジュール
* namespace
* 名前空間
* submodule
* サブモジュール
* version
* バージョン
* YANG
* ヤン
* YIN
* 陰
Note that the term "module" may be used as a generic term for a YANG module or submodule. When describing properties that are specific to submodules, the term "submodule" is used instead.
「モジュール」という用語は、YANG モジュールまたはサブモジュールの総称として使用される場合があることに注意してください。サブモジュールに固有のプロパティを説明する場合、代わりに「サブモジュール」という用語が使用されます。
The following terms are defined in [RFC8342] and are not redefined here:
以下の用語は [RFC8342] で定義されており、ここでは再定義されません。
* configuration
* 構成
* conventional configuration datastore
* 従来の構成データストア
* datastore
* データストア
* operational state
* 動作状態
* operational state datastore
* 動作状態データストア
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] で説明されているように解釈されます。
Both [RFC6020] and [RFC7950] make a distinction between the following concepts:
[RFC6020] と [RFC7950] は両方とも、次の概念を区別しています。
data model:
データモデル:
Describes how data is represented and accessed.
データがどのように表現され、アクセスされるかについて説明します。
YANG structures data models into modules for ease of use [RFC8309].
YANG は使いやすいようにデータ モデルをモジュールに構造化します [RFC8309]。
module:
モジュール:
Defines hierarchies of schema nodes to make a self-contained and compilable block of YANG definitions and inclusions.
スキーマ ノードの階層を定義して、YANG 定義とインクルージョンの自己完結型でコンパイル可能なブロックを作成します。
A YANG module is typically a single ".yang" file, starting with a "module" statement.
YANG モジュールは通常、「module」ステートメントで始まる単一の「.yang」ファイルです。
A YANG module may include any number of submodules that are stored in separate ".yang" files starting with a "submodule" statement. Regardless of the presence of submodules, the module and its submodules are externally viewed as a single YANG module.
YANG モジュールには、「submodule」ステートメントで始まる個別の「.yang」ファイルに格納される任意の数のサブモジュールを含めることができます。サブモジュールの存在に関係なく、モジュールとそのサブモジュールは外部からは 1 つの YANG モジュールとして見なされます。
A YANG data model can consist of:
YANG データ モデルは次のもので構成されます。
1. a single YANG module (e.g., [RFC9129]) or
1. 単一の YANG モジュール (例: [RFC9129]) または
2. multiple YANG modules (e.g., [RFC7407]).
2. 複数の YANG モジュール (例: [RFC7407])。
Note that the term "YANG model" is sometimes used as an abbreviation of "YANG data model". However, that term should be avoided in favor of "YANG data model". Likewise, "YANG data module" has no meaning and must be avoided.
なお、「YANGモデル」という用語は、「YANGデータモデル」の略称として使用される場合がある。ただし、この用語は「YANG データ モデル」を優先して避けるべきです。同様に、「YANG データ モジュール」も意味がないため、使用しないでください。
Even if a YANG data model is structured as a single YANG module, the term "YANG data model" should be used in the title, abstract, and in the body of the document where the overall design is described. "YANG module" should be used when a specific "*.yang" file is referenced. Likewise, "YANG module" should be used when using terms related to YANG module specifications (e.g., augmentation or deviation). However, when extending the concepts embodied in a YANG module, authors should refer to those as an extension to the "YANG data model".
YANG データ モデルが単一の YANG モジュールとして構造化されている場合でも、タイトル、要約、および設計全体が説明されている文書の本文では、「YANG データ モデル」という用語を使用する必要があります。特定の「*.yang」ファイルを参照する場合は、「YANG モジュール」を使用する必要があります。同様に、YANG モジュールの仕様に関連する用語 (拡張や偏差など) を使用する場合は、「YANG モジュール」を使用する必要があります。ただし、YANG モジュールに組み込まれた概念を拡張する場合、作成者はそれらを「YANG データ モデル」の拡張として参照する必要があります。
YANG modules being considered for publication in an RFC are contained in Internet-Drafts (I-Ds). Guidelines for authoring an I-D can be found at [ID-Guidelines]. These guidelines are not repeated here.
RFC での公開が検討されている YANG モジュールは、インターネット ドラフト (I-D) に含まれています。I-D を作成するためのガイドラインは、[ID-ガイドライン] でご覧いただけます。これらのガイドラインはここでは繰り返しません。
The following sections MUST be present in an I-D or RFC containing a YANG module:
YANG モジュールを含む I-D または RFC には、次のセクションが存在しなければなりません。
* Narrative sections (Section 3.5)
* 物語セクション (セクション 3.5)
* A Definitions section(s) (Section 3.6)
* A 定義セクション (セクション 3.6)
Additional YANG-specific considerations MUST be included for the following sections:
以下のセクションには、追加の YANG 固有の考慮事項を含める必要があります。
* Security Considerations (Section 3.7)
* セキュリティに関する考慮事項 (セクション 3.7)
* IANA Considerations (Section 3.8)
* IANA に関する考慮事項 (セクション 3.8)
* References (Section 3.9)
* 参考文献 (セクション 3.9)
There are three usage scenarios for YANG that can appear in an I-D or RFC:
I-D または RFC に記載できる YANG の使用シナリオは 3 つあります。
* normative module or submodule
* 標準モジュールまたはサブモジュール
* example module or submodule
* モジュールまたはサブモジュールの例
* example YANG fragment that is not part of any module or submodule
* モジュールまたはサブモジュールの一部ではない YANG フラグメントの例
The guidelines in this document refer mainly to a normative module or submodule, but they may be applicable to example modules and YANG fragments as well.
このドキュメントのガイドラインは主に標準的なモジュールまたはサブモジュールについて言及していますが、サンプル モジュールや YANG フラグメントにも同様に適用できる場合があります。
The module "description" statement MUST contain a reference to the latest approved IETF Trust Copyright statement, which is available at: <https://trustee.ietf.org/license-info/>.
モジュールの「説明」ステートメントには、<https://trustee.ietf.org/license-info/> で入手できる、最新の承認済み IETF Trust Copyright ステートメントへの参照が含まれなければなりません (MUST)。
Each normative YANG module or submodule contained within an I-D or RFC is considered to be a code component. The strings "<CODE BEGINS>" and "<CODE ENDS>" MUST be used to identify each code component.
I-D または RFC 内に含まれる各規範的な YANG モジュールまたはサブモジュールは、コード コンポーネントとみなされます。各コードコンポーネントを識別するには、文字列「<CODE BEGINS>」と「<CODE ENDS>」を使用しなければなりません。
The "<CODE BEGINS>" tag MUST be followed by a string identifying the file name specified in Section 5.2 of [RFC7950]. The name string form that includes the revision date SHOULD be used. The revision date MUST match the date used in the most recent revision of the module.
"<CODE BEGINS>" タグの後には、[RFC7950] のセクション 5.2 で指定されているファイル名を識別する文字列が続かなければなりません (MUST)。リビジョン日付を含む名前文字列形式を使用する必要があります(SHOULD)。リビジョンの日付は、モジュールの最新のリビジョンで使用されている日付と一致する必要があります。
The following example is for the "2016-03-20" revision of the "ietf-foo" module:
次の例は、「ietf-foo」モジュールの「2016-03-20」リビジョンのものです。
file "ietf-foo@2016-03-20.yang"
module ietf-foo {
namespace "urn:ietf:params:xml:ns:yang:ietf-foo";
prefix "foo";
organization "...";
contact "...";
description "...";
revision 2016-03-20 {
description "Latest revision";
reference "RFC FFFF: Foo Protocol";
}
// ... more statements
}
Example modules are not code components. The "<CODE BEGINS>" convention MUST NOT be used for example modules. However, example modules MUST be validated (Section 3.10).
サンプル モジュールはコード コンポーネントではありません。「<CODE BEGINS>」規則をモジュール例に使用してはなりません (MUST NOT)。ただし、サンプルモジュールは検証されなければなりません (セクション 3.10)。
An example module SHOULD be named using the term "example", followed by a hyphen, followed by a descriptive name, e.g., "example-toaster".
サンプルモジュールの名前は、「example」という用語の後にハイフンを付け、その後にわかりやすい名前を付ける必要があります (例: 「example-toaster」)。
See Section 4.9 regarding the namespace guidelines for example modules.
モジュール例の名前空間ガイドラインについては、セクション 4.9 を参照してください。
A terminology section MUST be present if any terms are defined in the document or if any terms are imported from other documents.
文書内で用語が定義されている場合、または用語が他の文書からインポートされている場合は、用語セクションが存在しなければなりません。
YANG tree diagrams provide a concise representation of a YANG module and SHOULD be included to help readers understand YANG module structure. Guidelines on tree diagrams can be found in Section 3 of [RFC8340]. Tree diagrams longer than one page SHOULD be included in an appendix, i.e., not in the main body of the document.
YANG ツリー図は、YANG モジュールの簡潔な表現を提供し、読者が YANG モジュールの構造を理解できるように含める必要があります (SHOULD)。樹形図に関するガイドラインは、[RFC8340] のセクション 3 に記載されています。1 ページを超えるツリー図は付録に含めるべきです (SHOULD)。つまり、文書の本文には含めないでください。
If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. Refer to Section 2.2 of [RFC8349] for an example of such a reference.
YANG ツリー図を使用する場合は、YANG ツリー図仕様への有益な参照を文書に含める必要があります。このような参照の例については、[RFC8349] のセクション 2.2 を参照してください。
The narrative sections MUST include an overview section that describes the scope and field of application of the data model(s) defined by the specification and that specifies the relationship (if any) of these data models to other standards, particularly to standards containing other YANG data models. The narrative part SHOULD include one or more sections to briefly describe the structure of the data models defined in the specification.
説明セクションには、仕様によって定義されたデータ モデルの適用範囲と分野を説明し、これらのデータ モデルと他の標準、特に他の YANG データ モデルを含む標準との関係 (存在する場合) を指定する概要セクションを含めなければなりません (MUST)。説明部分には、仕様で定義されているデータモデルの構造を簡単に説明する 1 つ以上のセクションを含める必要があります (SHOULD)。
If the module (or modules) defined by the specification imports definitions from other modules (except for those defined in [RFC7950] or [RFC9911]) or is always implemented in conjunction with other modules, then those facts MUST be noted in the overview section; any special interpretations of definitions in other modules MUST be noted as well. Refer to Section 2.3 of [RFC8349] for an example of this overview section.
仕様で定義されているモジュールが他のモジュール ([RFC7950] または [RFC9911] で定義されているモジュールを除く) から定義をインポートする場合、または常に他のモジュールと組み合わせて実装される場合、それらの事実は概要セクションに記載されなければなりません (MUST)。他のモジュールの定義の特別な解釈にも注意する必要があります。この概要セクションの例については、[RFC8349] のセクション 2.3 を参照してください。
If the document contains major Network Management Datastore Architecture (NMDA) exceptions or includes a temporary non-NMDA module [RFC8342], then the Introduction section SHOULD mention this fact with the reasoning that motivated that design. Refer to Section 4.23 for more NMDA-related guidance. Specifically, Section 4.23.2 includes a recommendation for designers to describe and justify any NMDA exceptions in detail as part of the module itself.
文書に主要な Network Management Datastore Architecture (NMDA) 例外が含まれる場合、または一時的な非 NMDA モジュール [RFC8342] が含まれる場合、「はじめに」セクションで、その設計の動機となった理由とともにこの事実に言及する必要があります (SHOULD)。NMDA 関連のガイダンスの詳細については、セクション 4.23 を参照してください。具体的には、セクション 4.23.2 には、設計者がモジュール自体の一部として NMDA 例外を詳細に説明し、正当化するための推奨事項が含まれています。
Consistent indentation SHOULD be used for all examples, including YANG fragments and protocol message instance data. If line wrapping is used for formatting purposes, then this SHOULD be indicated per the guidance in [RFC8792], as shown in the following example:
YANG フラグメントやプロトコル メッセージ インスタンス データを含むすべての例で、一貫したインデントを使用する必要があります (SHOULD)。書式設定の目的で行の折り返しが使用される場合、次の例に示すように、[RFC8792] のガイダンスに従ってこれを示す必要があります (SHOULD)。
=============== NOTE: '\' line wrapping per RFC 8792 ================
<myleaf xmlns="tag:example.com,2017:example-two">this is a long \
value so the line needs to wrap to stay within 72 characters</myleaf>
Built-in YANG features (e.g., breaking line, "+") SHOULD be used to fit a module into the line limits. Exceptionally, YANG modules MAY be folded as described in RFC 8792 if and only if built-in YANG features are not sufficient. A similar approach (e.g., using "-- tree-line-length 69" or splitting a tree into subtrees) SHOULD be followed for tree diagrams.
モジュールを行制限内に収めるには、組み込みの YANG 機能 (例: 改行、「+」) を使用する必要があります。例外的に、組み込みの YANG 機能が十分ではない場合に限り、RFC 8792 の記述に従って YANG モジュールを折りたたむことができます (MAY)。樹形図についても同様のアプローチ（例：「--tree-line-length 69」を使用するか、ツリーをサブツリーに分割する）に従うべきです（SHOULD）。
The narrative section SHOULD include a mention of the classification of a given model. Such a mention is meant to ease positioning the module in the overall operational ecosystem. Specifically, the following types from [RFC8309] and [RFC8969] can be used:
説明セクションには、特定のモデルの分類についての言及を含めるべきです(SHOULD)。このような言及は、運用エコシステム全体におけるモジュールの位置付けを容易にすることを目的としています。具体的には、[RFC8309] および [RFC8969] の次の型を使用できます。
Service Model:
サービスモデル:
Describes a service and the parameters of the service in a portable way that can be used uniformly and independent of the equipment and operating environment.
機器や動作環境に依存せず、均一に使用できるポータブルな方法でサービスとサービスのパラメータを記述します。
Examples of service models are the L3VPN Service Model (L3SM) [RFC8299] and the L2VPN Service Model (L2SM) [RFC8466].
サービス モデルの例としては、L3VPN サービス モデル (L3SM) [RFC8299] および L2VPN サービス モデル (L2SM) [RFC8466] があります。
Network Model:
ネットワークモデル:
Describes a network-level abstraction (or a subset of aspects of a network infrastructure), including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices. This model corresponds to the network configuration model discussed in [RFC8309].
デバイスとそのサブシステム、および複数のデバイスにわたるリンク層とネットワーク層で動作する関連プロトコルを含む、ネットワーク レベルの抽象化 (またはネットワーク インフラストラクチャの側面のサブセット) について説明します。このモデルは、[RFC8309] で議論されているネットワーク構成モデルに対応します。
This model can be used by a network operator to allocate resources (e.g., a tunnel resource or a topology resource) for the service or to schedule resources to meet the service requirements defined in a service model.
このモデルは、ネットワーク オペレータがサービスにリソース (トンネル リソースやトポロジ リソースなど) を割り当てたり、サービス モデルで定義されたサービス要件を満たすようにリソースをスケジュールしたりするために使用できます。
Examples of network models are the L3VPN Network Model (L3NM) [RFC9182] or the L2VPN Network Model (L2NM) [RFC9291].
ネットワーク モデルの例としては、L3VPN ネットワーク モデル (L3NM) [RFC9182] または L2VPN ネットワーク モデル (L2NM) [RFC9291] があります。
Device Model:
デバイスモデル:
Refers to the Network Element YANG data model described in [RFC8199] or the device configuration model discussed in [RFC8309].
[RFC8199] で説明されているネットワーク要素 YANG データ モデル、または [RFC8309] で説明されているデバイス構成モデルを指します。
Device models are also used to model a function embedded in a device (e.g., Access Control Lists (ACLs) [RFC8519]).
デバイス モデルは、デバイスに組み込まれた機能をモデル化するためにも使用されます (例: アクセス コントロール リスト (ACL) [RFC8519])。
A non-comprehensive list of device models is provided in Appendix A.4.4 of [RFC8969].
デバイスモデルの非包括的なリストは、[RFC8969] の付録 A.4.4 に提供されています。
This section contains the module(s) defined by the specification. These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax. YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or semantics are needed in the module. If any of the imported YANG modules are written using YANG 1.1, then the module MUST be written using YANG 1.1.
このセクションには、仕様によって定義されたモジュールが含まれています。これらのモジュールは、YANG 1.1 [RFC7950] 構文を使用して記述すべきです(SHOULD)。モジュール内で YANG 1.1 の構造やセマンティクスが必要ない場合は、YANG 1.0 [RFC6020] 構文を使用してもよい(MAY)。インポートされた YANG モジュールのいずれかが YANG 1.1 を使用して書かれている場合、そのモジュールは YANG 1.1 を使用して書かれなければなりません。
A YANG Independent Notation (YIN) syntax version (Section 13 of [RFC7950]) of the module MAY also be present in the document. There MAY also be other types of modules present in the document, such as Structure of Management Information Version 2 (SMIv2), which are not affected by these guidelines.
モジュールの YANG Independent Notation (YIN) 構文バージョン ([RFC7950] のセクション 13) も文書内に存在してもよい(MAY)。この文書には、これらのガイドラインの影響を受けない、管理情報バージョン 2 (SMIv2) の構造など、他のタイプのモジュールが存在する場合もあります。
Note that if the module itself is considered normative and not an example module or example YANG fragment, then all YANG statements within a YANG module are considered normative. The use of keywords defined in [RFC2119] and [RFC8174] apply to YANG "description" statements in normative modules exactly as they would in any other normative section.
サンプルモジュールまたはサンプル YANG フラグメントではなく、モジュール自体が規範的であるとみなされる場合、YANG モジュール内のすべての YANG ステートメントが規範的であるとみなされることに注意してください。[RFC2119] および [RFC8174] で定義されているキーワードの使用は、他の規範セクションと同様に、規範モジュールの YANG "description" ステートメントに適用されます。
Example YANG modules and example YANG fragments MUST NOT contain any normative text, including any key words from [RFC2119] and [RFC8174].
YANG モジュールの例と YANG フラグメントの例には、[RFC2119] および [RFC8174] のキーワードを含むいかなる規範的なテキストも含めてはなりません (MUST NOT)。
Consistent indentation and formatting (e.g., folding) SHOULD be used in all YANG statements within a module.
モジュール内のすべての YANG ステートメントでは、一貫したインデントと書式設定 (折りたたみなど) を使用する必要があります (SHOULD)。
See Section 4 for guidelines on YANG usage.
YANG の使用に関するガイドラインについては、セクション 4 を参照してください。
Each specification that defines one or more modules MUST contain a section that discusses security considerations relevant to those modules.
1 つ以上のモジュールを定義する各仕様には、それらのモジュールに関連するセキュリティの考慮事項について説明するセクションが含まれなければなりません (MUST)。
Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]), the security section MUST be modeled after the latest approved template (available at <https://wiki.ietf.org/group/ops/yang-security-guidelines>). Section 3.7.1 contains the security considerations template. Authors MUST check the web page at the URL listed above in case there is a more recent version available.
モジュールが [RFC8791] に準拠しているか、YANG 拡張機能 (例: [RFC7952]) を定義していない限り、セキュリティ セクションは、最新の承認されたテンプレート (<https://wiki.ietf.org/group/ops/yang-security-guidelines> で入手可能) に基づいてモデル化しなければなりません (MUST)。セクション 3.7.1 には、セキュリティに関する考慮事項のテンプレートが含まれています。作成者は、利用可能なより新しいバージョンがある場合には、上記の URL にある Web ページを確認する必要があります。
In particular:
特に：
* Writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name, and the associated security risks MUST be explained.
* 悪用された場合に特に破壊的となる可能性のある書き込み可能なデータノードは、名前で明示的にリストされなければならず、関連するセキュリティリスクも説明されなければなりません。
* Readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name, and the reasons for the sensitivity/privacy concerns MUST be explained.
* 特に機密情報を含む、または重大なプライバシー上の懸念を引き起こす読み取り可能なデータノードは、名前で明示的にリストされなければならず、機密性/プライバシー上の懸念の理由も説明されなければなりません。
* Operations (i.e., YANG "rpc" statements) that are potentially harmful to system behavior or that raise significant privacy concerns MUST be explicitly listed by name, and the reasons for the sensitivity/privacy concerns MUST be explained.
* システムの動作に潜在的に有害な操作、または重大なプライバシー上の懸念を引き起こす操作 (つまり、YANG "rpc" ステートメント) は、名前で明示的にリストされなければならず、機密性やプライバシーに関する懸念の理由も説明されなければなりません。
Documents that exclusively define modules that follow the extension in [RFC8791] are not required to include the security template in Section 3.7.1. Likewise, following the template is not required for modules that define YANG extensions such as [RFC7952].
[RFC8791] の拡張に従うモジュールのみを定義する文書には、セクション 3.7.1 にセキュリティ テンプレートを含める必要はありません。同様に、[RFC7952] などの YANG 拡張を定義するモジュールでは、テンプレートに従う必要はありません。
<BEGIN TEMPLATE TEXT>
X. Security Considerations
This section is modeled after the template described in Section 3.7.1
of [RFC9907].
The "<module-name>" 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 (e.g., Secure Shell (SSH)
[RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
mutual authentication.
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.
-- Note: RFC 8341 (or a future RFC that replaces it) MUST be listed
-- as a normative reference.
-- By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, and
-- RFC 9907 (or future RFCs that replace any of them) are listed as
-- informative references unless normatively cited in other sections
-- of the document that specifies the YANG module.
-- Writable nodes section:
--
-- If the data model contains any writable data nodes (those are all
-- the "config true" nodes), then include the following text:
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be sensitive or
vulnerable in some network environments. Write
operations (e.g., edit-config) and delete operations to these data
nodes without proper protection or authentication can have a negative
effect on network operations. The following subtrees and data nodes
have particular sensitivities/vulnerabilities:
-- If the data model contains any particularly sensitive data nodes,
-- e.g., ones that are protected by a "nacm:default-deny-write"
-- or a "nacm:default-deny-all" extensions statement, then those
-- subtrees and data nodes must be listed, with an explanation of the
-- associated security risks with a focus on how they can be
-- disruptive if abused. Otherwise, state:
--
-- "There are no particularly sensitive writable data nodes."
-- Readable nodes section:
--
-- If the data model contains any readable data nodes (i.e., those
-- that are "config false" nodes, but also all other nodes because
-- they can also be read via operations like get or get-config), then
-- include the following text:
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following
subtrees and data nodes have particular sensitivities/
vulnerabilities:
-- You must evaluate whether the data model contains any readable
-- data nodes (those are all the "config false" nodes, but also all
-- other nodes because they can also be read via operations like get
-- or get-config) that are particularly sensitive or vulnerable
-- (e.g., if they might reveal customer information or violate
-- personal privacy laws). Typically, particularly sensitive
-- readable data nodes are ones that are protected by a
-- "nacm:default-deny-read" or a "nacm:default-deny-all" extensions
-- statement.
--
-- Otherwise, state:
-- "There are no particularly sensitive readable data nodes."
-- RPC/action operations section:
--
-- If the data model contains any RPC or action operations, then
-- include the following text:
Some of the RPC or action operations in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control access to these operations.
Specifically, the following operations have particular
sensitivities/ vulnerabilities:
-- If the data model contains any particularly sensitive RPC
-- or action operations, then those operations must be listed
-- here, along with an explanation of the associated specific
-- sensitivity or vulnerability concerns.
--
-- Otherwise, state:
-- "There are no particularly sensitive RPC or action operations."
-- Reusable groupings from other modules section:
--
-- If the data model reuses groupings from other modules and
-- the document that specifies these groupings also
-- includes those as data nodes, then add this text as a
-- reminder of the specific sensitivity or vulnerability of
-- reused nodes.
This YANG module uses groupings from other YANG modules that
define nodes that may be considered sensitive or vulnerable
in network environments. Refer to the Security Considerations
of <RFC-insert-numbers> for information as to which nodes may
be considered sensitive or vulnerable in network environments.
-- No data nodes section:
--
-- If the data model does not define any data nodes (i.e., none
-- of the above sections or readable/writable data nodes or RPCs
-- have been included), then add the following text:
The YANG module defines a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG
modules. The module by itself does not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to
the YANG module that need to be considered.
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example').
<END TEMPLATE TEXT>
Each normative YANG module MUST be registered in both the "IETF XML Registry" group [RFC3688] [IANA-XML] and the "YANG Module Names" registry [RFC6020] [IANA-MOD-NAMES]. The registration request in the "YANG Module Names" registry should indicate whether or not the module is IANA-maintained. This applies to new modules and updated modules. An example of an update registration for the "ietf-template" module can be found in Section 5.
各標準 YANG モジュールは、「IETF XML レジストリ」グループ [RFC3688] [IANA-XML] と「YANG モジュール名」レジストリ [RFC6020] [IANA-MOD-NAMES] の両方に登録しなければなりません (MUST)。「YANG Module Names」レジストリの登録リクエストは、モジュールが IANA によって管理されているかどうかを示す必要があります。これは、新しいモジュールと更新されたモジュールに適用されます。「ietf-template」モジュールの更新登録の例はセクション 5 にあります。
Additional IANA considerations applicable to IANA-maintained YANG modules (including instructions to maintain them) are provided in Section 4.30.3.
IANA が保守する YANG モジュールに適用される追加の IANA 考慮事項 (モジュールを保守する手順を含む) は、セクション 4.30.3 に記載されています。
If an I-D defines a new namespace that is to be administered by the IANA, then the document MUST include an IANA Considerations section that specifies how the namespace is to be administered.
I-D が IANA によって管理される新しい名前空間を定義する場合、その文書には名前空間の管理方法を指定する IANA の考慮事項セクションが含まれなければなりません (MUST)。
Specifically, if any YANG module "namespace" statement value contained in the document is not already registered with IANA, then a new entry in the "ns" registry within the "IETF XML Registry" registry group MUST be requested from the IANA.
具体的には、文書に含まれる YANG モジュールの「namespace」ステートメントの値がまだ IANA に登録されていない場合、「IETF XML Registry」レジストリ グループ内の「ns」レジストリへの新しいエントリを IANA に要求しなければなりません (MUST)。
A registration template for new YANG modules is provided in Section 3.8.3.1.
新しい YANG モジュールの登録テンプレートはセクション 3.8.3.1 で提供されます。
It is possible to extend an existing namespace using a YANG submodule that belongs to an existing module already administered by IANA. In this case, the document containing the main module MUST be updated to use the latest revision of the submodule.
IANA によってすでに管理されている既存のモジュールに属する YANG サブモジュールを使用して、既存の名前空間を拡張することができます。この場合、メインモジュールを含むドキュメントは、サブモジュールの最新リビジョンを使用するように更新する必要があります。
A registration template for a new module is provided below:
新しいモジュールの登録テンプレートは以下に提供されます。
IANA is requested to register the following URI in the "ns"
registry within the "IETF XML Registry" group [RFC3688]:
URI:
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG
Module Names" registry [RFC6020] within the "YANG Parameters"
registry group.
Name:
Maintained by IANA? Y/N
Namespace:
Prefix:
Reference:
A registration template for a revised module is provided below:
改訂されたモジュールの登録テンプレートは以下に提供されます。
IANA is requested to update the following registration in the "ns"
registry within the "IETF XML Registry" group [RFC3688] to
reference this document:
URI:
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG
Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
registry group.
Name:
Maintained by IANA? Y/N
Namespace:
Prefix:
Reference:
For every "import" or "include" statement that appears in a module contained in the specification that identifies a module in a separate document, a corresponding normative reference to that document MUST appear in the Normative References section. The reference MUST correspond to the specific module version actually used within the specification.
別の文書内のモジュールを識別する、仕様に含まれるモジュールに出現するすべての「import」または「include」ステートメントについて、その文書への対応する規範的参照が規範的参照セクションに記載されなければなりません(MUST)。参照は、仕様内で実際に使用される特定のモジュールのバージョンに対応していなければなりません。
For every normative "reference" statement that appears in a module contained in the specification that identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification. If the "reference" statement identifies an informative reference that identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section.
別の文書を識別する仕様に含まれるモジュールに現れるすべての規範的な「参照」ステートメントについて、その文書への対応する規範的な参照が規範的な参照セクションに表示されるべきです(SHOULD)。参照は、仕様内で実際に使用される特定のドキュメントのバージョンに対応する必要があります (SHOULD)。「参照」ステートメントが別の文書を識別する情報参照を識別する場合、その文書への対応する情報参照が「情報参照」セクションに表示されてもよい(MAY)。
All modules need to be validated before submission in an I-D. The 'pyang' YANG compiler is freely available from GitHub: <https://github.com/mbj4668/pyang>.
I-D で提出する前に、すべてのモジュールを検証する必要があります。「pyang」YANG コンパイラは、GitHub: <https://github.com/mbj4668/pyang> から無料で入手できます。
If the 'pyang' compiler is used to validate a normative module, then the "--ietf" command-line option MUST be used to identify any IETF guideline issues.
標準モジュールの検証に「pyang」コンパイラを使用する場合、IETF ガイドラインの問題を特定するために「--ietf」コマンドライン オプションを使用しなければなりません。
If the 'pyang' compiler is used to validate an example module, then the "--ietf" command-line option MAY be used to identify any IETF guideline issues.
「pyang」コンパイラを使用してサンプルモジュールを検証する場合、「--ietf」コマンドラインオプションを使用して IETF ガイドラインの問題を特定できます (MAY)。
To ensure that a module fits into the line limits of an I-D, the command "pyang -f yang --keep-comments --yang-line-length 69" should be used.
モジュールが I-D の行制限に確実に収まるようにするには、コマンド「pyang -f yang --keep-comments --yang-line-length 69」を使用する必要があります。
The 'yanglint' program is also freely available from GitHub: <https://github.com/CESNET/libyang>.
「yanglint」プログラムは、GitHub: <https://github.com/CESNET/libyang> からも無料で入手できます。
This tool can be used to validate "XPath" statements within YANG modules.
このツールは、YANG モジュール内の「XPath」ステートメントを検証するために使用できます。
To check that JSON-encoded examples [RFC7951] comply with the target data models, programs such as 'yangson' or 'yanglint' should be used. Both programs are freely available from GitHub: <https://github.com/ CZ-NIC/yangson> and <https://github.com/CESNET/libyang>.
JSON でエンコードされたサンプル [RFC7951] がターゲット データ モデルに準拠していることを確認するには、「yangson」や「yanglint」などのプログラムを使用する必要があります。どちらのプログラムも GitHub: <https://github.com/CZ-NIC/yangson> および <https://github.com/CESNET/libyang> から無料で入手できます。
A version of 'rfcstrip' that will extract YANG modules from an I-D or RFC is freely available at: <https://github.com/mbj4668/rfcstrip>.
I-D または RFC から YANG モジュールを抽出する「rfcstrip」のバージョンは、<https://github.com/mbj4668/rfcstrip> から無料で入手できます。
This tool can be used to verify that the "<CODE BEGINS>" and "<CODE ENDS>" tags are used correctly and that the normative YANG modules can be extracted correctly.
このツールを使用すると、「<CODE BEGINS>」タグと「<CODE ENDS>」タグが正しく使用されていること、および標準的な YANG モジュールが正しく抽出できることを検証できます。
The 'xym' tool is freely available on GitHub and can be used to extract YANG modules from a document: <https://github.com/xym-tool/ xym>.
「xym」ツールは GitHub で無料で入手でき、ドキュメント <https://github.com/xym-tool/xym> から YANG モジュールを抽出するために使用できます。
Each specification that defines one or more modules SHOULD contain usage examples, either throughout the document or in an appendix. This includes example instance document snippets in an appropriate encoding (e.g., XML and/or JSON) to demonstrate the intended usage of the YANG module(s). Examples that are meant to illustrate a valid data instance MUST be validated (Section 3.10). Refer to Section 3.10 for tools that validate YANG modules and examples. If IP addresses/prefixes are used, then a mix of either IPv4 and IPv6 addresses/prefixes or IPv6 addresses/prefixes exclusively SHOULD be used in the examples.
1 つ以上のモジュールを定義する各仕様には、文書全体または付録に使用例が含まれている必要があります (SHOULD)。これには、YANG モジュールの使用目的を示す、適切なエンコーディング (XML や JSON など) のサンプル インスタンス ドキュメント スニペットが含まれています。有効なデータインスタンスを示すことを目的とした例は検証されなければなりません (セクション 3.10)。YANG モジュールを検証するツールと例については、セクション 3.10 を参照してください。IP アドレス/プレフィックスが使用される場合、例では IPv4 と IPv6 のアドレス/プレフィックス、または IPv6 アドレス/プレフィックスのいずれかを排他的に使用する必要があります (SHOULD)。
For some types (IP addresses, domain names, etc.), the IETF has reserved values for documentation use. Authors SHOULD use these reserved values in the usage examples if these types are used. Examples of reserved values are listed below:
一部のタイプ (IP アドレス、ドメイン名など) については、IETF がドキュメントで使用するために予約された値を持っています。これらのタイプが使用される場合、作成者は使用例でこれらの予約値を使用する必要があります (SHOULD)。予約値の例を以下に示します。
* IPv4 and IPv6 addresses/prefixes reserved for documentation are defined in [RFC5737], [RFC3849], and [RFC9637].
* ドキュメント用に予約されている IPv4 および IPv6 アドレス/プレフィックスは、[RFC5737]、[RFC3849]、および [RFC9637] で定義されています。
* The Enterprise Number 32473 reserved for documentation use is defined in [RFC5612].
* 文書使用のために予約されているエンタープライズ番号 32473 は [RFC5612] で定義されています。
* Autonomous System Numbers (ASNs) reserved for documentation use are defined in [RFC5398].
* 文書使用のために予約されている自律システム番号 (ASN) は [RFC5398] で定義されています。
* Reserved domain names for documentation are defined in [RFC2606].
* ドキュメント用に予約されたドメイン名は [RFC2606] で定義されています。
URI examples SHOULD be prefixed with "example:".
URI の例には「example:」という接頭辞を付ける必要があります (SHOULD)。
In order to ease extraction and validation of examples, it is RECOMMENDED to use code markers.
例の抽出と検証を容易にするために、コード マーカーを使用することが推奨されます。
Modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG 1.1 [RFC7950]. See the exception for YANG 1.0 in Section 3.6. The guidelines in this section are intended to supplement the YANG specification [RFC7950], which is intended to define a minimum set of conformance requirements.
IETF Standards Track 仕様のモジュールは、YANG 1.1 [RFC7950] のすべての構文要件と意味要件に準拠しなければなりません (MUST)。セクション 3.6 の YANG 1.0 の例外を参照してください。このセクションのガイドラインは、最小限の適合要件を定義することを目的とした YANG 仕様 [RFC7950] を補足することを目的としています。
In order to promote interoperability and establish a set of practices based on previous experience, the following sections establish usage guidelines for specific YANG constructs.
相互運用性を促進し、以前の経験に基づいて一連のプラクティスを確立するために、次のセクションでは、特定の YANG 構造の使用ガイドラインを確立します。
Only guidelines that clarify or restrict the minimum conformance requirements are included here.
ここには、最低限の適合要件を明確にするか制限するガイドラインのみが含まれています。
A template for IETF modules is provided in Appendix B.
IETF モジュールのテンプレートは付録 B に提供されています。
Normative modules contained in Standards Track documents MUST be named according to the guidelines in the IANA Considerations section of [RFC6020].
Standards Track 文書に含まれる標準モジュールは、[RFC6020] の IANA の考慮事項セクションのガイドラインに従って名前を付けなければなりません (MUST)。
A distinctive word or abbreviation (e.g., protocol name or working group abbreviation) SHOULD be used in the module name. If new definitions are being defined to extend one or more existing modules, then the same word or abbreviation should be reused, instead of creating a new one.
モジュール名には、独特の単語や略語（例：プロトコル名やワーキンググループの略語）を使用する必要があります（SHOULD）。1 つ以上の既存のモジュールを拡張するために新しい定義を定義する場合は、新しい定義を作成するのではなく、同じ単語または略語を再利用する必要があります。
All published module names MUST be unique. For a YANG module published in an RFC, this uniqueness is guaranteed by IANA (Section 14 of [RFC6020]). For unpublished modules, the authors need to check that no other work in progress is using the same module name.
公開されたすべてのモジュール名は一意である必要があります。RFC で公開された YANG モジュールの場合、この一意性は IANA によって保証されています ([RFC6020] のセクション 14)。未公開モジュールの場合、作成者は同じモジュール名を使用している進行中の作業が他にないことを確認する必要があります。
Example modules are non-normative and SHOULD be named with the prefix "example-".
サンプルモジュールは非規範的であり、接頭辞「example-」を付けて名前を付ける必要があります (SHOULD)。
It is suggested that a stable module name prefix be selected that represents the entire organization. All normative YANG modules published by the IETF MUST begin with the prefix "ietf-". All IANA-maintained YANG modules MUST begin with the prefix "iana-". Another standards organization, such as the IEEE, might use the prefix "ieee-" for all YANG modules.
組織全体を表す安定したモジュール名のプレフィックスを選択することをお勧めします。IETF によって公開されたすべての標準 YANG モジュールは、接頭辞「ietf-」で始まらなければなりません。IANA が管理するすべての YANG モジュールは、接頭辞「iana-」で始まらなければなりません。IEEE などの別の標準化団体は、すべての YANG モジュールにプレフィックス「ieee-」を使用する場合があります。
Once a module name is published, it MUST NOT be reused, even if the RFC containing the module is reclassified to "Historic" status. A module name cannot be changed in YANG, and this would be treated as a new module, not a name change.
モジュール名が公開されると、そのモジュールを含む RFC が「歴史的」ステータスに再分類されたとしても、そのモジュール名を再利用してはなりません。YANG ではモジュール名を変更できません。これは名前の変更ではなく、新しいモジュールとして扱われます。
All YANG definitions are scoped by the module containing the definition being referenced. This allows the same name to be used in multiple modules, even if the names are not unique. In the example below, the identifier "foo" is used in all three modules:
すべての YANG 定義は、参照される定義を含むモジュールによってスコープされます。これにより、名前が一意でなくても、複数のモジュールで同じ名前を使用できます。以下の例では、識別子「foo」が 3 つのモジュールすべてで使用されています。
module example-foo {
namespace "tag:example.com,2017:example-foo";
prefix f;
container foo;
}
module example-bar {
namespace "tag:example.com,2017:example-bar";
prefix b;
typedef foo { type uint32; }
}
module example-one {
namespace "tag:example.com,2017:example-one";
prefix one;
import example-foo { prefix f; }
import example-bar { prefix b; }
augment "/f:foo" {
leaf foo { type b:foo; }
}
}
YANG defines the following rules for prefix usage:
YANG では、プレフィックスの使用に関して次のルールを定義しています。
* Prefixes are never used for built-in data types and YANG keywords.
* 接頭辞は、組み込みデータ型および YANG キーワードには使用されません。
* A prefix MUST be used for any external statement (i.e., a statement defined with the YANG "extension" statement).
* 接頭辞は、外部ステートメント (つまり、YANG "拡張" ステートメントで定義されたステートメント) に使用しなければなりません (MUST)。
* The proper module prefix MUST be used for all identifiers imported from other modules.
* 他のモジュールからインポートされるすべての識別子には、適切なモジュール接頭辞を使用しなければなりません (MUST)。
* The proper module prefix MUST be used for all identifiers included from a submodule.
* サブモジュールから含まれるすべての識別子には、適切なモジュール接頭辞を使用しなければなりません (MUST)。
The following guidelines apply to prefix usage of the current (local) module:
次のガイドラインは、現在の (ローカル) モジュールのプレフィックスの使用に適用されます。
* The local module prefix SHOULD be used instead of no prefix in all path expressions.
* すべてのパス式で接頭辞を使用しない代わりに、ローカル モジュールの接頭辞を使用する必要があります (SHOULD)。
* The local module prefix MUST be used instead of no prefix in all "default" statements for an "identityref" or "instance-identifier" data type.
* 「identityref」または「instance-identifier」データ型のすべての「default」ステートメントでは、プレフィックスなしの代わりにローカル モジュール プレフィックスを使用しなければなりません（MUST）。
* The local module prefix MAY be used for references to typedefs, groupings, extensions, features, and identities defined in the module.
* ローカルモジュールプレフィックスは、モジュールで定義された typedef、グループ化、拡張機能、機能、およびアイデンティティへの参照に使用できます (MAY)。
Consistent with Section 7.1.4 of [RFC7950], the prefix defined by a module SHOULD be used when the module is imported, unless there is a conflict.
[RFC7950] のセクション 7.1.4 に従って、競合がない限り、モジュールがインポートされるときは、モジュールによって定義されたプレフィックスを使用する必要があります (SHOULD)。
Prefix values SHOULD be short but meaningful to the intended user. Prefix values SHOULD NOT conflict with known modules that have been previously published.
プレフィックス値は短くても、対象ユーザーにとって意味のあるものである必要があります。プレフィックス値は、以前に公開された既知のモジュールと競合してはなりません。
For convenience, prefix values of example modules SHOULD be prefixed with "ex" or similar patterns. In doing so, readers of example modules or tree diagrams that mix both example and standard modules can easily identify example parts.
便宜上、サンプルモジュールのプレフィックス値には「ex」または同様のパターンをプレフィックスとして付ける必要があります。そうすることで、サンプル モジュールや、サンプル モジュールと標準モジュールの両方が混在するツリー図の読者は、サンプル パーツを簡単に識別できます。
All YANG identifiers in published modules MUST be between 1 and 64 characters in length. These include any construct specified as an "identifier-arg-str" token in the ABNF in Section 14 of [RFC7950].
公開されたモジュール内のすべての YANG 識別子の長さは 1 ～ 64 文字でなければなりません。これらには、[RFC7950] のセクション 14 の ABNF で「identifier-arg-str」トークンとして指定されているすべての構造が含まれます。
Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lowercase letters, numbers, and dashes SHOULD be used in identifier names. Uppercase characters, the period character, and the underscore character MAY be used if the identifier represents a well-known value that uses these characters. YANG does not permit any other characters in YANG identifiers.
識別子は、モジュール全体で一貫した命名パターンに従う必要があります (SHOULD)。識別子名には小文字、数字、ダッシュのみを使用する必要があります(SHOULD)。識別子がこれらの文字を使用する既知の値を表す場合、大文字、ピリオド文字、およびアンダースコア文字を使用してもよい(MAY)。YANG では、YANG 識別子に他の文字を使用することはできません。
Identifiers SHOULD include complete words and/or well-known acronyms or abbreviations. Child nodes within a container or list SHOULD NOT replicate the parent identifier. YANG identifiers are hierarchical and are only meant to be unique within the set of sibling nodes defined in the same module namespace.
識別子には、完全な単語やよく知られた頭字語や略語を含めるべきです(SHOULD)。コンテナまたはリスト内の子ノードは、親識別子を複製してはなりません (SHOULD NOT)。YANG 識別子は階層的であり、同じモジュール名前空間で定義された兄弟ノードのセット内でのみ一意であることを意味します。
List identifiers SHOULD be singular with the surrounding container name plural. Similarly, "leaf-list" identifiers SHOULD be singular.
リスト識別子は単数形で、周囲のコンテナ名は複数形である必要があります(SHOULD)。同様に、「リーフリスト」識別子は単数形であるべきです(SHOULD)。
It is permissible to use common identifiers such as "name" or "id" in data definition statements, especially if these data nodes share a common data type.
特にこれらのデータ ノードが共通のデータ型を共有する場合、データ定義ステートメントで「name」や「id」などの共通の識別子を使用することが許可されます。
Identifiers SHOULD NOT carry any special semantics that identify data modeling properties. Only YANG statements and YANG extension statements are designed to convey machine-readable data modeling properties. For example, naming an object "config" or "state" does not change whether it is configuration data or state data. Only defined YANG statements or YANG "extension" statements can be used to assign semantics in a machine-readable format in YANG.
識別子には、データ モデリングのプロパティを識別する特別なセマンティクスを含めるべきではありません。YANG ステートメントと YANG 拡張ステートメントのみが、機械可読なデータ モデリング プロパティを伝えるように設計されています。たとえば、オブジェクトに「config」または「state」という名前を付けても、それが構成データであるか状態データであるかは変わりません。YANG で機械可読形式でセマンティクスを割り当てるために使用できるのは、定義された YANG ステートメントまたは YANG "拡張" ステートメントのみです。
In general, it is suggested that substatements containing very common default values SHOULD NOT be present. The substatements listed in Table 1 are commonly used with the default value, which would make the module difficult to read if used everywhere they are allowed.
一般に、非常に一般的なデフォルト値を含むサブステートメントは存在しないことが推奨されます。表 1 にリストされているサブステートメントは通常、デフォルト値で使用されるため、許可されている場所で使用するとモジュールが読みにくくなります。
+==============+===============+
| Statement | Default Value |
+==============+===============+
| config | true |
+--------------+---------------+
| mandatory | false |
+--------------+---------------+
| max-elements | unbounded |
+--------------+---------------+
| min-elements | 0 |
+--------------+---------------+
| ordered-by | system |
+--------------+---------------+
| status | current |
+--------------+---------------+
| yin-element | false |
+--------------+---------------+
Table 1: Statement Defaults
表 1: ステートメントのデフォルト
A module may be conceptually partitioned in several ways using the "if-feature" and/or "when" statements.
モジュールは、「if-feature」および/または「when」ステートメントを使用して、概念的にいくつかの方法で分割できます。
Data model designers need to carefully consider all modularity aspects, including the use of YANG conditional statements.
データ モデルの設計者は、YANG 条件ステートメントの使用を含む、モジュール性のすべての側面を慎重に検討する必要があります。
If a data definition is optional, depending on server support for a NETCONF or RESTCONF protocol capability, then a YANG "feature" statement SHOULD be defined. The defined "feature" statement SHOULD then be used in the conditional "if-feature" statement referencing the optional data definition.
データ定義がオプションの場合、NETCONF または RESTCONF プロトコル機能に対するサーバーのサポートに応じて、YANG "feature" ステートメントを定義する必要があります (SHOULD)。定義された「feature」ステートメントは、オプションのデータ定義を参照する条件付き「if-feature」ステートメントで使用されるべきです(SHOULD)。
If any notification data, or any data definition, for a non-configuration data node is not mandatory, then the server may or may not be required to return an instance of this data node. If any conditional requirements exist for returning the data node in a notification payload or retrieval request, they MUST be documented somewhere. For example, a "when" or "if-feature" statement could apply to the data node or the conditional requirements could be explained in a "description" statement within the data node or one of its ancestors (if any).
非構成データ ノードの通知データまたはデータ定義が必須ではない場合、サーバーはこのデータ ノードのインスタンスを返す必要がある場合とそうでない場合があります。通知ペイロードまたは取得リクエストでデータ ノードを返すための条件付き要件が存在する場合、それをどこかに文書化する必要があります。たとえば、「when」または「if-feature」ステートメントをデータ ノードに適用したり、データ ノードまたはその祖先 (存在する場合) の 1 つ内の「description」ステートメントで条件付き要件を説明したりできます。
If any "if-feature" statements apply to a list node, then the same "if-feature" statements MUST apply to any key leaf nodes for the list. There MUST NOT be any "if-feature" statements applied to any key leafs that do not also apply to the parent list node.
「if-feature」ステートメントがリスト ノードに適用される場合、同じ「if-feature」ステートメントがリストのキー リーフ ノードに適用されなければなりません(MUST)。親リスト ノードにも適用されないキー リーフに適用される「if-feature」ステートメントがあってはなりません。
There SHOULD NOT be any "when" statements applied to a key leaf node. It is possible that a "when" statement for an ancestor node of a key leaf will have the exact node-set result as the key leaf. In such a case, the "when" statement for the key leaf is redundant and SHOULD be avoided.
キーリーフノードに「when」ステートメントを適用してはなりません (SHOULD NOT)。キー リーフの祖先ノードの「when」ステートメントには、キー リーフと同じノード セットの結果が含まれる可能性があります。このような場合、キーリーフの「when」ステートメントは冗長であり、避けるべきです(SHOULD)。
Some modules use a "case + when" construct but provide duplicated information (e.g., the "when" statements are constraining a single case in the choice as shown in the example below). Such constructs with duplicated information SHOULD NOT be used.
一部のモジュールは「case + when」構造を使用しますが、重複した情報を提供します (たとえば、以下の例に示すように、「when」ステートメントは選択内の 1 つの case を制約します)。重複した情報を持つこのような構成は使用すべきではありません (SHOULD NOT)。
leaf type {
type enumeration {
enum a;
enum b;
enum c;
}
mandatory true;
}
choice type-choice {
case b {
container type-b {
when "../type = 'b'";
leaf foo {
type string;
}
}
}
case c {
container type-c {
when "../type = 'c'";
leaf bar {
mandatory true;
type string;
}
}
}
}
The following example removes the duplicated information:
次の例では、重複した情報を削除します。
leaf type {
type enumeration {
enum a;
enum b;
enum c;
}
mandatory true;
}
container type-b {
when "../type = 'b'";
leaf foo {
type string;
}
}
container type-c {
when "../type = 'c'";
leaf bar {
mandatory true;
type string;
}
}
Note that the use of "case + when" is still useful in cases where complementary modeling constraints should be expressed. See the example provided below:
「case + when」の使用は、相補的なモデリング制約を表現する必要がある場合に引き続き便利であることに注意してください。以下の例を参照してください。
leaf type {
type enumeration {
enum a;
enum b;
enum c;
}
}
choice second-type {
mandatory true;
case foo {
container foo {
presence "When present, indicates type foo";
leaf foo-attribute {
type string;
}
}
}
case b {
container bar {
when "../type = 'a' or ../type = 'b'";
presence "When present, indicates type bar";
leaf bar-attribute {
type string;
}
}
}
case c {
container baz {
when "../type = 'c'";
leaf baz-attribute {
mandatory true;
type string;
}
}
}
}
Section 8.1 of [RFC7950] includes provisions for defining constraints on state data and specifies that a constraint must be true in a valid state data tree. However, Section 5.3 of [RFC8342] softens that behavior by allowing semantic constraints to be violated under some circumstances to help to detect anomalies. Relaxing validation constraints on state data is meant to reveal deviations of the observed behavior versus intended behavior of a managed entity and hopefully trigger corrective actions by a management system. From that perspective, it is RECOMMENDED to avoid defining constraints on state data that would hinder the detection by a management system of abnormal behaviors of a managed entity.
[RFC7950] のセクション 8.1 には、状態データに対する制約を定義するための規定が含まれており、有効な状態データ ツリーでは制約が真でなければならないと指定されています。ただし、[RFC8342] のセクション 5.3 では、異常の検出を支援するために、特定の状況下でのセマンティック制約の違反を許可することで、その動作を緩和しています。状態データに対する検証制約を緩和することは、管理対象エンティティの意図された動作に対する観察された動作の逸脱を明らかにし、できれば管理システムによる修正措置を引き起こすことを目的としています。その観点から、管理システムによる管理対象エンティティの異常な動作の検出を妨げるような、状態データに対する制約の定義を避けることが推奨されます。
This section describes guidelines for using the XML Path Language (XPath) [W3C.REC-xpath] within YANG modules.
このセクションでは、YANG モジュール内で XML パス言語 (XPath) [W3C.REC-xpath] を使用するためのガイドラインについて説明します。
YANG defines five separate contexts for evaluation of "XPath" statements:
YANG は、「XPath」ステートメントの評価用に 5 つの個別のコンテキストを定義します。
1. The "running" datastore: collection of all YANG configuration data nodes. The document root is the conceptual container (e.g., "config" in the "edit-config" operation), which is the parent of all top-level data definition statements with a "config" statement value of "true".
1. 「実行中の」データストア: すべての YANG 構成データ ノードのコレクション。ドキュメント ルートは概念的コンテナ (たとえば、「edit-config」操作の「config」) であり、「config」ステートメントの値が「true」であるすべてのトップレベル データ定義ステートメントの親です。
2. State data + the "running" datastore: collection of all YANG data nodes. The document root is the conceptual container, parent of all top-level data definition statements.
2. 状態データ + 「実行中」データストア: すべての YANG データ ノードのコレクション。ドキュメント ルートは概念的なコンテナであり、すべてのトップレベル データ定義ステートメントの親です。
3. Notification: an event notification document. The document root is the notification element.
3. 通知: イベント通知文書。ドキュメント ルートは通知要素です。
4. RPC Input: The document root is the conceptual "input" node, which is the parent of all RPC input parameter definitions.
4. RPC 入力: ドキュメント ルートは概念的な「入力」ノードであり、すべての RPC 入力パラメーター定義の親です。
5. RPC Output: The document root is the conceptual "output" node, which is the parent of all RPC output parameter definitions.
5. RPC 出力: ドキュメント ルートは概念的な「出力」ノードであり、すべての RPC 出力パラメーター定義の親です。
Note that these XPath contexts cannot be mixed. For example, a "when" statement in a notification context cannot reference configuration data.
これらの XPath コンテキストは混合できないことに注意してください。たとえば、通知コンテキストの「when」ステートメントは構成データを参照できません。
notification foo {
leaf mtu {
// NOT okay because when-stmt context is this notification
when "/if:interfaces/if:interface[name='eth0']";
type leafref {
// Okay because path-stmt has a different context
path "/if:interfaces/if:interface/if:mtu";
}
}
}
It is especially important to consider the XPath evaluation context for XPath expressions defined in groupings. An XPath expression defined in a grouping may not be portable, meaning it cannot be used in multiple contexts and produce proper results.
グループ化で定義された XPath 式の XPath 評価コンテキストを考慮することが特に重要です。グループ内で定義された XPath 式は移植性がない場合があります。つまり、複数のコンテキストで使用して適切な結果を生成することはできません。
If the XPath expressions defined in a grouping are intended for a particular context, then this context SHOULD be identified in the "description" statement for the grouping.
グループ化で定義された XPath 式が特定のコンテキストを対象としている場合、このコンテキストはグループ化の「説明」ステートメントで識別される必要があります (SHOULD)。
The "position" and "last" functions SHOULD NOT be used. This applies to implicit use of the "position" function as well (e.g., '//chapter[42]'). A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The "position" and "last" functions MAY be used if they are evaluated in a context where the context node is a user-ordered "list" or "leaf-list".
「position」関数と「last」関数は使用しないでください。これは、「位置」関数の暗黙的な使用にも当てはまります (例: '//chapter[42]')。サーバーは、特定のユーザー順序リストまたはリーフリストのすべてのインスタンスの相対的な XML ドキュメントの順序を維持することのみを必要とします。「position」関数と「last」関数は、コンテキストノードがユーザーが順序付けした「リスト」または「リーフリスト」であるコンテキストで評価される場合に使用できます（MAY）。
The "id" function SHOULD NOT be used. The "ID" attribute is not present in YANG documents, so this function has no meaning. The XPath execution environment SHOULD return an empty string for this function.
「id」関数は使用すべきではありません。YANG ドキュメントには「ID」属性が存在しないため、この関数は意味を持ちません。XPath 実行環境は、この関数に対して空の文字列を返す必要があります (SHOULD)。
The "namespace-uri" and "name" functions SHOULD NOT be used. Expanded names in XPath are different than YANG. A specific canonical representation of a YANG-expanded name does not exist.
「namespace-uri」関数と「name」関数は使用しないでください。XPath での展開名は YANG とは異なります。YANG 拡張名の特定の正規表現は存在しません。
The "lang" function SHOULD NOT be used. This function does not apply to YANG because there is no "lang" attribute set with the document. The XPath execution environment SHOULD return "false" for this function.
「lang」関数は使用しないでください。ドキュメントに「lang」属性が設定されていないため、この関数は YANG には適用されません。XPath 実行環境は、この関数に対して「false」を返す必要があります (SHOULD)。
The "local-name", "namespace-uri", "name", "string", and "number" functions SHOULD NOT be used if the argument is a node-set. If so, the function result will be determined by the document order of the node-set. Since this order can be different on each server, the function results can also be different. Any function call that implicitly converts a node-set to a string will also have this issue.
引数がノードセットの場合、「local-name」、「namespace-uri」、「name」、「string」、「number」関数は使用すべきではありません（SHOULD NOT）。その場合、関数の結果はノードセットのドキュメント順序によって決まります。この順序はサーバーごとに異なる可能性があるため、関数の結果も異なる可能性があります。ノードセットを暗黙的に文字列に変換する関数呼び出しにも、この問題が発生します。
The "local-name" function SHOULD NOT be used to reference local names outside of the YANG module that defines the "must" or "when" statement containing the "local-name" function. Example of a "local-name" function that should not be used:
「local-name」関数は、「local-name」関数を含む「must」または「when」ステートメントを定義する YANG モジュールの外部でローカル名を参照するために使用してはなりません (SHOULD NOT)。使用すべきではない「local-name」関数の例:
/*[local-name()='foo']
The "derived-from-or-self" function SHOULD be used instead of an equality expression for identityref values. This allows the identities to be conceptually augmented.
「derived-from-or-self」関数は、identityref 値の等価式の代わりに使用されるべきです (SHOULD)。これにより、アイデンティティを概念的に強化することができます。
Example:
例：
// assume "ex" is the prefix of the module where the identity
// name-format-null is defined
// do not use
when "md-name-format = 'name-format-null'";
// this is preferred
when "derived-from-or-self(md-name-format, 'ex:name-format-null')";
The "attribute" and "namespace" axes are not supported in YANG and MAY be empty in a NETCONF or RESTCONF server implementation.
「属性」軸と「名前空間」軸は YANG ではサポートされていないため、NETCONF または RESTCONF サーバー実装では空にすることができます。
The "preceding" and "following" axes SHOULD NOT be used. These constructs rely on XML document order within a NETCONF or RESTCONF server configuration database, which may not be supported consistently or produce reliable results across implementations. Predicate expressions based on static node properties (e.g., element name or value, and "ancestor" or "descendant" axes) SHOULD be used instead. The "preceding" and "following" axes MAY be used if document order is not relevant to the outcome of the expression (e.g., check for global uniqueness of a parameter value).
「前」軸と「後」軸は使用しないでください。これらの構造は、NETCONF または RESTCONF サーバー構成データベース内の XML ドキュメントの順序に依存しているため、一貫してサポートされていない可能性や、実装間で信頼できる結果が得られない可能性があります。代わりに、静的なノードのプロパティ (要素名または値、「祖先」軸または「子孫」軸など) に基づく述語式を使用する必要があります (SHOULD)。「前」軸と「後」軸は、文書の順序が式の結果に関連しない場合 (たとえば、パラメータ値のグローバルな一意性のチェック) に使用できます (MAY)。
The "preceding-sibling" and "following-sibling" axes SHOULD NOT be used; however, they MAY be used if document order is not relevant to the outcome of the expression.
「preceding-sibling」軸と「following-sibling」軸は使用しないでください。ただし、文書の順序が式の結果に関係ない場合には使用してもよい(MAY)。
A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The "preceding-sibling" and "following-sibling" axes MAY be used if they are evaluated in a context where the context node is a user-ordered "list" or "leaf-list".
サーバーは、特定のユーザー順序リストまたはリーフリストのすべてのインスタンスの相対的な XML ドキュメントの順序を維持することのみを必要とします。"preceding-sibling" 軸と "following-sibling" 軸は、コンテキスト ノードがユーザー順序の "リスト" または "リーフ リスト" であるコンテキストで評価される場合に使用できます (MAY)。
Data nodes that use the "int64" and "uint64" built-in type SHOULD NOT be used within numeric or boolean expressions. There are boundary conditions in which the translation from the YANG 64-bit type to an XPath number can cause incorrect results. Specifically, an XPath "double" precision floating-point number cannot represent very large positive or negative 64-bit numbers because it only provides a total precision of 53 bits. The "int64" and "uint64" data types MAY be used in numeric expressions if the value can be represented with no more than 53 bits of precision.
「int64」および「uint64」組み込み型を使用するデータ ノードは、数値式またはブール式内で使用しないでください。YANG 64 ビット型から XPath 数値への変換によって誤った結果が生じる可能性がある境界条件があります。具体的には、XPath の「倍」精度浮動小数点数は、合計精度が 53 ビットしか提供しないため、非常に大きな正または負の 64 ビット数値を表すことができません。「int64」および「uint64」データ型は、値が 53 ビット以下の精度で表現できる場合、数値式で使用できます (MAY)。
Data modelers need to be careful not to confuse the YANG value space and the XPath value space. The data types are not the same in both, and conversion between YANG and XPath data types SHOULD be considered carefully.
データ モデラーは、YANG 値空間と XPath 値空間を混同しないように注意する必要があります。どちらのデータ型も同じではないため、YANG データ型と XPath データ型の間の変換は慎重に検討する必要があります。
Explicit XPath data type conversions MAY be used (e.g., "string", "boolean", or "number" functions), instead of implicit XPath data type conversions.
暗黙的な XPath データ型変換の代わりに、明示的な XPath データ型変換 (例: "string"、"boolean"、または "number" 関数) を使用してもよい(MAY)。
XPath expressions that contain a literal value representing a YANG identity SHOULD always include the declared prefix of the module where the identity is defined.
YANG ID を表すリテラル値を含む XPath 式には、ID が定義されているモジュールの宣言されたプレフィックスを常に含める必要があります (SHOULD)。
XPath expressions for "when" statements SHOULD NOT reference the context node or any descendant nodes of the context node. They MAY reference descendant nodes if the "when" statement is contained within an "augment" statement and the referenced nodes are not defined within the "augment" statement.
「when」ステートメントの XPath 式は、コンテキスト ノードまたはコンテキスト ノードの子孫ノードを参照してはなりません (SHOULD NOT)。「when」ステートメントが「augment」ステートメント内に含まれており、参照されるノードが「augment」ステートメント内で定義されていない場合、それらは子孫ノードを参照してもよい(MAY)。
Example:
例：
augment "/rt:active-route/rt:input/rt:destination-address" {
when "derived-from-or-self(rt:address-family, "
+ "'v4ur:ipv4-unicast')" {
description
"This augment is valid only for IPv4 unicast.";
}
// nodes defined here within the augment-stmt
// cannot be referenced in the when-stmt
}
It is possible to construct XPath expressions that will evaluate differently when combined with several modules within a server implementation rather than when evaluated within the single module. This is due to augmenting nodes from other modules.
単一モジュール内で評価される場合ではなく、サーバー実装内の複数のモジュールと組み合わせた場合に異なる評価を行う XPath 式を構築することが可能です。これは、他のモジュールからノードを増強するためです。
Wildcard expansion is done within a server against all the nodes from all namespaces, so it is possible for a "must" or "when" statement that uses the '*' operator to always evaluate to false if processed within a single YANG module. In such cases, the "description" statement SHOULD clarify that augmenting objects are expected to match the wildcard expansion.
ワイルドカード展開は、すべての名前空間のすべてのノードに対してサーバー内で実行されるため、単一の YANG モジュール内で処理される場合、'*' 演算子を使用する "must" または "when" ステートメントが常に false に評価される可能性があります。このような場合、「説明」ステートメントは、拡張オブジェクトがワイルドカード拡張に一致することが期待されていることを明確にする必要があります (SHOULD)。
when /foo/services/*/active {
description
"No services directly defined in this module.
Matches objects that have augmented the services container.";
}
The YANG "must" and "when" statements use an XPath boolean expression to define the test condition for the statement. It is important to specify these expressions in a way that will not cause inadvertent changes in the result if the objects referenced in the expression are updated in future revisions of the module.
YANG の「must」および「when」ステートメントは、XPath ブール式を使用してステートメントのテスト条件を定義します。式で参照されるオブジェクトがモジュールの将来のリビジョンで更新された場合に、結果に不注意による変更が生じない方法でこれらの式を指定することが重要です。
For example, the leaf "foo2" must exist if the leaf "foo1" is equal to "one" or "three":
たとえば、リーフ「foo1」が「one」または「three」に等しい場合、リーフ「foo2」が存在する必要があります。
leaf foo1 {
type enumeration {
enum one;
enum two;
enum three;
}
}
leaf foo2 {
// INCORRECT
must "/f:foo1 != 'two'";
type string;
}
leaf foo2 {
// CORRECT
must "/f:foo1 = 'one' or /f:foo1 = 'three'";
type string;
}
In the next revision of the module, leaf "foo1" is extended with a new enum named "four":
モジュールの次のリビジョンでは、リーフ「foo1」が「four」という名前の新しい列挙型で拡張されます。
leaf foo1 {
type enumeration {
enum one;
enum two;
enum three;
enum four;
}
}
Now the first XPath expression will allow the enum "four" to be accepted in addition to the "one" and "three" enum values.
これで、最初の XPath 式では、列挙値「one」および「three」に加えて、列挙「four」も受け入れられるようになります。
The YANG status statement MUST be present within a definition if its value is "deprecated" or "obsolete". The status SHOULD NOT be changed from "current" directly to "obsolete". An object SHOULD be available for at least one year after the publication date with a "deprecated" status before it is changed to "obsolete".
YANG ステータス ステートメントは、その値が「非推奨」または「廃止」の場合、定義内に存在しなければなりません。ステータスを「現在」から「廃止」に直接変更すべきではありません。オブジェクトは、「廃止」に変更される前に、公開日から少なくとも 1 年間は「非推奨」ステータスで利用可能であるべきです(SHOULD)。
The module or submodule name MUST NOT be changed once the document containing the module or submodule is published.
モジュールまたはサブモジュールを含むドキュメントが公開された後は、モジュールまたはサブモジュール名を変更してはなりません。
The module namespace URI value MUST NOT be changed once the document containing the module is published.
モジュールの名前空間 URI 値は、モジュールを含むドキュメントが公開された後は変更してはなりません。
The revision date substatement within the "import" statement SHOULD be present if any groupings are used from the external module.
外部モジュールからグループ化が使用される場合、「import」ステートメント内のリビジョン日付サブステートメントが存在する必要があります (SHOULD)。
The revision date substatement within the "include" statement SHOULD be present if any groupings are used from the external submodule.
外部サブモジュールからグループ化が使用される場合、「include」ステートメント内のリビジョン日付サブステートメントが存在する必要があります (SHOULD)。
If an "import" statement is for a module from a stable source (e.g., an RFC for an IETF module), then a reference-stmt SHOULD be present within an "import" statement.
「import」ステートメントが安定したソース (IETF モジュールの RFC など) からのモジュール用である場合、reference-stmt は「import」ステートメント内に存在する必要があります (SHOULD)。
import ietf-yang-types {
prefix yang;
reference "RFC 9911: Common YANG Data Types";
}
If submodules are used, then the document containing the main module MUST be updated so that the main module revision date is equal to or more recent than the revision date of any submodule that is (directly or indirectly) included by the main module.
サブモジュールを使用する場合、メイン モジュールを含むドキュメントは、メイン モジュールの改訂日が、メイン モジュールに (直接的または間接的に) 含まれるサブモジュールの改訂日と同じか、それ以降になるように更新しなければなりません (MUST)。
Definitions for future use SHOULD NOT be specified in a module. Do not specify placeholder objects like the "reserved" example below:
将来使用するための定義をモジュール内で指定すべきではありません。以下の「予約済み」の例のようなプレースホルダー オブジェクトを指定しないでください。
leaf reserved {
type string;
description
"This object has no purpose at this time, but a future
revision of this module might define a purpose
for this object.";
}
For published modules, the namespace MUST be a globally unique URI, as defined in [RFC3986]. This value is usually assigned by the IANA.
公開されたモジュールの場合、名前空間は [RFC3986] で定義されているように、グローバルに一意な URI でなければなりません (MUST)。この値は通常、IANA によって割り当てられます。
The "organization" statement MUST be present. If the module is contained in a document intended for IETF Standards Track status, then the organization SHOULD be the IETF working group (WG) chartered to write the document. Exceptions include (but are not limited to): example modules, IANA-maintained YANG modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.
「組織」ステートメントが存在する必要があります。モジュールが IETF Standards Track ステータスを対象とした文書に含まれている場合、その組織は文書の作成を認可された IETF ワーキング グループ (WG) であるべきです。例外には、サンプル モジュール、IANA が管理する YANG モジュール、または AD スポンサーのドキュメントに含まれるモジュールが含まれます (ただし、これらに限定されません)。他の標準化団体についても、同様のアプローチが提案されています。
The "contact" statement MUST be present. If the module is contained in a document intended for Standards Track status, then the WG web and mailing information SHOULD be present, and the main document author or editor contact information SHOULD be present. If additional authors or editors exist, their contact information MAY be present. There is no need to include the contact information for WG Chairs.
「contact」ステートメントが存在する必要があります。モジュールが Standards Track ステータスを目的とした文書に含まれている場合、WG の Web およびメール情報が存在する必要があり (SHOULD)、主要な文書の作成者または編集者の連絡先情報が存在する必要があります (SHOULD)。追加の著者または編集者が存在する場合、その連絡先情報が存在する場合があります。WG 議長の連絡先情報を含める必要はありません。
The "description" statement MUST be present. For modules published within IETF documents, the appropriate IETF Trust Copyright text MUST be present, as described in Section 3.1, and MUST contain the following statement:
「説明」ステートメントが存在する必要があります。IETF ドキュメント内で公開されたモジュールの場合、セクション 3.1 で説明されているように、適切な IETF Trust Copyright テキストが存在しなければならず、次のステートメントが含まれていなければなりません。
All revisions of IETF and IANA published modules can be found at the "YANG Parameters" registry group: <https://www.iana.org/assignments/yang-parameters>.
IETF および IANA が公開したモジュールのすべてのリビジョンは、「YANG Parameters」レジストリ グループ: <https://www.iana.org/assignments/yang-parameters> にあります。
If the module relies on information contained in other documents, which are not the same documents implied by the "import" statements present in the module, then these documents MUST be identified in the "reference" statement.
モジュールが、モジュール内に存在する「import」ステートメントによって暗示される同じドキュメントではない他のドキュメントに含まれる情報に依存する場合、これらのドキュメントは「reference」ステートメントで識別されなければなりません(MUST)。
A "revision" statement MUST be present for each published version of the module. The "revision" statement MUST have a "reference" substatement. It MUST identify the published document that contains the module. Modules are often extracted from their original documents, and it is useful for developers and operators to know how to find the original source document in a consistent manner. The "revision" statement MAY have a "description" substatement. For convenience, the description text of a new published revision may summarize any changes made to a module compared to the previous published revision. Typically, that list is a YANG-specific subset of the summary of changes listing any changes made from the RFC being updated or obsoleted as per [ID-Guidelines].
「リビジョン」ステートメントは、モジュールの公開バージョンごとに存在しなければなりません。「revision」ステートメントには「reference」サブステートメントが必要です。モジュールを含む公開ドキュメントを識別する必要があります。モジュールは元のドキュメントから抽出されることが多く、開発者やオペレータにとって、一貫した方法で元のソース ドキュメントを見つける方法を知っておくと役立ちます。「revision」ステートメントには「description」サブステートメントがあってもよい(MAY)。便宜上、新しく公開されたリビジョンの説明テキストには、以前に公開されたリビジョンと比較してモジュールに加えられた変更が要約されている場合があります。通常、そのリストは、[ID-ガイドライン]に従って更新または廃止された RFC から行われた変更をリストした変更概要の YANG 固有のサブセットです。
The following example shows the "revision" statement for a published YANG module:
次の例は、公開された YANG モジュールの「revision」ステートメントを示しています。
revision 2010-09-24 {
description
"Initial revision.";
reference
"RFC 6021: Common YANG Data Types";
}
The following example shows the "revision" statements for a published YANG module that updates a published module. The new "revision" statement summarizes the changes compared to the previous published revision.
次の例は、公開されたモジュールを更新する、公開された YANG モジュールの「リビジョン」ステートメントを示しています。新しい「リビジョン」ステートメントには、以前に公開されたリビジョンと比較した変更点がまとめられています。
revision 2013-07-15 {
description
"This revision adds the following new data types:
- yang:yang-identifier
- yang:hex-string
- yang:uuid
- yang:dotted-quad";
reference
"RFC 6991: Common YANG Data Types";
}
revision 2010-09-24 {
description
"Initial revision.";
reference
"RFC 6021: Common YANG Data Types";
}
For an unpublished module, a complete history of each unpublished module revision is not required. That is, within a sequence of draft versions, only the most recent revision need be recorded in the module. Do not remove or reuse a "revision" statement for a published module. A new revision date is not required unless the module contents have changed. If the module contents have changed, then the revision date of that new module version MUST be updated to a date later than that of the previous version.
未公開モジュールの場合、未公開モジュールの各リビジョンの完全な履歴は必要ありません。つまり、一連のドラフト バージョン内では、最新のリビジョンのみをモジュールに記録する必要があります。公開されたモジュールの「リビジョン」ステートメントを削除したり再利用したりしないでください。モジュールの内容が変更されない限り、新しい改訂日は必要ありません。モジュールの内容が変更された場合、その新しいモジュール バージョンの改訂日は、以前のバージョンよりも後の日付に更新されなければなりません (MUST)。
The following example shows the "revision" statements for an unpublished update to a published YANG module. The latest "revision" statement of the unpublished module summarizes the changes compared to the previous revision.
次の例は、公開された YANG モジュールに対する未公開の更新の「リビジョン」ステートメントを示しています。未公開モジュールの最新の「リビジョン」ステートメントには、以前のリビジョンと比較した変更点がまとめられています。
revision 2025-12-22 {
description
"This revision adds the following new data types:
- yang:date
- yang:date-no-zone
- yang:time
- yang:time-no-zone
- yang:hours32
- yang:minutes32
- yang:seconds32
- yang:centiseconds32
- yang:milliseconds32
- yang:microseconds32
- yang:microseconds64
- yang:nanoseconds32
- yang:nanoseconds64
- yang:language-tag
The yang-identifier definition has been aligned with YANG
1.1 and types representing time support the representation
of leap seconds. The representation of time zone offsets
has been aligned with RFC 9557. Several description and
pattern statements have been improved.";
reference
"RFC 9911: Common YANG Data Types";
}
revision 2013-07-15 {
description
"This revision adds the following new data types:
- yang:yang-identifier
- yang:hex-string
- yang:uuid
- yang:dotted-quad";
reference
"RFC 6991: Common YANG Data Types";
}
revision 2010-09-24 {
description
"Initial revision.";
reference
"RFC 6021: Common YANG Data Types";
}
It is RECOMMENDED that only valid YANG modules be included in documents, whether or not the modules are published yet. This allows:
モジュールがまだ公開されているかどうかに関係なく、有効な YANG モジュールのみをドキュメントに含めることが推奨されます。これにより、次のことが可能になります。
* the module to compile correctly instead of generating disruptive fatal errors.
* 破壊的な致命的なエラーを生成するのではなく、モジュールを正しくコンパイルできるようになります。
* early implementors to use the modules without picking a random value for the XML namespace.
* 初期の実装者は、XML 名前空間のランダムな値を選択せずにモジュールを使用できます。
* early interoperability testing since independent implementations will use the same XML namespace value.
* 独立した実装では同じ XML 名前空間値が使用されるため、早期の相互運用性テストが行われます。
Until a URI is assigned by the IANA, a proposed namespace URI MUST be provided for the "namespace" statement in a YANG module. A value SHOULD be selected that is not likely to collide with other YANG namespaces. Standard module names, prefixes, and URI strings already listed in the "YANG Module Names" registry group MUST NOT be used.
IANA によって URI が割り当てられるまで、提案された名前空間 URI が YANG モジュールの「namespace」ステートメントに提供されなければなりません (MUST)。他の YANG 名前空間と衝突する可能性が低い値を選択する必要があります (SHOULD)。「YANG Module Names」レジストリ グループにすでにリストされている標準モジュール名、プレフィックス、および URI 文字列は使用してはなりません。
A standard "namespace" statement value SHOULD have the following form:
標準の「名前空間」ステートメント値は次の形式である必要があります。
<URN prefix string>:<module-name>
The following URN prefix string SHOULD be used for published and unpublished YANG modules:
次の URN プレフィックス文字列は、公開および非公開の YANG モジュールに使用する必要があります (SHOULD)。
urn:ietf:params:xml:ns:yang
The following example URNs would be valid "namespace" statement values for Standards Track modules:
次の URN の例は、Standards Track モジュールの有効な「名前空間」ステートメントの値です。
urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
urn:ietf:params:xml:ns:yang:ietf-netconf-state
urn:ietf:params:xml:ns:yang:ietf-netconf
Note that a different URN prefix string SHOULD be used for modules that are not Standards Track. The string SHOULD be selected according to the guidelines in Section 5.3 of [RFC7950].
標準トラックではないモジュールには、異なる URN プレフィックス文字列を使用する必要があることに注意してください。文字列は、[RFC7950] のセクション 5.3 のガイドラインに従って選択される必要があります (SHOULD)。
The following URIs exemplify what might be used by modules that are not Standards Track. Note that the domain "example.com" SHOULD be used by example modules in I-Ds from the IETF Stream. These URIs are not intended to be dereferenced. They are used for module namespace identification only.
次の URI は、Standards Track ではないモジュールによって使用される可能性があるものの例を示しています。ドメイン「example.com」は、IETF ストリームからの I-D 内のサンプル モジュールによって使用される必要があることに注意してください。これらの URI は逆参照されることを目的としたものではありません。これらはモジュール名前空間の識別のみに使用されます。
Example URIs using URLs per [RFC3986]:
[RFC3986] に準拠した URL を使用した URI の例:
https://example.com/ns/example-interfaces
https://example.com/ns/example-system
Example URIs using tags per [RFC4151]:
[RFC4151] に準拠したタグを使用した URI の例:
tag:example.com,2017:example-interfaces
tag:example.com,2017:example-system
The top-level data organization SHOULD be considered carefully, in advance. Data model designers need to consider how the functionality for a given protocol or protocol family will grow over time.
最上位のデータ構成については、事前に慎重に検討する必要があります。データ モデルの設計者は、特定のプロトコルまたはプロトコル ファミリの機能が時間の経過とともにどのように拡張されるかを考慮する必要があります。
The separation of configuration data and operational state SHOULD be considered carefully. It is sometimes useful to define separate top-level containers for configuration and non-configuration data. For some existing top-level data nodes, configuration data was not in scope, so only one container representing operational state was created. Refer to NMDA [RFC8342] for details.
構成データと動作状態の分離は慎重に検討する必要があります。構成データと非構成データ用に別個のトップレベルのコンテナを定義すると便利な場合があります。一部の既存のトップレベル データ ノードでは、構成データがスコープ内になかったため、動作状態を表すコンテナーが 1 つだけ作成されました。詳細については、NMDA [RFC8342] を参照してください。
The number of top-level data nodes within a module SHOULD be minimized. It is often useful to retrieve related information within a single subtree. If data is too distributed, it becomes difficult to retrieve all at once.
モジュール内のトップレベルのデータノードの数は最小限にすべきです(SHOULD)。多くの場合、単一のサブツリー内の関連情報を取得すると便利です。データが分散しすぎると、一度にすべてを取得することが困難になります。
The names and data organization SHOULD reflect persistent information, such as the name of a protocol. The name of the working group SHOULD NOT be used because this may change over time.
名前とデータ構成は、プロトコルの名前などの永続的な情報を反映する必要があります (SHOULD)。作業グループの名前は時間の経過とともに変わる可能性があるため、使用しないでください。
A mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value.
必須データベース データ定義は、データベースを有効にするためにクライアントが提供する必要があるノードとして定義されます。サーバーは値を提供する必要はありません。
Top-level database data definitions MUST NOT be mandatory. If a mandatory node appears at the top level, it will immediately cause the database to be invalid. This can occur when the server boots or when a module is loaded dynamically at runtime.
最上位のデータベースのデータ定義は必須であってはなりません。必須ノードが最上位に表示されると、データベースは直ちに無効になります。これは、サーバーの起動時、または実行時にモジュールが動的にロードされるときに発生する可能性があります。
Selection of an appropriate data type (i.e., built-in type, existing derived type, or new derived type) is very subjective; therefore, few requirements can be specified on that subject.
適切なデータ型 (つまり、組み込み型、既存の派生型、または新しい派生型) の選択は非常に主観的です。したがって、その主題に関して指定できる要件はほとんどありません。
Data model designers SHOULD use the most appropriate built-in data type for the particular application.
データ モデルの設計者は、特定のアプリケーションに最も適切な組み込みデータ型を使用する必要があります (SHOULD)。
The signed numeric data types (i.e., "int8", "int16", "int32", and "int64") SHOULD NOT be used unless negative values are allowed for the desired semantics.
符号付き数値データ型 (つまり、「int8」、「int16」、「int32」、および「int64」) は、必要なセマンティクスで負の値が許可されない限り、使用すべきではありません(SHOULD NOT)。
If the set of values is fixed and the data type contents are controlled by a single naming authority (e.g., IANA), then an "enumeration" data type SHOULD be used.
値のセットが固定されており、データ型の内容が単一の命名機関 (IANA など) によって制御されている場合、「列挙」データ型を使用する必要があります (SHOULD)。
leaf foo {
type enumeration {
enum one;
enum two;
}
}
If distributed extensibility or hierarchical organization of enumerated values is required, then the "identityref" data type SHOULD be used instead of an "enumeration" or other built-in type.
分散拡張性または列挙値の階層構造が必要な場合は、「列挙」または他の組み込み型の代わりに「identityref」データ型を使用する必要があります(SHOULD)。
identity foo-type {
description "Base for the extensible type";
}
identity one {
base f:foo-type;
}
identity two {
base f:foo-type;
}
leaf foo {
type identityref {
base f:foo-type;
}
}
Note that any module can declare an identity with base "foo-type" that is valid for the "foo" leaf. Identityref values are considered to be qualified names.
どのモジュールも、「foo」リーフに対して有効なベース「foo-type」を使用してアイデンティティを宣言できることに注意してください。Identityref 値は修飾名とみなされます。
For string data types, if a machine-readable pattern can be defined for the desired semantics, then one or more pattern statements SHOULD be present. A single-quoted string SHOULD be used to specify the pattern, since a double-quoted string can modify the content. If the patterns used in a type definition have known limitations such as false negative or false positive matches, then these limitations SHOULD be documented within the typedef or data definition.
文字列データ型の場合、必要なセマンティクスに対して機械可読パターンを定義できる場合、1 つ以上のパターン ステートメントが存在する必要があります (SHOULD)。二重引用符で囲まれた文字列は内容を変更する可能性があるため、パターンの指定には一重引用符で囲まれた文字列を使用する必要があります (SHOULD)。型定義で使用されるパターンに偽陰性一致や偽陽性一致などの既知の制限がある場合、これらの制限を typedef またはデータ定義内に文書化する必要があります (SHOULD)。
The following typedef from [RFC9911] demonstrates the proper use of the "pattern" statement:
[RFC9911] の次の typedef は、「pattern」ステートメントの適切な使用法を示しています。
typedef ipv6-address-no-zone {
type inet:ipv6-address {
pattern '[0-9a-fA-F:\.]*';
}
...
}
For string data types, if the length of the string is required to be bounded in all implementations, then a "length" statement MUST be present.
文字列データ型の場合、すべての実装で文字列の長さを制限する必要がある場合は、「length」ステートメントが存在しなければなりません。
The following typedef from [RFC9911] demonstrates the proper use of the "length" statement:
[RFC9911] の次の typedef は、「length」ステートメントの適切な使用法を示しています。
typedef yang-identifier {
type string {
length "1..max";
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
}
...
}
For numeric data types, if the values allowed by the intended semantics are different than those allowed by the unbounded intrinsic data type (e.g., "int32"), then a range statement SHOULD be present.
数値データ型の場合、意図したセマンティクスで許可される値が、無制限の組み込みデータ型 (例: "int32") で許可される値と異なる場合、range ステートメントが存在する必要があります (SHOULD)。
The following typedef from [RFC9911] demonstrates the proper use of the "range" statement:
[RFC9911] の次の typedef は、「range」ステートメントの適切な使用法を示しています。
typedef dscp {
type uint8 {
range "0..63";
}
...
}
For "enumeration" or "bits" data types, the semantics for each "enum" or "bit" SHOULD be documented. A separate "description" statement (within each "enum" or "bit" statement) SHOULD be present.
「列挙」または「ビット」データ型の場合、各「列挙」または「ビット」のセマンティクスを文書化する必要があります(SHOULD)。個別の「description」ステートメント (各「enum」または「bit」ステートメント内) が存在する必要があります (SHOULD)。
leaf foo {
// INCORRECT
type enumeration {
enum one;
enum two;
}
description
"The foo enum...
one: The first enum
two: The second enum";
}
leaf foo {
// CORRECT
type enumeration {
enum one {
description "The first enum";
}
enum two {
description "The second enum";
}
}
description
"The foo enum... ";
}
The YANG "union" type is evaluated by testing a value against each member type in the union. The first type definition that accepts a value as valid is the member type used. In general, member types SHOULD be ordered from most restrictive to least restrictive types.
YANG の「共用体」型は、共用体の各メンバー型に対して値をテストすることによって評価されます。値を有効なものとして受け入れる最初の型定義は、使用されるメンバー型です。一般に、メンバー型は最も制限の厳しい型から最も制限の少ない型の順に並べる必要があります (SHOULD)。
In the following example, the "enumeration" type will never be matched because the preceding "string" type will match everything.
次の例では、先行する「string」タイプがすべてに一致するため、「enumeration」タイプは一致しません。
Incorrect:
正しくない：
type union {
type string;
type enumeration {
enum up;
enum down;
}
}
Correct:
正しい：
type union {
type enumeration {
enum up;
enum down;
}
type string;
}
It is possible for different member types to match, depending on the input encoding format. In XML, all values are passed as string nodes; but in JSON, there are different value types for numbers, booleans, and strings.
入力エンコード形式に応じて、異なるメンバー型が一致する可能性があります。XML では、すべての値は文字列ノードとして渡されます。ただし、JSON では、数値、ブール値、文字列にはさまざまな値の型があります。
In the following example, a JSON numeric value will always be matched by the "int32" type, but in XML the string value representing a number will be matched by the "string" type. The second version will match the "int32" member type no matter how the input is encoded.
次の例では、JSON 数値は常に「int32」タイプと一致しますが、XML では、数値を表す文字列値は「string」タイプと一致します。2 番目のバージョンは、入力のエンコード方法に関係なく、「int32」メンバーの型と一致します。
Incorrect:
正しくない：
type union {
type string;
type int32;
}
Correct:
正しい：
type union {
type int32;
type string;
}
YANG provides an "empty" data type, which has one value (i.e., present). The default is "not present", which is not actually a value. When used within a list key, only one value can (and must) exist for this key leaf. The type "empty" SHOULD NOT be used for a key leaf since it is pointless.
YANG は、1 つの値 (つまり、存在) を持つ「空」データ型を提供します。デフォルトは「存在しません」ですが、実際には値ではありません。リスト キー内で使用する場合、このキー リーフには 1 つの値のみが存在できます (また、存在する必要があります)。「空」タイプは無意味であるため、キーリーフには使用しないでください。
There is really no difference between a leaf of type "empty" and a leaf-list of type "empty". Both are limited to one instance. The type "empty" SHOULD NOT be used for a leaf-list.
実際には、タイプ「空」のリーフとタイプ「空」のリーフリストの間に違いはありません。どちらも 1 つのインスタンスに限定されます。「空」タイプはリーフリストに使用すべきではありません (SHOULD NOT)。
The advantage of using type "empty" instead of type "boolean" is that the default (not present) does not take up any bytes in a representation. The disadvantage is that the client may not be sure if an empty leaf is missing because it was filtered somehow or not implemented. The client may not have a complete and accurate schema for the data returned by the server and may not be aware of the missing leaf.
「boolean」型の代わりに「empty」型を使用する利点は、デフォルト (存在しない) が表現内でバイトを消費しないことです。欠点は、空のリーフが何らかの理由でフィルタリングされたため、または実装されていないために欠落しているかどうかをクライアントが確信できない可能性があることです。クライアントは、サーバーから返されたデータの完全かつ正確なスキーマを持っていない可能性があり、欠落しているリーフに気づいていない可能性があります。
The YANG "boolean" data type provides two values ("true" and "false"). When used within a list key, two entries can exist for this key leaf. Default values are ignored for key leafs, but a default statement is often used for plain boolean leafs. The advantage of the "boolean" type is that the leaf or leaf-list has a clear representation for both values. The default value is usually not returned unless explicitly requested by the client, so no bytes are used in a typical representation.
YANG の「ブール」データ型は 2 つの値 (「true」と「false」) を提供します。リスト キー内で使用される場合、このキー リーフには 2 つのエントリが存在できます。デフォルト値はキー リーフでは無視されますが、デフォルト ステートメントはプレーン ブール リーフによく使用されます。「ブール」型の利点は、リーフまたはリーフリストが両方の値を明確に表現できることです。通常、クライアントによって明示的に要求されない限り、デフォルト値は返されないため、一般的な表現ではバイトは使用されません。
In general, the "boolean" data type SHOULD be used instead of the "empty" data type, as shown in the example below:
一般に、以下の例に示すように、「空」データ型の代わりに「ブール」データ型を使用する必要があります。
Incorrect:
正しくない：
leaf flag1 {
type empty;
}
Correct:
正しい：
leaf flag2 {
type boolean;
default false;
}
If an appropriate derived type exists in any standard module, such as [RFC9911], then it SHOULD be used instead of defining a new derived type.
[RFC9911] などの標準モジュールに適切な派生型が存在する場合、新しい派生型を定義する代わりにそれを使用する必要があります (SHOULD)。
If an appropriate units identifier can be associated with the desired semantics, then a units statement SHOULD be present.
適切な単位識別子を目的のセマンティクスに関連付けることができる場合は、単位ステートメントが存在する必要があります (SHOULD)。
If an appropriate default value can be associated with the desired semantics, then a default statement SHOULD be present.
適切なデフォルト値を必要なセマンティクスに関連付けることができる場合、デフォルトのステートメントが存在する必要があります (SHOULD)。
If a significant number of derived types are defined, and it is anticipated that these data types will be reused by multiple modules, then these derived types SHOULD be contained in a separate module or submodule to allow easier reuse without unnecessary coupling.
かなりの数の派生型が定義されており、これらのデータ型が複数のモジュールによって再利用されることが予想される場合、不必要な結合なしで簡単に再利用できるように、これらの派生型を別のモジュールまたはサブモジュールに含めるべきです(SHOULD)。
The "description" statement MUST be present.
「説明」ステートメントが存在する必要があります。
If the type definition semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then the "reference" statement MUST be present.
型定義セマンティクスが外部ドキュメント (「import」ステートメントで示される別の YANG モジュール以外) で定義されている場合、「reference」ステートメントが存在しなければなりません (MUST)。
A reusable grouping is a YANG grouping that can be imported by another module and is intended for use by other modules. This is not the same as a grouping that is used within the module in which it is defined, but it happens to be exportable to another module because it is defined at the top level of the YANG module.
再利用可能なグループは、別のモジュールによってインポートでき、他のモジュールで使用することを目的とした YANG グループです。これは、定義されているモジュール内で使用されるグループ化と同じではありませんが、YANG モジュールの最上位で定義されているため、別のモジュールにエクスポート可能です。
The following guidelines apply to reusable groupings, in order to make them as robust as possible:
再利用可能なグループを可能な限り堅牢にするために、次のガイドラインが適用されます。
* Clearly identify the purpose of the grouping in the "description" statement.
* 「説明」ステートメントでグループ化の目的を明確に示します。
* There are five different XPath contexts in YANG (rpc/input, rpc/ output, notification, "config true" data nodes, and all data nodes). Clearly identify which XPath contexts are applicable or excluded for the grouping.
* YANG には 5 つの異なる XPath コンテキスト (rpc/input、rpc/output、notification、「config true」データ ノード、およびすべてのデータ ノード) があります。どの XPath コンテキストがグループ化に適用されるか除外されるかを明確に識別します。
* Do not reference data outside the grouping in any "path", "must", or "when" statements.
* 「path」、「must」、または「when」ステートメントでは、グループ化の外側のデータを参照しないでください。
* Do not include a "default" substatement on a leaf or choice unless the value applies on all possible contexts.
* 値がすべての可能なコンテキストに適用される場合を除き、リーフまたは選択肢に「デフォルト」サブステートメントを含めないでください。
* Do not include a "config" substatement on a data node unless the value applies on all possible contexts.
* 値がすべての可能なコンテキストに適用される場合を除き、データ ノードに「config」サブステートメントを含めないでください。
* Clearly identify any external dependencies in the grouping "description" statement, such as nodes referenced by an absolute path from a "path", "must", or "when" statement.
* 「path」、「must」、または「when」ステートメントからの絶対パスによって参照されるノードなど、グループ化「description」ステートメント内の外部依存関係を明確に識別します。
The "description" statement MUST be present in the following YANG statements:
「description」ステートメントは、次の YANG ステートメントに存在する必要があります。
* anydata
* あらゆるデータ
* anyxml
* 任意のxml
* augment
* 増強
* choice
* 選択
* container
* 容器
* extension
* 拡大
* feature
* 特徴
* grouping
* グループ化
* identity
* 身元
* leaf
* 葉
* leaf-list
* リーフリスト
* list
* リスト
* notification
* 通知
* rpc
* RPC
* typedef
* typedef
If the data definition semantics are defined in an external document, (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
データ定義セマンティクスが外部ドキュメント (「import」ステートメントで示される別の YANG モジュール以外) で定義されている場合、「reference」ステートメントが存在しなければなりません (MUST)。
The "anyxml" construct may be useful to represent an HTML banner containing markup elements, such as "<b>" and "</b>", and MAY be used in such cases. However, this construct SHOULD NOT be used if other YANG data node types can be used instead to represent the desired syntax and semantics.
「anyxml」構造は、「<b>」や「</b>」などのマークアップ要素を含む HTML バナーを表すのに役立つ場合があり、そのような場合に使用できます (MAY)。ただし、必要な構文とセマンティクスを表すために他の YANG データ ノード タイプを代わりに使用できる場合、この構造は使用すべきではありません (SHOULD NOT)。
It has been found that the "anyxml" statement is not implemented consistently across all servers. It is possible that mixed-mode XML will not be supported or that configuration anyxml nodes will not be supported.
「anyxml」ステートメントがすべてのサーバーで一貫して実装されていないことが判明しました。混合モード XML がサポートされないか、構成 anyxml ノードがサポートされない可能性があります。
If there are referential integrity constraints associated with the desired semantics that can be represented with XPath, then one or more "must" statements SHOULD be present.
XPath で表現できる目的のセマンティクスに関連付けられた参照整合性制約がある場合、1 つ以上の「must」ステートメントが存在する必要があります (SHOULD)。
For list and leaf-list data definitions, if the number of possible instances is required to be bounded for all implementations, then the max-elements statements SHOULD be present.
リストおよびリーフリストのデータ定義の場合、すべての実装で可能なインスタンスの数を制限する必要がある場合、max-elements ステートメントが存在する必要があります (SHOULD)。
If any "must" or "when" statements are used within the data definition, then the data definition "description" statement SHOULD describe the purpose of each one.
データ定義内で「must」または「when」ステートメントが使用されている場合、データ定義の「説明」ステートメントでそれぞれの目的を説明する必要があります (SHOULD)。
The "choice" statement is allowed to be directly present within a "case" statement in YANG 1.1. This needs to be considered carefully. Consider simply including the nested "choice" as additional "case" statements within the parent "choice" statement. Note that the "mandatory" and "default" statements within a nested "choice" statement only apply if the "case" containing the nested "choice" statement is first selected.
YANG 1.1 では、「choice」ステートメントを「case」ステートメント内に直接存在させることができます。これは慎重に検討する必要があります。ネストされた「choice」を、親の「choice」ステートメント内に追加の「case」ステートメントとして単純に含めることを検討してください。ネストされた「choice」ステートメント内の「mandatory」ステートメントと「default」ステートメントは、ネストされた「choice」ステートメントを含む「case」が最初に選択された場合にのみ適用されることに注意してください。
If a list defines any key leafs, then these leafs SHOULD be defined in order, as the first child nodes within the list. The key leafs MAY be in a different order in some cases, e.g., they are defined in a grouping, and not inline in the list statement.
リストがキー リーフを定義する場合、これらのリーフはリスト内の最初の子ノードとして順番に定義されるべきです(SHOULD)。キーリーフは場合によっては異なる順序であってもよい(MAY)。たとえば、キーリーフはリストステートメント内でインラインではなくグループ化で定義されている。
A non-presence container is used to organize data into specific subtrees. It is not intended to have semantics within the data model beyond this purpose, although YANG allows it (e.g., a "must" statement within the non-presence container).
非存在コンテナは、データを特定のサブツリーに編成するために使用されます。YANG では許可されていますが、この目的を超えてデータ モデル内にセマンティクスを含めることは意図されていません (たとえば、非存在コンテナ内の「must」ステートメント)。
Example using container wrappers:
コンテナラッパーを使用した例:
container top {
container foos {
list foo { ... }
}
container bars {
list bar { ... }
}
}
Example without container wrappers:
コンテナラッパーを使用しない例:
container top {
list foo { ... }
list bar { ... }
}
Use of non-presence containers to organize data is a subjective matter similar to use of subdirectories in a file system. Although these containers do not have any semantics, they can impact protocol operations for the descendant data nodes within a non-presence container, so use of these containers SHOULD be considered carefully.
データを整理するための非存在コンテナーの使用は、ファイル システムでのサブディレクトリの使用と同様に主観的な問題です。これらのコンテナにはセマンティクスはありませんが、存在しないコンテナ内の子孫データ ノードのプロトコル操作に影響を与える可能性があるため、これらのコンテナの使用は慎重に検討する必要があります。
The NETCONF and RESTCONF protocols do not currently support the ability to delete all list (or leaf-list) entries at once. This deficiency is sometimes avoided by use of a parent container (i.e., deleting the container also removes all child entries).
NETCONF および RESTCONF プロトコルは現在、すべてのリスト (またはリーフリスト) エントリを一度に削除する機能をサポートしていません。この欠陥は、親コンテナを使用することで回避できる場合があります (つまり、コンテナを削除すると、すべての子エントリも削除されます)。
Use of top-level objects needs to be considered carefully:
最上位オブジェクトの使用は慎重に検討する必要があります。
* top-level siblings are not ordered
* 最上位の兄弟は順序付けされていません
* top-level siblings are not static and depend on the modules that are loaded
* 最上位の兄弟は静的ではなく、ロードされるモジュールに依存します。
* for subtree filtering, retrieval of a top-level leaf-list will be treated as a content-match node for all top-level-siblings
* サブツリー フィルタリングの場合、トップレベルのリーフリストの取得は、すべてのトップレベルの兄弟のコンテンツ一致ノードとして扱われます。
* a top-level list with many instances may impact performance
* 多数のインスタンスを含むトップレベルのリストはパフォーマンスに影響を与える可能性があります
If the operation semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
操作セマンティクスが外部ドキュメント (「import」ステートメントで示される別の YANG モジュール以外) で定義されている場合、「reference」ステートメントが存在しなければなりません (MUST)。
If the operation impacts system behavior in some way, it SHOULD be mentioned in the "description" statement.
操作が何らかの形でシステムの動作に影響を与える場合、それを「説明」ステートメントに記載する必要があります (SHOULD)。
If the operation is potentially harmful to system behavior in some way, it MUST be mentioned in the Security Considerations section of the document.
操作が何らかの形でシステムの動作に有害な可能性がある場合は、文書の「セキュリティに関する考慮事項」セクションで言及しなければなりません。
The "description" statement MUST be present.
「説明」ステートメントが存在する必要があります。
If the notification semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
通知セマンティクスが外部ドキュメント (「import」ステートメントで示される別の YANG モジュール以外) で定義されている場合、「reference」ステートメントが存在しなければなりません (MUST)。
If the notification refers to a specific resource instance, then this instance SHOULD be identified in the notification data. This is usually done by including "leafref" leaf nodes with the key leaf values for the resource instance. For example:
通知が特定のリソースインスタンスを参照している場合、このインスタンスは通知データ内で識別されるべきです(SHOULD)。これは通常、リソース インスタンスのキー リーフ値を持つ「leafref」リーフ ノードを含めることによって行われます。例えば：
notification interface-up {
description "Sent when an interface is activated.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}
}
Note that there are no formal YANG statements to identify any data node resources associated with a notification. The "description" statement for the notification SHOULD specify if and how the notification identifies any data node resources associated with the specific event.
通知に関連付けられたデータ ノード リソースを識別するための正式な YANG ステートメントがないことに注意してください。通知の「説明」ステートメントでは、通知が特定のイベントに関連付けられたデータ ノード リソースを識別するかどうか、および識別する方法を指定する必要があります (SHOULD)。
The YANG "feature" statement is used to define a label for a set of optional functionality within a module. The "if-feature" statement is used in the YANG statements associated with a feature. The description-stmt within a feature-stmt MUST specify any interactions with other features.
YANG の「feature」ステートメントは、モジュール内のオプション機能のセットのラベルを定義するために使用されます。「if-feature」ステートメントは、機能に関連付けられた YANG ステートメントで使用されます。feature-stmt 内の description-stmt では、他の機能との対話を指定しなければなりません (MUST)。
The set of YANG features defined in a module should be considered carefully. Very fine granular features increase interoperability complexity and should be avoided. A likely misuse of the feature mechanism is the tagging of individual leafs (e.g., counters) with separate features.
モジュールで定義される YANG 機能のセットは慎重に検討する必要があります。非常に細かい粒度の機能は相互運用性の複雑さを増すため、避けるべきです。機能メカニズムの誤用として考えられるのは、個々のリーフ (カウンターなど) に別個の機能をタグ付けすることです。
If there is a large set of objects associated with a YANG feature, then consider moving those objects to a separate module instead of using a YANG feature. Note that the set of features within a module is easily discovered by the reader, but the set of related modules within the entire YANG library is not as easy to identify. Module names with a common prefix can help readers identify the set of related modules, but this assumes the reader will have discovered and installed all the relevant modules.
YANG 機能に関連付けられたオブジェクトの大きなセットがある場合は、YANG 機能を使用する代わりに、それらのオブジェクトを別のモジュールに移動することを検討してください。モジュール内の一連の機能は読者によって簡単に発見されますが、YANG ライブラリ全体内の関連モジュールのセットを識別するのはそれほど簡単ではないことに注意してください。共通のプレフィックスを持つモジュール名は、読者が関連モジュールのセットを識別するのに役立ちますが、これは読者がすべての関連モジュールを検出してインストールしていることを前提としています。
Another consideration for deciding whether to create a new module or add a YANG feature is the stability of the module in question. It may be desirable to have a stable base module that is not changed frequently. If new functionality is placed in a separate module, then the base module does not need to be republished. If it is designed as a YANG feature, then the module will need to be republished.
新しいモジュールを作成するか YANG 機能を追加するかを決定する際のもう 1 つの考慮事項は、問題のモジュールの安定性です。頻繁に変更されない、安定した基本モジュールを持つことが望ましい場合があります。新しい機能が別のモジュールに配置されている場合、基本モジュールを再公開する必要はありません。YANG 機能として設計されている場合、モジュールを再公開する必要があります。
If one feature requires implementation of another feature, then an "if-feature" statement SHOULD be used in the dependent "feature" statement.
ある機能が別の機能の実装を必要とする場合、「if-feature」ステートメントを依存する「feature」ステートメントで使用する必要があります (SHOULD)。
For example, feature2 requires implementation of feature1:
たとえば、feature2 には feature1 の実装が必要です。
feature feature1 {
description "Some protocol feature";
}
feature feature2 {
if-feature "feature1";
description "Another protocol feature";
}
The "min-elements" and "max-elements" statements can be used to control how many list or leaf-list instances are required for a particular data node. YANG constraint statements SHOULD be used to identify conditions that apply to all implementations of the data model. If platform-specific limitations (e.g., the "max-elements" supported for a particular list) are relevant to operations, then a data model definition statement (e.g., "max-ports" leaf) SHOULD be used to identify the limit.
「min-elements」および「max-elements」ステートメントを使用して、特定のデータ ノードに必要なリストまたはリーフ リスト インスタンスの数を制御できます。YANG 制約ステートメントは、データ モデルのすべての実装に適用される条件を識別するために使用する必要があります (SHOULD)。プラットフォーム固有の制限 (例: 特定のリストでサポートされる「最大要素」) が操作に関連する場合、制限を識別するためにデータ モデル定義ステートメント (例: 「最大ポート」リーフ) を使用する必要があります (SHOULD)。
"must" and "when" YANG statements are used to provide cross-object referential tests. They have very different behavior. The "when" statement causes data node instances to be silently deleted as soon as the condition becomes false. A false "when" statement is not considered to be an error.
「must」および「when」の YANG ステートメントは、オブジェクト間の参照テストを提供するために使用されます。彼らは非常に異なる行動をします。「when」ステートメントにより、条件が false になるとすぐにデータ ノード インスタンスがサイレントに削除されます。偽の「when」ステートメントはエラーとみなされません。
The "when" statement SHOULD be used together with "augment" or "uses" statements to achieve conditional model composition. The condition SHOULD be based on static properties of the augmented entry (e.g., list key leafs).
条件付きモデルの構成を実現するには、「when」ステートメントを「augment」または「uses」ステートメントと一緒に使用する必要があります (SHOULD)。条件は、拡張されたエントリの静的プロパティ（リストキーリーフなど）に基づくべきです（SHOULD）。
The "must" statement causes a datastore validation error if the condition is false. This statement SHOULD be used for enforcing parameter value restrictions that involve more than one data node (e.g., end-time parameter must be after the start-time parameter).
「must」ステートメントは、条件が false の場合にデータストア検証エラーを引き起こします。このステートメントは、複数のデータノードに関係するパラメータ値の制限を強制するために使用されるべきです(例えば、終了時間パラメータは開始時間パラメータの後でなければなりません)。
The YANG "augment" statement is used to define a set of data definition statements that will be added as child nodes of a target data node. The module namespace for these data nodes will be the augmenting module, not the augmented module.
YANG の「augment」ステートメントは、ターゲット データ ノードの子ノードとして追加される一連のデータ定義ステートメントを定義するために使用されます。これらのデータ ノードのモジュール名前空間は、拡張モジュールではなく、拡張モジュールになります。
A top-level "augment" statement SHOULD NOT be used if the target data node is in the same module or submodule as the evaluated "augment" statement. The data definition statements SHOULD be added inline instead.
ターゲットデータノードが評価された「augment」ステートメントと同じモジュールまたはサブモジュール内にある場合、トップレベルの「augment」ステートメントは使用すべきではありません（SHOULD NOT）。データ定義ステートメントは、代わりにインラインで追加する必要があります (SHOULD)。
The "augment" statement is often used together with the "when" statement and/or "if-feature" statement to make the augmentation conditional on some portion of the data model.
「augment」ステートメントは、データ モデルの一部に条件付きの拡張を行うために、「when」ステートメントや「if-feature」ステートメントと一緒に使用されることがよくあります。
The following example from [RFC8343] shows how a conditional container called "ethernet" is added to the "interface" list only for entries of the type "ethernetCsmacd".
[RFC8343] の次の例は、「ethernet」と呼ばれる条件付きコンテナが、「ethernetCsmacd」タイプのエントリに対してのみ「interface」リストに追加される方法を示しています。
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";
container ethernet {
leaf duplex {
...
}
}
}
YANG has very specific rules about how configuration data can be updated in new releases of a module. These rules allow an "old client" to continue interoperating with a "new server".
YANG には、モジュールの新しいリリースで構成データを更新する方法について、非常に具体的なルールがあります。これらのルールにより、「古いクライアント」が「新しいサーバー」と相互運用し続けることができます。
If data nodes are added to an existing entry, the old client MUST NOT be required to provide any mandatory parameters that were not in the original module definition.
データノードが既存のエントリに追加される場合、古いクライアントは、元のモジュール定義にない必須パラメータを提供することを要求してはなりません (MUST NOT)。
It is possible to add conditional "augment" statements such that the old client would not know about the new condition and would not specify the new condition. The conditional "augment" statement can contain mandatory objects only if the condition is false, unless explicitly requested by the client.
古いクライアントが新しい条件を認識せず、新しい条件を指定しないように、条件付きの「拡張」ステートメントを追加することができます。条件付きの「augment」ステートメントには、クライアントによって明示的に要求されない限り、条件が false の場合にのみ必須オブジェクトを含めることができます。
Only a conditional "augment" statement that uses the "when" statement form of a condition can be used in this manner. The YANG features enabled on the server cannot be controlled by the client in any way, so it is not safe to add mandatory augmenting data nodes based on the "if-feature" statement.
この方法で使用できるのは、条件の「when」ステートメント形式を使用する条件付き「augment」ステートメントのみです。サーバー上で有効になっている YANG 機能は、クライアントではいかなる方法でも制御できないため、「if-feature」ステートメントに基づいて必須の拡張データ ノードを追加するのは安全ではありません。
The XPath "when" statement condition MUST NOT reference data outside of the target data node because the client does not have any control over this external data.
XPath の「when」ステートメントの条件は、ターゲット データ ノードの外部のデータを参照してはなりません (MUST NOT)。これは、クライアントがこの外部データを制御できないためです。
In the following sample, it is okay to augment the "interface" entry with "mandatory-leaf" because the augmentation depends on support for "some-new-iftype". The old client does not know about this type, so it would never select this type; therefore, it would not add a mandatory data node.
次のサンプルでは、「interface」エントリを「mandatory-leaf」で拡張しても問題ありません。これは、拡張が「some-new-iftype」のサポートに依存しているためです。古いクライアントはこのタイプを知らないため、このタイプを選択することはありません。したがって、必須のデータ ノードは追加されません。
module example-module {
yang-version 1.1;
namespace "tag:example.com,2017:example-module";
prefix mymod;
import iana-if-type { prefix iana; }
import ietf-interfaces { prefix if; }
identity some-new-iftype {
base iana:iana-interface-type;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'";
leaf mandatory-leaf {
type string;
mandatory true;
}
}
}
Note that this practice is safe only for creating data resources. It is not safe for replacing or modifying resources if the client does not know about the new condition. The YANG data model MUST be packaged in a way that requires the client to be aware of the mandatory data nodes if it is aware of the condition for this data. In the example above, the "some-new-iftype" identity is defined in the same module as the "mandatory-leaf" data definition statement.
この方法は、データ リソースを作成する場合にのみ安全であることに注意してください。クライアントが新しい状態を知らない場合、リソースを置き換えたり変更したりするのは安全ではありません。YANG データ モデルは、クライアントがこのデータの条件を認識している場合、必須のデータ ノードを認識することを要求する方法でパッケージ化されなければなりません (MUST)。上の例では、「some-new-iftype」ID は「mandatory-leaf」データ定義ステートメントと同じモジュールで定義されています。
This practice is not safe for identities defined in a common module such as "iana-if-type" because the client is not required to know about "my-module" just because it knows about the "iana-if-type" module.
この方法は、「iana-if-type」などの共通モジュールで定義された ID に対しては安全ではありません。クライアントは、「iana-if-type」モジュールについて知っているからといって、「my-module」について知る必要はないからです。
Per Section 7.20.3 of [RFC7950], the YANG "deviation" statement is not allowed to appear in IETF YANG modules, but it can be useful for documenting server capabilities. Deviation statements are not reusable and typically not shared across all platforms.
[RFC7950] のセクション 7.20.3 に従って、YANG の「偏差」ステートメントを IETF YANG モジュールに使用することは許可されていませんが、サーバーの機能を文書化するのに役立ちます。逸脱ステートメントは再利用できず、通常、すべてのプラットフォームで共有されるわけではありません。
There are several reasons that deviations might be needed in an implementation, e.g., an object cannot be supported on all platforms, or feature delivery is done in multiple development phases. Deviation statements can also be used to add annotations to a module, which does not affect the conformance requirements for the module.
実装で逸脱が必要になる理由はいくつかあります。たとえば、オブジェクトがすべてのプラットフォームでサポートされるわけではない、機能の提供が複数の開発フェーズで行われるなどです。逸脱ステートメントを使用してモジュールに注釈を追加することもできますが、これはモジュールの適合要件には影響しません。
It is suggested that deviation statements be defined in separate modules from regular YANG definitions. This allows the deviations to be platform specific and/or temporary.
逸脱ステートメントは、通常の YANG 定義とは別のモジュールで定義することをお勧めします。これにより、逸脱をプラットフォーム固有および/または一時的なものにすることができます。
The order that deviation statements are evaluated can affect the result. Therefore, multiple deviation statements in the same module, for the same target object, SHOULD NOT be used.
偏差ステートメントが評価される順序は、結果に影響を与える可能性があります。したがって、同じモジュール内で、同じターゲットオブジェクトに対して複数の偏差ステートメントを使用すべきではありません(SHOULD NOT)。
The "max-elements" statement is intended to describe an architectural limit to the number of list entries. It is not intended to describe platform limitations. It is better to use a "deviation" statement for the platforms that have a hard resource limit.
「max-elements」ステートメントは、リスト エントリの数に対するアーキテクチャ上の制限を記述することを目的としています。プラットフォームの制限について説明することを目的としたものではありません。ハードリソース制限があるプラットフォームには「偏差」ステートメントを使用することをお勧めします。
Example documenting platform resource limits:
プラットフォームのリソース制限を文書化する例:
Wrong: (max-elements in the list itself)
間違い: (リスト自体の最大要素数)
container backups {
list backup {
...
max-elements 10;
...
}
}
Correct: (max-elements in a deviation)
正解: (偏差の最大要素)
deviation /bk:backups/bk:backup {
deviate add {
max-elements 10;
}
}
The YANG "extension" statement is used to specify external definitions. This appears in the YANG syntax as an "unknown-statement". Usage of "extension" statements in a published module needs to be considered carefully.
YANG「拡張」ステートメントは、外部定義を指定するために使用されます。これは、YANG 構文では「unknown-statement」として表示されます。公開されたモジュールでの「拡張」ステートメントの使用は慎重に検討する必要があります。
The following guidelines apply to the usage of YANG extensions:
YANG 拡張機能の使用には、次のガイドラインが適用されます。
* The semantics of the extension MUST NOT contradict any YANG statements. Extensions can add semantics not covered by the normal YANG statements.
* 拡張機能のセマンティクスは、YANG ステートメントと矛盾してはなりません (MUST NOT)。拡張機能では、通常の YANG ステートメントではカバーされていないセマンティクスを追加できます。
* The module containing the "extension" statement MUST clearly identify the conformance requirements for the extension. It should be clear whether all implementations of the YANG module containing the extension need to also implement the extension. If not, identify what conditions apply that would require implementation of the extension.
* 「拡張」ステートメントを含むモジュールは、拡張の適合要件を明確に識別しなければなりません。拡張機能を含む YANG モジュールのすべての実装でも拡張機能を実装する必要があるかどうかは明らかです。そうでない場合は、拡張機能の実装が必要となるどのような条件が適用されるかを特定します。
* The extension MUST clearly identify where it can be used within other YANG statements.
* 拡張機能は、他の YANG ステートメント内で使用できる場所を明確に識別する必要があります。
* The extension MUST clearly identify if YANG statements or other extensions are allowed or required within the extension as substatements.
* 拡張機能は、YANG ステートメントまたはその他の拡張機能が拡張機能内でサブステートメントとして許可されるか、または必須であるかを明確に識別しなければなりません (MUST)。
Data can be correlated in various ways, using common data types, common data naming, and common data organization. There are several ways to extend the functionality of a module, based on the degree of coupling between the old and new functionality:
データは、共通のデータ型、共通のデータ命名、共通のデータ構成を使用して、さまざまな方法で関連付けることができます。新旧の機能間の結合度に基づいて、モジュールの機能を拡張するにはいくつかの方法があります。
inline:
列をなして：
update the module with new protocol-accessible objects. The naming and data organization of the original objects is used. The new objects are in the original module namespace.
新しいプロトコルでアクセス可能なオブジェクトでモジュールを更新します。元のオブジェクトの名前とデータ構成が使用されます。新しいオブジェクトは元のモジュール名前空間にあります。
augment:
増強：
create a new module with new protocol-accessible objects that augment the original data structure. The naming and data organization of the original objects is used. The new objects are in the new module namespace.
元のデータ構造を拡張する新しいプロトコルでアクセス可能なオブジェクトを含む新しいモジュールを作成します。元のオブジェクトの名前とデータ構成が使用されます。新しいオブジェクトは新しいモジュール名前空間にあります。
mirror:
鏡：
create new objects in a new module or the original module, except use a new naming scheme and data location. The naming can be coupled in different ways. Tight coupling is achieved with a "leafref" data type, with the "require-instance" substatement set to "true". This method SHOULD be used.
新しい命名スキームとデータの場所を使用する場合を除き、新しいモジュールまたは元のモジュールに新しいオブジェクトを作成します。命名はさまざまな方法で組み合わせることができます。密結合は、「require-instance」サブステートメントを「true」に設定した「leafref」データ型で実現されます。この方法を使用する必要があります。
If the new data instances are not limited to the values in use in the original data structure, then the "require-instance" substatement MUST be set to "false". Loose coupling is achieved by using key leafs with the same data type as the original data structure. This has the same semantics as setting the "require-instance" substatement to "false".
新しいデータ インスタンスが元のデータ構造で使用されている値に制限されない場合は、「require-instance」サブステートメントを「false」に設定しなければなりません。疎結合は、元のデータ構造と同じデータ型のキー リーフを使用することによって実現されます。これは、「require-instance」サブステートメントを「false」に設定するのと同じセマンティクスを持ちます。
The relationship between configuration and operational state has been clarified in NMDA [RFC8342].
設定と動作状態の関係は、NMDA [RFC8342] で明確にされています。
Sometimes it is not practical to augment a data structure. For example, the correlated data could have different keys or contain mandatory nodes.
データ構造を拡張することが現実的でない場合もあります。たとえば、相関データには異なるキーが含まれたり、必須のノードが含まれたりする可能性があります。
The following example shows the use of the "leafref" data type for data correlation purposes:
次の例は、データ相関を目的とした「leafref」データ型の使用を示しています。
Not preferred:
好ましくない:
list foo {
key name;
leaf name {
type string;
}
...
}
list foo-addon {
key name;
config false;
leaf name {
type string;
}
...
}
Preferred:
好ましい:
list foo {
key name;
leaf name {
type string;
}
...
}
list foo-addon {
key name;
config false;
leaf name {
type leafref {
path "/foo/name";
require-instance false;
}
}
leaf addon {
type string;
mandatory true;
}
}
The modeling of operational state with YANG has been refined over time. At first, only data that has a "config" statement value of "false" was considered to be operational state. This data was not considered to be part of any datastore, which made the YANG XPath definition much more complicated.
YANG による動作状態のモデリングは、時間の経過とともに洗練されてきました。当初は、「config」ステートメントの値が「false」であるデータのみが動作状態とみなされていました。このデータはどのデータストアの一部ともみなされなかったため、YANG XPath 定義はさらに複雑になりました。
Operational state is now modeled using YANG according to the NMDA [RFC8342] and conceptually contained in the operational state datastore, which also includes the operational values of configuration data. There is no longer any need to duplicate data structures to provide separate configuration and operational state sections.
動作状態は現在、NMDA [RFC8342] に従って YANG を使用してモデル化されており、概念的には動作状態データストアに含まれており、構成データの動作値も含まれています。個別の構成セクションと動作状態セクションを提供するためにデータ構造を複製する必要はなくなりました。
This section describes some data modeling issues related to operational state and guidelines for transitioning YANG data model design to be NMDA compatible.
このセクションでは、動作状態に関連するデータ モデリングの問題と、YANG データ モデル設計を NMDA 互換に移行するためのガイドラインについて説明します。
If possible, operational state SHOULD be combined with its associated configuration data. This prevents duplication of key leafs and ancestor nodes. It also prevents race conditions for retrieval of dynamic entries and allows configuration and operational state to be retrieved together with minimal message overhead.
可能であれば、動作状態を関連する構成データと組み合わせる必要があります (SHOULD)。これにより、キー リーフと祖先ノードの重複が防止されます。また、動的エントリの取得における競合状態を防止し、最小限のメッセージ オーバーヘッドで構成と動作状態を取得できるようにします。
container foo {
...
// contains "config true" and "config false" nodes that have
// no corresponding "config true" object (e.g., counters)
}
If possible, the same data type SHOULD be used to represent the configured value and the operational value, for a given leaf or leaf-list object.
可能であれば、特定のリーフまたはリーフ リスト オブジェクトの設定値と運用値を表すために同じデータ型を使用する必要があります (SHOULD)。
Sometimes the configured value set is different than the operational value set for that object, for example, the "admin-status" and "oper-status" leafs in [RFC8343]. In this case, a separate object MAY be used to represent the configured and operational values.
場合によっては、設定された値セットがそのオブジェクトの動作値セットと異なることがあります。たとえば、[RFC8343] の「admin-status」および「oper-status」リーフです。この場合、設定値と動作値を表すために別のオブジェクトを使用してもよい(MAY)。
Sometimes the list keys are not identical for configuration data and the corresponding operational state. In this case, separate lists MAY be used to represent the configured and operational values.
場合によっては、リスト キーが構成データおよび対応する動作状態と同一ではないことがあります。この場合、設定値と動作値を表すために別個のリストを使用してもよい(MAY)。
If it is not possible to combine configuration and operational state, then the keys used to represent list entries SHOULD be the same type. The "leafref" data type SHOULD be used in operational state for key leafs that have corresponding configuration instances. The "require-instance" statement MAY be set to "false" (in YANG 1.1 modules only) to indicate instances are allowed in the operational state that do not exist in the associated configuration data.
構成と動作状態を組み合わせることができない場合、リストのエントリを表すために使用されるキーは同じタイプである必要があります (SHOULD)。「leafref」データ型は、対応する構成インスタンスを持つキーリーフの動作状態で使用されるべきです(SHOULD)。「require-instance」ステートメントは、関連する構成データに存在しないインスタンスが動作状態で許可されていることを示すために、「false」(YANG 1.1 モジュールのみ) に設定してもよい(MAY)。
The need to replicate objects or define different operational state objects depends on the data model. It is not possible to define one approach that will be optimal for all data models.
オブジェクトを複製する必要性、またはさまざまな動作状態オブジェクトを定義する必要性は、データ モデルによって異なります。すべてのデータ モデルに最適な 1 つのアプローチを定義することは不可能です。
Designers SHOULD describe and justify any NMDA exceptions in detail, such as the use of separate subtrees and/or separate leafs. The "description" statements for both the configuration and the operational state SHOULD be used for this purpose.
設計者は、個別のサブツリーや個別のリーフの使用など、NMDA 例外を詳細に説明し、正当化する必要があります。この目的には、構成と動作状態の両方の「説明」ステートメントを使用する必要があります (SHOULD)。
YANG modules SHOULD be designed with the assumption that they will be used on servers supporting the operational state datastore. With this in mind, YANG modules SHOULD define "config false" nodes wherever they make sense to the data model. "Config false" nodes SHOULD NOT be defined to provide the operational value for configuration nodes, except when the value space of a configured and operational value may differ, in which case a distinct "config false" node SHOULD be defined to hold the operational value for the configured node.
YANG モジュールは、動作状態データストアをサポートするサーバーで使用されることを想定して設計されるべきです。これを念頭に置いて、YANG モジュールは、データ モデルにとって意味のある場合は常に「config false」ノードを定義する必要があります (SHOULD)。「Config false」ノードは、構成ノードの動作値を提供するために定義すべきではありません（SHOULD NOT）。ただし、構成された値と動作値の値空間が異なる場合を除き、構成されたノードの動作値を保持するために別個の「config false」ノードを定義すべきです（SHOULD）。
The following guidelines are meant to help modelers develop YANG modules that will maximize the utility of the module with both current and new implementations.
次のガイドラインは、モデラーが現在と新しい実装の両方でモジュールの有用性を最大化する YANG モジュールを開発するのに役立つことを目的としています。
New modules and modules that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA compatible, as described in Section 4.23.1. This transition MAY be deferred if the module does not contain any configuration datastore objects.
新しいモジュールおよび構成情報の動作状態に関係のないモジュールは、セクション 4.23.1 で説明されているように、すぐに NMDA 互換になるように構造化する必要があります (SHOULD)。モジュールに構成データストア オブジェクトが含まれていない場合、この移行は延期されてもよい(MAY)。
The remaining are options that MAY be followed during the time that NMDA mechanisms are being defined.
残りは、NMDA メカニズムの定義中に従うことができるオプションです。
(a) Modules that require immediate support for the NMDA features SHOULD be structured for NMDA. A temporary non-NMDA version of this type of module MAY exist, as either an existing module or a module created by hand or with suitable tools that mirror the current modeling strategies. Both the NMDA and the non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in a non-normative appendix. The use of the non-NMDA module will allow temporary bridging of the time period until NMDA implementations are available.
(a) NMDA 機能の即時サポートを必要とするモジュールは、NMDA 用に構造化する必要があります (SHOULD)。このタイプのモジュールの一時的な非 NMDA バージョンは、既存のモジュール、または現在のモデリング戦略を反映する手動または適切なツールを使用して作成されたモジュールとして存在してもよい(MAY)。NMDA モジュールと非 NMDA モジュールは両方とも、NMDA モジュールを文書本体に、非 NMDA モジュールを非規範的な付録として、同じ文書で公開する必要があります (SHOULD)。非 NMDA モジュールを使用すると、NMDA 実装が利用可能になるまでの期間を一時的に埋めることができます。
(b) For published modules, the module should be republished with an NMDA-compatible structure, deprecating non-NMDA constructs. For example, the "ietf-interfaces" module in [RFC7223] has been restructured as an NMDA-compatible module in [RFC8343] (which obsoletes [RFC7223]). The "/interfaces-state" hierarchy has been marked with "status deprecated". Modules that mark their "/foo-state" hierarchy with "status deprecated" will allow NMDA-capable implementations to avoid the cost of duplicating the state nodes, while enabling non-NMDA-capable implementations to utilize them for access to the operational values.
(b) 公開されたモジュールの場合、モジュールは NMDA 互換の構造で再公開され、非 NMDA 構造は非推奨になります。たとえば、[RFC7223] の「ietf-interfaces」モジュールは、[RFC8343] の NMDA 互換モジュールとして再構築されました ([RFC7223] は廃止されます)。「/interfaces-state」階層には「ステータスが非推奨」とマークされています。「/foo-state」階層を「ステータス非推奨」とマークするモジュールにより、NMDA 対応実装は状態ノードを複製するコストを回避できる一方、NMDA 非対応実装は操作値へのアクセスに状態ノードを利用できるようになります。
(c) For modules that augment modules that have not been structured with the NMDA, the modeler will have to consider the structure of the base module and the guidelines listed above. Where possible, such modules should move to new revisions of the base module that are NMDA compatible. When that is not possible, augmenting "state" containers SHOULD be avoided, with the expectation that the base module will be re-released with the state containers marked as "deprecated". It is RECOMMENDED to augment only the "/foo" hierarchy of the base module. Where this recommendation cannot be followed, any new "state" elements SHOULD be included in their own module.
(c) NMDA で構造化されていないモジュールを拡張するモジュールの場合、モデラーは基本モジュールの構造と上記のガイドラインを考慮する必要があります。可能であれば、そのようなモジュールは、NMDA 互換性のあるベース モジュールの新しいリビジョンに移行する必要があります。それが不可能な場合は、基本モジュールが「非推奨」としてマークされた状態コンテナとともに再リリースされることを期待して、「状態」コンテナの拡張は避けるべきです(SHOULD)。基本モジュールの「/foo」階層のみを拡張することが推奨されます。この推奨事項に従うことができない場合は、新しい「状態」要素を独自のモジュールに含めるべきです(SHOULD)。
A temporary non-NMDA module allows a non-NMDA-aware client to access operational state from an NMDA-compliant server. It contains the top-level "config false" data nodes that would have been defined in a legacy YANG module (before NMDA).
一時的な非 NMDA モジュールを使用すると、NMDA 非対応クライアントが NMDA 準拠サーバーから動作状態にアクセスできるようになります。これには、レガシー YANG モジュール (NMDA より前) で定義されていたトップレベルの「config false」データ ノードが含まれています。
A server that needs to support both NMDA and non-NMDA clients can advertise both the new NMDA module and the temporary non-NMDA module. A non-NMDA client can use separate "foo" and "foo-state" subtrees, except the "foo-state" subtree is located in a different (temporary) module. The NMDA module can be used by a non-NMDA client to access the conventional configuration datastores and the deprecated <get> operation to access nested "config false" data nodes.
NMDA クライアントと非 NMDA クライアントの両方をサポートする必要があるサーバーは、新しい NMDA モジュールと一時的な非 NMDA モジュールの両方をアドバタイズできます。非 NMDA クライアントは、「foo-state」サブツリーが別の (一時的な) モジュールに配置されている場合を除き、個別の「foo」および「foo-state」サブツリーを使用できます。NMDA モジュールを非 NMDA クライアントが使用すると、従来の構成データストアにアクセスしたり、非推奨の <get> 操作を使用してネストされた「config false」データ ノードにアクセスしたりできます。
To create the temporary non-NMDA module from an NMDA module, the following steps can be taken:
NMDA モジュールから一時的な非 NMDA モジュールを作成するには、次の手順を実行します。
* Change the module name by appending "-state" to the original module name.
* 元のモジュール名に「-state」を追加してモジュール名を変更します。
* Change the namespace by appending "-state" to the original namespace value.
* 元の名前空間値に「-state」を追加して、名前空間を変更します。
* Change the prefix by appending "-s" to the original prefix value.
* 元のプレフィックス値に「-s」を追加してプレフィックスを変更します。
* Add an import to the original module (e.g., for typedef definitions).
* 元のモジュールにインポートを追加します (typedef 定義など)。
* Retain or create only the top-level nodes that have a "config" statement value "false". These subtrees represent "config false" data nodes that were combined into the configuration subtree; therefore, they are not available to non-NMDA-aware clients. Set the "status" statement to "deprecated" for each new node.
* 「config」ステートメントの値が「false」である最上位ノードのみを保持または作成します。これらのサブツリーは、構成サブツリーに結合された「config false」データ ノードを表します。したがって、NMDA を認識していないクライアントは使用できません。新しいノードごとに「status」ステートメントを「非推奨」に設定します。
* The module description SHOULD clearly identify the module as a temporary non-NMDA module.
* モジュールの説明では、モジュールが一時的な非 NMDA モジュールであることを明確に識別する必要があります (SHOULD)。
Create an NMDA-compliant module, using combined configuration and state subtrees, whenever possible.
可能な限り、構成と状態のサブツリーを組み合わせて使用して、NMDA 準拠のモジュールを作成します。
module example-foo {
namespace "urn:example:params:xml:ns:yang:example-foo";
prefix "foo";
container foo {
// configuration data child nodes
// operational value in operational state datastore only
// may contain "config false" nodes as needed
}
}
Do not remove non-compliant objects from existing modules. Instead, change the status to "deprecated". At some point, usually after 1 year, the status MAY be changed to "obsolete".
既存のモジュールから非準拠オブジェクトを削除しないでください。代わりに、ステータスを「非推奨」に変更します。ある時点 (通常は 1 年後) で、ステータスが「廃止」に変更される場合があります (MAY)。
Old Module:
古いモジュール:
module example-foo {
namespace "urn:example:params:xml:ns:yang:example-foo";
prefix "foo";
container foo {
// configuration data child nodes
}
container foo-state {
config false;
// operational state child nodes
}
}
Converted NMDA Module:
変換された NMDA モジュール:
module example-foo {
namespace "urn:example:params:xml:ns:yang:example-foo";
prefix "foo";
container foo {
// configuration data child nodes
// operational value in operational state datastore only
// may contain "config false" nodes as needed
// will contain any data nodes from old foo-state
}
// keep original foo-state but change status to deprecated
container foo-state {
config false;
status deprecated;
// operational state child nodes
}
}
Create a new module that contains the top-level operational state data nodes that would have been available before they were combined with configuration data nodes (to be NMDA compliant).
(NMDA に準拠するために) 構成データ ノードと結合される前に使用可能だったトップレベルの動作状態データ ノードを含む新しいモジュールを作成します。
module example-foo-state {
namespace "urn:example:params:xml:ns:yang:example-foo-state";
prefix "foo-s";
// import new or converted module; not used in this example
import example-foo { prefix foo; }
container foo-state {
config false;
status deprecated;
// operational state child nodes
}
}
It is generally likely that certain YANG statements require more runtime resources than other statements. Although there are no performance requirements for YANG validation, the following information MAY be considered when designing YANG data models:
一般に、特定の YANG ステートメントは、他のステートメントよりも多くのランタイム リソースを必要とする可能性があります。YANG 検証にはパフォーマンス要件はありませんが、YANG データ モデルを設計する際には次の情報を考慮することができます。
* Lists are generally more expensive than containers
* 一般にリストはコンテナよりも高価です
* "when" statement evaluation is generally more expensive than "if-feature" or "choice" statements
* 一般に、「when」ステートメントの評価は、「if-feature」または「choice」ステートメントよりも高価です。
* "must" statements are generally more expensive than "min-elements", "max-elements", "mandatory", or "unique" statements
* 一般に、「must」ステートメントは、「min-elements」、「max-elements」、「mandatory」、または「unique」ステートメントよりも高価です。
* "identityref" leafs are generally more expensive than "enumeration" leafs
* 「identityref」リーフは一般に「enumeration」リーフよりも高価です
* "leafref" and "instance-identifier" types with "require-instance" set to "true" are generally more expensive than if "require-instance" is set to "false"
* 「require-instance」が「true」に設定されている「leafref」および「instance-identifier」タイプは、一般に、「require-instance」が「false」に設定されている場合よりも高価になります。
Only the modules imported by a particular module can be assumed to be present in an implementation. An open system MAY include any combination of YANG modules.
特定のモジュールによってインポートされたモジュールのみが実装内に存在すると想定できます。オープン システムには、YANG モジュールの任意の組み合わせを含めることができます (MAY)。
The set of guidelines for YANG 1.1 will grow as operational experience is gained with the new language features. This section contains an initial set of guidelines for YANG 1.1 language features.
YANG 1.1 の一連のガイドラインは、新しい言語機能の運用経験が増えるにつれて拡張されます。このセクションには、YANG 1.1 言語機能の初期のガイドラインが含まれています。
Standard modules SHOULD NOT import multiple revisions of the same module into a module. This MAY be done if independent definitions (e.g., "enumeration" typedefs) from specific revisions are needed in the importing module.
標準モジュールは、同じモジュールの複数のリビジョンを 1 つのモジュールにインポートしないでください。これは、インポートするモジュールで特定のリビジョンからの独立した定義 (例: "列挙型" typedef) が必要な場合に行われてもよい(MAY)。
The YANG 1.1 feature logic is much more expressive than YANG 1.0. A "description" statement SHOULD describe the "if-feature" logic in text, to help readers understand the module.
YANG 1.1 の機能ロジックは、YANG 1.0 よりもはるかに表現力豊かです。「説明」ステートメントは、読者がモジュールを理解できるように、「if-feature」ロジックをテキストで説明する必要があります (SHOULD)。
YANG features SHOULD be used instead of the "when" statement, if possible. Features are advertised by the server, and objects conditional by the "if-feature" statement are conceptually grouped together. There is no such commonality supported for "when" statements.
可能であれば、「when」ステートメントの代わりに YANG 機能を使用する必要があります (SHOULD)。機能はサーバーによってアドバタイズされ、「if-feature」ステートメントによって条件付けされたオブジェクトは概念的にグループ化されます。「when」ステートメントではそのような共通性はサポートされていません。
Features generally require less server implementation complexity and runtime resources than objects that use "when" statements. Features are generally static (i.e., set when a module is loaded and not changed at runtime). However, every client edit might cause a "when" statement result to change.
この機能は通常、「when」ステートメントを使用するオブジェクトよりもサーバー実装の複雑さとランタイム リソースを必要としません。機能は一般に静的です (つまり、モジュールのロード時に設定され、実行時に変更されません)。ただし、クライアントが編集するたびに、「when」ステートメントの結果が変更される可能性があります。
The "anyxml" statement MUST NOT be used to represent a conceptual subtree of YANG data nodes. The "anydata" statement MUST be used for this purpose.
「anyxml」ステートメントは、YANG データ ノードの概念的なサブツリーを表すために使用してはなりません。この目的には「anydata」ステートメントを使用する必要があります。
The use of "action" statements or "rpc" statements is a subjective design decision. RPC operations are not associated with any particular data node. Actions are associated with a specific data node definition. An "action" statement SHOULD be used if the protocol operation is specific to a subset of all data nodes instead of all possible data nodes.
「action」ステートメントまたは「rpc」ステートメントの使用は、主観的な設計上の決定です。RPC 操作は特定のデータ ノードに関連付けられません。アクションは、特定のデータ ノード定義に関連付けられます。プロトコル操作が、考えられるすべてのデータ ノードではなく、すべてのデータ ノードのサブセットに固有である場合、「アクション」ステートメントを使用する必要があります (SHOULD)。
The same action name MAY be used in different definitions within different data node. For example, a "reset" action defined with a data node definition for an interface might have different parameters than for a power supply or a VLAN. The same action name SHOULD be used to represent similar semantics.
同じアクション名が、異なるデータ ノード内の異なる定義で使用されてもよい(MAY)。たとえば、インターフェイスのデータ ノード定義で定義された「リセット」アクションには、電源や VLAN とは異なるパラメータが含まれる場合があります。同様のセマンティクスを表すには、同じアクション名を使用する必要があります (SHOULD)。
The NETCONF Access Control Model (NACM) [RFC8341] does not support parameter-based access control for RPC operations. The user is given permission (or not) to invoke the RPC operation with any parameters. For example, if each client is only allowed to reset their own interface, then NACM cannot be used.
NETCONF アクセス制御モデル (NACM) [RFC8341] は、RPC 操作のパラメーターベースのアクセス制御をサポートしていません。ユーザーには、任意のパラメーターを使用して RPC 操作を呼び出す許可が与えられます (または与えられません)。たとえば、各クライアントが自分のインターフェイスのリセットのみを許可されている場合、NACM は使用できません。
For example, NACM cannot enforce access control based on the value of the "interface" parameter, only the "reset" operation itself:
たとえば、NACM は「interface」パラメータの値に基づいてアクセス制御を強制することはできず、「reset」操作自体のみを強制します。
rpc reset {
input {
leaf interface {
type if:interface-ref;
mandatory true;
description "The interface to reset.";
}
}
}
However, NACM can enforce access control for individual interface instances, using a "reset" action. If the user does not have read access to the specific "interface" instance, then it cannot invoke the "reset" action for that interface instance:
ただし、NACM は、「リセット」アクションを使用して、個々のインターフェイス インスタンスのアクセス制御を強制できます。ユーザーが特定の「インターフェイス」インスタンスへの読み取りアクセス権を持っていない場合、そのインターフェイス インスタンスの「リセット」アクションを呼び出すことはできません。
container interfaces {
list interface {
...
action reset { }
}
}
YANG modules can change over time. Typically, new data model definitions are needed to support new features. YANG update rules defined in Section 11 of [RFC7950] MUST be followed for published modules. They MAY be followed for unpublished modules.
YANG モジュールは時間の経過とともに変更される可能性があります。通常、新しい機能をサポートするには、新しいデータ モデル定義が必要です。[RFC7950] のセクション 11 で定義されている YANG 更新ルールは、公開されたモジュールに対して従わなければなりません (MUST)。未公開モジュールについてもこれらに従うことができます (MAY)。
The YANG update rules only apply to published module revisions. Each organization will have their own way to identify published work that is considered to be stable and unpublished work that is considered to be unstable. For example, in the IETF, an RFC is used for published work, and an I-D is used for unpublished work.
YANG 更新ルールは、公開されたモジュール リビジョンにのみ適用されます。各組織は、安定していると考えられる公開済みの作品と、不安定であると考えられる未公開の作品を識別する独自の方法を持っています。たとえば、IETF では、公開された著作物には RFC が使用され、未公開の著作物には I-D が使用されます。
[RFC8819] specifies a method for associating tags with YANG modules. Tags may be defined and associated at design time, at implementation time, or via user administrative control. Design-time tags are indicated using the module-tag "extension" statement.
[RFC8819] は、タグを YANG モジュールに関連付ける方法を指定しています。タグは、設計時、実装時、またはユーザー管理制御を介して定義および関連付けることができます。設計時のタグは、module-tag の「extension」ステートメントを使用して示されます。
A module MAY indicate, using module-tag "extension" statements, a set of tags that are to be automatically associated with it (i.e., not added through configuration).
モジュールは、モジュールタグの「拡張」ステートメントを使用して、自動的に関連付けられる (つまり、設定を通じて追加されない) タグのセットを示すことができます (MAY)。
module example-module {
namespace "https://example.com/yang/example";
prefix "ex";
//...
import module-tags { prefix tags; }
tags:module-tag "ietf:some-new-tag";
tags:module-tag "ietf:some-other-tag";
// ...
}
Authors can use existing standard tags or use new tags defined in the model definition, as appropriate. For IETF modules, new tags MUST be assigned in the IANA "IETF YANG Module Tags" registry within the "YANG Module Tags" registry group [IANA-TAGS].
作成者は、必要に応じて、既存の標準タグを使用することも、モデル定義で定義された新しいタグを使用することもできます。IETF モジュールの場合、「YANG モジュール タグ」レジストリ グループ [IANA-TAGS] 内の IANA 「IETF YANG モジュール タグ」レジストリに新しいタグを割り当てなければなりません。
For contexts where YANG is used to model abstract data structures (e.g., protocol messages), the use of the "structure" extension statement [RFC8791] is RECOMMENDED compared to the "yang-data" extension statement [RFC8040]. Examples of modules that rely upon the "structure" extension statement from [RFC8791] can be found in [RFC9132] or [RFC9195].
YANG が抽象データ構造 (プロトコルメッセージなど) をモデル化するために使用されるコンテキストでは、「yang-data」拡張ステートメント [RFC8040] と比較して、「structural」拡張ステートメント [RFC8791] の使用が推奨されます。[RFC8791] の「構造」拡張ステートメントに依存するモジュールの例は、[RFC9132] または [RFC9195] にあります。
Abstract data structures can be augmented using the "augment-structure" statement [RFC8791]. Examples of modules that augment abstract data structures can be found in [RFC9244] and [RFC9362].
抽象データ構造は、「augment- Structure」ステートメント [RFC8791] を使用して拡張できます。抽象データ構造を拡張するモジュールの例は、[RFC9244] および [RFC9362] にあります。
IANA maintains a set of registries that are key for interoperability. The content of these registries is usually available using various formats (e.g., plain text or XML). However, there was some confusion in the past about whether the content of some registries is dependent on a specific representation format. For example, Section 5 of [RFC8892] was published to clarify that MIB and YANG modules are merely additional formats in which the "Interface Types (ifType)" and "Tunnel Types (tunnelType)" registries are available. The MIB [RFC2863] and YANG modules ([RFC7224] [RFC8675]) are not separate registries, and the same values are always present in all formats of the same registry.
IANA は、相互運用性の鍵となる一連のレジストリを維持しています。これらのレジストリのコンテンツは、通常、さまざまな形式 (プレーン テキストや XML など) を使用して利用できます。ただし、一部のレジストリの内容が特定の表現形式に依存しているかどうかについて、過去に混乱がありました。たとえば、[RFC8892] のセクション 5 は、MIB および YANG モジュールが、「インターフェイス タイプ (ifType)」および「トンネル タイプ (tunnelType)」レジストリが利用可能な単なる追加フォーマットであることを明確にするために公開されました。MIB [RFC2863] と YANG モジュール ([RFC7224] [RFC8675]) は別個のレジストリではなく、同じレジストリのすべての形式に同じ値が常に存在します。
A design in which a YANG module includes parameters and values directly in a module that is not maintained by IANA while these are populated in an IANA registry could lead to ambiguity and maintain stale information. Such a design creates another source of information that may deviate from the IANA registry as new values are assigned or some values are deprecated.
YANG モジュールのパラメータと値が IANA レジストリに設定される一方で、IANA によって管理されていないモジュールに直接パラメータと値が含まれる設計では、あいまいさが生じ、古い情報が維持される可能性があります。このような設計では、新しい値が割り当てられたり、一部の値が非推奨になったりするときに、IANA レジストリから逸脱する可能性のある別の情報ソースが作成されます。
For the sake of consistency and the ability to support new values while maintaining IANA registries as the unique authoritative source of information, this document recommends the use of IANA-maintained YANG modules as the single source of information.
一貫性と、IANA レジストリを独自の信頼できる情報源として維持しながら新しい値をサポートできるようにするために、この文書では、IANA が維持する YANG モジュールを単一の情報源として使用することを推奨します。
The following section provides a set of guidelines for YANG module authors related to the design of IANA-maintained YANG modules. These guidelines are meant to leverage existing IANA registries and use YANG as another format to present the content of these registries when appropriate.
次のセクションでは、IANA が管理する YANG モジュールの設計に関連する YANG モジュール作成者向けの一連のガイドラインを提供します。これらのガイドラインは、既存の IANA レジストリを活用し、必要に応じてこれらのレジストリのコンテンツを表示するための別の形式として YANG を使用することを目的としています。
When designing a YANG module for a functionality governed by a protocol for which IANA maintains a registry, it is RECOMMENDED to specify an IANA-maintained YANG module that echoes the content of that registry. This is superior to including that content in an IETF-maintained module.
IANA がレジストリを管理するプロトコルによって管理される機能の YANG モジュールを設計する場合、そのレジストリの内容をエコーする IANA が管理する YANG モジュールを指定することが推奨されます。これは、IETF が管理するモジュールにそのコンテンツを含めるよりも優れています。
When one or multiple registries are available under the same registry group, it is RECOMMENDED to define an IANA-maintained YANG module for each registry. However, module designers MAY consider defining one single IANA-maintained YANG module that covers all registries if maintaining that single module is manageable (e.g., very few values are present or expected to be present for each registry). An example of such a module is documented in Section 5.2 of [RFC9132].
1 つまたは複数のレジストリが同じレジストリ グループで利用可能な場合、レジストリごとに IANA が管理する YANG モジュールを定義することが推奨されます。ただし、モジュール設計者は、単一モジュールの維持が管理可能な場合 (たとえば、各レジストリに存在する値が非常に少ない、または存在すると予想される)、すべてのレジストリをカバーする単一の IANA 管理 YANG モジュールを定義することを検討してもよい(MAY)。このようなモジュールの例は、[RFC9132] のセクション 5.2 に記載されています。
An IANA-maintained YANG module may use the "identityref" data type approach (e.g., [RFC8675]) or an "enumeration" data type approach (e.g., [RFC9108]). See Section 4.11.1 for a guidance on which data type to use. The decision about which type to use should be made based upon specifics related to the intended use of the IANA-maintained YANG module. For example, identities are useful if the registry entries are organized hierarchically, possibly including multiple inheritances. The reasoning for the design choice MUST be documented in the companion specification that registers an IANA-maintained YANG module. For example, [RFC9244] defines an IANA-maintained YANG module that uses enumerations for the following reason:
IANA が管理する YANG モジュールは、「identityref」データ型アプローチ (例: [RFC8675]) または「列挙」データ型アプローチ (例: [RFC9108]) を使用できます。使用するデータ型に関するガイダンスについては、セクション 4.11.1 を参照してください。どのタイプを使用するかは、IANA が管理する YANG モジュールの使用目的に関連する詳細に基づいて決定する必要があります。たとえば、レジストリ エントリが階層的に編成されており、おそらく複数の継承が含まれている場合、アイデンティティは便利です。設計選択の理由は、IANA が管理する YANG モジュールを登録する関連仕様に文書化されなければなりません (MUST)。たとえば、[RFC9244] では、次の理由で列挙型を使用する IANA 管理の YANG モジュールが定義されています。
The DOTS telemetry module (Section 11.1) uses "enumerations" rather than "identities" to define units, samples, and intervals because otherwise the namespace identifier "ietf-dots-telemetry" must be included when a telemetry attribute is included (e.g., in a mitigation efficacy update). The use of "identities" is thus suboptimal from the standpoint of message compactness, as message compactness is one of the key requirements for DOTS signal channel messages.
DOTS テレメトリ モジュール (セクション 11.1) は、単位、サンプル、間隔を定義するために「アイデンティティ」ではなく「列挙」を使用します。これを使用しないと、テレメトリ属性が含まれる場合 (緩和効果の更新など)、名前空間識別子「ietf-dots-telemetry」が含まれなければなりません。したがって、メッセージのコンパクトさは DOTS 信号チャネル メッセージの重要な要件の 1 つであるため、「アイデンティティ」の使用はメッセージのコンパクトさの観点からは最適とは言えません。
Designers of IANA-maintained YANG modules MAY supply the initial full version of the module in a specification document that registers the module or only a script to be used (including by IANA) for generating the module (e.g., an Extensible Stylesheet Language Transformations (XSLT) stylesheet as in Appendix A of [RFC9108] or a Python script as in [RFC9645]). For both cases, the document that defines an IANA-maintained YANG module MUST include a note indicating that the document is only documenting the initial version of the module and that the authoritative version is to be retrieved from the IANA registry. Also, the IANA-maintained module MUST include the following note indicating the RFC that registered the initial version of the IANA-maintained YANG module:
IANA が管理する YANG モジュールの設計者は、モジュールを登録する仕様書、またはモジュールの生成に使用されるスクリプト (IANA によるものを含む) のみ (例: [RFC9108] の付録 A にある Extensible Stylesheet Language Transformations (XSLT) スタイルシート、または [RFC9645] にある Python スクリプト) のみを登録する仕様書でモジュールの初期完全バージョンを提供してもよい(MAY)。どちらの場合も、IANA が管理する YANG モジュールを定義する文書には、その文書がモジュールの初期バージョンのみを文書化していること、および正式なバージョンは IANA レジストリから取得されることを示す注記が含まれなければなりません (MUST)。また、IANA が管理するモジュールには、IANA が管理する YANG モジュールの初期バージョンを登録した RFC を示す次のメモが含まれなければなりません (MUST)。
The initial version of this YANG module is part of RFC IIII; see the RFC itself for full legal notices.
この YANG モジュールの初期バージョンは RFC IIII の一部です。完全な法的通知については、RFC 自体を参照してください。
It is RECOMMENDED to include the URL from where to retrieve the recent version of the module. When a script is used, the Internet-Draft that defines an IANA-maintained YANG module has to include an appendix with the full script and SHOULD include an appendix with the initial full version of the module. Including such an appendix in Internet-Drafts is meant to assess the correctness of the outcome of the supplied script. The authors MUST include a note to the RFC Editor requesting that the appendix with the initial version of the module be removed before publication as RFC and that RFC IIII is replaced with the RFC number that is assigned to the document. Initial versions of IANA-maintained YANG modules that are published in RFCs may be misused despite the appropriate language to refer to the IANA registry to retrieve the up-to-date module. This is problematic for interoperability, e.g., when values are deprecated or are associated with a new meaning.
モジュールの最新バージョンを取得するための URL を含めることをお勧めします。スクリプトが使用される場合、IANA が管理する YANG モジュールを定義する Internet-Draft には、完全なスクリプトを含む付録を含める必要があり、モジュールの最初の完全バージョンを含む付録を含めるべきです (SHOULD)。このような付録を Internet-Drafts に含めることは、提供されたスクリプトの結果の正確さを評価することを目的としています。著者は、RFC として公開する前にモジュールの初期バージョンを含む付録を削除し、RFC IIII を文書に割り当てられた RFC 番号に置き換えることを要求する RFC 編集者へのメモを含めなければなりません (MUST)。RFC で公開されている IANA 管理の YANG モジュールの初期バージョンは、最新のモジュールを取得するために IANA レジストリを参照するための適切な言語にもかかわらず、悪用される可能性があります。これは、値が非推奨になったり、新しい意味に関連付けられたりする場合など、相互運用性にとって問題になります。
Note: [Style] provides XSLT 1.0 stylesheets and other tools for translating IANA registries to YANG modules. The tools can be used to generate up-to-date revisions of an IANA-maintained YANG module based upon the XML representation of an IANA registry.
注: [スタイル] は、IANA レジストリを YANG モジュールに変換するための XSLT 1.0 スタイルシートおよびその他のツールを提供します。このツールを使用すると、IANA レジストリの XML 表現に基づいて、IANA が管理する YANG モジュールの最新リビジョンを生成できます。
If an IANA-maintained YANG module is imported by another module, a normative reference with the IANA URL from which to retrieve the IANA-maintained YANG module SHOULD be included. Although not encouraged, referencing the RFC that defines the initial version of the IANA module is acceptable in specific cases (e.g., the imported version is specifically the initial version, the RFC includes useful description about the usage of the module).
IANA が管理する YANG モジュールが別のモジュールによってインポートされる場合、IANA が管理する YANG モジュールを取得するための IANA URL を含む規範的な参照が含まれる必要があります (SHOULD)。推奨されませんが、IANA モジュールの初期バージョンを定義する RFC を参照することは、特定の場合には許容されます (例: インポートされたバージョンが特に初期バージョンであり、RFC にはモジュールの使用法に関する有用な説明が含まれています)。
Examples of IANA URLs from which to retrieve the latest version of an IANA-maintained YANG module are as follows:
IANA が管理する YANG モジュールの最新バージョンを取得するための IANA URL の例は次のとおりです。
* https://www.iana.org/assignments/iana-bgp-l2-encaps,
* https://www.iana.org/assignments/iana-bgp-l2-encaps,
* https://www.iana.org/assignments/iana-pseudowire-types, and
* https://www.iana.org/assignments/iana-pseudowire-types、および
* https://www.iana.org/assignments/iana-bfd-types.
* https://www.iana.org/assignments/iana-bfd-types.
"IANA_FOO_URL" is used in the following to refer to such URLs. These URLs are expected to be sufficiently permanent and stable.
以下では、そのような URL を指すために「IANA_FOO_URL」が使用されます。これらの URL は十分に永続的で安定していることが期待されます。
Whenever referencing a specific version of an IANA-maintained YANG module is needed, then URLs such as the following are used:
IANA が管理する YANG モジュールの特定のバージョンを参照する必要がある場合は、次のような URL が使用されます。
* https://www.iana.org/assignments/iana-bgp-l2-encaps@2022-09-20.yang
* https://www.iana.org/assignments/iana-bgp-l2-encaps@2022-09-20.yang
"IANA_FOO_URL_With_REV" is used in the following to refer to such URLs.
以下では、そのような URL を指すために「IANA_FOO_URL_With_REV」が使用されます。
A template for IANA-maintained YANG modules is provided in Appendix C.
IANA が管理する YANG モジュールのテンプレートは付録 C に提供されています。
In addition to the IANA considerations in Section 3.8, the IANA Considerations section of an RFC that includes an IANA-maintained YANG module MUST provide the required instructions for IANA to automatically perform the maintenance of that IANA module. These instructions describe how to proceed with updates to the IANA-maintained YANG module that are triggered by a change to the authoritative registry. Concretely, the IANA Considerations section SHALL at least provide the following information:
セクション 3.8 の IANA 考慮事項に加え、IANA が保守する YANG モジュールを含む RFC の IANA 考慮事項セクションは、IANA がその IANA モジュールの保守を自動的に実行するために必要な指示を提供しなければなりません (MUST)。これらの手順では、権限のあるレジストリへの変更によってトリガーされる、IANA が管理する YANG モジュールの更新を続行する方法について説明します。具体的には、IANA の考慮事項セクションでは、少なくとも次の情報を提供するものとします。
* A request to IANA to add a note to the page displaying the information about the IANA-maintained YANG module that new values must not be directly added to the module. These values should be added to an authoritative IANA registry.
* IANA が管理する YANG モジュールに関する情報を表示するページに、新しい値をモジュールに直接追加してはならないという注記を追加するよう IANA にリクエストします。これらの値は、信頼できる IANA レジストリに追加する必要があります。
* A request to IANA to add a note to the authoritative IANA registry to indicate that any change to the registry must be reflected into the corresponding IANA-maintained YANG module. That is, any changes to the registry must be accompanied by an update to the corresponding IANA-maintained YANG module.
* レジストリへの変更は、対応する IANA が管理する YANG モジュールに反映する必要があることを示すメモを、権威ある IANA レジストリに追加するよう IANA に要求します。つまり、レジストリへの変更には、対応する IANA が管理する YANG モジュールの更新を伴う必要があります。
* Details about the required actions (e.g., add a new "identity" or "enum" statement) to update the IANA-maintained YANG module to reflect changes to an authoritative IANA registry. Typically, these details have to include the procedure to create a new "identity" statement name and substatements ("base", "status", "description", and "reference") or a new "enum" statement and substatements ("value", "status", "description", and "reference").
* IANA が管理する YANG モジュールを更新して、権限のある IANA レジストリへの変更を反映するために必要なアクション (新しい「identity」または「enum」ステートメントの追加など) の詳細。通常、これらの詳細には、新しい「identity」ステートメント名とサブステートメント (「base」、「status」、「description」、および「reference」)、または新しい「enum」ステートメントとサブステートメント (「value」、「status」、「description」、および「reference」) を作成する手順が含まれている必要があります。
- When creating a new "identity" statement name or a new "enum" statement, it is RECOMMENDED to use the same name (if present) as recorded in the IANA registry.
- 新しい「identity」ステートメント名または新しい「enum」ステートメントを作成するときは、IANA レジストリに記録されているのと同じ名前 (存在する場合) を使用することが推奨されます。
- If the name in the IANA registry does not comply with the naming conventions listed in Section 4.3.1, the procedure MUST detail how IANA can generate legal identifiers from such a name. Specifically, if the name begins with a number, it is RECOMMENDED to spell out (i.e., not use a digit) the number when used as an identifier. IANA should be provided with instructions to perform such a task. For example, authors of a module with such identifiers have to indicate whether:
- IANA レジストリ内の名前がセクション 4.3.1 にリストされている命名規則に準拠していない場合、その手順では、IANA がそのような名前から法的識別子を生成する方法を詳細に説明しなければなりません。特に、名前が数字で始まる場合、識別子として使用する場合はその数字をスペルアウトする (つまり、数字を使用しない) ことが推奨されます。IANA には、そのようなタスクを実行するための指示が提供される必要があります。たとえば、そのような識別子を持つモジュールの作成者は、次のことを示す必要があります。
o "3des-cbc" should be "three-des-cbc" or rather "triple-des-cbc" to be consistent with Section 6.3 of [RFC4253].
o [RFC4253] のセクション 6.3 との一貫性を保つために、「3des-cbc」は「three-des-cbc」、あるいはむしろ「triple-des-cbc」である必要があります。
o "6to4" should be "sixToFour" as in [RFC7224] or "sixtofour" as in [RFC8675].
o 「6to4」は、[RFC7224] の場合は「sixToFour」、または [RFC8675] の場合は「sixtofour」である必要があります。
- If a new registration uses an identifier that does not comply with the naming conventions listed in Section 4.3.1, IANA should check if guidance to generate legal identifiers was supplied in the RFC that specified the initial version of the module. If no such guidance is available, IANA should check the latest revision of the IANA-maintained YANG module for similar patterns. If all else fails, IANA should seek advice from relevant registry experts (e.g., designated experts for a registry using the Expert Review policy (Section 4.5 of [RFC8126]) or responsible area director).
- 新しい登録で、セクション 4.3.1 にリストされている命名規則に準拠していない識別子が使用されている場合、IANA は、モジュールの初期バージョンを指定した RFC に法的な識別子を生成するためのガイダンスが提供されているかどうかを確認する必要があります。そのようなガイダンスが利用できない場合、IANA は、IANA が管理する YANG モジュールの最新リビジョンに同様のパターンがないか確認する必要があります。他のすべてがうまくいかない場合、IANA は関連するレジストリの専門家 (たとえば、専門家レビュー ポリシー ([RFC8126] のセクション 4.5) を使用してレジストリに指定された専門家、または担当領域ディレクター) にアドバイスを求める必要があります。
The IANA Considerations Section MAY also provide the following information if a default action is to be overridden:
IANA の考慮事項セクションでは、デフォルトのアクションがオーバーライドされる場合に、次の情報も提供できます (MAY)。
* A note whether unassigned or reserved values should be present in the IANA-maintained YANG module. If no instruction is provided, unassigned or reserved values must not be present in the IANA-maintained YANG module.
* IANA が管理する YANG モジュールに未割り当ての値または予約された値が存在する必要があるかどうかに関する注記。命令が提供されない場合、IANA が管理する YANG モジュールに未割り当ての値または予約された値が存在してはなりません。
* An instruction whether experimental values should be included in the IANA-maintained YANG module. If no instruction is provided, experimental values MUST NOT be listed in the IANA-maintained YANG module.
* IANA が管理する YANG モジュールに実験値を含めるべきかどうかの指示。指示が提供されない場合、実験値を IANA が管理する YANG モジュールにリストしてはなりません。
* An instruction about how to generate the "revision" statement. If no instruction is provided, default actions provided in Section 5.3 will be followed.
* 「リビジョン」ステートメントを生成する方法に関する説明。指示が提供されない場合は、セクション 5.3 に記載されているデフォルトのアクションに従います。
A template for the IANA Considerations is provided in Section 4.30.3.1 for IANA-maintained YANG modules with identities and Section 4.30.3.2 for IANA-maintained YANG modules with enumerations. Authors may modify the template to reflect specifics of their modules (e.g., multiple registries can be listed for a single IANA-maintained YANG module, no explicit description (or name) field is listed under the authoritative IANA registry, or the name does not comply with YANG naming conventions (Section 4.3.1)).
IANA 考慮事項のテンプレートは、ID を使用する IANA 管理の YANG モジュールについてはセクション 4.30.3.1 で提供され、列挙を使用する IANA 管理の YANG モジュールについてはセクション 4.30.3.2 で提供されます。作成者は、モジュールの詳細を反映するためにテンプレートを変更することができます (たとえば、IANA が管理する単一の YANG モジュールに対して複数のレジストリがリストされる可能性がある、権限のある IANA レジストリの下に明示的な説明 (または名前) フィールドがリストされない、または名前が YANG 命名規則 (セクション 4.3.1) に準拠していないなど)。
An example of "revision" statements that are generated following the guidance in Section 5.3.2 is provided below:
セクション 5.3.2 のガイダンスに従って生成される「改訂」ステートメントの例を以下に示します。
revision 2023-11-27 {
description
"Registered RR Type RESINFO 261.";
reference
"https://www.iana.org/assignments/yang-parameters/"
+ "iana-dns-class-rr-type@2023-11-27.yang";
}
revision 2023-11-08 {
description
"Updated description and replaced draft string reference to
64 and 65 with RFC 9460: Service Binding and Parameter
Specification via the DNS (SVCB and HTTPS Resource Records).";
reference
"RFC 9460: Service Binding and Parameter Specification via the
DNS (SVCB and HTTPS Resource Records)
https://www.iana.org/assignments/yang-parameters/"
+ "iana-dns-class-rr-type@2023-11-08.yang";
}
revision 2023-04-25 {
description
"Updated reference for 64 and 65.";
reference
"https://www.iana.org/assignments/yang-parameters/"
+ "iana-dns-class-rr-type@2023-04-25.yang";
}
revision 2022-05-30 {
description
"Updated description, reference for 64 and 65.";
reference
"https://www.iana.org/assignments/yang-parameters/"
+ "iana-dns-class-rr-type@2022-05-30.yang";
}
revision 2021-08-31 {
description
"Initial revision.";
reference
"RFC 9108: YANG Types for DNS Classes and Resource Record
Types";
}
Duplicating the same reference at the high level and at the level of a new addition might be redundant. For example, the following does not provide access to a specific (OLD) revision of the module when future revisions are made [IANA_Tunnel_Type_URL]:
同じ参照を上位レベルと新規追加レベルで複製すると、冗長になる可能性があります。たとえば、次のコードでは、将来のリビジョンが作成されたときに、モジュールの特定の (古い) リビジョンへのアクセスが提供されません [IANA_Tunnel_Type_URL]:
revision 2021-04-23 {
description
"Registered tunnelType 19.";
reference
"RFC 4301: Security Architecture for the Internet Protocol";
}
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC 8675: A YANG Data Model for Tunnel Interface Types";
}
...
identity ipsectunnelmode {
base ift:tunnel;
description
"IpSec tunnel mode encapsulation.";
reference
"RFC 4301: Security Architecture for the Internet Protocol";
}
The following example shows how to generate the "revision" statements following the guidance in Section 5.3.2:
次の例は、セクション 5.3.2 のガイダンスに従って「リビジョン」ステートメントを生成する方法を示しています。
revision 2021-04-23 {
description
"Registered tunnelType 19.";
reference
"https://www.iana.org/assignments/yang-parameters/"
+ "iana-tunnel-type@2021-04-23.yang
RFC 4301: Security Architecture for the Internet Protocol";
}
revision 2019-11-16 {
description
"Initial revision.";
reference
"RFC 8675: A YANG Data Model for Tunnel Interface Types";
}
...
identity ipsectunnelmode {
base ift:tunnel;
description
"IpSec tunnel mode encapsulation.";
reference
"RFC 4301: Security Architecture for the Internet Protocol";
}
The templates in the following subsections are to be considered in addition to the required information that is provided in Section 3.8.
次のサブセクションのテンプレートは、セクション 3.8 で提供される必須情報に加えて考慮されます。
<BEGIN TEMPLATE TEXT>
This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry.
IANA is requested to add this note to [reference-to-the-iana-foo-
registry]:
When this registry is modified, the YANG module "iana-foo"
[IANA_FOO_URL] must be updated as defined in RFC IIII.
When a value is added to the "foo" registry, a new "identity"
statement needs to be added to the "iana-foo" YANG module.
The name of the "identity" MUST be the name as provided in the
registry. The "identity" statement should have the following
substatements defined:
"base": Contains 'name-base-identity-defined-in-foo'.
"status": Include only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status
"obsolete".
"description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with
the title of the document(s) added.
-- Optional:
-- Include only text that needs to be customized for the module.
-- Text that does not require customization should be
-- omitted.
-- Notes tagged with "--" include instructions for authors. These
-- notes must not be copied.
Unassigned and Reserved Values:
-- To be completed only if unassigned and/or reserved values
-- (which may include experimental values) should be included
-- in the module. These values are typically not included.
Description Substatements:
-- To be completed only if the default actions described in
-- Section 5.3.2 of RFC 9907 are to be overridden.
-- Specify whether instructions apply to "revision" statements,
-- "identity" statements, or both.
Reference Substatements:
-- To be completed only if the default actions described in
-- Section 5.3.2 of RFC 9907 are to be overridden.
-- Specify whether instructions apply to "revision" statements,
-- "identity" statements, or both.
Naming Considerations:
-- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when
-- used as an identifier.
<END TEMPLATE TEXT>
<BEGIN TEMPLATE TEXT>
This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry.
When a value is added to the "foo" registry, a new "enum" statement
must be added to the "iana-foo" YANG module. The "enum" statement,
and substatements thereof, should be defined:
"enum": Replicates a name from the registry.
"value": Contains the decimal value of the IANA-assigned
value.
"status": Is included only if a registration has been
deprecated or obsoleted. IANA "deprecated" maps
to YANG status "deprecated", and IANA "obsolete"
maps to YANG status "obsolete".
"description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry.
References to documents should also include titles.
-- Optional:
-- Include only text that needs to be customized for the module.
-- Text that does not require customization should be
-- omitted.
-- Notes tagged with "--" include instructions for authors. These
-- notes must not be copied.
Unassigned and Reserved Values:
-- To be completed only if unassigned and/or reserved values
-- (which may include experimental values) should be included
-- in the module. These values are typically not included.
Description Substatements:
-- To be completed only if the default actions described in
-- Section 5.3.2 of RFC 9907 are to be overridden.
-- Specify whether instructions apply to "revision" statements, "enum"
-- statements, or both.
Reference Substatements:
-- To be completed only if the default actions described in
-- Section 5.3.2 of RFC 9907 are to be overridden.
-- Specify whether instructions apply to "revision" statements, "enum"
-- statements, or both.
Naming Considerations:
-- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when
-- used as an identifier.
<END TEMPLATE TEXT>
The following registration in the "ns" registry of the "IETF XML Registry" registry group [RFC3688] was detailed in [RFC8407]. IANA has updated this registration to reference this document.
"IETF XML Registry" レジストリ グループ [RFC3688] の "ns" レジストリへの次の登録は、[RFC8407] で詳細に説明されています。IANA は、この文書を参照するためにこの登録を更新しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-template
urn:ietf:params:xml:ns:yang:ietf-template
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" registry group [RFC3688]:
IANA は、「IETF XML Registry」レジストリ グループ [RFC3688] 内の「ns」レジストリに次の URI を登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:iana-template
urn:ietf:params:xml:ns:yang:iana-template
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters" registry group.
IANA は、「YANG Parameters」レジストリ グループ内の「YANG Module Names」レジストリ [RFC6020] [RFC9890] に次の YANG モジュールを登録しました。
Name:
名前：
ietf-template
IETF テンプレート
Maintained by IANA?
IANAによって保守されていますか？
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-template
urn:ietf:params:xml:ns:yang:ietf-template
Prefix:
プレフィックス:
temp
温度
Reference:
参照：
RFC 9907
RFC 9907
Name:
名前：
iana-template
イアナテンプレート
Maintained by IANA?
IANAによって保守されていますか？
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:iana-template
urn:ietf:params:xml:ns:yang:iana-template
Prefix:
プレフィックス:
iana-foo
イアナフー
Reference:
参照：
RFC 9907
RFC 9907
For the references of the "YANG Module Names" registry under the "YANG Parameters" registry group, IANA has updated [RFC8407] to this document, as it contains the template necessary for registration in Appendix B.
「YANG Parameters」レジストリ グループの「YANG Module Names」レジストリの参照について、IANA は付録 B への登録に必要なテンプレートが含まれているため、この文書の [RFC8407] を更新しました。
IANA should refer to Section 4.30.3 for information necessary to populate "revision" statements and "identity" and "enum" substatements in IANA-maintained YANG modules.
IANA は、IANA が管理する YANG モジュールの「revision」ステートメントと「identity」および「enum」サブステートメントを設定するために必要な情報について、セクション 4.30.3 を参照する必要があります。
These considerations cover both the creation and maintenance of an IANA-maintained YANG module, and they include both instructions applicable to all IANA-maintained YANG modules and instructions that can be customized by module creators.
これらの考慮事項は、IANA が保守する YANG モジュールの作成と保守の両方をカバーしており、IANA が保守するすべての YANG モジュールに適用できる手順と、モジュール作成者がカスタマイズできる手順の両方が含まれています。
In particular, the following instructions should apply to all modules:
特に、次の手順はすべてのモジュールに適用する必要があります。
* When a YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements. The "revision" statement MUST contain both "description" and "reference" substatements as described in Section 5.3.2.
* YANG モジュールが更新されるときは、固有のリビジョン日付を持つ新しい「リビジョン」ステートメントを既存のリビジョン ステートメントの前に追加する必要があります。「revision」ステートメントには、セクション 5.3.2 で説明されているように、「description」サブステートメントと「reference」サブステートメントの両方を含める必要があります。
* When an underlying registration is deprecated or obsoleted, a corresponding "status" substatement should be added to the "identity" or "enum" statement.
* 基礎となる登録が非推奨または廃止された場合、対応する「status」サブステートメントを「identity」または「enum」ステートメントに追加する必要があります。
* The "reference" substatement in the "revision" statement should point specifically to the published module (i.e., IANA_FOO_URL_With_REV). When the registration is triggered by an RFC, that RFC must also be included in the "reference" substatement. It may also point to an authoritative event triggering the update to the YANG module. In all cases, the event is cited from the underlying IANA registry.
* 「revision」ステートメント内の「reference」サブステートメントは、公開されたモジュール (つまり、IANA_FOO_URL_With_REV) を明確に指す必要があります。登録が RFC によってトリガーされる場合、その RFC も「reference」サブステートメントに含める必要があります。また、YANG モジュールの更新をトリガーする権限のあるイベントを示している場合もあります。すべての場合において、イベントは基礎となる IANA レジストリから引用されます。
* References to documents should include titles.
* 文書への参照にはタイトルを含める必要があります。
In addition, when the module is published, IANA must add the following notes to:
さらに、モジュールが公開されるとき、IANA は次の注記を追加する必要があります。
The YANG Module Names registry:
YANG モジュール名のレジストリ:
New values must not be directly added to the "iana-foo" YANG module. They must instead be added to the "foo" registry.
新しい値を「iana-foo」YANG モジュールに直接追加しないでください。代わりに、それらを「foo」レジストリに追加する必要があります。
The underlying registry:
基礎となるレジストリ:
When this registry is modified, the YANG module "iana-foo" [IANA_FOO_URL] must be updated as defined in RFC IIII.
このレジストリを変更する場合、YANG モジュール「iana-foo」[IANA_FOO_URL] を RFC IIII の定義に従って更新する必要があります。
Unless the creators of an IANA-maintained YANG module specify otherwise in their document's IANA Considerations section, the following instructions will apply:
IANA が管理する YANG モジュールの作成者がドキュメントの IANA 考慮事項セクションで別途指定しない限り、次の指示が適用されます。
* Unassigned and reserved values (including experimental values) will be omitted from the module.
* 未割り当ての値と予約された値 (実験値を含む) はモジュールから省略されます。
* The "reference" substatement in an "identity" or "enum" statement should mirror the underlying registry. It may point to contact names as well as documents.
* 「identity」または「enum」ステートメント内の「reference」サブステートメントは、基礎となるレジストリを反映する必要があります。文書だけでなく連絡先の名前も指す場合があります。
* In a "revision" statement, the "description" substatement captures what changed in the revised version. Typically, the "description" enumerates changes such as updates to existing entries (e.g., update a "description" or a "reference") or notes which identities were added or had their status changed (e.g., deprecated, discouraged, or obsoleted).
* 「revision」ステートメントの「description」サブステートメントは、改訂版での変更内容をキャプチャします。通常、「説明」は、既存のエントリの更新 (例: 「説明」または「参照」の更新) などの変更を列挙するか、どの ID が追加されたか、またはステータスが変更されたか (非推奨、非推奨、廃止など) を記録します。
When such a description is not feasible, the description varies in accordance with the trigger for the update.
このような記述が不可能な場合には、更新の契機に応じて記述が変化する。
If the update is triggered by an RFC, the "description" substatement should include or consist of this text:
更新が RFC によってトリガーされる場合、「説明」サブステートメントには次のテキストが含まれるか、次のテキストで構成される必要があります。
Applied updates as specified by RFC XXXX.
RFC XXXX の指定に従って更新を適用しました。
If the registration policy for the registry does not require RFC publication (Section 4 of [RFC8126]), insert this text:
レジストリの登録ポリシーが RFC 公開 ([RFC8126] のセクション 4) を必要としない場合は、次のテキストを挿入します。
Applied updates as specified by the registration policy <Some_IANA_policy>.
登録ポリシー <Some_IANA_policy> で指定された更新を適用しました。
Although the document focuses on YANG data modeling language guidance, the document does not define a protocol or a protocol extension. As such, there are no new operations or manageability requirements introduced by this document.
この文書は YANG データ モデリング言語のガイダンスに焦点を当てていますが、プロトコルやプロトコル拡張は定義していません。そのため、このドキュメントで導入される新しい操作要件や管理性要件はありません。
This document defines guidelines for NETCONF or RESTCONF content defined with the YANG data modeling language. It does not introduce any new or increased security risks.
このドキュメントでは、YANG データ モデリング言語で定義された NETCONF または RESTCONF コンテンツのガイドラインを定義します。これにより、新たなセキュリティ リスクが発生したり、セキュリティ リスクが増加したりすることはありません。
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
DOI 10.17487/RFC5378, November 2008,
<https://www.rfc-editor.org/info/rfc5378>.
[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>.
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021,
<https://www.rfc-editor.org/info/rfc8819>.
[RFC9890] Bierman, A., Boucadair, M., Ed., and Q. Wu, "An Update to
YANG Module Names Registration", RFC 9890,
DOI 10.17487/RFC9890, October 2025,
<https://www.rfc-editor.org/info/rfc9890>.
[W3C.REC-xpath]
Clark, J., Ed. and S. DeRose, Ed., "XML Path Language
(XPath) Version 1.0", W3C Recommendation, 16 November
1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.
[Err5693] RFC Errata, Erratum ID 5693, RFC 8407,
<https://www.rfc-editor.org/errata/eid5693>.
[Err5800] RFC Errata, Erratum ID 5800, RFC 8407,
<https://www.rfc-editor.org/errata/eid5800>.
[Err6899] RFC Errata, Erratum ID 6899, RFC 8407,
<https://www.rfc-editor.org/errata/eid6899>.
[Err7416] RFC Errata, Erratum ID 7416, RFC 8407,
<https://www.rfc-editor.org/errata/eid7416>.
[IANA-MOD-NAMES]
IANA, "YANG Module Names",
<https://www.iana.org/assignments/yang-parameters/>.
[IANA-TAGS]
IANA, "YANG Module Tags",
<https://www.iana.org/assignments/yang-module-tags/>.
[IANA-XML] IANA, "IETF XML Registry",
<https://www.iana.org/assignments/xml-registry/>.
[IANA-YANG-PARAMETERS]
IANA, "YANG Parameters",
<https://www.iana.org/assignments/yang-parameters>.
[IANA_Tunnel_Type_URL]
IANA, "iana-tunnel-type YANG Module",
<https://www.iana.org/assignments/iana-tunnel-type>.
[ID-Guidelines]
IETF, "Content guidelines overview",
<https://authors.ietf.org/en/content-guidelines-overview>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/info/rfc2606>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>.
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of
MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
September 2005, <https://www.rfc-editor.org/info/rfc4181>.
[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>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, DOI 10.17487/RFC5398,
December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[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>.
[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>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>.
[RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data
Model for Tunnel Interface Types", RFC 8675,
DOI 10.17487/RFC8675, November 2019,
<https://www.rfc-editor.org/info/rfc8675>.
[RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration
Procedures for Interface Types and Tunnel Types",
RFC 8892, DOI 10.17487/RFC8892, August 2020,
<https://www.rfc-editor.org/info/rfc8892>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[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>.
[RFC9108] Lhotka, L. and P. Špaček, "YANG Types for DNS Classes and
Resource Record Types", RFC 9108, DOI 10.17487/RFC9108,
September 2021, <https://www.rfc-editor.org/info/rfc9108>.
[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for the OSPF Protocol", RFC 9129,
DOI 10.17487/RFC9129, October 2022,
<https://www.rfc-editor.org/info/rfc9129>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG
Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
2022, <https://www.rfc-editor.org/info/rfc9195>.
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/info/rfc9244>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/info/rfc9291>.
[RFC9362] Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Robust Block Transmission",
RFC 9362, DOI 10.17487/RFC9362, February 2023,
<https://www.rfc-editor.org/info/rfc9362>.
[RFC9637] Huston, G. and N. Buraglio, "Expanding the IPv6
Documentation Space", RFC 9637, DOI 10.17487/RFC9637,
August 2024, <https://www.rfc-editor.org/info/rfc9637>.
[RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS
Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024,
<https://www.rfc-editor.org/info/rfc9645>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/info/rfc9911>.
[Style] "IANA YANG", commit 3a6cb69, December 2021,
<https://github.com/llhotka/iana-yang>.
This section is adapted from [RFC4181].
このセクションは[RFC4181]を基にしています。
The purpose of a YANG module review is to review the YANG module for both technical correctness and adherence to IETF documentation requirements. The following checklist may be helpful when reviewing an I-D:
YANG モジュール レビューの目的は、技術的な正確性と IETF ドキュメント要件への準拠の両方について YANG モジュールをレビューすることです。I-D を確認する際には、次のチェックリストが役立ちます。
* I-D Boilerplate: Verify that the document contains the required sections (see <https://authors.ietf.org/required-content>).
* I-D ボイラープレート: ドキュメントに必要なセクションが含まれていることを確認します (<https://authors.ietf.org/required-content> を参照)。
* Abstract: Verify that the abstract does not contain references, that it does not have a section number, and that its content follows the guidelines in <https://www.ietf.org/id-info/ guidelines.html>.
* 要約: 要約に参考文献が含まれていないこと、セクション番号がないこと、およびその内容が <https://www.ietf.org/id-info/ガイドライン.html> のガイドラインに従っていることを確認してください。
* Copyright Notice: Verify that the document has the appropriate text regarding the rights that document contributors provide to the IETF Trust [RFC5378]. Verify that it contains the full IETF Trust copyright notice at the beginning of the document. The IETF Trust Legal Provisions (TLP) can be found at: <https://trustee.ietf.org/license-info/>
* 著作権に関する通知: 文書の寄稿者が IETF Trust [RFC5378] に提供する権利に関する適切なテキストが文書に含まれていることを確認してください。文書の冒頭に IETF Trust の著作権表示が完全に含まれていることを確認してください。IETF Trust Legal Provisions (TLP) は、<https://trustee.ietf.org/license-info/> でご覧いただけます。
* Security Considerations section: If none of the modules in the document falls under the exceptions in Section 3.7 (e.g., use YANG data structure), verify that the section is modeled after the latest approved template from the Operations and Management (OPS) area website (see <https://wiki.ietf.org/group/ops/yang-security-guidelines>) and that the guidelines therein have been followed.
* 「セキュリティに関する考慮事項」セクション: ドキュメント内のモジュールがセクション 3.7 の例外に該当しない場合 (YANG データ構造の使用など)、そのセクションが運用管理 (OPS) 領域の Web サイト (<https://wiki.ietf.org/group/ops/yang-security-guidelines> を参照) からの最新の承認済みテンプレートに基づいてモデル化されていること、およびそこに含まれるガイドラインに従っていることを確認します。
* IANA Considerations section: This section must always be present. For each module within the document, ensure that the IANA Considerations section contains entries for the following IANA registries:
* IANA の考慮事項セクション: このセクションは常に存在する必要があります。ドキュメント内の各モジュールについて、「IANA の考慮事項」セクションに次の IANA レジストリのエントリが含まれていることを確認してください。
- XML Namespace Registry: Register the YANG module namespace.
- XML 名前空間レジストリ: YANG モジュール名前空間を登録します。
- YANG Module Registry: Register the YANG module name, prefix, namespace, and RFC number according to the rules specified in [RFC6020].
- YANG Module Registry: YANG モジュール名、プレフィックス、名前空間、RFC 番号を [RFC6020] で規定されている規則に従って登録します。
* References: Verify that the references are properly divided between normative and informative references, that RFCs 2119 and 8174 are included as normative references if the terminology defined therein is used in the document, that all references required by the boilerplate are present, that all YANG modules containing imported items are cited as normative references, and that all citations point to the most current RFCs, unless there is a valid reason to do otherwise (for example, it is okay to include an informative reference to a previous version of a specification to help explain a feature included for backward compatibility). Be sure citations for all imported modules are present somewhere in the document text (outside the YANG module). If a YANG module contains "reference" or "description" statements that refer to an I-D, then the I-D is included as an informative reference.
* 参照: 参照が規範的参照と情報的参照に適切に分割されていること、RFC 2119 および 8174 で定義されている用語が文書内で使用されている場合は規範的参照として含まれていること、ボイラープレートで必要なすべての参照が存在していること、インポートされた項目を含むすべての YANG モジュールが規範的参照として引用されていること、および別段の正当な理由がない限り (たとえば、下位互換性のために含まれる機能を説明するために、仕様の前のバージョンへの有益な参照を含めることは問題ありません)。インポートされたすべてのモジュールの引用がドキュメント テキストのどこか (YANG モジュールの外側) に存在することを確認してください。YANG モジュールに I-D を参照する「参照」または「説明」ステートメントが含まれている場合、その I-D は情報参照として含まれます。
* License: Verify that the document contains the Revised BSD License in each YANG module or submodule. Some guidelines related to this requirement are described in Section 3.1. Make sure that the correct year is used in all copyright dates. Use the approved text from the latest TLP document, which can be found at: <https://trustee.ietf.org/license-info/>
* ライセンス: ドキュメントの各 YANG モジュールまたはサブモジュールに改訂された BSD ライセンスが含まれていることを確認します。この要件に関連するいくつかのガイドラインについては、セクション 3.1 で説明します。すべての著作権の日付に正しい年が使用されていることを確認してください。最新の TLP 文書の承認済みテキストを使用します。この文書は、<https://trustee.ietf.org/license-info/> にあります。
* Other Issues: Check for any issues mentioned in <https://www.ietf.org/id-info/checklist.html> that are not covered elsewhere.
* その他の問題: <https://www.ietf.org/id-info/checklist.html> で言及されている、他の場所では取り上げられていない問題がないか確認してください。
* Technical Content: Review the actual technical content for compliance with the guidelines in this document. The use of a YANG module compiler is recommended when checking for syntax errors. A list of freely available tools and other information, including formatting advice, can be found at: <https://wiki.ietf.org/group/netconf> and <https://wiki.ietf.org/group/netmod>
* 技術的な内容: この文書のガイドラインに準拠しているかどうか、実際の技術的な内容を確認してください。構文エラーをチェックする場合は、YANG モジュール コンパイラの使用をお勧めします。無料で利用できるツールのリストと、書式設定のアドバイスを含むその他の情報は、<https://wiki.ietf.org/group/netconf> および <https://wiki.ietf.org/group/netmod> で参照できます。
Checking for correct syntax, however, is only part of the job. It is just as important to actually read the YANG module document from the point of view of a potential implementor. It is particularly important to check that "description" statements are sufficiently clear and unambiguous to allow interoperable implementations to be created.
ただし、構文が正しいかどうかのチェックは作業の一部にすぎません。潜在的な実装者の観点から YANG モジュールのドキュメントを実際に読むことも同様に重要です。相互運用可能な実装を作成できるように、「説明」ステートメントが十分に明確で明確であることを確認することが特に重要です。
module ietf-template {
yang-version 1.1;
// replace this string with a unique namespace URN value
namespace "urn:ietf:params:xml:ns:yang:ietf-template";
// replace this string, and try to pick a unique prefix
prefix temp;
// import statements here: e.g.,
// import ietf-yang-types { prefix yang; }
// import ietf-inet-types { prefix inet; }
// identify the IETF working group if applicable
organization
"IETF your-wg-name (Expanded WG Name) Working Group";
// update this contact statement with your info
contact
"WG Web: https://datatracker.ietf.org/wg/your-wg-name
WG List: YOUR-WG-NAME <mailto:your-wg-name@ietf.org>
Editor: your-name
<mailto:your-email@example.com>";
// replace the first sentence in this "description" statement.
// replace the copyright notice with the most recent
// version, if it has been updated since the publication
// of this document.
description
"This module defines a template for other YANG modules.
Copyright (c) <insert year> 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).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed: replace 'date-revision' with the module publication date
// the format is (YYYY-MM-DD)
// replace XXXX with actual RFC number and remove
// this note
revision date-revision {
description
"What changed in this revision.";
reference
"RFC XXXX: <Replace With Document Title>";
}
// Authors: Replace RFC IIII with the RFC number and title
// of the RFC that defined the initial version of
// the module and remove this note
revision date-initial {
description
"Initial version.";
reference
"RFC IIII: <Replace With Document Title>";
}
// extension statements
// feature statements
// identity statements
// typedef statements
// grouping statements
// data definition statements
// augment statements
// rpc statements
// notification statements
// DO NOT put deviation statements in a published module
}
module iana-template {
yang-version 1.1;
// replace this string with a unique namespace URN value
namespace "urn:ietf:params:xml:ns:yang:iana-template";
// replace with the assigned prefix
prefix iana-foo;
organization
"Internet Assigned Numbers Authority (IANA)";
contact
"Internet Assigned Numbers Authority
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This module defines a template for IANA-maintained modules.
Copyright (c) <insert year> 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).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
The initial version of this YANG module is part of RFC IIII;
see the RFC itself for full legal notices.
// RFC Ed.: replace IIII with actual RFC number and remove
// this note
// If a script is used, complete with the script information
This version of this YANG module was generated from the
corresponding IANA registry using a <script-info>.
// RFC Ed.: replace the IANA_FOO_URL and remove this note
The latest version of this YANG module is available at
<IANA_FOO_URL>.";
// replace with the registry name and the URL of the IANA registry
reference
"Registry Name (URL)";
// replace 'date-revision' with the module publication date
// the format is (YYYY-MM-DD)
revision date-revision {
description
"Indicates the list of changes per Section 4.30.3 of RFC 9907";
reference
"URL of the latest version of the module
(if any) list the authoritative event (e.g., RFC) that
triggered the update to the YANG module";
}
// replace 'date-initial' with the module publication date
// the format is (YYYY-MM-DD)
revision date-initial {
description
"Initial version.";
reference
"URL of the published initial version of the module
RFC IIII: RFC Title";
// RFC Ed.: Update with the RFC number and title
// of the RFC that defined the initial version of
// the module and remove this note
}
// identity statements
// typedef statements
}
Thanks to Jürgen Schönwälder and Ladislav Lhotka for the discussion and valuable comments. Special thanks to Ladislav Lhotka for sharing more context that led to the design documented in [RFC9108].
議論と貴重なコメントをくださった Jürgen Schönwälder 氏と Ladislav Lhotka 氏に感謝します。[RFC9108] で文書化された設計につながったコンテキストをさらに共有してくれた Ladislav Lhotka に特に感謝します。
Thanks to Italo Busi, Benoît Claise, Tom Petch, Randy Presuhn, Martin Björklund, Acee Lindem, Dale R. Worley, Kent Watsen, Jan Lindblad, Qiufang Ma, Mahesh Jethanandani, Robert Wilton, and Thomas Fossati for the comments.
コメントをくださった Italo Busi、Benoit Claise、Tom Petch、Randy Presuhn、Martin Björklund、Acee Lindem、Dale R. Worley、Kent Watsen、Jan Lindblad、Qiufang Ma、Mahesh Jethanandani、Robert Wilton、および Thomas Fossati に感謝します。
Lou Berger suggested to include more details about IANA considerations.
Lou Berger は、IANA の考慮事項についてさらに詳細を含めることを提案しました。
Section 4.28 is inspired by [RFC8819].
セクション 4.28 は [RFC8819] に触発されています。
Michal Vaško reported an inconsistency in Sections 4.6.2 and 4.6.4 of [RFC8407].
Michal Vaško は、[RFC8407] のセクション 4.6.2 と 4.6.4 に矛盾があると報告しました。
Thanks to Xufeng Liu for reviewing the document, including providing YANGDOCTORS reviews.
YANGDOCTORS のレビューを提供するなど、ドキュメントをレビューしてくださった Xufeng Liu に感謝します。
Italo Busi provided the examples of "case + when" construct.
Italo Busi は、「case + when」構造の例を提供しました。
Thanks to Rich Salz and Michael Richardson for the SAAG review.
SAAG レビューについては、Rich Salz と Michael Richardson に感謝します。
Kent Watsen contributed text to the security and IANA-maintained YANG module templates.
Kent Watsen は、セキュリティおよび IANA が管理する YANG モジュール テンプレートにテキストを提供しました。
Special thanks to Amanda Baber for the thoughtful and careful review of the document.
文書を思慮深く慎重にレビューしてくださった Amanda Baber に心より感謝いたします。
Thanks to Qiufang Ma for the careful shepherd review.
注意深く羊飼いのレビューをしてくれた Qiufang Ma に感謝します。
Thanks to Acee Lindem for triggering the discussion on data model versus module.
データ モデルとモジュールに関する議論のきっかけを作ってくれた Acee Lindem に感謝します。
Thanks to Mahesh Jethanandani for the thoughtful AD review.
思慮深いADレビューをしてくれたMahesh Jethanandaniに感謝します。
Thanks to Christer Holmberg for the genart review, Jean Mahoney for the check on RPC implications, Ralf Weber for the dnsdir, Giuseppe Fioccola for the opsdir review, Joseph Touch for the tsvart review, and Yoav Nir for the secdir review.
genart レビューの Christer Holmberg、RPC への影響のチェックについて Jean Mahoney、dnsdir の Ralf Weber、opsdir レビューの Giuseppe Fioccola、tsvart レビューの Joseph Touch、secdir レビューの Yoav Nir に感謝します。
Thanks Éric Vyncke, Mike Bishop, Roman Danyliw, Orie Steele, Ketan Talaulikar, Deb Cooley, and Gorry Fairhurst for the IESG review.
IESG レビューにご協力いただいた Éric Vyncke、Mike Bishop、Roman Danyliw、Orie Steele、Ketan Talaulikar、Deb Cooley、Gorry Fairhurst に感謝します。
The author of RFC 8407:
RFC 8407 の作成者:
Andy Bierman
YumaWorks
Email: andy@yumaworks.com
Acknowledgments from RFC 8407:
RFC 8407 からの謝辞:
The structure and contents of this document are adapted from "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181], by C. M. Heard.
この文書の構造と内容は、C. M. Heard による「MIB 文書の作成者およびレビュー担当者のためのガイドライン」[RFC4181] から引用されています。
The working group thanks Martin Bjorklund, Juergen Schoenwaelder, Ladislav Lhotka, Jernej Tuljak, Lou Berger, Robert Wilton, Kent Watsen, and William Lupton for their extensive reviews and contributions to this document.
作業グループは、この文書に対する広範なレビューと貢献に対して Martin Bjorklund、Juergen Schoenwaelder、Ladislav Lhotka、Jernej Tuljak、Lou Berger、Robert Wilton、Kent Watsen、および William Lupton に感謝します。
Andy Bierman
YumaWorks
United States of America
Email: andy@yumaworks.com
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Qin Wu
Huawei
China
Email: bill.wu@huawei.com