[要約] RFC 6020は、NETCONFのためのデータモデリング言語であるYANGについての規格です。YANGは、ネットワーク構成のプロトコルを効果的にモデリングするために使用されます。目的は、ネットワーク機器の設定と管理を容易にすることです。
Internet Engineering Task Force (IETF) M. Bjorklund, Ed.
Request for Comments: 6020 Tail-f Systems
Category: Standards Track October 2010
ISSN: 2070-1721
YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語
Abstract
概要
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
Yangは、ネットワーク構成プロトコル（NetConf）、NetConfリモートプロシージャコール、およびNetConf通知によって操作された構成と状態データをモデル化するために使用されるデータモデリング言語です。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6020.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6020で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................8
2. Keywords ........................................................8
3. Terminology .....................................................8
3.1. Mandatory Nodes ...........................................10
4. YANG Overview ..................................................11
4.1. Functional Overview .......................................11
4.2. Language Overview .........................................13
4.2.1. Modules and Submodules .............................13
4.2.2. Data Modeling Basics ...............................13
4.2.3. State Data .........................................18
4.2.4. Built-In Types .....................................18
4.2.5. Derived Types (typedef) ............................19
4.2.6. Reusable Node Groups (grouping) ....................20
4.2.7. Choices ............................................21
4.2.8. Extending Data Models (augment) ....................22
4.2.9. RPC Definitions ....................................23
4.2.10. Notification Definitions ..........................24
5. Language Concepts ..............................................25
5.1. Modules and Submodules ....................................25
5.1.1. Import and Include by Revision .....................26
5.1.2. Module Hierarchies .................................27
5.2. File Layout ...............................................28
5.3. XML Namespaces ............................................29
5.3.1. YANG XML Namespace .................................29
5.4. Resolving Grouping, Type, and Identity Names ..............29
5.5. Nested Typedefs and Groupings .............................29
5.6. Conformance ...............................................30
5.6.1. Basic Behavior .....................................31
5.6.2. Optional Features ..................................31
5.6.3. Deviations .........................................31
5.6.4. Announcing Conformance Information in the
<hello> Message ....................................32
5.7. Data Store Modification ...................................34
6. YANG Syntax ....................................................34
6.1. Lexical Tokenization ......................................34
6.1.1. Comments ...........................................34
6.1.2. Tokens .............................................34
6.1.3. Quoting ............................................35
6.2. Identifiers ...............................................36
6.2.1. Identifiers and Their Namespaces ...................36
6.3. Statements ................................................37
6.3.1. Language Extensions ................................37
6.4. XPath Evaluations .........................................38
6.4.1. XPath Context ......................................38
6.5. Schema Node Identifier ....................................39
7. YANG Statements ................................................39
7.1. The module Statement ......................................39
7.1.1. The module's Substatements .........................41
7.1.2. The yang-version Statement .........................41
7.1.3. The namespace Statement ............................42
7.1.4. The prefix Statement ...............................42
7.1.5. The import Statement ...............................42
7.1.6. The include Statement ..............................43
7.1.7. The organization Statement .........................44
7.1.8. The contact Statement ..............................44
7.1.9. The revision Statement .............................44
7.1.10. Usage Example .....................................45
7.2. The submodule Statement ...................................46
7.2.1. The submodule's Substatements ......................48
7.2.2. The belongs-to Statement ...........................48
7.2.3. Usage Example ......................................49
7.3. The typedef Statement .....................................49
7.3.1. The typedef's Substatements ........................50
7.3.2. The typedef's type Statement .......................50
7.3.3. The units Statement ................................50
7.3.4. The typedef's default Statement ....................50
7.3.5. Usage Example ......................................51
7.4. The type Statement ........................................51
7.4.1. The type's Substatements ...........................51
7.5. The container Statement ...................................51
7.5.1. Containers with Presence ...........................52
7.5.2. The container's Substatements ......................53
7.5.3. The must Statement .................................53
7.5.4. The must's Substatements ...........................55
7.5.5. The presence Statement .............................56
7.5.6. The container's Child Node Statements ..............56
7.5.7. XML Mapping Rules ..................................56
7.5.8. NETCONF <edit-config> Operations ...................56
7.5.9. Usage Example ......................................57
7.6. The leaf Statement ........................................58
7.6.1. The leaf's default value ...........................58
7.6.2. The leaf's Substatements ...........................59
7.6.3. The leaf's type Statement ..........................59
7.6.4. The leaf's default Statement .......................59
7.6.5. The leaf's mandatory Statement .....................60
7.6.6. XML Mapping Rules ..................................60
7.6.7. NETCONF <edit-config> Operations ...................60
7.6.8. Usage Example ......................................61
7.7. The leaf-list Statement ...................................62
7.7.1. Ordering ...........................................62
7.7.2. The leaf-list's Substatements ......................63
7.7.3. The min-elements Statement .........................63
7.7.4. The max-elements Statement .........................63
7.7.5. The ordered-by Statement ...........................64
7.7.6. XML Mapping Rules ..................................64
7.7.7. NETCONF <edit-config> Operations ...................65
7.7.8. Usage Example ......................................66
7.8. The list Statement ........................................67
7.8.1. The list's Substatements ...........................68
7.8.2. The list's key Statement ...........................68
7.8.3. The list's unique Statement ........................69
7.8.4. The list's Child Node Statements ...................70
7.8.5. XML Mapping Rules ..................................70
7.8.6. NETCONF <edit-config> Operations ...................71
7.8.7. Usage Example ......................................72
7.9. The choice Statement ......................................75
7.9.1. The choice's Substatements .........................76
7.9.2. The choice's case Statement ........................76
7.9.3. The choice's default Statement .....................77
7.9.4. The choice's mandatory Statement ...................79
7.9.5. XML Mapping Rules ..................................79
7.9.6. NETCONF <edit-config> Operations ...................79
7.9.7. Usage Example ......................................79
7.10. The anyxml Statement .....................................80
7.10.1. The anyxml's Substatements ........................81
7.10.2. XML Mapping Rules .................................81
7.10.3. NETCONF <edit-config> Operations ..................81
7.10.4. Usage Example .....................................82
7.11. The grouping Statement ...................................82
7.11.1. The grouping's Substatements ......................83
7.11.2. Usage Example .....................................84
7.12. The uses Statement .......................................84
7.12.1. The uses's Substatements ..........................85
7.12.2. The refine Statement ..............................85
7.12.3. XML Mapping Rules .................................86
7.12.4. Usage Example .....................................86
7.13. The rpc Statement ........................................87
7.13.1. The rpc's Substatements ...........................88
7.13.2. The input Statement ...............................88
7.13.3. The output Statement ..............................89
7.13.4. XML Mapping Rules .................................90
7.13.5. Usage Example .....................................91
7.14. The notification Statement ...............................91
7.14.1. The notification's Substatements ..................92
7.14.2. XML Mapping Rules .................................92
7.14.3. Usage Example .....................................93
7.15. The augment Statement ....................................93
7.15.1. The augment's Substatements .......................94
7.15.2. XML Mapping Rules .................................94
7.15.3. Usage Example .....................................95
7.16. The identity Statement ...................................97
7.16.1. The identity's Substatements ......................97
7.16.2. The base Statement ................................97
7.16.3. Usage Example .....................................98
7.17. The extension Statement ..................................98
7.17.1. The extension's Substatements .....................99
7.17.2. The argument Statement ............................99
7.17.3. Usage Example ....................................100
7.18. Conformance-Related Statements ..........................100
7.18.1. The feature Statement ............................100
7.18.2. The if-feature Statement .........................102
7.18.3. The deviation Statement ..........................102
7.19. Common Statements .......................................105
7.19.1. The config Statement .............................105
7.19.2. The status Statement .............................105
7.19.3. The description Statement ........................106
7.19.4. The reference Statement ..........................106
7.19.5. The when Statement ...............................107
8. Constraints ...................................................108
8.1. Constraints on Data ......................................108
8.2. Hierarchy of Constraints .................................109
8.3. Constraint Enforcement Model .............................109
8.3.1. Payload Parsing ...................................109
8.3.2. NETCONF <edit-config> Processing ..................110
8.3.3. Validation ........................................111
9. Built-In Types ................................................111
9.1. Canonical Representation .................................112
9.2. The Integer Built-In Types ...............................112
9.2.1. Lexical Representation ............................113
9.2.2. Canonical Form ....................................114
9.2.3. Restrictions ......................................114
9.2.4. The range Statement ...............................114
9.2.5. Usage Example .....................................115
9.3. The decimal64 Built-In Type ..............................115
9.3.1. Lexical Representation ............................115
9.3.2. Canonical Form ....................................115
9.3.3. Restrictions ......................................116
9.3.4. The fraction-digits Statement .....................116
9.3.5. Usage Example .....................................117
9.4. The string Built-In Type .................................117
9.4.1. Lexical Representation ............................117
9.4.2. Canonical Form ....................................117
9.4.3. Restrictions ......................................117
9.4.4. The length Statement ..............................117
9.4.5. Usage Example .....................................118
9.4.6. The pattern Statement .............................119
9.4.7. Usage Example .....................................119
9.5. The boolean Built-In Type ................................120
9.5.1. Lexical Representation ............................120
9.5.2. Canonical Form ....................................120
9.5.3. Restrictions ......................................120
9.6. The enumeration Built-In Type ............................120
9.6.1. Lexical Representation ............................120
9.6.2. Canonical Form ....................................120
9.6.3. Restrictions ......................................120
9.6.4. The enum Statement ................................120
9.6.5. Usage Example .....................................121
9.7. The bits Built-In Type ...................................122
9.7.1. Restrictions ......................................122
9.7.2. Lexical Representation ............................122
9.7.3. Canonical Form ....................................122
9.7.4. The bit Statement .................................122
9.7.5. Usage Example .....................................123
9.8. The binary Built-In Type .................................123
9.8.1. Restrictions ......................................124
9.8.2. Lexical Representation ............................124
9.8.3. Canonical Form ....................................124
9.9. The leafref Built-In Type ................................124
9.9.1. Restrictions ......................................124
9.9.2. The path Statement ................................124
9.9.3. Lexical Representation ............................125
9.9.4. Canonical Form ....................................125
9.9.5. Usage Example .....................................126
9.10. The identityref Built-In Type ...........................129
9.10.1. Restrictions .....................................129
9.10.2. The identityref's base Statement .................129
9.10.3. Lexical Representation ...........................130
9.10.4. Canonical Form ...................................130
9.10.5. Usage Example ....................................130
9.11. The empty Built-In Type .................................131
9.11.1. Restrictions .....................................131
9.11.2. Lexical Representation ...........................131
9.11.3. Canonical Form ...................................131
9.11.4. Usage Example ....................................131
9.12. The union Built-In Type .................................132
9.12.1. Restrictions .....................................132
9.12.2. Lexical Representation ...........................132
9.12.3. Canonical Form ...................................133
9.13. The instance-identifier Built-In Type ...................133
9.13.1. Restrictions .....................................134
9.13.2. The require-instance Statement ...................134
9.13.3. Lexical Representation ...........................134
9.13.4. Canonical Form ...................................134
9.13.5. Usage Example ....................................134
10. Updating a Module ............................................135
11. YIN ..........................................................137
11.1. Formal YIN Definition ...................................137
11.1.1. Usage Example ....................................141
12. YANG ABNF Grammar ............................................143
13. Error Responses for YANG Related Errors ......................165
13.1. Error Message for Data That Violates a unique
Statement ...............................................165
13.2. Error Message for Data That Violates a
max-elements Statement ..................................165
13.3. Error Message for Data That Violates a
min-elements Statement ..................................165
13.4. Error Message for Data That Violates a must Statement ...166
13.5. Error Message for Data That Violates a
require-instance Statement ..............................166
13.6. Error Message for Data That Does Not Match a
leafref Type ............................................166
13.7. Error Message for Data That Violates a mandatory
choice Statement ........................................166
13.8. Error Message for the "insert" Operation ................167
14. IANA Considerations ..........................................167
14.1. Media type application/yang .............................168
14.2. Media type application/yin+xml ..........................169
15. Security Considerations ......................................170
16. Contributors .................................................171
17. Acknowledgements .............................................171
18. References ...................................................171
18.1. Normative References ....................................171
18.2. Informative References ..................................172
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], Section 1.1).
Yangは、ネットワーク構成プロトコル（NetConf）、NetConfリモートプロシージャコール、およびNetConf通知によって操作された構成と状態データをモデル化するために使用されるデータモデリング言語です。Yangは、NetConfの操作層とコンテンツ層をモデル化するために使用されます（NetConf構成プロトコル[RFC4741]、セクション1.1を参照）。
This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in the Extensible Markup Language (XML), and how NETCONF operations are used to manipulate the data.
このドキュメントでは、Yang言語の構文とセマンティクス、Yangモジュールで定義されているデータモデルが拡張可能なマークアップ言語（XML）で表される方法、およびNetConf操作がデータの操作に使用する方法について説明します。
The keywords "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].
キーワードは「必要」、「必要」、「必要」、「shall」、「shall "、" sulld "、" not "、" becommented "、" becomperd "、" "may"、 "optional"、 "optional"このドキュメントでは、BCP 14 [RFC2119]に記載されているように解釈されます。
o anyxml: A data node that can contain an unknown chunk of XML data.
o anyXML：XMLデータの未知のチャンクを含むことができるデータノード。
o augment: Adds new schema nodes to a previously defined schema node.
o Augment：以前に定義されたスキーマノードに新しいスキーマノードを追加します。
o base type: The type from which a derived type was derived, which may be either a built-in type or another derived type.
o ベースタイプ：導出されたタイプが派生したタイプは、組み込み型または別の派生型のいずれかである可能性があります。
o built-in type: A YANG data type defined in the YANG language, such as uint32 or string.
o 組み込みタイプ：UINT32や文字列など、Yang言語で定義されたヤンデータ型。
o choice: A schema node where only one of a number of identified alternatives is valid.
o 選択：識別された代替案の1つだけが有効なスキーマノード。
o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state [RFC4741].
o 構成データ：システムを初期のデフォルト状態から現在の状態[RFC4741]に変換するために必要な書き込み可能なデータのセット。
o conformance: A measure of how accurately a device follows a data model.
o 適合：デバイスがデータモデルにどれだけ正確に従うかの尺度。
o container: An interior data node that exists in at most one instance in the data tree. A container has no value, but rather a set of child nodes.
o コンテナ：データツリーにせいぜい1つのインスタンスに存在するインテリアデータノード。コンテナには価値がありませんが、むしろ一連の子ノードがあります。
o data definition statement: A statement that defines new data nodes. One of container, leaf, leaf-list, list, choice, case, augment, uses, and anyxml.
o データ定義ステートメント：新しいデータノードを定義するステートメント。コンテナ、葉、葉のリスト、リスト、選択、ケース、拡張、使用、およびanyxmlの1つ。
o data model: A data model describes how data is represented and accessed.
o データモデル：データモデルは、データの表現方法とアクセス方法を説明します。
o data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml.
o データノード：データツリーにインスタンス化できるスキーマツリーのノード。容器、葉、葉のリスト、リスト、およびanyxmlの1つ。
o data tree: The instantiated tree of configuration and state data on a device.
o データツリー：デバイス上の構成と状態データのインスタンス化されたツリー。
o derived type: A type that is derived from a built-in type (such as uint32), or another derived type.
o 派生タイプ：組み込み型（UINT32など）または別の派生型から派生したタイプ。
o device deviation: A failure of the device to implement the module faithfully.
o デバイスの偏差：デバイスがモジュールを忠実に実装できなかったこと。
o extension: An extension attaches non-YANG semantics to statements. The extension statement defines new statements to express these semantics.
o 拡張：拡張機能は、非ヤンのセマンティクスをステートメントに添付します。拡張ステートメントは、これらのセマンティクスを表現するための新しいステートメントを定義します。
o feature: A mechanism for marking a portion of the model as optional. Definitions can be tagged with a feature name and are only valid on devices that support that feature.
o 機能：モデルの一部をオプションとしてマークするメカニズム。定義は機能名でタグ付けでき、その機能をサポートするデバイスでのみ有効です。
o grouping: A reusable set of schema nodes, which may be used locally in the module, in modules that include it, and by other modules that import from it. The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
o グループ化：モジュールでローカルに使用できるスキーマノードの再利用可能なセット、それを含むモジュール、およびそこからインポートする他のモジュールで使用できます。グループ化ステートメントはデータ定義ステートメントではなく、スキーマツリーのノードを定義しません。
o identifier: Used to identify different kinds of YANG items by name.
o 識別子：名前で異なる種類のYangアイテムを識別するために使用されます。
o instance identifier: A mechanism for identifying a particular node in a data tree.
o インスタンス識別子：データツリー内の特定のノードを識別するメカニズム。
o interior node: Nodes within a hierarchy that are not leaf nodes.
o 内部ノード：葉のノードではない階層内のノード。
o leaf: A data node that exists in at most one instance in the data tree. A leaf has a value but no child nodes.
o リーフ：データツリーにせいぜい1つのインスタンスに存在するデータノード。葉には値がありますが、子ノードはありません。
o leaf-list: Like the leaf node but defines a set of uniquely identifiable nodes rather than a single node. Each node has a value but no child nodes.
o リーフリスト：リーフノードのように、単一のノードではなく、一意に識別可能なノードのセットを定義します。各ノードには値がありますが、子ノードはありません。
o list: An interior data node that may exist in multiple instances in the data tree. A list has no value, but rather a set of child nodes.
o リスト：データツリーの複数のインスタンスで存在する可能性のあるインテリアデータノード。リストには価値がありませんが、むしろ一連の子ノードがあります。
o module: A YANG module defines a hierarchy of nodes that can be used for NETCONF-based operations. With its definitions and the definitions it imports or includes from elsewhere, a module is self-contained and "compilable".
o モジュール：Yangモジュールは、NetConfベースの操作に使用できるノードの階層を定義します。その定義とそれがインポートまたは他の場所から含む定義により、モジュールは自己完結型で「編集可能」です。
o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
o RPC：NetConfプロトコル内で使用されるリモート手順コール。
o RPC operation: A specific Remote Procedure Call, as used within the NETCONF protocol. It is also called a protocol operation.
o RPC操作：NetConfプロトコル内で使用される特定のリモートプロシージャコール。また、プロトコル操作とも呼ばれます。
o schema node: A node in the schema tree. One of container, leaf, leaf-list, list, choice, case, rpc, input, output, notification, and anyxml.
o スキーマノード：スキーマツリーのノード。コンテナ、葉、葉のリスト、リスト、選択、ケース、RPC、入力、出力、通知、およびAnyXMLの1つ。
o schema node identifier: A mechanism for identifying a particular node in the schema tree.
o スキーマノード識別子：スキーマツリー内の特定のノードを識別するメカニズム。
o schema tree: The definition hierarchy specified within a module.
o スキーマツリー：モジュール内で指定された定義階層。
o state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics [RFC4741].
o 状態データ：読み取り専用のステータス情報や収集された統計[RFC4741]などの構成データではないシステム上の追加データ。
o submodule: A partial module definition that contributes derived types, groupings, data nodes, RPCs, and notifications to a module. A YANG module can be constructed from a number of submodules.
o サブモジュール：モジュールへの派生タイプ、グループ化、データノード、RPC、通知に寄与する部分モジュール定義。ヤンモジュールは、多くのサブモジュールから構築できます。
o top-level data node: A data node where there is no other data node between it and a module or submodule statement.
o トップレベルのデータノード：モジュールまたはサブモジュールステートメントの間に他のデータノードがないデータノード。
o uses: The "uses" statement is used to instantiate the set of schema nodes defined in a grouping statement. The instantiated nodes may be refined and augmented to tailor them to any specific needs.
o 使用：「使用」ステートメントは、グループ化ステートメントで定義されている一連のスキーマノードをインスタンス化するために使用されます。インスタンス化されたノードは、特定のニーズに合わせて調整するために洗練され、増強される場合があります。
A mandatory node is one of:
必須ノードは次のとおりです。
o A leaf, choice, or anyxml node with a "mandatory" statement with the value "true".
o 値「true」の「必須」ステートメントを備えた葉、選択、またはanyxmlノード。
o A list or leaf-list node with a "min-elements" statement with a value greater than zero.
o ゼロを超える値を持つ「ミニエレメント」ステートメントを備えたリストまたはリーフリストノード。
o A container node without a "presence" statement, which has at least one mandatory node as a child.
o 「存在」ステートメントのないコンテナノード。これには、子供として少なくとも1つの必須ノードがあります。
YANG is a language used to model data for the NETCONF protocol. A YANG module defines a hierarchy of data that can be used for NETCONF-based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data sent between a NETCONF client and server.
Yangは、NetConfプロトコルのデータをモデル化するために使用される言語です。Yangモジュールは、構成、状態データ、リモート手順呼び出し（RPC）、通知など、NetConfベースの操作に使用できるデータの階層を定義します。これにより、NetConfクライアントとサーバー間で送信されるすべてのデータを完全に説明できます。
YANG models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes. YANG provides clear and concise descriptions of the nodes, as well as the interaction between those nodes.
Yangは、データの階層構成を、各ノードに名前を持っているツリーとして、値または子ノードのセットとしてモデル化します。Yangは、ノードの明確で簡潔な説明と、それらのノード間の相互作用を提供します。
YANG structures data models into modules and submodules. A module can import data from other external modules, and include data from submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation can be conditional, with new nodes appearing only if certain conditions are met.
Yangはデータモデルをモジュールとサブモジュールに構造化します。モジュールは、他の外部モジュールからデータをインポートし、サブモジュールからのデータを含めることができます。階層を増強することができ、1つのモジュールが別のモジュールで定義されている階層にデータノードを追加できるようにします。この増強は条件付きであり、特定の条件が満たされた場合にのみ新しいノードが表示されます。
YANG models can describe constraints to be enforced on the data, restricting the appearance or value of nodes based on the presence or value of other nodes in the hierarchy. These constraints are enforceable by either the client or the server, and valid content MUST abide by them.
Yangモデルは、階層内の他のノードの存在または値に基づいてノードの外観または値を制限し、データに施行される制約を記述できます。これらの制約は、クライアントまたはサーバーのいずれかによって強制力があり、有効なコンテンツがそれらを順守する必要があります。
YANG defines a set of built-in types, and has a type mechanism through which additional types may be defined. Derived types can restrict their base type's set of valid values using mechanisms like range or pattern restrictions that can be enforced by clients or servers. They can also define usage conventions for use of the derived type, such as a string-based type that contains a host name.
Yangは、組み込みのタイプのセットを定義し、追加のタイプを定義できるタイプメカニズムを備えています。派生タイプは、クライアントやサーバーが実施できる範囲やパターン制限などのメカニズムを使用して、ベースタイプの有効な値のセットを制限できます。また、ホスト名を含む文字列ベースのタイプなど、派生タイプを使用するための使用規則を定義することもできます。
YANG permits the definition of reusable groupings of nodes. The instantiation of these groupings can refine or augment the nodes, allowing it to tailor the nodes to its particular needs. Derived types and groupings can be defined in one module or submodule and used in either that location or in another module or submodule that imports or includes it.
Yangは、ノードの再利用可能なグループの定義を許可します。これらのグループのインスタンス化により、ノードを改良または拡張することができ、特定のニーズに合わせてノードを調整できます。派生したタイプとグループは、1つのモジュールまたはサブモジュールで定義し、その場所またはインポートまたは含める別のモジュールまたはサブモジュールで使用できます。
YANG data hierarchy constructs include defining lists where list entries are identified by keys that distinguish them from each other. Such lists may be defined as either sorted by user or automatically sorted by the system. For user-sorted lists, operations are defined for manipulating the order of the list entries.
Yang Data階層構造には、リストのエントリが互いに区別するキーによって識別されるリストの定義が含まれます。このようなリストは、ユーザーによってソートされたものとして定義されるか、システムによって自動的にソートされます。ユーザーが使用したリストの場合、リストエントリの順序を操作するための操作が定義されています。
YANG modules can be translated into an equivalent XML syntax called YANG Independent Notation (YIN) (Section 11), allowing applications using XML parsers and Extensible Stylesheet Language Transformations (XSLT) scripts to operate on the models. The conversion from YANG to YIN is lossless, so content in YIN can be round-tripped back into YANG.
Yangモジュールは、Yang Independent Notation（Yin）（セクション11）と呼ばれる同等のXML構文に翻訳でき、XMLパーサーと拡張可能なスタイルシート言語変換（XSLT）スクリプトを使用してモデルで動作させることができます。ヤンから陰陽への変換はロスレスであるため、陰のコンテンツはヤンに戻って往復することができます。
YANG strikes a balance between high-level data modeling and low-level bits-on-the-wire encoding. The reader of a YANG module can see the high-level view of the data model while understanding how the data will be encoded in NETCONF operations.
Yangは、高レベルのデータモデリングとワイヤーの低レベルのビットエンコードのバランスを取ります。Yangモジュールの読者は、NetConf操作でデータがエンコードされる方法を理解しながら、データモデルの高レベルのビューを見ることができます。
YANG is an extensible language, allowing extension statements to be defined by standards bodies, vendors, and individuals. The statement syntax allows these extensions to coexist with standard YANG statements in a natural way, while extensions in a YANG module stand out sufficiently for the reader to notice them.
Yangは拡張可能な言語であり、標準団体、ベンダー、および個人によって拡張ステートメントを定義できるようにします。ステートメント構文により、これらの拡張は自然な方法で標準のヤンステートメントと共存することができ、ヤンモジュールの拡張は読者がそれらに気付くのに十分に際立っています。
YANG resists the tendency to solve all possible problems, limiting the problem space to allow expression of NETCONF data models, not arbitrary XML documents or arbitrary data models. The data models described by YANG are designed to be easily operated upon by NETCONF operations.
Yangは、可能なすべての問題を解決する傾向に抵抗し、問題のある空間を制限して、任意のXMLドキュメントや任意のデータモデルではなく、NetConfデータモデルの表現を許可します。Yangによって説明されているデータモデルは、NetConf操作によって簡単に操作できるように設計されています。
To the extent possible, YANG maintains compatibility with Simple Network Management Protocol's (SNMP's) SMIv2 (Structure of Management Information version 2 [RFC2578], [RFC2579]). SMIv2-based MIB modules can be automatically translated into YANG modules for read-only access. However, YANG is not concerned with reverse translation from YANG to SMIv2.
可能な限り、Yangは、単純なネットワーク管理プロトコル（SNMP）SMIV2（管理情報の構造バージョン2 [RFC2578]、[RFC2579]）との互換性を維持しています。SMIV2ベースのMIBモジュールは、読み取り専用アクセスのためにYangモジュールに自動的に変換できます。ただし、YangはYangからSmiv2への逆翻訳には関心がありません。
Like NETCONF, YANG targets smooth integration with the device's native management infrastructure. This allows implementations to leverage their existing access control mechanisms to protect or expose elements of the data model.
NetConfと同様に、Yangは、デバイスのネイティブ管理インフラストラクチャとのスムーズな統合をターゲットにしています。これにより、実装は既存のアクセス制御メカニズムを活用して、データモデルの要素を保護または公開することができます。
This section introduces some important constructs used in YANG that will aid in the understanding of the language specifics in later sections. This progressive approach handles the inter-related nature of YANG concepts and statements. A detailed description of YANG statements and syntax begins in Section 7.
このセクションでは、後のセクションで言語の詳細の理解を支援するヤンで使用されるいくつかの重要な構成要素を紹介します。この進歩的なアプローチは、ヤンの概念と声明の相互に関連する性質を処理します。Yangステートメントと構文の詳細な説明は、セクション7で始まります。
A module contains three types of statements: module-header statements, revision statements, and definition statements. The module header statements describe the module and give information about the module itself, the revision statements give information about the history of the module, and the definition statements are the body of the module where the data model is defined.
モジュールには、モジュールヘッダーステートメント、改訂ステートメント、および定義ステートメントの3種類のステートメントが含まれています。モジュールヘッダーステートメントはモジュールを説明し、モジュール自体に関する情報を提供し、改訂ステートメントはモジュールの履歴に関する情報を提供し、定義ステートメントはデータモデルが定義されているモジュールの本文です。
A NETCONF server may implement a number of modules, allowing multiple views of the same data, or multiple views of disjoint subsections of the device's data. Alternatively, the server may implement only one module that defines all available data.
NetConfサーバーは、多くのモジュールを実装して、同じデータの複数のビュー、またはデバイスのデータの分離サブセクションの複数のビューを許可する場合があります。または、サーバーは、利用可能なすべてのデータを定義する1つのモジュールのみを実装できます。
A module may be divided into submodules, based on the needs of the module owner. The external view remains that of a single module, regardless of the presence or size of its submodules.
モジュールは、モジュールの所有者のニーズに基づいて、サブモジュールに分割される場合があります。外部ビューは、サブモジュールの存在やサイズに関係なく、単一のモジュールのビューのままです。
The "include" statement allows a module or submodule to reference material in submodules, and the "import" statement allows references to material defined in other modules.
「含まれる」ステートメントは、サブモジュール内のモジュールまたはサブモジュールを参照材料に許可し、「インポート」ステートメントは他のモジュールで定義された材料への参照を許可します。
YANG defines four types of nodes for data modeling. In each of the following subsections, the example shows the YANG syntax as well as a corresponding NETCONF XML representation.
Yangは、データモデリングの4種類のノードを定義します。次の各サブセクションでは、この例はYang構文と対応するNetConf XML表現を示しています。
A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type and no child nodes.
リーフノードには、整数や文字列などの簡単なデータが含まれています。特定のタイプの1つの値と子ノードはありません。
YANG Example:
ヤンの例：
leaf host-name {
type string;
description "Hostname for this system";
}
NETCONF XML Example:
NetConf XMLの例：
<host-name>my.example.com</host-name>
The "leaf" statement is covered in Section 7.6.
「葉」ステートメントはセクション7.6で説明されています。
A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf.
リーフリストは、リーフごとに特定のタイプの1つの値が1つの葉のノードのシーケンスです。
YANG Example:
ヤンの例：
leaf-list domain-search {
type string;
description "List of domain names to search";
}
NETCONF XML Example:
NetConf XMLの例：
<domain-search>high.example.com</domain-search>
<domain-search>low.example.com</domain-search>
<domain-search>everywhere.example.com</domain-search>
The "leaf-list" statement is covered in Section 7.7.
「リーフリスト」ステートメントは、セクション7.7で説明されています。
A container node is used to group related nodes in a subtree. A container has only child nodes and no value. A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists).
コンテナノードは、サブツリーに関連するノードをグループ化するために使用されます。コンテナには子供のノードのみがあり、値はありません。コンテナには、任意のタイプの任意の数の子ノード（葉、リスト、コンテナ、葉のリストを含む）を含むことができます。
YANG Example:
ヤンの例：
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
}
}
NETCONF XML Example:
NetConf XMLの例：
<system>
<login>
<message>Good morning</message>
</login>
</system>
The "container" statement is covered in Section 7.5.
「コンテナ」ステートメントは、セクション7.5で説明されています。
A list defines a sequence of list entries. Each entry is like a structure or a record instance, and is uniquely identified by the values of its key leafs. A list can define multiple key leafs and may contain any number of child nodes of any type (including leafs, lists, containers etc.).
リストは、リストエントリのシーケンスを定義します。各エントリは、構造やレコードインスタンスのようなものであり、そのキーリーフの値によって独自に識別されます。リストは複数のキーリーフを定義でき、任意のタイプの任意の数の子ノード（リーフ、リスト、コンテナなど）を含む場合があります。
YANG Example:
ヤンの例：
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
NETCONF XML Example:
NetConf XMLの例：
<user>
<name>glocks</name>
<full-name>Goldie Locks</full-name>
<class>intruder</class>
</user>
<user>
<name>snowey</name>
<full-name>Snow White</full-name>
<class>free-loader</class>
</user>
<user>
<name>rzell</name>
<full-name>Rapun Zell</full-name>
<class>tower</class>
</user>
The "list" statement is covered in Section 7.8.
「リスト」ステートメントはセクション7.8で説明されています。
These statements are combined to define the module:
これらのステートメントは、モジュールを定義するために組み合わされています。
// Contents of "acme-system.yang" module acme-system { namespace "http://acme.example.com/system"; prefix "acme";
// "acme-system.yang"モジュールacme-system {namespace "http://acme.example.com/system";プレフィックス「acme」;
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
YANG can model state data, as well as configuration data, based on the "config" statement. When a node is tagged with "config false", its subhierarchy is flagged as state data, to be reported using NETCONF's <get> operation, not the <get-config> operation. Parent containers, lists, and key leafs are reported also, giving the context for the state data.
Yangは、「構成」ステートメントに基づいて、状態データと構成データをモデル化できます。ノードが「config false」でタグ付けされると、そのサブハイアラルキーは状態データとしてフラグが付けられ、<get-config>操作ではなく、NetConfの<get>操作を使用して報告されます。親コンテナ、リスト、およびキーリーフも報告されており、状態データのコンテキストが提供されます。
In this example, two leafs are defined for each interface, a configured speed and an observed speed. The observed speed is not configuration, so it can be returned with NETCONF <get> operations, but not with <get-config> operations. The observed speed is not configuration data, and it cannot be manipulated using <edit-config>.
この例では、各インターフェイス、構成された速度と観測速度に対して2つのリーフが定義されています。観測された速度は構成ではないため、netConf <get>操作で返すことができますが、<get-config>操作では返されません。観測された速度は構成データではなく、<edit-config>を使用して操作することはできません。
list interface { key "name";
リストインターフェイス{key "name";
leaf name {
type string;
}
leaf speed {
type enumeration {
enum 10m;
enum 100m;
enum auto;
}
}
leaf observed-speed {
type uint32;
config false;
}
}
YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements from the management domain. The following table summarizes the built-in types discussed in Section 9:
Yangには、多くのプログラミング言語と同様の組み込みタイプのセットがありますが、管理ドメインからの特別な要件によるいくつかの違いがあります。次の表は、セクション9で説明されている組み込みのタイプをまとめたものです。
+---------------------+-------------------------------------+
| Name | Description |
+---------------------+-------------------------------------+
| binary | Any binary data |
| bits | A set of bits or flags |
| boolean | "true" or "false" |
| decimal64 | 64-bit signed decimal number |
| empty | A leaf that does not have any value |
| enumeration | Enumerated strings |
| identityref | A reference to an abstract identity |
| instance-identifier | References a data tree node |
| int8 | 8-bit signed integer |
| int16 | 16-bit signed integer |
| int32 | 32-bit signed integer |
| int64 | 64-bit signed integer |
| leafref | A reference to a leaf instance |
| string | Human-readable string |
| uint8 | 8-bit unsigned integer |
| uint16 | 16-bit unsigned integer |
| uint32 | 32-bit unsigned integer |
| uint64 | 64-bit unsigned integer |
| union | Choice of member types |
+---------------------+-------------------------------------+
The "type" statement is covered in Section 7.4.
「タイプ」ステートメントは、セクション7.4で説明されています。
YANG can define derived types from base types using the "typedef" statement. A base type can be either a built-in type or a derived type, allowing a hierarchy of derived types.
Yangは、「typedef」ステートメントを使用して、ベースタイプから派生タイプを定義できます。ベースタイプは、組み込みタイプまたは派生タイプのいずれかであり、派生型の階層を可能にします。
A derived type can be used as the argument for the "type" statement.
派生タイプは、「タイプ」ステートメントの引数として使用できます。
YANG Example:
ヤンの例：
typedef percent {
type uint8 {
range "0 .. 100";
}
description "Percentage";
}
leaf completed {
type percent;
}
NETCONF XML Example:
NetConf XMLの例：
<completed>20</completed>
The "typedef" statement is covered in Section 7.3.
「typedef」ステートメントは、セクション7.3で説明されています。
Groups of nodes can be assembled into reusable collections using the "grouping" statement. A grouping defines a set of nodes that are instantiated with the "uses" statement:
ノードのグループは、「グループ」ステートメントを使用して再利用可能なコレクションに組み立てることができます。グループ化は、「使用」ステートメントにインスタンス化されたノードのセットを定義します。
grouping target {
leaf address {
type inet:ip-address;
description "Target IP address";
}
leaf port {
type inet:port-number;
description "Target port number";
}
}
container peer {
container destination {
uses target;
}
}
NETCONF XML Example:
NetConf XMLの例：
<peer>
<destination>
<address>192.0.2.1</address>
<port>830</port>
</destination>
</peer>
The grouping can be refined as it is used, allowing certain statements to be overridden. In this example, the description is refined:
グループ化を使用すると洗練することができ、特定のステートメントをオーバーライドできます。この例では、説明は洗練されています。
container connection {
container source {
uses target {
refine "address" {
description "Source IP address";
}
refine "port" {
description "Source port number";
}
}
}
container destination {
uses target {
refine "address" {
description "Destination IP address";
}
refine "port" {
description "Destination port number";
}
}
}
}
The "grouping" statement is covered in Section 7.11.
「グループ化」ステートメントは、セクション7.11で説明されています。
YANG allows the data model to segregate incompatible nodes into distinct choices using the "choice" and "case" statements. The "choice" statement contains a set of "case" statements that define sets of schema nodes that cannot appear together. Each "case" may contain multiple nodes, but each node may appear in only one "case" under a "choice".
Yangを使用すると、データモデルは、「選択」と「ケース」ステートメントを使用して、互換性のないノードを明確な選択肢に分離できます。「選択」ステートメントには、一緒に表示できないスキーマノードのセットを定義する「ケース」ステートメントのセットが含まれています。各「ケース」には複数のノードが含まれている場合がありますが、各ノードは「選択」の下に「1つのケース」のみに表示される場合があります。
When an element from one case is created, all elements from all other cases are implicitly deleted. The device handles the enforcement of the constraint, preventing incompatibilities from existing in the configuration.
1つのケースからの要素が作成されると、他のすべてのケースのすべての要素が暗黙的に削除されます。デバイスは制約の施行を処理し、構成に互換性が存在するのを防ぎます。
The choice and case nodes appear only in the schema tree, not in the data tree or NETCONF messages. The additional levels of hierarchy are not needed beyond the conceptual schema.
選択ノードとケースノードは、スキーマツリーにのみ表示され、データツリーまたはネットコンメッセージには表示されません。階層の追加レベルは、概念スキーマ以外には必要ありません。
YANG Example:
ヤンの例：
container food {
choice snack {
case sports-arena {
leaf pretzel {
type empty;
}
leaf beer {
type empty;
}
}
case late-night {
leaf chocolate {
type enumeration {
enum dark;
enum milk;
enum first-available;
}
}
}
}
}
NETCONF XML Example:
NetConf XMLの例：
<food>
<pretzel/>
<beer/>
</food>
The "choice" statement is covered in Section 7.9.
「選択」ステートメントはセクション7.9で説明されています。
YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. This is useful for example for vendors to add vendor-specific parameters to standard data models in an interoperable way.
Yangを使用すると、モジュールは、現在のモジュール（およびそのサブモジュール）または外部モジュールの両方を含むデータモデルに追加のノードを挿入できます。これは、たとえば、ベンダーが相互運用可能な方法でベンダー固有のパラメーターを標準データモデルに追加するのに役立ちます。
The "augment" statement defines the location in the data model hierarchy where new nodes are inserted, and the "when" statement defines the conditions when the new nodes are valid.
「Augment」ステートメントは、新しいノードが挿入されるデータモデルの階層の場所と、新しいノードが有効なときの条件を「条件」と定義する「」の位置を定義します。
YANG Example:
ヤンの例：
augment /system/login/user {
when "class != 'wheel'";
leaf uid {
type uint16 {
range "1000 .. 30000";
}
}
}
This example defines a "uid" node that only is valid when the user's "class" is not "wheel".
この例は、ユーザーの「クラス」が「ホイール」ではない場合にのみ有効な「UID」ノードを定義します。
If a module augments another module, the XML representation of the data will reflect the prefix of the augmenting module. For example, if the above augmentation were in a module with prefix "other", the XML would look like:
モジュールが別のモジュールを拡張する場合、データのXML表現は、拡張モジュールのプレフィックスを反映します。たとえば、上記の増強が接頭辞「その他」のモジュールにある場合、XMLは次のようになります。
NETCONF XML Example:
NetConf XMLの例：
<user>
<name>alicew</name>
<full-name>Alice N. Wonderland</full-name>
<class>drop-out</class>
<other:uid>1024</other:uid>
</user>
The "augment" statement is covered in Section 7.15.
「Augment」ステートメントは、セクション7.15で説明されています。
YANG allows the definition of NETCONF RPCs. The operations' names, input parameters, and output parameters are modeled using YANG data definition statements.
Yangは、NetConf RPCの定義を許可します。操作の名前、入力パラメーター、および出力パラメーターは、Yangデータ定義ステートメントを使用してモデル化されます。
YANG Example:
ヤンの例：
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}
NETCONF XML Example:
NetConf XMLの例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://acme.example.com/system">
<image-name>acmefw-2.3</image-name>
</activate-software-image>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://acme.example.com/system">
The image acmefw-2.3 is being installed.
</status>
</rpc-reply>
The "rpc" statement is covered in Section 7.13.
「RPC」ステートメントは、セクション7.13で説明されています。
YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the content of the notification.
Yangは、NetConfに適した通知の定義を許可します。Yangデータ定義ステートメントは、通知の内容をモデル化するために使用されます。
YANG Example:
ヤンの例：
notification link-failure {
description "A link failure has been detected";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf if-admin-status {
type admin-status;
}
leaf if-oper-status {
type oper-status;
}
}
NETCONF XML Example:
NetConf XMLの例：
<notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system">
<if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status>
</link-failure>
</notification>
The "notification" statement is covered in Section 7.14.
「通知」ステートメントは、セクション7.14で説明されています。
The module is the base unit of definition in YANG. A module defines a single data model. A module can define a complete, cohesive model, or augment an existing data model with additional nodes.
モジュールは、ヤンの定義のベース単位です。モジュールは単一のデータモデルを定義します。モジュールは、完全で結束力のあるモデルを定義したり、追加のノードを使用して既存のデータモデルを拡張したりできます。
Submodules are partial modules that contribute definitions to a module. A module may include any number of submodules, but each submodule may belong to only one module.
サブモジュールは、モジュールに定義を提供する部分モジュールです。モジュールには任意の数のサブモジュールが含まれる場合がありますが、各サブモジュールは1つのモジュールのみに属している場合があります。
The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name.
すべての標準モジュールとサブモジュールの名前は一意でなければなりません。エンタープライズモジュールの開発者は、モジュール名のプレフィックスとしてエンタープライズまたは組織名を使用することにより、標準モジュールや他のエンタープライズモジュールと衝突する可能性が低いモジュールの名前を選択することをお勧めします。
A module uses the "include" statement to include its submodules, and the "import" statement to reference external modules. Similarly, a submodule uses the "import" statement to reference other modules, and uses the "include" statement to reference other submodules within its module. A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module.
モジュールは、「含める」ステートメントを使用してサブモジュールを含め、「インポート」ステートメントを参照する外部モジュールを参照します。同様に、サブモジュールは「インポート」ステートメントを使用して他のモジュールを参照し、「含める」ステートメントを使用してモジュール内の他のサブモジュールを参照します。モジュールまたはサブモジュールには、他のモジュールからのサブモジュールを含めるべきではなく、サブモジュールは独自のモジュールをインポートしてはなりません。
The import and include statements are used to make definitions available to other modules and submodules:
インポートおよびインクルードステートメントは、他のモジュールやサブモジュールで定義を利用できるようにするために使用されます。
o For a module or submodule to reference definitions in an external module, the external module MUST be imported.
o モジュールまたはサブモジュールが外部モジュールで定義を参照する場合、外部モジュールをインポートする必要があります。
o For a module to reference definitions in one of its submodules, the module MUST include the submodule.
o サブモジュールの1つで定義を参照するモジュールの場合、モジュールにはサブモジュールを含める必要があります。
o For a submodule to reference definitions in a second submodule of the same module, the first submodule MUST include the second submodule.
o 同じモジュールの2番目のサブモジュールで定義を参照するサブモジュールの場合、最初のサブモジュールには2番目のサブモジュールを含める必要があります。
There MUST NOT be any circular chains of imports or includes. For example, if submodule "a" includes submodule "b", "b" cannot include "a".
輸入の循環チェーンや含まれる循環チェーンがあってはなりません。たとえば、サブモジュール「A」にサブモジュール「B」が含まれる場合、「B」は「A」を含めることはできません。
When a definition in an external module is referenced, a locally defined prefix MUST be used, followed by ":", and then the external identifier. References to definitions in the local module MAY use the prefix notation. Since built-in data types do not belong to any module and have no prefix, references to built-in data types (e.g., int32) cannot use the prefix notation.
外部モジュールの定義が参照される場合、ローカルで定義されたプレフィックスを使用し、その後に「：」、次に外部識別子を使用する必要があります。ローカルモジュールの定義への参照は、プレフィックス表記を使用する場合があります。組み込みのデータ型は任意のモジュールに属しておらず、プレフィックスがないため、内蔵データ型（例：INT32）への参照はプレフィックス表記を使用できません。
Published modules evolve independently over time. In order to allow for this evolution, modules need to be imported using specific revisions. When a module is written, it uses the current revisions of other modules, based on what is available at the time. As future revisions of the imported modules are published, the importing module is unaffected and its contents are unchanged. When the author of the module is prepared to move to the most recently published revision of an imported module, the module is republished with an updated "import" statement. By republishing with the new revision, the authors explicitly indicate their acceptance of any changes in the imported module.
公開されたモジュールは、時間とともに独立して進化します。この進化を可能にするために、特定の改訂を使用してモジュールをインポートする必要があります。モジュールが書かれている場合、当時利用可能なものに基づいて、他のモジュールの現在の改訂を使用します。インポートされたモジュールの将来の改訂が公開されると、インポートモジュールは影響を受けず、その内容は変更されません。モジュールの著者が、インポートされたモジュールの最近公開された改訂に移行する準備ができている場合、モジュールは更新された「インポート」ステートメントで再発行されます。新しい改訂で再発行することにより、著者は、インポートされたモジュールの変更を受け入れることを明示的に示しています。
For submodules, the issue is related but simpler. A module or submodule that includes submodules needs to specify the revision of the included submodules. If a submodule changes, any module or submodule that includes it needs to be updated.
サブモジュールの場合、問題は関連していますが、より簡単です。サブモジュールを含むモジュールまたはサブモジュールは、付属のサブモジュールの改訂を指定する必要があります。サブモジュールが変更された場合、それを含むモジュールまたはサブモジュールを更新する必要があります。
For example, module "b" imports module "a".
たとえば、モジュール「B」はモジュール「A」をインポートします。
module a {
revision 2008-01-01 { ... }
grouping a {
leaf eh { .... }
}
}
module b {
import a {
prefix p;
revision-date 2008-01-01;
}
container bee {
uses p:a;
}
}
When the author of "a" publishes a new revision, the changes may not be acceptable to the author of "b". If the new revision is acceptable, the author of "b" can republish with an updated revision in the "import" statement.
「A」の著者が新しい改訂を公開する場合、「B」の著者に変更が受け入れられない場合があります。新しい改訂が許容される場合、「B」の著者は、「インポート」ステートメントで更新された改訂で再発行できます。
YANG allows modeling of data in multiple hierarchies, where data may have more than one top-level node. Models that have multiple top-level nodes are sometimes convenient, and are supported by YANG.
Yangを使用すると、データのモデリングが複数の階層でモデリングを許可します。ここでは、データには複数のトップレベルノードがある場合があります。複数のトップレベルノードを持つモデルは、便利な場合があり、Yangによってサポートされています。
NETCONF is capable of carrying any XML content as the payload in the <config> and <data> elements. The top-level nodes of YANG modules are encoded as child elements, in any order, within these elements. This encapsulation guarantees that the corresponding NETCONF messages are always well-formed XML documents.
NetConfは、XMLコンテンツを<config>および<data>要素のペイロードとして運ぶことができます。Yangモジュールのトップレベルノードは、これらの要素内で、任意の順序で子要素としてエンコードされます。このカプセル化は、対応するNetConfメッセージが常に適切に形成されたXMLドキュメントであることを保証します。
For example:
例えば：
module my-config { namespace "http://example.com/schema/config"; prefix "co";
モジュールmy-config {namespace "http://example.com/schema/config";プレフィックス「Co」;
container system { ... }
container routing { ... }
}
could be encoded in NETCONF as:
ネットコンでエンコードすることができます：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<!-- system data here -->
</system>
<routing xmlns="http://example.com/schema/config">
<!-- routing data here -->
</routing>
</config>
</edit-config>
</rpc>
YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form:
Yangモジュールとサブモジュールは、通常、ファイル、1つのモジュールまたはサブモジュールに保存されます。ファイルの名前はフォームでなければなりません。
module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
module-or-submodule-name ['@' revision-date]（ '.yang' / '.yin'）
YANG compilers can find imported modules and included submodules via this convention. While the YANG language defines modules, tools may compile submodules independently for performance and manageability reasons. Errors and warnings that cannot be detected during submodule compilation may be delayed until the submodules are linked into a cohesive module.
Yangコンパイラは、この規則を通じてインポートされたモジュールを見つけることができ、サブモジュールを含むことができます。Yang Languageはモジュールを定義していますが、ツールはパフォーマンスと管理性の理由で独立してサブモジュールをコンパイルする場合があります。サブモジュールの編集中に検出できないエラーと警告は、サブモジュールがまとまりのあるモジュールにリンクされるまで遅延する場合があります。
All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES], which is a globally unique URI [RFC3986]. A NETCONF client or server uses the namespace during XML encoding of data.
すべてのYang定義は、グローバルに一意のURI [RFC3986]である特定のXMLネームスペース[XML-Names]にバインドされているモジュール内で指定されています。NetConfクライアントまたはサーバーは、データのXMLエンコード中に名前空間を使用します。
Namespaces for modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているモジュールの名前空間は、IANAによって割り当てる必要があります。セクション14を参照してください。
Namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces, for example by using the enterprise or organization name in the namespace.
プライベートモジュールの名前空間は、中央レジストリのないモジュールを所有する組織によって割り当てられます。名前空間URIを選択して、名前空間のエンタープライズまたは組織名を使用して、標準または他のエンタープライズネームスペースと衝突できないようにする必要があります。
The "namespace" statement is covered in Section 7.1.3.
「名前空間」ステートメントは、セクション7.1.3で説明されています。
YANG defines an XML namespace for NETCONF <edit-config> operations and <error-info> content. The name of this namespace is "urn:ietf:params:xml:ns:yang:1".
Yangは、NetConf <edit-config>操作と<Error-info>コンテンツのXML名空間を定義します。この名前空間の名前は「urn：ietf：params：xml：ns：yang：1」です。
Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language.
グループ化、タイプ、およびアイデンティティ名は、使用されるコンテキストではなく、定義されているコンテキストで解決されます。グループ化、typedef、およびIDのユーザーは、モジュールをインポートしたり、サブモジュールを含めて、元の定義で作成されたすべての参照を満たすために必要ではありません。これは、従来のプログラミング言語で静的なスコープのように動作します。
For example, if a module defines a grouping in which a type is referenced, when the grouping is used in a second module, the type is resolved in the context of the original module, not the second module. There is no worry over conflicts if both modules define the type, since there is no ambiguity.
たとえば、モジュールがタイプが参照されるグループを定義する場合、グループ化が2番目のモジュールで使用される場合、タイプは2番目のモジュールではなく元のモジュールのコンテキストで解決されます。あいまいさがないため、両方のモジュールがタイプを定義する場合、競合に心配はありません。
Typedefs and groupings may appear nested under many YANG statements, allowing these to be lexically scoped by the hierarchy under which they appear. This allows types and groupings to be defined near where they are used, rather than placing them at the top level of the hierarchy. The close proximity increases readability.
typedefsとグループ化は、多くのヤンステートメントの下にネストされているように見える場合があり、それらを表示する階層によってこれらを語彙的に範囲にすることができます。これにより、階層の最上位レベルに配置するのではなく、使用されている場所の近くでタイプとグループ化を定義できます。近接性は読みやすさを向上させます。
Scoping also allows types to be defined without concern for naming conflicts between types in different submodules. Type names can be specified without adding leading strings designed to prevent name collisions within large modules.
また、スコーピングにより、異なるサブモジュールのタイプ間の競合を命名することに懸念なくタイプを定義することもできます。タイプ名は、大きなモジュール内の名前の衝突を防ぐために設計された先頭の文字列を追加せずに指定できます。
Finally, scoping allows the module author to keep types and groupings private to their module or submodule, preventing their reuse. Since only top-level types and groupings (i.e., those appearing as substatements to a module or submodule statement) can be used outside the module or submodule, the developer has more control over what pieces of their module are presented to the outside world, supporting the need to hide internal information and maintaining a boundary between what is shared with the outside world and what is kept private.
最後に、スコーピングにより、モジュールの著者は、モジュールまたはサブモジュールのタイプとグループ化をプライベートに保ち、再利用を防ぐことができます。モジュールまたはサブモジュールの外で使用できるのは、トップレベルのタイプとグループ（つまり、モジュールまたはサブモジュールステートメントの代替として表示されるもの）のみを使用するため、開発者はモジュールの一部が外の世界に表示されるものをより制御し、サポートしています。内部情報を隠し、外の世界と共有されているものとプライベートに保たれているものとの境界を維持する必要性。
Scoped definitions MUST NOT shadow definitions at a higher scope. A type or grouping cannot be defined if a higher level in the schema hierarchy has a definition with a matching identifier.
スコープされた定義は、より高い範囲で定義をシャドウ化してはなりません。スキーマ階層のより高いレベルに一致する識別子を使用して定義がある場合、タイプまたはグループ化を定義することはできません。
A reference to an unprefixed type or grouping, or one which uses the prefix of the current module, is resolved by locating the closest matching "typedef" or "grouping" statement among the immediate substatements of each ancestor statement.
再固定されていないタイプまたはグループ化、または現在のモジュールのプレフィックスを使用するものへの参照は、各祖先ステートメントの即時の置換の間に最も近い一致する「typedef」または「グループ化」ステートメントを見つけることにより解決されます。
Conformance is a measure of how accurately a device follows the model. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. Deviations from the model can reduce the utility of the model and increase fragility of applications that use it.
適合は、デバイスがモデルにどれだけ正確に従うかの尺度です。一般的に言えば、デバイスはモデルを忠実に実装する責任があり、モデルを実装するデバイスを同一に実装するデバイスを処理できるようにします。モデルからの逸脱は、モデルの有用性を低下させ、それを使用するアプリケーションの脆弱性を高めることができます。
YANG modelers have three mechanisms for conformance:
Yang Modelersには、適合性のための3つのメカニズムがあります。
o the basic behavior of the model
o モデルの基本的な動作
o optional features that are part of the model
o モデルの一部であるオプションの機能
o deviations from the model
o モデルからの逸脱
We will consider each of these in sequence.
これらのそれぞれを順番に検討します。
The model defines a contract between the NETCONF client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract.
このモデルは、NetConfクライアントとサーバーの間の契約を定義します。これにより、両当事者は、モデル化されたデータの背後にある構文とセマンティクスを他者が知っていると信じることができます。ヤンの強さは、この契約の強さにあります。
In many models, the modeler will allow sections of the model to be conditional. The device controls whether these conditional portions of the model are supported or valid for that particular device.
多くのモデルでは、モデラーがモデルのセクションを条件付きにすることを許可します。デバイスは、モデルのこれらの条件付き部分がその特定のデバイスに対してサポートされているか有効かを制御します。
For example, a syslog data model may choose to include the ability to save logs locally, but the modeler will realize that this is only possible if the device has local storage. If there is no local storage, an application should not tell the device to save logs.
たとえば、Syslogデータモデルには、ログをローカルに保存する機能を含めることができますが、モデラーは、デバイスにローカルストレージがある場合にのみ可能であることを認識します。ローカルストレージがない場合、アプリケーションはログを保存するようにデバイスに指示してはなりません。
YANG supports this conditional mechanism using a construct called "feature". Features give the modeler a mechanism for making portions of the module conditional in a manner that is controlled by the device. The model can express constructs that are not universally present in all devices. These features are included in the model definition, allowing a consistent view and allowing applications to learn which features are supported and tailor their behavior to the device.
Yangは、「特徴」と呼ばれるコンストラクトを使用してこの条件付きメカニズムをサポートしています。機能は、モデルによって制御される方法でモジュールの一部を条件付きにするためのメカニズムを提供します。このモデルは、すべてのデバイスに普遍的に存在しないコンストラクトを表現できます。これらの機能はモデル定義に含まれており、一貫したビューを可能にし、アプリケーションがサポートされている機能を学習し、デバイスに合わせて動作を調整できるようにします。
A module may declare any number of features, identified by simple strings, and may make portions of the module optional based on those features. If the device supports a feature, then the corresponding portions of the module are valid for that device. If the device doesn't support the feature, those parts of the module are not valid, and applications should behave accordingly.
モジュールは、単純な文字列で識別された任意の数の機能を宣言し、それらの機能に基づいてモジュールの一部をオプションにすることができます。デバイスが機能をサポートする場合、モジュールの対応する部分がそのデバイスに有効です。デバイスが機能をサポートしていない場合、モジュールのこれらの部分は有効ではなく、アプリケーションがそれに応じて動作する必要があります。
Features are defined using the "feature" statement. Definitions in the module that are conditional to the feature are noted by the "if-feature" statement with the name of the feature as its argument.
機能は、「機能」ステートメントを使用して定義されています。この機能に条件付けられたモジュール内の定義は、機能の名前を引数として、「if-feature」ステートメントに記載されています。
Further details are available in Section 7.18.1.
詳細については、セクション7.18.1をご覧ください。
In an ideal world, all devices would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, devices are often not able or designed to implement the model as written. For YANG-based automation to deal with these device deviations, a mechanism must exist for devices to inform applications of the specifics of such deviations.
理想的な世界では、すべてのデバイスが定義通りモデルを実装する必要があり、モデルからの逸脱は許可されません。しかし、現実の世界では、デバイスは書面によるモデルを実装することができないことが多い、または設計されていません。Yangベースの自動化がこれらのデバイスの逸脱に対処するためには、そのような逸脱の詳細をアプリケーションに通知するためのデバイスにメカニズムが存在する必要があります。
For example, a BGP module may allow any number of BGP peers, but a particular device may only support 16 BGP peers. Any application configuring the 17th peer will receive an error. While an error may suffice to let the application know it cannot add another peer, it would be far better if the application had prior knowledge of this limitation and could prevent the user from starting down the path that could not succeed.
たとえば、BGPモジュールは任意の数のBGPピアを許可する場合がありますが、特定のデバイスは16のBGPピアのみをサポートできます。17番目のピアを構成するアプリケーションは、エラーを受け取ります。別のピアを追加できないことをアプリケーションに知らせるのにエラーで十分かもしれませんが、アプリケーションにこの制限の事前知識があり、ユーザーが成功できないパスを開始するのを防ぐことができれば、はるかに優れています。
Device deviations are declared using the "deviation" statement, which takes as its argument a string that identifies a node in the schema tree. The contents of the statement details the manner in which the device implementation deviates from the contract as defined in the module.
デバイスの偏差は、「偏差」ステートメントを使用して宣言されます。これは、その引数として、スキーマツリーのノードを識別する文字列を取得します。ステートメントの内容は、モジュールで定義されているように、デバイスの実装が契約から逸脱する方法を詳述しています。
Further details are available in Section 7.18.3.
詳細については、セクション7.18.3をご覧ください。
The namespace URI MUST be advertised as a capability in the NETCONF <hello> message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form:
ネームスペースURIは、NetConfサーバーによるYangモジュールのサポートを示すために、NetConf <Hello>メッセージの機能として宣伝する必要があります。宣伝されているURIの機能は、フォームでなければなりません。
capability-string = namespace-uri [ parameter-list ]
parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter /
module-parameter /
feature-parameter /
deviation-parameter
revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-date" is the revision of the module (see Section 7.1.9) that the NETCONF server implements, "module-name" is the name of module as it appears in the "module" statement (see Section 7.1), "namespace-uri" is the namespace URI for the module as it appears in the "namespace" statement (see Section 7.1.3), "feature" is the name of an optional feature implemented by the device (see Section 7.18.1), and "deviation" is the name of a module defining device deviations (see Section 7.18.3).
ここで、「改訂日」は、NetConfサーバーが実装するモジュールの改訂（セクション7.1.9を参照）です。「モジュール名」は、「モジュール」ステートメント（セクション7.1を参照）に表示されるモジュールの名前です。「Namespace-uri」は、「名前空間」ステートメントに表示されるモジュールの名前空間URIです（セクション7.1.3を参照）、「機能」はデバイスによって実装されたオプション機能の名前です（セクション7.18.1を参照）、および「偏差」とは、デバイスの偏差を定義するモジュールの名前です（セクション7.18.3を参照）。
In the parameter list, each named parameter MUST occur at most once.
パラメーターリストでは、各名前のパラメーターがせいぜい1回発生する必要があります。
Servers indicate the names of supported modules via the <hello> message. Module namespaces are encoded as the base URI in the capability string, and the module name is encoded as the "module" parameter to the base URI.
サーバーは、<hello>メッセージを介してサポートされているモジュールの名前を示します。モジュール名空間は、機能文字列のベースURIとしてエンコードされ、モジュール名はベースURIの「モジュール」パラメーターとしてエンコードされます。
A server MUST advertise all revisions of all modules it implements.
サーバーは、実装するすべてのモジュールのすべての改訂を宣伝する必要があります。
For example, this <hello> message advertises one module "syslog".
たとえば、この<hello>メッセージは1つのモジュール「syslog」を宣伝します。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&revision=2008-04-01
</capability>
</hello>
Servers indicate the names of supported features via the <hello> message. In <hello> messages, the features are encoded in the "features" parameter within the URI. The value of this parameter is a comma-separated list of feature names that the device supports for the specific module.
サーバーは、<hello>メッセージを介してサポートされている機能の名前を示します。<hello>メッセージでは、機能はURI内の「機能」パラメーターにエンコードされています。このパラメーターの値は、デバイスが特定のモジュールでサポートする機能名のコンマ区切りリストです。
For example, this <hello> message advertises one module, informing
the client that it supports the "local-storage" feature of module
"syslog".
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&features=local-storage
</capability>
</hello>
Device deviations are announced via the "deviations" parameter. The value of the "deviations" parameter is a comma-separated list of modules containing deviations from the capability's module.
デバイスの偏差は、「逸脱」パラメーターを介して発表されます。「偏差」パラメーターの値は、機能のモジュールからの偏差を含むモジュールのコンマ分離されたリストです。
For example, this <hello> message advertises two modules, informing the client that it deviates from module "syslog" according to the deviations listed in the module "my-devs".
たとえば、この<hello>メッセージは2つのモジュールを宣伝し、モジュール「my-devs」に記載されている逸脱に従ってモジュール「syslog」から逸脱することをクライアントに通知します。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&deviations=my-devs
</capability>
<capability>
http://example.com/my-deviations?module=my-devs
</capability>
</hello>
Data models may allow the server to alter the configuration data store in ways not explicitly directed via NETCONF protocol messages. For example, a data model may define leafs that are assigned system-generated values when the client does not provide one. A formal mechanism for specifying the circumstances where these changes are allowed is out of scope for this specification.
データモデルにより、サーバーは、NetConfプロトコルメッセージを介して明示的に指示されていない方法で構成データストアを変更できる場合があります。たとえば、データモデルは、クライアントが提供しない場合にシステム生成値が割り当てられたリーフを定義できます。これらの変更が許可されている状況を指定するための正式なメカニズムは、この仕様の範囲外です。
The YANG syntax is similar to that of SMIng [RFC3780] and programming languages like C and C++. This C-like syntax was chosen specifically for its readability, since YANG values the time and effort of the readers of models above those of modules writers and YANG tool-chain developers. This section introduces the YANG syntax.
Yang構文は、Sming [RFC3780]およびCやCのようなプログラミング言語の構文と似ています。Yangは、モジュールの作家やYangツールチェーン開発者のモデルよりも上のモデルの読者の時間と労力を重視しているため、このC様構文はその読みやすさのために特別に選択されました。このセクションでは、Yang構文を紹介します。
YANG modules use the UTF-8 [RFC3629] character encoding.
Yangモジュールは、UTF-8 [RFC3629]文字エンコードを使用します。
YANG modules are parsed as a series of tokens. This section details the rules for recognizing tokens from an input stream. YANG tokenization rules are both simple and powerful. The simplicity is driven by a need to keep the parsers easy to implement, while the power is driven by the fact that modelers need to express their models in readable formats.
Yangモジュールは、一連のトークンとして解析されます。このセクションでは、入力ストリームからトークンを認識するためのルールについて詳しく説明します。ヤントークン化ルールは、単純で強力です。シンプルさは、パーサーの実装を容易に保つ必要性によって駆動されますが、モデラーはモデルを読み取り可能な形式で表現する必要があるという事実によって駆動されます。
Comments are C++ style. A single line comment starts with "//" and ends at the end of the line. A block comment is enclosed within "/*" and "*/".
コメントはCスタイルです。単一の行のコメントは「//」で始まり、行の最後で終了します。ブロックコメントは、「/*」および「*/」に囲まれています。
A token in YANG is either a keyword, a string, a semicolon (";"), or braces ("{" or "}"). A string can be quoted or unquoted. A keyword is either one of the YANG keywords defined in this document, or a prefix identifier, followed by ":", followed by a language extension keyword. Keywords are case sensitive. See Section 6.2 for a formal definition of identifiers.
ヤンのトークンは、キーワード、文字列、セミコロン（ ";"）、またはブレース（ "{"または "}"）のいずれかです。文字列は引用または引用されていません。キーワードは、このドキュメントで定義されているYangキーワードのいずれか、またはプレフィックス識別子のいずれかで、その後に「：」が続き、その後に言語拡張キーワードが続きます。キーワードはケースに敏感です。識別子の正式な定義については、セクション6.2を参照してください。
If a string contains any space or tab characters, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes.
文字列にスペースまたはタブ文字が含まれている場合、セミコロン（ ";"）、ブレース（ "{"または "}"）、またはコメントシーケンス（ "//"、 "/*"、または "*/"）が含まれています。次に、二重または単一の引用符に囲まれている必要があります。
If the double-quoted string contains a line break followed by space or tab characters that are used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. In this process, a tab character is treated as 8 space characters.
ダブル引用文字にラインブレイクが含まれている場合、Yangファイルのレイアウトに従ってテキストをインデントするために使用されるスペースまたはタブ文字が続く場合、この主要な白文学は、弦から剥がれ、ダブルの列まで削除されます。引用キャラクター、または最初の非白文字のキャラクターに、どちらか最初に発生した方。このプロセスでは、タブ文字は8つのスペース文字として扱われます。
If the double-quoted string contains space or tab characters before a line break, this trailing whitespace is stripped from the string.
二重引用文字にラインが切れる前にスペースまたはタブ文字が含まれている場合、この走行式の空白は文字列から剥がれます。
A single-quoted string (enclosed within ' ') preserves each character within the quotes. A single quote character cannot occur in a single-quoted string, even when preceded by a backslash.
単一引用文字（ ''内に囲まれている）は、引用符内の各文字を保持します。単一の引用文字は、バックスラッシュが前に行われた場合でも、単一引用符で発生することはできません。
Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash:
二重引用文字（ ""に囲まれた）内で、バックスラッシュキャラクターは特別なキャラクターを紹介します。これは、バックスラッシュのすぐ後に続くキャラクターに依存します。
\n new line \t a tab character \" a double quote \\ a single backslash
\ n新しいライン\ tタブ文字\ "二重Quote \\単一のバックスラッシュ
If a quoted string is followed by a plus character ("+"), followed by another quoted string, the two strings are concatenated into one string, allowing multiple concatenations to build one string. Whitespace trimming and substitution of backslash-escaped characters in double-quoted strings is done before concatenation.
引用された文字列の後にプラス文字（ ""）が続いて、別の引用文字列が続く場合、2つの文字列が1つの文字列に連結され、複数の連結が1つの文字列を構築できるようにします。二重引用文字のバックスラッシュエスケープ文字のホワイトスペースのトリミングと置換は、連結前に行われます。
The following strings are equivalent:
次の文字列は同等です。
hello "hello" 'hello' "hel" + "lo" 'hel' + "lo"
こんにちは "hello" 'hello' "hel" "lo" 'hel' "lo"
The following examples show some special strings:
次の例は、いくつかの特別な文字列を示しています。
"\"" - string containing a double quote '"' - string containing a double quote "\n" - string containing a new line character '\n' - string containing a backslash followed by the character n
"\" " - 二重引用符を含む文字列 '"' - 二重引用符を含む文字列\ n " - 新しいライン文字を含む文字列 '\ n' - バックスラッシュを含む文字
The following examples show some illegal strings:
次の例は、いくつかの違法な文字列を示しています。
'''' - a single-quoted string cannot contain single quotes """ - a double quote must be escaped in a double-quoted string
'' '' - 単一引用文字は単一の引用符を含めることができません "" - 二重引用符は二重引用文字列で逃げる必要があります
The following strings are equivalent:
次の文字列は同等です。
"first line second line"
「ファーストラインセカンドライン」
"first line\n" + " second line"
「ファーストライン\ n」「セカンドライン」
Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. Implementations MUST support identifiers up to 64 characters in length. Identifiers are case sensitive. The identifier syntax is formally defined by the rule "identifier" in Section 12. Identifiers can be specified as quoted or unquoted strings.
識別子は、名前で異なる種類のヤンアイテムを識別するために使用されます。各識別子は、大文字または小文字のASCII文字またはアンダースコア文字から始まり、その後、ゼロ以上のASCII文字、数字、アンダースコア文字、ハイフン、ドットが続きます。実装は、長さが最大64文字の識別子をサポートする必要があります。識別子はケースに敏感です。識別子構文は、セクション12のルール「識別子」によって正式に定義されます。識別子は引用符または引用されていない文字列として指定できます。
Each identifier is valid in a namespace that depends on the type of the YANG item being defined. All identifiers defined in a namespace MUST be unique.
各識別子は、定義されているヤンアイテムのタイプに依存する名前空間で有効です。名前空間で定義されているすべての識別子は一意でなければなりません。
o All module and submodule names share the same global module identifier namespace.
o すべてのモジュールとサブモジュール名は、同じグローバルモジュール識別子ネームスペースを共有しています。
o All extension names defined in a module and its submodules share the same extension identifier namespace.
o モジュールで定義されたすべての拡張名とそのサブモジュールは、同じ拡張識別子ネームスペースを共有します。
o All feature names defined in a module and its submodules share the same feature identifier namespace.
o モジュールで定義されているすべての機能名とそのサブモジュールは、同じ機能識別子ネームスペースを共有しています。
o All identity names defined in a module and its submodules share the same identity identifier namespace.
o モジュールで定義されているすべてのID名とそのサブモジュールは、同じID識別子ネームスペースを共有します。
o All derived type names defined within a parent node or at the top level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that typedef, and it MUST NOT define a typedef with the same name.
o 親ノード内またはモジュールまたはそのサブモジュールの最上位レベルで定義されたすべての派生タイプ名は、同じタイプ識別子ネームスペースを共有します。この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされています。これは、すべての子孫ノードがそのtypedefを使用する場合があり、同じ名前のtypedefを定義してはならないことを意味します。
o All grouping names defined within a parent node or at the top level of the module or its submodules share the same grouping identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that grouping, and it MUST NOT define a grouping with the same name.
o 親ノード内またはモジュールまたはそのサブモジュールの最上位レベルで定義されたすべてのグループ名は、同じグループ識別子ネームスペースを共有しています。この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされています。これは、すべての子孫ノードがそのグループ化を使用する場合があり、同じ名前のグループを定義してはならないことを意味します。
o All leafs, leaf-lists, lists, containers, choices, rpcs, notifications, and anyxmls defined (directly or through a uses statement) within a parent node or at the top level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the closest ancestor node that is not a case or choice node.
o すべてのリーフ、リーフリスト、リスト、コンテナ、選択肢、RPC、通知、およびanyXMLS（直接または使用ステートメントを介して）、または親ノード内またはモジュールまたはそのサブモジュールの最上位レベルで同じ識別子名空間を共有します。この名前空間は、親ノードがケースノードでない限り、親ノードまたはモジュールにスコープされます。その場合、名前空間は、ケースまたは選択ノードではない最も近い祖先ノードにスコープされます。
o All cases within a choice share the same case identifier namespace. This namespace is scoped to the parent choice node.
o 選択内のすべてのケースは、同じケース識別子ネームスペースを共有します。この名前空間は、親の選択ノードにスコープされています。
Forward references are allowed in YANG.
ヤンではフォワード参照が許可されています。
A YANG module contains a sequence of statements. Each statement starts with a keyword, followed by zero or one argument, followed either by a semicolon (";") or a block of substatements enclosed within braces ("{ }"):
Yangモジュールには、一連のステートメントが含まれています。各ステートメントは、キーワードで始まり、その後にゼロまたは1つの引数が続き、その後にセミコロン（ ";"）またはブレース内に囲まれた置換のブロック（ "{{}"）が続きます。
statement = keyword [argument] (";" / "{" *statement "}")
The argument is a string, as defined in Section 6.1.2.
引数は、セクション6.1.2で定義されている文字列です。
A module can introduce YANG extensions by using the "extension" keyword (see Section 7.17). The extensions can be imported by other modules with the "import" statement (see Section 7.1.5). When an imported extension is used, the extension's keyword MUST be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MUST be qualified with the module's prefix.
モジュールは、「拡張機能」キーワードを使用してYang拡張機能を導入できます（セクション7.17を参照）。拡張機能は、「インポート」ステートメントを使用して他のモジュールによってインポートできます（セクション7.1.5を参照）。インポートされた拡張機能を使用する場合、拡張機能のキーワードは、拡張機能のモジュールがインポートされたプレフィックスを使用して適格にする必要があります。拡張機能が定義されているモジュールで拡張機能が使用されている場合、拡張機能のキーワードはモジュールのプレフィックスで適格でなければなりません。
Since submodules cannot include the parent module, any extensions in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the extension.
サブモジュールには親モジュールを含めることはできないため、サブモジュールに曝露する必要があるモジュール内の拡張機能は、サブモジュールで定義する必要があります。サブモジュールは、このサブモジュールを含めて、拡張の定義を見つけることができます。
If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler.
Yangコンパイラが、Yangモジュールに未知のステートメントとして表示される特定の拡張機能をサポートしていない場合（セクション12を参照）、不明なステートメント全体がコンパイラによって無視される場合があります。
YANG relies on XML Path Language (XPath) 1.0 [XPATH] as a notation for specifying many inter-node references and dependencies. NETCONF clients and servers are not required to implement an XPath interpreter, but MUST ensure that the requirements encoded in the data model are enforced. The manner of enforcement is an implementation decision. The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context (see Section 6.4.1). An implementation may choose to implement them by hand, rather than using the XPath expression directly.
Yangは、多くのノード間参照と依存関係を指定する表記として、XML Path言語（XPath）1.0 [XPath]に依存しています。NetConfクライアントとサーバーは、XPathインタープリターを実装する必要はありませんが、データモデルでエンコードされた要件が実施されることを確認する必要があります。執行方法は、実装決定です。Xpath式は構文的に正しいものでなければならず、使用されるすべての接頭辞はXPathコンテキストに存在する必要があります（セクション6.4.1を参照）。実装は、XPath式を直接使用するのではなく、手で実装することを選択できます。
The data model used in the XPath expressions is the same as that used in XPath 1.0 [XPATH], with the same extension for root node children as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means that the root node may have any number of element nodes as its children.
XPath式で使用されるデータモデルは、XPATH 1.0 [XPath]で使用されているデータと同じであり、XSLT 1.0 [XSLT]で使用されるルートノード子供の拡張機能が同じです（セクション3.1）。具体的には、ルートノードには、子供として任意の数の要素ノードがあることを意味します。
All YANG XPath expressions share the following XPath context definition:
すべてのYang XPath式は、次のXPathコンテキスト定義を共有しています。
o The set of namespace declarations is the set of all "import" statements' prefix and namespace pairs in the module where the XPath expression is specified, and the "prefix" statement's prefix for the "namespace" statement's URI.
o 名前空間宣言のセットは、XPath式が指定されているモジュールのすべての「インポート」ステートメントのプレフィックスのプレフィックスと名前空間ペアのセットと、「名前空間」ステートメントのURIの「プレフィックス」ステートメントのプレフィックスです。
o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used (see Section 7.12).
o 名前空間プレフィックスのない名前は、現在のノードの識別子と同じ名前空間に属します。グループ内では、その名前空間は、グループ化が使用される場所によって影響を受けます（セクション7.12を参照）。
o The function library is the core function library defined in [XPATH], and a function "current()" that returns a node set with the initial context node.
o 関数ライブラリは、[xpath]で定義されているコア関数ライブラリと、初期コンテキストノードでノードセットを返す関数「current（）」です。
o The set of variable bindings is empty.
o 可変バインディングのセットは空です。
The mechanism for handling unprefixed names is adopted from XPath 2.0 [XPATH2.0], and helps simplify XPath expressions in YANG. No ambiguity may ever arise because YANG node identifiers are always qualified names with a non-null namespace URI.
再固定されていない名前を処理するメカニズムは、Xpath 2.0 [XPath2.0]から採用されており、YangのXpath式の簡素化に役立ちます。Yangノード識別子は常に非ヌルの名前空間URIを持つ適格な名前であるため、あいまいさは生じません。
The context node varies with the YANG XPath expression, and is specified where the YANG statement with the XPath expression is defined.
コンテキストノードは、Yang XPath式によって異なり、XPath式のYangステートメントが定義されている場所で指定されています。
A schema node identifier is a string that identifies a node in the schema tree. It has two forms, "absolute" and "descendant", defined by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid" in Section 12, respectively. A schema node identifier consists of a path of identifiers, separated by slashes ("/"). In an absolute schema node identifier, the first identifier after the leading slash is any top-level schema node in the local module or in all imported modules.
スキーマノード識別子は、スキーマツリーのノードを識別する文字列です。セクション12のルール「Absolute-Schema-Nodeid」と「Descendant-Schema-Nodeid」で定義された「絶対」と「子孫」の2つの形式があります。スキーマノード識別子は、スラッシュ（ "/"）で区切られた識別子のパスで構成されています。絶対スキーマノード識別子では、主要なスラッシュ後の最初の識別子は、ローカルモジュールまたはすべてのインポートモジュールのトップレベルスキーマノードです。
References to identifiers defined in external modules MUST be qualified with appropriate prefixes, and references to identifiers defined in the current module and its submodules MAY use a prefix.
外部モジュールで定義された識別子への参照は、適切なプレフィックスで適格でなければならず、現在のモジュールとそのサブモジュールで定義されている識別子への参照は、プレフィックスを使用する場合があります。
For example, to identify the child node "b" of top-level node "a", the string "/a/b" can be used.
たとえば、トップレベルノード「A」の子ノード「b」を識別するために、文字列「/a/b」を使用できます。
The following sections describe all of the YANG statements.
次のセクションでは、すべてのヤンステートメントについて説明します。
Note that even a statement that does not have any substatements defined in YANG can have vendor-specific extensions as substatements. For example, the "description" statement does not have any substatements defined in YANG, but the following is legal:
description "some text" {
acme:documentation-flag 5;
}
The "module" statement defines the module's name, and groups all statements that belong to the module together. The "module" statement's argument is the name of the module, followed by a block of substatements that hold detailed module information. The module name follows the rules for identifiers in Section 6.2.
「モジュール」ステートメントはモジュールの名前を定義し、モジュールに属するすべてのステートメントを一緒にグループ化します。「モジュール」ステートメントの引数はモジュールの名前であり、その後、詳細なモジュール情報を保持する置換ブロックが続きます。モジュール名は、セクション6.2の識別子のルールに従います。
Names of modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているモジュールの名前は、IANAによって割り当てる必要があります。セクション14を参照してください。
Private module names are assigned by the organization owning the module without a central registry. It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the module name.
プライベートモジュール名は、中央レジストリなしでモジュールを所有する組織によって割り当てられます。たとえば、モジュール名のプレフィックスとしてエンタープライズまたは組織名を使用することにより、標準または他のエンタープライズモジュールやサブモジュールと衝突する可能性が低いモジュール名を選択することをお勧めします。
A module typically has the following layout:
通常、モジュールには次のレイアウトがあります。
module <module-name> {
// header information
<yang-version statement>
<namespace statement>
<prefix statement>
// linkage statements <import statements> <include statements>
//リンケージステートメント<インポートステートメント> <ステートメントを含める>
// meta information
<organization statement>
<contact statement>
<description statement>
<reference statement>
// revision history <revision statements>
//リビジョン履歴<リビジョンステートメント>
// module definitions <other statements> }
//モジュール定義<その他のステートメント>}
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| namespace | 7.1.3 | 1 |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
The optional "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument is a string. If present, it MUST contain the value "1", which is the current YANG version and the default value.
オプションの「Yang-version」ステートメントは、モジュールの開発に使用されたYang言語のバージョンを指定します。声明の議論は文字列です。存在する場合は、現在のYangバージョンとデフォルト値である値「1」を含める必要があります。
Handling of the "yang-version" statement for versions other than "1" (the version defined here) is out of scope for this specification. Any document that defines a higher version will need to define the backward compatibility of such a higher version.
「1」以外のバージョン（ここで定義されているバージョン）以外のバージョンの「Yang-version」ステートメントの処理は、この仕様の範囲外です。より高いバージョンを定義するドキュメントは、このような上位バージョンの後方互換性を定義する必要があります。
The "namespace" statement defines the XML namespace that all identifiers defined by the module are qualified by, with the exception of data node identifiers defined inside a grouping (see Section 7.12 for details). The argument to the "namespace" statement is the URI of the namespace.
「名前空間」ステートメントは、グループ内で定義されているデータノード識別子を除き、モジュールによって定義されたすべての識別子が資格があるXML名前空間を定義します（詳細についてはセクション7.12を参照）。「名前空間」ステートメントの引数は、名前空間のURIです。
See also Section 5.3.
セクション5.3も参照してください。
The "prefix" statement is used to define the prefix associated with the module and its namespace. The "prefix" statement's argument is the prefix string that is used as a prefix to access a module. The prefix string MAY be used to refer to definitions contained in the module, e.g., "if:ifName". A prefix follows the same rules as an identifier (see Section 6.2).
「プレフィックス」ステートメントは、モジュールとその名前空間に関連付けられたプレフィックスを定義するために使用されます。「プレフィックス」ステートメントの引数は、モジュールにアクセスするプレフィックスとして使用されるプレフィックス文字列です。プレフィックス文字列は、モジュールに含まれる定義を参照するために使用できます。たとえば、「ifname」。接頭辞は、識別子と同じルールに従います（セクション6.2を参照）。
When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. To improve readability of the NETCONF XML, a NETCONF client or server that generates XML or XPath that use prefixes SHOULD use the prefix defined by the module, unless there is a conflict.
「モジュール」ステートメント内で使用する場合、「プレフィックス」ステートメントは、このモジュールがインポートされているときに使用するプレフィックスを定義します。NetConf XMLの可読性を向上させるには、競合がない限り、プレフィックスを使用するXMLまたはXPathを生成するXMLまたはXPathを生成するXMLまたはXPathを生成するサーバーをモジュールで定義するプレフィックスを使用する必要があります。
When used inside the "import" statement, the "prefix" statement defines the prefix to be used when accessing definitions inside the imported module. When a reference to an identifier from the imported module is used, the prefix string for the imported module is used in combination with a colon (":") and the identifier, e.g., "if: ifIndex". To improve readability of YANG modules, the prefix defined by a module SHOULD be used when the module is imported, unless there is a conflict. If there is a conflict, i.e., two different modules that both have defined the same prefix are imported, at least one of them MUST be imported with a different prefix.
「インポート」ステートメント内で使用する場合、「プレフィックス」ステートメントは、インポートされたモジュール内の定義にアクセスするときに使用するプレフィックスを定義します。インポートされたモジュールからの識別子への参照が使用されると、インポートされたモジュールのプレフィックス文字列は、コロン（ "："）と識別子と組み合わせて使用されます。たとえば、「ifindex」。Yangモジュールの可読性を向上させるには、競合がない限り、モジュールがインポートされているときにモジュールによって定義されるプレフィックスを使用する必要があります。競合がある場合、つまり、両方とも同じ接頭辞を定義した2つの異なるモジュールがインポートされている場合、少なくとも1つは別のプレフィックスでインポートする必要があります。
All prefixes, including the prefix for the module itself MUST be unique within the module or submodule.
モジュール自体のプレフィックスを含むすべてのプレフィックスは、モジュールまたはサブモジュール内で一意でなければなりません。
The "import" statement makes definitions from one module available inside another module or submodule. The argument is the name of the module to import, and the statement is followed by a block of substatements that holds detailed import information. When a module is imported, the importing module may: o use any grouping and typedef defined at the top level in the imported module or its submodules.
「インポート」ステートメントは、別のモジュールまたはサブモジュール内で利用可能な1つのモジュールからの定義を作成します。引数はインポートするモジュールの名前であり、ステートメントの後に詳細なインポート情報を保持する置換のブロックが続きます。モジュールがインポートされると、インポートモジュールは次のようになります。oインポートされたモジュールまたはそのサブモジュールの最上位レベルで定義されたTypedefを使用します。
o use any extension, feature, and identity defined in the imported module or its submodules.
o インポートされたモジュールまたはそのサブモジュールで定義されている任意の拡張機能、機能、およびIDを使用します。
o use any node in the imported module's schema tree in "must", "path", and "when" statements, or as the target node in "augment" and "deviation" statements.
o インポートされたモジュールのスキーマツリーの任意のノードを「マスト」、「パス」、「 "ステートメントのとき、または「augment」および「偏差」ステートメントのターゲットノードとして使用します。
The mandatory "prefix" substatement assigns a prefix for the imported module that is scoped to the importing module or submodule. Multiple "import" statements may be specified to import from different modules.
必須の「プレフィックス」サブセーションは、インポートモジュールまたはサブモジュールにスコープされたインポートされたモジュールのプレフィックスを割り当てます。複数の「インポート」ステートメントを指定して、異なるモジュールからインポートすることができます。
When the optional "revision-date" substatement is present, any typedef, grouping, extension, feature, and identity referenced by definitions in the local module are taken from the specified revision of the imported module. It is an error if the specified revision of the imported module does not exist. If no "revision-date" substatement is present, it is undefined from which revision of the module they are taken.
オプションの「リビジョンデート」のサクスチャメントが存在する場合、ローカルモジュールの定義によって参照されるtypedef、グループ化、拡張機能、機能、およびIDは、インポートされたモジュールの指定された改訂から取得されます。インポートされたモジュールの指定された改訂が存在しない場合、これはエラーです。「改訂日」の次の置換が存在しない場合、それが採取されるモジュールの改訂から未定義です。
Multiple revisions of the same module MUST NOT be imported.
同じモジュールの複数の改訂をインポートしてはなりません。
The import's Substatements
インポートの代替
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| prefix | 7.1.4 | 1 |
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The import's "revision-date" statement is used to specify the exact version of the module to import. The "revision-date" statement MUST match the most recent "revision" statement in the imported module.
インポートの「改訂版」ステートメントは、インポートするモジュールの正確なバージョンを指定するために使用されます。「改訂日」ステートメントは、インポートされたモジュールの最新の「改訂」ステートメントと一致する必要があります。
The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. The argument is an identifier that is the name of the submodule to include. Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module.
「含まれる」ステートメントは、そのサブモジュールの親モジュール、またはその親モジュールの別のサブモジュールから利用可能なサブモジュールからコンテンツを作成するために使用されます。引数は、含まれるサブモジュールの名前である識別子です。モジュールには、「属する」ステートメントで定義されているように、そのモジュールに属するサブモジュールのみを含めることができます（セクション7.2.2を参照）。サブモジュールには、同じモジュールに属する他のサブモジュールのみを含めることができます。
When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule.
モジュールにサブモジュールが含まれている場合、サブモジュールの内容がモジュールのノード階層に組み込まれます。サブモジュールに別のサブモジュールが含まれている場合、ターゲットサブモジュールの定義が現在のサブモジュールで利用可能になります。
When the optional "revision-date" substatement is present, the specified revision of the submodule is included in the module. It is an error if the specified revision of the submodule does not exist. If no "revision-date" substatement is present, it is undefined which revision of the submodule is included.
オプションの「改訂版」のサクスチャメントが存在する場合、サブモジュールの指定された改訂がモジュールに含まれています。サブモジュールの指定された修正が存在しない場合、これはエラーです。「改訂日」の次のサクステメントが存在しない場合、どのサブモジュールの改訂が含まれているかは定義されていません。
Multiple revisions of the same submodule MUST NOT be included.
同じサブモジュールの複数の改訂を含める必要はありません。
The includes's Substatements
含まれる代替
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The "organization" statement defines the party responsible for this module. The argument is a string that is used to specify a textual description of the organization(s) under whose auspices this module was developed.
「組織」ステートメントは、このモジュールを担当する当事者を定義します。引数は、このモジュールが開発された任期の下にある組織のテキストの説明を指定するために使用される文字列です。
The "contact" statement provides contact information for the module. The argument is a string that is used to specify contact information for the person or persons to whom technical queries concerning this module should be sent, such as their name, postal address, telephone number, and electronic mail address.
「連絡先」ステートメントは、モジュールの連絡先情報を提供します。引数は、名前、郵便住所、電話番号、電子メールアドレスなど、このモジュールに関する技術的な質問を送信する人の連絡先情報を指定するために使用される文字列です。
The "revision" statement specifies the editorial revision history of the module, including the initial revision. A series of revision statements detail the changes in the module's definition. The argument is a date string in the format "YYYY-MM-DD", followed by a block of substatements that holds detailed revision information. A module SHOULD have at least one initial "revision" statement. For every published editorial change, a new one SHOULD be added in front of the revisions sequence, so that all revisions are in reverse chronological order.
「改訂」ステートメントは、最初の改訂を含むモジュールの編集改訂履歴を指定します。一連の改訂ステートメントは、モジュールの定義の変更を詳述しています。引数は、「yyyy-mm-dd」という形式の日付文字列で、その後、詳細な改訂情報を保持する置換ブロックが続きます。モジュールには、少なくとも1つの初期「改訂」ステートメントが必要です。公開されているすべての編集上の変更については、すべての改訂が逆年代順になるように、新しい編集の変更を改訂シーケンスの前に追加する必要があります。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
module acme-system { namespace "http://acme.example.com/system"; prefix "acme";
モジュールACME-System {namespace "http://acme.example.com/system";プレフィックス「acme」;
import ietf-yang-types {
prefix "yang";
}
include acme-types;
ACMEタイプを含めます。
organization "ACME Inc."; contact "Joe L. User
組織「Acme Inc.」;「Joe L.ユーザー」にお問い合わせください
ACME, Inc. 42 Anywhere Drive Nowhere, CA 95134 USA
Acme、Inc。42どこでも運転する場所、CA 95134 USA
Phone: +1 800 555 0100
EMail: joe@acme.example.com";
description "The module for entities implementing the ACME protocol.";
説明「ACMEプロトコルを実装するエンティティのモジュール」;
revision "2007-06-09" {
description "Initial revision.";
}
// definitions follow... }
//定義が続きます...}
While the primary unit in YANG is a module, a YANG module can itself be constructed out of several submodules. Submodules allow a module designer to split a complex model into several pieces where all the submodules contribute to a single namespace, which is defined by the module that includes the submodules.
Yangの主要なユニットはモジュールですが、Yangモジュール自体はいくつかのサブモジュールから構築できます。サブモジュールにより、モジュール設計者は複雑なモデルをいくつかのピースに分割できます。そこでは、すべてのサブモジュールが単一の名前空間に寄与します。これは、サブモジュールを含むモジュールによって定義されます。
The "submodule" statement defines the submodule's name, and groups all statements that belong to the submodule together. The "submodule" statement's argument is the name of the submodule, followed by a block of substatements that hold detailed submodule information. The submodule name follows the rules for identifiers in Section 6.2.
「サブモジュール」ステートメントは、サブモジュールの名前を定義し、サブモジュールに属するすべてのステートメントをグループ化します。「サブモジュール」ステートメントの引数は、サブモジュールの名前であり、その後、詳細なサブモジュール情報を保持する置換ブロックが続きます。サブモジュール名は、セクション6.2の識別子のルールに従います。
Names of submodules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているサブモジュールの名前は、IANAによって割り当てる必要があります。セクション14を参照してください。
Private submodule names are assigned by the organization owning the submodule without a central registry. It is RECOMMENDED to choose submodule names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the submodule name.
プライベートサブモジュール名は、中央のレジストリなしでサブモジュールを所有する組織によって割り当てられます。サブモジュール名のプレフィックスとしてエンタープライズまたは組織名を使用することにより、標準または他のエンタープライズモジュールやサブモジュールと衝突する可能性が低いサブモジュール名を選択することをお勧めします。
A submodule typically has the following layout:
通常、サブモジュールには次のレイアウトがあります。
submodule <module-name> {
<yang-version statement>
<Yang-versionステートメント>
// module identification <belongs-to statement>
//モジュール識別<belonds toステートメント>
// linkage statements <import statements> <include statements>
//リンケージステートメント<インポートステートメント> <ステートメントを含める>
// meta information
<organization statement>
<contact statement>
<description statement>
<reference statement>
// revision history <revision statements>
//リビジョン履歴<リビジョンステートメント>
// module definitions <other statements> }
//モジュール定義<その他のステートメント>}
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| belongs-to | 7.2.2 | 1 |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
The "belongs-to" statement specifies the module to which the submodule belongs. The argument is an identifier that is the name of the module.
「belunds to」ステートメントは、サブモジュールが属するモジュールを指定します。引数は、モジュールの名前である識別子です。
A submodule MUST only be included by the module to which it belongs, or by another submodule that belongs to that module.
サブモジュールは、それが属するモジュール、またはそのモジュールに属する別のサブモジュールによってのみ含める必要があります。
The mandatory "prefix" substatement assigns a prefix for the module to which the submodule belongs. All definitions in the local submodule and any included submodules can be accessed by using the prefix.
必須の「プレフィックス」サブセーションは、サブモジュールが属するモジュールにプレフィックスを割り当てます。ローカルサブモジュールおよび含まれるサブモジュールのすべての定義は、プレフィックスを使用してアクセスできます。
The belongs-to's Substatements
属するものの代替
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| prefix | 7.1.4 | 1 |
+--------------+---------+-------------+
submodule acme-types {
サブモジュールACMEタイプ{
belongs-to "acme-system" {
prefix "acme";
}
import ietf-yang-types {
prefix "yang";
}
organization "ACME Inc."; contact "Joe L. User
組織「Acme Inc.」;「Joe L.ユーザー」にお問い合わせください
ACME, Inc. 42 Anywhere Drive Nowhere, CA 95134 USA
Acme、Inc。42どこでも運転する場所、CA 95134 USA
Phone: +1 800 555 0100
EMail: joe@acme.example.com";
description "This submodule defines common ACME types.";
説明「このサブモジュールは、一般的なACMEタイプを定義します。」;
revision "2007-06-09" {
description "Initial revision.";
}
// definitions follows... }
//定義が続きます...}
The "typedef" statement defines a new type that may be used locally in the module, in modules or submodules which include it, and by other modules that import from it, according to the rules in Section 5.5. The new type is called the "derived type", and the type from which it was derived is called the "base type". All derived types can be traced back to a YANG built-in type.
「typedef」ステートメントは、セクション5.5のルールに従って、モジュール、モジュールまたはサブモジュール、およびそれからインポートする他のモジュールによって局所的に使用できる新しいタイプを定義します。新しいタイプは「派生型」と呼ばれ、導出されたタイプは「ベースタイプ」と呼ばれます。派生したすべてのタイプは、ヤン内蔵のタイプにまでさかのぼることができます。
The "typedef" statement's argument is an identifier that is the name of the type to be defined, and MUST be followed by a block of substatements that holds detailed typedef information.
「typedef」ステートメントの引数は、定義するタイプの名前である識別子であり、詳細なtypedef情報を保持する置換ブロックが続く必要があります。
The name of the type MUST NOT be one of the YANG built-in types. If the typedef is defined at the top level of a YANG module or submodule, the name of the type to be defined MUST be unique within the module.
タイプの名前は、Yang組み込みのタイプの1つであってはなりません。typedefがYangモジュールまたはサブモジュールの最上位レベルで定義されている場合、定義するタイプの名前はモジュール内で一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| default | 7.3.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.3.2 | 1 |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
The "type" statement, which MUST be present, defines the base type from which this type is derived. See Section 7.4 for details.
存在する必要がある「タイプ」ステートメントは、このタイプが導出されるベースタイプを定義します。詳細については、セクション7.4を参照してください。
The "units" statement, which is optional, takes as an argument a string that contains a textual definition of the units associated with the type.
オプションである「単位」ステートメントは、タイプに関連付けられた単位のテキスト定義を含む文字列を引数として取ります。
The "default" statement takes as an argument a string that contains a default value for the new type.
「デフォルト」ステートメントは、新しいタイプのデフォルト値を含む文字列を引数として取得します。
The value of the "default" statement MUST be valid according to the type specified in the "type" statement.
「デフォルト」ステートメントの値は、「タイプ」ステートメントで指定されたタイプに従って有効でなければなりません。
If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type.
ベースタイプのデフォルト値があり、新しい派生タイプが新しいデフォルト値を指定していない場合、ベースタイプのデフォルト値は、新しい派生タイプのデフォルト値でもあります。
If the type's default value is not valid according to the new restrictions specified in a derived type or leaf definition, the derived type or leaf definition MUST specify a new default value compatible with the restrictions.
タイプのデフォルト値が、派生タイプまたは葉の定義で指定された新しい制限に従って有効でない場合、派生タイプまたは葉の定義は、制限と互換性のある新しいデフォルト値を指定する必要があります。
typedef listen-ipv4-address {
type inet:ipv4-address;
default "0.0.0.0";
}
The "type" statement takes as an argument a string that is the name of a YANG built-in type (see Section 9) or a derived type (see Section 7.3), followed by an optional block of substatements that are used to put further restrictions on the type.
「タイプ」ステートメントは、引数として、Yang内蔵タイプ（セクション9を参照）または派生タイプ（セクション7.3を参照）の名前である文字列を取得し、その後にさらに配置するために使用されるオプションの置換ブロックが続きますタイプの制限。
The restrictions that can be applied depend on the type being restricted. The restriction statements for all built-in types are described in the subsections of Section 9.
適用できる制限は、制限されているタイプによって異なります。すべての組み込みタイプの制限ステートメントは、セクション9のサブセクションで説明されています。
+------------------+---------+-------------+
| substatement | section | cardinality |
+------------------+---------+-------------+
| bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n |
| length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 |
| pattern | 9.4.6 | 0..n |
| range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 |
| type | 7.4 | 0..n |
+------------------+---------+-------------+
The "container" statement is used to define an interior data node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed container information.
「コンテナ」ステートメントは、スキーマツリーの内部データノードを定義するために使用されます。識別子である1つの引数が必要であり、詳細なコンテナ情報を保持する置換ブロックが続きます。
A container node does not have a value, but it has a list of child nodes in the data tree. The child nodes are defined in the container's substatements.
コンテナノードには値がありませんが、データツリーに子ノードのリストがあります。子ノードは、コンテナの置換で定義されています。
YANG supports two styles of containers, those that exist only for organizing the hierarchy of data nodes, and those whose presence in the configuration has an explicit meaning.
Yangは、データノードの階層を整理するためだけに存在するコンテナの2つのスタイルと、構成内の存在が明示的な意味を持つコンテナをサポートしています。
In the first style, the container has no meaning of its own, existing only to contain child nodes. This is the default style.
最初のスタイルでは、コンテナには独自の意味がなく、子ノードを含むためだけに存在します。これがデフォルトスタイルです。
For example, the set of scrambling options for Synchronous Optical Network (SONET) interfaces may be placed inside a "scrambling" container to enhance the organization of the configuration hierarchy, and to keep these nodes together. The "scrambling" node itself has no meaning, so removing the node when it becomes empty relieves the user from performing this task.
たとえば、同期光ネットワーク（SONET）インターフェイスのスクランブルオプションのセットは、構成階層の構成を強化し、これらのノードを一緒に保つために「スクランブル」容器内に配置できます。「スクランブル」ノード自体には意味がないため、空になったときにノードを削除すると、ユーザーがこのタスクを実行することができません。
In the second style, the presence of the container itself is configuration data, representing a single bit of configuration data. The container acts as both a configuration knob and a means of organizing related configuration. These containers are explicitly created and deleted.
2番目のスタイルでは、コンテナ自体の存在は構成データであり、1つの構成データを表します。コンテナは、構成ノブと関連する構成を整理する手段の両方として機能します。これらのコンテナは明示的に作成され、削除されます。
YANG calls this style a "presence container" and it is indicated using the "presence" statement, which takes as its argument a text string indicating what the presence of the node means.
Yangはこのスタイルを「存在コンテナ」と呼び、「存在感」ステートメントを使用して示されています。これは、ノードの存在が何を意味するかを示すテキスト文字列を引数として取得します。
For example, an "ssh" container may turn on the ability to log into the device using ssh, but can also contain any ssh-related configuration knobs, such as connection rates or retry limits.
たとえば、「SSH」コンテナは、SSHを使用してデバイスにログインする機能をオンにする場合がありますが、接続レートや再試行制限などのSSH関連の構成ノブを含めることもできます。
The "presence" statement (see Section 7.5.5) is used to give semantics to the existence of the container in the data tree.
「存在」ステートメント（セクション7.5.5を参照）は、データツリー内のコンテナの存在のセマンティクスを提供するために使用されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| must | 7.5.3 | 0..n |
| presence | 7.5.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "must" statement, which is optional, takes as an argument a string that contains an XPath expression (see Section 6.4). It is used to formally declare a constraint on valid data. The constraint is enforced according to the rules in Section 8.
オプションである「必須」ステートメントは、引数としてXPath式を含む文字列を取得します（セクション6.4を参照）。有効なデータの制約を正式に宣言するために使用されます。制約は、セクション8の規則に従って強制されます。
When a datastore is validated, all "must" constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated.
データストアが検証されると、すべての「マスト」制約は、データツリーの各データノード、および使用中のデフォルト値があるすべてのリーフに対して概念的に1回評価されます（セクション7.6.1を参照）。データノードがデータツリーに存在せず、デフォルト値がない場合、その「必須」ステートメントは評価されません。
All such constraints MUST evaluate to true for the data to be valid.
そのような制約はすべて、データが有効であるためにTRUEに評価する必要があります。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、セクション6.4.1の定義に加えて、次のコンテキストで概念的に評価されます。
o The context node is the node in the data tree for which the "must" statement is defined.
o コンテキストノードは、「マスト」ステートメントが定義されているデータツリーのノードです。
o The accessible tree is made up of all nodes in the data tree, and all leafs with default values in use (see Section 7.6.1).
o アクセス可能なツリーは、データツリー内のすべてのノードと、使用中のデフォルト値のあるすべてのリーフで構成されています（セクション7.6.1を参照）。
The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードに依存します。
o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
o コンテキストノードが構成を表す場合、ツリーはコンテキストノードが存在するNetConf DataStoreのデータです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルの構成データノードがあります。
o If the context node represents state data, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
o コンテキストノードが状態データを表す場合、ツリーはすべてデバイス上の状態データと<running/> datastoreです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルのデータノードがあります。
o If the context node represents notification content, the tree is the notification XML instance document. The XPath root node has the element representing the notification being defined as the only child.
o コンテキストノードが通知コンテンツを表す場合、ツリーは通知XMLインスタンスドキュメントです。Xpathルートノードには、通知を表す要素が唯一の子として定義されています。
o If the context node represents RPC input parameters, the tree is the RPC XML instance document. The XPath root node has the element representing the RPC operation being defined as the only child.
o コンテキストノードがRPC入力パラメーターを表す場合、ツリーはRPC XMLインスタンスドキュメントです。Xpathルートノードには、RPC操作が唯一の子として定義されている要素があります。
o If the context node represents RPC output parameters, the tree is the RPC reply instance document. The XPath root node has the elements representing the RPC output parameters as children.
o コンテキストノードがRPC出力パラメーターを表す場合、ツリーはRPC Replyインスタンスドキュメントです。XPathルートノードには、RPC出力パラメーターを子供として表す要素があります。
The result of the XPath expression is converted to a boolean value using the standard XPath rules.
XPath式の結果は、標準のXPathルールを使用してブール値に変換されます。
Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Sections 7.6 and 7.7), any XPath comparisons are done on the canonical value.
データツリー内のすべての葉の値は概念的に標準的な形式に保存されているため（セクション7.6および7.7を参照）、Xpath比較は標準値で行われます。
Also note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. How the evaluation is done in practice is an implementation decision.
また、XPath式が概念的に評価されていることに注意してください。これは、実装がデバイスでXPath評価者を使用する必要がないことを意味します。実際に評価が行われる方法は、実装決定です。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
The "error-message" statement, which is optional, takes a string as an argument. If the constraint evaluates to false, the string is passed as <error-message> in the <rpc-error>.
オプションである「エラーメサージ」ステートメントは、引数として文字列を取得します。制約がfalseに評価される場合、文字列は<rpc-error>で<error-message>として渡されます。
The "error-app-tag" statement, which is optional, takes a string as an argument. If the constraint evaluates to false, the string is passed as <error-app-tag> in the <rpc-error>.
オプションである「エラーアプリタグ」ステートメントは、引数として文字列を取得します。制約がfalseに評価される場合、文字列は<rpc-error>で<error-app-tag>として渡されます。
container interface {
leaf ifType {
type enumeration {
enum ethernet;
enum atm;
}
}
leaf ifMTU {
type uint32;
}
must "ifType != 'ethernet' or " +
"(ifType = 'ethernet' and ifMTU = 1500)" {
error-message "An ethernet MTU must be 1500";
}
must "ifType != 'atm' or " +
"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
error-message "An atm MTU must be 64 .. 17966";
}
}
The "presence" statement assigns a meaning to the presence of a container in the data tree. It takes as an argument a string that contains a textual description of what the node's presence means.
「存在」ステートメントは、データツリー内のコンテナの存在に意味を割り当てます。引数として、ノードの存在の意味のテキストの説明を含む文字列を取得します。
If a container has the "presence" statement, the container's existence in the data tree carries some meaning. Otherwise, the container is used to give some structure to the data, and it carries no meaning by itself.
コンテナに「存在」ステートメントがある場合、データツリーにコンテナの存在が何らかの意味を持ちます。それ以外の場合、コンテナはデータに何らかの構造を与えるために使用されますが、それ自体で意味を持ちません。
See Section 7.5.1 for additional information.
追加情報については、セクション7.5.1を参照してください。
Within a container, the "container", "leaf", "list", "leaf-list", "uses", "choice", and "anyxml" statements can be used to define child nodes to the container.
コンテナ内では、「コンテナ」、「リーフ」、「リスト」、「リーフリスト」、「使用」、「選択」、および「anyXML」ステートメントを使用して、コンテナに子ノードを定義できます。
A container node is encoded as an XML element. The element's local name is the container's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
コンテナノードはXML要素としてエンコードされています。要素のローカル名はコンテナの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
The container's child nodes are encoded as subelements to the container element. If the container defines RPC input or output parameters, these subelements are encoded in the same order as they are defined within the "container" statement. Otherwise, the subelements are encoded in any order.
コンテナの子ノードは、コンテナ要素のサブエレメントとしてエンコードされています。コンテナがRPC入力または出力パラメーターを定義する場合、これらのサブエレメントは「コンテナ」ステートメント内で定義されているのと同じ順序でエンコードされます。それ以外の場合、サブエレメントは任意の順序でエンコードされます。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, must be prepared to handle the case that a container node without a "presence" statement is not present in the XML.
<get>または<get-config>要求に返信するNetConfサーバーは、コンテナノードに「存在」ステートメントがなく、子ノードが存在しない場合、コンテナ要素を送信しないことを選択できます。したがって、<get>または<get-config>リクエストに対して<rpc-reply>を受信するクライアントは、XMLに「存在」ステートメントのないコンテナノードが存在しないというケースを処理するために準備する必要があります。
Containers can be created, deleted, replaced, and modified through <edit-config>, by using the "operation" attribute (see [RFC4741], Section 7.2) in the container's XML element.
コンテナのXML要素の「操作」属性（[RFC4741]、セクション7.2を参照）を使用して、コンテナは<edit-config>を介して削除、削除、交換、および変更できます。
If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container.
コンテナに「存在感」ステートメントがなく、最後の子ノードが削除されている場合、NetConfサーバーはコンテナを削除する場合があります。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the container node are:
NetConfサーバーが<edit-config>リクエストを処理する場合、コンテナノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist.
操作が「マージ」または「交換」の場合、ノードが存在しない場合にノードが作成されます。
If the operation is "create", the node is created if it does not exist. If the node already exists, a "data-exists" error is returned.
操作が「作成」の場合、ノードが存在しない場合にノードが作成されます。ノードが既に存在する場合、「データ存在」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在する場合にノードが削除されます。ノードが存在しない場合、「データミッシング」エラーが返されます。
Given the following container definition:
次のコンテナの定義が与えられます。
container system {
description "Contains various system parameters";
container services {
description "Configure externally available services";
container "ssh" {
presence "Enables SSH";
description "SSH service specific configuration";
// more leafs, containers and stuff here...
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<system>
<services>
<ssh/>
</services>
</system>
Since the <ssh> element is present, ssh is enabled.
<ssh>要素が存在するため、SSHが有効になります。
To delete a container with an <edit-config>:
<edit-config>でコンテナを削除するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh nc:operation="delete"/>
</services>
</system>
</config>
</edit-config>
</rpc>
The "leaf" statement is used to define a leaf node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf information.
「リーフ」ステートメントは、スキーマツリーの葉のノードを定義するために使用されます。識別子である1つの引数が必要であり、詳細な葉情報を保持する置換ブロックが続きます。
A leaf node has a value, but no child nodes in the data tree. Conceptually, the value in the data tree is always in the canonical form (see Section 9.1).
リーフノードには値がありますが、データツリーには子ノードはありません。概念的には、データツリーの値は常に標準的な形式です（セクション9.1を参照）。
A leaf node exists in zero or one instances in the data tree.
葉のノードは、データツリーにゼロまたは1つのインスタンスで存在します。
The "leaf" statement is used to define a scalar variable of a particular built-in or derived type.
「リーフ」ステートメントは、特定の組み込みまたは派生型のスカラー変数を定義するために使用されます。
The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container:
リーフのデフォルト値は、葉がデータツリーに存在しない場合にサーバーが使用する値です。デフォルト値の使用は、非表現コンテナではないスキーマツリーのリーフの最も近い祖先ノードに依存します。
o If no such ancestor exists in the schema tree, the default value MUST be used.
o スキーマツリーにそのような祖先が存在しない場合、デフォルト値を使用する必要があります。
o Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree, or if the case node is the choice's default case, and no nodes from any other case exist in the data tree.
o それ以外の場合、この祖先がケースノードである場合、ケースからのノードがデータツリーに存在する場合、またはケースノードが選択のデフォルトケースであり、データに他のケースからのノードが存在しない場合、デフォルト値を使用する必要があります。木。
o Otherwise, the default value MUST be used if the ancestor node exists in the data tree.
o それ以外の場合、祖先ノードがデータツリーに存在する場合、デフォルト値を使用する必要があります。
In these cases, the default value is said to be in use.
これらの場合、デフォルト値は使用されていると言われています。
When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value.
デフォルト値が使用されている場合、サーバーは、デフォルト値が値としてデフォルト値を持つデータツリーに葉が存在するかのように動作的に動作する必要があります。
If a leaf has a "default" statement, the leaf's default value is the value of the "default" statement. Otherwise, if the leaf's type has a default value, and the leaf is not mandatory, then the leaf's default value is the type's default value. In all other cases, the leaf does not have a default value.
リーフに「デフォルト」ステートメントがある場合、リーフのデフォルト値は「デフォルト」ステートメントの値です。それ以外の場合、リーフのタイプのデフォルト値があり、リーフが必須でない場合、リーフのデフォルト値はタイプのデフォルト値です。他のすべての場合、葉にはデフォルト値がありません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "type" statement, which MUST be present, takes as an argument the name of an existing built-in or derived type. The optional substatements specify restrictions on this type. See Section 7.4 for details.
存在する必要がある「タイプ」ステートメントは、既存の組み込みまたは派生タイプの名前を引数として取ります。オプションの置換は、このタイプの制限を指定します。詳細については、セクション7.4を参照してください。
The "default" statement, which is optional, takes as an argument a string that contains a default value for the leaf.
オプションである「デフォルト」ステートメントは、葉のデフォルト値を含む文字列を引数として取得します。
The value of the "default" statement MUST be valid according to the type specified in the leaf's "type" statement.
「デフォルト」ステートメントの値は、Leafの「タイプ」ステートメントで指定されたタイプに従って有効でなければなりません。
The "default" statement MUST NOT be present on nodes where "mandatory" is true.
「デフォルト」ステートメントは、「必須」が真であるノードに存在してはなりません。
The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If not specified, the default is "false".
オプションである「必須」ステートメントは、文字列「真」または「false」という引数として取得し、有効なデータに制約を付けます。指定されていない場合、デフォルトは「false」です。
If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1):
「必須」が「真」である場合、制約の動作は、非表現容器ではないスキーマツリーの葉の最も近い祖先ノードのタイプに依存します（セクション7.5.1を参照）。
o If no such ancestor exists in the schema tree, the leaf MUST exist.
o スキーマの木にそのような祖先が存在しない場合、葉が存在する必要があります。
o Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists in the data tree.
o それ以外の場合、この祖先がケースノードである場合、ケースのノードがデータツリーに存在する場合、葉が存在する必要があります。
o Otherwise, the leaf MUST exist if the ancestor node exists in the data tree.
o それ以外の場合、祖先ノードがデータツリーに存在する場合、葉が存在する必要があります。
This constraint is enforced according to the rules in Section 8.
この制約は、セクション8のルールに従って強制されます。
A leaf node is encoded as an XML element. The element's local name is the leaf's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リーフノードはXML要素としてエンコードされています。要素のローカル名はリーフの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
The value of the leaf node is encoded to XML according to the type, and sent as character data in the element.
リーフノードの値は、タイプに応じてXMLにエンコードされ、要素の文字データとして送信されます。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, MUST be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value.
<get>または<get-config>リクエストに返信するNetConfサーバーは、その値がデフォルト値である場合、葉要素を送信しないことを選択できます。したがって、A <get>または<get-config>リクエストに対して<rpc-reply>を受信するクライアントは、デフォルト値を持つリーフノードがXMLに存在しないケースを処理するために準備する必要があります。この場合、サーバーが使用する値はデフォルト値であることが知られています。
See Section 7.6.8 for an example.
例については、セクション7.6.8を参照してください。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the leaf node are:
NetConfサーバーが<edit-config>リクエストを処理する場合、リーフノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the value found in the XML RPC data.
操作が「マージ」または「置換」の場合、ノードが存在しない場合にノードが作成され、その値はXML RPCデータにある値に設定されます。
If the operation is "create", the node is created if it does not exist. If the node already exists, a "data-exists" error is returned.
操作が「作成」の場合、ノードが存在しない場合にノードが作成されます。ノードが既に存在する場合、「データ存在」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在する場合にノードが削除されます。ノードが存在しない場合、「データミッシング」エラーが返されます。
Given the following "leaf" statement, placed in the previously defined "ssh" container (see Section 7.5.9):
以前に定義された「SSH」コンテナに配置された次の「リーフ」ステートメントを与えられます（セクション7.5.9を参照）。
leaf port {
type inet:port-number;
default 22;
description "The port to which the SSH server listens"
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<port>2022</port>
To set the value of a leaf with an <edit-config>:
<edit-config>でリーフの値を設定するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh>
<port>2022</port>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
Where the "leaf" statement is used to define a simple scalar variable of a particular type, the "leaf-list" statement is used to define an array of a particular type. The "leaf-list" statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf-list information.
「リーフ」ステートメントを使用して特定のタイプの単純なスカラー変数を定義する場合、「リーフリスト」ステートメントを使用して特定のタイプの配列を定義します。「リーフリスト」ステートメントは、識別子である1つの引数を取り、その後、詳細な葉リスト情報を保持する置換ブロックが続きます。
The values in a leaf-list MUST be unique.
リーフリストの値は一意でなければなりません。
Conceptually, the values in the data tree are always in the canonical form (see Section 9.1).
概念的には、データツリーの値は常に標準的な形式にあります（セクション9.1を参照）。
If the type referenced by the leaf-list has a default value, it has no effect in the leaf-list.
リーフリストによって参照されるタイプのデフォルト値がある場合、リーフリストには影響がありません。
YANG supports two styles for ordering the entries within lists and leaf-lists. In many lists, the order of list entries does not impact the implementation of the list's configuration, and the device is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order to the device implementor. YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system".
Yangは、リストとリーフリスト内のエントリを注文するための2つのスタイルをサポートしています。多くのリストでは、リストエントリの順序はリストの構成の実装に影響を与えず、デバイスはリストエントリを妥当な順序で自由に並べ替えることができます。リストの「説明」文字列は、デバイスの実装者への注文を提案する場合があります。Yangはこのスタイルのリストを「システムの注文」と呼び、それらは「System-by System」という声明に示されています。
For example, a list of valid users would typically be sorted alphabetically, since the order in which the users appeared in the configuration would not impact the creation of those users' accounts.
たとえば、有効なユーザーのリストは、通常、ユーザーが構成に表示される順序がそれらのユーザーのアカウントの作成に影響を与えないため、通常アルファベット順にソートされます。
In the other style of lists, the order of list entries matters for the implementation of the list's configuration and the user is responsible for ordering the entries, while the device maintains that order. YANG calls this style of list "user ordered" and they are indicated with the statement "ordered-by user".
他のスタイルのリストでは、リストのエントリの順序はリストの構成を実装するために重要であり、ユーザーはエントリを注文する責任がありますが、デバイスはその順序を維持します。Yangはこのスタイルのリストを「ユーザー注文」と呼び、それらは「ユーザーごとに注文された」というステートメントで示されています。
For example, the order in which firewall filters entries are applied to incoming traffic may affect how that traffic is filtered. The user would need to decide if the filter entry that discards all TCP traffic should be applied before or after the filter entry that allows all traffic from trusted interfaces. The choice of order would be crucial.
たとえば、ファイアウォールフィルターエントリが着信トラフィックに適用される順序は、そのトラフィックのフィルタリング方法に影響を与える可能性があります。ユーザーは、すべてのTCPトラフィックを破棄するフィルターエントリをフィルターエントリの前または後に、信頼できるインターフェイスからのすべてのトラフィックを可能にするかどうかを判断する必要があります。順序の選択が重要です。
YANG provides a rich set of facilities within NETCONF's <edit-config> operation that allows the order of list entries in user-ordered lists to be controlled. List entries may be inserted or rearranged, positioned as the first or last entry in the list, or positioned before or after another specific entry.
Yangは、NetConfの<edit-config>操作内の豊富な施設セットを提供し、ユーザー順序のリストのリストエントリを制御できるようにします。リストエントリは、リストの最初または最後のエントリとして配置されているか、別の特定のエントリの前または後に配置された、挿入または再配置されます。
The "ordered-by" statement is covered in Section 7.7.5.
「順序付けられた」ステートメントは、セクション7.7.5で説明されています。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.4 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "min-elements" statement, which is optional, takes as an argument a non-negative integer that puts a constraint on valid list entries. A valid leaf-list or list MUST have at least min-elements entries.
オプションである「Min-Elements」ステートメントは、有効なリストエントリに制約を付ける非陰性整数を引数として取ります。有効なリーフリストまたはリストには、少なくとも最小要素のエントリが必要です。
If no "min-elements" statement is present, it defaults to zero.
「Min-Elements」ステートメントが存在しない場合、デフォルトはゼロになります。
The behavior of the constraint depends on the type of the leaf-list's or list's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1):
制約の動作は、葉のリストまたはリストの最も近い先祖ノードのタイプのタイプに依存します。
o If this ancestor is a case node, the constraint is enforced if any other node from the case exists.
o この祖先がケースノードである場合、ケースの他のノードが存在する場合、制約が施行されます。
o Otherwise, it is enforced if the ancestor node exists.
o それ以外の場合は、祖先ノードが存在する場合に施行されます。
The constraint is further enforced according to the rules in Section 8.
制約は、セクション8の規則に従ってさらに強制されます。
The "max-elements" statement, which is optional, takes as an argument a positive integer or the string "unbounded", which puts a constraint on valid list entries. A valid leaf-list or list always has at most max-elements entries.
オプションである「Max-Elements」ステートメントは、主張としてポジティブな整数または「Unbounded」の文字列を取得し、有効なリストエントリに制約を課します。有効なリーフリストまたはリストには、常に最大の要素エントリが常にあります。
If no "max-elements" statement is present, it defaults to "unbounded".
「Max-Elements」ステートメントが存在しない場合、デフォルトは「バウンドされていない」になります。
The "max-elements" constraint is enforced according to the rules in Section 8.
「最大要素」の制約は、セクション8の規則に従って施行されます。
The "ordered-by" statement defines whether the order of entries within a list are determined by the user or the system. The argument is one of the strings "system" or "user". If not present, order defaults to "system".
「注文」ステートメントは、リスト内のエントリの順序がユーザーまたはシステムによって決定されるかどうかを定義します。引数は、文字列「システム」または「ユーザー」の1つです。存在しない場合、注文はデフォルトで「システム」になります。
This statement is ignored if the list represents state data, RPC output parameters, or notification content.
このステートメントは、リストが状態データ、RPC出力パラメーター、または通知コンテンツを表す場合、無視されます。
See Section 7.7.1 for additional information.
詳細については、セクション7.7.1を参照してください。
The entries in the list are sorted according to an unspecified order. Thus, an implementation is free to sort the entries in the most appropriate order. An implementation SHOULD use the same order for the same data, regardless of how the data were created. Using a deterministic order will make comparisons possible using simple tools like "diff".
リストのエントリは、不特定の順序に従ってソートされます。したがって、実装は、エントリを最も適切な順序で自由に並べ替えることができます。実装は、データの作成方法に関係なく、同じデータに対して同じ注文を使用する必要があります。決定論的順序を使用すると、「diff」などの簡単なツールを使用して比較が可能になります。
This is the default order.
これはデフォルトの順序です。
The entries in the list are sorted according to an order defined by the user. This order is controlled by using special XML attributes in the <edit-config> request. See Section 7.7.7 for details.
リスト内のエントリは、ユーザーが定義した注文に従ってソートされます。この順序は、<edit-config>リクエストで特別なXML属性を使用することにより制御されます。詳細については、セクション7.7.7を参照してください。
A leaf-list node is encoded as a series of XML elements. Each element's local name is the leaf-list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リーフリストノードは、一連のXML要素としてエンコードされます。各要素のローカル名はリーフリストの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
The value of each leaf-list entry is encoded to XML according to the type, and sent as character data in the element.
各リーフリストエントリの値は、タイプに従ってXMLにエンコードされ、要素の文字データとして送信されます。
The XML elements representing leaf-list entries MUST appear in the order specified by the user if the leaf-list is "ordered-by user"; otherwise, the order is implementation-dependent. The XML elements representing leaf-list entries MAY be interleaved with other sibling elements, unless the leaf-list defines RPC input or output parameters.
リーフリストが「ユーザーごとに順序付け」である場合、葉のリストエントリを表すXML要素は、ユーザーが指定した順序で表示する必要があります。それ以外の場合、注文は実装依存です。リーフリストがRPC入力または出力パラメーターを定義しない限り、リーフリストエントリを表すXML要素は、他の兄弟要素とインターリーブされる場合があります。
See Section 7.7.8 for an example.
例については、セクション7.7.8を参照してください。
Leaf-list entries can be created and deleted, but not modified, through <edit-config>, by using the "operation" attribute in the leaf-list entry's XML element.
Leaf-ListエントリのXML要素の「操作」属性を使用することにより、リーフリストエントリを作成および削除できますが、<edit-config>を介して変更されません。
In an "ordered-by user" leaf-list, the attributes "insert" and "value" in the YANG XML namespace (Section 5.3.1) can be used to control where in the leaf-list the entry is inserted. These can be used during "create" operations to insert a new leaf-list entry, or during "merge" or "replace" operations to insert a new leaf-list entry or move an existing one.
「順序付けられたユーザー」リーフリストでは、Yang XMLネームスペース（セクション5.3.1）の属性「挿入」と「値」を使用して、リーフリスト内のエントリが挿入される場所を制御できます。これらは、「作成」操作中に新しいリーフリストエントリを挿入するとき、または「マージ」または「交換」操作中に新しい葉リストのエントリを挿入するか、既存の操作を移動します。
The "insert" attribute can take the values "first", "last", "before", and "after". If the value is "before" or "after", the "value" attribute MUST also be used to specify an existing entry in the leaf-list.
「挿入」属性は、最初に値を「最後」、「前」、「後」を取得できます。値が「前」または「後」の場合、「値」属性を使用して、リーフリストに既存のエントリを指定する必要があります。
If no "insert" attribute is present in the "create" operation, it defaults to "last".
「Create」操作に「挿入」属性が存在しない場合、デフォルトは「最後」になります。
If several entries in an "ordered-by user" leaf-list are modified in the same <edit-config> request, the entries are modified one at the time, in the order of the XML elements in the request.
「順序付けられたユーザー」のリーフリストのいくつかのエントリが同じ<edit-config>リクエストで変更された場合、リクエストのXML要素の順序で、その時点でエントリが変更されます。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire leaf-list, the leaf-list order is the same as the order of the XML elements in the request.
<copy-config>、またはリーフリスト全体をカバーする「置き換え」操作を備えた<edit-config>では、リーフリストの順序は、リクエストのXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a leaf-list node are:
NetConfサーバーが<edit-config>リクエストを処理する場合、リーフリストノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the leaf-list entry is created if it does not exist.
操作が「マージ」または「交換」の場合、葉のリストが存在しない場合は葉リストのエントリが作成されます。
If the operation is "create", the leaf-list entry is created if it does not exist. If the leaf-list entry already exists, a "data-exists" error is returned.
操作が「作成」されている場合、リーフリストエントリが存在しない場合は作成されます。葉のリストのエントリが既に存在する場合、「データを存在する」エラーが返されます。
If the operation is "delete", the entry is deleted from the leaf-list if it exists. If the leaf-list entry does not exist, a "data-missing" error is returned.
操作が「削除」の場合、エントリが存在する場合、エントリはリーフリストから削除されます。リーフリストのエントリが存在しない場合、「データミッシング」エラーが返されます。
leaf-list allow-user {
type string;
description "A list of user name patterns to allow";
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<allow-user>alice</allow-user>
<allow-user>bob</allow-user>
To create a new element in this list, using the default <edit-config> operation "merge":
このリストに新しい要素を作成するには、デフォルトの<edit-config>操作「マージ」を使用します。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh>
<allow-user>eric</allow-user>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
Given the following ordered-by user leaf-list:
次の注文されたユーザーリーフリストを考慮してください。
leaf-list cipher {
type string;
ordered-by user;
description "A list of ciphers";
}
The following would be used to insert a new cipher "blowfish-cbc" after "3des-cbc":
以下は、「3DES-CBC」の後に新しい暗号「ブローフィッシュCBC」を挿入するために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh>
<cipher nc:operation="create"
yang:insert="after"
yang:value="3des-cbc">blowfish-cbc</cipher>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
The "list" statement is used to define an interior data node in the schema tree. A list node may exist in multiple instances in the data tree. Each such instance is known as a list entry. The "list" statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed list information.
「リスト」ステートメントは、スキーマツリーの内部データノードを定義するために使用されます。データツリーの複数のインスタンスにリストノードが存在する場合があります。そのようなインスタンスはそれぞれ、リストエントリとして知られています。「リスト」ステートメントは、識別子である1つの引数を取り、その後に詳細なリスト情報を保持する置換ブロックが続きます。
A list entry is uniquely identified by the values of the list's keys, if defined.
リストエントリは、定義されている場合、リストのキーの値によって一意に識別されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| key | 7.8.2 | 0..1 |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "key" statement, which MUST be present if the list represents configuration, and MAY be present otherwise, takes as an argument a string that specifies a space-separated list of leaf identifiers of this list. A leaf identifier MUST NOT appear more than once in the key. Each such leaf identifier MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list, or in groupings used in the list.
リストが構成を表す場合に存在する必要があり、そうでない場合は存在する「キー」ステートメントは、このリストの葉の識別子のスペース分離リストを指定する文字列を引数として取得します。葉の識別子は、キーに複数回表示してはなりません。そのような各葉の識別子は、リストの子葉を参照する必要があります。葉は、リストの置換、またはリストで使用されるグループで直接定義できます。
The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. It also implies that any mandatory statement in the key leafs are ignored.
キーで指定されたすべての葉の合計値は、リストエントリを一意に識別するために使用されます。リストエントリが作成された場合、すべてのキーリーフに値を指定する必要があります。したがって、キーリーフまたはそのタイプのデフォルト値は無視されます。また、重要な葉の必須声明が無視されていることを意味します。
A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty".
キーの一部である葉は、組み込みのタイプ「空」であってはならないことを除いて、任意の組み込みまたは派生タイプのものである可能性があります。
All key leafs in a list MUST have the same value for their "config" as the list itself.
リスト内のすべてのキーリーフは、リスト自体と「構成」に対して同じ値を持っている必要があります。
The key string syntax is formally defined by the rule "key-arg" in Section 12.
キー文字列の構文は、セクション12のルール「キーARG」によって正式に定義されています。
The "unique" statement is used to put constraints on valid list entries. It takes as an argument a string that contains a space-separated list of schema node identifiers, which MUST be given in the descendant form (see the rule "descendant-schema-nodeid" in Section 12). Each such schema node identifier MUST refer to a leaf.
「一意の」ステートメントは、有効なリストエントリに制約を付けるために使用されます。それは引数として、Schemaノード識別子の空間分離されたリストを含む文字列を取得します。これは、子孫の形式で指定する必要があります（セクション12のルール「子孫 - 系統」を参照）。このような各スキーマノード識別子は、葉を参照する必要があります。
If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data.
参照されたリーフの1つが構成データを表す場合、参照されるすべてのリーフは構成データを表す必要があります。
The "unique" constraint specifies that the combined values of all the leaf instances specified in the argument string, including leafs with default values, MUST be unique within all list entry instances in which all referenced leafs exist. The constraint is enforced according to the rules in Section 8.
「一意の」制約は、デフォルト値を持つリーフを含む引数文字列で指定されたすべてのリーフインスタンスの結合値が、参照されるすべての葉が存在するすべてのリストエントリインスタンス内で一意でなければならないことを指定します。制約は、セクション8の規則に従って強制されます。
The unique string syntax is formally defined by the rule "unique-arg" in Section 12.
一意の文字列構文は、セクション12のルール「一意のARG」によって正式に定義されています。
With the following list:
次のリストで：
list server {
key "name";
unique "ip port";
leaf name {
type string;
}
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
}
}
The following configuration is not valid:
次の構成は無効です：
<server>
<name>smtp</name>
<ip>192.0.2.1</ip>
<port>25</port>
</server>
<server>
<name>http</name>
<ip>192.0.2.1</ip>
<port>25</port>
</server>
The following configuration is valid, since the "http" and "ftp" list entries do not have a value for all referenced leafs, and are thus not taken into account when the "unique" constraint is enforced:
「HTTP」および「FTP」リストエントリには参照されるすべての葉の値がないため、「一意」制約が強制されている場合は考慮されないため、次の構成が有効です。
<server>
<name>smtp</name>
<ip>192.0.2.1</ip>
<port>25</port>
</server>
<server>
<name>http</name>
<ip>192.0.2.1</ip>
</server>
<server>
<name>ftp</name>
<ip>192.0.2.1</ip>
</server>
Within a list, the "container", "leaf", "list", "leaf-list", "uses", "choice", and "anyxml" statements can be used to define child nodes to the list.
リスト内で、「コンテナ」、「リーフ」、「リスト」、「リーフリスト」、「使用」、「選択」、および「anyXML」ステートメントを使用して、子ノードをリストに定義できます。
A list is encoded as a series of XML elements, one for each entry in the list. Each element's local name is the list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リストは、リスト内の各エントリ用に1つのXML要素としてエンコードされています。各要素のローカル名はリストの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
The list's key nodes are encoded as subelements to the list's identifier element, in the same order as they are defined within the "key" statement.
リストのキーノードは、「キー」ステートメント内で定義されているのと同じ順序で、リストの識別子要素のサブレメントとしてエンコードされます。
The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order.
リストの残りの子ノードは、キーの後、リスト要素のサブエレメントとしてエンコードされます。リストがRPC入力または出力パラメーターを定義する場合、サブエレメントは「リスト」ステートメント内で定義されているのと同じ順序でエンコードされます。それ以外の場合、サブエレメントは任意の順序でエンコードされます。
The XML elements representing list entries MUST appear in the order specified by the user if the list is "ordered-by user", otherwise the order is implementation-dependent. The XML elements representing list entries MAY be interleaved with other sibling elements, unless the list defines RPC input or output parameters.
リストエントリを表すXML要素は、リストが「ユーザーごとに順序付け」である場合、ユーザーが指定した順序で表示する必要があります。リストエントリを表すXML要素は、リストがRPC入力または出力パラメーターを定義しない限り、他の兄弟要素とインターリーブする場合があります。
List entries can be created, deleted, replaced, and modified through <edit-config>, by using the "operation" attribute in the list's XML element. In each case, the values of all keys are used to uniquely identify a list entry. If all keys are not specified for a list entry, a "missing-element" error is returned.
リストのXML要素に「操作」属性を使用して、リストエントリを<edit-config>を介して作成、削除、交換、および変更できます。いずれの場合も、すべてのキーの値を使用して、リストエントリを一意に識別します。すべてのキーがリストエントリに指定されていない場合、「欠落要素」エラーが返されます。
In an "ordered-by user" list, the attributes "insert" and "key" in the YANG XML namespace (Section 5.3.1) can be used to control where in the list the entry is inserted. These can be used during "create" operations to insert a new list entry, or during "merge" or "replace" operations to insert a new list entry or move an existing one.
「並べ替えられたユーザー」リストでは、Yang XMLネームスペース（セクション5.3.1）の属性「挿入」と「キー」を使用して、リストのエントリが挿入されている場所を制御できます。これらを「作成」操作中に使用して、新しいリストエントリを挿入するか、「マージ」または「交換」操作中に新しいリストエントリを挿入したり、既存のリストを移動したりできます。
The "insert" attribute can take the values "first", "last", "before", and "after". If the value is "before" or "after", the "key" attribute MUST also be used, to specify an existing element in the list. The value of the "key" attribute is the key predicates of the full instance identifier (see Section 9.13) for the list entry.
「挿入」属性は、最初に値を「最後」、「前」、「後」を取得できます。値が「前」または「後」の場合、リスト内の既存の要素を指定するために「キー」属性も使用する必要があります。「キー」属性の値は、リストエントリの完全なインスタンス識別子（セクション9.13を参照）のキー述語です。
If no "insert" attribute is present in the "create" operation, it defaults to "last".
「Create」操作に「挿入」属性が存在しない場合、デフォルトは「最後」になります。
If several entries in an "ordered-by user" list are modified in the same <edit-config> request, the entries are modified one at the time, in the order of the XML elements in the request.
「Ordered-byユーザー」リストのいくつかのエントリが同じ<edit-config>リクエストで変更された場合、リクエストのXML要素の順序で、その時点でエントリが変更されます。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire list, the list entry order is the same as the order of the XML elements in the request.
<copy-config>、またはリスト全体をカバーする「置き換え」操作を備えた<edit-config>では、リストエントリの順序はリクエストのXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a list node are:
NetConfサーバーが<edit-config>リクエストを処理する場合、リストノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the list entry is created if it does not exist. If the list entry already exists and the "insert" and "key" attributes are present, the list entry is moved according to the values of the "insert" and "key" attributes. If the list entry exists and the "insert" and "key" attributes are not present, the list entry is not moved.
操作が「マージ」または「交換」の場合、リストエントリが存在しない場合に作成されます。リストエントリが既に存在し、「挿入」と「キー」属性が存在する場合、リストエントリは「挿入」および「キー」属性の値に従って移動されます。リストエントリが存在し、「挿入」と「キー」属性が存在しない場合、リストエントリは移動しません。
If the operation is "create", the list entry is created if it does not exist. If the list entry already exists, a "data-exists" error is returned.
操作が「作成」の場合、リストエントリが存在しない場合に作成されます。リストエントリが既に存在する場合、「データ存在」エラーが返されます。
If the operation is "delete", the entry is deleted from the list if it exists. If the list entry does not exist, a "data-missing" error is returned.
操作が「削除」の場合、エントリが存在する場合、エントリはリストから削除されます。リストエントリが存在しない場合、「データミッシング」エラーが返されます。
Given the following list:
次のリストが与えられます。
list user {
key "name";
config true;
description "This is a list of users in the system.";
leaf name {
type string;
}
leaf type {
type string;
}
leaf full-name {
type string;
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
</user>
To create a new user "barney":
新しいユーザー「バーニー」を作成するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<user nc:operation="create">
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
</user>
</system>
</config>
</edit-config>
</rpc>
To change the type of "fred" to "superuser":
「フレッド」のタイプを「スーパーユーザー」に変更するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<user>
<name>fred</name>
<type>superuser</type>
</user>
</system>
</config>
</edit-config>
</rpc>
Given the following ordered-by user list:
次の注文されたユーザーリストが与えられます。
list user {
description "This is a list of users in the system.";
ordered-by user;
config true;
key "name";
キー「名前」;
leaf name {
type string;
}
leaf type {
type string;
}
leaf full-name {
type string;
}
}
The following would be used to insert a new user "barney" after the user "fred":
以下は、ユーザー「フレッド」の後に新しいユーザー「バーニー」を挿入するために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config"
xmlns:ex="http://example.com/schema/config">
<user nc:operation="create"
yang:insert="after"
yang:key="[ex:name='fred']">
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
</user>
</system>
</config>
</edit-config>
</rpc>
The following would be used to move the user "barney" before the user "fred":
以下は、ユーザー「Fred」の前にユーザー「Barney」を移動するために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config"
xmlns:ex="http://example.com/schema/config">
<user nc:operation="merge"
yang:insert="before"
yang:key="[ex:name='fred']">
<name>barney</name>
</user>
</system>
</config>
</edit-config>
</rpc>
The "choice" statement defines a set of alternatives, only one of which may exist at any one time. The argument is an identifier, followed by a block of substatements that holds detailed choice information. The identifier is used to identify the choice node in the schema tree. A choice node does not exist in the data tree.
「選択」ステートメントは、一連の代替案を定義しますが、そのうちの1つだけが一度に存在する可能性があります。引数は識別子であり、その後、詳細な選択情報を保持する置換ブロックが続きます。識別子は、スキーマツリーの選択ノードを識別するために使用されます。データツリーには選択ノードが存在しません。
A choice consists of a number of branches, defined with the "case" substatement. Each branch contains a number of child nodes. The nodes from at most one of the choice's branches exist at the same time.
選択は、「ケース」の代替物で定義された多くの枝で構成されています。各ブランチには、多くの子ノードが含まれています。せいぜい1つの選択肢のブランチのノードは、同時に存在します。
See Section 8.3.2 for additional information.
詳細については、セクション8.3.2を参照してください。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| mandatory | 7.9.4 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "case" statement is used to define branches of the choice. It takes as an argument an identifier, followed by a block of substatements that holds detailed case information.
「ケース」ステートメントは、選択の枝を定義するために使用されます。それは引数として識別子を受け取り、その後、詳細なケース情報を保持する置換ブロックが続きます。
The identifier is used to identify the case node in the schema tree. A case node does not exist in the data tree.
識別子は、スキーマツリーのケースノードを識別するために使用されます。データツリーにはケースノードが存在しません。
Within a "case" statement, the "anyxml", "choice", "container", "leaf", "list", "leaf-list", and "uses" statements can be used to define child nodes to the case node. The identifiers of all these child nodes MUST be unique within all cases in a choice. For example, the following is illegal:
「ケース」ステートメント内で、「anyxml」、「choice」、「container」、「leaf "、" list "、" leaf-list "、および" leaf-list "、および「leaf-list」、および「leaf-list」を使用して、ケースノードに子ノードを定義できます。。これらすべての子ノードの識別子は、選択したすべての場合に一意でなければなりません。たとえば、以下は違法です。
choice interface-type { // This example is illegal YANG
case a {
leaf ethernet { ... }
}
case b {
container ethernet { ...}
}
}
As a shorthand, the "case" statement can be omitted if the branch contains a single "anyxml", "container", "leaf", "list", or "leaf-list" statement. In this case, the identifier of the case node is the same as the identifier in the branch statement. The following example:
速記として、ブランチに単一の「anyxml」、「コンテナ」、「リーフ」、「リスト」、または「リーフリスト」ステートメントが含まれている場合、「ケース」ステートメントを省略できます。この場合、ケースノードの識別子は、ブランチステートメントの識別子と同じです。次の例：
choice interface-type {
container ethernet { ... }
}
is equivalent to:
に相当します：
choice interface-type {
case ethernet {
container ethernet { ... }
}
}
The case identifier MUST be unique within a choice.
ケース識別子は、選択の範囲内で一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "default" statement indicates if a case should be considered as the default if no child nodes from any of the choice's cases exist. The argument is the identifier of the "case" statement. If the "default" statement is missing, there is no default case.
「デフォルト」ステートメントは、選択のケースのいずれかの子ノードが存在しない場合、ケースをデフォルトと見なすべきかどうかを示します。引数は、「ケース」ステートメントの識別子です。「デフォルト」ステートメントが欠落している場合、デフォルトのケースはありません。
The "default" statement MUST NOT be present on choices where "mandatory" is true.
「デフォルト」ステートメントは、「必須」が真である選択に存在してはなりません。
The default case is only important when considering the default values of nodes under the cases. The default values for nodes under the default case are used if none of the nodes under any of the cases are present.
デフォルトのケースは、ケースの下でノードのデフォルト値を考慮する場合にのみ重要です。デフォルトのケースでのノードのデフォルト値は、いずれかのケースの下にあるノードが存在しない場合に使用されます。
There MUST NOT be any mandatory nodes (Section 3.1) directly under the default case.
デフォルトのケースに直接、必須ノード（セクション3.1）はありません。
Default values for child nodes under a case are only used if one of the nodes under that case is present, or if that case is the default case. If none of the nodes under a case are present and the case is not the default case, the default values of the cases' child nodes are ignored.
ケースの下の子ノードのデフォルト値は、そのケースに基づくノードの1つが存在する場合、またはそのケースがデフォルトのケースである場合にのみ使用されます。ケースの下にあるノードが存在せず、ケースがデフォルトのケースではない場合、ケースのデフォルト値の子ノードは無視されます。
In this example, the choice defaults to "interval", and the default value will be used if none of "daily", "time-of-day", or "manual" are present. If "daily" is present, the default value for "time-of-day" will be used.
この例では、選択は「間隔」にデフォルトであり、デフォルト値は「毎日」、「日時」、または「マニュアル」が存在しない場合に使用されます。「毎日」が存在する場合、「日時」のデフォルト値が使用されます。
container transfer {
choice how {
default interval;
case interval {
leaf interval {
type uint16;
default 30;
units minutes;
}
}
case daily {
leaf daily {
type empty;
}
leaf time-of-day {
type string;
units 24-hour-clock;
default 1am;
}
}
case manual {
leaf manual {
type empty;
}
}
}
}
The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If "mandatory" is "true", at least one node from exactly one of the choice's case branches MUST exist.
オプションである「必須」ステートメントは、文字列「真」または「false」という引数として取得し、有効なデータに制約を付けます。「必須」が「true」である場合、選択したケースブランチの1つから少なくとも1つのノードが存在する必要があります。
If not specified, the default is "false".
指定されていない場合、デフォルトは「false」です。
The behavior of the constraint depends on the type of the choice's closest ancestor node in the schema tree which is not a non-presence container (see Section 7.5.1):
制約の動作は、非表現容器ではないスキーマツリーで選択の最も近い祖先ノードのタイプに依存します（セクション7.5.1を参照）。
o If this ancestor is a case node, the constraint is enforced if any other node from the case exists.
o この祖先がケースノードである場合、ケースの他のノードが存在する場合、制約が施行されます。
o Otherwise, it is enforced if the ancestor node exists.
o それ以外の場合は、祖先ノードが存在する場合に施行されます。
The constraint is further enforced according to the rules in Section 8.
制約は、セクション8の規則に従ってさらに強制されます。
The choice and case nodes are not visible in XML.
XMLでは、選択ノードとケースノードが表示されません。
The child nodes of the selected "case" statement MUST be encoded in the same order as they are defined in the "case" statement if they are part of an RPC input or output parameter definition. Otherwise, the subelements are encoded in any order.
選択した「ケース」ステートメントの子ノードは、RPC入力または出力パラメーター定義の一部である場合、「ケース」ステートメントで定義されているのと同じ順序でエンコードする必要があります。それ以外の場合、サブエレメントは任意の順序でエンコードされます。
Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If an <edit-config> operation creates a node from a case, the NETCONF server will delete any existing nodes that are defined in other cases inside the choice.
選択のケースの1つだけがいつでも有効であるため、1つのケースからノードを作成すると、他のすべてのケースからすべてのノードを暗黙的に削除します。<edit-config>操作がケースからノードを作成すると、NetConfサーバーは、選択内の他のケースで定義されている既存のノードを削除します。
Given the following choice:
次の選択が与えられます：
container protocol {
choice name {
case a {
leaf udp {
type empty;
}
}
case b {
leaf tcp {
type empty;
}
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<protocol>
<tcp/>
</protocol>
To change the protocol from tcp to udp:
プロトコルをTCPからUDPに変更するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<protocol>
<udp nc:operation="create"/>
</protocol>
</system>
</config>
</edit-config>
</rpc>
The "anyxml" statement defines an interior node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed anyxml information.
「anyXML」ステートメントは、スキーマツリーの内部ノードを定義しています。識別子である1つの引数が必要であり、詳細なanyXML情報を保持する置換ブロックが続きます。
The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. This can be useful, for example, in RPC replies. An example is the <filter> parameter in the <get-config> operation.
「anyXML」ステートメントは、XMLの未知のチャンクを表すために使用されます。XMLには制限はありません。これは、たとえばRPC Repliesで役立つ場合があります。例は、<get-config>操作の<filter>パラメーターです。
An anyxml node cannot be augmented (see Section 7.15).
AnyXMLノードは拡張できません（セクション7.15を参照）。
Since the use of anyxml limits the manipulation of the content, it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data.
anyXMLを使用すると、コンテンツの操作が制限されるため、「anyXML」ステートメントを使用して構成データを表すことをお勧めします。
An anyxml node exists in zero or one instances in the data tree.
anyXMLノードは、データツリーのゼロまたは1つのインスタンスで存在します。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
An anyxml node is encoded as an XML element. The element's local name is the anyxml's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of the anyxml node is encoded as XML content of this element.
anyXMLノードはXML要素としてエンコードされます。要素のローカル名はanyXMLの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。anyXMLノードの値は、この要素のXMLコンテンツとしてエンコードされます。
Note that any prefixes used in the encoding are local to each instance encoding. This means that the same XML may be encoded differently by different implementations.
エンコードで使用されるプレフィックスは、各インスタンスエンコードにローカルであることに注意してください。これは、同じXMLが異なる実装によって異なってエンコードされる可能性があることを意味します。
An anyxml node is treated as an opaque chunk of data. This data can be modified in its entirety only.
anyXMLノードは、不透明なデータの塊として扱われます。このデータは全体でのみ変更できます。
Any "operation" attributes present on subelements of an anyxml node are ignored by the NETCONF server.
anyXMLノードのサブエレメントに存在する「操作」属性は、NetConfサーバーによって無視されます。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the anyxml node are:
NetConfサーバーが<edit-config>リクエストを処理する場合、anyXMLノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data.
操作が「マージ」または「置換」の場合、ノードが存在しない場合にノードが作成され、その値はXML RPCデータにあるanyXMLノードのXMLコンテンツに設定されます。
If the operation is "create", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the node already exists, a "data-exists" error is returned.
操作が「作成」の場合、ノードが存在しない場合にノードが作成され、その値はXML RPCデータにあるanyXMLノードのXMLコンテンツに設定されます。ノードが既に存在する場合、「データ存在」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在する場合にノードが削除されます。ノードが存在しない場合、「データミッシング」エラーが返されます。
Given the following "anyxml" statement:
次の「anyxml」ステートメントが与えられます。
anyxml data;
anyxmlデータ;
The following are two valid encodings of the same anyxml value:
以下は、同じAnyXML値の2つの有効なエンコーディングです。
<data xmlns:if="http://example.com/ns/interface">
<if:interface>
<if:ifIndex>1</if:ifIndex>
</if:interface>
</data>
<data>
<interface xmlns="http://example.com/ns/interface">
<ifIndex>1</ifIndex>
</interface>
</data>
The "grouping" statement is used to define a reusable block of nodes, which may be used locally in the module, in modules that include it, and by other modules that import from it, according to the rules in Section 5.5. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed grouping information.
「グループ化」ステートメントは、セクション5.5のルールに従って、モジュール、それを含むモジュール、およびそこからインポートする他のモジュールで局所的に使用できるノードの再利用可能なブロックを定義するために使用されます。識別子である1つの引数が必要であり、詳細なグループ化情報を保持する置換ブロックが続きます。
The "grouping" statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
「グループ化」ステートメントはデータ定義ステートメントではなく、スキーマツリーのノードを定義しません。
A grouping is like a "structure" or a "record" in conventional programming languages.
グループ化は、従来のプログラミング言語の「構造」または「レコード」のようなものです。
Once a grouping is defined, it can be referenced in a "uses" statement (see Section 7.12). A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings.
グループ化が定義されると、「使用」ステートメントで参照できます（セクション7.12を参照）。グループは、他のグループのチェーンを通じて直接または間接的にも、それ自体を参照してはなりません。
If the grouping is defined at the top level of a YANG module or submodule, the grouping's identifier MUST be unique within the module.
グループ化がYangモジュールまたはサブモジュールの最上位レベルで定義されている場合、グループ化の識別子はモジュール内で一意でなければなりません。
A grouping is more than just a mechanism for textual substitution, but defines a collection of nodes. Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used. Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the "grouping" statement appears. For extensions, this means that extensions are applied to the grouping node, not the uses node.
グループ化は、単なるテキスト代替のメカニズムではありませんが、ノードのコレクションを定義します。グループ内に表示される識別子は、使用されている場所ではなく、グループ化が定義されている範囲に対して解決されます。接頭辞マッピング、タイプ名、グループ化名、および拡張使用法は、「グループ化」ステートメントが表示される階層で評価されます。拡張機能の場合、これは、使用ノードではなく、拡張機能がグループノードに適用されることを意味します。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
import ietf-inet-types {
prefix "inet";
}
grouping endpoint {
description "A reusable endpoint group.";
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
}
}
The "uses" statement is used to reference a "grouping" definition. It takes one argument, which is the name of the grouping.
「使用」ステートメントは、「グループ化」定義を参照するために使用されます。グループの名前である1つの議論が必要です。
The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, and then updated according to the "refine" and "augment" statements.
グループ化への「使用」参照の効果は、グループ化によって定義されたノードが現在のスキーマツリーにコピーされ、「改良」および「拡大」ステートメントに従って更新されることです。
The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module.
グループ化で定義された識別子は、グループの内容が「グループ」ステートメント内に表示されない「使用」ステートメントを介してスキーマツリーに追加されるまで、名前空間にバインドされません。現在のモジュールの。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| augment | 7.15 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| refine | 7.12.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
Some of the properties of each node in the grouping can be refined with the "refine" statement. The argument is a string that identifies a node in the grouping. This node is called the refine's target node. If a node in the grouping is not present as a target node of a "refine" statement, it is not refined, and thus used exactly as it was defined in the grouping.
グループ内の各ノードのプロパティの一部は、「洗練」ステートメントで洗練できます。引数は、グループ内のノードを識別する文字列です。このノードは、Refineのターゲットノードと呼ばれます。グループ内のノードが「洗練」ステートメントのターゲットノードとして存在しない場合、洗練されていないため、グループで定義されているとまったく同じように使用されます。
The argument string is a descendant schema node identifier (see Section 6.5).
引数文字列は、子孫スキーマノード識別子です（セクション6.5を参照）。
The following refinements can be done:
次の改良を行うことができます。
o A leaf or choice node may get a default value, or a new default value if it already had one.
o リーフまたは選択ノードは、デフォルト値を取得する場合があります。また、既にある場合は新しいデフォルト値を取得できます。
o Any node may get a specialized "description" string.
o 任意のノードは、専門の「説明」文字列を取得する場合があります。
o Any node may get a specialized "reference" string.
o 任意のノードは、特殊な「参照」文字列を取得する場合があります。
o Any node may get a different "config" statement.
o 任意のノードは、別の「構成」ステートメントを取得する場合があります。
o A leaf, anyxml, or choice node may get a different "mandatory" statement.
o リーフ、AnyXML、または選択ノードは、別の「必須」ステートメントを取得する場合があります。
o A container node may get a "presence" statement.
o コンテナノードには、「存在」ステートメントが表示される場合があります。
o A leaf, leaf-list, list, container, or anyxml node may get additional "must" expressions.
o 葉、葉のリスト、リスト、コンテナ、またはanyXMLノードは、追加の「必須」式を取得する場合があります。
o A leaf-list or list node may get a different "min-elements" or "max-elements" statement.
o リーフリストまたはリストノードは、異なる「最小要素」または「最大要素」ステートメントを取得する場合があります。
Each node in the grouping is encoded as if it was defined inline, even if it is imported from another module with another XML namespace.
グループ内の各ノードは、別のXMLネームスペースを持つ別のモジュールからインポートされていても、インラインで定義されているかのようにエンコードされます。
To use the "endpoint" grouping defined in Section 7.11.2 in a definition of an HTTP server in some other module, we can do:
他のモジュールのHTTPサーバーの定義でセクション7.11.2で定義されている「エンドポイント」グループ化を使用するには、次のことができます。
import acme-system {
prefix "acme";
}
container http-server {
leaf name {
type string;
}
uses acme:endpoint;
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<http-server>
<name>extern-web</name>
<ip>192.0.2.1</ip>
<port>80</port>
</http-server>
If port 80 should be the default for the HTTP server, default can be added:
ポート80がHTTPサーバーのデフォルトである場合、デフォルトを追加できます。
container http-server {
leaf name {
type string;
}
uses acme:endpoint {
refine port {
default 80;
}
}
}
If we want to define a list of servers, and each server has the ip and port as keys, we can do:
サーバーのリストを定義したい場合、各サーバーにはキーとしてIPとポートがある場合は、次のことができます。
list server {
key "ip port";
leaf name {
type string;
}
uses acme:endpoint;
}
The following is an error:
以下はエラーです。
container http-server {
uses acme:endpoint;
leaf ip { // illegal - same identifier "ip" used twice
type string;
}
}
The "rpc" statement is used to define a NETCONF RPC operation. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed rpc information. This argument is the name of the RPC, and is used as the element name directly under the <rpc> element, as designated by the substitution group "rpcOperation" in [RFC4741].
The "rpc" statement defines an rpc node in the schema tree. Under the rpc node, a schema node with the name "input", and a schema node with the name "output" are also defined. The nodes "input" and "output" are defined in the module's namespace.
「RPC」ステートメントは、スキーマツリーのRPCノードを定義しています。RPCノードの下では、「入力」という名前のスキーマノードと、「出力」という名前のスキーマノードも定義されています。ノード「入力」と「出力」は、モジュールの名前空間で定義されています。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
The "input" statement, which is optional, is used to define input parameters to the RPC operation. It does not take an argument. The substatements to "input" define nodes under the RPC's input node.
オプションである「入力」ステートメントは、RPC操作に入力パラメーターを定義するために使用されます。それは議論をしません。「入力」の置換は、RPCの入力ノードの下でノードを定義します。
If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. Otherwise, the server MUST return a "missing-element" error.
入力ツリーの葉に「True」の値が付いた「必須」ステートメントがある場合、葉はNetConf RPCの呼び出しに存在する必要があります。それ以外の場合、サーバーは「欠落要素」エラーを返す必要があります。
If a leaf in the input tree has a default value, the NETCONF server MUST use this value in the same cases as described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the NETCONF RPC invocation with the default value as its value.
入力ツリーのリーフにデフォルト値がある場合、NetConfサーバーは、セクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。これらの場合、サーバーは、葉がNetConf RPCの呼び出しにデフォルト値をその値として存在するかのように動作的に動作する必要があります。
If a "config" statement is present for any node in the input tree, the "config" statement is ignored.
入力ツリー内のノードに対して「config」ステートメントが存在する場合、「config」ステートメントは無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the input tree.
任意のノードにfalseと評価される「When」ステートメントがある場合、このノードは入力ツリーに存在してはなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
The "output" statement, which is optional, is used to define output parameters to the RPC operation. It does not take an argument. The substatements to "output" define nodes under the RPC's output node.
オプションである「出力」ステートメントは、RPC操作に出力パラメーターを定義するために使用されます。それは議論をしません。「出力」の置換は、RPCの出力ノードの下でノードを定義します。
If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC reply.
出力ツリーの葉に「True」の値が付いた「必須」ステートメントがある場合、葉はNetConf RPCの返信に存在する必要があります。
If a leaf in the output tree has a default value, the NETCONF client MUST use this value in the same cases as described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF RPC reply with the default value as its value.
出力ツリーのリーフにデフォルト値がある場合、NetConfクライアントはセクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。これらの場合、クライアントは、NetConf RPCの葉がデフォルト値をその値として返信しているかのように操作的に動作する必要があります。
If a "config" statement is present for any node in the output tree, the "config" statement is ignored.
出力ツリー内のノードに対して「config」ステートメントが存在する場合、「config」ステートメントは無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the output tree.
任意のノードにfalseと評価される「When」ステートメントがある場合、このノードは出力ツリーに存在してはなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
An rpc node is encoded as a child XML element to the <rpc> element defined in [RFC4741]. The element's local name is the rpc's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
RPCノードは、[RFC4741]で定義された<RPC>要素の子XML要素としてエンコードされます。要素のローカル名はRPCの識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
Input parameters are encoded as child XML elements to the rpc node's XML element, in the same order as they are defined within the "input" statement.
入力パラメーターは、「入力」ステートメント内で定義されているのと同じ順序で、RPCノードのXML要素の子XML要素としてエンコードされます。
If the RPC operation invocation succeeded, and no output parameters are returned, the <rpc-reply> contains a single <ok/> element defined in [RFC4741]. If output parameters are returned, they are encoded as child elements to the <rpc-reply> element defined in [RFC4741], in the same order as they are defined within the "output" statement.
RPC操作の呼び出しが成功し、出力パラメーターが返されない場合、<rpc-reply>には[rfc4741]で定義された単一の<ok/>要素が含まれます。出力パラメーターが返されると、[RFC4741]で定義された<RPC-Reply>要素の子要素として、「出力」ステートメント内で定義されているのと同じ順序でエンコードされます。
The following example defines an RPC operation:
次の例は、RPC操作を定義しています。
module rock { namespace "http://example.net/rock"; prefix "rock";
Module Rock {namespace "http://example.net/rock";接頭辞「ロック」;
rpc rock-the-house {
input {
leaf zip-code {
type string;
}
}
}
}
A corresponding XML instance example of the complete rpc and rpc-reply:
完全なRPCおよびRPC-Replyの対応するXMLインスタンスの例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The "notification" statement is used to define a NETCONF notification. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed notification information. The "notification" statement defines a notification node in the schema tree.
「通知」ステートメントは、NetConf通知を定義するために使用されます。識別子である1つの引数が必要であり、その後に詳細な通知情報を保持する置換ブロックが続きます。「通知」ステートメントは、スキーマツリーの通知ノードを定義しています。
If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF notification.
通知ツリーの葉に「True」の値が付いた「必須」ステートメントがある場合、葉はNetConf通知に存在する必要があります。
If a leaf in the notification tree has a default value, the NETCONF client MUST use this value in the same cases as described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF notification with the default value as its value.
通知ツリーのリーフにデフォルト値がある場合、NetConfクライアントはセクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。これらの場合、クライアントは、デフォルト値をその値として、葉がNetConf通知に存在するかのように動作的に動作する必要があります。
If a "config" statement is present for any node in the notification tree, the "config" statement is ignored.
通知ツリー内のノードに対して「config」ステートメントが存在する場合、「config」ステートメントは無視されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
A notification node is encoded as a child XML element to the <notification> element defined in NETCONF Event Notifications [RFC5277]. The element's local name is the notification's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
通知ノードは、NetConfイベント通知[RFC5277]で定義された<通知>要素の子XML要素としてエンコードされます。要素のローカル名は通知の識別子であり、その名前空間はモジュールのXMLネームスペースです（セクション7.1.3を参照）。
The following example defines a notification:
次の例は、通知を定義しています。
module event {
モジュールイベント{
namespace "http://example.com/event"; prefix "ev";
namespace "http://example.com/event";プレフィックス「ev」;
notification event {
leaf event-class {
type string;
}
anyxml reporting-entity;
leaf severity {
type string;
}
}
}
A corresponding XML instance example of the complete notification:
完全な通知の対応するXMLインスタンスの例：
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event">
<event-class>fault</event-class>
<reporting-entity>
<card>Ethernet0</card>
</reporting-entity>
<severity>major</severity>
</event>
</notification>
The "augment" statement allows a module or submodule to add to the schema tree defined in an external module, or the current module and its submodules, and to add to the nodes from a grouping in a "uses" statement. The argument is a string that identifies a node in the schema tree. This node is called the augment's target node. The target node MUST be either a container, list, choice, case, input, output, or notification node. It is augmented with the nodes defined in the substatements that follow the "augment" statement.
「Augment」ステートメントでは、モジュールまたはサブモジュールが外部モジュール、または現在のモジュールとそのサブモジュールで定義されたスキーマツリーに追加し、「使用」ステートメントのグループ化からノードに追加することができます。引数は、スキーマツリーのノードを識別する文字列です。このノードは、Augmentのターゲットノードと呼ばれます。ターゲットノードは、コンテナ、リスト、選択、ケース、入力、出力、または通知ノードのいずれかである必要があります。「Augment」ステートメントに続く置換で定義されたノードで補強されています。
The argument string is a schema node identifier (see Section 6.5). If the "augment" statement is on the top level in a module or submodule, the absolute form (defined by the rule
引数文字列はスキーマノード識別子です（セクション6.5を参照）。「Augment」ステートメントがモジュールまたはサブモジュールの上位レベルにある場合、絶対形式（ルールで定義されています
"absolute-schema-nodeid" in Section 12) of a schema node identifier MUST be used. If the "augment" statement is a substatement to the "uses" statement, the descendant form (defined by the rule "descendant-schema-nodeid" in Section 12) MUST be used.
スキーマノード識別子のセクション12）の「絶対的な節形」を使用する必要があります。「Augment」ステートメントが「使用」ステートメントへの代替である場合、子孫形式（セクション12の「子孫」の系統」で定義されている）を使用する必要があります。
If the target node is a container, list, case, input, output, or notification node, the "container", "leaf", "list", "leaf-list", "uses", and "choice" statements can be used within the "augment" statement.
ターゲットノードがコンテナ、リスト、ケース、入力、または通知ノード、「コンテナ」、「リーフ」、「リスト」、「リーフリスト」、「使用」、および「選択」ステートメントである場合「Augment」ステートメント内で使用されます。
If the target node is a choice node, the "case" statement, or a case shorthand statement (see Section 7.9.2) can be used within the "augment" statement.
ターゲットノードが選択ノードである場合、「ケース」ステートメント、またはケースの速記ステートメント（セクション7.9.2を参照）を「Augment」ステートメント内で使用できます。
If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see Section 3.1).
ターゲットノードが別のモジュールにある場合、拡張によって追加されたノードは必須ノードである必要があります（セクション3.1を参照）。
The "augment" statement MUST NOT add multiple nodes with the same name from the same module to the target node.
「Augment」ステートメントは、同じモジュールからターゲットノードに同じ名前の複数のノードを追加してはなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
All data nodes defined in the "augment" statement are defined as XML elements in the XML namespace of the module where the "augment" is specified.
「Augment」ステートメントで定義されているすべてのデータノードは、「Augment」が指定されているモジュールのXMLネームスペースのXML要素として定義されます。
When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order.
ノードが拡張されると、拡張子ノードは、任意の順序で拡張ノードのサブエレメントとしてエンコードされます。
In namespace http://example.com/schema/interfaces, we have:
名前空間http://example.com/schema/interfacesには、次のことがあります。
container interfaces {
list ifEntry {
key "ifIndex";
leaf ifIndex {
type uint32;
}
leaf ifDescr {
type string;
}
leaf ifType {
type iana:IfType;
}
leaf ifMtu {
type int32;
}
}
}
Then, in namespace http://example.com/schema/ds0, we have:
次に、名前空間http://example.com/schema/ds0に、次のようになります。
import interface-module {
prefix "if";
}
augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'";
leaf ds0ChannelNumber {
type ChannelNumber;
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<interfaces xmlns="http://example.com/schema/interfaces"
xmlns:ds0="http://example.com/schema/ds0">
<ifEntry>
<ifIndex>1</ifIndex>
<ifDescr>Flintstone Inc Ethernet A562</ifDescr>
<ifType>ethernetCsmacd</ifType>
<ifMtu>1500</ifMtu>
</ifEntry>
<ifEntry>
<ifIndex>2</ifIndex>
<ifDescr>Flintstone Inc DS0</ifDescr>
<ifType>ds0</ifType>
<ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
</ifEntry>
</interfaces>
As another example, suppose we have the choice defined in Section 7.9.7. The following construct can be used to extend the protocol definition:
別の例として、セクション7.9.7で定義されている選択肢があるとします。次の構造を使用して、プロトコル定義を拡張できます。
augment /ex:system/ex:protocol/ex:name {
case c {
leaf smtp {
type empty;
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<ex:system>
<ex:protocol>
<ex:tcp/>
</ex:protocol>
</ex:system>
or
また
<ex:system>
<ex:protocol>
<other:smtp/>
</ex:protocol>
</ex:system>
The "identity" statement is used to define a new globally unique, abstract, and untyped identity. Its only purpose is to denote its name, semantics, and existence. An identity can either be defined from scratch or derived from a base identity. The identity's argument is an identifier that is the name of the identity. It is followed by a block of substatements that holds detailed identity information.
「アイデンティティ」ステートメントは、新しいグローバルでユニークで抽象的で、未積分のアイデンティティを定義するために使用されます。その唯一の目的は、その名前、セマンティクス、存在を示すことです。アイデンティティは、ゼロから定義するか、ベースアイデンティティから導き出されます。アイデンティティの議論は、アイデンティティの名前である識別子です。その後、詳細なID情報を保持する置換のブロックが続きます。
The built-in datatype "identityref" (see Section 9.10) can be used to reference identities within a data model.
組み込みのデータ型「IdentityRef」（セクション9.10を参照）を使用して、データモデル内のアイデンティティを参照できます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| base | 7.16.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
The "base" statement, which is optional, takes as an argument a string that is the name of an existing identity, from which the new identity is derived. If no "base" statement is present, the identity is defined from scratch.
オプションである「ベース」ステートメントは、新しいアイデンティティが導き出される既存のアイデンティティの名前である文字列を引数として取得します。「ベース」ステートメントが存在しない場合、アイデンティティはゼロから定義されます。
If a prefix is present on the base name, it refers to an identity defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule.
接頭辞がベース名に存在する場合、そのプレフィックスでインポートされたモジュールで定義されたID、またはプレフィックスがローカルモジュールのプレフィックスと一致する場合はローカルモジュールを指します。それ以外の場合、一致する名前を持つIDは、現在のモジュールまたは含まれるサブモジュールで定義する必要があります。
Since submodules cannot include the parent module, any identities in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the identity.
サブモジュールには親モジュールを含めることはできないため、サブモジュールにさらされる必要があるモジュール内のアイデンティティをサブモジュールで定義する必要があります。サブモジュールは、このサブモジュールを含めて、アイデンティティの定義を見つけることができます。
An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.
アイデンティティは、他のアイデンティティのチェーンを介して直接または間接的にもそれ自体を参照してはなりません。
module crypto-base { namespace "http://example.com/crypto-base"; prefix "crypto";
モジュールcrypto-base {namespace "http://example.com/crypto-base";プレフィックス「crypto」;
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
}
module des { namespace "http://example.com/des"; prefix "des";
モジュールdes {namespace "http://example.com/des";プレフィックス「des」;
import "crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
description "Triple DES crypto algorithm";
}
}
The "extension" statement allows the definition of new statements within the YANG language. This new statement definition can be imported and used by other modules.
「拡張機能」ステートメントは、ヤン言語内の新しいステートメントの定義を許可します。この新しいステートメント定義は、他のモジュールによってインポートおよび使用できます。
The statement's argument is an identifier that is the new keyword for the extension and must be followed by a block of substatements that holds detailed extension information. The purpose of the "extension" statement is to define a keyword, so that it can be imported and used by other modules.
ステートメントの引数は、拡張の新しいキーワードである識別子であり、詳細な拡張情報を保持する置換ブロックが続く必要があります。「拡張機能」ステートメントの目的は、キーワードを定義して、他のモジュールによってインポートおよび使用できるようにすることです。
The extension can be used like a normal YANG statement, with the statement name followed by an argument if one is defined by the extension, and an optional block of substatements. The statement's name is created by combining the prefix of the module in which the extension was defined, a colon (":"), and the extension's keyword, with no interleaving whitespace. The substatements of an extension are defined by the extension, using some mechanism outside the scope of this specification. Syntactically, the substatements MUST be YANG statements, or also defined using "extension" statements. YANG statements in extensions MUST follow the syntactical rules in Section 12.
拡張機能は、通常のYangステートメントのように使用できます。ステートメント名は、拡張機能によって定義されている場合に引数が続き、置換のオプションブロックが続きます。ステートメントの名前は、拡張機能が定義されているモジュールの接頭辞、コロン（ "："）、および拡張機能のキーワードを組み合わせて作成します。拡張の置換は、この仕様の範囲外のいくつかのメカニズムを使用して、拡張によって定義されます。構文的に、置換はヤンステートメントであるか、「拡張」ステートメントを使用して定義されている必要があります。拡張機能のYangステートメントは、セクション12の構文規則に従う必要があります。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| argument | 7.17.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
The "argument" statement, which is optional, takes as an argument a string that is the name of the argument to the keyword. If no argument statement is present, the keyword expects no argument when it is used.
オプションである「引数」ステートメントは、キーワードへの引数の名前である文字列を引数として取得します。引数ステートメントが存在しない場合、キーワードは使用されたときに引数を期待しません。
The argument's name is used in the YIN mapping, where it is used as an XML attribute or element name, depending on the argument's "yin-element" statement.
引数の名前は、Yinマッピングで使用されます。ここでは、引数の「Yin-Element」ステートメントに応じて、XML属性または要素名として使用されます。
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| yin-element | 7.17.2.2 | 0..1 |
+--------------+----------+-------------+
The "yin-element" statement, which is optional, takes as an argument the string "true" or "false". This statement indicates if the argument is mapped to an XML element in YIN or to an XML attribute (see Section 11).
オプションである「Yin-Element」ステートメントは、文字列「True」または「False」を引数として取得します。このステートメントは、引数が陰のXML要素またはXML属性にマッピングされているかどうかを示します（セクション11を参照）。
If no "yin-element" statement is present, it defaults to "false".
「yin-element」ステートメントが存在しない場合、デフォルトは「false」になります。
To define an extension:
拡張機能を定義するには：
module my-extensions { ...
モジュールMy-Extensions {...
extension c-define {
description
"Takes as argument a name string.
Makes the code generator use the given name in the
#define.";
argument "name";
}
}
To use the extension:
拡張機能を使用するには：
module my-interfaces {
...
import my-extensions {
prefix "myext";
}
...
container interfaces {
...
myext:c-define "MY_INTERFACES";
}
}
This section defines statements related to conformance, as described in Section 5.6.
このセクションでは、セクション5.6で説明されているように、適合性に関連するステートメントを定義します。
The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see Section 7.18.2). Schema nodes tagged with a feature are ignored by the device unless the device supports the given feature. This allows portions of the YANG module to be conditional based on conditions on the device. The model can represent the abilities of the device within the model, giving a richer model that allows for differing device abilities and roles.
「機能」ステートメントは、スキーマの一部が条件付きとしてマークされるメカニズムを定義するために使用されます。「if-feature」ステートメントを使用して後で参照できる機能名が定義されています（セクション7.18.2を参照）。デバイスが指定された機能をサポートしない限り、機能でタグ付けされたスキーマノードは、デバイスによって無視されます。これにより、Yangモジュールの一部がデバイスの条件に基づいて条件付きになります。このモデルは、モデル内のデバイスの能力を表すことができ、デバイスの能力と役割が異なることを可能にするより豊富なモデルを提供します。
The argument to the "feature" statement is the name of the new feature, and follows the rules for identifiers in Section 6.2. This name is used by the "if-feature" statement to tie the schema nodes to the feature.
「機能」ステートメントの引数は新機能の名前であり、セクション6.2の識別子のルールに従います。この名前は、「if-feature」ステートメントで使用され、スキーマノードを機能に結び付けます。
In this example, a feature called "local-storage" represents the ability for a device to store syslog messages on local storage of some sort. This feature is used to make the "local-storage-limit" leaf conditional on the presence of some sort of local storage. If the device does not report that it supports this feature, the "local-storage-limit" node is not supported.
この例では、「ローカルストレージ」と呼ばれる機能は、デバイスが何らかのローカルストレージにsyslogメッセージを保存する機能を表しています。この機能は、ある種のローカルストレージの存在を条件とする「ローカルストレージ制限」葉を作成するために使用されます。デバイスがこの機能をサポートしていることを報告しない場合、「ローカルストレージリミット」ノードはサポートされていません。
module syslog {
...
feature local-storage {
description
"This feature means the device supports local
storage (memory, flash or disk) that can be used to
store syslog messages.";
}
container syslog {
leaf local-storage-limit {
if-feature local-storage;
type uint64;
units "kilobyte";
config false;
description
"The amount of local storage that can be
used to hold syslog messages.";
}
}
}
The "if-feature" statement can be used in many places within the YANG syntax. Definitions tagged with "if-feature" are ignored when the device does not support that feature.
「if-feature」ステートメントは、Yang構文内の多くの場所で使用できます。「if-feature」でタグ付けされた定義は、デバイスがその機能をサポートしていない場合に無視されます。
A feature MUST NOT reference itself, neither directly nor indirectly through a chain of other features.
機能は、他の機能のチェーンを介して直接または間接的にもそれ自体を参照してはなりません。
In order for a device to implement a feature that is dependent on any other features (i.e., the feature has one or more "if-feature" sub-statements), the device MUST also implement all the dependant features.
デバイスが他の機能に依存する機能（つまり、この機能には1つ以上の「if-feature」サブステートメントがある）を実装するためには、デバイスはすべての従属機能を実装する必要があります。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
The "if-feature" statement makes its parent statement conditional. The argument is the name of a feature, as defined by a "feature" statement. The parent statement is implemented by servers that support this feature. If a prefix is present on the feature name, it refers to a feature defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, a feature with the matching name MUST be defined in the current module or an included submodule.
「if-feature」ステートメントは、親の声明を条件としています。引数は、「機能」ステートメントで定義されているように、機能の名前です。親ステートメントは、この機能をサポートするサーバーによって実装されます。プレフィックスが機能名に存在する場合、そのプレフィックスでインポートされたモジュールで定義されている機能、またはプレフィックスがローカルモジュールのプレフィックスと一致する場合はローカルモジュールを指します。それ以外の場合、一致する名前の機能は、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
Since submodules cannot include the parent module, any features in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the feature.
サブモジュールには親モジュールを含めることはできないため、サブモジュールに曝露する必要があるモジュール内の機能は、サブモジュールで定義する必要があります。サブモジュールは、このサブモジュールを含めて、機能の定義を見つけることができます。
The "deviation" statement defines a hierarchy of a module that the device does not implement faithfully. The argument is a string that identifies the node in the schema tree where a deviation from the module occurs. This node is called the deviation's target node. The contents of the "deviation" statement give details about the deviation.
「偏差」ステートメントは、デバイスが忠実に実装していないモジュールの階層を定義します。引数は、モジュールからの偏差が発生するスキーマツリーのノードを識別する文字列です。このノードは、偏差のターゲットノードと呼ばれます。「偏差」ステートメントの内容は、偏差に関する詳細を示しています。
The argument string is an absolute schema node identifier (see Section 6.5).
引数文字列は、絶対スキーマノード識別子です（セクション6.5を参照）。
Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards.
逸脱は、デバイスまたはクラスのデバイスが標準から逸脱する方法を定義します。これは、実装が標準によってどのように異なるかを学ぶためのメカニズムであるため、逸脱は公開された標準の一部ではないことを意味します。
Device deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. A device that deviates from a module is not fully compliant with the module.
デバイスの逸脱は強く落胆しており、最後の手段としてのみ使用する必要があります。アプリケーションにデバイスが標準に従わない方法を伝えることは、標準を正しく実装することに代わるものではありません。モジュールから逸脱するデバイスは、モジュールに完全に準拠していません。
However, in some cases, a particular device may not have the hardware or software ability to support parts of a standard module. When this occurs, the device makes a choice either to treat attempts to configure unsupported parts of the module as an error that is reported back to the unsuspecting application or ignore those incoming requests. Neither choice is acceptable.
ただし、場合によっては、特定のデバイスには、標準モジュールの一部をサポートするハードウェアまたはソフトウェア機能がない場合があります。これが発生すると、デバイスは、疑いを持たないアプリケーションに報告されるエラーとして、サポートされていない部分をモジュールのサポートされていない部分を構成しようとする試みを処理するか、それらの着信リクエストを無視することを選択することを選択します。どちらの選択も受け入れられません。
Instead, YANG allows devices to document portions of a base module that are not supported or supported but with different syntax, by using the "deviation" statement.
代わりに、Yangは、「偏差」ステートメントを使用して、サポートまたはサポートされていないが異なる構文を使用して、サポートまたはサポートされていないベースモジュールの一部を文書化できるようにします。
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 1..n |
| reference | 7.19.4 | 0..1 |
+--------------+----------+-------------+
The "deviate" statement defines how the device's implementation of the target node deviates from its original definition. The argument is one of the strings "not-supported", "add", "replace", or "delete".
「Deviate」ステートメントは、ターゲットノードのデバイスの実装が元の定義からどのように逸脱するかを定義します。引数は、「サポートされていない」、「追加」、「置き換え」、または「削除」の文字列の1つです。
The argument "not-supported" indicates that the target node is not implemented by this device.
「サポートされていない」引数は、ターゲットノードがこのデバイスによって実装されていないことを示しています。
The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node.
引数「add」は、ターゲットノードにプロパティを追加します。追加するプロパティは、「逸脱」ステートメントの置換によって識別されます。プロパティが1回しか表示できない場合、プロパティはターゲットノードに存在してはなりません。
The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node.
引数は、ターゲットノードのプロパティを置き換えます。交換するプロパティは、「逸脱」ステートメントの置換によって識別されます。交換するプロパティは、ターゲットノードに存在する必要があります。
The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node.
引数「削除」は、ターゲットノードからプロパティを削除します。削除するプロパティは、「削除」ステートメントの置換によって識別されます。Subsurtementのキーワードは、ターゲットノードの対応するキーワードと一致する必要があり、引数の文字列は、ターゲットノードの対応するキーワードの引数文字列に等しくなければなりません。
The deviates's Substatements
Deviatesの代替
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| mandatory | 7.6.5 | 0..1 |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| type | 7.4 | 0..1 |
| unique | 7.8.3 | 0..n |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
In this example, the device is informing client applications that it does not support the "daytime" service in the style of RFC 867.
この例では、デバイスはクライアントアプリケーションに、RFC 867のスタイルで「昼間」サービスをサポートしていないことを通知しています。
deviation /base:system/base:daytime {
deviate not-supported;
}
The following example sets a device-specific default value to a leaf that does not have a default value defined:
次の例では、デバイス固有のデフォルト値をデフォルト値を定義していない葉に設定します。
deviation /base:system/base:user/base:type {
deviate add {
default "admin"; // new users are 'admin' by default
}
}
In this example, the device limits the number of name servers to 3:
この例では、デバイスは名前サーバーの数を3に制限します。
deviation /base:system/base:name-server {
deviate replace {
max-elements 3;
}
}
If the original definition is:
元の定義が次の場合：
container system {
must "daytime or time";
...
}
a device might remove this must constraint by doing:
デバイスは、これを行うことにより、これを削除する場合があります。
deviation "/base:system" {
deviate delete {
must "daytime or time";
}
}
This section defines substatements common to several other statements.
このセクションでは、他のいくつかの声明に共通する置換を定義します。
The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration will be part of the reply to a <get-config> request, and can be sent in a <copy-config> or <edit-config> request.
「config」ステートメントは、文字列「true」または「false」という引数として取得します。「構成」が「true」の場合、定義は構成を表します。構成を表すデータノードは、<get-config>リクエストへの返信の一部であり、<copy-config>または<edit-config>リクエストで送信できます。
If "config" is "false", the definition represents state data. Data nodes representing state data will be part of the reply to a <get>, but not to a <get-config> request, and cannot be sent in a <copy-config> or <edit-config> request.
「config」が「false」の場合、定義は状態データを表します。状態データを表すデータノードは、<get>への返信の一部ですが、<get-config>リクエストに対するものではなく、<copy-config>または<edit-config>リクエストで送信することはできません。
If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node.
「構成」が指定されていない場合、デフォルトは親スキーマノードの「構成」値と同じです。親ノードが「ケース」ノードの場合、値は「ケース」ノードの親「選択」ノードと同じです。
If the top node does not specify a "config" statement, the default is "true".
上部ノードが「構成」ステートメントを指定していない場合、デフォルトは「true」です。
If a node has "config" set to "false", no node underneath it can have "config" set to "true".
ノードが「false」に「config」が設定されている場合、その下にノードが「true」に設定されている「構成」を持つことはできません。
The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete".
「ステータス」ステートメントは、文字列の1つ「現在」、「非推奨」、または「時代遅れ」の1つとして取得されます。
o "current" means that the definition is current and valid.
o 「現在」とは、定義が最新で有効であることを意味します。
o "deprecated" indicates an obsolete definition, but it permits new/ continued implementation in order to foster interoperability with older/existing implementations.
o 「非推奨」は時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を可能にします。
o "obsolete" means the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations.
o 「時代遅れ」とは、定義が時代遅れであり、実装されたり、実装から削除することはできないことを意味します。
If no status is specified, the default is "current".
ステータスが指定されていない場合、デフォルトは「現在」です。
If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module.
定義が「現在」の場合、同じモジュール内の「非推奨」または「時代遅れ」定義を参照してはなりません。
If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module.
定義が「非推奨」である場合、同じモジュール内の「時代遅れの」定義を参照してはなりません。
For example, the following is illegal:
たとえば、以下は違法です。
typedef my-type {
status deprecated;
type int32;
}
leaf my-leaf {
status current;
type my-type; // illegal, since my-type is deprecated
}
The "description" statement takes as an argument a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability, it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module.
「説明」ステートメントは、この定義の人間が読むことができるテキストの説明を含む文字列を引数として取ります。テキストは、モジュール開発者によって選択された言語（または言語）で提供されます。相互運用性のために、モジュールを使用するネットワーク管理者のコミュニティの間で広く理解されている言語を選択することをお勧めします。
The "reference" statement takes as an argument a string that is used to specify a textual cross-reference to an external document, either another module that defines related management information, or a document that provides additional information relevant to this definition.
「参照」ステートメントは、外部ドキュメントのテキストの相互参照を指定するために使用される文字列を引数として取得します。関連する管理情報を定義する別のモジュール、またはこの定義に関連する追加情報を提供するドキュメントのいずれかです。
For example, a typedef for a "uri" data type could look like:
たとえば、「URI」データ型のtypedefは次のようになります。
typedef uri {
type string;
reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax";
...
}
The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression (see Section 6.4), which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the node defined by the parent data definition statement is valid; otherwise, it is not.
「When」ステートメントは、親データ定義ステートメントを条件としています。親データ定義ステートメントによって定義されたノードは、「いつ」ステートメントが満たされているときに指定された条件が満たされた場合にのみ有効です。声明の議論はXPath式（セクション6.4を参照）であり、この条件を正式に指定するために使用されます。XPath式が特定のインスタンスの「true」と概念的に評価される場合、親データ定義ステートメントによって定義されたノードは有効です。そうでなければ、そうではありません。
See Section 8.3.2 for additional information.
詳細については、セクション8.3.2を参照してください。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、セクション6.4.1の定義に加えて、次のコンテキストで概念的に評価されます。
o If the "when" statement is a child of an "augment" statement, then the context node is the augment's target node in the data tree, if the target node is a data node. Otherwise, the context node is the closest ancestor node to the target node that is also a data node.
o 「When」ステートメントが「Augment」ステートメントの子である場合、ターゲットノードがデータノードである場合、コンテキストノードはデータツリー内のAugmentのターゲットノードです。それ以外の場合、コンテキストノードは、データノードでもあるターゲットノードに最も近い祖先ノードです。
o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node.
o 「When」ステートメントが「使用」、「選択」、または「ケース」ステートメントの子である場合、コンテキストノードは、「使用」、「選択」、または「ケース」ノードに最も近い先祖ノードです。データノードでもあります。
o If the "when" statement is a child of any other data definition statement, the context node is the data definition's node in the data tree.
o 「When」ステートメントが他のデータ定義ステートメントの子である場合、コンテキストノードはデータツリーのデータ定義のノードです。
o The accessible tree is made up of all nodes in the data tree, and all leafs with default values in use (see Section 7.6.1).
o アクセス可能なツリーは、データツリー内のすべてのノードと、使用中のデフォルト値のあるすべてのリーフで構成されています（セクション7.6.1を参照）。
The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードに依存します。
o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
o コンテキストノードが構成を表す場合、ツリーはコンテキストノードが存在するNetConf DataStoreのデータです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルの構成データノードがあります。
o If the context node represents state data, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
o コンテキストノードが状態データを表す場合、ツリーはすべてデバイス上の状態データと<running/> datastoreです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルのデータノードがあります。
o If the context node represents notification content, the tree is the notification XML instance document. The XPath root node has the element representing the notification being defined as the only child.
o コンテキストノードが通知コンテンツを表す場合、ツリーは通知XMLインスタンスドキュメントです。Xpathルートノードには、通知を表す要素が唯一の子として定義されています。
o If the context node represents RPC input parameters, the tree is the RPC XML instance document. The XPath root node has the element representing the RPC operation being defined as the only child.
o コンテキストノードがRPC入力パラメーターを表す場合、ツリーはRPC XMLインスタンスドキュメントです。Xpathルートノードには、RPC操作が唯一の子として定義されている要素があります。
o If the context node represents RPC output parameters, the tree is the RPC reply instance document. The XPath root node has the elements representing the RPC output parameters as children.
o コンテキストノードがRPC出力パラメーターを表す場合、ツリーはRPC Replyインスタンスドキュメントです。XPathルートノードには、RPC出力パラメーターを子供として表す要素があります。
The result of the XPath expression is converted to a boolean value using the standard XPath rules.
XPath式の結果は、標準のXPathルールを使用してブール値に変換されます。
Note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. The "when" statement can very well be implemented with specially written code.
XPath式は概念的に評価されていることに注意してください。これは、実装がデバイスでXPath評価者を使用する必要がないことを意味します。「When」ステートメントは、特別に書かれたコードで非常によく実装できます。
Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines.
いくつかのYangステートメントは、有効なデータの制約を定義しています。これらの制約は、ステートメントが定義するデータの種類に応じて、さまざまな方法で実施されます。
o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree.
o 制約が構成データで定義されている場合、有効な構成データツリーで真である必要があります。
o If the constraint is defined on state data, it MUST be true in a reply to a <get> operation without a filter.
o 制約が状態データで定義されている場合、フィルターなしで<get>操作への返信では真でなければなりません。
o If the constraint is defined on notification content, it MUST be true in any notification instance.
o 制約が通知コンテンツで定義されている場合、通知インスタンスで真である必要があります。
o If the constraint is defined on RPC input parameters, it MUST be true in an invocation of the RPC operation.
o 制約がRPC入力パラメーターで定義されている場合、RPC操作の呼び出しに当てはまる必要があります。
o If the constraint is defined on RPC output parameters, it MUST be true in the RPC reply.
o 制約がRPC出力パラメーターで定義されている場合、RPC応答では真でなければなりません。
Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device.
親ノードの条件は、ノードの階層の自然な結果として、子ノードの制約に影響します。「必須」、「必須」、「ミニエレメント」、および「最大要素」の制約は、親ノードに現在のデバイスで満たされていない「とき」または「if-feature」プロパティを持っている場合、強制されません。
In this example, the "mandatory" constraint on the "longitude" leaf are not enforced on devices that lack the "has-gps" feature:
この例では、「経度」葉の「必須」制約は、「has-gps」機能を欠くデバイスでは施行されていません。
container location {
if-feature has-gps;
leaf longitude {
mandatory true;
...
}
}
For configuration data, there are three windows when constraints MUST be enforced:
構成データの場合、制約を実施する必要がある場合は3つのウィンドウがあります。
o during parsing of RPC payloads
o RPCペイロードの解析中
o during processing of NETCONF operations
o NetConf操作の処理中
o during validation
o 検証中
Each of these scenarios is considered in the following sections.
これらの各シナリオは、次のセクションで検討されます。
When content arrives in RPC payloads, it MUST be well-formed XML, following the hierarchy and content rules defined by the set of models the device implements.
コンテンツがRPCペイロードに到着すると、デバイスを実装するモデルのセットで定義された階層およびコンテンツルールに従って、適切に形成されたXMLでなければなりません。
o If a leaf data value does not match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties, the server MUST reply with an "invalid-value" error-tag in the rpc-error, and with the error-app-tag and error-message associated with the constraint, if any exist.
o 葉のデータ値が、タイプの「範囲」、「長さ」、「パターン」プロパティで定義されているものを含む葉のタイプの制約と一致しない場合、サーバーは「無効な値」エラータグで返信する必要があります。RPC-Error、および存在する場合は、制約に関連するエラーアプリタグとエラーメサージを使用します。
o If all keys of a list entry are not present, the server MUST reply with a "missing-element" error-tag in the rpc-error.
o リストエントリのすべてのキーが存在しない場合、サーバーはRPC-Errorの「欠落要素」エラータグで返信する必要があります。
o If data for more than one case branch of a choice is present, the server MUST reply with a "bad-element" in the rpc-error.
o 選択の複数のケースブランチのデータが存在する場合、サーバーはRPC-Errorの「バッド要素」で返信する必要があります。
o If data for a node tagged with "if-feature" is present, and the feature is not supported by the device, the server MUST reply with an "unknown-element" error-tag in the rpc-error.
o 「if-feature」でタグ付けされたノードのデータが存在し、機能がデバイスによってサポートされていない場合、サーバーはRPC-Errorの「未知の要素」エラータグで返信する必要があります。
o If data for a node tagged with "when" is present, and the "when" condition evaluates to "false", the server MUST reply with an "unknown-element" error-tag in the rpc-error.
o 「when」が存在するノードのデータと「 "when"条件が「false」と評価される場合、サーバーはRPC-Errorの「不明な要素」エラータグで返信する必要があります。
o For insert handling, if the value for the attributes "before" and "after" are not valid for the type of the appropriate key leafs, the server MUST reply with a "bad-attribute" error-tag in the rpc-error.
o 挿入処理の場合、「前」と「後」の属性の値が適切なキーリーフのタイプに対して有効でない場合、サーバーはRPC-Errorの「悪いアトリブ」エラータグで返信する必要があります。
o If the attributes "before" and "after" appears in any element that is not a list whose "ordered-by" property is "user", the server MUST reply with an "unknown-attribute" error-tag in the rpc-error.
o 属性が「前」と「後」が「順序付けられた」プロパティが「ユーザー」であるリストではない要素に表示される場合、サーバーはRPC-Errorの「不明なアトリブ」エラータグで返信する必要があります。
After the incoming data is parsed, the NETCONF server performs the <edit-config> operation by applying the data to the configuration datastore. During this processing, the following errors MUST be detected:
着信データが解析された後、NetConfサーバーは、データを構成データストアに適用することにより、<edit-config>操作を実行します。この処理中に、次のエラーを検出する必要があります。
o Delete requests for non-existent data.
o 存在しないデータのリクエストを削除します。
o Create requests for existent data.
o 存在するデータのリクエストを作成します。
o Insert requests with "before" or "after" parameters that do not exist.
o 存在しない「前」または「後」パラメーターでリクエストを挿入します。
During <edit-config> processing:
<edit-config>処理中：
o If the NETCONF operation creates data nodes under a "choice", any existing nodes from other "case" branches are deleted by the server.
o NetConf操作が「選択」の下でデータノードを作成する場合、他の「ケース」ブランチからの既存のノードはサーバーによって削除されます。
o If the NETCONF operation modifies a data node such that any node's "when" expression becomes false, then the node with the "when" expression is deleted by the server.
o NetConf操作がデータノードを変更して、ノードが「false」になるときに、「 "expressionがサーバーによって削除されるときのノードがfalseになるように変更されます。
When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is <running/> or <startup/>, these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation. If the datastore is <candidate/>, the constraint enforcement is delayed until a <commit> or <validate> operation.
データストア処理が完了した場合、最終コンテンツはすべての検証制約に従う必要があります。この検証処理は、データストアに従って異なる時間に実行されます。DataStoreが<running/>または<起動/>の場合、これらの制約は<edit-config>または<copy-config>操作の最後に実施する必要があります。DataStoreが<候補/>の場合、制約施行はa <comped>または<balidate>操作まで遅延します。
o Any "must" constraints MUST evaluate to "true".
o 「マスト」の制約は、「真」と評価する必要があります。
o Any referential integrity constraints defined via the "path" statement MUST be satisfied.
o 「パス」ステートメントを介して定義された参照整合性の制約を満たす必要があります。
o Any "unique" constraints on lists MUST be satisfied.
o リストに「一意の」制約が満たされている必要があります。
o The "min-elements" and "max-elements" constraints are enforced for lists and leaf-lists.
o リストと葉のリストには、「最小要素」と「最大要素」の制約が施行されています。
YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements from the management information model.
Yangには、多くのプログラミング言語のものと同様の組み込みタイプのセットがありますが、管理情報モデルからの特別な要件によるいくつかの違いがあります。
Additional types may be defined, derived from those built-in types or from other derived types. Derived types may use subtyping to formally restrict the set of possible values.
追加のタイプは、これらの組み込みタイプまたは他の派生タイプから導出された定義できます。派生タイプは、サブタイピングを使用して、可能な値のセットを正式に制限する場合があります。
The different built-in types and their derived types allow different kinds of subtyping, namely length and regular expression restrictions of strings (Sections 9.4.4 and 9.4.6) and range restrictions of numeric types (Section 9.2.4).
さまざまな組み込みタイプとその派生タイプにより、さまざまな種類のサブタイピング、すなわち、文字列の長さと正規表現の制限（セクション9.4.4および9.4.6）と数値タイプの範囲制限（セクション9.2.4）が可能になります。
The lexical representation of a value of a certain type is used in the NETCONF messages and when specifying default values and numerical ranges in YANG modules.
特定のタイプの値の語彙表現は、NetConfメッセージで使用され、Yangモジュールでデフォルト値と数値範囲を指定するときに使用されます。
For most types, there is a single canonical representation of the type's values. Some types allow multiple lexical representations of the same value, for example, the positive integer "17" can be represented as "+17" or "17". Implementations MUST support all lexical representations specified in this document.
ほとんどのタイプでは、タイプの値の単一の標準表現があります。一部のタイプは、同じ値の複数の語彙表現を可能にします。たとえば、正の整数「17」は「17」または「17」として表すことができます。実装は、このドキュメントで指定されているすべての語彙表現をサポートする必要があります。
When a NETCONF server sends data, it MUST be in the canonical form.
NetConfサーバーがデータを送信するとき、それは標準形式でなければなりません。
Some types have a lexical representation that depends on the XML context in which they occur. These types do not have a canonical form.
一部のタイプには、発生するXMLコンテキストに依存する字句表現があります。これらのタイプには標準的なフォームがありません。
The integer built-in types are int8, int16, int32, int64, uint8, uint16, uint32, and uint64. They represent signed and unsigned integers of different sizes:
整数の組み込みタイプは、INT8、INT16、INT32、INT64、UINT8、UINT16、UINT32、およびUINT64です。それらは、さまざまなサイズの署名と署名されていない整数を表します。
int8 represents integer values between -128 and 127, inclusively.
INT8は、-128〜127の間の整数値を包括的に表します。
int16 represents integer values between -32768 and 32767, inclusively.
INT16は、-32768から32767の間の整数値を包括的に表します。
int32 represents integer values between -2147483648 and 2147483647, inclusively.
INT32は、-2147483648と2147483647の間の整数値を包括的に表します。
int64 represents integer values between -9223372036854775808 and 9223372036854775807, inclusively.
INT64は、-922372036854775808と9223372036854775807の間の整数値を包括的に表します。
uint8 represents integer values between 0 and 255, inclusively.
UINT8は、0〜255の間の整数値を包括的に表します。
uint16 represents integer values between 0 and 65535, inclusively.
UINT16は、0〜65535の間の整数値を包括的に表します。
uint32 represents integer values between 0 and 4294967295, inclusively.
UINT32は、0〜4294967295の間の整数値を包括的に表します。
uint64 represents integer values between 0 and 18446744073709551615, inclusively.
UINT64は、0〜18446744073709551615の整数値を包括的に表します。
An integer value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits. If no sign is specified, "+" is assumed.
整数値は、オプションの符号（ ""または " - "）として語彙的に表され、その後の小数桁のシーケンスが続きます。記号が指定されていない場合、「」と想定されます。
For convenience, when specifying a default value for an integer in a YANG module, an alternative lexical representation can be used, which represents the value in a hexadecimal or octal notation. The hexadecimal notation consists of an optional sign ("+" or "-"), the characters "0x" followed a number of hexadecimal digits, where letters may be uppercase or lowercase. The octal notation consists of an optional sign ("+" or "-"), the character "0" followed a number of octal digits.
便宜上、Yangモジュールの整数のデフォルト値を指定する場合、16進表またはOctal表記の値を表す代替の語彙表現を使用できます。16進表記は、オプションの符号（ "" "" ""または " - "）で構成されており、文字「0x」は、文字が大文字または小文字である可能性のある多くの16進数桁に従いました。オクタル表記は、オプションのサイン（ ""または " - "）で構成され、文字「0」は多くのオクタル桁に従いました。
Note that if a default value in a YANG module has a leading zero ("0"), it is interpreted as an octal number. In the XML instance documents, an integer is always interpreted as a decimal number, and leading zeros are allowed.
Yangモジュールのデフォルト値が先頭のゼロ（ "0"）がある場合、それはOctal数として解釈されることに注意してください。XMLインスタンスドキュメントでは、整数は常に小数点以下の数字として解釈され、主要なゼロが許可されます。
Examples:
例：
// legal values +4711 // legal positive value 4711 // legal positive value -123 // legal negative value 0xf00f // legal positive hexadecimal value -0xf // legal negative hexadecimal value 052 // legal positive octal value
//法的価値4711 //法的肯定的価値4711 //法的肯定的価値-123 //法的ネガティブ値0xf00f //法的肯定的な16進価値-0xf //法的ネガティブヘキサデシマル値052 //法的肯定的なオクタル値
// illegal values - 1 // illegal intermediate space
//違法値-1 //違法な中間スペース
The canonical form of a positive integer does not include the sign "+". Leading zeros are prohibited. The value zero is represented as "0".
正の整数の標準形式には、サイン「」は含まれていません。主要なゼロは禁止されています。値ゼロは「0」として表されます。
All integer types can be restricted with the "range" statement (Section 9.2.4).
すべての整数タイプは、「範囲」ステートメント（セクション9.2.4）で制限できます。
The "range" statement, which is an optional substatement to the "type" statement, takes as an argument a range expression string. It is used to restrict integer and decimal built-in types, or types derived from those.
「タイプ」ステートメントへのオプションの置換である「範囲」ステートメントは、引数として範囲式文字列を取得します。整数および10進数の組み込みタイプ、またはそれらから派生したタイプを制限するために使用されます。
A range consists of an explicit value, or a lower-inclusive bound, two consecutive dots "..", and an upper-inclusive bound. Multiple values or ranges can be given, separated by "|". If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a range restriction is applied to an already range-restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. Each explicit value and range boundary value given in the range expression MUST match the type being restricted, or be one of the special values "min" or "max". "min" and "max" mean the minimum and maximum value accepted for the type being restricted, respectively.
範囲は、明示的な値、または包括的な境界が2つの連続したドット「..」、および上部インクルーシブバウンドで構成されています。「|」で区切られた複数の値または範囲を指定できます。複数の値または範囲が与えられている場合、それらはすべてバラバラでなければならず、昇順でなければなりません。範囲の制限が既に範囲制限タイプに適用されている場合、新しい制限は等しいか、それ以上の制限でなければなりません。それは下限を上げ、上限を減らし、明示的な値または範囲を削除するか、中間範囲の範囲に分割します。ギャップ。範囲式で与えられる各明示的な値と範囲の境界値は、制限されているタイプと一致するか、特別な値「min」または「max」の1つでなければなりません。「Min」と「Max」は、それぞれ制限されているタイプの最小値と最大値を意味します。
The range expression syntax is formally defined by the rule "range-arg" in Section 12.
範囲式の構文は、セクション12のルール「範囲ARG」によって正式に定義されています。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
typedef my-base-int32-type {
type int32 {
range "1..4 | 10..20";
}
}
typedef my-type1 {
type my-base-int32-type {
// legal range restriction
range "11..max"; // 11..20
}
}
typedef my-type2 {
type my-base-int32-type {
// illegal range restriction
range "11..100";
}
}
The decimal64 type represents a subset of the real numbers, which can be represented by decimal numerals. The value space of decimal64 is the set of numbers that can be obtained by multiplying a 64-bit signed integer by a negative power of ten, i.e., expressible as "i x 10^-n" where i is an integer64 and n is an integer between 1 and 18, inclusively.
Decimal64タイプは、小数点以下の数字で表すことができる実数のサブセットを表します。Decimal64の値空間は、64ビットの署名整数に10の負の力を掛けることで取得できる数値のセットです。つまり、私は整数であり、nは整数です。包括的に1から18の間。
A decimal64 value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits. If no sign is specified, "+" is assumed.
Decimal64値は、オプションの記号（ ""または " - "）として語彙的に表現され、その後の小数桁のシーケンスが続き、オプションでは小数インジケータとしての期間（ ''）が続き、小数桁のシーケンスが続きます。記号が指定されていない場合、「」と想定されます。
The canonical form of a positive decimal64 does not include the sign "+". The decimal point is required. Leading and trailing zeros are prohibited, subject to the rule that there MUST be at least one digit before and after the decimal point. The value zero is represented as "0.0".
正の小数点の標準形式には、サイン「」は含まれていません。小数点が必要です。先頭と後続のゼロは禁止されており、小数点の前後に少なくとも1桁の数字が必要であるという規則の対象となります。値ゼロは「0.0」として表されます。
A decimal64 type can be restricted with the "range" statement (Section 9.2.4).
Decimal64タイプは、「範囲」ステートメント（セクション9.2.4）で制限できます。
The "fraction-digits" statement, which is a substatement to the "type" statement, MUST be present if the type is "decimal64". It takes as an argument an integer between 1 and 18, inclusively. It controls the size of the minimum difference between values of a decimal64 type, by restricting the value space to numbers that are expressible as "i x 10^-n" where n is the fraction-digits argument.
「タイプ」ステートメントの代替である「分数桁」ステートメントは、タイプが「decimal64」である場合は存在する必要があります。それは議論として、1〜18の整数を包括的に取ります。値空間を「i x 10^-n」として表現できる数値に制限することにより、小数点の値間の最小差のサイズを制御します。ここで、nは分数桁の引数です。
The following table lists the minimum and maximum value for each fraction-digit value:
次の表には、各分数桁の値の最小値と最大値を示します。
+----------------+-----------------------+----------------------+
| fraction-digit | min | max |
+----------------+-----------------------+----------------------+
| 1 | -922337203685477580.8 | 922337203685477580.7 |
| 2 | -92233720368547758.08 | 92233720368547758.07 |
| 3 | -9223372036854775.808 | 9223372036854775.807 |
| 4 | -922337203685477.5808 | 922337203685477.5807 |
| 5 | -92233720368547.75808 | 92233720368547.75807 |
| 6 | -9223372036854.775808 | 9223372036854.775807 |
| 7 | -922337203685.4775808 | 922337203685.4775807 |
| 8 | -92233720368.54775808 | 92233720368.54775807 |
| 9 | -9223372036.854775808 | 9223372036.854775807 |
| 10 | -922337203.6854775808 | 922337203.6854775807 |
| 11 | -92233720.36854775808 | 92233720.36854775807 |
| 12 | -9223372.036854775808 | 9223372.036854775807 |
| 13 | -922337.2036854775808 | 922337.2036854775807 |
| 14 | -92233.72036854775808 | 92233.72036854775807 |
| 15 | -9223.372036854775808 | 9223.372036854775807 |
| 16 | -922.3372036854775808 | 922.3372036854775807 |
| 17 | -92.23372036854775808 | 92.23372036854775807 |
| 18 | -9.223372036854775808 | 9.223372036854775807 |
+----------------+-----------------------+----------------------+
typedef my-decimal {
type decimal64 {
fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max";
}
}
The string built-in type represents human-readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]:
文字列内蔵タイプは、ヤンの人間が読みやすい文字列を表します。リーガルキャラクターは、タブ、キャリッジリターン、ラインフィード、およびUnicodeとISO/IEC 10646の法定文字です[ISO.10646]：
;; any Unicode character, excluding the surrogate blocks,
;; FFFE, and FFFF.
string = *char
char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
%x10000-10FFFF
A string value is lexically represented as character data in the XML instance documents.
文字列値は、XMLインスタンスドキュメントの文字データとして語彙的に表されます。
The canonical form is the same as the lexical representation. No Unicode normalization is performed of string values.
標準形式は語彙表現と同じです。文字列値のユニコード正規化は実行されません。
A string can be restricted with the "length" (Section 9.4.4) and "pattern" (Section 9.4.6) statements.
文字列は、「長さ」（セクション9.4.4）および「パターン」（セクション9.4.6）ステートメントで制限できます。
The "length" statement, which is an optional substatement to the "type" statement, takes as an argument a length expression string. It is used to restrict the built-in type "string", or types derived from "string".
「タイプ」ステートメントのオプションの置換である「長さ」ステートメントは、引数として長さの式文字列を取得します。組み込みのタイプ「文字列」、または「文字列」から派生したタイプを制限するために使用されます。
A "length" statement restricts the number of Unicode characters in the string.
「長さ」ステートメントは、文字列内のUnicode文字の数を制限します。
A length range consists of an explicit value, or a lower bound, two consecutive dots "..", and an upper bound. Multiple values or ranges can be given, separated by "|". Length-restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a length restriction is applied to an already length-restricted type, the new restriction MUST be equal or more limiting, that is, raising the lower bounds, reducing the upper bounds, removing explicit length values or ranges, or splitting ranges into multiple ranges with intermediate gaps. A length value is a non-negative integer, or one of the special values "min" or "max". "min" and "max" mean the minimum and maximum length accepted for the type being restricted, respectively. An implementation is not required to support a length value larger than 18446744073709551615.
長さの範囲は、明示的な値、または下限、2つの連続したドット「..」、および上限で構成されています。「|」で区切られた複数の値または範囲を指定できます。長さの制限値は否定的であってはなりません。複数の値または範囲が与えられている場合、それらはすべてバラバラでなければならず、昇順でなければなりません。長さの制限が既に長さの制限タイプに適用されている場合、新しい制限は等しいか、つまり、下限を上げ、上限を減らし、明示的な長さの値または範囲を削除するか、複数の範囲に分割する必要があります。中間ギャップ付き。長さの値は、非陰性整数、または特別な値「min」または「max」の1つです。「min」と「max」とは、それぞれ制限されているタイプの最小値と最大長を意味します。18446744073709551615を超える長さの値をサポートするために実装は必要ありません。
The length expression syntax is formally defined by the rule "length-arg" in Section 12.
長さの式構文は、セクション12のルール「長さARG」によって正式に定義されます。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
typedef my-base-str-type {
type string {
length "1..255";
}
}
type my-base-str-type {
// legal length refinement
length "11 | 42..max"; // 11 | 42..255
}
type my-base-str-type {
// illegal length refinement
length "1..999";
}
The "pattern" statement, which is an optional substatement to the "type" statement, takes as an argument a regular expression string, as defined in [XSD-TYPES]. It is used to restrict the built-in type "string", or types derived from "string", to values that match the pattern.
[XSD-Types]で定義されているように、「タイプ」ステートメントのオプションの表現である「パターン」ステートメントは、引数として正規表現文字列を取得します。組み込みのタイプ「文字列」または「文字列」から派生したタイプをパターンに一致させる値に制限するために使用されます。
If the type has multiple "pattern" statements, the expressions are ANDed together, i.e., all such expressions have to match.
タイプに複数の「パターン」ステートメントがある場合、式は一緒にandedされます。つまり、そのような表現はすべて一致する必要があります。
If a pattern restriction is applied to an already pattern-restricted type, values must match all patterns in the base type, in addition to the new patterns.
パターン制限が既にパターン制限タイプに適用されている場合、新しいパターンに加えて、値はベースタイプのすべてのパターンと一致する必要があります。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
With the following type:
次のタイプで：
type string {
length "0..4";
pattern "[0-9a-fA-F]*";
}
the following strings match:
次の文字列が一致します：
AB // legal 9A00 // legal
AB //リーガル9A00 //リーガル
and the following strings do not match:
そして、次の文字列が一致しません：
00ABAB // illegal, too long xx00 // illegal, bad characters
00abab //違法、長すぎるxx00 //違法、悪い文字
The boolean built-in type represents a boolean value.
ブールビルトインタイプは、ブール値を表します。
The lexical representation of a boolean value is a string with a value of "true" or "false". These values MUST be in lowercase.
ブール値の語彙表現は、「true」または「false」の値を持つ文字列です。これらの値は小文字でなければなりません。
The canonical form is the same as the lexical representation.
標準形式は語彙表現と同じです。
A boolean cannot be restricted.
ブールを制限することはできません。
The enumeration built-in type represents values from a set of assigned names.
列挙ビルトインタイプは、割り当てられた名前のセットからの値を表します。
The lexical representation of an enumeration value is the assigned name string.
列挙値の語彙表現は、割り当てられた名前文字列です。
The canonical form is the assigned name string.
標準形式は、割り当てられた名前文字列です。
An enumeration cannot be restricted.
列挙は制限できません。
The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of Unicode control codes SHOULD be avoided.
「タイプ」ステートメントの代替である「列挙」ステートメントは、タイプが「列挙」である場合は存在する必要があります。列挙型の各割り当て名前を指定するために繰り返し使用されます。引数として、割り当てられた名前である文字列を取得します。文字列は空であってはなりません。また、主要または後続の空白文字を持っていてはいけません。ユニコード制御コードの使用は避ける必要があります。
The statement is optionally followed by a block of substatements that holds detailed enum information.
ステートメントの後に、詳細な列挙情報を保持する置換ブロックが続きます。
All assigned names in an enumeration MUST be unique.
列挙に割り当てられたすべての名前は一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+
The "value" statement, which is optional, is used to associate an integer value with the assigned name for the enum. This integer value MUST be in the range -2147483648 to 2147483647, and it MUST be unique within the enumeration type. The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.
オプションである「値」ステートメントは、整数値を列挙の割り当て名に関連付けるために使用されます。この整数値は、範囲-2147483648〜2147483647でなければならず、列挙タイプ内で一意でなければなりません。値はYangとXMLエンコードによって使用されていませんが、実装者にとって便利なものとして運ばれます。
If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value.
値が指定されていない場合、1つは自動的に割り当てられます。「列挙」の置換が最初の定義されたものである場合、割り当てられた値はゼロ（0）です。それ以外の場合、割り当てられた値は、現在の最高の列挙値よりも大きいものです。
If the current highest value is equal to 2147483647, then an enum value MUST be specified for "enum" substatements following the one with the current highest value.
現在の最高値が2147483647に等しい場合、現在の最高値を持つものに続く「列挙」置換に列挙値を指定する必要があります。
leaf myenum {
type enumeration {
enum zero;
enum one;
enum seven {
value 7;
}
}
}
The lexical representation of the leaf "myenum" with value "seven" is:
葉の「ミエヌム」の値「7」の語彙表現は次のとおりです。
<myenum>seven</myenum>
The bits built-in type represents a bit set. That is, a bits value is a set of flags identified by small integer position numbers starting at 0. Each bit number has an assigned name.
ビット内蔵タイプは、少しセットを表します。つまり、ビット値は、0から始まる小さな整数位置番号によって識別されるフラグのセットです。各ビット番号には割り当てられた名前があります。
A bits type cannot be restricted.
ビットタイプを制限することはできません。
The lexical representation of the bits type is a space-separated list of the individual bit values that are set. An empty string thus represents a value where no bits are set.
BITSタイプの語彙表現は、設定された個々のビット値のスペース分離リストです。したがって、空の文字列は、ビットが設定されていない値を表します。
In the canonical form, the bit values are separated by a single space character and they appear ordered by their position (see Section 9.7.4.2).
標準形式では、ビット値は単一のスペース文字によって分離され、位置によって順序付けられているように見えます（セクション9.7.4.2を参照）。
The "bit" statement, which is a substatement to the "type" statement, MUST be present if the type is "bits". It is repeatedly used to specify each assigned named bit of a bits type. It takes as an argument a string that is the assigned name of the bit. It is followed by a block of substatements that holds detailed bit information. The assigned name follows the same syntax rules as an identifier (see Section 6.2).
「タイプ」ステートメントの代替である「ビット」ステートメントは、タイプが「ビット」である場合は存在する必要があります。割り当てられた各名前のビットタイプを指定するために繰り返し使用されます。それは引数として、ビットの割り当てられた名前である文字列を取得します。その後、詳細なビット情報を保持する置換ブロックが続きます。割り当てられた名前は、識別子と同じ構文ルールに従います（セクション6.2を参照）。
All assigned names in a bits type MUST be unique.
ビットタイプのすべての割り当てられた名前は一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+
The "position" statement, which is optional, takes as an argument a non-negative integer value that specifies the bit's position within a hypothetical bit field. The position value MUST be in the range 0 to 4294967295, and it MUST be unique within the bits type. The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors.
オプションである「ポジション」ステートメントは、仮説ビットフィールド内のビットの位置を指定する非陰性整数値を引数として取得します。位置値は0〜4294967295の範囲でなければならず、ビットタイプ内で一意でなければなりません。値はYangとNetConfメッセージによって使用されていませんが、実装者にとって便利なものとして運ばれます。
If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position.
少しの位置が指定されていない場合、1つは自動的に割り当てられます。「ビット」の置換が最初の定義されたものである場合、割り当てられた値はゼロ（0）です。それ以外の場合、割り当てられた値は、現在の最高のビット位置よりも大きいものです。
If the current highest bit position value is equal to 4294967295, then a position value MUST be specified for "bit" substatements following the one with the current highest position value.
現在の最高のビット位置値が4294967295に等しい場合、現在の最高位置値を持つものに続く「ビット」置換に位置値を指定する必要があります。
Given the following leaf:
次の葉を与えられた：
leaf mybits {
type bits {
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
bit 10-Mb-only {
position 2;
}
}
default "auto-sense-speed";
}
The lexical representation of this leaf with bit values disable-nagle and 10-Mb-only set would be:
ビット値を備えたこの葉の語彙表現は、ナグルと10 MBのみのセットを無効にします。
<mybits>disable-nagle 10-Mb-only</mybits>
The binary built-in type represents any binary data, i.e., a sequence of octets.
バイナリ内蔵タイプは、バイナリデータ、つまりオクテットのシーケンスを表します。
A binary can be restricted with the "length" (Section 9.4.4) statement. The length of a binary value is the number of octets it contains.
バイナリは、「長さ」（セクション9.4.4）ステートメントで制限できます。バイナリ値の長さは、含まれるオクテットの数です。
Binary values are encoded with the base64 encoding scheme (see [RFC4648], Section 4).
バイナリ値は、base64エンコードスキームでエンコードされます（[RFC4648]、セクション4を参照）。
The canonical form of a binary value follows the rules in [RFC4648].
バイナリ値の標準形式は、[RFC4648]のルールに従います。
The leafref type is used to reference a particular leaf instance in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances.
LeafRefタイプは、データツリーの特定のリーフインスタンスを参照するために使用されます。「パス」の代替（セクション9.9.2）は、葉のインスタンスのセットを選択し、葉の値空間はこれらの葉のインスタンスの値のセットです。
If the leaf with the leafref type represents configuration data, the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All leafref nodes MUST reference existing leaf instances or leafs with default values in use (see Section 7.6.1) for the data to be valid. This constraint is enforced according to the rules in Section 8.
LeafRefタイプの葉が構成データを表す場合、それが言及する葉も構成を表す必要があります。このような葉は、有効なデータに制約を課します。すべてのLeafRefノードは、データが有効になるために使用されているデフォルト値（セクション7.6.1を参照）を持つ既存のリーフインスタンスまたはリーフを参照する必要があります。この制約は、セクション8のルールに従って強制されます。
There MUST NOT be any circular chains of leafrefs.
葉の円形チェーンはないはずです。
If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.18.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features.
Leafrefが指す葉が1つ以上の特徴に基づいて条件付きである場合（セクション7.18.2を参照）、葉のタイプの葉も少なくとも同じ機能セットに基づいて条件付けられなければなりません。
A leafref cannot be restricted.
葉を制限することはできません。
The "path" statement, which is a substatement to the "type" statement, MUST be present if the type is "leafref". It takes as an argument a string that MUST refer to a leaf or leaf-list node.
「タイプ」ステートメントの代替である「パス」ステートメントは、タイプが「leafref」である場合、存在する必要があります。引数として、葉または葉のリストノードを指す必要がある文字列を取得します。
The syntax for a path argument is a subset of the XPath abbreviated syntax. Predicates are used only for constraining the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 12.
パス引数の構文は、Xpathの略語構文のサブセットです。述語は、リストエントリのキーノードの値を制約するためにのみ使用されます。各述語は、キーごとに正確に1つの平等テストで構成され、リストに複数のキーがある場合、複数の隣接する述語が存在する場合があります。構文は、セクション12のルール「パスARG」によって正式に定義されています。
The predicates are only used when more than one key reference is needed to uniquely identify a leaf instance. This occurs if a list has multiple keys, or a reference to a leaf other than the key in a list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together.
述語は、葉のインスタンスを一意に識別するために複数のキー参照が必要な場合にのみ使用されます。これは、リストに複数のキーがある場合、またはリスト内のキー以外の葉への参照が必要な場合に発生します。これらの場合、複数の葉が通常指定され、述語がそれらを結び付けるために使用されます。
The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the leaf with the leafref type represents configuration data, this node set MUST be non-empty.
「パス」式は、ゼロ、1つ、またはそれ以上のノードで構成されるノードセットを評価します。LeafRefタイプの葉が構成データを表す場合、このノードセットは空ではない必要があります。
The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
セクション6.4.1の定義に加えて、「パス」XPath式は、次のコンテキストで概念的に評価されます。
o The context node is the node in the data tree for which the "path" statement is defined.
o コンテキストノードは、「パス」ステートメントが定義されているデータツリーのノードです。
The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードに依存します。
o If the context node represents configuration data, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
o コンテキストノードが構成データを表す場合、ツリーはコンテキストノードが存在するNetConf DataStoreのデータです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルの構成データノードがあります。
o Otherwise, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
o それ以外の場合、ツリーはすべてデバイス上の状態データと<running/> datastoreです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルのデータノードがあります。
A leafref value is encoded the same way as the leaf it references.
葉の値は、それが参照する葉と同じ方法でエンコードされます。
The canonical form of a leafref is the same as the canonical form of the leaf it references.
葉の標準形式は、葉の標準形式と同じです。
With the following list:
次のリストで：
list interface {
key "name";
leaf name {
type string;
}
leaf admin-status {
type admin-status;
}
list address {
key "ip";
leaf ip {
type yang:ip-address;
}
}
}
The following leafref refers to an existing interface:
次のLeafrefは、既存のインターフェイスを指します。
leaf mgmt-interface {
type leafref {
path "../interface/name";
}
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
</interface>
<interface>
<name>lo</name>
</interface>
<mgmt-interface>eth0</mgmt-interface>
The following leafrefs refer to an existing address of an interface:
次のLeafrefsは、インターフェイスの既存のアドレスを指します。
container default-address {
leaf ifname {
type leafref {
path "../../interface/name";
}
}
leaf address {
type leafref {
path "../../interface[name = current()/../ifname]"
+ "/address/ip";
}
}
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<address>
<ip>192.0.2.1</ip>
</address>
<address>
<ip>192.0.2.2</ip>
</address>
</interface>
<interface>
<name>lo</name>
<admin-status>up</admin-status>
<address>
<ip>127.0.0.1</ip>
</address>
</interface>
<default-address>
<ifname>eth0</ifname>
<address>192.0.2.2</address>
</default-address>
The following list uses a leafref for one of its keys. This is similar to a foreign key in a relational database.
次のリストでは、キーの1つにLeafrefを使用しています。これは、リレーショナルデータベースの外部キーに似ています。
list packet-filter {
key "if-name filter-id";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf filter-id {
type uint32;
}
...
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<address>
<ip>192.0.2.1</ip>
</address>
<address>
<ip>192.0.2.2</ip>
</address>
</interface>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>1</filter-id>
...
</packet-filter>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>2</filter-id>
...
</packet-filter>
The following notification defines two leafrefs to refer to an existing admin-status:
次の通知では、既存の管理者ステータスを参照する2つのLeafRefsを定義しています。
notification link-failure {
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf admin-status {
type leafref {
path
"/interface[name = current()/../if-name]"
+ "/admin-status";
}
}
}
An example of a corresponding XML notification:
対応するXML通知の例：
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-04-01T00:01:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system">
<if-name>eth0</if-name>
<admin-status>up</admin-status>
</link-failure>
</notification>
The identityref type is used to reference an existing identity (see Section 7.16).
IDREFタイプは、既存のIDを参照するために使用されます（セクション7.16を参照）。
An identityref cannot be restricted.
IdentityRefを制限することはできません。
The "base" statement, which is a substatement to the "type" statement, MUST be present if the type is "identityref". The argument is the name of an identity, as defined by an "identity" statement. If a prefix is present on the identity name, it refers to an identity defined in the module that was imported with that prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule.
「タイプ」ステートメントの代替である「ベース」ステートメントは、タイプが「IDREF」である場合、存在する必要があります。議論は、「アイデンティティ」ステートメントで定義されているように、アイデンティティの名前です。ID名にプレフィックスが存在する場合、そのプレフィックスでインポートされたモジュールで定義されたIDを指します。それ以外の場合、一致する名前を持つIDは、現在のモジュールまたは含まれるサブモジュールで定義する必要があります。
Valid values for an identityref are any identities derived from the identityref's base identity. On a particular server, the valid values are further restricted to the set of identities defined in the modules supported by the server.
IDREFの有効な値は、IDREFのベースアイデンティティから派生したアイデンティティです。特定のサーバーでは、有効な値は、サーバーによってサポートされているモジュールで定義されている一連のアイデンティティにさらに制限されます。
An identityref is encoded as the referred identity's qualified name as defined in [XML-NAMES]. If the prefix is not present, the namespace of the identityref is the default namespace in effect on the element that contains the identityref value.
IDREFは、[xml-names]で定義されている紹介されたアイデンティティの適格名としてエンコードされます。接頭辞が存在しない場合、IDEFREFの名前空間は、IDEFREF値を含む要素に有効なデフォルトの名前空間です。
When an identityref is given a default value using the "default" statement, the identity name in the default value MAY have a prefix. If a prefix is present on the identity name, it refers to an identity defined in the module that was imported with that prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule.
IDREFに「デフォルト」ステートメントを使用してデフォルト値が与えられた場合、デフォルト値のIDNAME名にプレフィックスがある場合があります。ID名にプレフィックスが存在する場合、そのプレフィックスでインポートされたモジュールで定義されたIDを指します。それ以外の場合、一致する名前を持つIDは、現在のモジュールまたは含まれるサブモジュールで定義する必要があります。
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
語彙形式は、値が発生するXMLコンテキストに依存するため、このタイプには標準的な形式がありません。
With the identity definitions in Section 7.16.3 and the following module:
セクション7.16.3および次のモジュールのID定義が次のとおりです。
module my-crypto {
モジュールmy-crypto {
namespace "http://example.com/my-crypto"; prefix mc;
namespace "http://example.com/my-crypto";プレフィックスMC;
import "crypto-base" {
prefix "crypto";
}
identity aes {
base "crypto:crypto-alg";
}
leaf crypto {
type identityref {
base "crypto:crypto-alg";
}
}
}
the leaf "crypto" will be encoded as follows, if the value is the "des3" identity defined in the "des" module:
値が「DES」モジュールで定義されている「DES3」アイデンティティである場合、葉の「Crypto」は次のようにエンコードされます。
<crypto xmlns:des="http://example.com/des">des:des3</crypto>
Any prefixes used in the encoding are local to each instance encoding. This means that the same identityref may be encoded differently by different implementations. For example, the following example encodes the same leaf as above:
エンコードで使用されるプレフィックスは、各インスタンスエンコードにローカルです。これは、同じIDREFが異なる実装によって異なってエンコードされる可能性があることを意味します。たとえば、次の例では、上記と同じ葉をコードします。
<crypto xmlns:x="http://example.com/des">x:des3</crypto>
If the "crypto" leaf's value instead is "aes" defined in the "my-crypto" module, it can be encoded as:
「暗号」リーフの値が代わりに「私のクリプト」モジュールで定義されている「AE」である場合、次のようにエンコードできます。
<crypto xmlns:mc="http://example.com/my-crypto">mc:aes</crypto>
or, using the default namespace:
または、デフォルトの名前空間を使用してください。
<crypto>aes</crypto>
The empty built-in type represents a leaf that does not have any value, it conveys information by its presence or absence.
空の内蔵タイプは、価値がない葉を表し、その有無によって情報を伝えます。
An empty type cannot have a default value.
空のタイプはデフォルト値を持つことはできません。
An empty type cannot be restricted.
空のタイプを制限することはできません。
Not applicable.
適用できない。
Not applicable.
適用できない。
The following leaf
次の葉
leaf enable-qos {
type empty;
}
will be encoded as
ASとしてエンコードされます
<enable-qos/>
<enable-qos/>
if it exists.
存在する場合。
The union built-in type represents a value that corresponds to one of its member types.
ユニオンビルトインタイプは、メンバータイプの1つに対応する値を表します。
When the type is "union", the "type" statement (Section 7.4) MUST be present. It is used to repeatedly specify each member type of the union. It takes as an argument a string that is the name of a member type.
タイプが「ユニオン」の場合、「タイプ」ステートメント（セクション7.4）が存在する必要があります。組合の各メンバータイプを繰り返し指定するために使用されます。それは、メンバータイプの名前である文字列を引数として受け取ります。
A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref".
メンバータイプは、組み込みのタイプまたは派生タイプの任意のタイプである場合があります。
When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the "type" statement, until a match is found.
ユニオンのデータ型を表す文字列が検証されると、一致が見つかるまで「タイプ」ステートメントで指定されている順序で、各メンバータイプに対して文字列が検証されます。
Any default value or "units" property defined in the member types is not inherited by the union type.
メンバータイプで定義されているデフォルト値または「単位」プロパティは、ユニオンタイプによって継承されません。
Example:
例：
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
A union cannot be restricted. However, each member type can be restricted, based on the rules defined in Section 9.
組合を制限することはできません。ただし、セクション9で定義されているルールに基づいて、各メンバータイプを制限できます。
The lexical representation of a union is a value that corresponds to the representation of any one of the member types.
組合の語彙表現は、メンバータイプのいずれかの表現に対応する値です。
The canonical form of a union value is the same as the canonical form of the member type of the value.
組合価値の正規形式は、値のメンバータイプの標準形式と同じです。
The instance-identifier built-in type is used to uniquely identify a particular instance node in the data tree.
Instance-Identifierビルトインタイプは、データツリー内の特定のインスタンスノードを一意に識別するために使用されます。
The syntax for an instance-identifier is a subset of the XPath abbreviated syntax, formally defined by the rule "instance-identifier" in Section 12. It is used to uniquely identify a node in the data tree. Predicates are used only for specifying the values for the key nodes for list entries, a value of a leaf-list entry, or a positional index for a list without keys. For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate.
Instance-Identifierの構文は、セクション12のルール「Instance-Identifier」で正式に定義されているXPathの短縮構文のサブセットです。データツリーのノードを一意に識別するために使用されます。述語は、リストエントリのキーノードの値、リーフリストエントリの値、またはキーのないリストの位置インデックスを指定するためにのみ使用されます。キーを使用したリストエントリを識別するには、各述語はキーごとに1つの等自由テストで構成され、各キーには対応する述語が必要です。
If the leaf with the instance-identifier type represents configuration data, and the "require-instance" property (Section 9.13.2) is "true", the node it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All such leaf nodes MUST reference existing nodes or leaf nodes with their default value in use (see Section 7.6.1) for the data to be valid. This constraint is enforced according to the rules in Section 8.
インスタンスIDENTIFIERタイプの葉が構成データを表し、「要求」プロパティ（セクション9.13.2）が「TRUE」である場合、それが言及するノードも構成を表す必要があります。このような葉は、有効なデータに制約を課します。このようなリーフノードはすべて、データを有効にするために使用中のデフォルト値（セクション7.6.1を参照）を使用して、既存のノードまたは葉のノードを参照する必要があります。この制約は、セクション8のルールに従って強制されます。
The "instance-identifier" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
セクション6.4.1の定義に加えて、「Instance-Identifier」XPath式は、次のコンテキストで概念的に評価されます。
o The context node is the root node in the accessible tree.
o コンテキストノードは、アクセス可能なツリーのルートノードです。
The accessible tree depends on the leaf with the instance-identifier type:
アクセス可能なツリーは、インスタンスIDENTIFIERタイプの葉に依存します。
o If this leaf represents configuration data, the tree is the data in the NETCONF datastore where the leaf exists. The XPath root node has all top-level configuration data nodes in all modules as children.
o この葉が構成データを表す場合、ツリーは葉が存在するNetConf DataStoreのデータです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルの構成データノードがあります。
o Otherwise, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
o それ以外の場合、ツリーはすべてデバイス上の状態データと<running/> datastoreです。Xpathルートノードには、子供としてのすべてのモジュールのすべてのトップレベルのデータノードがあります。
An instance-identifier can be restricted with the "require-instance" statement (Section 9.13.2).
インスタンス識別子は、「要求」ステートメント（セクション9.13.2）で制限できます。
The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "instance-identifier". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true".
「タイプ」ステートメントの代替である「要求」ステートメントは、タイプが「インスタンス識別子」である場合、存在する場合があります。引数として、文字列「true」または「false」を取ります。このステートメントが存在しない場合、デフォルトは「true」になります。
If "require-instance" is "true", it means that the instance being referred MUST exist for the data to be valid. This constraint is enforced according to the rules in Section 8.
「要件」が「真」である場合、データが有効であるために紹介されるインスタンスが存在する必要があることを意味します。この制約は、セクション8のルールに従って強制されます。
If "require-instance" is "false", it means that the instance being referred MAY exist in valid data.
「要件」が「false」である場合、参照されるインスタンスが有効なデータに存在する可能性があることを意味します。
An instance-identifier value is lexically represented as a string. All node names in an instance-identifier value MUST be qualified with explicit namespace prefixes, and these prefixes MUST be declared in the XML namespace scope in the instance-identifier's XML element.
インスタンス識別子値は、文字列として語彙的に表されます。Instance-Identifier値のすべてのノード名は、明示的な名前空間プレフィックスで適格でなければなりません。これらのプレフィックスは、Instance IdentifierのXML要素のXMLネームスペーススコープで宣言する必要があります。
Any prefixes used in the encoding are local to each instance encoding. This means that the same instance-identifier may be encoded differently by different implementations.
エンコードで使用されるプレフィックスは、各インスタンスエンコードにローカルです。これは、同じインスタンスIDENTIFIERが異なる実装によって異なってエンコードされる可能性があることを意味します。
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
語彙形式は、値が発生するXMLコンテキストに依存するため、このタイプには標準的な形式がありません。
The following are examples of instance identifiers:
以下は、インスタンス識別子の例です。
/* instance-identifier for a container */
/ex:system/ex:services/ex:ssh
/* instance-identifier for a leaf */
/ex:system/ex:services/ex:ssh/ex:port
/* instance-identifier for a list entry */
/ex:system/ex:user[ex:name='fred']
/* instance-identifier for a leaf in a list entry */
/ex:system/ex:user[ex:name='fred']/ex:type
/* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3]
As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
モジュールで経験が得られるため、そのモジュールを修正することが望ましい場合があります。ただし、元の仕様と更新された仕様を使用してサーバーを使用してクライアント間で相互運用性の問題を引き起こす可能性がある場合、変更は許可されません。
For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. If there are no existing "revision" statements, then one MUST be added to identify the new revision. Furthermore, any necessary changes MUST be applied to any meta-data statements, including the "organization" and "contact" statements (Sections 7.1.7, 7.1.8).
公開された変更の場合、新しい「改訂」ステートメント（セクション7.1.9）を既存の「改訂」ステートメントの前に含める必要があります。既存の「改訂」ステートメントがない場合は、新しい改訂を特定するために追加する必要があります。さらに、必要な変更は、「組織」や「連絡先」ステートメント（セクション7.1.7、7.1.8）を含むメタデータステートメントに適用する必要があります。
Note that definitions contained in a module are available to be imported by any other module, and are referenced in "import" statements via the module name. Thus, a module name MUST NOT be changed. Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are qualified by the namespace.
モジュールに含まれる定義は、他のモジュールによってインポートされる可能性があり、モジュール名を介して「インポート」ステートメントで参照されることに注意してください。したがって、モジュール名を変更してはなりません。さらに、すべてのXML要素が名前空間で適格であるため、「名前空間」ステートメントを変更する必要はありません。
Obsolete definitions MUST NOT be removed from modules since their identifiers may still be referenced by other modules.
識別子が他のモジュールによって参照される可能性があるため、廃止された定義をモジュールから削除してはなりません。
A definition may be revised in any of the following ways:
定義は、次のいずれかの方法で改訂される場合があります。
o An "enumeration" type may have new enums added, provided the old enums's values do not change.
o 「列挙」タイプには、古いenumsの値が変更されない場合、「列挙」タイプには新しい酵素が追加されている場合があります。
o A "bits" type may have new bits added, provided the old bit positions do not change.
o 古いビット位置が変更されない場合、「ビット」タイプに新しいビットが追加される場合があります。
o A "range", "length", or "pattern" statement may expand the allowed value space.
o 「範囲」、「長さ」、または「パターン」ステートメントは、許容値スペースを拡張する場合があります。
o A "default" statement may be added to a leaf that does not have a default value (either directly or indirectly through its type).
o 「デフォルト」ステートメントは、デフォルト値を持たない葉に追加される場合があります（そのタイプを介して直接または間接的に）。
o A "units" statement may be added.
o 「単位」ステートメントが追加される場合があります。
o A "reference" statement may be added or updated.
o 「参照」ステートメントが追加または更新される場合があります。
o A "must" statement may be removed or its constraint relaxed.
o 「必須」ステートメントが削除されるか、その制約が緩和される場合があります。
o A "mandatory" statement may be removed or changed from "true" to "false".
o 「必須」ステートメントは、「真」から「false」に変更されるか、変更される場合があります。
o A "min-elements" statement may be removed, or changed to require fewer elements.
o 「Min-Elements」ステートメントを削除するか、より少ない要素を必要とするように変更される場合があります。
o A "max-elements" statement may be removed, or changed to allow more elements.
o 「最大要素」ステートメントを削除するか、より多くの要素を許可するために変更される場合があります。
o A "description" statement may be added or clarified without changing the semantics of the definition.
o 「説明」ステートメントは、定義のセマンティクスを変更せずに追加または明確にすることができます。
o New typedefs, groupings, rpcs, notifications, extensions, features, and identities may be added.
o 新しいtypedefs、グループ化、RPC、通知、拡張機能、機能、およびアイデンティティが追加される場合があります。
o New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature).
o 新しいデータ定義ステートメントは、既存のノード（セクション3.1）を既存のノードまたはモジュールまたはサブモジュールの上部レベルに追加しない場合、または新しい機能に条件付きで依存している場合（つまり、「if-」を持っている場合、追加される場合があります。機能 "新しい機能を指すステートメント）。
o A new "case" statement may be added.
o 新しい「ケース」ステートメントが追加される場合があります。
o A node that represented state data may be changed to represent configuration, provided it is not mandatory (Section 3.1).
o 状態データを表すノードは、必須ではない場合に構成を表すように変更できます（セクション3.1）。
o An "if-feature" statement may be removed, provided its node is not mandatory (Section 3.1).
o ノードが必須ではない場合、「if-feature」ステートメントが削除される場合があります（セクション3.1）。
o A "status" statement may be added, or changed from "current" to "deprecated" or "obsolete", or from "deprecated" to "obsolete".
o 「ステータス」ステートメントが追加されるか、「現在」から「非推奨」または「時代遅れ」に変更される場合があります。
o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change.
o 「タイプ」ステートメントは、タイプの構文やセマンティクスを変更しない別の「タイプ」ステートメントに置き換えることができます。たとえば、インラインタイプ定義はtypedefに置き換えることができますが、構文が変化するため、INT8タイプをINT16に置き換えることはできません。
o Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs.
o データ定義ノードのセットは、構文的および意味的に同等のノードの別のセットに置き換えることができます。たとえば、リーフのセットは、同じリーフを持つグループ化の使用に置き換えることができます。
o A module may be split into a set of submodules, or a submodule may be removed, provided the definitions in the module do not change in any other way than allowed here.
o モジュールは、サブモジュールのセットに分割されるか、モジュールの定義がここで許可されている以外の方法で変更されない場合、サブモジュールを削除することもできます。
o The "prefix" statement may be changed, provided all local uses of the prefix also are changed.
o 接頭辞のすべてのローカル使用も変更されている場合、「プレフィックス」ステートメントが変更される場合があります。
Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier.
それ以外の場合、以前の定義のセマンティクスが変更された場合（つまり、上記で許可されているもの以外の定義以外の定義に対して非編集上の変更が行われる場合）、これは新しい識別子を使用して新しい定義によって達成する必要があります。
In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered.
データ定義ステートメントを置換として持っているステートメントでは、それらのデータ定義の表現を再注文してはなりません。
A YANG module can be translated into an alternative XML-based syntax called YIN. The translated module is called a YIN module. This section describes symmetric mapping rules between the two formats.
Yangモジュールは、Yinと呼ばれる代替XMLベースの構文に翻訳できます。翻訳されたモジュールはYinモジュールと呼ばれます。このセクションでは、2つの形式間の対称マッピングルールについて説明します。
The YANG and YIN formats contain equivalent information using different notations. The YIN notation enables developers to represent YANG data models in XML and therefore use the rich set of XML-based tools for data filtering and validation, automated generation of code and documentation, and other tasks. Tools like XSLT or XML validators can be utilized.
YangおよびYin形式には、異なる表記を使用して同等の情報が含まれています。Yin表記により、開発者はXMLのYangデータモデルを表現できるため、データフィルタリングと検証、コードとドキュメントの自動生成、およびその他のタスクにXMLベースのツールのリッチセットを使用できます。XSLTやXMLバリデーターなどのツールを利用できます。
The mapping between YANG and YIN does not modify the information content of the model. Comments and whitespace are not preserved.
YangとYinの間のマッピングは、モデルの情報コンテンツを変更しません。コメントと空白は保存されていません。
There is a one-to-one correspondence between YANG keywords and YIN elements. The local name of a YIN element is identical to the corresponding YANG keyword. This means, in particular, that the document element (root) of a YIN document is always <module> or <submodule>.
YangキーワードとYin要素の間には1対1の対応があります。Yin要素のローカル名は、対応するYangキーワードと同じです。これは、特に、yinドキュメントのドキュメント要素（ルート）が常に<モジュール>または<submodule>であることを意味します。
YIN elements corresponding to the YANG keywords belong to the namespace whose associated URI is "urn:ietf:params:xml:ns:yang:yin:1".
ヤンキーワードに対応するYin要素は、関連するURIが「urn：ietf：params：xml：ns：yang：yin：1」である名前空間に属します。
YIN elements corresponding to extension keywords belong to the namespace of the YANG module where the extension keyword is declared via the "extension" statement.
拡張キーワードに対応するYin要素は、拡張キーワードが「拡張機能」ステートメントを介して宣言されるYangモジュールの名前空間に属します。
The names of all YIN elements MUST be properly qualified with their namespaces specified above using the standard mechanisms of [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes.
すべてのyin要素の名前は、[xml-names]の標準メカニズム、つまり「xmlns」および「xmlns：xxx」属性の標準メカニズムを使用して、上記で指定された名前空間で適切に修飾する必要があります。
The argument of a YANG statement is represented in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the mapping for the set of YANG keywords. For extensions, the argument mapping is specified within the "extension" statement (see Section 7.17). The following rules hold for arguments:
Yangステートメントの引数は、YinでXML属性またはキーワード要素のサブレメントとして表されます。表1は、Yangキーワードのセットのマッピングを定義しています。拡張機能の場合、引数マッピングは「拡張機能」ステートメント内で指定されています（セクション7.17を参照）。議論のための次のルールが保持されます。
o If the argument is represented as an attribute, this attribute has no namespace.
o 引数が属性として表されている場合、この属性には名前空間がありません。
o If the argument is represented as an element, it is qualified by the same namespace as its parent keyword element.
o 引数が要素として表されている場合、親キーワード要素と同じ名前空間で適格です。
o If the argument is represented as an element, it MUST be the first child of the keyword element.
o 引数が要素として表されている場合、キーワード要素の最初の子でなければなりません。
Substatements of a YANG statement are represented as (additional) children of the keyword element and their relative order MUST be the same as the order of substatements in YANG.
ヤン声明の置換は、キーワード要素の（追加の）子供として表され、その相対順序はヤンの置換の順序と同じでなければなりません。
Comments in YANG MAY be mapped to XML comments.
Yangのコメントは、XMLコメントにマッピングされる場合があります。
Mapping of arguments of the YANG statements.
ヤン声明の議論のマッピング。
+------------------+---------------+-------------+
| keyword | argument name | yin-element |
+------------------+---------------+-------------+
| anyxml | name | false |
| argument | name | false |
| augment | target-node | false |
| base | name | false |
| belongs-to | module | false |
| bit | name | false |
| case | name | false |
| choice | name | false |
| config | value | false |
| contact | text | true |
| container | name | false |
| default | value | false |
| description | text | true |
| deviate | value | false |
| deviation | target-node | false |
| enum | name | false |
| error-app-tag | value | false |
| error-message | value | true |
| extension | name | false |
| feature | name | false |
| fraction-digits | value | false |
| grouping | name | false |
| identity | name | false |
| if-feature | name | false |
| import | module | false |
| include | module | false |
| input | <no argument> | n/a |
| key | value | false |
| leaf | name | false |
| leaf-list | name | false |
| length | value | false |
| list | name | false |
| mandatory | value | false |
| max-elements | value | false |
| min-elements | value | false |
| module | name | false |
| must | condition | false |
| namespace | uri | false |
| notification | name | false |
| ordered-by | value | false |
| organization | text | true |
| output | <no argument> | n/a |
| path | value | false |
| pattern | value | false |
| position | value | false |
| prefix | value | false |
| presence | value | false |
| range | value | false |
| reference | text | true |
| refine | target-node | false |
| require-instance | value | false |
| revision | date | false |
| revision-date | date | false |
| rpc | name | false |
| status | value | false |
| submodule | name | false |
| type | name | false |
| typedef | name | false |
| unique | tag | false |
| units | name | false |
| uses | name | false |
| value | value | false |
| when | condition | false |
| yang-version | value | false |
| yin-element | value | false |
+------------------+---------------+-------------+
Table 1
表1
The following YANG module:
次のYangモジュール：
module acme-foo { namespace "http://acme.example.com/foo"; prefix "acfoo";
モジュールacme-foo {namespace "http://acme.example.com/foo";接頭辞「acfoo」;
import my-extensions {
prefix "myext";
}
list interface {
key "name";
leaf name {
type string;
}
leaf mtu {
type uint32;
description "The MTU of the interface.";
myext:c-define "MY_MTU";
}
}
}
where the extension "c-define" is defined in Section 7.17.3, is translated into the following YIN:
拡張「C-Define」がセクション7.17.3で定義されている場合、次の陰に変換されます。
<module name="acme-foo"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:acfoo="http://acme.example.com/foo"
xmlns:myext="http://example.com/my-extensions">
<namespace uri="http://acme.example.com/foo"/>
<prefix value="acfoo"/>
<import module="my-extensions">
<prefix value="myext"/>
</import>
<list name="interface">
<key value="name"/>
<leaf name="name">
<type name="string"/>
</leaf>
<leaf name="mtu">
<type name="uint32"/>
<description>
<text>The MTU of the interface.</text>
</description>
<myext:c-define name="MY_MTU"/>
</leaf>
</list>
</module>
In YANG, almost all statements are unordered. The ABNF grammar [RFC5234] defines the canonical order. To improve module readability, it is RECOMMENDED that clauses be entered in this order.
ヤンでは、ほとんどすべての声明が順序付けられていません。ABNF文法[RFC5234]は、標準的な順序を定義します。モジュールの読みやすさを改善するには、この順序で句を入力することをお勧めします。
Within the ABNF grammar, unordered statements are marked with comments.
ABNFの文法内では、順序付けられていないステートメントにコメントが付いています。
This grammar assumes that the scanner replaces YANG comments with a single space character.
この文法は、スキャナーがYangのコメントを単一のスペース文字に置き換えると想定しています。
<CODE BEGINS> file "yang.abnf"
<code begins> file "yang.abnf"
module-stmt = optsep module-keyword sep identifier-arg-str optsep "{" stmtsep module-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep
Module-stmt = optsep module-keyword sep identifier-arg-str optsep "{" stmtsep module-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep
submodule-stmt = optsep submodule-keyword sep identifier-arg-str optsep "{" stmtsep submodule-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep
submodule-stmt = optsep submodule-keyword sep identifier-arg-str optsep "{" stmtsep submodule-header-stmts linkage-stmts meta-stmts revision-stmts body-stmts "}" optsep
module-header-stmts = ;; these stmts can appear in any order [yang-version-stmt stmtsep] namespace-stmt stmtsep prefix-stmt stmtsep
module-header-stmts = ;;これらのstmtsは任意の順序で表示できます[yang-version-stmt stmtsep] namespace-stmt stmtsep prefix-stmt stmtsep
submodule-header-stmts = ;; these stmts can appear in any order [yang-version-stmt stmtsep] belongs-to-stmt stmtsep
submodule-header-stmts = ;;これらのstmtsは任意の順序で表示できます[yang-version-stmt stmtsep]はstmt stmtsepに属します
meta-stmts = ;; these stmts can appear in any order
[organization-stmt stmtsep]
[contact-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep)
*(include-stmt stmtsep)
revision-stmts = *(revision-stmt stmtsep)
body-stmts = *((extension-stmt /
feature-stmt /
identity-stmt /
typedef-stmt /
grouping-stmt /
data-def-stmt /
augment-stmt /
rpc-stmt /
notification-stmt /
deviation-stmt) stmtsep)
data-def-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / choice-stmt / anyxml-stmt / uses-stmt
data-def-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / choice-stmt / anyxml-stmt / uses-stmt
yang-version-stmt = yang-version-keyword sep yang-version-arg-str optsep stmtend
Yang-version-stmt = yang-version-keyword sep yang-version-arg-str optsep stmtend
yang-version-arg-str = < a string that matches the rule
yang-version-arg >
yang-version-arg = "1"
import-stmt = import-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep [revision-date-stmt stmtsep] "}"
import-stmt = import-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep [revision-date-stmt stmtsep] "}"
include-stmt = include-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [revision-date-stmt stmtsep] "}")
include-stmt = include-keyword sep identifier-arg-str optsep（ ";" / "{" stmtsep [revision-date-stmt stmtsep] "}"）
namespace-stmt = namespace-keyword sep uri-str optsep stmtend
namespace-stmt = namespace-keyword sep uri-str optsep stmtend
uri-str = < a string that matches the rule
URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str optsep stmtend
プレフィックス-stmt = prefix-keyword sep prefix-arg-str optsep stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep "}"
属するstmt = bunlds-keyword to-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep "}"
organization-stmt = organization-keyword sep string optsep stmtend
組織-STMT = Organization-KeyWord SEP String OptSep Stmtend
contact-stmt = contact-keyword sep string optsep stmtend
contact-stmt = contact-keyword sep string optsep stmtend
description-stmt = description-keyword sep string optsep stmtend
Description-stmt = description-Keyword SEP文字列OptSep stmtend
reference-stmt = reference-keyword sep string optsep stmtend
Reference-STMT = Reference-KeyWord SEP文字列OptSep Stmtend
units-stmt = units-keyword sep string optsep stmtend
revision-stmt = revision-keyword sep revision-date optsep (";" / "{" stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] "}")
Revision-stmt = Revision-Keyword sep revision-date optsep（ ";" / "{" stmtsep [description-stmt stmtsep] [Reference-stmt stmtsep] "}"）
revision-date = date-arg-str
revision-date-stmt = revision-date-keyword sep revision-date stmtend
extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[argument-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
argument-stmt = argument-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [yin-element-stmt stmtsep] "}")
argument-stmt = argument-keyword sep identifier-arg-str optsep（ ";" / "{" stmtsep [yin-element-stmt stmtsep] "}"）
yin-element-stmt = yin-element-keyword sep yin-element-arg-str stmtend
yin-element-stmt = yin-element-keyword sep yin-element-arg-stmtend
yin-element-arg-str = < a string that matches the rule
yin-element-arg >
yin-element-arg = true-keyword / false-keyword
identity-stmt = identity-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[base-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
base-stmt = base-keyword sep identifier-ref-arg-str optsep stmtend
base-stmt = base-keyword sep identifier-ref-arg-str optsep stmtend
feature-stmt = feature-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str optsep stmtend
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str optsep stmtend
typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
type-stmt stmtsep
[units-stmt stmtsep]
[default-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
type-stmt = type-keyword sep identifier-ref-arg-str optsep (";" / "{" stmtsep type-body-stmts "}")
Type-stmt = type-Keyword sep識別子ref-arg-str optsep（ ";" / "{" stmtsep type-body-stmts "}"）
type-body-stmts = numerical-restrictions / decimal64-specification / string-restrictions / enum-specification / leafref-specification / identityref-specification / instance-identifier-specification / bits-specification / union-specification
Type-body-stmts =数値 - 制限 / Decimal64仕様 /文字列restrictions / enum-depecification / leafrefpecification / Identity-refpecification / instance-identier-depecification / bits仕様 /組合仕様化
numerical-restrictions = range-stmt stmtsep
range-stmt = range-keyword sep range-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
decimal64-specification = fraction-digits-stmt
fraction-digits-stmt = fraction-digits-keyword sep fraction-digits-arg-str stmtend
fraction-digits-stmt = fraction-digits-keyword sep fraction-digits-arg-stmtend
fraction-digits-arg-str = < a string that matches the rule
fraction-digits-arg >
fraction-digits-arg = ("1" ["0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8"])
/ "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
string-restrictions = ;; these stmts can appear in any order [length-stmt stmtsep] *(pattern-stmt stmtsep)
string-restrictions = ;;これらのstmtsは任意の順序で表示できます[lengthstmt stmtsep] *（pattern-stmt stmtsep）
length-stmt = length-keyword sep length-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
pattern-stmt = pattern-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
default-stmt = default-keyword sep string stmtend
enum-specification = 1*(enum-stmt stmtsep)
enum-stmt = enum-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[value-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
leafref-specification = ;; these stmts can appear in any order path-stmt stmtsep [require-instance-stmt stmtsep]
leafref-specification = ;;これらのSTMTは、任意の任意の順序Path-stmt stmtsep [require-instance-stmt stmtsep]に表示できます。
path-stmt = path-keyword sep path-arg-str stmtend
require-instance-stmt = require-instance-keyword sep require-instance-arg-str stmtend
require-instance-stmt = require-instance-keyword sep recult-instance-arg-stmtend
require-instance-arg-str = < a string that matches the rule
require-instance-arg >
require-instance-arg = true-keyword / false-keyword
instance-identifier-specification = [require-instance-stmt stmtsep]
instance-identifier-specification = [necluse-instance-stmt stmtsep]
identityref-specification =
base-stmt stmtsep
union-specification = 1*(type-stmt stmtsep)
bits-specification = 1*(bit-stmt stmtsep)
bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[position-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
"}")
position-stmt = position-keyword sep position-value-arg-str stmtend
position-stmt = position-keyword sep position-value-arg-stmtend
position-value-arg-str = < a string that matches the rule
position-value-arg >
position-value-arg = non-negative-integer-value
status-stmt = status-keyword sep status-arg-str stmtend
status-arg-str = < a string that matches the rule
status-arg >
status-arg = current-keyword / obsolete-keyword / deprecated-keyword
status-arg = current-keyword / oberete-keyword / deprecated-keyword
config-stmt = config-keyword sep config-arg-str stmtend
config-stmt = config-keyword sep config-arg-stmtend
config-arg-str = < a string that matches the rule
config-arg >
config-arg = true-keyword / false-keyword
mandatory-stmt = mandatory-keyword sep mandatory-arg-str stmtend
必須stmt =必須キーワードsep encort-arg-stmtend
mandatory-arg-str = < a string that matches the rule
mandatory-arg >
mandatory-arg = true-keyword / false-keyword
presence-stmt = presence-keyword sep string stmtend
ordered-by-stmt = ordered-by-keyword sep ordered-by-arg-str stmtend
注文ごとに注文済みのキーワードごとに注文済みstmtendごとに注文しました
ordered-by-arg-str = < a string that matches the rule
ordered-by-arg >
ordered-by-arg = user-keyword / system-keyword
must-stmt = must-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
error-message-stmt = error-message-keyword sep string stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend min-elements-stmt = min-elements-keyword sep min-value-arg-str stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend min-elements-stmt = min-elements-keyword sep min-value-arg-stmtend
min-value-arg-str = < a string that matches the rule
min-value-arg >
min-value-arg = non-negative-integer-value
max-elements-stmt = max-elements-keyword sep max-value-arg-str stmtend
max-elements-stmt = max-elements-keyword sep max-value-arg-stmtend
max-value-arg-str = < a string that matches the rule
max-value-arg >
max-value-arg = unbounded-keyword / positive-integer-value
max-value-arg = unbound-keyword / positive-integer-value
value-stmt = value-keyword sep integer-value stmtend
grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
container-stmt = container-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
leaf-stmt = leaf-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
list-stmt = list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[key-stmt stmtsep]
*(unique-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt / grouping-stmt) stmtsep) 1*(data-def-stmt stmtsep) "}"
*（（typedef-stmt / grouping-stmt）stmtsep）1*（data-def-stmt stmtsep） "}"
key-stmt = key-keyword sep key-arg-str stmtend
key-arg-str = < a string that matches the rule
key-arg >
key-arg = node-identifier *(sep node-identifier)
key-arg = node-identifier *（sep node-identifier）
unique-stmt = unique-keyword sep unique-arg-str stmtend
unique-stmt = unique-keyword sep sique-arg-strtr stmtend
unique-arg-str = < a string that matches the rule
unique-arg >
unique-arg = descendant-schema-nodeid *(sep descendant-schema-nodeid)
unique-arg = descendant-schema-nodeid *（sep descendant-schema-nodeid）
choice-stmt = choice-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((short-case-stmt / case-stmt) stmtsep)
"}")
short-case-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / anyxml-stmt
ショートセースstmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / anyxml-stmt
case-stmt = case-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) [status-stmt stmtsep]
case-stmt = case-keyword sep identifier-arg-str optsep（ ";" / "{" stmtsep ;;これらのstmtsは任意の順序で表示できます[when stmt stmtsep] *（if-feature stmt stmtsep）[status-stmt stmtsep]
[description-stmt stmtsep] [reference-stmt stmtsep] *(data-def-stmt stmtsep) "}")
[description-stmt stmtsep] [Reference-stmt stmtsep] *（data-def-stmt stmtsep） "}"）
anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
uses-stmt = uses-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(refine-stmt stmtsep)
*(uses-augment-stmt stmtsep)
"}")
refine-stmt = refine-keyword sep refine-arg-str optsep (";" / "{" stmtsep (refine-container-stmts / refine-leaf-stmts / refine-leaf-list-stmts / refine-list-stmts / refine-choice-stmts / refine-case-stmts / refine-anyxml-stmts) "}")
Refine-stmt = refine-keyword sep refine-arg-str optsep（ ";" / "{" stmtsep（refine-container-stmts / refine-leaf-stmts / refine-leaf-list-stmts / refine-list-stmts /Refine-choice-stmts / refine-case-stmts / refine-anyxml-stmts） "}"）
refine-arg-str = < a string that matches the rule
refine-arg >
refine-arg = descendant-schema-nodeid
refine-container-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-leaf-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-leaf-list-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-list-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-choice-stmts = ;; these stmts can appear in any order
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-case-stmts = ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep]
refine-case-stmts = ;;これらのstmtsは任意の順序で表示できます[description-stmt stmtsep] [Reference-stmt stmtsep]
refine-anyxml-stmts = ;; these stmts can appear in any order *(must-stmt stmtsep) [config-stmt stmtsep]
refine-anyxml-stmts = ;;これらのstmtsは任意の順序で表示できます *（必須stmtsep）[configstmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
uses-augment-arg-str = < a string that matches the rule
uses-augment-arg >
uses-augment-arg = descendant-schema-nodeid
augment-stmt = augment-keyword sep augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
augment-arg-str = < a string that matches the rule
augment-arg >
augment-arg = absolute-schema-nodeid
unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}")
unknown-statement2 = [prefix ":"] identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}")
when-stmt = when-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep] [reference-stmt stmtsep] "}")
[description-stmt stmtsep] [Reference-stmt stmtsep] "}"）
rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
[input-stmt stmtsep]
[output-stmt stmtsep]
"}")
input-stmt = input-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
output-stmt = output-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
notification-stmt = notification-keyword sep
identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
deviation-stmt = deviation-keyword sep deviation-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] (deviate-not-supported-stmt / 1*(deviate-add-stmt / deviate-replace-stmt / deviate-delete-stmt)) "}"
Deviation-stmt = deviation-Keyword sep deviation-arg-str optsep "{" stmtsep ;;これらのstmtsは、任意の順序で表示できます。「}」
deviation-arg-str = < a string that matches the rule
deviation-arg >
deviation-arg = absolute-schema-nodeid
deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword optsep (";" / "{" stmtsep "}")
deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword optsep（ ";" / "{" stmtsep "}"）
deviate-add-stmt = deviate-keyword sep add-keyword optsep
(";" /
"{" stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")
deviate-delete-stmt = deviate-keyword sep delete-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}")
Deviate-delete-stmt = deviate-keyword sep delete-keyword optsep（ ";" / "{" stmtsep [units-stmt stmtsep] *（best-stmt stmtsep） *（inquire stmt stmtsep）[default stmt stmtsep] "} "）
deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
(";" /
"{" stmtsep
[type-stmt stmtsep]
[units-stmt stmtsep]
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")
;; Ranges
;;範囲
range-arg-str = < a string that matches the rule
range-arg >
range-arg = range-part *(optsep "|" optsep range-part)
range-arg = range-part *（optsep "|" optsepレンジパート）
range-part = range-boundary [optsep ".." optsep range-boundary]
レンジパート=レンジバウンダリー[optsep ".." optsep range-boundary]
range-boundary = min-keyword / max-keyword /
integer-value / decimal-value
;; Lengths
;;長さ
length-arg-str = < a string that matches the rule
length-arg >
length-arg = length-part *(optsep "|" optsep length-part)
length-arg = length-part *（optsep "|" optsep length-part）
length-part = length-boundary [optsep ".." optsep length-boundary]
長さパート=長さの境界[optsep ".." optsep lengthary]
length-boundary = min-keyword / max-keyword / non-negative-integer-value
長さの境界= min-keyword / max-keyword / non-negative-integer-value
;; Date
;;日にち
date-arg-str = < a string that matches the rule
date-arg >
date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT
date-arg = 4digit " - " 2digit " - " 2digit
;; Schema Node Identifiers
;;スキーマノード識別子
schema-nodeid = absolute-schema-nodeid / descendant-schema-nodeid
schema-nodeid = absolute-schema-nodeid / descendant-schema-nodeid
absolute-schema-nodeid = 1*("/" node-identifier)
descendant-schema-nodeid = node-identifier absolute-schema-nodeid
Descendant-schema-nodeid = node-identifier Absolute-schema-nodeid
node-identifier = [prefix ":"] identifier
;; Instance Identifiers
;;インスタンス識別子
instance-identifier = 1*("/" (node-identifier *predicate))
predicate = "[" *WSP (predicate-expr / pos) *WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP
((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE))
pos = non-negative-integer-value
;; leafref path
;;葉のパス
path-arg-str = < a string that matches the rule
path-arg >
path-arg = absolute-path / relative-path
absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*(".." "/") descendant-path
descendant-path = node-identifier [*path-predicate absolute-path]
descendant-path = node-identifier [*path-predicate absolute-path]
path-predicate = "[" *WSP path-equality-expr *WSP "]"
path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr
path-key-expr = current-function-invocation *WSP "/" *WSP rel-path-keyexpr
path-key-expr = current-function-invocation *wsp "/" *wsp rel-path-keyexpr
rel-path-keyexpr = 1*(".." *WSP "/" *WSP)
*(node-identifier *WSP "/" *WSP)
node-identifier
;;; Keywords, using abnfgen's syntax for case-sensitive strings
;; statement keywords
anyxml-keyword = 'anyxml'
argument-keyword = 'argument'
augment-keyword = 'augment'
base-keyword = 'base'
belongs-to-keyword = 'belongs-to'
bit-keyword = 'bit'
case-keyword = 'case'
choice-keyword = 'choice'
config-keyword = 'config'
contact-keyword = 'contact'
container-keyword = 'container'
default-keyword = 'default'
description-keyword = 'description'
enum-keyword = 'enum'
error-app-tag-keyword = 'error-app-tag'
error-message-keyword = 'error-message'
extension-keyword = 'extension'
deviation-keyword = 'deviation'
deviate-keyword = 'deviate'
feature-keyword = 'feature'
fraction-digits-keyword = 'fraction-digits'
grouping-keyword = 'grouping'
identity-keyword = 'identity'
if-feature-keyword = 'if-feature'
import-keyword = 'import'
include-keyword = 'include'
input-keyword = 'input'
key-keyword = 'key'
leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list'
length-keyword = 'length'
list-keyword = 'list'
mandatory-keyword = 'mandatory'
max-elements-keyword = 'max-elements'
min-elements-keyword = 'min-elements'
module-keyword = 'module'
must-keyword = 'must'
namespace-keyword = 'namespace'
notification-keyword= 'notification'
ordered-by-keyword = 'ordered-by'
organization-keyword= 'organization'
output-keyword = 'output'
path-keyword = 'path'
pattern-keyword = 'pattern'
position-keyword = 'position'
prefix-keyword = 'prefix'
presence-keyword = 'presence'
range-keyword = 'range'
reference-keyword = 'reference'
refine-keyword = 'refine'
require-instance-keyword = 'require-instance'
revision-keyword = 'revision'
revision-date-keyword = 'revision-date'
rpc-keyword = 'rpc'
status-keyword = 'status'
submodule-keyword = 'submodule'
type-keyword = 'type'
typedef-keyword = 'typedef'
unique-keyword = 'unique'
units-keyword = 'units'
uses-keyword = 'uses'
value-keyword = 'value'
when-keyword = 'when'
yang-version-keyword= 'yang-version'
yin-element-keyword = 'yin-element'
;; other keywords
;;その他のキーワード
add-keyword = 'add'
current-keyword = 'current'
delete-keyword = 'delete'
deprecated-keyword = 'deprecated'
false-keyword = 'false'
max-keyword = 'max'
min-keyword = 'min'
not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete'
replace-keyword = 'replace'
system-keyword = 'system'
true-keyword = 'true'
unbounded-keyword = 'unbounded'
user-keyword = 'user'
current-function-invocation = current-keyword *WSP "(" *WSP ")"
;; Basic Rules
;;基本的なルール
prefix-arg-str = < a string that matches the rule
prefix-arg >
prefix-arg = prefix
prefix = identifier
identifier-arg-str = < a string that matches the rule
identifier-arg >
identifier-arg = identifier
;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string that matches the rule
identifier-ref-arg >
identifier-ref-arg = [prefix ":"] identifier
string = < an unquoted string as returned by
the scanner >
integer-value = ("-" non-negative-integer-value) /
non-negative-integer-value
non-negative-integer-value = "0" / positive-integer-value
非否定的-Integer-Value = "0" / positive-integer-value
positive-integer-value = (non-zero-digit *DIGIT)
zero-integer-value = 1*DIGIT
stmtend = ";" / "{" *unknown-statement "}"
sep = 1*(WSP / line-break)
; unconditional separator
optsep = *(WSP / line-break)
stmtsep = *(WSP / line-break / unknown-statement)
line-break = CRLF / LF
non-zero-digit = %x31-39
decimal-value = integer-value ("." zero-integer-value)
Decimal-value = integer-value（ "。" zero-integer-value）
SQUOTE = %x27
; ' (Single Quote)
;;
;; RFC 5234 core rules.
;;
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
CR = %x0D
; carriage return
CRLF = CR LF ; Internet standard new line
crlf = cr lf;インターネット標準の新しいライン
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
; only lower-case a..f
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
SP = %x20
; space
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB ; whitespace
wsp = sp / htab;空白
<CODE ENDS>
<コードエンド>
A number of NETCONF error responses are defined for error cases related to the data-model handling. If the relevant YANG statement has an "error-app-tag" substatement, that overrides the default value specified below.
データモデルの処理に関連するエラーケースに対して、多くのNetConfエラー応答が定義されています。関連するYangステートメントに「エラーアプリタグ」のサクセクトメントがある場合、以下に指定されたデフォルト値をオーバーライドします。
If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned:
NetConf操作により、一意の制約が無効になる構成データが得られると、次のエラーが返されます。
error-tag: operation-failed error-app-tag: data-not-unique error-info: <non-unique>: Contains an instance identifier that points to a leaf that invalidates the unique constraint. This element is present once for each non-unique leaf.
エラータグ：操作型のエラーアプリタグ：data-not-unique error-info：<nonique>：一意の制約を無効にする葉を指すインスタンス識別子が含まれています。この要素は、非ユニーク葉ごとに1回存在します。
The <non-unique> element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1").
<非unique>要素はYang Namespace（ "urn：ietf：params：xml：ns：yang：1"）にあります。
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too many entries the following error is returned:
NetConf操作により、リストまたはリーフリストがあまりにも多くのエントリがある構成データが得られる場合、次のエラーが返されます。
error-tag: operation-failed error-app-tag: too-many-elements
エラータグ：操作型のエラーアプリタグ：マニュティーエレメントが多すぎます
This error is returned once, with the error-path identifying the list node, even if there are more than one extra child present.
このエラーは、エラーパスがリストノードを識別し、たとえ複数の余分な子供が存在している場合でも、一度返されます。
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too few entries the following error is returned:
NetConf操作により、リストまたはリーフリストのエントリが少なすぎる構成データが得られる場合、次のエラーが返されます。
error-tag: operation-failed error-app-tag: too-few-elements
エラータグ：操作型のエラーアプリタグ：繰り返しエレメント
This error is returned once, with the error-path identifying the list node, even if there are more than one child missing.
このエラーは、複数の子供が欠落している場合でも、エラーパスがリストノードを識別することで、一度返されます。
If a NETCONF operation would result in configuration data where the restrictions imposed by a "must" statement is violated the following error is returned, unless a specific "error-app-tag" substatement is present for the "must" statement.
NetConf操作により、「必須」ステートメントに特定の「エラーアプリタグ」のサクセクトメントが存在しない限り、「マスト」ステートメントによって課される制限が「マスト」ステートメントに違反される構成データが得られる場合、次のエラーが返されます。
error-tag: operation-failed error-app-tag: must-violation
エラータグ：オペレーションフェイルのエラーアプリタグ：必見
If a NETCONF operation would result in configuration data where a leaf of type "instance-identifier" marked with require-instance "true" refers to a non-existing instance, the following error is returned:
NetConf操作により、「Instance-Identifier」というタイプの葉が要求にマークされた「true」とマークされた構成データが存在する場合、存在しないインスタンスを指します。次のエラーが返されます。
error-tag: data-missing error-app-tag: instance-required error-path: Path to the instance-identifier leaf.
エラータグ：Data Missing Error-App-Tag：Instance-Required Error-Path：Instance-Identifier Leafへのパス。
If a NETCONF operation would result in configuration data where a leaf of type "leafref" refers to a non-existing instance, the following error is returned:
NetConf操作により、タイプ「Leafref」の葉が存在しないインスタンスを指す構成データが得られる場合、次のエラーが返されます。
error-tag: data-missing error-app-tag: instance-required error-path: Path to the leafref leaf.
エラータグ：Data Missing Error-App-Tag：Instance-Required Error-Path：Leafref Leafへのパス。
If a NETCONF operation would result in configuration data where no nodes exists in a mandatory choice, the following error is returned:
NetConf操作により、必須の選択肢にノードが存在しない構成データが得られる場合、次のエラーが返されます。
error-tag: data-missing error-app-tag: missing-choice error-path: Path to the element with the missing choice. error-info: <missing-choice>: Contains the name of the missing mandatory choice.
エラータグ：データミッシングエラーアプリタグ：欠落選択エラーパス：欠落している選択肢のある要素へのパス。error-info：<Missing-Choice>：欠落している必須選択の名前が含まれています。
The <missing-choice> element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1").
<Missing-Choice>要素はYang Namespace（ "urn：ietf：params：xml：ns：yang：1"）にあります。
If the "insert" and "key" or "value" attributes are used in an <edit-config> for a list or leaf-list node, and the "key" or "value" refers to a non-existing instance, the following error is returned:
リストまたはリーフリストノードの<edit-config>で「挿入」および「キー」または「値」属性が使用され、「キー」または「値」が存在しないインスタンスを指します。次のエラーが返されます：
error-tag: bad-attribute error-app-tag: missing-instance
エラータグ：adttribute error-app-tag：欠落しているインスタンス
This document defines a registry for YANG module and submodule names. The name of the registry is "YANG Module Names".
このドキュメントでは、Yangモジュールとサブモジュール名のレジストリを定義します。レジストリの名前は「Yangモジュール名」です。
The registry shall record for each entry:
レジストリは、各エントリの記録を記録します。
o the name of the module or submodule
o モジュールまたはサブモジュールの名前
o for modules, the assigned XML namespace
o モジュールの場合、割り当てられたXMLネームスペース
o for modules, the prefix of the module
o モジュールの場合、モジュールのプレフィックス
o for submodules, the name of the module it belongs to
o サブモジュールの場合、それが属するモジュールの名前
o a reference to the (sub)module's documentation (e.g., the RFC number)
o （サブ）モジュールのドキュメントへの参照（例：RFC番号）
There are no initial assignments.
初期割り当てはありません。
For allocation, RFC publication is required as per RFC 5226 [RFC5226]. All registered YANG module names MUST comply with the rules for identifiers stated in Section 6.2, and MUST have a module name prefix.
割り当てのために、RFC 5226 [RFC5226]に従ってRFCの出版物が必要です。登録されたすべてのYangモジュール名は、セクション6.2に記載されている識別子のルールに準拠する必要があり、モジュール名のプレフィックスが必要です。
The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844], while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams MUST have a similar suitable prefix.
モジュール名のプレフィックス「IETF-」はIETFストリームドキュメント[RFC4844]用に予約されていますが、モジュール名のプレフィックス「IRTF-」はIRTFストリームドキュメント用に予約されています。他のRFCストリームで公開されているモジュールには、同様の適切なプレフィックスが必要です。
All module and submodule names in the registry MUST be unique.
レジストリ内のすべてのモジュール名とサブモジュール名は一意でなければなりません。
All XML namespaces in the registry MUST be unique.
レジストリ内のすべてのXMLネームスペースは一意でなければなりません。
This document registers two URIs for the YANG and YIN XML namespaces in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following have been registered.
このドキュメントは、IETF XMLレジストリ[RFC3688]のYangおよびYin XMLネームスペースの2つのURIを登録します。RFC 3688の形式に続いて、以下が登録されています。
URI: urn:ietf:params:xml:ns:yang:yin:1
URI: urn:ietf:params:xml:ns:yang:1
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URIs are XML namespaces.
XML：n/a、要求されたurisはXMLネームスペースです。
This document registers two new media types as defined in the following sections.
このドキュメントは、次のセクションで定義されている2つの新しいメディアタイプを登録します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: yang
MIMEサブタイプ名：Yang
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: 8-bit
考慮事項のエンコード：8ビット
Security considerations: See Section 15 in RFC 6020
セキュリティ上の考慮事項：RFC 6020のセクション15を参照してください
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 6020
公開された仕様：RFC 6020
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
YANG module validators, web servers used for downloading YANG modules, email clients, etc.
Yangモジュールのバリデーター、Yangモジュールのダウンロードに使用されるWebサーバー、クライアントにメールなど。
Additional information:
追加情報：
Magic Number: None
マジック番号：なし
File Extension: .yang
ファイル拡張子：.yang
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information:
Martin Bjorklund <mbj@tail-f.com>
Intended usage: COMMON
意図された使用法：共通
Author: This specification is a work item of the IETF NETMOD working group, with mailing list address <netmod@ietf.org>.
著者：この仕様は、IETF NetModワーキンググループのワークアイテムであり、メーリングリストアドレス<netmod@ietf.org>があります。
Change controller:
The IESG <iesg@ietf.org>
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: yin+xml
MIMEサブタイプ名：Yin XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
"charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023].
「charset」：このパラメーターには、[rfc3023]で指定されている「アプリケーション/xml」メディアタイプのcharsetパラメーターに対して同一のセマンティクスがあります。
Encoding considerations:
考慮事項のエンコード：
Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
[RFC3023]に記載されている「アプリケーション/XML」のものと同一、セクション3.2。
Security considerations: See Section 15 in RFC 6020
セキュリティ上の考慮事項：RFC 6020のセクション15を参照してください
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 6020
公開された仕様：RFC 6020
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
YANG module validators, web servers used for downloading YANG modules, email clients, etc.
Yangモジュールのバリデーター、Yangモジュールのダウンロードに使用されるWebサーバー、クライアントにメールなど。
Additional information:
追加情報：
Magic Number: As specified for "application/xml" in [RFC3023], Section 3.2.
マジック番号：[RFC3023]の「アプリケーション/XML」に指定されているように、セクション3.2。
File Extension: .yin
ファイル拡張子：.yin
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information:
Martin Bjorklund <mbj@tail-f.com>
Intended usage: COMMON Author: This specification is a work item of the IETF NETMOD working group, with mailing list address <netmod@ietf.org>.
意図された使用法：共通著者：この仕様は、IETF NetModワーキンググループのワークアイテムであり、メーリングリストアドレス<netmod@ietf.org>。
Change controller:
The IESG <iesg@ietf.org>
This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
このドキュメントは、管理情報の説明を書き、読む言語を定義します。言語自体はインターネットにセキュリティの影響を与えません。
The same considerations are relevant as for the base NETCONF protocol (see [RFC4741], Section 9).
同じ考慮事項は、ベースNetConfプロトコルと関連しています（[RFC4741]、セクション9を参照）。
Data modeled in YANG might contain sensitive information. RPCs or notifications defined in YANG might transfer sensitive information.
Yangでモデル化されたデータには、機密情報が含まれている場合があります。Yangで定義されているRPCまたは通知は、機密情報を転送する可能性があります。
Security issues are related to the usage of data modeled in YANG. Such issues shall be dealt with in documents describing the data models and documents about the interfaces used to manipulate the data e.g., the NETCONF documents.
セキュリティの問題は、ヤンでモデル化されたデータの使用に関連しています。このような問題は、データモデルとドキュメントを説明するドキュメントで、データを操作するために使用されるインターフェイスに関するドキュメントで扱われます。
Data modeled in YANG is dependent upon:
ヤンでモデル化されたデータは次のことに依存しています。
o the security of the transmission infrastructure used to send sensitive information.
o 機密情報を送信するために使用される送信インフラストラクチャのセキュリティ。
o the security of applications that store or release such sensitive information.
o このような機密情報を保存またはリリースするアプリケーションのセキュリティ。
o adequate authentication and access control mechanisms to restrict the usage of sensitive data.
o 機密データの使用を制限するための適切な認証およびアクセス制御メカニズム。
YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised.
Yangパーサーは、奇形のドキュメントに関して堅牢である必要があります。不明または信頼できないソースから奇形のドキュメントを読むと、攻撃者がYangパーサーを実行しているユーザーの特権を獲得する可能性があります。極端な状況では、マシン全体が損なわれる可能性があります。
The following people all contributed significantly to the initial YANG document:
次の人々はすべて、最初のYang文書に大きく貢献しました。
- Andy Bierman (Brocade) - Balazs Lengyel (Ericsson) - David Partain (Ericsson) - Juergen Schoenwaelder (Jacobs University Bremen) - Phil Shafer (Juniper Networks)
- Andy Bierman（Brocade） - Balazs Lengyel（Ericsson） - David Partain（Ericsson） - Juergen Schoenwaelder（Jacobs University Bremen） - Phil Shafer（Juniper Networks）
The editor wishes to thank the following individuals, who all provided helpful comments on various versions of this document: Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert Wijnen.
編集者は、このドキュメントのさまざまなバージョンについて有益なコメントを提供してくれた次の個人に感謝したいと考えています：Mehmet Ersue、Washam Fan、Joel Halpern、Leif Johansson、Ladislav Lhotka、Gerhard Muenz、Tom Petch、Randy Presuhn、David Reid、BertWijnen。
[ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO Standard 10646:2003, 2003.
[ISO.10646]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS）」、ISO Standard 10646：2003、2003。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NetConf Event Notifications」、RFC 5277、2008年7月。
[XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Layman, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XML-Names] Hollander、D.、Tobin、R.、Thompson、H.、Bray、T。、およびA. Layman、「XML 1.0の名前空間（第3版）」、World Wide Webコンソーシアムの推奨REC-XML-Names-20091208、2009年12月、<http://www.w3.org/tr/2009/rec-xml-names-20091208>。
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPath] Clark、J。およびS. Derose、「XML Path Language（XPath）バージョン1.0」、World Wide Web Consortiumの推奨REC-XPATH-19991116、1999年11月、<http://www.w3.org/tr/1999/rec-xpath-1991116>。
[XSD-TYPES] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSD-Types] Malhotra、A。およびP. Biron、「XML Schema Part 2：DataTypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSchema-2-20041028、2004年10月、<http：//www.w3。ORG/TR/2004/REC-XMLSCHEMA-2-20041028>。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「Smiv2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation Structure of Management Information", RFC 3780, May 2004.
[RFC3780] Strauss、F。およびJ. Schoenwaelder、「Sming-次世代管理情報の構造」、RFC 3780、2004年5月。
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle、L。およびインターネットアーキテクチャボード、「RFCシリーズおよびRFCエディター」、RFC 4844、2007年7月。
[XPATH2.0] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, January 2007, <http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[Xpath2.0] Berglund、A.、Boag、S.、Chamberlin、D.、Fernandez、M.、Kay、M.、Robie、J。、およびJ. Simeon、 "XML Path Language（XPath）2.0"、World Wide Web Consortiumの推奨REC-XPATH20-20070123、2007年1月、<http://www.w3.org/tr/2007/rec-xpath20-20070123>。
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[XSLT] Clark、J。、「XSL Transformations（XSLT）バージョン1.0」、World Wide Web Consortiumの推奨REC-XSLT-19991116、1999年11月、<http://www.w3.org/tr/1999/rec-xsltt-19991116>。
Author's Address
著者の連絡先
Martin Bjorklund (editor) Tail-f Systems
Martin Bjorklund（編集者）テールFシステム
EMail: mbj@tail-f.com