YANG 1.1データモデリング言語
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) M. Bjorklund, Ed.
Request for Comments: 7950 Tail-f Systems
Category: Standards Track August 2016
ISSN: 2070-1721
The YANG 1.1 Data Modeling Language
YANG 1.1データモデリング言語
Abstract
概要
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
YANGは、ネットワーク管理プロトコルの構成データ、状態データ、リモートプロシージャコール、および通知をモデル化するために使用されるデータモデリング言語です。 このドキュメントでは、YANG言語のバージョン1.1の構文とセマンティクスについて説明します。 YANGバージョン1.1は、YANG言語のメンテナンスリリースであり、元の仕様のあいまいさと欠陥に対処しています。 YANGバージョン1からの下位互換性の問題はいくつかあります。 このドキュメントでは、ネットワーク構成プロトコル（NETCONF）へのYANGマッピングも指定しています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 インターネット標準の詳細については、RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7950.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7950 で入手できます。
Bjorklund Standards Track [Page 1] RFC 7950 YANG 1.1 August 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権表示 Copyright（c）2016 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外でそのような資料の変更を許可する権利を与えていない可能性があります。 このような資料の著作権を管理する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセス外で変更できず、その形式を除いて、IETF標準プロセス外でその派生物を作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Bjorklund Standards Track [Page 2]
RFC 7950 YANG 1.1 August 2016
Table of Contents
1. Introduction ....................................................9
1.1. Summary of Changes from RFC 6020 ..........................10
2. Key Words ......................................................12
3. Terminology ....................................................12
3.1. A Note on Examples ........................................16
4. YANG Overview ..................................................16
4.1. Functional Overview .......................................16
4.2. Language Overview .........................................18
4.2.1. Modules and Submodules .............................18
4.2.2. Data Modeling Basics ...............................19
4.2.3. Configuration and State Data .......................23
4.2.4. Built-In Types .....................................24
4.2.5. Derived Types (typedef) ............................25
4.2.6. Reusable Node Groups (grouping) ....................25
4.2.7. Choices ............................................27
4.2.8. Extending Data Models (augment) ....................28
4.2.9. Operation Definitions ..............................29
4.2.10. Notification Definitions ..........................31
5. Language Concepts ..............................................32
5.1. Modules and Submodules ....................................32
5.1.1. Import and Include by Revision .....................33
5.1.2. Module Hierarchies .................................34
5.2. File Layout ...............................................36
5.3. XML Namespaces ............................................36
5.3.1. YANG XML Namespace .................................36
5.4. Resolving Grouping, Type, and Identity Names ..............37
5.5. Nested Typedefs and Groupings .............................37
5.6. Conformance ...............................................38
5.6.1. Basic Behavior .....................................38
5.6.2. Optional Features ..................................38
5.6.3. Deviations .........................................39
5.6.4. Announcing Conformance Information in NETCONF ......40
5.6.5. Implementing a Module ..............................40
5.7. Datastore Modification ....................................44
6. YANG Syntax ....................................................44
6.1. Lexical Tokenization ......................................45
6.1.1. Comments ...........................................45
6.1.2. Tokens .............................................45
6.1.3. Quoting ............................................45
6.2. Identifiers ...............................................47
6.2.1. Identifiers and Their Namespaces ...................47
6.3. Statements ................................................48
6.3.1. Language Extensions ................................48
6.4. XPath Evaluations .........................................49
6.4.1. XPath Context ......................................50
6.5. Schema Node Identifier ....................................54
Bjorklund Standards Track [Page 3]
RFC 7950 YANG 1.1 August 2016
7. YANG Statements ................................................55
7.1. The "module" Statement ....................................55
7.1.1. The module's Substatements .........................56
7.1.2. The "yang-version" Statement .......................57
7.1.3. The "namespace" Statement ..........................57
7.1.4. The "prefix" Statement .............................57
7.1.5. The "import" Statement .............................58
7.1.6. The "include" Statement ............................59
7.1.7. The "organization" Statement .......................60
7.1.8. The "contact" Statement ............................60
7.1.9. The "revision" Statement ...........................60
7.1.10. Usage Example .....................................61
7.2. The "submodule" Statement .................................62
7.2.1. The submodule's Substatements ......................63
7.2.2. The "belongs-to" Statement .........................63
7.2.3. Usage Example ......................................64
7.3. The "typedef" Statement ...................................65
7.3.1. The typedef's Substatements ........................65
7.3.2. The typedef's "type" Statement .....................65
7.3.3. The "units" Statement ..............................65
7.3.4. The typedef's "default" Statement ..................66
7.3.5. Usage Example ......................................66
7.4. The "type" Statement ......................................66
7.4.1. The type's Substatements ...........................67
7.5. The "container" Statement .................................67
7.5.1. Containers with Presence ...........................67
7.5.2. The container's Substatements ......................68
7.5.3. The "must" Statement ...............................69
7.5.4. The must's Substatements ...........................70
7.5.5. The "presence" Statement ...........................71
7.5.6. The container's Child Node Statements ..............71
7.5.7. XML Encoding Rules .................................71
7.5.8. NETCONF <edit-config> Operations ...................72
7.5.9. Usage Example ......................................72
7.6. The "leaf" Statement ......................................73
7.6.1. The leaf's Default Value ...........................74
7.6.2. The leaf's Substatements ...........................75
7.6.3. The leaf's "type" Statement ........................75
7.6.4. The leaf's "default" Statement .....................75
7.6.5. The leaf's "mandatory" Statement ...................76
7.6.6. XML Encoding Rules .................................76
7.6.7. NETCONF <edit-config> Operations ...................76
7.6.8. Usage Example ......................................77
7.7. The "leaf-list" Statement .................................77
7.7.1. Ordering ...........................................78
7.7.2. The leaf-list's Default Values .....................79
7.7.3. The leaf-list's Substatements ......................80
7.7.4. The leaf-list's "default" Statement ................80
Bjorklund Standards Track [Page 4]
RFC 7950 YANG 1.1 August 2016
7.7.5. The "min-elements" Statement .......................80
7.7.6. The "max-elements" Statement .......................81
7.7.7. The "ordered-by" Statement .........................81
7.7.8. XML Encoding Rules .................................82
7.7.9. NETCONF <edit-config> Operations ...................82
7.7.10. Usage Example .....................................83
7.8. The "list" Statement ......................................84
7.8.1. The list's Substatements ...........................85
7.8.2. The list's "key" Statement .........................85
7.8.3. The list's "unique" Statement ......................86
7.8.4. The list's Child Node Statements ...................87
7.8.5. XML Encoding Rules .................................88
7.8.6. NETCONF <edit-config> Operations ...................88
7.8.7. Usage Example ......................................90
7.9. The "choice" Statement ....................................93
7.9.1. The choice's Substatements .........................94
7.9.2. The choice's "case" Statement ......................94
7.9.3. The choice's "default" Statement ...................96
7.9.4. The choice's "mandatory" Statement .................98
7.9.5. XML Encoding Rules .................................98
7.9.6. Usage Example ......................................99
7.10. The "anydata" Statement .................................100
7.10.1. The anydata's Substatements ......................100
7.10.2. XML Encoding Rules ...............................101
7.10.3. NETCONF <edit-config> Operations .................101
7.10.4. Usage Example ....................................101
7.11. The "anyxml" Statement ..................................102
7.11.1. The anyxml's Substatements .......................103
7.11.2. XML Encoding Rules ...............................103
7.11.3. NETCONF <edit-config> Operations .................103
7.11.4. Usage Example ....................................104
7.12. The "grouping" Statement ................................104
7.12.1. The grouping's Substatements .....................105
7.12.2. Usage Example ....................................105
7.13. The "uses" Statement ....................................106
7.13.1. The uses's Substatements .........................106
7.13.2. The "refine" Statement ...........................106
7.13.3. XML Encoding Rules ...............................107
7.13.4. Usage Example ....................................107
7.14. The "rpc" Statement .....................................108
7.14.1. The rpc's Substatements ..........................109
7.14.2. The "input" Statement ............................109
7.14.3. The "output" Statement ...........................110
7.14.4. NETCONF XML Encoding Rules .......................111
7.14.5. Usage Example ....................................112
Bjorklund Standards Track [Page 5]
RFC 7950 YANG 1.1 August 2016
7.15. The "action" Statement ..................................113
7.15.1. The action's Substatements .......................114
7.15.2. NETCONF XML Encoding Rules .......................114
7.15.3. Usage Example ....................................115
7.16. The "notification" Statement ............................116
7.16.1. The notification's Substatements .................117
7.16.2. NETCONF XML Encoding Rules .......................117
7.16.3. Usage Example ....................................118
7.17. The "augment" Statement .................................119
7.17.1. The augment's Substatements ......................121
7.17.2. XML Encoding Rules ...............................121
7.17.3. Usage Example ....................................122
7.18. The "identity" Statement ................................124
7.18.1. The identity's Substatements .....................124
7.18.2. The "base" Statement .............................124
7.18.3. Usage Example ....................................125
7.19. The "extension" Statement ...............................126
7.19.1. The extension's Substatements ....................126
7.19.2. The "argument" Statement .........................127
7.19.3. Usage Example ....................................127
7.20. Conformance-Related Statements ..........................128
7.20.1. The "feature" Statement ..........................128
7.20.2. The "if-feature" Statement .......................130
7.20.3. The "deviation" Statement ........................131
7.21. Common Statements .......................................134
7.21.1. The "config" Statement ...........................134
7.21.2. The "status" Statement ...........................135
7.21.3. The "description" Statement ......................136
7.21.4. The "reference" Statement ........................136
7.21.5. The "when" Statement .............................136
8. Constraints ...................................................138
8.1. Constraints on Data ......................................138
8.2. Configuration Data Modifications .........................139
8.3. NETCONF Constraint Enforcement Model .....................139
8.3.1. Payload Parsing ...................................139
8.3.2. NETCONF <edit-config> Processing ..................140
8.3.3. Validation ........................................141
9. Built-In Types ................................................141
9.1. Canonical Representation .................................141
9.2. The Integer Built-In Types ...............................142
9.2.1. Lexical Representation ............................142
9.2.2. Canonical Form ....................................143
9.2.3. Restrictions ......................................143
9.2.4. The "range" Statement .............................143
9.2.5. Usage Example .....................................144
Bjorklund Standards Track [Page 6]
RFC 7950 YANG 1.1 August 2016
9.3. The decimal64 Built-In Type ..............................144
9.3.1. Lexical Representation ............................145
9.3.2. Canonical Form ....................................145
9.3.3. Restrictions ......................................145
9.3.4. The "fraction-digits" Statement ...................145
9.3.5. Usage Example .....................................146
9.4. The string Built-In Type .................................146
9.4.1. Lexical Representation ............................146
9.4.2. Canonical Form ....................................147
9.4.3. Restrictions ......................................147
9.4.4. The "length" Statement ............................147
9.4.5. The "pattern" Statement ...........................148
9.4.6. The "modifier" Statement ..........................148
9.4.7. Usage Example .....................................149
9.5. The boolean Built-In Type ................................150
9.5.1. Lexical Representation ............................150
9.5.2. Canonical Form ....................................150
9.5.3. Restrictions ......................................150
9.6. The enumeration Built-In Type ............................150
9.6.1. Lexical Representation ............................150
9.6.2. Canonical Form ....................................151
9.6.3. Restrictions ......................................151
9.6.4. The "enum" Statement ..............................151
9.6.5. Usage Example .....................................152
9.7. The bits Built-In Type ...................................154
9.7.1. Restrictions ......................................154
9.7.2. Lexical Representation ............................154
9.7.3. Canonical Form ....................................154
9.7.4. The "bit" Statement ...............................155
9.7.5. Usage Example .....................................156
9.8. The binary Built-In Type .................................157
9.8.1. Restrictions ......................................157
9.8.2. Lexical Representation ............................157
9.8.3. Canonical Form ....................................157
9.9. The leafref Built-In Type ................................157
9.9.1. Restrictions ......................................158
9.9.2. The "path" Statement ..............................158
9.9.3. The "require-instance" Statement ..................159
9.9.4. Lexical Representation ............................159
9.9.5. Canonical Form ....................................159
9.9.6. Usage Example .....................................159
9.10. The identityref Built-In Type ...........................163
9.10.1. Restrictions .....................................163
9.10.2. The identityref's "base" Statement ...............163
9.10.3. Lexical Representation ...........................163
9.10.4. Canonical Form ...................................164
9.10.5. Usage Example ....................................164
Bjorklund Standards Track [Page 7]
RFC 7950 YANG 1.1 August 2016
9.11. The empty Built-In Type .................................165
9.11.1. Restrictions .....................................165
9.11.2. Lexical Representation ...........................165
9.11.3. Canonical Form ...................................165
9.11.4. Usage Example ....................................166
9.12. The union Built-In Type .................................166
9.12.1. Restrictions .....................................166
9.12.2. Lexical Representation ...........................166
9.12.3. Canonical Form ...................................167
9.12.4. Usage Example ....................................167
9.13. The instance-identifier Built-In Type ...................168
9.13.1. Restrictions .....................................168
9.13.2. Lexical Representation ...........................169
9.13.3. Canonical Form ...................................169
9.13.4. Usage Example ....................................169
10. XPath Functions ..............................................170
10.1. Function for Node Sets ..................................170
10.1.1. current() ........................................170
10.2. Function for Strings ....................................170
10.2.1. re-match() .......................................170
10.3. Function for the YANG Types "leafref" and
"instance-identifier" ...................................171
10.3.1. deref() ..........................................171
10.4. Functions for the YANG Type "identityref" ...............172
10.4.1. derived-from() ...................................172
10.4.2. derived-from-or-self() ...........................174
10.5. Function for the YANG Type "enumeration" ................174
10.5.1. enum-value() .....................................174
10.6. Function for the YANG Type "bits" .......................175
10.6.1. bit-is-set() .....................................175
11. Updating a Module ............................................176
12. Coexistence with YANG Version 1 ..............................179
13. YIN ..........................................................179
13.1. Formal YIN Definition ...................................180
13.1.1. Usage Example ....................................182
14. YANG ABNF Grammar ............................................184
15. NETCONF Error Responses for YANG-Related Errors ..............211
15.1. Error Message for Data That Violates a "unique"
Statement ...............................................211
15.2. Error Message for Data That Violates a
"max-elements" Statement ................................211
15.3. Error Message for Data That Violates a
"min-elements" Statement ................................211
15.4. Error Message for Data That Violates a "must"
Statement ...............................................212
15.5. Error Message for Data That Violates a
"require-instance" Statement ............................212
Bjorklund Standards Track [Page 8]
RFC 7950 YANG 1.1 August 2016
15.6. Error Message for Data That Violates a Mandatory
"choice" Statement ......................................212
15.7. Error Message for the "insert" Operation ................212
16. IANA Considerations ..........................................213
17. Security Considerations ......................................213
18. References ...................................................214
18.1. Normative References ....................................214
18.2. Informative References ..................................215
Acknowledgements .................................................217
Contributors .....................................................217
Author's Address .................................................217
1.はじめに............................................... ..... 9
1.1. RFC 6020からの変更の概要.......................... 10
2.キーワード.............................................................. ........ 12
3.用語......................................................... ..... 12
3.1.例に関する注記.................................................. 16
4. YANGの概要........................................................ .... 16
4.1.機能概要................................................. 16
4.2.言語の概要................................................... 18
4.2.1.モジュールとサブモジュール............................. 18
4.2.2.データモデリングの基礎............................... 19
4.2.3.構成および状態データ................................. 23
4.2.4.組み込み型..................................... 24
4.2.5.派生型（typedef）............................ 25
4.2.6.再利用可能なノードグループ（グループ化）.................... 25
4.2.7.選択肢............................................ 27
4.2.8.データモデルの拡張（拡張）.................... 28
4.2.9.操作の定義.............................. 29
4.2.10.通知の定義.................................... 31
5.言語の概念.............................................................. 32
5.1.モジュールとサブモジュール.................................... 32
5.1.1.リビジョンごとのインポートとインクルード..................... 33
5.1.2.モジュール階層................................. 34
5.2.ファイルレイアウト................................................................... 36
5.3. XML名前空間............................................ 36
5.3.1. YANG XML名前空間................................. 36
5.4.グループ化、タイプ、およびID名の解決.............. 37
5.5.ネストされたTypedefとグループ............................. 37
5.6.適合性............................................................ 38
5.6.1.基本的な動作................................................. 38
5.6.2.オプション機能................................................. 38
5.6.3.偏差......................................... 39
5.6.4. NETCONFでの適合性情報の発表...... 40
5.6.5.モジュールの実装.............................. 40
5.7.データストアの変更................................................ 44
6. YANG構文.............................................. ...... 44
6.1.字句トークン化................................................ 45
6.1.1.コメント.................................................................... 45
6.1.2.トークン............................................. 45
6.1.3.引用............................................ 45
6.2.識別子............................................... 47
6.2.1.識別子とその名前空間................... 47
6.3.ステートメント................................................ 48
6.3.1.言語拡張機能................................ 48
6.4. XPath評価................................................... 49
6.4.1. XPathコンテキスト................................................ 50
6.5.スキーマノード識別子................................................. 54
7. YANGステートメント........................................................ ..55
7.1. 「モジュール」ステートメント................................................... 55
7.1.1.モジュールのサブステートメント......................... 56
7.1.2. 「陽バージョン」ステートメント....................... 57
7.1.3. 「名前空間」ステートメント.......................... 57
7.1.4. 「プレフィックス」ステートメント............................. 57
7.1.5. 「インポート」ステートメント............................. 58
7.1.6. 「include」ステートメント............................ 59
7.1.7. 「組織」声明................................. 60
7.1.8. 「連絡先」ステートメント............................ 60
7.1.9. 「改訂」声明........................... 60
7.1.10.使用例................................................................ 61
7.2. 「サブモジュール」ステートメント................................. 62
7.2.1.サブモジュールのサブステートメント...................... 63
7.2.2. 「所属」ステートメント......................... 63
7.2.3.使用例................................................ 64
7.3. 「typedef」ステートメント................................... 65
7.3.1. typedefのサブステートメント........................ 65
7.3.2. typedefの「type」ステートメント..................... 65
7.3.3. 「ユニット」ステートメント.............................. 65
7.3.4. typedefの「デフォルト」ステートメント.................................. 66
7.3.5.使用例................................................ 66
7.4. 「タイプ」ステートメント................................................ 66
7.4.1.タイプのサブステートメント........................... 67
7.5. 「コンテナ」ステートメント................................................ 67
7.5.1.存在感のあるコンテナ........................... 67
7.5.2.コンテナのサブステートメント............ 68
7.5.3. 「必須」の声明............................... 69
7.5.4.マストのサブステートメント........................... 70
7.5.5. 「プレゼンス」ステートメント........................... 71
7.5.6.コンテナの子ノードステートメント.............. 71
7.5.7. XMLエンコーディングルール................................. 71
7.5.8. NETCONF <edit-config>操作................... 72
7.5.9.使用例................................................ 72
7.6 「リーフ」ステートメント................................................ 73
7.6.1.リーフのデフォルト値........................... 74
7.6.2.リーフのサブステートメント........................... 75
7.6.3.リーフの「タイプ」ステートメント........................ 75
7.6.4.リーフの「デフォルト」ステートメント..................... 75
7.6.5.リーフの「必須」ステートメント................... 76
7.6.6. XMLエンコーディングルール................................. 76
7.6.7. NETCONF <edit-config>操作................... 76
7.6.8.使用例................................................ 77
7.7. 「リーフリスト」ステートメント................................. 77
7.7.1.注文.................................................................... 78
7.7.2.リーフリストのデフォルト値..................... 79
7.7.3.リーフリストのサブステートメント...................... 80
7.7.4.リーフリストの「デフォルト」ステートメント................ 80
7.7.5. 「min-elements」ステートメント....................... 80
7.7.6. 「max-elements」ステートメント....................... 81
7.7.7. 「ordered-by」ステートメント......................... 81
7.7.8. XMLエンコーディングルール................................. 82
7.7.9. NETCONF <edit-config>操作................... 82
7.7.10.使用例................................................... 83
7.8. 「リスト」ステートメント................................................ 84
7.8.1.リストのサブステートメント........................... 85
7.8.2.リストの「キー」ステートメント......................... 85
7.8.3.リストの「独自の」声明................................ 86
7.8.4.リストの子ノードステートメント................... 87
7.8.5. XMLエンコーディングルール................................. 88
7.8.6. NETCONF <edit-config>操作................... 88
7.8.7.使用例................................................ 90
7.9. 「選択」ステートメント.................................... 93
7.9.1.選択のサブステートメント......................... 94
7.9.2.選択の「ケース」ステートメント...................... 94
7.9.3.選択の「デフォルト」ステートメント................... 96
7.9.4.選択の「必須」ステートメント................. 98
7.9.5. XMLエンコーディングルール................................. 98
7.9.6.使用例................................................ 99
7.10. 「anydata」ステートメント................................. 100
7.10.1. anydataのサブステートメント...................... 100
7.10.2. XMLエンコーディングルール............................... 101
7.10.3. NETCONF <edit-config>操作................. 101
7.10.4.使用例................................................... 101
7.11. 「anyxml」ステートメント................................................. 102
7.11.1. anyxmlのサブステートメント....................... 103
7.11.2. XMLエンコーディングルール............................... 103
7.11.3. NETCONF <edit-config>操作................. 103
7.11.4.使用例................................................... 104
7.12. 「グループ化」ステートメント................................ 104
7.12.1.グループのサブステートメント..................... 105
7.12.2.使用例................................................... 105
7.13. 「使用」ステートメント.................................... 106
7.13.1.使用のサブステートメント......................... 106
7.13.2. 「リファイン」ステートメント........................... 106
7.13.3. XMLエンコーディングルール............................... 107
7.13.4.使用例................................................... 107
7.14. 「rpc」ステートメント..................................... 108
7.14.1. RPCのサブステートメント.......................... 109
7.14.2. 「入力」ステートメント............................ 109
7.14.3. 「出力」ステートメント........................... 110
7.14.4. NETCONF XMLエンコーディングルール....................... 111
7.14.5.使用例................................................... 112
7.15. 「アクション」ステートメント.................................. 113
7.15.1.アクションのサブステートメント....................... 114
7.15.2. NETCONF XMLエンコーディングルール....................... 114
7.15.3.使用例................................................... 115
7.16. 「通知」ステートメント............................ 116
7.16.1.通知のサブステートメント................. 117
7.16.2. NETCONF XMLエンコーディングルール....................... 117
7.16.3.使用例................................................... 118
7.17. 「拡張」ステートメント................................. 119
7.17.1.拡張のサブステートメント...................... 121
7.17.2. XMLエンコーディングルール............................... 121
7.17.3.使用例................................................... 122
7.18. 「アイデンティティ」ステートメント................................ 124
7.18.1.アイデンティティのサブステートメント..................... 124
7.18.2. 「ベース」ステートメント............................. 124
7.18.3.使用例................................................... 125
7.19. 「拡張」ステートメント............................... 126
7.19.1.拡張機能のサブステートメント.................... 126
7.19.2. 「引数」ステートメント......................... 127
7.19.3.使用例................................................... 127
7.20.適合性に関する声明.......................... 128
7.20.1. 「機能」ステートメント.......................... 128
7.20.2. 「if-feature」ステートメント....................... 130
7.20.3. 「偏差」ステートメント........................ 131
7.21.共通の声明................................................. 134
7.21.1. 「config」ステートメント........................... 134
7.21.2. 「ステータス」ステートメント........................... 135
7.21.3. 「説明」ステートメント............ 136
7.21.4. 「参照」ステートメント........................ 136
7.21.5. 「いつ」ステートメント....................................... 136
8.制約............................................... .... 138
8.1.データの制約................................................ 138
8.2.設定データの変更......................... 139
8.3. NETCONF制約適用モデル..................... 139
8.3.1.ペイロード解析................................... 139
8.3.2. NETCONF <edit-config>処理.................. 140
8.3.3.検証............................................................ 141
9.組み込み型...................................................... .... 141
9.1.正規表現................................................. 141
9.2.整数組み込み型............................... 142
9.2.1.字句表現............................ 142
9.2.2.正規形................................................. 143
9.2.3.制限事項................................................ 143
9.2.4. 「範囲」ステートメント............................. 143
9.2.5.使用例................................................................ 144
9.3. decimal64組み込みタイプ.............................. 144
9.3.1.字句表現............................ 145
9.3.2.正規形................................................. 145
9.3.3.制限事項................................................ 145
9.3.4. 「端数桁」ステートメント................... 145
9.3.5.使用例................................................................ 146
9.4.文字列の組み込みタイプ................................. 146
9.4.1.字句表現............................ 146
9.4.2.正規形................................................. 147
9.4.3.制限事項................................................ 147
9.4.4. 「長さ」ステートメント............................ 147
9.4.5. 「パターン」ステートメント........................... 148
9.4.6. 「修飾子」ステートメント.......................... 148
9.4.7.使用例................................................................ 149
9.5.ブール組み込みタイプ................................ 150
9.5.1.字句表現............................ 150
9.5.2.正規形................................................. 150
9.5.3.制限事項................................................ 150
9.6.列挙型組み込みタイプ............................ 150
9.6.1.字句表現............................ 150
9.6.2.正規形................................................. 151
9.6.3.制限事項................................................ 151
9.6.4. 「列挙型」ステートメント.............................. 151
9.6.5.使用例................................................... 152
9.7.ビット内蔵タイプ................................................. 154
9.7.1.制限事項................................................ 154
9.7.2.字句表現............................ 154
9.7.3.正規形................................................. 154
9.7.4. 「ビット」ステートメント............................... 155
9.7.5.使用例................................................................ 156
9.8.バイナリ組み込みタイプ................................. 157
9.8.1.制限事項................................................ 157
9.8.2.字句表現............................ 157
9.8.3.正規形................................................. 157
9.9. leafref組み込みタイプ................................ 157
9.9.1.制限事項................................................ 158
9.9.2. 「パス」ステートメント........................................ 158
9.9.3. 「インスタンスの要求」ステートメント.................. 159
9.9.4.字句表現............................ 159
9.9.5.正規形.................................... 159
9.9.6.使用例................................................... 159
9.10. identityref組み込みタイプ........................... 163
9.10.1.制限事項................................................................ 163
9.10.2. identityrefの「ベース」ステートメント............... 163
9.10.3.字句表現........................... 163
9.10.4.正規形................................... 164
9.10.5.使用例................................................... 164
9.11.空の組み込みタイプ................................. 165
9.11.1.制限事項................................................................ 165
9.11.2.字句表現........................... 165
9.11.3.正規形................................... 165
9.11.4.使用例................................................... 166
9.12.ユニオン組み込み型................................................ 166
9.12.1.制限事項................................................................ 166
9.12.2.字句表現........................... 166
9.12.3.正規形................................... 167
9.12.4.使用例................................................... 167
9.13.インスタンス識別子の組み込みタイプ................... 168
9.13.1.制限事項................................................................ 168
9.13.2.字句表現........................... 169
9.13.3.正規形................................... 169
9.13.4.使用例................................................... 169
10. XPath関数........................................................................ 170
10.1ノードセットの機能.................................. 170
10.1.1. current（）........................................ 170
10.2文字列用の関数................................................. 170
10.2.1. re-match（）................................................. 170
10.3. YANGタイプ「leafref」および
「インスタンス識別子」................................... 171
10.3.1. deref（）.......................................... 171
10.4. YANGタイプ「identityref」の関数............... 172
10.4.1.派生元（）................................... 172
10.4.2.派生元または自己（）........................... 174
10.5. YANGタイプ「列挙型」の関数................ 174
10.5.1. enum-value（）..................................... 174
10.6. YANGタイプ「ビット」の機能....................... 175
10.6.1. bit-is-set（）..................................... 175
11.モジュールの更新............................................ 176
12. YANGバージョン1との共存.............................. 179
13. YIN ............................................... ........... 179
13.1.正式なYINの定義................................... 180
13.1.1.使用例................................................... 182
14.ヤンABNF文法............................................ 184
15. YANG関連のエラーに対するNETCONFエラー応答.............. 211
15.1. 「一意」に違反するデータのエラーメッセージ
ステートメント............................................... 211
15.2.に違反するデータのエラーメッセージ
「max-elements」ステートメント................................ 211
15.3.に違反するデータのエラーメッセージ
「min-elements」ステートメント................................ 211
15.4. 「必須」に違反するデータのエラーメッセージ
ステートメント............................................... 212
15.5.に違反するデータのエラーメッセージ
「インスタンスを要求」ステートメント............................ 212
15.6 必須に違反するデータのエラーメッセージ
「選択」ステートメント................................................ 212
15.7. 「挿入」操作のエラーメッセージ................ 212
16. IANAの考慮事項.......................................... 213
17.セキュリティに関する考慮事項................................................ 213
18.参考資料......................................................... .... 214
18.1. 規範的な参照................................................. 214
18.2. 参考資料................................................. 215
謝辞................................................................ 217
貢献者................................................................. .... 217
著者のアドレス................................................................ .217
1. Introduction
1.はじめに
YANG is a data modeling language originally designed to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF Remote Procedure Calls, and NETCONF notifications [RFC6241]. Since the publication of YANG version 1 [RFC6020], YANG has been used or proposed to be used for other protocols (e.g., RESTCONF [RESTCONF] and the Constrained Application Protocol (CoAP) Management Interface (CoMI) [CoMI]). Further, encodings other than XML have been proposed (e.g., JSON [RFC7951]).
YANGは、もともとネットワーク構成プロトコル（NETCONF）、NETCONFリモートプロシージャコール、およびNETCONF通知[RFC6241]によって操作される構成および状態データをモデル化するために設計されたデータモデリング言語です。 YANGバージョン1 [RFC6020]の公開以来、YANGは他のプロトコル（RESTCONF [RESTCONF]やConstrained Application Protocol（CoAP）Management Interface（CoMI）[CoMI]など）で使用または使用が提案されています。 さらに、XML以外のエンコーディングも提案されています（JSON [RFC7951]など）。
This document describes the syntax and semantics of version 1.1 of the YANG language. It also describes how a data model defined in a YANG module is encoded in the Extensible Markup Language (XML) [XML] and how NETCONF operations are used to manipulate the data. Other protocols and encodings are possible but are out of scope for this specification.
このドキュメントでは、YANG言語のバージョン1.1の構文とセマンティクスについて説明します。 また、YANGモジュールで定義されたデータモデルがExtensible Markup Language（XML）[XML]でエンコードされる方法、およびNETCONF操作を使用してデータを操作する方法についても説明します。 他のプロトコルとエンコーディングも可能ですが、この仕様の範囲外です。
In terms of developing YANG data models, [YANG-Guidelines] provides some guidelines and recommendations.
YANGデータモデルの開発に関して、[YANG-Guidelines]はいくつかのガイドラインと推奨事項を提供します。
Note that this document does not obsolete RFC 6020 [RFC6020].
このドキュメントはRFC 6020 [RFC6020]を廃止するものではないことに注意してください。
Bjorklund Standards Track [Page 9] RFC 7950 YANG 1.1 August 2016 1.1. Summary of Changes from RFC 6020
1.1。 RFC 6020からの変更の概要
This document defines version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification [RFC6020].
このドキュメントは、YANG言語のバージョン1.1を定義しています。 YANGバージョン1.1は、YANG言語のメンテナンスリリースであり、元の仕様[RFC6020]のあいまいさと欠陥に対処しています。
The following changes are not backward compatible with YANG version 1:
次の変更は、YANGバージョン1との下位互換性がありません。
o Changed the rules for the interpretation of escaped characters in
double-quoted strings. This is a backward-incompatible change
from YANG version 1. When updating a YANG version 1 module to 1.1
and the module uses a character sequence that is now illegal, the
string must be changed to match the new rules. See Section 6.1.3
for details.
二重引用符で囲まれた文字列のエスケープ文字の解釈に関するルールを変更しました。 これは、YANGバージョン1からの下位互換性のない変更です。 YANGバージョン1モジュールを1.1に更新し、モジュールが不正になった文字シーケンスを使用する場合、新しいルールに一致するように文字列を変更する必要があります。 詳細については、セクション6.1.3を参照してください。
o An unquoted string cannot contain any single or double quote
characters. This is a backward-incompatible change from YANG
version 1. When updating a YANG version 1 module to 1.1 and the
module uses such quote characters, the string must be changed to
match the new rules. See Section 6.1.3 for details.
引用符で囲まれていない文字列には、単一引用符または二重引用符を含めることはできません。 これは、YANGバージョン1からの下位互換性のない変更です。 YANGバージョン1モジュールを1.1に更新し、モジュールがそのような引用文字を使用している場合、新しいルールに一致するように文字列を変更する必要があります。 詳細については、セクション6.1.3を参照してください。
o Made "when" and "if-feature" illegal on list keys. This is a
backward-incompatible change from YANG version 1. When updating a
YANG version 1 module to 1.1 and the module uses these constructs,
they must be removed to match the new rules.
「いつ」と「if-feature」がリストキーで違法になりました。 これは、YANGバージョン1からの下位互換性のない変更です。 YANGバージョン1モジュールを1.1に更新し、モジュールがこれらの構成を使用する場合、新しい規則に一致させるためにそれらを削除する必要があります。
o Defined the legal characters in YANG modules. When updating a
YANG version 1 module to 1.1, any characters that are now illegal
must be removed. See Section 6 for details.
YANGモジュールで有効な文字を定義しました。 YANGバージョン1モジュールを1.1に更新する場合、現在は不正な文字を削除する必要があります。 詳細については、セクション6を参照してください。
o Made noncharacters illegal in the built-in type "string". This
change affects the runtime behavior of YANG-based protocols.
組み込み型「文字列」で文字以外を無効にしました。 この変更は、YANGベースのプロトコルの実行時の動作に影響します。
The following additional changes have been done to YANG:
YANGには、以下の追加の変更が加えられています。
o Changed the YANG version from "1" to "1.1".
YANGのバージョンを「1」から「1.1」に変更しました。
o Made the "yang-version" statement mandatory in YANG version "1.1".
YANGバージョン "1.1"で "yang-version"ステートメントを必須にしました。
o Extended the "if-feature" syntax to be a boolean expression over
feature names.
「if-feature」構文を機能名に対するブール式に拡張しました。
o Allow "if-feature" in "bit", "enum", and "identity".
「bit」、「enum」、「identity」で「if-feature」を許可します。
o Allow "if-feature" in "refine".
「refine」で「if-feature」を許可します。
Bjorklund Standards Track [Page 10]
RFC 7950 YANG 1.1 August 2016
o Allow "choice" as a shorthand "case" statement (see
Section 7.9.2).
「選択」を省略形の「ケース」ステートメントとして許可します（7.9.2項を参照）。
o Added a new substatement "modifier" to the "pattern" statement
(see Section 9.4.6).
「パターン」ステートメントに新しいサブステートメント「修飾子」を追加しました（セクション9.4.6を参照）。
o Allow "must" in "input", "output", and "notification".
「入力」、「出力」、「通知」で「必須」を許可します。
o Allow "require-instance" in leafref.
leafrefで「require-instance」を許可します。
o Allow "description" and "reference" in "import" and "include".
「インポート」と「インクルード」で「説明」と「参照」を許可します。
o Allow imports of multiple revisions of a module.
モジュールの複数のリビジョンのインポートを許可します。
o Allow "augment" to add conditionally mandatory nodes (see
Section 7.17).
「augment」で条件付き必須ノードを追加できるようにします（7.17節を参照）。
o Added a set of new XML Path Language (XPath) functions in
Section 10.
セクション10に一連の新しいXMLパス言語（XPath）関数を追加しました。
o Clarified the XPath context's tree in Section 6.4.1.
セクション6.4.1でXPathコンテキストのツリーを明確にしました。
o Defined the string value of an identityref in XPath expressions
(see Section 9.10).
XPath式でidentityrefの文字列値を定義しました（セクション9.10を参照）。
o Clarified what unprefixed names mean in leafrefs in typedefs (see
Sections 6.4.1 and 9.9.2).
typedefのリーフ参照で接頭辞のない名前が何を意味するかを明確にしました（セクション6.4.1および9.9.2を参照）。
o Allow identities to be derived from multiple base identities (see
Sections 7.18 and 9.10).
IDが複数の基本IDから派生できるようにします（セクション7.18および9.10を参照）。
o Allow enumerations and bits to be subtyped (see Sections 9.6
and 9.7).
列挙型とビットをサブタイプ化できるようにします（セクション9.6および9.7を参照）。
o Allow leaf-lists to have default values (see Section 7.7.2).
リーフリストにデフォルト値を持たせる（セクション7.7.2を参照）。
o Allow non-unique values in non-configuration leaf-lists (see
Section 7.7).
非構成リーフリストで非一意の値を許可します（セクション7.7を参照）。
o Use syntax for case-sensitive strings (as per [RFC7405]) in the
grammar.
文法では、[RFC7405]のように、大文字と小文字を区別する文字列の構文を使用します。
o Changed the module advertisement mechanism (see Section 5.6.4).
モジュール通知メカニズムを変更しました（5.6.4項を参照）。
o Changed the scoping rules for definitions in submodules. A
submodule can now reference all definitions in all submodules that
belong to the same module, without using the "include" statement.
サブモジュールの定義のスコープ規則を変更しました。 サブモジュールは、「include」ステートメントを使用せずに、同じモジュールに属するすべてのサブモジュールのすべての定義を参照できるようになりました。
Bjorklund Standards Track [Page 11]
RFC 7950 YANG 1.1 August 2016
o Added a new statement "action", which is used to define operations
tied to data nodes.
データノードに関連付けられた操作を定義するために使用される新しいステートメント「アクション」を追加しました。
o Allow notifications to be tied to data nodes.
通知をデータノードに関連付けることができます。
o Added a new data definition statement "anydata" (see
Section 7.10), which is RECOMMENDED to be used instead of "anyxml"
when the data can be modeled in YANG.
新しいデータ定義ステートメント「anydata」を追加しました（セクション7.10を参照）。これは、データをYANGでモデル化できる場合に「anyxml」の代わりに使用することをお勧めします。
o Allow types "empty" and "leafref" in unions.
共用体で「空」および「リーフ参照」タイプを許可します。
o Allow type "empty" in a key.
キーに「空」のタイプを許可します。
o Removed the restriction that identifiers could not start with the
characters "xml".
識別子が文字「xml」で開始できないという制限を削除しました。
The following changes have been done to the NETCONF mapping:
NETCONFマッピングに次の変更が加えられました。
o A server advertises support for YANG 1.1 modules by using
ietf-yang-library [RFC7895] instead of listing them as
capabilities in the <hello> message.
サーバーは、<hello>メッセージに機能としてリストする代わりに、ietf-yang-library [RFC7895]を使用して、YANG 1.1モジュールのサポートをアドバタイズします。
2. Key Words
2.キーワード
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL このドキュメントの "は、BCP 14 [RFC2119]で説明されているように解釈されます。
3. Terminology
3.用語
The following terms are used within this document:
このドキュメントでは、次の用語が使用されています。
o action: An operation defined for a node in the data tree.
アクション：データツリーのノードに対して定義された操作。
o anydata: A data node that can contain an unknown set of nodes that
can be modeled by YANG, except anyxml.
anydata：anyxmlを除き、YANGでモデル化できる不明なノードのセットを含むことができるデータノード。
o anyxml: A data node that can contain an unknown chunk of XML data.
anyxml：不明なXMLデータのチャンクを含むことができるデータノード。
o augment: Adds new schema nodes to a previously defined schema
node.
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 built-in type: A YANG data type defined in the YANG language, such
as uint32 or string.
組み込み型：uint32やstringなど、YANG言語で定義されたYANGデータ型。
Bjorklund Standards Track [Page 12]
RFC 7950 YANG 1.1 August 2016
o choice: A schema node where only one of a number of identified
alternatives is valid.
選択：識別された多数の選択肢のうち1つだけが有効なスキーマノード。
o client: An entity that can access YANG-defined data on a server,
over some network management protocol.
クライアント：ネットワーク管理プロトコルを介して、サーバー上のYANG定義データにアクセスできるエンティティ。
o conformance: A measure of how accurately a server follows a data
model.
適合性：サーバーがデータモデルにどれだけ正確に従うかを示す尺度。
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.
コンテナー：データツリーの最大1つのインスタンスに存在する内部データノード。 コンテナには値はありませんが、子ノードのセットがあります。
o data definition statement: A statement that defines new data
nodes. One of "container", "leaf", "leaf-list", "list", "choice",
"case", "augment", "uses", "anydata", and "anyxml".
データ定義ステートメント：新しいデータノードを定義するステートメント。 「container」、「leaf」、「leaf-list」、「list」、「choice」、「case」、「augment」、「uses」、「anydata」、「anyxml」のいずれか。
o data model: A data model describes how data is represented and
accessed.
データモデル：データモデルは、データの表現方法とアクセス方法を記述します。
o data node: A node in the schema tree that can be instantiated in a
data tree. One of container, leaf, leaf-list, list, anydata, and
anyxml.
データノード：データツリーでインスタンス化できるスキーマツリーのノード。 コンテナ、リーフ、リーフリスト、リスト、anydata、anyxmlのいずれか。
o data tree: An instantiated tree of any data modeled with YANG,
e.g., configuration data, state data, combined configuration and
state data, RPC or action input, RPC or action output, or
notification.
データツリー：YANGでモデル化された任意のデータのインスタンス化されたツリー。
o derived type: A type that is derived from a built-in type (such as
uint32) or another derived type.
派生型：組み込み型（uint32など）または別の派生型から派生した型。
o extension: An extension attaches non-YANG semantics to statements.
The "extension" statement defines new statements to express these
semantics.
拡張機能：拡張機能は、YANG以外のセマンティクスをステートメントに付加します。 「拡張」ステートメントは、これらのセマンティクスを表現するための新しいステートメントを定義します。
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 servers that support that feature.
機能：モデルの一部をオプションとしてマークするためのメカニズム。 定義には機能名のタグを付けることができ、その機能をサポートするサーバーでのみ有効です。
o grouping: A reusable set of schema nodes, which may be used
locally in the module 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 identifier: A string used to identify different kinds of YANG
items by name.
identifier：さまざまな種類のYANGアイテムを名前で識別するために使用される文字列。
Bjorklund Standards Track [Page 13] RFC 7950 YANG 1.1 August 2016 o identity: A globally unique, abstract, and untyped name.
identity：グローバルに一意で、抽象的で型付けされていない名前。
o instance identifier: A mechanism for identifying a particular node
in a data tree.
インスタンス識別子：データツリー内の特定のノードを識別するメカニズム。
o interior node: Nodes within a hierarchy that are not leaf nodes.
内部ノード：葉ノードではない階層内のノード。
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.
リーフ：データツリー内の多くても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 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 mandatory node: A mandatory node is one of:
必須ノード：必須ノードは次のいずれかです。
* A leaf, choice, anydata, or anyxml node with a "mandatory"
statement with the value "true".
「必須」ステートメントの値が「true」のリーフ、選択、anydata、またはanyxmlノード。
* A list or leaf-list node with a "min-elements" statement with a
value greater than zero.
ゼロより大きい値を持つ「min-elements」ステートメントを持つリストまたはリーフリストノード。
* A container node without a "presence" statement and that has at
least one mandatory node as a child.
「プレゼンス」ステートメントがなく、子として少なくとも1つの必須ノードがあるコンテナノード。
o module: A YANG module defines hierarchies of schema nodes. With
its definitions and the definitions it imports or includes from
elsewhere, a module is self-contained and "compilable".
module：YANGモジュールは、スキーマノードの階層を定義します。 モジュールの定義とそれがインポートまたは他の場所からインクルードする定義により、モジュールは自己完結型で「コンパイル可能」です。
o non-presence container: A container that has no meaning of its
own, existing only to contain child nodes.
非存在コンテナ：独自の意味を持たないコンテナで、子ノードを含むためにのみ存在します。
o presence container: A container where the presence of the
container itself carries some meaning.
プレゼンスコンテナ：コンテナ自体のプレゼンスが何らかの意味を持つコンテナ。
o RPC: A Remote Procedure Call.
RPC：リモートプロシージャコール。
o RPC operation: A specific Remote Procedure Call.
RPC操作：特定のリモートプロシージャコール。
o schema node: A node in the schema tree. One of action, container,
leaf, leaf-list, list, choice, case, rpc, input, output,
notification, anydata, and anyxml.
スキーマノード：スキーマツリーのノード。 action、container、leaf、leaf-list、list、choice、case、rpc、input、output、notification、anydata、anyxmlのいずれか。
Bjorklund Standards Track [Page 14]
RFC 7950 YANG 1.1 August 2016
o schema node identifier: A mechanism for identifying a particular
node in the schema tree.
スキーマノード識別子：スキーマツリー内の特定のノードを識別するためのメカニズム。
o schema tree: The definition hierarchy specified within a module.
スキーマツリー：モジュール内で指定された定義階層。
o server: An entity that provides access to YANG-defined data to a
client, over some network management protocol.
サーバー：一部のネットワーク管理プロトコルを介して、クライアントにYANG定義のデータへのアクセスを提供するエンティティ。
o server deviation: A failure of the server to implement a module
faithfully.
サーバーの逸脱：サーバーがモジュールを忠実に実装できないこと。
o submodule: A partial module definition that contributes derived
types, groupings, data nodes, RPCs, actions, and notifications to
a module. A YANG module can be constructed from a number of
submodules.
サブモジュール：派生型、グループ、データノード、RPC、アクション、および通知をモジュールに提供する部分的なモジュール定義。 YANGモジュールは、いくつかのサブモジュールから構成できます。
o top-level data node: A data node where there is no other data node
between it and a "module" or "submodule" statement.
トップレベルのデータノード：「モジュール」または「サブモジュール」ステートメントとの間に他のデータノードがないデータノード。
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.
用途：「uses」ステートメントは、「grouping」ステートメントで定義されたスキーマノードのセットをインスタンス化するために使用されます。 インスタンス化されたノードは、特定のニーズに合わせて調整および拡張することができます。
o value space: For a data type; the set of values permitted by the
data type. For a leaf or leaf-list instance; the value space of
its data type.
値スペース：データ型の場合。 データ型で許可されている値のセット。 リーフまたはリーフリストのインスタンスの場合。 そのデータ型の値空間。
The following terms are defined in [RFC6241]:
以下の用語は[RFC6241]で定義されています：
o configuration data
設定データ
o configuration datastore
構成データストア
o datastore
データストア
o state data
状態データ
When modeled with YANG, a datastore is realized as an instantiated data tree.
YANGでモデル化すると、データストアはインスタンス化されたデータツリーとして実現されます。
When modeled with YANG, a configuration datastore is realized as an instantiated data tree with configuration data.
YANGでモデル化すると、構成データストアは、構成データを含むインスタンス化されたデータツリーとして実現されます。
Bjorklund Standards Track [Page 15] RFC 7950 YANG 1.1 August 2016 3.1. A Note on Examples
3.1。 例に関する注記
Throughout this document, there are many examples of YANG statements. These examples are supposed to illustrate certain features and are not supposed to be complete, valid YANG modules.
このドキュメント全体を通して、YANGステートメントの多くの例があります。 これらの例は特定の機能を説明するためのものであり、完全で有効なYANGモジュールではありません。
4. YANG Overview
4. YANGの概要
This non-normative section is intended to give a high-level overview of YANG to first-time readers.
この非規範的なセクションは、初めての読者にYANGの概要を説明することを目的としています。
4.1. Functional Overview
4.1。 機能の概要
YANG is a language originally designed to model data for the NETCONF protocol. A YANG module defines hierarchies of data that can be used for NETCONF-based operations, including configuration, state data, RPCs, and notifications. This allows a complete description of all data sent between a NETCONF client and server. Although out of scope for this specification, YANG can also be used with protocols other than NETCONF.
YANGは、もともとNETCONFプロトコルのデータをモデル化するために設計された言語です。 YANGモジュールは、構成、状態データ、RPC、通知など、NETCONFベースの操作に使用できるデータの階層を定義します。 これにより、NETCONFクライアントとサーバーの間で送信されるすべてのデータの完全な説明が可能になります。 この仕様の範囲外ですが、YANGは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 definitions from other external modules and can include definitions 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は、データモデルをモジュールとサブモジュールに構造化します。 モジュールは他の外部モジュールから定義をインポートでき、サブモジュールからの定義を含めることができます。 階層を拡張して、あるモジュールが別のモジュールで定義された階層にデータノードを追加できるようにすることができます。 この拡張は条件付きにすることができ、特定の条件が満たされた場合にのみ新しいノードが表示されます。
YANG data models can describe constraints to be enforced on the data, restricting the presence 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.
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 hostname.
YANGは組み込み型のセットを定義し、追加の型を定義できる型メカニズムを備えています。 派生型は、クライアントやサーバーによって強制できる範囲やパターンの制限などのメカニズムを使用して、基本型の有効な値のセットを制限できます。 また、ホスト名を含む文字列ベースの型など、派生型を使用するための使用規則を定義することもできます。
Bjorklund Standards Track [Page 16] RFC 7950 YANG 1.1 August 2016 YANG permits the definition of reusable groupings of nodes. The usage 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 and used in either the same module or another module that imports 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データ階層構造には、リストエントリが互いに区別するキーによって識別されるリストの定義が含まれます。 そのようなリストは、ユーザーによってソートされるか、システムによって自動的にソートされるかのいずれかとして定義されます。 ユーザーがソートしたリストの場合、操作はリストエントリの順序を操作するために定義されます。
YANG modules can be translated into an equivalent XML syntax called YANG Independent Notation (YIN) (Section 13), allowing applications using XML parsers and Extensible Stylesheet Language Transformations (XSLT) scripts to operate on the models. The conversion from YANG to YIN is semantically lossless, so content in YIN can be round-tripped back into YANG.
YANGモジュールは、YANG Independent Notation（YIN）（セクション13）と呼ばれる同等のXML構文に変換できるため、XMLパーサーとExtensible Stylesheet Language Transformations（XSLT）スクリプトを使用するアプリケーションでモデルを操作できます。 YANGからYINへの変換はセマンティックスロスレスであるため、YINのコンテンツをYANGに戻すことができます。
YANG is an extensible language, allowing extensions 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ステートメントと自然に共存できますが、YANGモジュールの拡張機能は、読者がそれらに気付くのに十分なほど目立ちます。
YANG resists the tendency to solve all possible problems, limiting the problem space to allow expression of data models for network management protocols such as NETCONF, not arbitrary XML documents or arbitrary data models.
YANGはすべての起こり得る問題を解決する傾向に抵抗し、問題のスペースを制限して、任意のXMLドキュメントや任意のデータモデルではなく、NETCONFなどのネットワーク管理プロトコルのデータモデルを表現できるようにします。
To the extent possible, YANG maintains compatibility with the 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 [RFC6643]. However, YANG is not concerned with reverse translation from YANG to SMIv2.
YANGは、可能な限り、Simple Network Management Protocol（SNMP）のSMIv2（Structure of Management Information version 2 [RFC2578] [RFC2579]）との互換性を維持しています。 SMIv2ベースのMIBモジュールは、読み取り専用アクセスのために自動的にYANGモジュールに変換できます[RFC6643]。 ただし、YANGは、YANGからSMIv2への逆変換とは関係ありません。
Bjorklund Standards Track [Page 17] RFC 7950 YANG 1.1 August 2016 4.2. Language Overview
4.2。 言語の概要
This section introduces some important constructs used in YANG that will aid in the understanding of the language specifics in later sections.
このセクションでは、後のセクションで言語の詳細を理解するのに役立つYANGで使用されるいくつかの重要な構成要素を紹介します。
4.2.1. Modules and Submodules
4.2.1。 モジュールとサブモジュール
YANG data models are defined in modules. A module contains a collection of related definitions.
YANGデータモデルはモジュールで定義されます。 モジュールには、関連する定義のコレクションが含まれています。
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 server may implement a number of modules, allowing multiple views of the same data or multiple views of disjoint subsections of the server's data. Alternatively, the server may implement only one module that defines all available data.
サーバーは複数のモジュールを実装して、同じデータの複数のビュー、またはサーバーのデータの互いに素なサブセクションの複数のビューを許可できます。 または、サーバーは、使用可能なすべてのデータを定義するモジュールを1つだけ実装することもできます。
A module may have portions of its definitions separated into submodules, based on the needs of the module designer. The external view remains that of a single module, regardless of the presence or size of its submodules.
モジュールは、モジュール設計者のニーズに基づいて、その定義の一部をサブモジュールに分割することができます。 サブモジュールの存在やサイズに関係なく、外観は単一のモジュールの外観のままです。
The "import" statement allows a module or submodule to reference definitions defined in other modules.
「インポート」ステートメントにより、モジュールまたはサブモジュールは、他のモジュールで定義された定義を参照できます。
The "include" statement is used in a module to identify each submodule that belongs to it.
「include」ステートメントは、モジュールに使用され、それに属する各サブモジュールを識別します。
Bjorklund Standards Track [Page 18] RFC 7950 YANG 1.1 August 2016 4.2.2. Data Modeling Basics
4.2.2。 データモデリングの基本
YANG defines four main types of data nodes for data modeling. In each of the following subsections, the examples show the YANG syntax as well as a corresponding XML encoding. The syntax of YANG statements is defined in Section 6.3.
YANGは、データモデリング用に4つの主要なタイプのデータノードを定義しています。 次の各サブセクションの例は、YANG構文と対応するXMLエンコーディングを示しています。 YANGステートメントの構文はセクション6.3で定義されています。
4.2.2.1. Leaf Nodes
4.2.2.1。 葉ノード
A leaf instance 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.";
}
XML Encoding Example:
<host-name>my.example.com</host-name>
The "leaf" statement is covered in Section 7.6.
「リーフ」ステートメントについては、セクション7.6で説明します。
4.2.2.2. Leaf-List Nodes
4.2.2.2。 リーフリストノード
A leaf-list defines a sequence of values of a particular type.
リーフリストは、特定のタイプの値のシーケンスを定義します。
YANG Example:
leaf-list domain-search {
type string;
description
"List of domain names to search.";
}
XML Encoding Example:
<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で説明しています。
Bjorklund Standards Track [Page 19] RFC 7950 YANG 1.1 August 2016 4.2.2.3. Container Nodes
4.2.2.3。 コンテナノード
A container 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 (leafs, lists, containers, leaf-lists, actions, and notifications).
コンテナは、関連するノードをサブツリーにグループ化するために使用されます。 コンテナには子ノードのみがあり、値はありません。 コンテナーには、任意のタイプ（リーフ、リスト、コンテナー、リーフリスト、アクション、および通知）の子ノードをいくつでも含めることができます。
YANG Example:
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session.";
}
}
}
XML Encoding Example:
<system>
<login>
<message>Good morning</message>
</login>
</system>
The "container" statement is covered in Section 7.5.
「コンテナ」ステートメントについては、セクション7.5で説明しています。
Bjorklund Standards Track [Page 20] RFC 7950 YANG 1.1 August 2016 4.2.2.4. List Nodes
4.2.2.4。 ノードのリスト
A list defines a sequence of list entries. Each entry is like a container and is uniquely identified by the values of its key leafs if it has any key leafs defined. 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;
}
}
XML Encoding Example:
<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で説明しています。
Bjorklund Standards Track [Page 21] RFC 7950 YANG 1.1 August 2016 4.2.2.5. Example Module
4.2.2.5。 モジュールの例
These statements are combined to define the module:
これらのステートメントを組み合わせてモジュールを定義します。
// Contents of "example-system.yang"
module example-system {
yang-version 1.1;
namespace "urn:example:system";
prefix "sys";
organization "Example Inc.";
contact "joe@example.com";
description
"The module for entities implementing the Example 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.";
}
Bjorklund Standards Track [Page 22]
RFC 7950 YANG 1.1 August 2016
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
4.2.3. Configuration and State Data
4.2.3。 構成および状態データ
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. If it is tagged with "config true", its subhierarchy is flagged as configuration data. Parent containers, lists, and key leafs are reported also, giving the context for the state data.
YANGは、「config」ステートメントに基づいて、構成データだけでなく状態データもモデル化できます。 ノードに「config false」のタグが付けられると、そのサブ階層に状態データとしてフラグが立てられます。 「config true」というタグが付けられている場合、そのサブ階層には構成データとしてフラグが立てられます。 親コンテナー、リスト、およびキーリーフも報告され、状態データのコンテキストが提供されます。
In this example, two leafs are defined for each interface, a configured speed and an observed speed.
この例では、構成済みの速度と観測された速度の2つのリーフが各インターフェースに定義されています。
list interface {
key "name";
config true;
leaf name {
type string;
}
leaf speed {
type enumeration {
enum 10m;
enum 100m;
enum auto;
}
}
leaf observed-speed {
type uint32;
config false;
}
}
Bjorklund Standards Track [Page 23]
RFC 7950 YANG 1.1 August 2016
The "config" statement is covered in Section 7.21.1.
「config」ステートメントについては、セクション7.21.1で説明しています。
4.2.4. Built-In Types
4.2.4。 組み込み型
YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements of network management. 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 | One of an enumerated set of strings |
| identityref | A reference to an abstract identity |
| instance-identifier | A reference to 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 | A character 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.
「type」ステートメントについては、セクション7.4で説明しています。
Bjorklund Standards Track [Page 24] RFC 7950 YANG 1.1 August 2016 4.2.5. Derived Types (typedef)
4.2.5。 派生型（typedef）
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.
派生型は、「type」ステートメントの引数として使用できます。
YANG Example:
typedef percent {
type uint8 {
range "0 .. 100";
}
}
leaf completed {
type percent;
}
XML Encoding Example:
<completed>20</completed>
The "typedef" statement is covered in Section 7.3.
「typedef」ステートメントについては、セクション7.3で説明しています。
4.2.6. Reusable Node Groups (grouping)
4.2.6。 再利用可能なノードグループ（グループ化）
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.
ノードのグループは、「グループ化」ステートメントを使用して再利用可能なコレクションに組み立てることができます。 グループ化は、「uses」ステートメントでインスタンス化されるノードのセットを定義します。
YANG Example:
grouping target {
leaf address {
type inet:ip-address;
description "Target IP address.";
}
leaf port {
type inet:port-number;
description "Target port number.";
}
}
Bjorklund Standards Track [Page 25]
RFC 7950 YANG 1.1 August 2016
container peer {
container destination {
uses target;
}
}
XML Encoding Example:
<peer>
<destination>
<address>2001:db8::2</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.12.
「グループ化」ステートメントについては、セクション7.12で説明しています。
Bjorklund Standards Track [Page 26] RFC 7950 YANG 1.1 August 2016 4.2.7. Choices
4.2.7。 選択肢
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を使用すると、データモデルは「choice」および「case」ステートメントを使用して、互換性のないノードを異なる選択肢に分離できます。 「choice」ステートメントには、一緒に表示できないスキーマノードのセットを定義する「case」ステートメントのセットが含まれています。 各「ケース」には複数のノードが含まれる場合がありますが、各ノードは「選択」の下の1つの「ケース」にしか表示されません。
The choice and case nodes appear only in the schema tree and not in the data tree. The additional levels of hierarchy are not needed beyond the conceptual schema. The presence of a case is indicated by the presence of one or more of the nodes within it.
選択ノードとケースノードはスキーマツリーにのみ表示され、データツリーには表示されません。 概念的なスキーマを超えて、階層の追加レベルは必要ありません。 ケースの存在は、ケース内の1つ以上のノードの存在によって示されます。
Since only one of the choice's cases can be valid at any time, when a node from one case is created in the data tree, all nodes from all other cases are implicitly deleted. The server handles the enforcement of the constraint, preventing incompatibilities from existing in the configuration.
常に有効なケースは1つだけなので、1つのケースのノードがデータツリーで作成されると、他のすべてのケースのすべてのノードが暗黙的に削除されます。 サーバーは制約の適用を処理し、非互換性が構成に存在しないようにします。
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;
}
}
}
}
}
Bjorklund Standards Track [Page 27]
RFC 7950 YANG 1.1 August 2016
XML Encoding Example:
<food>
<pretzel/>
<beer/>
</food>
The "choice" statement is covered in Section 7.9.
「選択」ステートメントについては、セクション7.9で説明しています。
4.2.8. Extending Data Models (augment)
4.2.8。 データモデルの拡張（拡張）
YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) and 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」ステートメントは、新しいノードが挿入されるデータモデル階層内の場所を定義し、「when」ステートメントは、新しいノードが有効なときの条件を定義します。
When a server implements a module containing an "augment" statement, that implies that the server's implementation of the augmented module contains the additional nodes.
サーバーが「augment」ステートメントを含むモジュールを実装する場合、それはサーバーの拡張モジュールの実装が追加のノードを含むことを意味します。
YANG Example:
augment /system/login/user {
when "class != 'wheel'";
leaf uid {
type uint16 {
range "1000 .. 30000";
}
}
}
This example defines a "uid" node that is valid only when the user's
"class" is not "wheel".
この例では、ユーザーの「クラス」が「ホイール」ではない場合にのみ有効な「uid」ノードを定義しています。
Bjorklund Standards Track [Page 28] RFC 7950 YANG 1.1 August 2016 If a module augments another module, the XML elements that are added to the encoding are in the namespace of the augmenting module. For example, if the above augmentation were in a module with prefix "other", the XML would look like:
モジュールが別のモジュールを拡張する場合、エンコーディングに追加されるXML要素は、拡張モジュールの名前空間にあります。 たとえば、上記の拡張が「other」という接頭辞を持つモジュール内にある場合、XMLは次のようになります。
XML Encoding Example:
<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.17.
「拡張」ステートメントについては、セクション7.17で説明しています。
4.2.9. Operation Definitions
4.2.9。 操作の定義
YANG allows the definition of operations. The operations' names, input parameters, and output parameters are modeled using YANG data definition statements. Operations on the top level in a module are defined with the "rpc" statement. Operations can also be tied to a container or list data node. Such operations are defined with the "action" statement.
YANGは操作の定義を可能にします。 操作の名前、入力パラメーター、および出力パラメーターは、YANGデータ定義ステートメントを使用してモデル化されます。 モジュールの最上位の操作は、「rpc」ステートメントで定義されます。 操作は、コンテナーまたはリストデータノードに関連付けることもできます。 このような操作は、「アクション」ステートメントで定義されます。
YANG Example for an operation at the top level:
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}
Bjorklund Standards Track [Page 29]
RFC 7950 YANG 1.1 August 2016
NETCONF XML Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://example.com/system">
<image-name>example-fw-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://example.com/system">
The image example-fw-2.3 is being installed.
</status>
</rpc-reply>
YANG Example for an operation tied to a list data node:
list interface {
key "name";
leaf name {
type string;
}
action ping {
input {
leaf destination {
type inet:ip-address;
}
}
output {
leaf packet-loss {
type uint8;
}
}
}
}
Bjorklund Standards Track [Page 30]
RFC 7950 YANG 1.1 August 2016
NETCONF XML Example:
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<interface xmlns="http://example.com/system">
<name>eth1</name>
<ping>
<destination>192.0.2.1</destination>
</ping>
</interface>
</action>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:sys="http://example.com/system">
<sys:packet-loss>60</sys:packet-loss>
</rpc-reply>
The "rpc" statement is covered in Section 7.14, and the "action"
statement is covered in Section 7.15.
「rpc」ステートメントはセクション7.14で説明されており、「アクション」ステートメントはセクション7.15で説明されています。
4.2.10. Notification Definitions
4.2.10。 通知の定義
YANG allows the definition of notifications. YANG data definition statements are used to model the content of the notification.
YANGは通知の定義を許可します。 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;
}
}
Bjorklund Standards Track [Page 31]
RFC 7950 YANG 1.1 August 2016
NETCONF XML Example:
<notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="urn:example: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.16.
「通知」ステートメントについては、セクション7.16で説明しています。
5. Language Concepts
5.言語の概念
5.1. Modules and Submodules
5.1。 モジュールとサブモジュール
The module is the base unit of definition in YANG. A module defines a single data model. A module can also augment an existing data model with additional nodes.
モジュールは、YANGでの定義の基本単位です。 モジュールは単一のデータモデルを定義します。 モジュールは、追加のノードで既存のデータモデルを補強することもできます。
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つのモジュールにのみ属することができます。
Developers of YANG modules and submodules 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. Within a server, all module names MUST be unique.
YANGモジュールおよびサブモジュールの開発者は、モジュール名の接頭辞としてエンタープライズ名または組織名を使用するなどして、標準または他のエンタープライズモジュールと衝突する可能性が低いモジュールの名前を選択することをお勧めします。 サーバー内では、すべてのモジュール名が一意である必要があります。
A module uses the "include" statement to list all its submodules. A module, or submodule belonging to that module, can reference definitions in the module and all submodules included by the module.
モジュールは「include」ステートメントを使用して、そのすべてのサブモジュールをリストします。 モジュール、またはそのモジュールに属するサブモジュールは、モジュール内の定義およびモジュールに含まれるすべてのサブモジュールを参照できます。
A module or submodule uses the "import" statement to reference external modules. Statements in the module or submodule can reference definitions in the external module using the prefix specified in the "import" statement.
モジュールまたはサブモジュールは、「インポート」ステートメントを使用して外部モジュールを参照します。 モジュールまたはサブモジュールのステートメントは、「import」ステートメントで指定されたプレフィックスを使用して、外部モジュールの定義を参照できます。
For backward compatibility with YANG version 1, a submodule MAY use the "include" statement to reference other submodules within its module, but this is not necessary in YANG version 1.1. A submodule can reference any definition in the module it belongs to and in all submodules included by the module. A submodule MUST NOT include different revisions of other submodules than the revisions that its module includes.
YANGバージョン1との下位互換性のために、サブモジュールは「include」ステートメントを使用してモジュール内の他のサブモジュールを参照できますが、これはYANGバージョン1.1では必要ありません。 サブモジュールは、それが属するモジュール内、およびモジュールに含まれるすべてのサブモジュール内の定義を参照できます。 サブモジュールには、そのモジュールに含まれているリビジョンとは異なる他のサブモジュールのリビジョンを含めてはなりません（MUST NOT）。
Bjorklund Standards Track [Page 32] RFC 7950 YANG 1.1 August 2016 A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module.
モジュールまたはサブモジュールに他のモジュールのサブモジュールを含めてはならず（MUST NOT）、サブモジュールは独自のモジュールをインポートしてはなりません（MUST NOT）。
The "import" and "include" statements are used to make definitions available from other modules:
"import"および "include"ステートメントは、他のモジュールから定義を利用できるようにするために使用されます。
o For a module or submodule to reference definitions in an external
module, the external module MUST be imported.
モジュールまたはサブモジュールが外部モジュールの定義を参照するには、外部モジュールをインポートする必要があります。
o A module MUST include all its submodules.
モジュールには、そのすべてのサブモジュールを含める必要があります。
o A module, or submodule belonging to that module, MAY reference
definitions in the module and all submodules included by the
module.
モジュール、またはそのモジュールに属するサブモジュールは、モジュール内の定義およびモジュールに含まれるすべてのサブモジュールを参照する場合があります。
There MUST NOT be any circular chains of imports. For example, if module "a" imports module "b", "b" cannot import "a".
インポートの循環チェーンがあってはなりません。 たとえば、モジュール「a」がモジュール「b」をインポートする場合、「b」は「a」をインポートできません。
When a definition in an external module is referenced, a locally
defined prefix MUST be used, followed by a colon (":") 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. The syntax for a
reference to a definition is formally defined by the rule
"identifier-ref" in Section 14.
外部モジュールの定義が参照される場合、ローカルで定義された接頭辞を使用しなければならず、その後にコロン（ "："）が続き、その後に外部識別子が続きます。 ローカルモジュールの定義への参照では、プレフィックス表記を使用できます。 組み込みデータ型はどのモジュールにも属しておらず、プレフィックスもないため、組み込みデータ型（int32など）への参照ではプレフィックス表記を使用できません。 定義への参照の構文は、セクション14のルール「identifier-ref」によって正式に定義されています。
5.1.1. Import and Include by Revision
5.1.1。 リビジョンごとにインポートして含める
Published modules evolve independently over time. In order to allow for this evolution, modules can be imported using specific revisions. Initially, a module imports the revisions of other modules that are current when the module is written. 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 may specify the revision of the included submodules. If a submodule changes, any module or submodule that includes it by revision needs to be updated to reference the new revision.
サブモジュールの場合、問題は関連していますがより単純です。 サブモジュールを含むモジュールまたはサブモジュールは、含まれるサブモジュールのリビジョンを指定できます。 サブモジュールが変更された場合、リビジョンごとにそれを含むモジュールまたはサブモジュールは、新しいリビジョンを参照するように更新する必要があります。
Bjorklund Standards Track [Page 33]
RFC 7950 YANG 1.1 August 2016
For example, module "b" imports module "a".
module a {
yang-version 1.1;
namespace "urn:example:a";
prefix "a";
revision 2008-01-01 { ... }
grouping a {
leaf eh { .... }
}
}
module b {
yang-version 1.1;
namespace "urn:example:b";
prefix "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」の作成者は「import」ステートメントの更新されたリビジョンで再発行できます。
If a module is not imported with a specific revision, it is undefined which revision is used.
モジュールが特定のリビジョンでインポートされない場合、どのリビジョンが使用されるかは未定義です。
5.1.2. Module Hierarchies
5.1.2。 モジュール階層
YANG allows modeling of data in multiple hierarchies, where data may have more than one top-level node. Each top-level data node in a module defines a separate hierarchy. Models that have multiple top-level nodes are sometimes convenient and are supported by YANG.
YANGを使用すると、データに複数の最上位ノードが存在する可能性がある複数の階層のデータをモデル化できます。 モジュールの各最上位データノードは、個別の階層を定義します。 複数の最上位ノードがあるモデルは便利な場合があり、YANGでサポートされています。
Bjorklund Standards Track [Page 34] RFC 7950 YANG 1.1 August 2016 5.1.2.1. NETCONF XML Encoding
5.1.2.1。 NETCONF XMLエンコーディング
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, an instance of:
module example-config {
yang-version 1.1;
namespace "urn:example:config";
prefix "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="urn:example:config">
<!-- system data here -->
</system>
<routing xmlns="urn:example:config">
<!-- routing data here -->
</routing>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 35]
RFC 7950 YANG 1.1 August 2016
5.2. File Layout
5.2。 ファイルのレイアウト
YANG modules and submodules are typically stored in files, one "module" or "submodule" statement per file. The name of the file SHOULD be of the form:
YANGモジュールとサブモジュールは通常ファイルに保存され、ファイルごとに1つの「モジュール」または「サブモジュール」ステートメントがあります。 ファイルの名前は次の形式にする必要があります（SHOULD）
module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
"module-or-submodule-name" is the name of the module or submodule,
and the optional "revision-date" is the latest revision of the module
or submodule, as defined by the "revision" statement (Section 7.1.9).
"module-or-submodule-name"はモジュールまたはサブモジュールの名前で、オプションの "revision-date"は "revision"ステートメントで定義されているモジュールまたはサブモジュールの最新リビジョンです（セクション7.1.9）。 。
The file extension ".yang" denotes that the contents of the file are written with YANG syntax (Section 6), and ".yin" denotes that the contents of the file are written with YIN syntax (Section 13).
ファイル拡張子 ".yang"は、ファイルの内容がYANG構文（セクション6）で記述されていることを示し、 "。yin"は、ファイルの内容がYIN構文（セクション13）で記述されていることを示します。
YANG parsers can find imported modules and included submodules via this convention.
YANGパーサーは、この規則により、インポートされたモジュールと含まれているサブモジュールを見つけることができます。
5.3. XML Namespaces
5.3。 XML名前空間
All YANG definitions are specified within a module. Each module is bound to a distinct 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エンコーディング中にネームスペースを使用します。
XML namespaces for modules published in RFC streams [RFC4844] MUST be assigned by IANA; see Section 14 in [RFC6020].
RFCストリーム[RFC4844]で公開されたモジュールのXML名前空間は、IANAによって割り当てられる必要があります。 [RFC6020]のセクション14を参照してください。
XML 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.
プライベートモジュールのXML名前空間は、中央レジストリのないモジュールを所有する組織によって割り当てられます。 名前空間URIは、標準または他のエンタープライズ名前空間と衝突しないように選択する必要があります。たとえば、名前空間でエンタープライズ名または組織名を使用します。
The "namespace" statement is covered in Section 7.1.3.
「名前空間」ステートメントについては、セクション7.1.3で説明しています。
5.3.1. YANG XML Namespace
5.3.1。 YANG XML名前空間
YANG defines an XML namespace for NETCONF <edit-config> operations, <error-info> content, and the <action> element. The name of this namespace is "urn:ietf:params:xml:ns:yang:1".
YANGは、NETCONF <edit-config>操作、<error-info>コンテンツ、および<action>要素のXML名前空間を定義します。 この名前空間の名前は「urn：ietf：params：xml：ns：yang：1」です。
Bjorklund Standards Track [Page 36] RFC 7950 YANG 1.1 August 2016 5.4. Resolving Grouping, Type, and Identity Names
5.4。 グループ化、タイプ、およびID名の解決
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 ambiguity if both modules define the type.
たとえば、モジュールがタイプを参照するグループ化を定義している場合、そのグループ化が2番目のモジュールで使用されると、タイプは2番目のモジュールではなく元のモジュールのコンテキストで解決されます。 両方のモジュールが型を定義する場合、あいまいさはありません。
5.5. Nested Typedefs and Groupings
5.5。 ネストされたTypedefとグループ化
Typedefs and groupings may appear nested under many YANG statements, allowing these to be lexically scoped by the statement 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.
Typedefとグループ化は、多くのYANGステートメントの下にネストされて表示される場合があり、それらが表示されるステートメント階層によってレキシカルにスコープを設定できます。 これにより、タイプとグループを階層の最上位に配置するのではなく、使用される場所の近くに定義できます。 近接することで読みやすさが向上します。
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 statement hierarchy has a definition with a matching identifier.
スコープ定義は、より高いスコープで定義をシャドウすることはできません。 ステートメント階層の上位レベルに一致するIDの定義がある場合、タイプまたはグループ化は定義できません。
A reference to an unprefixed type or grouping, or one that uses the prefix of the current module, is resolved by locating the matching "typedef" or "grouping" statement among the immediate substatements of each ancestor statement.
接頭辞のない型またはグループ化、または現在のモジュールの接頭辞を使用するものへの参照は、各祖先ステートメントの直接のサブステートメントの中で一致する「typedef」または「グループ化」ステートメントを見つけることによって解決されます。
Bjorklund Standards Track [Page 37] RFC 7950 YANG 1.1 August 2016 5.6. Conformance
5.6。 適合
Conformance to a model is a measure of how accurately a server follows the model. Generally speaking, servers are responsible for implementing the model faithfully, allowing applications to treat servers that implement the model identically. Deviations from the model can reduce the utility of the model and increase the fragility of applications that use it.
モデルへの適合性は、サーバーがモデルにどれだけ正確に従うかを示す尺度です。 一般的に言って、サーバーはモデルを忠実に実装する責任があり、アプリケーションはモデルを実装するサーバーを同じように扱うことができます。 モデルからの逸脱は、モデルの有用性を低下させ、それを使用するアプリケーションの脆弱性を増大させる可能性があります。
YANG modelers have three mechanisms for conformance:
YANGモデラーには、3つの適合メカニズムがあります。
o the basic behavior of the model
モデルの基本的な動作
o optional features that are part of the model
モデルの一部であるオプション機能
o deviations from the model
モデルからの逸脱
We will consider each of these in sequence.
これらのそれぞれを順番に検討します。
5.6.1. Basic Behavior
5.6.1。 基本的な行動
The model defines a contract between a YANG-based client and server; this contract allows both parties to have faith that the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract.
モデルは、YANGベースのクライアントとサーバー間の契約を定義します。 この契約により、両当事者は、モデル化されたデータの背後にある構文とセマンティクスを他方が知っているという信頼を持つことができます。 YANGの強みは、この契約の強さにあります。
5.6.2. Optional Features
5.6.2。 オプション機能
In many models, the modeler will allow sections of the model to be conditional. The server controls whether these conditional portions of the model are supported or valid for that particular server.
多くのモデルでは、モデラーはモデルのセクションを条件付きにすることができます。 サーバーは、モデルのこれらの条件付き部分がサポートされているか、その特定のサーバーで有効かを制御します。
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 server has local storage. If there is no local storage, an application should not tell the server 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 server. The model can express constructs that are not universally present in all servers. 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 server.
YANGは、「機能」と呼ばれる構造を使用して、この条件付きメカニズムをサポートしています。 機能は、サーバーによって制御される方法でモジュールの一部を条件付きにするためのメカニズムをモデラーに提供します。 モデルは、すべてのサーバーに普遍的に存在するわけではない構成を表現できます。 これらの機能はモデル定義に含まれているため、一貫したビューが可能になり、アプリケーションはサポートされている機能を学習して、サーバーに合わせて動作を調整できます。
Bjorklund Standards Track [Page 38] RFC 7950 YANG 1.1 August 2016 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 server supports a feature, then the corresponding portions of the module are valid for that server. If the server 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.
機能は「feature」ステートメントを使用して定義されます。 機能を条件とするモジュール内の定義は、「if-feature」ステートメントで示されます。
Further details are available in Section 7.20.1.
詳細については、セクション7.20.1を参照してください。
5.6.3. Deviations
5.6.3。 偏差
In an ideal world, all servers would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, servers are often not able or designed to implement the model as written. For YANG-based automation to deal with these server deviations, a mechanism must exist for servers 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 server 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番目のピアを構成するアプリケーションはエラーを受け取ります。 エラーでアプリケーションに別のピアを追加できないことを通知するのに十分な場合がありますが、アプリケーションにこの制限に関する事前の知識があり、ユーザーが成功しなかったパスを開始できない場合は、はるかに良いでしょう。
Server 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 detail the manner in which the server implementation deviates from the contract as defined in the module.
サーバーの偏差は、スキーマツリー内のノードを識別する文字列を引数として取る「偏差」ステートメントを使用して宣言されます。 ステートメントの内容は、サーバー実装がモジュールで定義されているコントラクトから逸脱する方法を詳しく説明しています。
Further details are available in Section 7.20.3.
詳細は、7.20.3項を参照してください。
Bjorklund Standards Track [Page 39] RFC 7950 YANG 1.1 August 2016 5.6.4. Announcing Conformance Information in NETCONF
5.6.4。 NETCONFでの適合性情報の発表
This document defines the following mechanism for announcing conformance information. Other mechanisms may be defined by future specifications.
このドキュメントは、適合情報を発表するための次のメカニズムを定義します。 その他のメカニズムは、将来の仕様で定義される可能性があります。
A NETCONF server MUST announce the modules it implements (see Section 5.6.5) by implementing the YANG module "ietf-yang-library" defined in [RFC7895] and listing all implemented modules in the "/modules-state/module" list.
NETCONFサーバーは、[RFC7895]で定義されたYANGモジュール「ietf-yang-library」を実装し、「/ modules-state / module」リストにすべての実装済みモジュールをリストすることにより、実装するモジュール（セクション5.6.5を参照）を通知する必要があります。
The server also MUST advertise the following capability in the <hello> message (line breaks and whitespaces are used for formatting reasons only):
サーバーは、<hello>メッセージで次の機能もアドバタイズする必要があります（改行と空白はフォーマット上の理由でのみ使用されます）。
urn:ietf:params:netconf:capability:yang-library:1.0?
revision=<date>&module-set-id=<id>
The parameter "revision" has the same value as the revision date of
the "ietf-yang-library" module implemented by the server. This
parameter MUST be present.
パラメータ「revision」は、サーバーによって実装された「ietf-yang-library」モジュールの改訂日と同じ値を持っています。 このパラメーターは存在しなければなりません。
The parameter "module-set-id" has the same value as the leaf "/modules-state/module-set-id" from "ietf-yang-library". This parameter MUST be present.
パラメータ「module-set-id」は、「ietf-yang-library」のリーフ「/ modules-state / module-set-id」と同じ値です。 このパラメーターは存在しなければなりません。
With this mechanism, a client can cache the supported modules for a server and only update the cache if the "module-set-id" value in the <hello> message changes.
このメカニズムにより、クライアントはサーバーでサポートされているモジュールをキャッシュし、<hello>メッセージの「module-set-id」値が変更された場合にのみキャッシュを更新できます。
5.6.5. Implementing a Module
5.6.5。 モジュールの実装
A server implements a module if it implements the module's data nodes, RPCs, actions, notifications, and deviations.
サーバーは、モジュールのデータノード、RPC、アクション、通知、および偏差を実装する場合、モジュールを実装します。
A server MUST NOT implement more than one revision of a module.
サーバーは、モジュールの複数のリビジョンを実装してはなりません（MUST NOT）。
If a server implements a module A that imports a module B, and A uses any node from B in an "augment" or "path" statement that the server supports, then the server MUST implement a revision of module B that has these nodes defined. This is regardless of whether module B is imported by revision or not.
サーバーがモジュールBをインポートするモジュールAを実装し、Aがサーバーがサポートする「拡張」または「パス」ステートメントでBのノードを使用する場合、サーバーはこれらのノードが定義されているモジュールBのリビジョンを実装する必要があります。 。 これは、モジュールBがリビジョンによってインポートされるかどうかに関係ありません。
Bjorklund Standards Track [Page 40] RFC 7950 YANG 1.1 August 2016 If a server implements a module A that imports a module C without specifying the revision date of module C and the server does not implement C (e.g., if C only defines some typedefs), the server MUST list module C in the "/modules-state/module" list from "ietf-yang-library" [RFC7895], and it MUST set the leaf "conformance-type" to "import" for this module.
サーバーがモジュールCの改訂日を指定せずにモジュールCをインポートするモジュールAを実装し、サーバーがCを実装しない場合（たとえば、Cが一部のtypedefのみを定義する場合）、サーバーはモジュールCを「/ modules- "ietf-yang-library" [RFC7895]のstate / module "リスト。このモジュールのリーフ" conformance-type "を" import "に設定する必要があります。
If a server lists a module C in the "/modules-state/module" list from "ietf-yang-library" and there are other modules Ms listed that import C without specifying the revision date of module C, the server MUST use the definitions from the most recent revision of C listed for modules Ms.
サーバーが「ietf-yang-library」の「/ modules-state / module」リストにモジュールCをリストし、モジュールCの改訂日を指定せずにCをインポートする他のモジュールMがリストされている場合、サーバーは モジュールMsにリストされているCの最新リビジョンの定義。
The reason for these rules is that clients need to be able to know the specific data model structure and types of all leafs and leaf-lists implemented in a server.
これらのルールの理由は、クライアントがサーバーに実装されているすべてのリーフとリーフリストの特定のデータモデル構造とタイプを認識できる必要があるためです。
For example, with these modules:
module a {
yang-version 1.1;
namespace "urn:example:a";
prefix "a";
import b {
revision-date 2015-01-01;
}
import c;
revision 2015-01-01;
feature foo;
augment "/b:x" {
if-feature foo;
leaf y {
type b:myenum;
}
}
container a {
leaf x {
type c:bar;
}
}
}
Bjorklund Standards Track [Page 41]
RFC 7950 YANG 1.1 August 2016
module b {
yang-version 1.1;
namespace "urn:example:b";
prefix "b";
revision 2015-01-01;
typedef myenum {
type enumeration {
enum zero;
}
}
container x {
}
}
module b {
yang-version 1.1;
namespace "urn:example:b";
prefix "b";
revision 2015-04-04;
revision 2015-01-01;
typedef myenum {
type enumeration {
enum zero; // added in 2015-01-01
enum one; // added in 2015-04-04
}
}
container x { // added in 2015-01-01
container y; // added in 2015-04-04
}
}
module c {
yang-version 1.1;
namespace "urn:example:c";
prefix "c";
revision 2015-02-02;
typedef bar {
...
}
}
Bjorklund Standards Track [Page 42]
RFC 7950 YANG 1.1 August 2016
module c {
yang-version 1.1;
namespace "urn:example:c";
prefix "c";
revision 2015-03-03;
revision 2015-02-02;
typedef bar {
...
}
}
A server that implements revision "2015-01-01" of module "a" and
supports feature "foo" can implement revision "2015-01-01" or
"2015-04-04" of module "b". Since "b" was imported by revision, the
type of leaf "/b:x/a:y" is the same, regardless of which revision of
"b" the server implements.
モジュール「a」のリビジョン「2015-01-01」を実装し、機能「foo」をサポートするサーバーは、モジュール「b」のリビジョン「2015-01-01」または「2015-04-04」を実装できます。 「b」はリビジョンによってインポートされたため、サーバーが実装する「b」のリビジョンに関係なく、リーフ「/ b：x / a：y」のタイプは同じです。
A server that implements module "a" but does not support feature "foo" does not have to implement module "b".
モジュール "a"を実装しているが、機能 "foo"をサポートしていないサーバーは、モジュール "b"を実装する必要はありません。
A server that implements revision "2015-01-01" of module "a" picks any revision of module "c" and lists it in the "/modules-state/module" list from "ietf-yang-library".
モジュール「a」のリビジョン「2015-01-01」を実装するサーバーは、モジュール「c」のリビジョンを選択し、「ietf-yang-library」の「/ modules-state / module」リストにリストします。
The following XML encoding example shows valid data for the "/modules-state/module" list for a server that implements module "a":
次のXMLエンコードの例は、モジュール「a」を実装するサーバーの「/ modules-state / module」リストの有効なデータを示しています。
<modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id>ee1ecb017370cafd</module-set-id>
<module>
<name>a</name>
<revision>2015-01-01</revision>
<namespace>urn:example:a</namespace>
<feature>foo</feature>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>b</name>
<revision>2015-04-04</revision>
<namespace>urn:example:b</namespace>
<conformance-type>implement</conformance-type>
</module>
Bjorklund Standards Track [Page 43]
RFC 7950 YANG 1.1 August 2016
<module>
<name>c</name>
<revision>2015-02-02</revision>
<namespace>urn:example:c</namespace>
<conformance-type>import</conformance-type>
</module>
</modules-state>
5.7. Datastore Modification
5.7。 データストアの変更
Data models may allow the server to alter the configuration datastore in ways not explicitly directed via network management 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.
データモデルにより、サーバーはネットワーク管理プロトコルメッセージを介して明示的に指示されない方法で構成データストアを変更できます。 たとえば、データモデルは、クライアントが提供しない場合にシステム生成値が割り当てられるリーフを定義する場合があります。 これらの変更が許可される状況を指定するための正式なメカニズムは、この仕様の範囲外です。
6. YANG Syntax
6. YANG構文
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 ++などのプログラミング言語の構文に似ています。 このCのような構文は、YANGがモジュールライターおよびYANGツールチェーン開発者よりもモデルのリーダーの時間と労力を重視しているため、特にその読みやすさのために選択されました。 このセクションでは、YANG構文を紹介します。
Legal characters in YANG modules are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. The character syntax is formally defined by the rule "yang-char" in Section 14.
YANGモジュールの有効な文字は、UnicodeおよびISO / IEC 10646 [ISO.10646]文字で、タブ、キャリッジリターン、ラインフィードが含まれますが、他のC0制御文字、サロゲートブロック、および非文字は含まれません。 文字構文は、セクション14のルール "yang-char"によって正式に定義されています。
YANG modules and submodules are stored in files using the UTF-8 [RFC3629] character encoding.
YANGモジュールとサブモジュールは、UTF-8 [RFC3629]文字エンコーディングを使用してファイルに保存されます。
Lines in a YANG module end with a carriage return-line feed combination or with a line feed alone. A carriage return that is not followed by a line feed may only appear inside a quoted string (Section 6.1.3). Note that carriage returns and line feeds that appear inside quoted strings become part of the value of the string without modification; the value of a multi-line quoted string contains the same form of line ends as those lines of the YANG module.
YANGモジュールの行は、キャリッジリターンとラインフィードの組み合わせ、またはラインフィードのみで終了します。 改行が続かないキャリッジリターンは、引用符で囲まれた文字列内にのみ表示できます（セクション6.1.3）。 引用符で囲まれた文字列内に表示される改行と改行は、変更されずに文字列の値の一部になることに注意してください。 複数行で引用された文字列の値には、YANGモジュールの行と同じ形式の行の終わりが含まれます。
Bjorklund Standards Track [Page 44] RFC 7950 YANG 1.1 August 2016 6.1. Lexical Tokenization
6.1。 字句トークン化
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モジュールは一連のトークンとして解析されます。 このセクションでは、入力ストリームからトークンを認識するためのルールについて詳しく説明します。 YANGトークン化ルールはシンプルかつ強力です。 シンプルさは、パーサーの実装を容易に保つ必要があるために推進されますが、モデラーは、モデルを読み取り可能な形式で表現する必要があるという事実によって推進されます。
6.1.1. Comments
6.1.1。 コメント
Comments are C++ style. A single line comment starts with "//" and ends at the end of the line. A block comment starts with "/*" and ends with the nearest following "*/".
コメントはC ++スタイルです。 単一行のコメントは「//」で始まり、行の終わりで終わります。 ブロックコメントは「/ *」で始まり、最も近い後続の「* /」で終わります。
Note that inside a quoted string (Section 6.1.3), these character pairs are never interpreted as the start or end of a comment.
引用符で囲まれた文字列（セクション6.1.3）内では、これらの文字ペアがコメントの開始または終了として解釈されることはありません。
6.1.2. Tokens
6.1.2。 トークン
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 a colon (":"), followed by a language
extension keyword. Keywords are case sensitive. See Section 6.2 for
a formal definition of identifiers.
YANGのトークンは、キーワード、文字列、セミコロン（ ";"）、または中括弧（ "{"または "}"）のいずれかです。 文字列は引用符で囲んだり、引用符で囲んだりできます。 キーワードは、このドキュメントで定義されているYANGキーワードのいずれか、または接頭辞識別子の後にコロン（ "："）が続き、その後に言語拡張キーワードが続きます。 キーワードでは大文字と小文字が区別されます。 識別子の正式な定義については、セクション6.2を参照してください。
6.1.3. Quoting
6.1.3。 引用
An unquoted string is any sequence of characters that does not
contain any space, tab, carriage return, or line feed characters, a
single or double quote character, a semicolon (";"), braces ("{" or
"}"), or comment sequences ("//", "/*", or "*/").
引用符で囲まれていない文字列は、スペース、タブ、キャリッジリターン、またはラインフィード文字、単一引用符または二重引用符、セミコロン（ ";"）、中かっこ（ "{"または "}"）を含まない文字のシーケンスです。 、またはコメントシーケンス（ "//"、 "/ *"、または "* /"）。
Note that any keyword can legally appear as an unquoted string.
すべてのキーワードは、引用符で囲まれていない文字列として合法的に表示できることに注意してください。
Within an unquoted string, every character is preserved. Note that this means that the backslash character does not have any special meaning in an unquoted string.
引用符で囲まれていない文字列内では、すべての文字が保持されます。 これは、引用符で囲まれていない文字列では円記号が特別な意味を持たないことを意味します。
If a 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 starting double quote character, or to the first non-whitespace character, whichever occurs first. Any tab character in a succeeding line that must be examined for stripping is first converted into 8 space characters.
二重引用符で囲まれた文字列に、YANGファイルのレイアウトに従ってテキストをインデントするために使用される改行とそれに続くスペースまたはタブ文字が含まれている場合、この先頭の空白は、文字列から先頭の列まで削除されます 二重引用符文字、または最初の空白以外の文字のいずれか先に出現した方。 ストリッピングを検査する必要がある次の行のタブ文字は、最初に8つのスペース文字に変換されます。
Bjorklund Standards Track [Page 45] RFC 7950 YANG 1.1 August 2016 If a 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 representation of a special character, which depends on the character that immediately follows the backslash:
二重引用符で囲まれた文字列（ ""で囲まれている）内では、円記号によって特殊文字の表現が導入されます。これは、円記号の直後に続く文字に依存します。
\n newline
\t a tab character
\" a double quote
\\ a single backslash
The backslash MUST NOT be followed by any other character.
バックスラッシュの後には他の文字を続けてはいけません。
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, line breaks, and comments are allowed between the quoted
strings and the plus character.
引用符付き文字列の後にプラス文字（ "+"）が続き、別の引用符付き文字列が続く場合、2つの文字列は1つの文字列に連結され、複数の連結で1つの文字列を作成できます。 引用符で囲まれた文字列とプラス文字の間には、空白、改行、コメントを入れることができます。
In double-quoted strings, whitespace trimming is done before substitution of backslash-escaped characters. Concatenation is performed as the last step.
二重引用符で囲まれた文字列では、バックスラッシュでエスケープされた文字を置き換える前に、空白のトリミングが行われます。 最後のステップとして連結が実行されます。
6.1.3.1. Quoting Examples
6.1.3.1。 引用例
The following strings are equivalent:
次の文字列は同等です。
hello
"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 newline character
'\n' - string containing a backslash followed
by the character n
Bjorklund Standards Track [Page 46]
RFC 7950 YANG 1.1 August 2016
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"
6.2. Identifiers
6.2。 識別子
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 and MAY support longer identifiers. Identifiers are case sensitive. The identifier syntax is formally defined by the rule "identifier" in Section 14. Identifiers can be specified as quoted or unquoted strings.
識別子は、さまざまな種類のYANGアイテムを名前で識別するために使用されます。 各識別子は、大文字または小文字のASCII文字またはアンダースコア文字で始まり、0個以上のASCII文字、数字、アンダースコア文字、ハイフン、ドットが続きます。 実装は、長さが最大64文字の識別子をサポートする必要があり、より長い識別子をサポートする場合があります。 識別子は大文字と小文字が区別されます。 識別子の構文は、セクション14のルール「識別子」によって正式に定義されています。 識別子は、引用符付きまたは引用符なしの文字列として指定できます。
6.2.1. Identifiers and Their Namespaces
6.2.1。 識別子とその名前空間
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.
各識別子は、定義されているYANGアイテムのタイプに依存するネームスペースで有効です。 名前空間で定義されたすべての識別子は一意でなければなりません。
o All module and submodule names share the same global module
identifier namespace.
すべてのモジュールとサブモジュールの名前は、同じグローバルモジュール識別子の名前空間を共有します。
o All extension names defined in a module and its submodules share
the same extension identifier namespace.
モジュールとそのサブモジュールで定義されたすべての拡張名は、同じ拡張識別子の名前空間を共有します。
o All feature names defined in a module and its submodules share the
same feature identifier namespace.
モジュールとそのサブモジュールで定義されているすべての機能名は、同じ機能識別子名前空間を共有します。
o All identity names defined in a module and its submodules share
the same identity identifier namespace.
モジュールとそのサブモジュールで定義されたすべての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
descendant node may use that typedef, and it MUST NOT define a
typedef with the same name.
親ノード内、またはモジュールのトップレベルで定義されたすべての派生型名またはそのサブモジュールは、同じ型識別子の名前空間を共有します。 この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。 これは、すべての子孫ノードがそのtypedefを使用する可能性があり、同じ名前でtypedefを定義してはならないことを意味します。
Bjorklund Standards Track [Page 47]
RFC 7950 YANG 1.1 August 2016
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
descendant node may use that grouping, and it MUST NOT define a
grouping with the same name.
親ノード内、またはモジュールまたはそのサブモジュールの最上位で定義されているすべてのグループ化名は、同じグループ化識別子名前空間を共有します。 この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。 これは、すべての子孫ノードがそのグループを使用できることを意味し、同じ名前のグループを定義してはなりません（MUST NOT）。
o All leafs, leaf-lists, lists, containers, choices, rpcs, actions,
notifications, anydatas, 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.
親ノード内またはモジュールの最上位レベルまたはそのサブモジュール共有で（直接または「uses」ステートメントを介して）定義されたすべての葉、葉リスト、リスト、コンテナー、選択、rpcs、アクション、通知、anydata、およびanyxml 同じ識別子の名前空間。 親ノードがケースノードでない限り、この名前空間のスコープは親ノードまたはモジュールです。 その場合、名前空間は、ケースノードや選択ノードではない、最も近い祖先ノードにスコープされます。
o All cases within a choice share the same case identifier
namespace. This namespace is scoped to the parent choice node.
選択肢内のすべてのケースは、同じケース識別子の名前空間を共有します。 この名前空間のスコープは、親の選択ノードです。
Forward references are allowed in YANG.
YANGでは前方参照が許可されています。
6.3. Statements
6.3。 ステートメント
A YANG module contains a sequence of statements. Each statement
starts with a keyword, followed by zero or one argument, followed by
either 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項で定義されている文字列です。
6.3.1. Language Extensions
6.3.1。 言語拡張
A module can introduce YANG extensions by using the "extension" keyword (see Section 7.19). 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 prefix of this module.
モジュールは "extension"キーワードを使用してYANG拡張を導入できます（セクション7.19を参照）。 拡張機能は、 "import"ステートメントを使用して他のモジュールによってインポートできます（セクション7.1.5を参照）。 インポートされた拡張機能が使用される場合、拡張機能のモジュールがインポートされたときの接頭辞を使用して、拡張機能のキーワードを修飾する必要があります。 拡張が定義されているモジュールで拡張が使用されている場合、拡張のキーワードはこのモジュールの接頭辞で修飾する必要があります。
The processing of extensions depends on whether support for those extensions is claimed for a given YANG parser or the tool set in which it is embedded. An unsupported extension appearing in a YANG module as an unknown-statement (see Section 14) MAY be ignored in its entirety. Any supported extension MUST be processed in accordance with the specification governing that extension.
拡張機能の処理は、それらの拡張機能のサポートが、指定されたYANGパーサーまたはそれが埋め込まれているツールセットに対して要求されているかどうかによって異なります。 YANGモジュールで不明なステートメント（セクション14を参照）として表示されるサポートされていない拡張機能は、その全体が無視される場合があります。 サポートされる拡張機能はすべて、その拡張機能を管理する仕様に従って処理する必要があります。
Bjorklund Standards Track [Page 48] RFC 7950 YANG 1.1 August 2016 Care must be taken when defining extensions so that modules that use the extensions are meaningful also for applications that do not support the extensions.
拡張機能を定義するときは、拡張機能を使用するモジュールが、拡張機能をサポートしないアプリケーションでも意味を持つように注意する必要があります。
6.4. XPath Evaluations
6.4。 XPath評価
YANG relies on XML Path Language (XPath) 1.0 [XPATH] as a notation for specifying many inter-node references and dependencies. An implementation is 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パス言語（XPath）1.0 [XPATH]に依存しています。 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 (see Section 3.1 in [XSLT]). 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を参照）。 具体的には、ルートノードは子として任意の数の要素ノードを持つことができることを意味します。
The data tree has no concept of document order. An implementation needs to choose some document order, but how it is done is an implementation decision. This means that XPath expressions in YANG modules SHOULD NOT rely on any specific document order.
データツリーには、ドキュメントの順序という概念はありません。 実装ではドキュメントの順序を選択する必要がありますが、その方法は実装の決定です。 これは、YANGモジュールのXPath式が特定のドキュメントの順序に依存してはならないことを意味します。
Numbers in XPath 1.0 are IEEE 754 [IEEE754-2008] double-precision floating-point values; see Section 3.5 in [XPATH]. This means that some values of int64, uint64, and decimal64 types (see Sections 9.2 and 9.3) cannot be exactly represented in XPath expressions. Therefore, due caution should be exercised when using nodes with 64-bit numeric values in XPath expressions. In particular, numerical comparisons involving equality may yield unexpected results.
XPath 1.0の数値は、IEEE 754 [IEEE754-2008]倍精度浮動小数点値です。 [XPATH]のセクション3.5を参照してください。 これは、int64、uint64、およびdecimal64型のいくつかの値（セクション9.2および9.3を参照）は、XPath式で正確に表現できないことを意味します。 したがって、XPath式で64ビットの数値を持つノードを使用する場合は、十分な注意が必要です。 特に、等式を含む数値比較では、予期しない結果が生じる可能性があります。
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 10";
}
An instance of the "lxiv" leaf having the value of
10.0000000000000001 will then successfully pass validation.
値が10.0000000000000001の「lxiv」リーフのインスタンスは、検証に成功します。
Bjorklund Standards Track [Page 49] RFC 7950 YANG 1.1 August 2016 6.4.1. XPath Context
6.4.1。 XPathコンテキスト
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.
名前空間宣言のセットは、XPath式が指定されているモジュール内のすべての「import」ステートメントの接頭辞と名前空間のペアのセット、および「namespace」ステートメントのURIに対する「prefix」ステートメントの接頭辞です。
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.13). Inside a typedef, that namespace is affected by
where the typedef is referenced. If a typedef is defined and
referenced within a grouping, the namespace is affected by where
the grouping is used (see Section 7.13).
名前空間接頭辞のない名前は、現在のノードの識別子と同じ名前空間に属しています。 グループ化の内部では、その名前空間はグループ化が使用される場所に影響されます（セクション7.13を参照）。 typedef内では、その名前空間はtypedefが参照される場所の影響を受けます。 typedefがグループ内で定義および参照されている場合、名前空間はグループが使用される場所に影響されます（セクション7.13を参照）。
o The function library is the core function library defined in
[XPATH] and the functions defined in Section 10.
関数ライブラリは、[XPATH]で定義されたコア関数ライブラリであり、セクション10で定義された関数です。
o The set of variable bindings is empty.
変数バインディングのセットが空です。
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ノード識別子は常にnull以外の名前空間URIで修飾された名前であるため、あいまいさが発生することはありません。
The accessible tree depends on where the statement with the XPath expression is defined:
アクセス可能なツリーは、XPath式を含むステートメントが定義されている場所によって異なります。
o If the XPath expression is defined in a substatement to a data
node that represents configuration, the accessible tree is the
data in the datastore where the context node exists. The root
node has all top-level configuration data nodes in all modules as
children.
XPath式が構成を表すデータノードのサブステートメントで定義されている場合、アクセス可能なツリーは、コンテキストノードが存在するデータストア内のデータです。 ルートノードには、すべてのモジュールのすべての最上位の構成データノードが子として含まれます。
o If the XPath expression is defined in a substatement to a data
node that represents state data, the accessible tree is all state
data in the server, and the running configuration datastore. The
root node has all top-level data nodes in all modules as children.
XPath式が状態データを表すデータノードのサブステートメントで定義されている場合、アクセス可能なツリーは、サーバー内のすべての状態データと実行中の構成データストアです。 ルートノードには、すべてのモジュールのすべての最上位データノードが子として含まれます。
o If the XPath expression is defined in a substatement to a
"notification" statement, the accessible tree is the notification
instance, all state data in the server, and the running
configuration datastore. If the notification is defined on the
top level in a module, then the root node has the node
Bjorklund Standards Track [Page 50]
RFC 7950 YANG 1.1 August 2016
representing the notification being defined and all top-level data
nodes in all modules as children. Otherwise, the root node has
all top-level data nodes in all modules as children.
XPath式が「通知」ステートメントのサブステートメントで定義されている場合、アクセス可能なツリーは、通知インスタンス、サーバー内のすべての状態データ、および実行中の構成データストアです。 通知がモジュールの最上位で定義されている場合、ルートノードには、定義されている通知を表すノードと、すべてのモジュールのすべての最上位のデータノードが子として含まれます。 それ以外の場合、ルートノードはすべてのモジュールのすべての最上位データノードを子として持ちます。
o If the XPath expression is defined in a substatement to an "input"
statement in an "rpc" or "action" statement, the accessible tree
is the RPC or action operation instance, all state data in the
server, and the running configuration datastore. The root node
has top-level data nodes in all modules as children.
Additionally, for an RPC, the root node also has the node
representing the RPC operation being defined as a child. The node
representing the operation being defined has the operation's input
parameters as children.
XPath式が「rpc」または「action」ステートメントの「input」ステートメントのサブステートメントで定義されている場合、アクセス可能なツリーは、RPCまたはアクション操作インスタンス、サーバー内のすべての状態データ、および実行中の構成データストアです。 ルートノードには、すべてのモジュールで子として最上位のデータノードがあります。 さらに、RPCの場合、ルートノードには、RPC操作を表すノードが子として定義されています。 定義されている操作を表すノードには、子としての操作の入力パラメーターがあります。
o If the XPath expression is defined in a substatement to an
"output" statement in an "rpc" or "action" statement, the
accessible tree is the RPC or action operation instance, all state
data in the server, and the running configuration datastore. The
root node has top-level data nodes in all modules as children.
Additionally, for an RPC, the root node also has the node
representing the RPC operation being defined as a child. The node
representing the operation being defined has the operation's
output parameters as children.
XPath式が「rpc」または「action」ステートメントの「output」ステートメントのサブステートメントで定義されている場合、アクセス可能なツリーは、RPCまたはアクション操作インスタンス、サーバー内のすべての状態データ、および実行中の構成データストアです。 ルートノードには、すべてのモジュールで子として最上位のデータノードがあります。 さらに、RPCの場合、ルートノードには、RPC操作を表すノードが子として定義されています。 定義される操作を表すノードには、子としての操作の出力パラメーターがあります。
In the accessible tree, all leafs and leaf-lists with default values in use exist (see Sections 7.6.1 and 7.7.2).
アクセス可能なツリーには、デフォルト値が使用されているすべてのリーフとリーフリストが存在します（セクション7.6.1および7.7.2を参照）。
If a node that exists in the accessible tree has a non-presence container as a child, then the non-presence container also exists in the accessible tree.
アクセス可能なツリーに存在するノードが子として存在しないコンテナを持っている場合、存在しないコンテナもアクセス可能なツリーに存在します。
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ステートメントが定義されている場所で指定されます。
Bjorklund Standards Track [Page 51] RFC 7950 YANG 1.1 August 2016 6.4.1.1. Examples
6.4.1.1。 例
Given the following module:
次のモジュールがあるとします。
module example-a {
yang-version 1.1;
namespace urn:example:a;
prefix a;
container a {
list b {
key id;
leaf id {
type string;
}
notification down {
leaf reason {
type string;
}
}
action reset {
input {
leaf delay {
type uint32;
}
}
output {
leaf result {
type string;
}
}
}
}
}
notification failure {
leaf b-ref {
type leafref {
path "/a/b/id";
}
}
}
}
Bjorklund Standards Track [Page 52]
RFC 7950 YANG 1.1 August 2016
and given the following data tree, specified in XML:
そして、XMLで指定された次のデータツリーが与えられます：
<a xmlns="urn:example:a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
</b>
</a>
The accessible tree for a notification "down" on /a/b[id="2"] is:
/a/b[id="2"]の「ダウン」通知のアクセス可能なツリーは次のとおりです。
<a xmlns="urn:example:a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
<down>
<reason>error</reason>
</down>
</b>
</a>
// possibly other top-level nodes here
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "when" parameter set to "10" would be:
/a/b[id="1"]の "reset"のアクション呼び出しのアクセス可能なツリーは、 "when"パラメータが "10"に設定されています。
<a xmlns="urn:example:a">
<b>
<id>1</id>
<reset>
<delay>10</delay>
</reset>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here
Bjorklund Standards Track [Page 53]
RFC 7950 YANG 1.1 August 2016
The accessible tree for the action output of this action is:
このアクションのアクション出力のアクセス可能なツリーは次のとおりです。
<a xmlns="urn:example:a">
<b>
<id>1</id>
<reset>
<result>ok</result>
</reset>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here
The accessible tree for a notification "failure" could be:
通知「失敗」のアクセス可能なツリーは次のとおりです。
<a xmlns="urn:example:a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
</b>
</a>
<failure>
<b-ref>2</b-ref>
</failure>
// possibly other top-level nodes here
6.5. Schema Node Identifier
6.5。 スキーマノード識別子
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 14, 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 an imported
module.
スキーマノード識別子は、スキーマツリー内のノードを識別する文字列です。 セクション14の規則「absolute-schema-nodeid」と「descendant-schema-nodeid」でそれぞれ定義されている「absolute」と「descendant」の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"を使用できます。
Bjorklund Standards Track [Page 54] RFC 7950 YANG 1.1 August 2016 7. YANG Statements
7. YANGステートメント
The following sections describe all of the YANG statements.
次のセクションでは、すべてのYANGステートメントについて説明します。
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:
YANGでサブステートメントが定義されていないステートメントでも、ベンダー固有の拡張機能をサブステートメントとして使用できることに注意してください。 たとえば、「description」ステートメントには、YANGで定義されたサブステートメントはありませんが、以下は有効です：
description "Some text." {
ex:documentation-flag 5;
}
7.1. The "module" Statement
7.1。 「モジュール」ステートメント
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 holds detailed module information. The module name is an identifier (see Section 6.2).
「モジュール」ステートメントは、モジュールの名前を定義し、モジュールに属するすべてのステートメントをグループ化します。 「モジュール」ステートメントの引数は、モジュールの名前であり、その後に詳細なモジュール情報を保持するサブステートメントのブロックが続きます。 モジュール名は識別子です（セクション6.2を参照）。
Names of modules published in RFC streams [RFC4844] MUST be assigned by IANA; see Section 14 in [RFC6020].
RFCストリーム[RFC4844]で公開されているモジュールの名前は、IANAによって割り当てられる必要があります。 [RFC6020]のセクション14を参照してください。
Private module names are assigned by the organization owning the module without a central registry. See Section 5.1 for recommendations on how to name modules.
プライベートモジュール名は、中央レジストリのないモジュールを所有する組織によって割り当てられます。 モジュールの命名方法に関する推奨事項については、セクション5.1を参照してください。
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>
Bjorklund Standards Track [Page 55]
RFC 7950 YANG 1.1 August 2016
// revision history
<revision statements>
// module definitions
<other statements>
}
7.1.1. The module's Substatements
7.1.1。 モジュールのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| augment | 7.17 | 0..n |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| deviation | 7.20.3 | 0..n |
| extension | 7.19 | 0..n |
| feature | 7.20.1 | 0..n |
| grouping | 7.12 | 0..n |
| identity | 7.18 | 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.16 | 0..n |
| organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 |
| reference | 7.21.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.14 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
| yang-version | 7.1.2 | 1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 56]
RFC 7950 YANG 1.1 August 2016
7.1.2. The "yang-version" Statement
7.1.2。 「yangバージョン」ステートメント
The "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument is a string. It MUST contain the value "1.1" for YANG modules defined based on this specification.
「yang-version」ステートメントは、モジュールの開発に使用されたYANG言語のバージョンを指定します。 ステートメントの引数は文字列です。 この仕様に基づいて定義されたYANGモジュールの値「1.1」を含める必要があります。
A module or submodule that doesn't contain the "yang-version" statement, or one that contains the value "1", is developed for YANG version 1, defined in [RFC6020].
「yang-version」ステートメントを含まないモジュールまたはサブモジュール、または値「1」を含むものは、[RFC6020]で定義されているYANGバージョン1用に開発されています。
Handling of the "yang-version" statement for versions other than "1.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.1」（ここで定義されているバージョン）以外のバージョンの「yang-version」ステートメントの処理は、この仕様の範囲外です。 より高いバージョンを定義するドキュメントは、そのようなより高いバージョンの下位互換性を定義する必要があります。
For compatibility between YANG versions 1 and 1.1, see Section 12.
YANGバージョン1と1.1の互換性については、セクション12を参照してください。
7.1.3. The "namespace" Statement
7.1.3。 「名前空間」ステートメント
The "namespace" statement defines the XML namespace that all identifiers defined by the module are qualified by in the XML encoding, with the exception of identifiers for data nodes, action nodes, and notification nodes defined inside a grouping (see Section 7.13 for details). The argument to the "namespace" statement is the URI of the namespace.
「namespace」ステートメントは、モジュールによって定義されたすべての識別子がXMLエンコーディングで修飾されるXML名前空間を定義します。ただし、グループ内で定義されたデータノード、アクションノード、通知ノードの識別子は除きます（詳細については、セクション7.13を参照） 。 「namespace」ステートメントの引数は、名前空間のURIです。
See also Section 5.3.
セクション5.3も参照してください。
7.1.4. The "prefix" Statement
7.1.4。 「プレフィックス」ステートメント
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 with the module to refer to definitions contained in the module, e.g., "if:ifName". A prefix is an identifier (see Section 6.2).
「prefix」ステートメントは、モジュールとその名前空間に関連付けられたプレフィックスを定義するために使用されます。 「prefix」ステートメントの引数は、モジュールにアクセスするためのプレフィックスとして使用されるプレフィックス文字列です。 プレフィックス文字列は、モジュールに含まれている定義を参照するためにモジュールで使用される場合があります（例： "if：ifName"）。 接頭辞は識別子です（セクション6.2を参照）。
When used inside the "module" statement, the "prefix" statement defines the prefix suggested 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 uses prefixes SHOULD use the prefix defined by the module as the XML namespace prefix, unless there is a conflict.
NETCONF XMLの読みやすさを向上させるために、プレフィックスを使用するXMLまたはXPathを生成するNETCONFクライアントまたはサーバーは、競合がない限り、モジュールによって定義されたプレフィックスをXML名前空間プレフィックスとして使用する必要があります（SHOULD）。
Bjorklund Standards Track [Page 57]
RFC 7950 YANG 1.1 August 2016
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 followed by
a colon (":") and the identifier is used, 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.
「インポート」ステートメント内で使用される場合、「プレフィックス」ステートメントは、インポートされたモジュール内の定義にアクセスするときに使用されるプレフィックスを定義します。 インポートされたモジュールからの識別子への参照が使用される場合、インポートされたモジュールの接頭辞文字列の後にコロン（ "："）と識別子が使用されます（例： "if：ifIndex"）。 YANGモジュールの読みやすさを向上させるために、競合がない限り、モジュールのインポート時にモジュールで定義されたプレフィックスを使用する必要があります（SHOULD）。 競合がある場合、つまり、両方とも同じプレフィックスを定義している2つの異なるモジュールがインポートされる場合、少なくとも1つは異なるプレフィックスでインポートする必要があります。
All prefixes, including the prefix for the module itself, MUST be unique within the module or submodule.
モジュール自体のプレフィックスを含むすべてのプレフィックスは、モジュールまたはサブモジュール内で一意である必要があります。
7.1.5. The "import" Statement
7.1.5。 「インポート」ステートメント
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.
インポートされたモジュールまたはそのサブモジュールの最上位で定義されているグループ化とtypedefを使用します。
o use any extension, feature, and identity defined in the imported
module or its submodules.
インポートされたモジュールまたはそのサブモジュールで定義されている拡張機能、機能、および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.
インポートされたモジュールのスキーマツリー内の任意のノードを「must」、「path」、および「when」ステートメントで使用するか、「augment」および「deviation」ステートメントでターゲットノードとして使用します。
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.
オプションの "revision-date"サブステートメントが存在する場合、ローカルモジュールの定義によって参照されるtypedef、グループ化、拡張、機能、およびIDは、インポートされたモジュールの指定されたリビジョンから取得されます。 インポートされたモジュールの指定されたリビジョンが存在しない場合はエラーになります。 「revision-date」サブステートメントが存在しない場合、それらが取得されるモジュールのリビジョンからは未定義です。
Multiple revisions of the same module can be imported, provided that different prefixes are used.
異なる接頭辞が使用されている場合、同じモジュールの複数のリビジョンをインポートできます。
Bjorklund Standards Track [Page 58]
RFC 7950 YANG 1.1 August 2016
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| prefix | 7.1.4 | 1 |
| reference | 7.21.4 | 0..1 |
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The import's Substatements
7.1.5.1. The import's "revision-date" Statement
7.1.5.1。 インポートの「改訂日」ステートメント
The import's "revision-date" statement is used to specify the version of the module to import.
インポートの「改訂日」ステートメントは、インポートするモジュールのバージョンを指定するために使用されます。
7.1.6. The "include" Statement
7.1.6。 「include」ステートメント
The "include" statement is used to make content from a submodule available to that submodule's 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).
「include」ステートメントは、サブモジュールのコンテンツをそのサブモジュールの親モジュールで使用できるようにするために使用されます。 引数は、含めるサブモジュールの名前である識別子です。 モジュールには、「belongs-to」ステートメントで定義されているように、そのモジュールに属するサブモジュールのみを含めることができます（セクション7.2.2を参照）。
When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module.
モジュールにサブモジュールが含まれている場合、サブモジュールのコンテンツがモジュールのノード階層に組み込まれます。
For backward compatibility with YANG version 1, a submodule is allowed to include another submodule belonging to the same module, but this is not necessary in YANG version 1.1 (see Section 5.1).
YANGバージョン1との下位互換性のために、サブモジュールは同じモジュールに属する別のサブモジュールを含めることができますが、これはYANGバージョン1.1では必要ありません（セクション5.1を参照）。
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.
オプションの "revision-date"サブステートメントが存在する場合、指定されたサブモジュールのリビジョンがモジュールに含まれます。 サブモジュールの指定されたリビジョンが存在しない場合はエラーになります。 「改訂日」サブステートメントが存在しない場合、サブモジュールのどのリビジョンが含まれるかは未定義です。
Multiple revisions of the same submodule MUST NOT be included.
同じサブモジュールの複数のリビジョンを含めることはできません。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The includes's Substatements
Bjorklund Standards Track [Page 59]
RFC 7950 YANG 1.1 August 2016
7.1.7. The "organization" Statement
7.1.7。 「組織」声明
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.
「組織」ステートメントは、このモジュールの責任者を定義します。 引数は、このモジュールが開発された組織の下で組織のテキストによる説明を指定するために使用される文字列です。
7.1.8. The "contact" Statement
7.1.8。 「連絡」ステートメント
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.
「連絡先」ステートメントは、モジュールの連絡先情報を提供します。 引数は、名前、住所、電話番号、電子メールアドレスなど、このモジュールに関する技術的なクエリの送信先の連絡先情報を指定するために使用される文字列です。
7.1.9. The "revision" Statement
7.1.9。 「改訂」ステートメント
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 "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つの「改訂」ステートメントが必要です（SHOULD）。 公開された編集上の変更ごとに、新しいものをリビジョンシーケンスの前に追加して、すべてのリビジョンが新しい順になるようにする必要があります。
7.1.9.1. The revision's Substatements
7.1.9.1。 改訂のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 60]
RFC 7950 YANG 1.1 August 2016
7.1.10. Usage Example
7.1.10。 使用例
The following example relies on [RFC6991].
次の例は、[RFC6991]に依存しています。
module example-system {
yang-version 1.1;
namespace "urn:example:system";
prefix "sys";
import ietf-yang-types {
prefix "yang";
reference "RFC 6991: Common YANG Data Types";
}
include example-types;
organization "Example Inc.";
contact
"Joe L. User
Example Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100
Email: joe@example.com";
description
"The module for entities implementing the Example system.";
revision 2007-06-09 {
description "Initial revision.";
}
// definitions follow...
}
Bjorklund Standards Track [Page 61]
RFC 7950 YANG 1.1 August 2016
7.2. The "submodule" Statement
7.2。 「サブモジュール」ステートメント
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 it 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 holds detailed submodule information. The submodule name is an identifier (see Section 6.2).
「サブモジュール」ステートメントはサブモジュールの名前を定義し、サブモジュールに属するすべてのステートメントをグループ化します。 「サブモジュール」ステートメントの引数は、サブモジュールの名前であり、その後に詳細なサブモジュール情報を保持するサブステートメントのブロックが続きます。 サブモジュール名は識別子です（セクション6.2を参照）。
Names of submodules published in RFC streams [RFC4844] MUST be assigned by IANA; see Section 14 in [RFC6020].
RFCストリーム[RFC4844]で公開されているサブモジュールの名前は、IANAによって割り当てられる必要があります。 [RFC6020]のセクション14を参照してください。
Private submodule names are assigned by the organization owning the submodule without a central registry. See Section 5.1 for recommendations on how to name submodules.
プライベートサブモジュール名は、中央レジストリのないサブモジュールを所有する組織によって割り当てられます。 サブモジュールの命名方法に関する推奨事項については、セクション5.1を参照してください。
A submodule typically has the following layout:
サブモジュールは通常、次のレイアウトになっています。
submodule <module-name> {
<yang-version statement>
// module identification
<belongs-to statement>
// linkage statements
<import statements>
// meta-information
<organization statement>
<contact statement>
<description statement>
<reference statement>
// revision history
<revision statements>
// module definitions
<other statements>
}
Bjorklund Standards Track [Page 62]
RFC 7950 YANG 1.1 August 2016
7.2.1. The submodule's Substatements
7.2.1。 サブモジュールのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| augment | 7.17 | 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.21.3 | 0..1 |
| deviation | 7.20.3 | 0..n |
| extension | 7.19 | 0..n |
| feature | 7.20.1 | 0..n |
| grouping | 7.12 | 0..n |
| identity | 7.18 | 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.16 | 0..n |
| organization | 7.1.7 | 0..1 |
| reference | 7.21.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.14 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
| yang-version | 7.1.2 | 1 |
+--------------+---------+-------------+
7.2.2. The "belongs-to" Statement
7.2.2。 「所属」ステートメント
The "belongs-to" statement specifies the module to which the submodule belongs. The argument is an identifier that is the name of the module.
「belongs-to」ステートメントは、サブモジュールが属するモジュールを指定します。 引数は、モジュールの名前である識別子です。
A submodule MUST only be included by either the module to which it belongs or 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 module that the submodule belongs to and all its submodules can be accessed by using the prefix.
必須の「プレフィックス」サブステートメントは、サブモジュールが属するモジュールのプレフィックスを割り当てます。 サブモジュールが属するモジュール内のすべての定義とそのすべてのサブモジュールには、プレフィックスを使用してアクセスできます。
Bjorklund Standards Track [Page 63]
RFC 7950 YANG 1.1 August 2016
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| prefix | 7.1.4 | 1 |
+--------------+---------+-------------+
The belongs-to's Substatement
7.2.3. Usage Example
7.2.3。 使用例
submodule example-types {
yang-version 1.1;
belongs-to "example-system" {
prefix "sys";
}
import ietf-yang-types {
prefix "yang";
}
organization "Example Inc.";
contact
"Joe L. User
Example Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100
Email: joe@example.com";
description
"This submodule defines common Example types.";
revision "2007-06-09" {
description "Initial revision.";
}
// definitions follow...
}
Bjorklund Standards Track [Page 64]
RFC 7950 YANG 1.1 August 2016
7.3. The "typedef" Statement
7.3。 「typedef」ステートメント
The "typedef" statement defines a new type that may be used locally in the module or submodule, 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のルールに従って、モジュールまたはサブモジュールでローカルに、およびそこからインポートする他のモジュールで使用できる新しいタイプを定義します。 新しい型は「派生型」と呼ばれ、派生元の型は「基本型」と呼ばれます。 すべての派生型は、YANG組み込み型までさかのぼることができます。
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モジュールまたはサブモジュールのトップレベルで定義されている場合、定義されるタイプの名前はモジュール内で一意である必要があります。
7.3.1. The typedef's Substatements
7.3.1。 typedefのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| default | 7.3.4 | 0..1 |
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| type | 7.3.2 | 1 |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
7.3.2. The typedef's "type" Statement
7.3.2。 typedefの「type」ステートメント
The "type" statement, which MUST be present, defines the base type from which this type is derived. See Section 7.4 for details.
「type」ステートメントは必ず存在しなければならず、このタイプの派生元となる基本タイプを定義します。 詳細はセクション7.4を参照してください。
7.3.3. The "units" Statement
7.3.3。 「ユニット」ステートメント
The "units" statement, which is optional, takes as an argument a string that contains a textual definition of the units associated with the type.
オプションの「units」ステートメントは、型に関連付けられた単位のテキストによる定義を含む文字列を引数として受け取ります。
Bjorklund Standards Track [Page 65] RFC 7950 YANG 1.1 August 2016 7.3.4. The typedef's "default" Statement
7.3.4。 typedefの「デフォルト」ステートメント
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.
タイプのデフォルト値が、派生タイプまたはリーフ定義で指定された新しい制限に従って有効でない場合、派生タイプまたはリーフ定義は、制限と互換性のある新しいデフォルト値を指定する必要があります。
7.3.5. Usage Example
7.3.5。 使用例
typedef listen-ipv4-address {
type inet:ipv4-address;
default "0.0.0.0";
}
7.4. The "type" Statement
7.4。 「タイプ」ステートメント
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 is used to put further restrictions on the type.
「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のサブセクションで説明しています。
Bjorklund Standards Track [Page 66] RFC 7950 YANG 1.1 August 2016 7.4.1. The type's Substatements
7.4.1。 タイプのサブステートメント
+------------------+---------+-------------+
| substatement | section | cardinality |
+------------------+---------+-------------+
| base | 7.18.2 | 0..n |
| bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n |
| fraction-digits | 9.3.4 | 0..1 |
| length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 |
| pattern | 9.4.5 | 0..n |
| range | 9.2.4 | 0..1 |
| require-instance | 9.9.3 | 0..1 |
| type | 7.4 | 0..n |
+------------------+---------+-------------+
7.5. The "container" Statement
7.5。 「コンテナ」ステートメント
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.
「container」ステートメントは、スキーマツリーの内部データノードを定義するために使用されます。 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.
コンテナノードには値はありませんが、データツリー内に子ノードのリストがあります。 子ノードは、コンテナのサブステートメントで定義されます。
7.5.1. Containers with Presence
7.5.1。 存在感のあるコンテナ
YANG supports two styles of containers, those that exist only for organizing the hierarchy of data nodes and those whose presence in the data tree has an explicit meaning.
YANGは、データノードの階層を編成するためにのみ存在するコンテナと、データツリー内での存在が明確な意味を持つコンテナの2つのスタイルをサポートしています。
In the first style, the container has no meaning of its own, existing only to contain child nodes. In particular, the presence of the container node with no child nodes is semantically equivalent to the absence of the container node. YANG calls this style a "non-presence container". This is the default style.
最初のスタイルでは、コンテナはそれ自体には意味がなく、子ノードを含むためだけに存在します。 特に、子ノードのないコンテナノードの存在は、意味的にはコンテナノードの不在と同等です。 YANGはこのスタイルを「非存在コンテナ」と呼んでいます。 これがデフォルトのスタイルです。
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）インターフェイスのスクランブルオプションのセットを「スクランブル」コンテナ内に配置して、構成階層の編成を強化し、これらのノードをまとめて維持することができます。 「スクランブル」ノード自体には意味がないため、ノードが空になったときにノードを削除しても、ユーザーはこのタスクを実行する必要がありません。
Bjorklund Standards Track [Page 67] RFC 7950 YANG 1.1 August 2016 In the second style, the presence of the container itself carries some meaning, representing a single bit of data.
2番目のスタイルでは、コンテナー自体の存在がデータの1ビットを表すという意味があります。
For configuration data, the container acts as both a configuration knob and a means of organizing related configuration nodes. These containers are explicitly created and deleted.
構成データの場合、コンテナーは構成ノブと、関連する構成ノードを編成する手段の両方として機能します。 これらのコンテナは明示的に作成および削除されます。
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 server using Secure SHell (SSH) but can also contain any SSH-related configuration knobs, such as connection rates or retry limits.
たとえば、「ssh」コンテナは、Secure SHell（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を参照）は、データツリー内のコンテナの存在に意味を与えるために使用されます。
7.5.2. The container's Substatements
7.5.2。 コンテナのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| action | 7.15 | 0..n |
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.21.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| if-feature | 7.20.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 |
| notification | 7.16 | 0..n |
| presence | 7.5.5 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 68]
RFC 7950 YANG 1.1 August 2016
7.5.3. The "must" Statement
7.5.3。 「必須」ステートメント
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 node in the accessible tree (see Section 6.4.1).
データストアが検証されると、すべての「必須」制約は、アクセス可能なツリーのノードごとに1回概念的に評価されます（セクション6.4.1を参照）。
All such constraints MUST evaluate to "true" for the data to be valid.
そのような制約はすべて、データが有効であるために「真」と評価されなければなりません。
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 "must" statement is a substatement of a "notification"
statement, the context node is the node representing the
notification in the accessible tree.
「必須」ステートメントが「通知」ステートメントのサブステートメントである場合、コンテキストノードは、アクセス可能なツリーで通知を表すノードです。
o If the "must" statement is a substatement of an "input" statement,
the context node is the node representing the operation in the
accessible tree.
「必須」ステートメントが「入力」ステートメントのサブステートメントである場合、コンテキストノードは、アクセス可能なツリー内の操作を表すノードです。
o If the "must" statement is a substatement of an "output"
statement, the context node is the node representing the operation
in the accessible tree.
「必須」ステートメントが「出力」ステートメントのサブステートメントである場合、コンテキストノードは、アクセス可能なツリー内の操作を表すノードです。
o Otherwise, the context node is the node in the accessible tree for
which the "must" statement is defined.
それ以外の場合、コンテキストノードは、「必須」ステートメントが定義されているアクセス可能なツリー内のノードです。
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 Section 9.1), any XPath comparisons are done on the canonical value.
データツリー内のすべてのリーフ値は概念的には正規形で格納されるため（セクション9.1を参照）、XPathの比較はすべて正規値に対して行われることに注意してください。
Also note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator in the server. How the evaluation is done in practice is an implementation decision.
また、XPath式は概念的に評価されることに注意してください。 これは、実装がサーバーでXPathエバリュエーターを使用する必要がないことを意味します。 評価が実際にどのように行われるかは、実装の決定です。
Bjorklund Standards Track [Page 69] RFC 7950 YANG 1.1 August 2016 7.5.4. The must's Substatements
7.5.4。 マストのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+
7.5.4.1. The "error-message" Statement
7.5.4.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> in NETCONF.
オプションの「error-message」ステートメントは、引数として文字列を取ります。 制約が「false」と評価された場合、文字列はNETCONFの<rpc-error>で<error-message>として渡されます。
7.5.4.2. The "error-app-tag" Statement
7.5.4.2。 「error-app-tag」ステートメント
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> in NETCONF.
「error-app-tag」ステートメントはオプションであり、ストリングを引数として取ります。 制約が「false」と評価された場合、文字列はNETCONFの<rpc-error>で<error-app-tag>として渡されます。
7.5.4.3. Usage Example of must and error-message
7.5.4.3。 mustとerror-messageの使用例
container interface {
leaf ifType {
type enumeration {
enum ethernet;
enum atm;
}
}
leaf ifMTU {
type uint32;
}
must 'ifType != "ethernet" or ifMTU = 1500' {
error-message "An Ethernet MTU must be 1500";
}
must 'ifType != "atm" or'
+ ' (ifMTU <= 17966 and ifMTU >= 64)' {
error-message "An ATM MTU must be 64 .. 17966";
}
}
Bjorklund Standards Track [Page 70]
RFC 7950 YANG 1.1 August 2016
7.5.5. The "presence" Statement
7.5.5。 「プレゼンス」ステートメント
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を参照してください。
7.5.6. The container's Child Node Statements
7.5.6。 コンテナの子ノードステートメント
Within a container, the "container", "leaf", "list", "leaf-list", "uses", "choice", "anydata", and "anyxml" statements can be used to define child nodes to the container.
コンテナ内では、「container」、「leaf」、「list」、「leaf-list」、「uses」、「choice」、「anydata」、および「anyxml」ステートメントを使用して、コンテナに子ノードを定義できます。 。
7.5.7. XML Encoding Rules
7.5.7。 XMLエンコーディングルール
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 or action 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またはアクションの入力または出力パラメーターを定義する場合、これらのサブエレメントは、「コンテナー」ステートメント内で定義されているのと同じ順序でエンコードされます。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
Any whitespace between the subelements to the container is insignificant, i.e., an implementation MAY insert whitespace characters between subelements.
コンテナのサブ要素間の空白は重要ではありません。つまり、実装はサブ要素間に空白文字を挿入できます（MAY）。
If a non-presence container does not have any child nodes, the container may or may not be present in the XML encoding.
非プレゼンスコンテナに子ノードがない場合、コンテナはXMLエンコーディングに存在する場合と存在しない場合があります。
Bjorklund Standards Track [Page 71] RFC 7950 YANG 1.1 August 2016 7.5.8. NETCONF <edit-config> Operations
7.5.8。 NETCONF <edit-config>操作
Containers can be created, deleted, replaced, and modified through <edit-config> by using the "operation" attribute (see Section 7.2 in [RFC6241]) in the container's XML element.
コンテナーは、コンテナーのXML要素で「操作」属性（[RFC6241]のセクション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サーバーはコンテナーを削除できます（MAY）。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the container node are as follows:
NETCONFサーバーが<edit-config>リクエストを処理する場合、コンテナーノードの手順の要素は次のとおりです。
o If the operation is "merge" or "replace", the node is created if
it does not exist.
操作が「マージ」または「置換」の場合、ノードが存在しなければ作成されます。
o 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.
操作が「作成」の場合、ノードが存在しなければ作成されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
o If the operation is "delete", the node is deleted if it exists.
If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在すると削除されます。 ノードが存在しない場合、「データ欠落」エラーが返されます。
7.5.9. Usage Example
7.5.9。 使用例
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...
}
}
}
Bjorklund Standards Track [Page 72]
RFC 7950 YANG 1.1 August 2016
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="urn:example:config">
<services>
<ssh nc:operation="delete"/>
</services>
</system>
</config>
</edit-config>
</rpc>
7.6. The "leaf" Statement
7.6 「リーフ」ステートメント
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 instance in the data tree.
リーフノードは、データツリーの0または1つのインスタンスに存在します。
The "leaf" statement is used to define a scalar variable of a particular built-in or derived type.
「リーフ」ステートメントは、特定の組み込み型または派生型のスカラー変数を定義するために使用されます。
Bjorklund Standards Track [Page 73] RFC 7950 YANG 1.1 August 2016 7.6.1. The leaf's Default Value
7.6.1。 葉のデフォルト値
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 (see Section 7.5.1):
葉のデフォルト値は、葉がデータツリーに存在しない場合にサーバーが使用する値です。 デフォルト値の使用は、存在しないコンテナではないスキーマツリー内のリーフの最も近い祖先ノードに依存します（セクション7.5.1を参照）。
o If no such ancestor exists in the schema tree, the default value
MUST be used.
そのような祖先がスキーマツリーに存在しない場合は、デフォルト値を使用する必要があります。
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 the
case node is the choice's default case, and if no nodes from any
other case exist in the data tree.
それ以外の場合、この祖先がケースノードの場合、ケースのノードがデータツリーに存在するかケースノードが選択肢のデフォルトケースであり、他のケースのノードがデータツリーに存在しない場合は、デフォルト値を使用する必要があります。 。
o Otherwise, the default value MUST be used if the ancestor node
exists in the data tree.
それ以外の場合、祖先ノードがデータツリーに存在する場合は、デフォルト値を使用する必要があります。
In these cases, the default value is said to be in use.
これらの場合、デフォルト値が使用中であると言われます。
Note that if the leaf or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default value is not in use.
リーフまたはその祖先に「when」条件または「false」と評価される「if-feature」式がある場合、デフォルト値は使用されないことに注意してください。
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.
リーフに「デフォルト」ステートメントがある場合、リーフのデフォルト値は「デフォルト」ステートメントの値です。 それ以外の場合、リーフのタイプにデフォルト値があり、リーフが必須ではない場合、リーフのデフォルト値はタイプのデフォルト値です。 他のすべての場合、リーフにはデフォルト値がありません。
Bjorklund Standards Track [Page 74] RFC 7950 YANG 1.1 August 2016 7.6.2. The leaf's Substatements
7.6.2。 葉のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.21.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.6.3. The leaf's "type" Statement
7.6.3。 葉の「タイプ」ステートメント
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.
「type」ステートメントは必ず存在しなければならず、既存の組み込み型または派生型の名前を引数として取ります。 オプションのサブステートメントは、このタイプの制限を指定します。 詳細はセクション7.4を参照してください。
7.6.4. The leaf's "default" Statement
7.6.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.
「デフォルト」ステートメントの値は、リーフの「タイプ」ステートメントで指定されたタイプに従って有効でなければなりません。
The "default" statement MUST NOT be present on nodes where "mandatory" is "true".
「デフォルト」ステートメントは、「必須」が「true」であるノードに存在してはなりません（MUST NOT）。
The definition of the default value MUST NOT be marked with an "if-feature" statement. For example, the following is illegal:
デフォルト値の定義は、「if-feature」ステートメントでマークしてはなりません。 たとえば、以下は不正です。
leaf color {
type enumeration {
enum blue { if-feature blue; }
...
}
default blue; // illegal - enum value is conditional
}
Bjorklund Standards Track [Page 75]
RFC 7950 YANG 1.1 August 2016
7.6.5. The leaf's "mandatory" Statement
7.6.5。 リーフの「必須」ステートメント
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".
オプションの「必須」ステートメントは、ストリング「true」または「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):
「必須」が「true」の場合、制約の動作は、非存在コンテナではないスキーマツリー内のリーフの最も近い祖先ノードのタイプに依存します（セクション7.5.1を参照）。
o If no such ancestor exists in the schema tree, the leaf MUST
exist.
そのような祖先がスキーマツリーに存在しない場合、リーフが存在する必要があります。
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 Otherwise, the leaf MUST exist if the ancestor node exists in the
data tree.
それ以外の場合、祖先ノードがデータツリーに存在する場合、リーフが存在する必要があります。
This constraint is enforced according to the rules in Section 8.
この制約は、セクション8のルールに従って実施されます。
7.6.6. XML Encoding Rules
7.6.6。 XMLエンコーディングルール
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 is sent as character data in the element.
リーフノードの値は、タイプに従ってXMLにエンコードされ、要素内の文字データとして送信されます。
See Section 7.6.8 for an example.
例については、セクション7.6.8を参照してください。
7.6.7. NETCONF <edit-config> Operations
7.6.7。 NETCONF <edit-config>操作
When a NETCONF server processes an <edit-config> request, the elements of procedure for the leaf node are as follows:
NETCONFサーバーが<edit-config>要求を処理するとき、リーフノードの手順の要素は次のとおりです。
o 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データで見つかった値に設定されます。
o 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.
操作が「作成」の場合、ノードが存在しなければ作成されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
o If the operation is "delete", the node is deleted if it exists.
If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在すると削除されます。 ノードが存在しない場合、「データ欠落」エラーが返されます。
Bjorklund Standards Track [Page 76] RFC 7950 YANG 1.1 August 2016 7.6.8. Usage Example
7.6.8。 使用例
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="urn:example:config">
<services>
<ssh>
<port>2022</port>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
7.7. The "leaf-list" Statement
7.7。 「リーフリスト」ステートメント
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.
「leaf」ステートメントを使用して特定のタイプの単純なスカラー変数を定義する場合、「leaf-list」ステートメントを使用して特定のタイプの配列を定義します。 「リーフリスト」ステートメントは、1つの引数（識別子）を取り、その後に詳細なリーフリスト情報を保持するサブステートメントのブロックが続きます。
In configuration data, the values in a leaf-list MUST be unique.
構成データでは、リーフリストの値は一意である必要があります。
Bjorklund Standards Track [Page 77] RFC 7950 YANG 1.1 August 2016 The definitions of the default values MUST NOT be marked with an "if-feature" statement.
デフォルト値の定義は、「if-feature」ステートメントでマークしてはなりません。
Conceptually, the values in the data tree MUST be in the canonical form (see Section 9.1).
概念的には、データツリーの値は標準的な形式でなければなりません（セクション9.1を参照）。
7.7.1. Ordering
7.7.1。 注文
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 server is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order to the server implementor. YANG calls this style of list "system ordered"; such lists are indicated with the statement "ordered-by system".
YANGは、リストおよびリーフリスト内のエントリの順序付けに2つのスタイルをサポートしています。 多くのリストでは、リストエントリの順序はリストの構成の実装に影響を与えず、サーバーはリストエントリを適切な順序で自由にソートできます。 リストの「説明」文字列は、サーバーの実装者に注文を示唆する場合があります。 YANGはこのスタイルのリストを「システム注文」と呼んでいます。 このようなリストは、「ordered-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 server maintains that order. YANG calls this style of list "user ordered"; such lists are indicated with the statement "ordered-by user".
他のスタイルのリストでは、リストエントリの順序はリストの構成の実装にとって重要であり、サーバーがその順序を維持しながら、ユーザーはエントリの順序付けを担当します。 YANGはこのスタイルのリストを「ユーザー注文」と呼んでいます。 そのようなリストは、「ordered-by user」というステートメントで示されます。
For example, the order in which packet filter 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.7.
「ordered-by」ステートメントについては、セクション7.7.7で説明しています。
Bjorklund Standards Track [Page 78] RFC 7950 YANG 1.1 August 2016 7.7.2. The leaf-list's Default Values
7.7.2。 リーフリストのデフォルト値
The default values of a leaf-list are the values that the server uses if the leaf-list does not exist in the data tree. The usage of the default values depends on the leaf-list'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 default values
MUST be used.
そのような祖先がスキーマツリーに存在しない場合は、デフォルト値を使用する必要があります。
o Otherwise, if this ancestor is a case node, the default values
MUST be used if any node from the case exists in the data tree or
the case node is the choice's default case, and if no nodes from
any other case exist in the data tree.
それ以外の場合、この祖先がケースノードである場合、ケースのいずれかのノードがデータツリーに存在するか、ケースノードが選択肢のデフォルトケースであり、他のケースのノードがデータツリーに存在しない場合、デフォルト値を使用する必要があります。 。
o Otherwise, the default values MUST be used if the ancestor node
exists in the data tree.
それ以外の場合、祖先ノードがデータツリーに存在する場合は、デフォルト値を使用する必要があります。
In these cases, the default values are said to be in use.
これらの場合、デフォルト値が使用中であると言われます。
Note that if the leaf-list or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default values are not in use.
リーフリストまたはその祖先に「when」条件または「false」と評価される「if-feature」式がある場合、デフォルト値は使用されないことに注意してください。
When the default values are in use, the server MUST operationally behave as if the leaf-list was present in the data tree with the default values as its values.
デフォルト値が使用されている場合、サーバーは、デフォルト値を値として持つリーフリストがデータツリーに存在するかのように動作する必要があります。
If a leaf-list has one or more "default" statements, the leaf-list's default values are the values of the "default" statements, and if the leaf-list is user ordered, the default values are used in the order of the "default" statements. Otherwise, if the leaf-list's type has a default value and the leaf-list does not have a "min-elements" statement with a value greater than or equal to one, then the leaf-list's default value is one instance of the type's default value. In all other cases, the leaf-list does not have any default values.
リーフリストに1つ以上の「デフォルト」ステートメントがある場合、リーフリストのデフォルト値は「デフォルト」ステートメントの値であり、リーフリストがユーザー順の場合、デフォルト値は 「デフォルト」ステートメント。 それ以外の場合、リーフリストのタイプにデフォルト値があり、リーフリストに1以上の「min-elements」ステートメントがない場合、リーフリストのデフォルト値はタイプのインスタンスの1つのインスタンスです。 デフォルト値。 他のすべての場合、リーフリストにはデフォルト値がありません。
Bjorklund Standards Track [Page 79] RFC 7950 YANG 1.1 August 2016 7.7.3. The leaf-list's Substatements
7.7.3。 リーフリストのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.21.1 | 0..1 |
| default | 7.7.4 | 0..n |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.7 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| type | 7.4 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.7.4. The leaf-list's "default" Statement
7.7.4。 リーフリストの「デフォルト」ステートメント
The "default" statement, which is optional, takes as an argument a string that contains a default value for the leaf-list.
オプションの「デフォルト」ステートメントは、リーフリストのデフォルト値を含む文字列を引数として受け取ります。
The value of the "default" statement MUST be valid according to the type specified in the leaf-list's "type" statement.
「デフォルト」ステートメントの値は、リーフリストの「タイプ」ステートメントで指定されたタイプに従って有効でなければなりません。
The "default" statement MUST NOT be present on nodes where "min-elements" has a value greater than or equal to one.
「デフォルト」ステートメントは、「min-elements」が1以上の値を持つノードに存在してはなりません（MUST NOT）。
7.7.5. The "min-elements" Statement
7.7.5。 「min-elements」ステートメント
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」ステートメントは、有効なリストエントリに制約を課す負でない整数を引数として取ります。 有効なリーフリストまたはリストには、少なくとも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):
制約の動作は、存在しないコンテナではないスキーマツリー内のリーフリストまたはリストの最も近い祖先ノードのタイプによって異なります（セクション7.5.1を参照）。
o If no such ancestor exists in the schema tree, the constraint is
enforced.
そのような祖先がスキーマツリーに存在しない場合、制約が適用されます。
o Otherwise, if this ancestor is a case node, the constraint is
enforced if any other node from the case exists.
それ以外の場合、この祖先がケースノードの場合、ケースの他のノードが存在する場合に制約が適用されます。
Bjorklund Standards Track [Page 80] RFC 7950 YANG 1.1 August 2016 o Otherwise, it is enforced if the ancestor node exists.
それ以外の場合は、祖先ノードが存在する場合に適用されます。
The constraint is further enforced according to the rules in Section 8.
制約は、セクション8のルールに従ってさらに適用されます。
7.7.6. The "max-elements" Statement
7.7.6。 「max-elements」ステートメント
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」を引数として取ります。 有効なリーフリストまたはリストには、常に最大でmax-elementsのエントリがあります。
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.
「max-elements」制約は、セクション8のルールに従って適用されます。
7.7.7. The "ordered-by" Statement
7.7.7。 「ordered-by」ステートメント
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, ordering defaults to "system".
「ordered-by」ステートメントは、リスト内のエントリーの順序がユーザーとシステムのどちらによって決定されるかを定義します。 引数は、文字列「system」または「user」のいずれかです。 存在しない場合、順序付けはデフォルトで「システム」になります。
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を参照してください。
7.7.7.1. ordered-by system
7.7.7.1。 注文システム
The entries in the list are ordered according to an order determined by the system. The "description" string for the list may suggest an order to the server implementor. If not, an implementation is free to order the entries in any 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".
リストのエントリは、システムによって決定された順序に従って並べられます。 リストの「説明」文字列は、サーバーの実装者に注文を示唆する場合があります。 そうでない場合、実装はエントリを任意の順序で自由に順序付けできます。 実装では、データの作成方法に関係なく、同じデータに同じ順序を使用する必要があります（SHOULD）。 確定的な順序を使用すると、「diff」などの単純なツールを使用して比較が可能になります。
This is the default order.
これがデフォルトの順序です。
7.7.7.2. ordered-by user
7.7.7.2。 注文したユーザー
The entries in the list are ordered according to an order defined by the user. In NETCONF, this order is controlled by using special XML attributes in the <edit-config> request. See Section 7.7.9 for details.
リストのエントリは、ユーザーが定義した順序に従って並べられます。 NETCONFでは、この順序は<edit-config>リクエストで特別なXML属性を使用して制御されます。 詳細については、セクション7.7.9を参照してください。
Bjorklund Standards Track [Page 81] RFC 7950 YANG 1.1 August 2016 7.7.8. XML Encoding Rules
7.7.8。 XMLエンコーディングルール
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 is 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 elements for siblings of the leaf-list, unless the leaf-list defines RPC or action input or output parameters.
リーフリストが「ordered-by user」の場合、リーフリストエントリを表すXML要素は、ユーザーが指定した順序で出現する必要があります。 それ以外の場合、順序は実装に依存します。 リーフリストがRPCまたはアクションの入力または出力パラメーターを定義していない限り、リーフリストエントリを表すXML要素は、リーフリストの兄弟の要素とインターリーブされる場合があります。
See Section 7.7.10 for an example.
例については、7.7.10項を参照してください。
7.7.9. NETCONF <edit-config> Operations
7.7.9。 NETCONF <edit-config>操作
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.
リーフリストエントリは、<edit-config>を使用して作成および削除できますが、変更はできません。リーフリストエントリのXML要素の "operation"属性を使用します。
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.
"ordered-by user"リーフリストでは、YANG XML名前空間（セクション5.3.1）の属性 "insert"および "value"を使用して、リーフリストのどこにエントリを挿入するかを制御できます。 これらは、新しいリーフリストエントリを挿入する「作成」操作、または新しいリーフリストエントリを挿入するか、既存のエントリを移動する「マージ」または「置換」操作中に使用できます。
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.
「挿入」属性は、「最初」、「最後」、「前」、および「後」の値を取ることができます。 値が「before」または「after」の場合、「value」属性を使用して、リーフリスト内の既存のエントリを指定する必要もあります。
If no "insert" attribute is present in the "create" operation, it defaults to "last".
「作成」操作に「挿入」属性が存在しない場合、デフォルトで「最後」になります。
If several entries in an "ordered-by user" leaf-list are modified in the same <edit-config> request, the entries are modified one at a time, in the order of the XML elements in the request.
「ordered-by user」リーフリストのいくつかのエントリが同じ<edit-config>リクエストで変更された場合、エントリはリクエストのXML要素の順序で一度に1つずつ変更されます。
In a <copy-config> or in 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>で、リーフリスト全体を対象とする「replace」操作では、リーフリストの順序は、リクエスト内のXML要素の順序と同じです。
Bjorklund Standards Track [Page 82] RFC 7950 YANG 1.1 August 2016 When a NETCONF server processes an <edit-config> request, the elements of procedure for a leaf-list node are as follows:
NETCONFサーバーが<edit-config>要求を処理するとき、リーフリストノードの手順の要素は次のとおりです。
o If the operation is "merge" or "replace", the leaf-list entry is
created if it does not exist.
操作が「マージ」または「置換」の場合、リーフリストエントリが存在しない場合は作成されます。
o 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.
操作が「作成」の場合、リーフリストエントリが存在しない場合は作成されます。 リーフリストエントリがすでに存在する場合、「data-exists」エラーが返されます。
o 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.
操作が「削除」の場合、エントリが存在する場合、そのエントリはリーフリストから削除されます。 リーフリストエントリが存在しない場合、「データ欠落」エラーが返されます。
7.7.10. Usage Example
7.7.10。 使用例
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>操作「merge」を使用します。
<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="urn:example:config">
<services>
<ssh>
<allow-user>eric</allow-user>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 83]
RFC 7950 YANG 1.1 August 2016
Given the following ordered-by user leaf-list:
次のordered-byユーザーリーフリストがあるとします。
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」の後に新しい暗号「blowfish-cbc」を挿入するために使用されます。
<rpc message-id="102"
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="urn:example:config">
<services>
<ssh>
<cipher nc:operation="create"
yang:insert="after"
yang:value="3des-cbc">blowfish-cbc</cipher>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
7.8. The "list" Statement
7.8。 「リスト」ステートメント
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.
「list」ステートメントは、スキーマツリーの内部データノードを定義するために使用されます。 リストノードは、データツリーの複数のインスタンスに存在する場合があります。 このような各インスタンスは、リストエントリと呼ばれます。 「リスト」ステートメントは、1つの引数（識別子）を受け取り、その後に詳細なリスト情報を保持するサブステートメントのブロックが続きます。
A list entry is uniquely identified by the values of the list's keys, if defined.
リストのエントリは、定義されている場合、リストのキーの値によって一意に識別されます。
Bjorklund Standards Track [Page 84] RFC 7950 YANG 1.1 August 2016 7.8.1. The list's Substatements
7.8.1。 リストのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| action | 7.15 | 0..n |
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.21.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| if-feature | 7.20.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.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n |
| notification | 7.16 | 0..n |
| ordered-by | 7.7.7 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n |
| uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.8.2. The list's "key" Statement
7.8.2。 リストの「キー」ステートメント
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 one or more 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.
「key」ステートメントは、リストが構成を表す場合は存在しなければならず、そうでない場合は存在する場合がありますが、このリストの1つ以上のリーフ識別子のスペース区切りリストを指定する文字列を引数として取ります。 リーフ識別子は、キーに複数回出現してはなりません。 このようなリーフ識別子はそれぞれ、リストの子リーフを参照する必要があります。 リーフは、リストのサブステートメントで直接定義することも、リストで使用されるグループで定義することもできます。
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. Any "mandatory" statements in the key leafs are ignored.
キーで指定されたすべての葉の結合値は、リストエントリを一意に識別するために使用されます。 リストエントリの作成時に、すべてのキーリーフに値を指定する必要があります。 したがって、キーリーフのデフォルト値またはそのタイプは無視されます。 キーリーフの「必須」ステートメントは無視されます。
Bjorklund Standards Track [Page 85] RFC 7950 YANG 1.1 August 2016 A leaf that is part of the key can be of any built-in or derived type.
キーの一部であるリーフは、任意の組み込み型または派生型にすることができます。
All key leafs in a list MUST have the same value for their "config" as the list itself.
リスト内のすべてのキーリーフは、リスト自体と同じ "config"の値を持つ必要があります。
The key string syntax is formally defined by the rule "key-arg" in Section 14.
キー文字列の構文は、セクション14のルール「key-arg」によって正式に定義されています。
7.8.3. The list's "unique" Statement
7.8.3。 リストの「ユニークな」ステートメント
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 14). Each such schema node identifier MUST refer to a leaf.
「ユニーク」ステートメントは、有効なリストエントリに制約を課すために使用されます。 引数として、スペースで区切られたスキーマノード識別子のリストを含む文字列を受け取ります。これは、子孫の形式で指定する必要があります（セクション14の「descendant-schema-nodeid」のルールを参照）。 このような各スキーマノード識別子はリーフを参照する必要があります。
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 or have default values. 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 14.
一意の文字列構文は、セクション14のルール「unique-arg」によって正式に定義されています。
7.8.3.1. Usage Example
7.8.3.1。 使用例
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;
}
}
Bjorklund Standards Track [Page 86]
RFC 7950 YANG 1.1 August 2016
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>
7.8.4. The list's Child Node Statements
7.8.4。 リストの子ノードステートメント
Within a list, the "container", "leaf", "list", "leaf-list", "uses", "choice", "anydata", and "anyxml" statements can be used to define child nodes to the list.
リスト内では、「container」、「leaf」、「list」、「leaf-list」、「uses」、「choice」、「anydata」、および「anyxml」ステートメントを使用して、リストに子ノードを定義できます。 。
Bjorklund Standards Track [Page 87] RFC 7950 YANG 1.1 August 2016 7.8.5. XML Encoding Rules
7.8.5. XML Encoding Rules
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). There is no XML element surrounding the list as a whole.
リストは、リスト内の各エントリに1つずつ、一連のXML要素としてエンコードされます。 各要素のローカル名はリストの識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。 リスト全体を囲むXML要素はありません。
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.
リストのキーノードは、「key」ステートメント内で定義されているのと同じ順序で、リストの識別子要素のサブ要素としてエンコードされます。
The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC or action 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またはアクションの入力または出力パラメーターを定義している場合、サブエレメントは、「list」ステートメント内で定義されているのと同じ順序でエンコードされます。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
Any whitespace between the subelements to the list entry is insignificant, i.e., an implementation MAY insert whitespace characters between subelements.
リストエントリのサブ要素間の空白は重要ではありません。つまり、実装はサブ要素間に空白文字を挿入できます（MAY）。
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 elements for siblings of the list, unless the list defines RPC or action input or output parameters.
リストが「ordered-by user」の場合、リストエントリを表すXML要素は、ユーザーが指定した順序で出現する必要があります。 それ以外の場合、順序は実装に依存します。 リストがRPCまたはアクションの入力または出力パラメーターを定義していない限り、リストエントリを表すXML要素は、リストの兄弟の要素とインターリーブされる場合があります。
7.8.6. NETCONF <edit-config> Operations
7.8.6。 NETCONF <edit-config>操作
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要素の「operation」属性を使用して、<edit-config>で作成、削除、置換、および変更できます。 いずれの場合も、すべてのキーの値を使用して、リストエントリを一意に識別します。 リストエントリにすべてのキーが指定されていない場合、「missing-element」エラーが返されます。
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.
"ordered-by user"リストでは、YANG XML名前空間（セクション5.3.1）の属性 "insert"および "key"を使用して、リストのどこにエントリを挿入するかを制御できます。 これらは、「作成」操作中に新しいリストエントリを挿入したり、「マージ」または「置換」操作中に使用して新しいリストエントリを挿入したり、既存のリストエントリを移動したりできます。
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.
「挿入」属性は、「最初」、「最後」、「前」、および「後」の値を取ることができます。 値が「before」または「after」の場合、「key」属性も使用して、リスト内の既存の要素を指定する必要があります。 「key」属性の値は、リストエントリの完全なインスタンス識別子（9.13項を参照）のキー述語です。
Bjorklund Standards Track [Page 88] RFC 7950 YANG 1.1 August 2016 If no "insert" attribute is present in the "create" operation, it defaults to "last".
「作成」操作に「挿入」属性が存在しない場合、デフォルトで「最後」になります。
If several entries in an "ordered-by user" list are modified in the same <edit-config> request, the entries are modified one at a time, in the order of the XML elements in the request.
「ordered-by user」リストのいくつかのエントリが同じ<edit-config>リクエストで変更される場合、エントリは、リクエストのXML要素の順序で一度に1つずつ変更されます。
In a <copy-config> or in 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>またはリスト全体を対象とする「replace」操作を含む<edit-config>では、リストエントリの順序は、リクエスト内のXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a list node are as follows:
NETCONFサーバーが<edit-config>要求を処理する場合、リストノードの手順の要素は次のとおりです。
o 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.
操作が「マージ」または「置換」の場合、リストエントリが存在しない場合は作成されます。 リストエントリがすでに存在し、「挿入」および「キー」属性が存在する場合、リストエントリは「挿入」および「キー」属性の値に従って移動されます。 リストエントリが存在し、「挿入」および「キー」属性が存在しない場合、リストエントリは移動されません。
o 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.
操作が「作成」の場合、リストエントリが存在しない場合は作成されます。 リストエントリがすでに存在する場合、「data-exists」エラーが返されます。
o 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.
操作が「削除」の場合、エントリが存在する場合はリストから削除されます。 リストエントリが存在しない場合は、「データ欠落」エラーが返されます。
Bjorklund Standards Track [Page 89] RFC 7950 YANG 1.1 August 2016 7.8.7. Usage Example
7.8.7。 使用例
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>
Bjorklund Standards Track [Page 90]
RFC 7950 YANG 1.1 August 2016
To create a new user "barney":
新しいユーザー「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="urn:example: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":
「fred」のタイプを「スーパーユーザー」に変更するには：
<rpc message-id="102"
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="urn:example:config">
<user>
<name>fred</name>
<type>superuser</type>
</user>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 91]
RFC 7950 YANG 1.1 August 2016
Given the following ordered-by user list:
次のordered-byユーザーリストがあるとします。
list user {
description
"This is a list of users in the system.";
ordered-by user;
config true;
key "first-name surname";
leaf first-name {
type string;
}
leaf surname {
type string;
}
leaf type {
type string;
}
}
The following would be used to insert a new user "barney rubble"
after the user "fred flintstone":
以下は、ユーザー「fred flintstone」の後に新しいユーザー「barney rubble」を挿入するために使用されます。
<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="urn:example:config"
xmlns:ex="urn:example:config">
<user nc:operation="create"
yang:insert="after"
yang:key="[ex:first-name='fred']
[ex:surname='flintstone']">
<first-name>barney</first-name>
<surname>rubble</surname>
<type>admin</type>
</user>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 92]
RFC 7950 YANG 1.1 August 2016
The following would be used to move the user "barney rubble" before
the user "fred flintstone":
次のコードは、ユーザー「frney flintstone」の前にユーザー「barney rubble」を移動するために使用されます。
<rpc message-id="102"
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="urn:example:config"
xmlns:ex="urn:example:config">
<user nc:operation="merge"
yang:insert="before"
yang:key="[ex:name='fred']
[ex:surname='flintstone']">
<first-name>barney</first-name>
<surname>rubble</surname>
</user>
</system>
</config>
</edit-config>
</rpc>
7.9. The "choice" Statement
7.9。 「選択」ステートメント
The "choice" statement defines a set of alternatives, only one of which may be present in any one data tree. 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.
「choice」ステートメントは、一連の代替案を定義します。そのうちの1つだけが、任意の1つのデータツリーに存在できます。 引数は識別子であり、その後に詳細な選択情報を保持するサブステートメントのブロックが続きます。 識別子は、スキーマツリーで選択ノードを識別するために使用されます。 選択ノードがデータツリーに存在しません。
A choice consists of a number of branches, each defined with a "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つのブランチからのノードが同時に存在します。
Since only one of the choice's cases can be valid at any time in the data tree, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice.
データツリーではいつでも選択肢の1つのケースのみが有効であるため、1つのケースからノードを作成すると、他のすべてのケースからすべてのノードが暗黙的に削除されます。 リクエストがケースからノードを作成する場合、サーバーは他のケースで定義されている既存のノードを選択肢内で削除します。
Bjorklund Standards Track [Page 93] RFC 7950 YANG 1.1 August 2016 7.9.1. The choice's Substatements
7.9.1。 選択のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.21.1 | 0..1 |
| container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.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.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.9.2. The choice's "case" Statement
7.9.2。 選択の「ケース」ステートメント
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.
「case」ステートメントは、選択したブランチを定義するために使用されます。 引数として識別子を受け取り、その後に詳細なケース情報を保持するサブステートメントのブロックが続きます。
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 "anydata", "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:
「case」ステートメント内では、「anydata」、「anyxml」、「choice」、「container」、「leaf」、「list」、「leaf-list」、および「uses」ステートメントを使用して子ノードを定義できます ケースノードに。 これらすべての子ノードの識別子は、選択されたすべてのケースで一意である必要があります。 たとえば、以下は不正です。
choice interface-type { // This example is illegal YANG
case a {
leaf ethernet { ... }
}
case b {
container ethernet { ...}
}
}
Bjorklund Standards Track [Page 94]
RFC 7950 YANG 1.1 August 2016
As a shorthand, the "case" statement can be omitted if the branch
contains a single "anydata", "anyxml", "choice", "container", "leaf",
"list", or "leaf-list" statement. In this case, the case node still
exists in the schema tree, and its identifier is the same as the
identifier of the child node. Schema node identifiers (Section 6.5)
MUST always explicitly include case node identifiers. The following
example:
省略形として、ブランチに単一の「anydata」、「anyxml」、「choice」、「container」、「leaf」、「list」、または「leaf-list」ステートメントが含まれている場合、「case」ステートメントは省略できます。 この場合、ケースノードはまだスキーマツリーに存在し、その識別子は子ノードの識別子と同じです。 スキーマノード識別子（セクション6.5）には、常に明示的にケースノード識別子を含める必要があります。 次の例：
choice interface-type {
container ethernet { ... }
}
is equivalent to:
choice interface-type {
case ethernet {
container ethernet { ... }
}
}
The case identifier MUST be unique within a choice.
ケース識別子は、選択肢内で一意である必要があります。
7.9.2.1. The case's Substatements
7.9.2.1。 ケースのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 95]
RFC 7950 YANG 1.1 August 2016
7.9.3. The choice's "default" Statement
7.9.3。 選択の「デフォルト」ステートメント
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 default "case" statement. If the "default" statement is missing, there is no default case.
「デフォルト」ステートメントは、選択のいずれかのケースの子ノードが存在しない場合に、ケースをデフォルトと見なす必要があるかどうかを示します。 引数は、デフォルトの「case」ステートメントの識別子です。 「デフォルト」ステートメントがない場合、デフォルトのケースはありません。
The "default" statement MUST NOT be present on choices where "mandatory" is "true".
「デフォルト」ステートメントは、「必須」が「true」である選択肢に存在してはなりません。
The default case is only important when considering the "default" statements of nodes under the cases (i.e., default values of leafs and leaf-lists, and default cases of nested choices). The default values and nested default cases 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) directly under the default case.
デフォルトのケースの直下に必須ノード（セクション3）があってはなりません。
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つが存在する場合、またはそのケースがデフォルトのケースである場合にのみ使用されます。 ケースの下にノードが存在せず、ケースがデフォルトのケースでない場合、ケースの子ノードのデフォルト値は無視されます。
Bjorklund Standards Track [Page 96] RFC 7950 YANG 1.1 August 2016 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.
この例では、デフォルトで「interval」が選択され、「daily」、「time-of-day」、または「manual」が存在しない場合はデフォルト値が使用されます。 「毎日」が存在する場合、「時刻」のデフォルト値が使用されます。
container transfer {
choice how {
default interval;
case interval {
leaf interval {
type uint16;
units minutes;
default 30;
}
}
case daily {
leaf daily {
type empty;
}
leaf time-of-day {
type string;
units 24-hour-clock;
default "01.00";
}
}
case manual {
leaf manual {
type empty;
}
}
}
}
Bjorklund Standards Track [Page 97]
RFC 7950 YANG 1.1 August 2016
7.9.4. The choice's "mandatory" Statement
7.9.4。 選択の「必須」ステートメント
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.
オプションの「必須」ステートメントは、ストリング「true」または「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 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 constraint is
enforced.
そのような祖先がスキーマツリーに存在しない場合、制約が適用されます。
o Otherwise, if this ancestor is a case node, the constraint is
enforced if any other node from the case exists.
それ以外の場合、この祖先がケースノードの場合、ケースの他のノードが存在する場合に制約が適用されます。
o Otherwise, it is enforced if the ancestor node exists.
それ以外の場合は、祖先ノードが存在する場合に適用されます。
The constraint is further enforced according to the rules in Section 8.
制約は、セクション8のルールに従ってさらに適用されます。
7.9.5. XML Encoding Rules
7.9.5。 XMLエンコーディングルール
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 or action input or output parameter definition. Otherwise, the subelements are encoded in any order.
選択した「case」ステートメントの子ノードは、RPCまたはアクションの入力または出力パラメーター定義の一部である場合、「case」ステートメントで定義されているのと同じ順序でエンコードする必要があります。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
Bjorklund Standards Track [Page 98] RFC 7950 YANG 1.1 August 2016 7.9.6. Usage Example
7.9.6。 使用例
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="urn:example:config">
<protocol>
<udp nc:operation="create"/>
</protocol>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 99]
RFC 7950 YANG 1.1 August 2016
7.10. The "anydata" Statement
7.10。 「anydata」ステートメント
The "anydata" 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 anydata information.
「anydata」ステートメントは、スキーマツリーの内部ノードを定義します。 1つの引数（識別子）を受け取り、その後に詳細なanydata情報を保持するサブステートメントのブロックが続きます。
The "anydata" statement is used to represent an unknown set of nodes that can be modeled with YANG, except anyxml, but for which the data model is not known at module design time. It is possible, though not required, for the data model for anydata content to become known through protocol signaling or other means that are outside the scope of this document.
「anydata」ステートメントは、anyxmlを除いて、YANGでモデル化できる未知のノードのセットを表すために使用されますが、データモデルはモジュール設計時に不明です。 必須ではありませんが、データコンテンツのデータモデルが、このドキュメントの範囲外であるプロトコルシグナリングまたはその他の手段によって認識される可能性があります。
An example of where anydata can be useful is a list of received notifications where the specific notifications are not known at design time.
anydataが役立つ例としては、設計時に特定の通知が不明な受信通知のリストがあります。
An anydata node cannot be augmented (see Section 7.17).
anydataノードは拡張できません（セクション7.17を参照）。
An anydata node exists in zero or one instance in the data tree.
anydataノードは、データツリーの0または1つのインスタンスに存在します。
An implementation may or may not know the data model used to model a specific instance of an anydata node.
実装は、anydataノードの特定のインスタンスをモデル化するために使用されるデータモデルを知っている場合と知らない場合があります。
Since the use of anydata limits the manipulation of the content, the "anydata" statement SHOULD NOT be used to define configuration data.
anydataを使用するとコンテンツの操作が制限されるため、「anydata」ステートメントを使用して構成データを定義することはできません（SHOULD NOT）。
7.10.1. The anydata's Substatements
7.10.1。 anydataのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.21.1 | 0..1 |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 100]
RFC 7950 YANG 1.1 August 2016
7.10.2. XML Encoding Rules
7.10.2。 XMLエンコーディングルール
An anydata node is encoded as an XML element. The element's local name is the anydata's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of the anydata node is a set of nodes, which are encoded as XML subelements to the anydata element.
anydataノードは、XML要素としてエンコードされます。 要素のローカル名はanydataの識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。 anydataノードの値はノードのセットであり、XMLサブエレメントとしてanydataエレメントにエンコードされます。
7.10.3. NETCONF <edit-config> Operations
7.10.3。 NETCONF <edit-config>操作
An anydata node is treated as an opaque chunk of data. This data can be modified in its entirety only.
anydataノードは、不透明なデータのチャンクとして扱われます。 このデータは、全体のみを変更できます。
Any "operation" attributes present on subelements of an anydata node are ignored by the NETCONF server.
anydataノードのサブエレメントに存在する「操作」属性は、NETCONFサーバーによって無視されます。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the anydata node are as follows:
NETCONFサーバーが<edit-config>要求を処理する場合、anydataノードの手順の要素は次のとおりです。
o If the operation is "merge" or "replace", the node is created if
it does not exist, and its value is set to the subelements of the
anydata node found in the XML RPC data.
操作が「マージ」または「置換」の場合、ノードが存在しない場合はノードが作成され、その値はXML RPCデータで見つかったanydataノードのサブ要素に設定されます。
o If the operation is "create", the node is created if it does not
exist, and its value is set to the subelements of the anydata node
found in the XML RPC data. If the node already exists, a
"data-exists" error is returned.
操作が「作成」の場合、ノードが存在しない場合はノードが作成され、その値はXML RPCデータで見つかったanydataノードのサブ要素に設定されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
o If the operation is "delete", the node is deleted if it exists.
If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在すると削除されます。 ノードが存在しない場合、「データ欠落」エラーが返されます。
7.10.4. Usage Example
7.10.4。 使用例
Given the following "anydata" statement:
次の「anydata」ステートメントがあるとします。
list logged-notification {
key time;
leaf time {
type yang:date-and-time;
}
anydata data;
}
Bjorklund Standards Track [Page 101]
RFC 7950 YANG 1.1 August 2016
The following is a valid encoding of such a list instance:
以下は、そのようなリストインスタンスの有効なエンコーディングです。
<logged-notification>
<time>2014-07-29T13:43:12Z</time>
<data>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2014-07-29T13:43:01Z</eventTime>
<event xmlns="urn:example:event">
<event-class>fault</event-class>
<reporting-entity>
<card>Ethernet0</card>
</reporting-entity>
<severity>major</severity>
</event>
</notification>
</data>
</logged-notification>
7.11. The "anyxml" Statement
7.11。 「anyxml」ステートメント
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 in NETCONF.
「anyxml」ステートメントは、未知のXMLチャンクを表すために使用されます。 XMLに制限はありません。 これは、RPC応答などで役立ちます。 例は、NETCONFの<get-config>操作の<filter>パラメータです。
An anyxml node cannot be augmented (see Section 7.17).
anyxmlノードは拡張できません（セクション7.17を参照）。
An anyxml node exists in zero or one instance in the data tree.
anyxmlノードは、データツリーのゼロまたは1つのインスタンスに存在します。
Since the use of anyxml limits the manipulation of the content, the "anyxml" statement SHOULD NOT be used to define configuration data.
anyxmlを使用するとコンテンツの操作が制限されるため、「anyxml」ステートメントを使用して構成データを定義しないでください。
It should be noted that in YANG version 1, "anyxml" was the only statement that could model an unknown hierarchy of data. In many cases, this unknown hierarchy of data is actually modeled in YANG, but the specific YANG data model is not known at design time. In these situations, it is RECOMMENDED to use "anydata" (Section 7.10) instead of "anyxml".
YANGバージョン1では、「anyxml」がデータの不明な階層をモデル化できる唯一のステートメントであったことに注意してください。 多くの場合、この未知のデータ階層は実際にはYANGでモデル化されていますが、特定のYANGデータモデルは設計時には不明です。 これらの状況では、「anyxml」の代わりに「anydata」（セクション7.10）を使用することをお勧めします。
Bjorklund Standards Track [Page 102] RFC 7950 YANG 1.1 August 2016 7.11.1. The anyxml's Substatements
7.11.1。 anyxmlのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.21.1 | 0..1 |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.11.2. XML Encoding Rules
7.11.2。 XMLエンコーディングルール
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 XML 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プレフィックスは、各インスタンスのエンコーディングに対してローカルであることに注意してください。 これは、同じXMLが異なる実装によって異なる方法でエンコードされる可能性があることを意味します。
7.11.3. NETCONF <edit-config> Operations
7.11.3。 NETCONF <edit-config>操作
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 as follows:
NETCONFサーバーが<edit-config>要求を処理する場合、anyxmlノードの手順の要素は次のとおりです。
o 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コンテンツに設定されます。
o 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コンテンツに設定されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
o If the operation is "delete", the node is deleted if it exists.
If the node does not exist, a "data-missing" error is returned.
操作が「削除」の場合、ノードが存在すると削除されます。 ノードが存在しない場合、「データ欠落」エラーが返されます。
Bjorklund Standards Track [Page 103] RFC 7950 YANG 1.1 August 2016 7.11.4. Usage Example
7.11.4。 使用例
Given the following "anyxml" statement:
次の「anyxml」ステートメントがあるとします。
anyxml html-info;
The following are two valid encodings of the same anyxml value:
以下は、同じanyxml値の2つの有効なエンコーディングです。
<html-info>
<p xmlns="http://www.w3.org/1999/xhtml">
This is <em>very</em> cool.
</p>
</html-info>
<html-info>
<x:p xmlns:x="http://www.w3.org/1999/xhtml">
This is <x:em>very</x:em> cool.
</x:p>
</html-info>
7.12. The "grouping" Statement
7.12。 「グループ化」ステートメント
The "grouping" statement is used to define a reusable block of nodes, which may be used locally in the module or submodule, 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.13). A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings.
グループ化が定義されると、「uses」ステートメントで参照できます（セクション7.13を参照）。 グループ化は、他のグループ化のチェーンを介して直接的または間接的にそれ自体を参照してはなりません。
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; it also 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 Bjorklund Standards Track [Page 104] RFC 7950 YANG 1.1 August 2016 where the "grouping" statement appears. For extensions, this means that extensions defined as direct children to a "grouping" statement are applied to the grouping itself.
グループ化は、単なるテキスト置換のメカニズムではありません。 ノードのコレクションも定義します。 グループ内に表示される識別子は、グループが使用されている場所ではなく、グループが定義されているスコープに関連して解決されます。 接頭辞マッピング、タイプ名、グループ化名、および拡張機能の使用法は、「グループ化」ステートメントが表示される階層で評価されます。 拡張機能の場合、これは、「グループ化」ステートメントの直接の子として定義された拡張機能がグループ化自体に適用されることを意味します。
Note that if a grouping defines an action or a notification node in its hierarchy, then it cannot be used in all contexts. For example, it cannot be used in an rpc definition. See Sections 7.15 and 7.16.
グループ化がその階層内でアクションまたは通知ノードを定義する場合、すべてのコンテキストで使用できるわけではないことに注意してください。 たとえば、rpc定義では使用できません。 セクション7.15および7.16を参照してください。
7.12.1. The grouping's Substatements
7.12.1。 グループのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| action | 7.15 | 0..n |
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| notification | 7.16 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
+--------------+---------+-------------+
7.12.2. Usage Example
7.12.2。 使用例
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;
}
}
Bjorklund Standards Track [Page 105]
RFC 7950 YANG 1.1 August 2016
7.13. The "uses" Statement
7.13。 「使用」ステートメント
The "uses" statement is used to reference a "grouping" definition. It takes one argument, which is the name of the grouping.
「uses」ステートメントは、「グループ化」定義を参照するために使用されます。 これは、グループ化の名前である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 are then updated according to the "refine" and "augment" statements.
グループ化への「使用」参照の効果は、グループ化によって定義されたノードが現在のスキーマツリーにコピーされ、「refine」および「augment」ステートメントに従って更新されることです。
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.
グループ化で定義された識別子は、「グループ化」ステートメント内に表示されない「uses」ステートメントを介してグループ化の内容がスキーマツリーに追加されるまで、名前空間にバインドされません。 現在のモジュールの。
7.13.1. The uses's Substatements
7.13.1。 使用のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| augment | 7.17 | 0..n |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| refine | 7.13.2 | 0..n |
| status | 7.21.2 | 0..1 |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.13.2. The "refine" Statement
7.13.2。 「洗練」ステートメント
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 is used exactly as it was defined in the grouping.
グループ化の各ノードのプロパティの一部は、「refine」ステートメントで調整できます。 引数は、グループ内のノードを識別する文字列です。 このノードは、リファインのターゲットノードと呼ばれます。 グループ化のノードが「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 A leaf-list node may get a set of default values, or a new set of
default values if it already had defaults; i.e., the set of
refined default values replaces the defaults already given.
リーフリストノードは、デフォルト値のセットを取得するか、すでにデフォルト値が設定されている場合は新しいデフォルト値のセットを取得します。 つまり、洗練されたデフォルト値のセットは、すでに与えられているデフォルトを置き換えます。
Bjorklund Standards Track [Page 106] RFC 7950 YANG 1.1 August 2016 o Any node may get a specialized "description" string.
どのノードも、特殊な「説明」文字列を取得できます。
o Any node may get a specialized "reference" string.
どのノードも特殊な「参照」文字列を取得できます。
o Any node may get a different "config" statement.
どのノードも異なる "config"ステートメントを取得する場合があります。
o A leaf, anydata, anyxml, or choice node may get a different
"mandatory" statement.
リーフ、anydata、anyxml、またはchoiceノードは、異なる「必須」ステートメントを取得する場合があります。
o A container node may get a "presence" statement.
コンテナノードは「存在」ステートメントを取得する場合があります。
o A leaf, leaf-list, list, container, anydata, or anyxml node may
get additional "must" expressions.
リーフ、リーフリスト、リスト、コンテナ、anydata、またはanyxmlノードは、追加の「必須」式を取得する場合があります。
o A leaf-list or list node may get a different "min-elements" or
"max-elements" statement.
リーフリストまたはリストノードは、異なる「最小要素」または「最大要素」ステートメントを取得する場合があります。
o A leaf, leaf-list, list, container, choice, case, anydata, or
anyxml node may get additional "if-feature" expressions.
リーフ、リーフリスト、リスト、コンテナ、選択、ケース、anydata、またはanyxmlノードは、追加の「if-feature」式を取得する場合があります。
o Any node can get refined extensions, if the extension allows
refinement. See Section 7.19 for details.
拡張で絞り込みが許可されている場合は、どのノードでも絞り込みを行うことができます。 詳細については、セクション7.19を参照してください。
7.13.3. XML Encoding Rules
7.13.3。 XMLエンコーディングルール
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名前空間を持つ別のモジュールからインポートされた場合でも、インラインで定義されているかのようにエンコードされます。
7.13.4. Usage Example
7.13.4。 使用例
To use the "endpoint" grouping defined in Section 7.12.2 in a definition of an HTTP server in some other module, we can do:
セクション7.12.2で定義された「エンドポイント」グループを他のモジュールのHTTPサーバーの定義で使用するには、次のようにします。
import example-system {
prefix "sys";
}
container http-server {
leaf name {
type string;
}
uses sys:endpoint;
}
Bjorklund Standards Track [Page 107]
RFC 7950 YANG 1.1 August 2016
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, a default can
be added:
ポート80をHTTPサーバーのデフォルトにする必要がある場合は、デフォルトを追加できます。
container http-server {
leaf name {
type string;
}
uses sys:endpoint {
refine port {
default 80;
}
}
}
If we want to define a list of servers and each server has "ip" and
"port" as keys, we can do:
サーバーのリストを定義し、各サーバーがキーとして「ip」と「port」を持っている場合、次のようにできます。
list server {
key "ip port";
leaf name {
type string;
}
uses sys:endpoint;
}
The following is an error:
以下はエラーです。
container http-server {
uses sys:endpoint;
leaf ip { // illegal - same identifier "ip" used twice
type string;
}
}
7.14. The "rpc" Statement
7.14。 「rpc」ステートメント
The "rpc" statement is used to define an 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.
「rpc」ステートメントは、RPC操作を定義するために使用されます。 1つの引数（識別子）を受け取り、その後に詳細なRPC情報を保持するサブステートメントのブロックが続きます。 この引数はRPCの名前です。
Bjorklund Standards Track [Page 108] RFC 7950 YANG 1.1 August 2016 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ノードの下には、「input」という名前のスキーマノードと「output」という名前のスキーマノードも定義されています。 ノード「入力」と「出力」は、モジュールの名前空間で定義されます。
7.14.1. The rpc's Substatements
7.14.1。 RPCのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| if-feature | 7.20.2 | 0..n |
| input | 7.14.2 | 0..1 |
| output | 7.14.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
7.14.2. The "input" Statement
7.14.2。 「入力」ステートメント
The "input" statement, which is optional, is used to define input parameters to the operation. It does not take an argument. The substatements to "input" define nodes under the operation's input node.
オプションの「入力」ステートメントは、操作への入力パラメーターを定義するために使用されます。 引数は取りません。 「入力」のサブステートメントは、操作の入力ノードの下のノードを定義します。
If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in an RPC invocation.
入力ツリーのリーフに値「true」の「必須」ステートメントがある場合、そのリーフはRPC呼び出しに存在する必要があります。
If a leaf in the input tree has a default value, the server MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the RPC invocation with the default value as its value.
入力ツリーのリーフにデフォルト値がある場合、サーバーは、セクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。 これらの場合、サーバーは、葉がRPC呼び出しに存在し、その値としてデフォルト値が設定されているかのように動作する必要があります。
If a leaf-list in the input tree has one or more default values, the server MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the server MUST operationally behave as if the leaf-list was present in the RPC invocation with the default values as its values.
入力ツリーのリーフリストに1つ以上のデフォルト値がある場合、サーバーは、セクション7.7.2で説明されているのと同じケースでこれらの値を使用する必要があります。 これらの場合、サーバーは、リーフリストがデフォルト値をその値として持つRPC呼び出しに存在するかのように操作上動作する必要があります。
Since the input tree is not part of any datastore, all "config" statements for nodes in the input tree are ignored.
入力ツリーはデータストアの一部ではないため、入力ツリーのノードのすべての「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」ステートメントがある場合、このノードは入力ツリーに存在してはなりません（MUST NOT）。
Bjorklund Standards Track [Page 109] RFC 7950 YANG 1.1 August 2016 7.14.2.1. The input's Substatements
7.14.2.1。 入力のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.12 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| must | 7.5.3 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
+--------------+---------+-------------+
7.14.3. The "output" Statement
7.14.3。 「出力」ステートメント
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 operation's output node.
オプションの「output」ステートメントは、RPC操作の出力パラメーターを定義するために使用されます。 引数は取りません。 「出力」のサブステートメントは、操作の出力ノードの下のノードを定義します。
If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in an RPC reply.
出力ツリーのリーフに値「true」の「必須」ステートメントがある場合、そのリーフはRPC応答に存在する必要があります。
If a leaf in the output tree has a default value, the client MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the RPC reply with the default value as its value.
出力ツリーのリーフにデフォルト値がある場合、クライアントはセクション7.6.1で説明されているのと同じケースでこの値を使用しなければなりません（MUST）。 これらの場合、クライアントは、リーフがRPC応答に存在するかのように動作し、デフォルト値をその値として使用する必要があります。
If a leaf-list in the output tree has one or more default values, the client MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the client MUST operationally behave as if the leaf-list was present in the RPC reply with the default values as its values.
出力ツリーのリーフリストに1つ以上のデフォルト値がある場合、クライアントは、セクション7.7.2で説明されているのと同じケースでこれらの値を使用する必要があります。 これらの場合、クライアントは、デフォルト値を値として持つRPC応答にリーフリストが存在するかのように、動作上動作する必要があります。
Since the output tree is not part of any datastore, all "config" statements for nodes in the output tree are ignored.
出力ツリーはデータストアの一部ではないため、出力ツリーのノードのすべての「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」ステートメントがある場合、このノードは出力ツリーに存在してはなりません（MUST NOT）。
Bjorklund Standards Track [Page 110] RFC 7950 YANG 1.1 August 2016 7.14.3.1. The output's Substatements
7.14.3.1。 出力のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.12 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| must | 7.5.3 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
+--------------+---------+-------------+
7.14.4. NETCONF XML Encoding Rules
7.14.4。 NETCONF XMLエンコーディングルール
An rpc node is encoded as a child XML element to the <rpc> element, as designated by the substitution group "rpcOperation" in [RFC6241]. The element's local name is the rpc's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
[RFC6241]の置換グループ「rpcOperation」で指定されているように、rpcノードは<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 [RFC6241]. If output parameters are returned, they are encoded as child elements to the <rpc-reply> element defined in [RFC6241], in the same order as they are defined within the "output" statement.
RPC操作の呼び出しが成功し、出力パラメーターが返されない場合、<rpc-reply>には、[RFC6241]で定義されている単一の<ok />要素が含まれています。 出力パラメーターが返される場合、それらは[output]ステートメント内で定義されているのと同じ順序で、[RFC6241]で定義されている<rpc-reply>要素の子要素としてエンコードされます。
Bjorklund Standards Track [Page 111] RFC 7950 YANG 1.1 August 2016 7.14.5. Usage Example
7.14.5。 使用例
The following example defines an RPC operation:
次の例では、RPC操作を定義しています。
module example-rock {
yang-version 1.1;
namespace "urn:example:rock";
prefix "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="urn:example: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>
Bjorklund Standards Track [Page 112]
RFC 7950 YANG 1.1 August 2016
7.15. The "action" Statement
7.15。 「アクション」ステートメント
The "action" statement is used to define an operation connected to a specific container or list data node. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed action information. The argument is the name of the action.
「アクション」ステートメントは、特定のコンテナーまたはリストデータノードに接続された操作を定義するために使用されます。 1つの引数（識別子）を受け取り、その後に詳細なアクション情報を保持するサブステートメントのブロックが続きます。 引数はアクションの名前です。
The "action" statement defines an action node in the schema tree. Under the action 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.
「アクション」ステートメントは、スキーマツリーのアクションノードを定義します。 アクションノードの下には、「input」という名前のスキーマノードと、「output」という名前のスキーマノードも定義されています。 ノード「入力」と「出力」は、モジュールの名前空間で定義されます。
An action MUST NOT be defined within an rpc, another action, or a notification, i.e., an action node MUST NOT have an rpc, action, or a notification node as one of its ancestors in the schema tree. For example, this means that it is an error if a grouping that contains an action somewhere in its node hierarchy is used in a notification definition.
アクションは、rpc、別のアクション、または通知内で定義してはなりません（MUST NOT）。つまり、アクションノードは、スキーマツリー内の祖先の1つとしてrpc、アクション、または通知ノードを持ってはなりません。 たとえば、これは、ノード階層のどこかにアクションを含むグループが通知定義で使用されている場合、エラーであることを意味します。
An action MUST NOT have any ancestor node that is a list node without a "key" statement.
アクションには、「キー」ステートメントのないリストノードである祖先ノードがあってはなりません。
Since an action cannot be defined at the top level of a module or in a "case" statement, it is an error if a grouping that contains an action at the top of its node hierarchy is used at the top level of a module or in a case definition.
アクションはモジュールの最上位または「case」ステートメントでは定義できないため、ノード階層の最上位にアクションを含むグループがモジュールの最上位または内部で使用されている場合はエラーになります。 ケース定義。
The difference between an action and an rpc is that an action is tied to a node in the datastore, whereas an rpc is not. When an action is invoked, the node in the datastore is specified along with the name of the action and the input parameters.
アクションとrpcの違いは、アクションはデータストアのノードに関連付けられているのに対し、rpcは関連付けられていないことです。 アクションが呼び出されると、データストア内のノードがアクションの名前と入力パラメーターとともに指定されます。
Bjorklund Standards Track [Page 113] RFC 7950 YANG 1.1 August 2016 7.15.1. The action's Substatements
7.15.1。 アクションのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| if-feature | 7.20.2 | 0..n |
| input | 7.14.2 | 0..1 |
| output | 7.14.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
7.15.2. NETCONF XML Encoding Rules
7.15.2。 NETCONF XMLエンコーディングルール
When an action is invoked, an element with the local name "action" in the namespace "urn:ietf:params:xml:ns:yang:1" (see Section 5.3.1) is encoded as a child XML element to the <rpc> element defined in [RFC6241], as designated by the substitution group "rpcOperation" in [RFC6241].
アクションが呼び出されると、名前空間「urn：ietf：params：xml：ns：yang：1」（セクション5.3.1を参照）のローカル名が「action」の要素が子XML要素として<にエンコードされます。 [RFC6241]の置換グループ「rpcOperation」で指定されている、[RFC6241]で定義されているrpc>要素。
The <action> element contains a hierarchy of nodes that identifies the node in the datastore. It MUST contain all containers and list nodes in the direct path from the top level down to the list or container containing the action. For lists, all key leafs MUST also be included. The innermost container or list contains an XML element that carries the name of the defined action. Within this element, the input parameters are encoded as child XML elements, in the same order as they are defined within the "input" statement.
<action>要素には、データストア内のノードを識別するノードの階層が含まれています。 最上位からアクションを含むリストまたはコンテナまでの直接パスにあるすべてのコンテナとリストノードを含める必要があります。 リストの場合、すべてのキーリーフも含める必要があります。 最も内側のコンテナまたはリストには、定義されたアクションの名前を保持するXML要素が含まれています。 この要素内では、入力パラメーターは、「input」ステートメント内で定義されているのと同じ順序で子XML要素としてエンコードされます。
Only one action can be invoked in one <rpc>. If more than one action is present in the <rpc>, the server MUST reply with a "bad-element" <error-tag> in the <rpc-error>.
1つの<rpc>で呼び出すことができるアクションは1つだけです。 <rpc>に複数のアクションが存在する場合、サーバーは、<rpc-error>の「bad-element」<error-tag>で応答する必要があります。
If the action operation invocation succeeded and no output parameters are returned, the <rpc-reply> contains a single <ok/> element defined in [RFC6241]. If output parameters are returned, they are encoded as child elements to the <rpc-reply> element defined in [RFC6241], in the same order as they are defined within the "output" statement.
アクション操作の呼び出しが成功し、出力パラメーターが返されない場合、<rpc-reply>には、[RFC6241]で定義されている単一の<ok />要素が含まれています。 出力パラメーターが返される場合、それらは[output]ステートメント内で定義されているのと同じ順序で、[RFC6241]で定義されている<rpc-reply>要素の子要素としてエンコードされます。
Bjorklund Standards Track [Page 114] RFC 7950 YANG 1.1 August 2016 7.15.3. Usage Example
7.15.3。 使用例
The following example defines an action to reset one server at a server farm:
次の例では、サーバーファームで1つのサーバーをリセットするアクションを定義しています。
module example-server-farm {
yang-version 1.1;
namespace "urn:example:server-farm";
prefix "sfarm";
import ietf-yang-types {
prefix "yang";
}
list server {
key name;
leaf name {
type string;
}
action reset {
input {
leaf reset-at {
type yang:date-and-time;
mandatory true;
}
}
output {
leaf reset-finished-at {
type yang:date-and-time;
mandatory true;
}
}
}
}
}
Bjorklund Standards Track [Page 115]
RFC 7950 YANG 1.1 August 2016
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">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="urn:example:server-farm">
<name>apache-1</name>
<reset>
<reset-at>2014-07-29T13:42:00Z</reset-at>
</reset>
</server>
</action>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<reset-finished-at xmlns="urn:example:server-farm">
2014-07-29T13:42:12Z
</reset-finished-at>
</rpc-reply>
7.16. The "notification" Statement
7.16。 「通知」ステートメント
The "notification" statement is used to define a 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.
「通知」ステートメントは、通知を定義するために使用されます。 1つの引数（識別子）を受け取り、その後に詳細な通知情報を保持するサブステートメントのブロックが続きます。 「通知」ステートメントは、スキーマツリーの通知ノードを定義します。
A notification can be defined at the top level of a module, or connected to a specific container or list data node in the schema tree.
通知は、モジュールの最上位で定義するか、スキーマツリーの特定のコンテナーまたはリストデータノードに接続できます。
A notification MUST NOT be defined within an rpc, action, or another notification, i.e., a notification node MUST NOT have an rpc, action, or a notification node as one of its ancestors in the schema tree. For example, this means that it is an error if a grouping that contains a notification somewhere in its node hierarchy is used in an rpc definition.
通知は、rpc、アクション、または別の通知内で定義してはなりません（MUST NOT）。つまり、通知ノードには、スキーマツリー内の祖先の1つとしてrpc、アクション、または通知ノードがあってはなりません。 たとえば、これは、ノード階層のどこかに通知を含むグループがrpc定義で使用されている場合、エラーであることを意味します。
A notification MUST NOT have any ancestor node that is a list node without a "key" statement.
通知には、「キー」ステートメントのないリストノードである祖先ノードがあってはなりません（MUST NOT）。
Since a notification cannot be defined in a "case" statement, it is an error if a grouping that contains a notification at the top of its node hierarchy is used in a case definition.
通知は「case」ステートメントで定義できないため、ノード階層の最上位に通知を含むグループをケース定義で使用すると、エラーになります。
Bjorklund Standards Track [Page 116] RFC 7950 YANG 1.1 August 2016 If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a notification instance.
通知ツリーのリーフに値「true」の「必須」ステートメントがある場合、リーフは通知インスタンスに存在する必要があります。
If a leaf in the notification tree has a default value, the client MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the notification instance with the default value as its value.
通知ツリーのリーフにデフォルト値がある場合、クライアントはセクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。 これらの場合、クライアントは、リーフが通知インスタンスに存在し、デフォルト値がその値であるかのように操作上動作する必要があります。
If a leaf-list in the notification tree has one or more default values, the client MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the client MUST operationally behave as if the leaf-list was present in the notification instance with the default values as its values.
通知ツリーのリーフリストに1つ以上のデフォルト値がある場合、クライアントは、セクション7.7.2で説明されているのと同じケースでこれらの値を使用する必要があります。 これらのケースでは、クライアントは、リーフリストがデフォルト値をその通知インスタンスとして通知インスタンスに存在しているかのように操作上動作する必要があります。
Since the notification tree is not part of any datastore, all "config" statements for nodes in the notification tree are ignored.
通知ツリーはデータストアの一部ではないため、通知ツリー内のノードのすべての「config」ステートメントは無視されます。
7.16.1. The notification's Substatements
7.16.1。 通知のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| grouping | 7.12 | 0..n |
| if-feature | 7.20.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 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n |
+--------------+---------+-------------+
7.16.2. NETCONF XML Encoding Rules
7.16.2。 NETCONF XMLエンコーディングルール
A notification node that is defined on the top level of a module 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]で定義されている<notification>要素への子XML要素としてエンコードされます。 要素のローカル名は通知の識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。
Bjorklund Standards Track [Page 117] RFC 7950 YANG 1.1 August 2016 When a notification node is defined as a child to a data node, the <notification> element defined in [RFC5277] contains a hierarchy of nodes that identifies the node in the datastore. It MUST contain all containers and list nodes from the top level down to the list or container containing the notification. For lists, all key leafs MUST also be included. The innermost container or list contains an XML element that carries the name of the defined notification.
通知ノードがデータノードの子として定義されている場合、[RFC5277]で定義されている<notification>要素には、データストア内のノードを識別するノードの階層が含まれています。 最上位から通知を含むリストまたはコンテナまでのすべてのコンテナとリストノードを含める必要があります。 リストの場合、すべてのキーリーフも含める必要があります。 最も内側のコンテナまたはリストには、定義された通知の名前を保持するXML要素が含まれています。
The notification's child nodes are encoded as subelements to the notification node's XML element, in any order.
通知の子ノードは、通知ノードのXML要素のサブ要素として任意の順序でエンコードされます。
7.16.3. Usage Example
7.16.3。 使用例
The following example defines a notification at the top level of a module:
次の例では、モジュールのトップレベルで通知を定義しています。
module example-event {
yang-version 1.1;
namespace "urn:example:event";
prefix "ev";
notification event {
leaf event-class {
type string;
}
leaf reporting-entity {
type instance-identifier;
}
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="urn:example:event">
<event-class>fault</event-class>
<reporting-entity>
/ex:interface[ex:name='Ethernet0']
</reporting-entity>
<severity>major</severity>
</event>
</notification>
Bjorklund Standards Track [Page 118]
RFC 7950 YANG 1.1 August 2016
The following example defines a notification in a data node:
次の例では、データノードで通知を定義します。
module example-interface-module {
yang-version 1.1;
namespace "urn:example:interface-module";
prefix "if";
container interfaces {
list interface {
key "name";
leaf name {
type string;
}
notification interface-enabled {
leaf by-user {
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>
<interfaces xmlns="urn:example:interface-module">
<interface>
<name>eth1</name>
<interface-enabled>
<by-user>fred</by-user>
</interface-enabled>
</interface>
</interfaces>
</notification>
7.17. The "augment" Statement
7.17。 「拡張」ステートメント
The "augment" statement allows a module or submodule to add to a schema tree defined in an external module, or in 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」ステートメントを使用すると、モジュールまたはサブモジュールを、外部モジュール、または現在のモジュールとそのサブモジュールで定義されたスキーマツリーに追加したり、「uses」ステートメントのグループからノードに追加したりできます。 引数は、スキーマツリー内のノードを識別する文字列です。 このノードは、拡張のターゲットノードと呼ばれます。 ターゲットノードは、コンテナ、リスト、選択、ケース、入力、出力、または通知ノードのいずれかである必要があります。 これは、「augment」ステートメントに続くサブステートメントで定義されたノードで拡張されます。
Bjorklund Standards Track [Page 119] RFC 7950 YANG 1.1 August 2016 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 "absolute-schema-nodeid" in Section 14) 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 14) MUST be used.
引数文字列はスキーマノード識別子です（6.5節を参照）。 「augment」ステートメントがモジュールまたはサブモジュールの最上位にある場合、スキーマノード識別子の絶対形式（セクション14の「absolute-schema-nodeid」のルールで定義）を使用する必要があります。 「augment」ステートメントが「uses」ステートメントのサブステートメントである場合は、子孫フォーム（セクション14の「descendant-schema-nodeid」ルールで定義）を使用する必要があります。
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.
ターゲットノードがコンテナ、リスト、ケース、入力、出力、または通知ノードの場合、「container」、「leaf」、「list」、「leaf-list」、「uses」、および「choice」ステートメントは、 「augment」ステートメント内で使用されます。
If the target node is a container or list node, the "action" and "notification" statements can be used within the "augment" statement.
ターゲットノードがコンテナまたはリストノードである場合、「アクション」および「通知」ステートメントは「拡張」ステートメント内で使用できます。
If the target node is a choice node, the "case" statement or a shorthand "case" statement (see Section 7.9.2) can be used within the "augment" statement.
ターゲットノードが選択ノードの場合、「augment」ステートメント内で「case」ステートメントまたは省略形の「case」ステートメント（7.9.2を参照）を使用できます。
The "augment" statement MUST NOT add multiple nodes with the same name from the same module to the target node.
"augment"ステートメントは、同じモジュールから同じ名前の複数のノードをターゲットノードに追加してはなりません（MUST NOT）。
If the augmentation adds mandatory nodes (see Section 3) that represent configuration to a target node in another module, the augmentation MUST be made conditional with a "when" statement. Care must be taken when defining the "when" expression so that clients that do not know about the augmenting module do not break.
拡張により、構成を表す必須ノード（セクション3を参照）を別のモジュールのターゲットノードに追加する場合、「when」ステートメントを使用して、拡張を条件付きにする必要があります。 「いつ」式を定義するときは、拡張モジュールについて知らないクライアントが壊れないように注意する必要があります。
In the following example, it is OK to augment the "interface" entry with "mandatory-leaf" because the augmentation depends on support for "some-new-iftype". The old client does not know about this type, so it would never select this type and would therefore not be adding a mandatory data node.
次の例では、「interface-」エントリに「mandatory-leaf」を追加しても問題ありません。これは、拡張が「some-new-iftype」のサポートに依存しているためです。 古いクライアントはこのタイプを認識しないため、このタイプを選択することはないため、必須のデータノードを追加しません。
module example-augment {
yang-version 1.1;
namespace "urn:example:augment";
prefix mymod;
import ietf-interfaces {
prefix if;
}
identity some-new-iftype {
base if:interface-type;
}
Bjorklund Standards Track [Page 120]
RFC 7950 YANG 1.1 August 2016
augment "/if:interfaces/if:interface" {
when 'derived-from-or-self(if:type, "mymod:some-new-iftype")';
leaf mandatory-leaf {
mandatory true;
type string;
}
}
}
7.17.1. The augment's Substatements
7.17.1。 拡張のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| action | 7.15 | 0..n |
| anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| notification | 7.16 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 |
+--------------+---------+-------------+
7.17.2. XML Encoding Rules
7.17.2。 XMLエンコーディングルール
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.
ノードが拡張されると、拡張される子ノードは、拡張されるノードへのサブエレメントとして任意の順序でエンコードされます。
Bjorklund Standards Track [Page 121] RFC 7950 YANG 1.1 August 2016 7.17.3. Usage Example
7.17.3。 使用例
In namespace urn:example:interface-module, we have:
名前空間urn：example：interface-moduleには、次のものが含まれます。
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 urn:example:ds0, we have:
次に、名前空間urn：example：ds0には、次のようになります。
import example-interface-module {
prefix "if";
}
augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'";
leaf ds0ChannelNumber {
type ChannelNumber;
}
}
Bjorklund Standards Track [Page 122]
RFC 7950 YANG 1.1 August 2016
A corresponding XML instance example:
対応するXMLインスタンスの例：
<interfaces xmlns="urn:example:interface-module"
xmlns:ds0="urn:example: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.6. The following construct can be used to extend the
protocol definition:
別の例として、セクション7.9.6で定義された選択肢があるとします。 次の構文を使用して、プロトコル定義を拡張できます。
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>
Bjorklund Standards Track [Page 123]
RFC 7950 YANG 1.1 August 2016
7.18. The "identity" Statement
7.18。 「アイデンティティ」ステートメント
The "identity" statement is used to define a new globally unique, abstract, and untyped identity. The identity's only purpose is to denote its name, semantics, and existence. An identity can be either defined from scratch or derived from one or more base identities. 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.
「identity」ステートメントは、グローバルに一意で抽象的で型付けされていない新しいアイデンティティを定義するために使用されます。 アイデンティティの唯一の目的は、名前、セマンティクス、および存在を示すことです。 IDは、最初から定義するか、1つ以上の基本IDから派生させることができます。 アイデンティティの引数は、アイデンティティの名前である識別子です。 その後に、詳細なID情報を保持するサブステートメントのブロックが続きます。
The built-in datatype "identityref" (see Section 9.10) can be used to reference identities within a data model.
組み込みデータ型「identityref」（セクション9.10を参照）を使用して、データモデル内のIDを参照できます。
7.18.1. The identity's Substatements
7.18.1。 アイデンティティのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| base | 7.18.2 | 0..n |
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
+--------------+---------+-------------+
7.18.2. The "base" Statement
7.18.2。 「ベース」ステートメント
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 multiple "base" statements are present, the identity is derived from all of them.
「base」ステートメントはオプションであり、既存のIDの名前であるストリングを引数として取り、そこから新しいIDが派生します。 「ベース」ステートメントがない場合、IDは最初から定義されます。 複数の「基本」ステートメントが存在する場合、IDはそれらすべてから派生します。
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は、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.
アイデンティティは、他のアイデンティティのチェーンを介して直接的または間接的に自分自身を参照してはなりません。
Bjorklund Standards Track [Page 124] RFC 7950 YANG 1.1 August 2016 The derivation of identities has the following properties:
アイデンティティの導出には、次のプロパティがあります。
o It is irreflexive, which means that an identity is not derived
from itself.
それは非反射的です。つまり、アイデンティティはそれ自体から派生したものではありません。
o It is transitive, which means that if identity B is derived from A
and C is derived from B, then C is also derived from A.
これは推移的です。つまり、アイデンティティBがAから派生し、CがBから派生している場合、CもAから派生します。
7.18.3. Usage Example
7.18.3。 使用例
module example-crypto-base {
yang-version 1.1;
namespace "urn:example:crypto-base";
prefix "crypto";
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
identity symmetric-key {
description
"Base identity used to identify symmetric-key crypto
algorithms.";
}
identity public-key {
description
"Base identity used to identify public-key crypto
algorithms.";
}
}
module example-des {
yang-version 1.1;
namespace "urn:example:des";
prefix "des";
import "example-crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
base "crypto:symmetric-key";
description "DES crypto algorithm.";
}
Bjorklund Standards Track [Page 125]
RFC 7950 YANG 1.1 August 2016
identity des3 {
base "crypto:crypto-alg";
base "crypto:symmetric-key";
description "Triple DES crypto algorithm.";
}
}
7.19. The "extension" Statement
7.19。 「拡張」ステートメント
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.
「拡張」ステートメントでは、YANG言語内で新しいステートメントを定義できます。 この新しいステートメント定義をインポートして、他のモジュールで使用できます。
The "extension" 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" statement, 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" statement, using some
mechanism outside the scope of this specification. Syntactically,
the substatements MUST be YANG statements, including extensions
defined using "extension" statements. YANG statements in extensions
MUST follow the syntactical rules in Section 14.
拡張機能は通常のYANGステートメントのように使用できます。「拡張機能」ステートメントで定義されている場合はステートメント名の後に引数が続き、オプションでサブステートメントのブロックが続きます。 ステートメントの名前は、拡張が定義されたモジュールのプレフィックス、コロン（ "："）、および拡張のキーワードを組み合わせることによって作成されます。 拡張機能のサブステートメントは、この仕様の範囲外のメカニズムを使用して、「拡張機能」ステートメントによって定義されます。 構文的には、サブステートメントは、「拡張」ステートメントを使用して定義された拡張を含むYANGステートメントである必要があります。 拡張機能のYANGステートメントは、セクション14の構文規則に従う必要があります。
An extension can allow refinement (see Section 7.13.2) and deviations (Section 7.20.3.2), but the mechanism for how this is defined is outside the scope of this specification.
拡張により、改良（セクション7.13.2を参照）と偏差（セクション7.20.3.2を参照）を許可できますが、これを定義するメカニズムはこの仕様の範囲外です。
7.19.1. The extension's Substatements
7.19.1。 拡張のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| argument | 7.19.2 | 0..1 |
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 126]
RFC 7950 YANG 1.1 August 2016
7.19.2. The "argument" Statement
7.19.2。 「引数」ステートメント
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属性または要素名として使用されます。
7.19.2.1. The argument's Substatement
7.19.2.1。 引数のサブステートメント
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| yin-element | 7.19.2.2 | 0..1 |
+--------------+----------+-------------+
7.19.2.2. The "yin-element" Statement
7.19.2.2。 「yin要素」ステートメント
The "yin-element" statement, which is optional, takes as an argument the string "true" or "false". This statement indicates whether the argument is mapped to an XML element in YIN or to an XML attribute (see Section 13).
オプションの「yin-element」ステートメントは、ストリング「true」または「false」を引数として取ります。 このステートメントは、引数がYINのXML要素にマップされるか、XML属性にマップされるかを示します（セクション13を参照）。
If no "yin-element" statement is present, it defaults to "false".
「yin-element」ステートメントが存在しない場合、デフォルトで「false」になります。
7.19.3. Usage Example
7.19.3。 使用例
To define an extension:
拡張を定義するには：
module example-extensions {
yang-version 1.1;
...
extension c-define {
description
"Takes as an argument a name string.
Makes the code generator use the given name
in the #define.";
argument "name";
}
}
Bjorklund Standards Track [Page 127]
RFC 7950 YANG 1.1 August 2016
To use the extension:
拡張機能を使用するには：
module example-interfaces {
yang-version 1.1;
...
import example-extensions {
prefix "myext";
}
...
container interfaces {
...
myext:c-define "MY_INTERFACES";
}
}
7.20. Conformance-Related Statements
7.20。 適合性関連のステートメント
This section defines statements related to conformance, as described in Section 5.6.
このセクションでは、セクション5.6で説明されているように、適合性に関するステートメントを定義します。
7.20.1. The "feature" Statement
7.20.1。 「機能」ステートメント
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.20.2). Schema nodes tagged with an "if-feature" statement are ignored by the server unless the server supports the given feature expression. This allows portions of the YANG module to be conditional based on conditions in the server. The model can represent the abilities of the server within the model, giving a richer model that allows for differing server abilities and roles.
「機能」ステートメントは、スキーマの一部を条件付きとしてマークするメカニズムを定義するために使用されます。 「if-feature」ステートメントを使用して後で参照できる機能名が定義されています（セクション7.20.2を参照）。 「if-feature」ステートメントでタグ付けされたスキーマノードは、サーバーが指定された機能式をサポートしていない限り、サーバーによって無視されます。 これにより、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」ステートメントで使用されます。
Bjorklund Standards Track [Page 128] RFC 7950 YANG 1.1 August 2016 In this example, a feature called "local-storage" represents the ability for a server 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 server does not report that it supports this feature, the "local-storage-limit" node is not supported.
この例では、「local-storage」と呼ばれる機能が、サーバーが何らかのローカルストレージにsyslogメッセージを保存する機能を表しています。 この機能は、「local-storage-limit」リーフをある種のローカルストレージの存在を条件とするために使用されます。 サーバーがこの機能をサポートしていることを報告しない場合、「local-storage-limit」ノードはサポートされません。
module example-syslog {
yang-version 1.1;
...
feature local-storage {
description
"This feature means that the server 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
server 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 server to support a feature that is dependent on any other features (i.e., the feature has one or more "if-feature" substatements), the server MUST also support all the dependent features.
サーバーが他の機能に依存する機能をサポートする（つまり、機能に1つ以上の "if-feature"サブステートメントがある）ために、サーバーはすべての依存機能もサポートする必要があります。
Bjorklund Standards Track [Page 129] RFC 7950 YANG 1.1 August 2016 7.20.1.1. The feature's Substatements
7.20.1.1。 機能のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
+--------------+---------+-------------+
7.20.2. The "if-feature" Statement
7.20.2。 「if-feature」ステートメント
The "if-feature" statement makes its parent statement conditional. The argument is a boolean expression over feature names. In this expression, a feature name evaluates to "true" if and only if the feature is supported by the server. The parent statement is implemented by servers where the boolean expression evaluates to "true".
「if-feature」ステートメントは、その親ステートメントを条件付きにします。 引数は、機能名に対するブール式です。 この式では、機能がサーバーでサポートされている場合にのみ、機能名が「true」と評価されます。 親ステートメントは、ブール式が「true」と評価されるサーバーによって実装されます。
The if-feature boolean expression syntax is formally defined by the rule "if-feature-expr" in Section 14. Parentheses are used to group expressions. When the expression is evaluated, the order of precedence is (highest precedence first): grouping (parentheses), "not", "and", "or".
if-featureブール式の構文は、セクション14のルール「if-feature-expr」によって正式に定義されています。 括弧は式をグループ化するために使用されます。 式が評価されるときの優先順位は、グループ化（括弧）、「not」、「and」、「or」（優先順位が最初）です。
If a prefix is present on a feature name in the boolean expression, the prefixed name 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.
ブール式の機能名に接頭辞が存在する場合、接頭辞付きの名前は、その接頭辞を使用してインポートされたモジュールで定義された機能、または接頭辞がローカルモジュールの接頭辞と一致する場合はローカルモジュールを参照します。 それ以外の場合、一致する名前の機能は、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
A leaf that is a list key MUST NOT have any "if-feature" statements.
リストキーであるリーフには、「if-feature」ステートメントを含めることはできません。
Bjorklund Standards Track [Page 130] RFC 7950 YANG 1.1 August 2016 7.20.2.1. Usage Example
7.20.2.1。 使用例
In this example, the container "target" is implemented if either the "outbound-tls" or "outbound-ssh" feature is supported by the server.
この例では、「outbound-tls」または「outbound-ssh」機能のいずれかがサーバーでサポートされている場合、コンテナー「target」が実装されます。
container target {
if-feature "outbound-tls or outbound-ssh";
...
}
The following examples are equivalent:
次の例は同等です。
if-feature "not foo or bar and baz";
if-feature "(not foo) or (bar and baz)";
7.20.3. The "deviation" Statement
7.20.3。 「偏差」ステートメント
The "deviation" statement defines a hierarchy of a module that the server 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 server or class of servers 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.
偏差は、サーバーまたはサーバーのクラスが標準から逸脱する方法を定義します。 これは、偏差が実装と標準との違いを知るためのメカニズムであるため、偏差が公開された標準の一部であってはならないことを意味します。
Server deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a server fails to follow a standard is no substitute for implementing the standard correctly. A server 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 server makes a choice to either 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.
ただし、特定のデバイスには、標準モジュールの一部をサポートするハードウェアまたはソフトウェアの機能がない場合があります。 これが発生すると、サーバーは、モジュールのサポートされていない部分を構成する試みを、疑いを持たないアプリケーションに報告されるエラーとして扱うか、それらの着信要求を無視するかを選択します。 どちらの選択も受け入れられません。
Bjorklund Standards Track [Page 131] RFC 7950 YANG 1.1 August 2016 Instead, YANG allows servers to document portions of a base module that are not supported, or that are supported but with different syntax, by using the "deviation" statement.
代わりに、YANGは、「偏差」ステートメントを使用して、サポートされていない、またはサポートされているが構文が異なる基本モジュールの部分をサーバーが文書化できるようにします。
After applying all deviations announced by a server, in any order, the resulting data model MUST still be valid.
サーバーによって発表されたすべての偏差を任意の順序で適用した後、結果のデータモデルは依然として有効である必要があります。
7.20.3.1. The deviation's Substatements
7.20.3.1。 偏差のサブステートメント
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| description | 7.21.3 | 0..1 |
| deviate | 7.20.3.2 | 1..n |
| reference | 7.21.4 | 0..1 |
+--------------+----------+-------------+
7.20.3.2. The "deviate" Statement
7.20.3.2。 「逸脱」ステートメント
The "deviate" statement defines how the server'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」ステートメントは、ターゲットノードのサーバーの実装が元の定義からどのように逸脱するかを定義します。 引数は、「サポートされていない」、「追加」、「置換」、または「削除」のいずれかの文字列です。
The argument "not-supported" indicates that the target node is not implemented by this server.
引数「not-supported」は、ターゲットノードがこのサーバーによって実装されていないことを示します。
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」は、ターゲットノードにプロパティを追加します。 追加するプロパティは、「deviate」ステートメントのサブステートメントによって識別されます。 プロパティが1度しか出現できない場合、そのプロパティはターゲットノードに存在してはなりません（MUST NOT）。
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.
引数「replace」は、ターゲットノードのプロパティを置き換えます。 置き換えるプロパティは、「deviate」ステートメントのサブステートメントによって識別されます。 置き換えるプロパティは、ターゲットノードに存在する必要があります。
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.
引数「delete」は、ターゲットノードからプロパティを削除します。 削除するプロパティは、「delete」ステートメントのサブステートメントによって識別されます。 サブステートメントのキーワードは、ターゲットノードの対応するキーワードと一致する必要があり、引数の文字列は、ターゲットノードの対応するキーワードの引数文字列と等しい必要があります。
Bjorklund Standards Track [Page 132]
RFC 7950 YANG 1.1 August 2016
+--------------+--------------+-------------+
| substatement | section | cardinality |
+--------------+--------------+-------------+
| config | 7.21.1 | 0..1 |
| default | 7.6.4, 7.7.4 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 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 |
+--------------+--------------+-------------+
The deviate's Substatements
If the target node has a property defined by an extension, this
property can be deviated if the extension allows deviations. See
Section 7.19 for details.
ターゲットノードに拡張機能で定義されたプロパティがある場合、拡張機能で逸脱が許可されていると、このプロパティが逸脱する可能性があります。 詳細については、セクション7.19を参照してください。
7.20.3.3. Usage Example
7.20.3.3。 使用例
In this example, the server is informing client applications that it does not support the "daytime" service in the style of RFC 867.
この例では、サーバーはクライアントアプリケーションにRFC 867のスタイルの「日中」サービスをサポートしていないことを通知しています。
module example-deviations {
yang-version 1.1;
namespace "urn:example:deviations";
prefix md;
import example-base {
prefix base;
}
deviation /base:system/base:daytime {
deviate not-supported;
}
...
}
A server would advertise both modules "example-base" and
"example-deviations".
サーバーは、「example-base」と「example-deviations」の両方のモジュールを通知します。
Bjorklund Standards Track [Page 133] RFC 7950 YANG 1.1 August 2016 The following example sets a server-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 server 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 server might remove this "must" constraint by doing:
サーバーは次のようにして、この「必須」の制約を削除する場合があります。
deviation /base:system {
deviate delete {
must "daytime or time";
}
}
7.21. Common Statements
7.21。 共通の声明
This section defines substatements common to several other statements.
このセクションでは、他のいくつかのステートメントに共通するサブステートメントを定義します。
7.21.1. The "config" Statement
7.21.1。 「config」ステートメント
The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration are part of configuration datastores.
「config」ステートメントは、ストリング「true」または「false」を引数として取ります。 「config」が「true」の場合、定義は構成を表します。 構成を表すデータノードは、構成データストアの一部です。
If "config" is "false", the definition represents state data. Data nodes representing state data are not part of configuration datastores.
「config」が「false」の場合、定義は状態データを表します。 状態データを表すデータノードは、構成データストアの一部ではありません。
Bjorklund Standards Track [Page 134] RFC 7950 YANG 1.1 August 2016 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.
「config」が指定されていない場合、デフォルトは親スキーマノードの「config」値と同じです。 親ノードがケースノードの場合、値はケースノードの親選択ノードと同じです。
If the top node does not specify a "config" statement, the default is "true".
最上位ノードが「config」ステートメントを指定しない場合、デフォルトは「true」です。
If a node has "config" set to "false", no node underneath it can have "config" set to "true".
ノードの「config」が「false」に設定されている場合、その下のノードで「config」を「true」に設定することはできません。
7.21.2. The "status" Statement
7.21.2。 「ステータス」ステートメント
The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete".
「ステータス」ステートメントは、「現在」、「非推奨」、「廃止」のいずれかの文字列を引数として取ります。
o "current" means that the definition is current and valid.
「現在」とは、定義が最新かつ有効であることを意味します。
o "deprecated" indicates an obsolete definition, but it permits
new/continued implementation in order to foster interoperability
with older/existing implementations.
「非推奨」は廃止された定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
o "obsolete" means that the definition is obsolete and SHOULD NOT be
implemented and/or can be removed from implementations.
「廃止された」とは、定義が廃止されており、実装してはならず（SHOULD NOT）、および/または実装から削除できることを意味します。
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
}
Bjorklund Standards Track [Page 135]
RFC 7950 YANG 1.1 August 2016
7.21.3. The "description" Statement
7.21.3。 「説明」ステートメント
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.
"description"ステートメントは、この定義の人間が読めるテキスト記述を含む文字列を引数として取ります。 テキストは、モジュール開発者が選択した1つまたは複数の言語で提供されます。 相互運用性のために、モジュールを使用するネットワーク管理者のコミュニティの間で広く理解されている言語を選択することをお勧めします。
7.21.4. The "reference" Statement
7.21.4。 「参照」ステートメント
The "reference" statement takes as an argument a string that is a human-readable 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";
...
}
7.21.5. The "when" Statement
7.21.5。 「いつ」ステートメント
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」と評価される場合、親データ定義ステートメントによって定義されたノードは有効です。 そうでなければ、そうではありません。
A leaf that is a list key MUST NOT have a "when" statement.
リストキーであるリーフには、「when」ステートメントを含めることはできません。
If a key leaf is defined in a grouping that is used in a list, the "uses" statement MUST NOT have a "when" statement.
キーリーフがリストで使用されるグループで定義されている場合、「uses」ステートメントに「when」ステートメントを含めることはできません。
See Section 8.3.2 for additional information.
詳細については、セクション8.3.2を参照してください。
Bjorklund Standards Track [Page 136] RFC 7950 YANG 1.1 August 2016 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. If no such node exists, the context node is the root node.
The accessible tree is tentatively altered during the processing
of the XPath expression by removing all instances (if any) of the
nodes added by the "augment" statement.
「when」ステートメントが「augment」ステートメントの子である場合、ターゲットノードがデータノードであれば、コンテキストノードはデータツリー内のaugmentのターゲットノードです。 それ以外の場合、コンテキストノードは、データノードでもあるターゲットノードに最も近い祖先ノードです。 そのようなノードが存在しない場合、コンテキストノードはルートノードです。 アクセス可能なツリーは、XPath式の処理中に、「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 node with the "when" statement that is also a data
node. If no such node exists, the context node is the root node.
The accessible tree is tentatively altered during the processing
of the XPath expression by removing all instances (if any) of the
nodes added by the "uses", "choice", or "case" statement.
"when"ステートメントが "uses"、 "choice"、または "case"ステートメントの子である場合、コンテキストノードは、データノードでもある "when"ステートメントを持つノードに最も近い祖先ノードです。 そのようなノードが存在しない場合、コンテキストノードはルートノードです。 アクセス可能なツリーは、XPath式の処理中に、「uses」、「choice」、または「case」ステートメントによって追加されたノードのすべてのインスタンス（存在する場合）を削除することにより、一時的に変更されます。
o If the "when" statement is a child of any other data definition
statement, the accessible tree is tentatively altered during the
processing of the XPath expression by replacing all instances of
the data node for which the "when" statement is defined with a
single dummy node with the same name, but with no value and no
children. If no such instance exists, the dummy node is
tentatively created. The context node is this dummy node.
「when」ステートメントが他のデータ定義ステートメントの子である場合、アクセス可能なツリーは、「when」ステートメントが定義されているデータノードのすべてのインスタンスを単一のダミーで置き換えることにより、XPath式の処理中に一時的に変更されます。 同じ名前で、値も子もないノード。 そのようなインスタンスが存在しない場合、ダミーノードが一時的に作成されます。 コンテキストノードはこのダミーノードです。
The result of the XPath expression is converted to a boolean value using the standard XPath rules.
XPath式の結果は、標準のXPathルールを使用してブール値に変換されます。
If the XPath expression references any node that also has associated "when" statements, those "when" expressions MUST be evaluated first. There MUST NOT be any circular dependencies among "when" expressions.
XPath式が「when」ステートメントも関連付けられているノードを参照する場合、それらの「when」式を最初に評価する必要があります。 「when」式の間に循環依存関係があってはなりません。
Note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator in the server. The "when" statement can very well be implemented with specially written code.
XPath式は概念的に評価されることに注意してください。 これは、実装がサーバーでXPathエバリュエーターを使用する必要がないことを意味します。 「when」ステートメントは、特別に記述されたコードで非常にうまく実装できます。
Bjorklund Standards Track [Page 137] RFC 7950 YANG 1.1 August 2016 8. Constraints
8.制約
8.1. Constraints on Data
8.1。 データの制約
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.
制約が構成データで定義されている場合、有効な構成データツリーでtrueでなければなりません。
o If the constraint is defined on state data, it MUST be true in a
valid state data tree.
制約が状態データに定義されている場合、有効な状態データツリーでtrueでなければなりません。
o If the constraint is defined on notification content, it MUST be
true in any notification data tree.
制約が通知コンテンツで定義されている場合、通知データツリーでtrueにする必要があります。
o If the constraint is defined on RPC or action input parameters, it
MUST be true in an invocation of the RPC or action operation.
制約がRPCまたはアクション入力パラメーターで定義されている場合、RPCまたはアクション操作の呼び出しで制約がtrueでなければなりません。
o If the constraint is defined on RPC or action output parameters,
it MUST be true in the RPC or action reply.
制約がRPCまたはアクション出力パラメーターで定義されている場合、RPCまたはアクション応答でtrueでなければなりません。
The following properties are true in all data trees:
次のプロパティは、すべてのデータツリーに当てはまります。
o All leaf data values MUST match the type constraints for the leaf,
including those defined in the type's "range", "length", and
"pattern" properties.
すべてのリーフデータ値は、タイプの「範囲」、「長さ」、および「パターン」プロパティで定義されたものを含め、リーフのタイプ制約と一致する必要があります。
o All key leafs MUST be present for all list entries.
すべてのキーリーフは、すべてのリストエントリに存在する必要があります。
o Nodes MUST be present for at most one case branch in all choices.
ノードは、すべての選択肢で最大1つのケースブランチに存在する必要があります。
o There MUST be no nodes tagged with "if-feature" present if the
"if-feature" expression evaluates to "false" in the server.
「if-feature」式がサーバーで「false」と評価される場合、「if-feature」でタグ付けされたノードが存在してはなりません（MUST）。
o There MUST be no nodes tagged with "when" present if the "when"
condition evaluates to "false" in the data tree.
「when」条件がデータツリーで「false」と評価される場合、「when」でタグ付けされたノードが存在してはなりません（MUST）。
The following properties are true in a valid data tree:
次のプロパティは、有効なデータツリーでtrueです。
o All "must" constraints MUST evaluate to "true".
すべての「必須」制約は「真」に評価される必要があります。
o All referential integrity constraints defined via the "path"
statement MUST be satisfied.
「パス」ステートメントを介して定義されたすべての参照整合性制約が満たされる必要があります。
o All "unique" constraints on lists MUST be satisfied.
リストに対するすべての「固有の」制約は満たされなければなりません。
Bjorklund Standards Track [Page 138]
RFC 7950 YANG 1.1 August 2016
o The "mandatory" constraint is enforced for leafs and choices,
unless the node or any of its ancestors has a "when" condition or
"if-feature" expression that evaluates to "false".
「必須」制約は、ノードまたはその祖先のいずれかに「when」条件または「false」と評価される「if-feature」式がない限り、葉と選択肢に適用されます。
o The "min-elements" and "max-elements" constraints are enforced for
lists and leaf-lists, unless the node or any of its ancestors has
a "when" condition or "if-feature" expression that evaluates to
"false".
「min-elements」および「max-elements」制約は、ノードまたはその祖先に「false」と評価される「when」条件または「if-feature」式がない限り、リストとリーフリストに適用されます。
The running configuration datastore MUST always be valid.
実行中の構成データストアは常に有効でなければなりません。
8.2. Configuration Data Modifications
8.2。 構成データの変更
o If a request creates configuration data nodes under a choice, any
existing nodes from other case branches in the data tree are
deleted by the server.
リクエストが選択の下に構成データノードを作成する場合、データツリー内の他のケースブランチからの既存のノードはサーバーによって削除されます。
o If a request modifies a configuration data node such that any
node's "when" expression becomes false, then the node in the data
tree with the "when" expression is deleted by the server.
リクエストによって構成データノードが変更され、ノードの「when」式がfalseになる場合、「when」式を含むデータツリー内のノードはサーバーによって削除されます。
8.3. NETCONF Constraint Enforcement Model
8.3。 NETCONF制約適用モデル
For configuration data, there are three windows when constraints MUST be enforced:
構成データの場合、制約を適用する必要があるのは3つのウィンドウです。
o during parsing of RPC payloads
RPCペイロードの解析中
o during processing of the <edit-config> operation
<edit-config>操作の処理中
o during validation
検証中
Each of these scenarios is considered in the following sections.
以下のセクションでは、これらの各シナリオについて検討します。
8.3.1. Payload Parsing
8.3.1。 ペイロードの解析
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 server 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 (Section 7.5.4.2) and error-message
(Section 7.5.4.1) associated with the constraint, if any exist.
タイプの「範囲」、「長さ」、および「パターン」プロパティで定義されたものを含め、リーフデータ値がリーフのタイプ制約と一致しない場合、サーバーは「無効な値」<エラータグで応答する必要があります > <rpc-error>内、および存在する場合は、制約に関連付けられたerror-app-tag（セクション7.5.4.2）およびerror-message（セクション7.5.4.1）
Bjorklund Standards Track [Page 139]
RFC 7950 YANG 1.1 August 2016
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>.
リストエントリのすべてのキーが存在しない場合、サーバーは<rpc-error>の「missing-element」<error-tag>で応答する必要があります。
o If data for more than one case branch of a choice is present, the
server MUST reply with a "bad-element" <error-tag> in the
<rpc-error>.
選択の複数のケースブランチのデータが存在する場合、サーバーは<rpc-error>の「bad-element」<error-tag>で応答する必要があります。
o If data for a node tagged with "if-feature" is present and the
"if-feature" expression evaluates to "false" in the server, the
server MUST reply with an "unknown-element" <error-tag> in the
<rpc-error>.
「if-feature」でタグ付けされたノードのデータが存在し、「if-feature」式がサーバーで「false」と評価される場合、サーバーは<内の「unknown-element」<error-tag>で応答する必要があります 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>.
「when」でタグ付けされたノードのデータが存在し、「when」条件が「false」と評価された場合、サーバーは<rpc-error>の「unknown-element」<error-tag>で応答する必要があります。
o For insert handling, if the values 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>.
挿入処理の場合、「before」および「after」属性の値が適切なキーリーフのタイプに対して無効である場合、サーバーは<rpc- エラー>。
o If the attributes "before" and "after" appear 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>.
"before"および "after"属性が、 "ordered-by"プロパティが "user"であるリストではない要素に出現する場合、サーバーは<内の "unknown-attribute" <error-tag>で応答する必要があります rpc-error>。
8.3.2. NETCONF <edit-config> Processing
8.3.2。 NETCONF <edit-config>処理
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 Create requests for existent data.
既存のデータに対するリクエストを作成します。
o Insert requests with "before" or "after" parameters that do not
exist.
存在しない「before」または「after」パラメータを含むリクエストを挿入します。
o Modification requests for nodes tagged with "when", and the "when"
condition evaluates to "false". In this case, the server MUST
reply with an "unknown-element" <error-tag> in the <rpc-error>.
「いつ」というタグが付けられたノードの変更リクエスト、および「いつ」条件は「false」と評価されます。 この場合、サーバーは<rpc-error>内の「unknown-element」<error-tag>で応答する必要があります。
Bjorklund Standards Track [Page 140] RFC 7950 YANG 1.1 August 2016 8.3.3. Validation
8.3.3。 検証
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 takes place.
データストア処理が完了すると、最終的なコンテンツはすべての検証制約に従う必要があります。 この検証処理は、データストアに応じて異なるタイミングで実行されます。 データストアが「実行中」または「起動」の場合、これらの制約は<edit-config>または<copy-config>操作の最後に適用する必要があります。 データストアが「候補」の場合、制約の適用は、<commit>または<validate>操作が行われるまで遅延されます。
9. Built-In Types
9.組み込み型
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 that are 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.5) and range restrictions of numeric types (Section 9.2.4).
さまざまな組み込み型とその派生型により、さまざまな種類のサブタイピングが可能になります。つまり、文字列の長さと正規表現の制限（セクション9.4.4および9.4.5）と数値型の範囲の制限（セクション9.2.4）です。
The lexical representation of a value of a certain type is used in the XML encoding and when specifying default values and numerical ranges in YANG modules.
特定のタイプの値の字句表現は、XMLエンコーディングで、およびYANGモジュールでデフォルト値と数値範囲を指定するときに使用されます。
9.1. Canonical Representation
9.1。 正規表現
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 server sends XML-encoded data, it MUST use the canonical form defined in this section. Other encodings may introduce alternate representations. Note, however, that values in the data tree are conceptually stored in the canonical representation as defined in this section. In particular, any XPath expression evaluations are done using the canonical form if the data type has a canonical form. If the data type does not have a canonical form, the format of the value MUST match the data type's lexical representation, but the exact format is implementation dependent.
サーバーがXMLエンコードされたデータを送信する場合、このセクションで定義されている正規形式を使用する必要があります。 他のエンコーディングでは代替表現が導入される場合があります。 ただし、データツリーの値は、このセクションで定義されているように、概念的には正規表現に格納されます。 特に、データ型が標準形式である場合、XPath式の評価は標準形式を使用して行われます。 データ型が標準形式を持たない場合、値の形式はデータ型の字句表現と一致する必要がありますが、正確な形式は実装に依存します。
Bjorklund Standards Track [Page 141] RFC 7950 YANG 1.1 August 2016 Some types have a lexical representation that depends on the encoding, e.g., the XML context in which they occur. These types do not have a canonical form.
一部のタイプには、エンコーディングに依存する字句表現があります（例：発生するXMLコンテキスト）。 これらの型には、標準的な形式はありません。
9.2. The Integer Built-In Types
9.2。 整数の組み込み型
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.
int16 represents integer values between -32768 and 32767,
inclusively.
int32 represents integer values between -2147483648 and 2147483647,
inclusively.
int64 represents integer values between -9223372036854775808 and
9223372036854775807, inclusively.
uint8 represents integer values between 0 and 255, inclusively.
uint16 represents integer values between 0 and 65535, inclusively.
uint32 represents integer values between 0 and 4294967295,
inclusively.
uint64 represents integer values between 0 and 18446744073709551615,
inclusively.
9.2.1. Lexical Representation
9.2.1。 字句表現
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.
整数値は、オプションの符号（「+」または「-」）としてレキシカルに表現され、その後に一連の10進数字が続きます。 符号を指定しない場合、「+」が想定されます。
For convenience, when specifying a default value for an integer in a
YANG module, an alternative lexical representation can be used that
represents the value in a hexadecimal or octal notation. The
hexadecimal notation consists of an optional sign ("+" or "-"),
followed by the characters "0x", followed by a number of hexadecimal
digits where letters may be uppercase or lowercase. The octal
notation consists of an optional sign ("+" or "-"), followed by the
character "0", followed by a number of octal digits.
便宜上、YANGモジュールで整数のデフォルト値を指定する場合、16進または8進表記で値を表す代替字句表現を使用できます。 16進表記は、オプションの符号（「+」または「-」）と、それに続く文字「0x」、それに続く文字が大文字または小文字の16進数の数で構成されます。 8進数表記は、オプションの符号（「+」または「-」）と、それに続く文字「0」、それに続く8進数の数で構成されます。
Bjorklund Standards Track [Page 142]
RFC 7950 YANG 1.1 August 2016
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 encoding, an
integer is always interpreted as a decimal number, and leading zeros
are allowed.
YANGモジュールのデフォルト値に先行ゼロ（ "0"）がある場合、それは8進数として解釈されることに注意してください。 XMLエンコーディングでは、整数は常に10進数として解釈され、先行ゼロが許可されます。
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
// illegal values
- 1 // illegal intermediate space
9.2.2. Canonical Form
9.2.2。 正規形
The canonical form of a positive integer does not include the sign "+". Leading zeros are prohibited. The value zero is represented as "0".
正の整数の正規形には、記号「+」は含まれません。 先行ゼロは禁止されています。 値ゼロは「0」として表されます。
9.2.3. Restrictions
9.2.3。 制限事項
All integer types can be restricted with the "range" statement (Section 9.2.4).
すべての整数型は、「範囲」ステートメント（セクション9.2.4）で制限できます。
9.2.4. The "range" Statement
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 them.
「範囲」ステートメントは、「タイプ」ステートメントのオプションのサブステートメントであり、引数として範囲式ストリングを受け取ります。 整数および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 a type that is already range-restricted, the new restriction MUST be equally limiting or more limiting, i.e., 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 Bjorklund Standards Track [Page 143] RFC 7950 YANG 1.1 August 2016 match the type being restricted or be one of the special values "min" or "max". "min" and "max" mean the minimum and maximum values accepted for the type being restricted, respectively.
範囲は、明示的な値、または下限を含む2つの連続するドットで構成されます ".. 、および上限を含む境界。 複数の値または範囲を「|」で区切って指定できます。 複数の値または範囲を指定する場合、それらはすべてばらばらである必要があり、昇順でなければなりません。 範囲の制限がすでに範囲制限されているタイプに適用される場合、新しい制限は同様に制限またはより制限的でなければなりません（つまり、下限を上げる、上限を下げる、明示的な値または範囲を削除する、または範囲を複数に分割する） 中間ギャップのある範囲。 範囲式で指定される各明示的な値と範囲境界値は、制限されるタイプと一致するか、特別な値「min」または「max」のいずれかである必要があります。 「min」と「max」は、それぞれ制限されるタイプで受け入れられる最小値と最大値を意味します。
The range expression syntax is formally defined by the rule "range-arg" in Section 14.
範囲式の構文は、セクション14のルール「range-arg」によって正式に定義されています。
9.2.4.1. The range's Substatements
9.2.4.1。 範囲のサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+
9.2.5. Usage Example
9.2.5。 使用例
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";
}
}
9.3. The decimal64 Built-In Type
9.3。 decimal64組み込みタイプ
The decimal64 built-in 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組み込み型は実数のサブセットを表し、10進数で表すことができます。 decimal64の値空間は、64ビットの符号付き整数に10の負のべき乗を掛けることによって取得できる数値のセットです。つまり、「ix 10 ^ -n」として表現できます。 1から18まで。
Bjorklund Standards Track [Page 144] RFC 7950 YANG 1.1 August 2016 9.3.1. Lexical Representation
9.3.1。 字句表現
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値は、字句的にオプションの符号（ "+"または "-"）として表され、その後に一連の10進数字が続き、オプションでピリオド（ '）が続きます。 ）10進標識および10進数字のシーケンスとして。 符号を指定しない場合、「+」が想定されます。
9.3.2. Canonical Form
9.3.2。 正規形
The canonical form of a positive decimal64 value 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".
正のdecimal64値の正規形式には、記号「+」は含まれません。 小数点が必要です。 先頭と末尾のゼロは禁止されていますが、小数点の前後に少なくとも1桁はなければならないという規則に従います。 値ゼロは「0.0」と表されます。
9.3.3. Restrictions
9.3.3。 制限事項
A decimal64 type can be restricted with the "range" statement (Section 9.2.4).
decimal64型は、 "range"ステートメント（セクション9.2.4）で制限できます。
9.3.4. The "fraction-digits" Statement
9.3.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」の場合、「type」ステートメントのサブステートメントである「fraction-digits」ステートメントが存在する必要があります。 1から18までの整数を引数として取ります。 これは、値のスペースを "i x 10 ^ -n"で表される数値に制限することにより、decimal64タイプの値間の最小差のサイズを制御します。ここで、nは小数桁引数です。
Bjorklund Standards Track [Page 145] RFC 7950 YANG 1.1 August 2016 The following table lists the minimum and maximum values 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 |
+----------------+-----------------------+----------------------+
9.3.5. Usage Example
9.3.5。 使用例
typedef my-decimal {
type decimal64 {
fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max";
}
}
9.4. The string Built-In Type
9.4。 文字列の組み込みタイプ
The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. The string syntax is formally defined by the rule "yang-string" in Section 14.
文字列組み込み型は、YANGで人間が読める文字列を表します。 有効な文字は、UnicodeおよびISO / IEC 10646 [ISO.10646]文字で、タブ、キャリッジリターン、ラインフィードが含まれますが、他のC0制御文字、サロゲートブロック、および非文字は含まれません。 文字列の構文は、セクション14の「yang-string」というルールによって正式に定義されています。
9.4.1. Lexical Representation
9.4.1。 字句表現
A string value is lexically represented as character data in the XML encoding.
文字列値は、XMLエンコーディングで字句的に文字データとして表されます。
Bjorklund Standards Track [Page 146] RFC 7950 YANG 1.1 August 2016 9.4.2. Canonical Form
9.4.2。 正規形
The canonical form is the same as the lexical representation. No Unicode normalization of string values is performed.
正規形は字句表現と同じです。 文字列値のUnicode正規化は実行されません。
9.4.3. Restrictions
9.4.3。 制限事項
A string can be restricted with the "length" (Section 9.4.4) and "pattern" (Section 9.4.5) statements.
文字列は、 "length"（セクション9.4.4）および "pattern"（セクション9.4.5）ステートメントで制限できます。
9.4.4. The "length" Statement
9.4.4。 「長さ」ステートメント
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 types "string" and "binary" or types derived from them.
「type」ステートメントのオプションのサブステートメントである「length」ステートメントは、長さ式ストリングを引数として取ります。 これは、組み込み型「文字列」と「バイナリ」またはそれらから派生した型を制限するために使用されます。
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 a type that is already length-restricted, the new restriction MUST be equally limiting or more limiting, i.e., 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 lengths accepted for the type being restricted, respectively. An implementation is not required to support a length value larger than 18446744073709551615.
長さの範囲は、明示的な値、または下限、2つの連続するドット "..、および上限で構成されます。 複数の値または範囲を「|」で区切って指定できます。 長さ制限値は負であってはなりません。 複数の値または範囲を指定する場合、それらはすべてばらばらである必要があり、昇順でなければなりません。 長さ制限がすでに長さ制限されているタイプに適用されている場合、新しい制限は同様に制限またはより制限されている必要があります。つまり、下限の引き上げ、上限の削減、明示的な長さの値または範囲の削除、または範囲の分割 中間ギャップのある複数の範囲。 長さの値は、負でない整数、または特別な値「min」または「max」のいずれかです。 「min」と「max」は、それぞれ制限されるタイプで受け入れられる最小長と最大長を意味します。 18446744073709551615より大きい長さの値をサポートするための実装は必要ありません。
The length expression syntax is formally defined by the rule "length-arg" in Section 14.
長さ式の構文は、セクション14のルール「length-arg」によって正式に定義されています。
9.4.4.1. The length's Substatements
9.4.4.1。 長さのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+
Bjorklund Standards Track [Page 147]
RFC 7950 YANG 1.1 August 2016
9.4.5. The "pattern" Statement
9.4.5。 「パターン」ステートメント
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.
「type」ステートメントのオプションのサブステートメントである「pattern」ステートメントは、[XSD-TYPES]で定義されているように、引数として正規表現文字列を取ります。 これは、組み込み型「string」または「string」から派生した型を、パターンに一致する値に制限するために使用されます。
If the type has multiple "pattern" statements, the expressions are ANDed together, i.e., all such expressions have to match.
タイプに複数の「パターン」ステートメントがある場合、式はAND演算されます。つまり、そのような式はすべて一致する必要があります。
If a pattern restriction is applied to a type that is already pattern-restricted, values must match all patterns in the base type, in addition to the new patterns.
パターン制限がすでにパターン制限されているタイプに適用される場合、値は、新しいパターンに加えて、基本タイプのすべてのパターンと一致する必要があります。
9.4.5.1. The pattern's Substatements
9.4.5.1。 パターンのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| modifier | 9.4.6 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+
9.4.6. The "modifier" Statement
9.4.6。 「修飾子」ステートメント
The "modifier" statement, which is an optional substatement to the "pattern" statement, takes as an argument the string "invert-match".
「パターン」ステートメントのオプションのサブステートメントである「修飾子」ステートメントは、ストリング「invert-match」を引数として受け取ります。
If a pattern has the "invert-match" modifier present, the type is restricted to values that do not match the pattern.
パターンに「invert-match」修飾子が存在する場合、タイプはパターンに一致しない値に制限されます。
Bjorklund Standards Track [Page 148] RFC 7950 YANG 1.1 August 2016 9.4.7. Usage Example
9.4.7。 使用例
With the following typedef:
次のtypedefを使用します。
typedef my-base-str-type {
type string {
length "1..255";
}
}
the following refinement is legal:
次の改良は合法です：
type my-base-str-type {
// legal length refinement
length "11 | 42..max"; // 11 | 42..255
}
and the following refinement is illegal:
次の改良は違法です：
type my-base-str-type {
// illegal length refinement
length "1..999";
}
With the following type:
次のタイプで：
type string {
length "0..4";
pattern "[0-9a-fA-F]*";
}
the following strings match:
次の文字列が一致します。
AB // legal
9A00 // legal
and the following strings do not match:
次の文字列は一致しません：
00ABAB // illegal, too long
xx00 // illegal, bad characters
Bjorklund Standards Track [Page 149]
RFC 7950 YANG 1.1 August 2016
With the following type:
次のタイプで：
type string {
length "1..max";
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '[xX][mM][lL].*' {
modifier invert-match;
}
}
the following string matches:
次の文字列が一致します。
enabled // legal
and the following strings do not match:
次の文字列は一致しません：
10-mbit // illegal, starts with a number
xml-element // illegal, starts with illegal sequence
9.5. The boolean Built-In Type
9.5。 ブール組み込みタイプ
The boolean built-in type represents a boolean value.
ブールの組み込みタイプはブール値を表します。
9.5.1. Lexical Representation
9.5.1。 字句表現
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」の値を持つ文字列です。 これらの値は小文字でなければなりません。
9.5.2. Canonical Form
9.5.2。 正規形
The canonical form is the same as the lexical representation.
正規形は字句表現と同じです。
9.5.3. Restrictions
9.5.3。 制限事項
A boolean cannot be restricted.
ブール値は制限できません。
9.6. The enumeration Built-In Type
9.6。 列挙型組み込みタイプ
The enumeration built-in type represents values from a set of assigned names.
列挙型組み込みタイプは、割り当てられた名前のセットからの値を表します。
9.6.1. Lexical Representation
9.6.1。 字句表現
The lexical representation of an enumeration value is the assigned name string.
列挙値の字句表現は、割り当てられた名前の文字列です。
Bjorklund Standards Track [Page 150] RFC 7950 YANG 1.1 August 2016 9.6.2. Canonical Form
9.6.2。 正規形
The canonical form is the assigned name string.
正規形式は、割り当てられた名前の文字列です。
9.6.3. Restrictions
9.6.3。 制限事項
An enumeration can be restricted with one or more "enum" (Section 9.6.4) statements, which enumerate a subset of the values for the base type.
列挙は、基本タイプの値のサブセットを列挙する1つ以上の「列挙」（セクション9.6.4）ステートメントで制限できます。
9.6.4. The "enum" Statement
9.6.4。 「列挙型」ステートメント
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 that is the assigned name. The string MUST NOT be zero-length and MUST NOT have any leading or trailing whitespace characters (any Unicode character with the "White_Space" property). The use of Unicode control codes SHOULD be avoided.
タイプが「列挙」の場合、「タイプ」ステートメントのサブステートメントである「列挙」ステートメントが存在する必要があります。 これは、列挙型の割り当てられた各名前を指定するために繰り返し使用されます。 割り当てられた名前である文字列を引数として受け取ります。 文字列の長さは0であってはならず、先頭または末尾の空白文字（ "White_Space"プロパティを持つUnicode文字）があってはなりません（MUST NOT）。 Unicode制御コードの使用は避けてください。
The statement is optionally followed by a block of substatements that holds detailed enum information.
ステートメントの後には、オプションの詳細な列挙情報を保持するサブステートメントのブロックが続きます。
All assigned names in an enumeration MUST be unique.
列挙で割り当てられた名前はすべて一意である必要があります。
When an existing enumeration type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The value of such an assigned name MUST NOT be changed.
既存の列挙型が制限されている場合、新しい型の割り当てられた名前のセットは、基本型の割り当てられた名前のセットのサブセットである必要があります。 そのような割り当てられた名前の値は変更してはなりません。
9.6.4.1. The enum's Substatements
9.6.4.1。 列挙型のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 151]
RFC 7950 YANG 1.1 August 2016
9.6.4.2. The "value" Statement
9.6.4.2。 「値」ステートメント
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.
オプションの「value」ステートメントは、整数値をenumに割り当てられた名前に関連付けるために使用されます。 この整数値は-2147483648～2147483647の範囲内である必要があり、列挙型内で一意である必要があります。
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 (i.e., the highest enum value, implicit or explicit, prior to the current "enum" substatement in the parent "type" statement).
値が指定されていない場合は、自動的に割り当てられます。 「列挙型」サブステートメントが最初に定義されたものである場合、割り当てられる値はゼロ（0）です。 それ以外の場合、割り当てられた値は、現在の最高列挙値（つまり、親「type」ステートメントの現在の「列挙」サブステートメントの前の暗黙または明示の最高列挙値）よりも1つ大きくなります。
Note that the presence of an "if-feature" statement in an "enum" statement does not affect the automatically assigned value.
「enum」ステートメントに「if-feature」ステートメントが存在しても、自動的に割り当てられる値には影響しません。
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に等しい場合、現在の最高値を持つサブステートメントに続く「列挙型」サブステートメントに列挙値を指定する必要があります。
When an existing enumeration type is restricted, the "value" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type.
既存の列挙型が制限されている場合、「値」ステートメントは基本タイプと同じ値を持つか、存在しない必要があります。その場合、値は基本タイプと同じです。
9.6.5. Usage Example
9.6.5。 使用例
leaf myenum {
type enumeration {
enum zero;
enum one;
enum seven {
value 7;
}
}
}
The lexical representation of the leaf "myenum" with
value "seven" is:
値「seven」を持つリーフ「myenum」の字句表現は次のとおりです。
<myenum>seven</myenum>
Bjorklund Standards Track [Page 152]
RFC 7950 YANG 1.1 August 2016
With the following typedef:
次のtypedefを使用します。
typedef my-base-enumeration-type {
type enumeration {
enum white {
value 1;
}
enum yellow {
value 2;
}
enum red {
value 3;
}
}
}
the following refinement is legal:
次の改良は合法です：
type my-base-enumeration-type {
// legal enum refinement
enum yellow;
enum red {
value 3;
}
}
and the following refinement is illegal:
次の改良は違法です：
type my-base-enumeration-type {
// illegal enum refinement
enum yellow {
value 4; // illegal value change
}
enum black; // illegal addition of new name
}
Bjorklund Standards Track [Page 153]
RFC 7950 YANG 1.1 August 2016
The following example shows how an "enum" can be tagged with
"if-feature", making the value legal only on servers that advertise
the corresponding feature:
次の例は、「列挙型」を「if-feature」でタグ付けして、対応する機能をアドバタイズするサーバーでのみ値を正当にする方法を示しています。
type enumeration {
enum tcp;
enum ssh {
if-feature ssh;
}
enum tls {
if-feature tls;
}
}
9.7. The bits Built-In Type
9.7。 ビット組み込みタイプ
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から始まる小さな整数の位置番号によって識別されるフラグのセットです。 各ビット番号には名前が割り当てられています。
When an existing bits type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The bit position of such an assigned name MUST NOT be changed.
既存のビットタイプが制限されている場合、新しいタイプの割り当てられた名前のセットは、基本タイプの割り当てられた名前のセットのサブセットである必要があります。 そのような割り当てられた名前のビット位置は変更してはなりません。
9.7.1. Restrictions
9.7.1。 制限事項
A bits type can be restricted with the "bit" (Section 9.7.4) statement.
ビットタイプは、「ビット」（セクション9.7.4）ステートメントで制限できます。
9.7.2. Lexical Representation
9.7.2。 字句表現
The lexical representation of the bits type is a space-separated list of the names of the bits that are set. A zero-length string thus represents a value where no bits are set.
ビットタイプの字句表現は、設定されているビットの名前のスペース区切りリストです。 したがって、長さがゼロの文字列は、ビットが設定されていない値を表します。
9.7.3. Canonical Form
9.7.3。 正規形
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を参照）。
Bjorklund Standards Track [Page 154] RFC 7950 YANG 1.1 August 2016 9.7.4. The "bit" Statement
9.7.4。 「ビット」ステートメント
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.
ビットタイプで割り当てられた名前はすべて一意である必要があります。
9.7.4.1. The bit's Substatements
9.7.4.1。 ビットのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| position | 9.7.4.2 | 0..1 |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
+--------------+---------+-------------+
9.7.4.2. The "position" Statement
9.7.4.2。 「ポジション」ステートメント
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.
オプションの「position」ステートメントは、仮想ビットフィールド内のビットの位置を指定する負でない整数値を引数として取ります。 位置の値は0から4294967295の範囲でなければならず、ビットタイプ内で一意である必要があります。
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 (i.e., the highest bit position, implicit or explicit, prior to the current "bit" substatement in the parent "type" statement).
ビット位置が指定されていない場合は、自動的に割り当てられます。 「ビット」サブステートメントが最初に定義されたものである場合、割り当てられる値はゼロ（0）です。 それ以外の場合、割り当てられた値は、現在の最高ビット位置（つまり、親「type」ステートメントの現在の「ビット」サブステートメントの前の暗黙的または明示的な最高ビット位置）より1つ大きくなります。
Note that the presence of an "if-feature" statement in a "bit" statement does not affect the automatically assigned position.
「bit」ステートメントに「if-feature」ステートメントが存在しても、自動的に割り当てられる位置には影響しないことに注意してください。
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に等しい場合、現在の最高位置値を持つものに続く「ビット」サブステートメントに位置値を指定する必要があります。
When an existing bits type is restricted, the "position" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type.
既存のビットタイプが制限されている場合、「position」ステートメントは基本タイプと同じ値を持つか、存在しない必要があります。その場合、値は基本タイプと同じです。
Bjorklund Standards Track [Page 155] RFC 7950 YANG 1.1 August 2016 9.7.5. Usage Example
9.7.5。 使用例
Given the following typedef and leaf:
次のtypedefとリーフがあるとします。
typedef mybits-type {
type bits {
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
bit ten-mb-only {
position 2;
}
}
}
leaf mybits {
type mybits-type;
default "auto-sense-speed";
}
The lexical representation of this leaf with bit values disable-nagle
and ten-mb-only set would be:
ビット値disable-nagleと10 mbのみが設定されたこのリーフの字句表現は次のようになります。
<mybits>disable-nagle ten-mb-only</mybits>
The following example shows a legal refinement of this type:
次の例は、このタイプの法的改良を示しています。
type mybits-type {
// legal bit refinement
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
}
Bjorklund Standards Track [Page 156]
RFC 7950 YANG 1.1 August 2016
and the following refinement is illegal:
次の改良は違法です：
type mybits-type {
// illegal bit refinement
bit disable-nagle {
position 2; // illegal position change
}
bit hundred-mb-only; // illegal addition of new name
}
9.8. The binary Built-In Type
9.8。 バイナリ組み込み型
The binary built-in type represents any binary data, i.e., a sequence of octets.
バイナリ組み込みタイプは、任意のバイナリデータ、つまりオクテットのシーケンスを表します。
9.8.1. Restrictions
9.8.1。 制限事項
A binary type can be restricted with the "length" (Section 9.4.4) statement. The length of a binary value is the number of octets it contains.
バイナリ型は、 "length"（9.4.4節）ステートメントで制限できます。 バイナリ値の長さは、含まれるオクテットの数です。
9.8.2. Lexical Representation
9.8.2。 字句表現
Binary values are encoded with the base64 encoding scheme (see Section 4 in [RFC4648]).
バイナリ値は、base64エンコードスキームでエンコードされます（[RFC4648]のセクション4を参照）。
9.8.3. Canonical Form
9.8.3。 正規形
The canonical form of a binary value follows the rules of "Base 64 Encoding" in [RFC4648].
バイナリ値の標準形式は、[RFC4648]の「Base 64エンコーディング」の規則に従います。
9.9. The leafref Built-In Type
9.9。 leafref組み込みタイプ
The leafref built-in type is restricted to the value space of some leaf or leaf-list node in the schema tree and optionally further restricted by corresponding instance nodes in the data tree. The "path" substatement (Section 9.9.2) is used to identify the referred leaf or leaf-list node in the schema tree. The value space of the referring node is the value space of the referred node.
leafref組み込み型は、スキーマツリー内の一部のリーフノードまたはリーフリストノードの値スペースに制限され、オプションで、データツリー内の対応するインスタンスノードによってさらに制限されます。 「パス」サブステートメント（セクション9.9.2）は、スキーマツリーで参照されているリーフまたはリーフリストノードを識別するために使用されます。 参照ノードの値空間は、参照ノードの値空間です。
If the "require-instance" property (Section 9.9.3) is "true", there MUST exist a node in the data tree, or a node with a default value in use (see Sections 7.6.1 and 7.7.2), of the referred schema tree leaf or leaf-list node with the same value as the leafref value in a valid data tree.
「require-instance」プロパティ（セクション9.9.3）が「true」の場合、データツリーにノード、またはデフォルト値が使用されているノードが存在している必要があります（セクション7.6.1および7.7.2を参照）。 有効なデータツリー内のleafref値と同じ値を持つ、参照されるスキーマツリーリーフまたはリーフリストノードの。
Bjorklund Standards Track [Page 157] RFC 7950 YANG 1.1 August 2016 If the referring node represents configuration data and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration.
参照ノードが構成データを表し、「require-instance」プロパティ（セクション9.9.3）が「true」の場合、参照ノードも構成を表す必要があります。
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.20.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features.
leafrefが参照するリーフが1つ以上の機能に基づいて条件付きである場合（セクション7.20.2を参照）、leafrefタイプのリーフも、少なくとも同じ機能セットに基づいて条件付きである必要があります。
9.9.1. Restrictions
9.9.1。 制限事項
A leafref can be restricted with the "require-instance" statement (Section 9.9.3).
leafrefは、「require-instance」ステートメント（セクション9.9.3）で制限できます。
9.9.2. The "path" Statement
9.9.2。 「パス」ステートメント
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.
「type」ステートメントのサブステートメントである「path」ステートメントは、タイプが「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 14.
パス引数の構文は、XPath省略構文のサブセットです。 述語は、リストエントリのキーノードの値を制約するためにのみ使用されます。 各述語は、キーごとに正確に1つの等価テストで構成され、リストに複数のキーがある場合、複数の隣接する述語が存在する場合があります。 構文は、セクション14のルール「path-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 "require-instance" property is "true", this node set MUST be non-empty.
「パス」式は、0、1、またはそれ以上のノードで構成されるノードセットに評価されます。 「require-instance」プロパティが「true」の場合、このノードセットは空ではない必要があります。
The "path" 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 "path" statement is defined within a typedef, the context
node is the leaf or leaf-list node in the data tree that
references the typedef.
「パス」ステートメントがtypedef内で定義されている場合、コンテキストノードは、typedefを参照するデータツリーのリーフノードまたはリーフリストノードです。
o Otherwise, the context node is the node in the data tree for which
the "path" statement is defined.
それ以外の場合、コンテキストノードは、「パス」ステートメントが定義されているデータツリー内のノードです。
Bjorklund Standards Track [Page 158] RFC 7950 YANG 1.1 August 2016 9.9.3. The "require-instance" Statement
9.9.3。 「require-instance」ステートメント
The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "instance-identifier" or "leafref". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true".
「require-instance」ステートメントは、「type」ステートメントのサブステートメントであり、タイプが「instance-identifier」または「leafref」の場合に存在する場合があります。 引数として文字列「true」または「false」を取ります。 このステートメントが存在しない場合、デフォルトで「true」に設定されます。
If "require-instance" is "true", it means that the instance being referred to MUST exist for the data to be valid. This constraint is enforced according to the rules in Section 8.
「require-instance」が「true」の場合、データが有効であるためには、参照されているインスタンスが存在しなければならないことを意味します。 この制約は、セクション8のルールに従って実施されます。
If "require-instance" is "false", it means that the instance being referred to MAY exist in valid data.
「require-instance」が「false」の場合、参照されているインスタンスが有効なデータに存在する可能性があることを意味します。
9.9.4. Lexical Representation
9.9.4。 字句表現
A leafref value is lexically represented the same way as the leaf it references represents its value.
leafref値は、参照する葉がその値を表すのと同じ方法で字句的に表現されます。
9.9.5. Canonical Form
9.9.5。 正規形
The canonical form of a leafref is the same as the canonical form of the leaf it references.
leafrefの標準形は、参照する葉の標準形と同じです。
9.9.6. Usage Example
9.9.6。 使用例
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;
}
}
}
Bjorklund Standards Track [Page 159]
RFC 7950 YANG 1.1 August 2016
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";
}
}
}
Bjorklund Standards Track [Page 160]
RFC 7950 YANG 1.1 August 2016
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;
}
...
}
Bjorklund Standards Track [Page 161]
RFC 7950 YANG 1.1 August 2016
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つのleafrefを定義しています。
notification link-failure {
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf admin-status {
type leafref {
path "/interface[name = current()/../if-name]"
+ "/admin-status";
}
}
}
Bjorklund Standards Track [Page 162]
RFC 7950 YANG 1.1 August 2016
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="urn:example:system">
<if-name>eth0</if-name>
<admin-status>up</admin-status>
</link-failure>
</notification>
9.10. The identityref Built-In Type
9.10。 identityref組み込み型
The identityref built-in type is used to reference an existing identity (see Section 7.18).
identityref組み込みタイプは、既存のIDを参照するために使用されます（7.18節を参照）。
9.10.1. Restrictions
9.10.1。 制限事項
An identityref cannot be restricted.
identityrefを制限することはできません。
9.10.2. The identityref's "base" Statement
9.10.2。 identityrefの「ベース」ステートメント
The "base" statement, which is a substatement to the "type" statement, MUST be present at least once 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.
「type」ステートメントのサブステートメントである「base」ステートメントは、タイプが「identityref」の場合、少なくとも1回は存在する必要があります。 引数は、「identity」ステートメントで定義されているIDの名前です。 ID名にプレフィックスが存在する場合、そのプレフィックスは、そのプレフィックスを使用してインポートされたモジュールで定義されたIDを指します。 それ以外の場合、一致する名前のIDは、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
Valid values for an identityref are any identities derived from all the identityref's base identities. On a particular server, the valid values are further restricted to the set of identities defined in the modules implemented by the server.
identityrefの有効な値は、すべてのidentityrefの基本IDから派生したIDです。 特定のサーバーでは、有効な値は、サーバーによって実装されたモジュールで定義されたIDのセットにさらに制限されます。
9.10.3. Lexical Representation
9.10.3。 字句表現
An identityref is lexically represented 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.
identityrefは、[XML-NAMES]で定義されているように、参照されるIDの修飾名として字句的に表現されます。 プレフィックスが存在しない場合、identityrefの名前空間は、identityref値を含む要素に有効なデフォルトの名前空間です。
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, or the prefix for the current module if the identity is defined in the Bjorklund Standards Track [Page 163] RFC 7950 YANG 1.1 August 2016 current module or one of its submodules. Otherwise, an identity with the matching name MUST be defined in the current module or one of its submodules.
identityrefに「default」ステートメントを使用してデフォルト値を指定すると、デフォルト値のID名にプレフィックスが付いている場合があります。 ID名にプレフィックスが存在する場合、そのプレフィックスでインポートされたモジュールで定義されたID、または現在のモジュールまたはそのサブモジュールの1つでIDが定義されている場合は現在のモジュールのプレフィックスを参照します。 それ以外の場合、一致する名前のIDは、現在のモジュールまたはそのサブモジュールの1つで定義する必要があります。
The string value of a node of type "identityref" in a "must" or "when" XPath expression is the referred identity's qualified name with the prefix present. If the referred identity is defined in an imported module, the prefix in the string value is the prefix defined in the corresponding "import" statement. Otherwise, the prefix in the string value is the prefix for the current module.
「必須」または「いつ」のXPath式のタイプ「identityref」のノードのストリング値は、プレフィックスが存在する参照IDの修飾名です。 参照されたIDがインポートされたモジュールで定義されている場合、文字列値のプレフィックスは、対応する「インポート」ステートメントで定義されたプレフィックスです。 それ以外の場合、文字列値のプレフィックスは現在のモジュールのプレフィックスです。
9.10.4. Canonical Form
9.10.4。 正規形
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
字句形式は値が発生するXMLコンテキストに依存するため、この型には標準形式がありません。
9.10.5. Usage Example
9.10.5。 使用例
With the identity definitions in Section 7.18.3 and the following module:
セクション7.18.3のID定義と次のモジュールを使用します。
module example-my-crypto {
yang-version 1.1;
namespace "urn:example:my-crypto";
prefix mc;
import "example-crypto-base" {
prefix "crypto";
}
identity aes {
base "crypto:crypto-alg";
}
leaf crypto {
type identityref {
base "crypto:crypto-alg";
}
}
container aes-parameters {
when "../crypto = 'mc:aes'";
...
}
}
Bjorklund Standards Track [Page 164]
RFC 7950 YANG 1.1 August 2016
the following is an example of how the leaf "crypto" can be encoded,
if the value is the "des3" identity defined in the "des" module:
以下は、値が「des」モジュールで定義された「des3」識別である場合、リーフ「crypto」をエンコードする方法の例です。
<crypto xmlns:des="urn:example: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:
エンコーディングで使用されるプレフィックスは、各インスタンスのエンコーディングに対してローカルです。 つまり、同じidentityrefは、実装によって異なる方法でエンコードされる可能性があります。 たとえば、次の例は上記と同じリーフをエンコードします。
<crypto xmlns:x="urn:example:des">x:des3</crypto>
If the "crypto" leaf's value is instead "aes", defined in the
"example-my-crypto" module, it can be encoded as:
「crypto」リーフの値が「aes」であり、「example-my-crypto」モジュールで定義されている場合、次のようにエンコードできます。
<crypto xmlns:mc="urn:example:my-crypto">mc:aes</crypto>
or, using the default namespace:
または、デフォルトの名前空間を使用します。
<crypto>aes</crypto>
9.11. The empty Built-In Type
9.11。 空の組み込みタイプ
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.
空のタイプにデフォルト値を設定することはできません。
9.11.1. Restrictions
9.11.1。 制限事項
An empty type cannot be restricted.
空のタイプは制限できません。
9.11.2. Lexical Representation
9.11.2。 字句表現
Not applicable.
適用できません。
9.11.3. Canonical Form
9.11.3。 正規形
Not applicable.
適用できません。
Bjorklund Standards Track [Page 165] RFC 7950 YANG 1.1 August 2016 9.11.4. Usage Example
9.11.4。 使用例
With the following leaf:
次の葉を持つ：
leaf enable-qos {
type empty;
}
the following is an example of a valid encoding if the leaf exists:
以下は、リーフが存在する場合の有効なエンコードの例です。
<enable-qos/>
9.12. The union Built-In Type
9.12。 ユニオン組み込み型
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 repeatedly used to specify each member type of the union. It takes as an argument a string that is the name of a member type.
タイプが「共用体」の場合、「タイプ」ステートメント（セクション7.4）が存在しなければなりません（MUST）。 ユニオンの各メンバータイプを指定するために繰り返し使用されます。 引数として、メンバー型の名前である文字列を受け取ります。
A member type can be of any built-in or derived type.
メンバー型は、任意の組み込み型または派生型にすることができます。
When generating an XML encoding, a value is encoded according to the rules of the member type to which the value belongs. When interpreting an XML encoding, a value is validated consecutively against each member type, in the order they are specified in the "type" statement, until a match is found. The type that matched will be the type of the value for the node that was validated, and the encoding is interpreted according to the rules for that type.
XMLエンコードを生成する場合、値は、その値が属するメンバータイプのルールに従ってエンコードされます。 XMLエンコーディングを解釈するとき、一致が見つかるまで、「type」ステートメントで指定された順序で、各メンバータイプに対して値が連続的に検証されます。 一致したタイプは、検証されたノードの値のタイプになり、エンコーディングはそのタイプのルールに従って解釈されます。
Any default value or "units" property defined in the member types is not inherited by the union type.
メンバタイプで定義されているデフォルト値または「ユニット」プロパティは、共用体タイプには継承されません。
9.12.1. Restrictions
9.12.1。 制限事項
A union cannot be restricted. However, each member type can be restricted, based on the rules defined in Section 9.
労働組合を制限することはできません。 ただし、セクション9で定義されたルールに基づいて、各メンバータイプを制限できます。
9.12.2. Lexical Representation
9.12.2。 字句表現
The lexical representation of a union is a value that corresponds to the representation of any one of the member types.
共用体の字句表現は、メンバー型のいずれかの表現に対応する値です。
Bjorklund Standards Track [Page 166] RFC 7950 YANG 1.1 August 2016 9.12.3. Canonical Form
9.12.3。 正規形
The canonical form of a union value is the same as the canonical form of the member type of the value.
共用体値の標準形は、値のメンバー型の標準形と同じです。
9.12.4. Usage Example
9.12.4。 使用例
The following is a union of an int32 and an enumeration:
以下は、int32と列挙の結合です。
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
Care must be taken when a member type is a leafref where the
"require-instance" property (Section 9.9.3) is "true". If a leaf of
such a type refers to an existing instance, the leaf's value must be
revalidated if the target instance is deleted. For example, with the
following definitions:
メンバータイプが "require-instance"プロパティ（セクション9.9.3）が "true"であるleafrefである場合は注意が必要です。 このようなタイプのリーフが既存のインスタンスを参照している場合、ターゲットインスタンスが削除されると、リーフの値を再検証する必要があります。 たとえば、次の定義の場合：
list filter {
key name;
leaf name {
type string;
}
...
}
leaf outbound-filter {
type union {
type leafref {
path "/filter/name";
}
type enumeration {
enum default-filter;
}
}
}
assume that there exists an entry in the filter list with the name
"http" and that the outbound-filter leaf has this value:
フィルターリストに「http」という名前のエントリがあり、outbound-filterリーフに次の値があると仮定します。
<filter>
<name>http</name>
</filter>
<outbound-filter>http</outbound-filter>
Bjorklund Standards Track [Page 167]
RFC 7950 YANG 1.1 August 2016
If the filter entry "http" is removed, the outbound-filter leaf's
value doesn't match the leafref, and the next member type is checked.
The current value ("http") doesn't match the enumeration, so the
resulting configuration is invalid.
フィルターエントリ「http」が削除された場合、outbound-filterリーフの値がleafrefと一致せず、次のメンバータイプがチェックされます。 現在の値（ "http"）が列挙と一致しないため、結果の構成は無効です。
If the second member type in the union had been of type "string" instead of an enumeration, the current value would have matched, and the resulting configuration would have been valid.
ユニオンの2番目のメンバータイプが列挙型ではなく「文字列」型であった場合、現在の値は一致し、結果の構成は有効でした。
9.13. The instance-identifier Built-In Type
9.13。 インスタンス識別子の組み込みタイプ
The instance-identifier built-in type is used to uniquely identify a particular instance node in the data tree.
インスタンスID組み込みタイプは、データツリー内の特定のインスタンスノードを一意に識別するために使用されます。
The syntax for an instance-identifier is a subset of the XPath
abbreviated syntax, formally defined by the rule
"instance-identifier" in Section 14. 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. If a key is of type "empty", it is represented as a
zero-length string ("").
instance-identifierの構文は、XPath省略構文のサブセットであり、セクション14のルール「instance-identifier」によって正式に定義されています。 データツリー内のノードを一意に識別するために使用されます。 述語は、リストエントリのキーノードの値、リーフリストエントリの値、またはキーのないリストの位置インデックスの指定にのみ使用されます。 キーでリストエントリを識別するために、各述語はキーごとに1つの等価テストで構成され、各キーには対応する述語が必要です。 キーのタイプが「空」の場合、長さゼロの文字列（ ""）として表されます。
If the leaf with the instance-identifier type represents configuration data and the "require-instance" property (Section 9.9.3) 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 or leaf-list nodes with their default value in use (see Sections 7.6.1 and 7.7.2) for the data to be valid. This constraint is enforced according to the rules in Section 8.
instance-identifierタイプのリーフが構成データを表し、「require-instance」プロパティー（セクション9.9.3）が「true」の場合、参照するノードも構成を表す必要があります。 このようなリーフは、有効なデータに制約を課します。 そのようなすべてのリーフノードは、データが有効であるために、使用中のデフォルト値（セクション7.6.1および7.7.2を参照）で既存のノードまたはリーフまたはリーフリストノードを参照する必要があります。 この制約は、セクション8のルールに従って実施されます。
The "instance-identifier" 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 root node in the accessible tree.
コンテキストノードは、アクセス可能なツリーのルートノードです。
9.13.1. Restrictions
9.13.1。 制限事項
An instance-identifier can be restricted with the "require-instance" statement (Section 9.9.3).
instance-identifierは、「require-instance」ステートメント（セクション9.9.3）で制限できます。
Bjorklund Standards Track [Page 168] RFC 7950 YANG 1.1 August 2016 9.13.2. Lexical Representation
9.13.2。 字句表現
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.
インスタンス識別子の値は、字句的に文字列として表されます。 インスタンス識別子の値のすべてのノード名は、明示的な名前空間プレフィックスで修飾する必要があり、これらのプレフィックスは、インスタンス識別子の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.
エンコーディングで使用されるプレフィックスは、各インスタンスのエンコーディングに対してローカルです。 つまり、同じインスタンス識別子は、実装によって異なる方法でエンコードされる可能性があります。
9.13.3. Canonical Form
9.13.3。 正規形
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
字句形式は値が発生するXMLコンテキストに依存するため、この型には標準形式がありません。
9.13.4. Usage Example
9.13.4。 使用例
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 list entry where the second
key ("enabled") is of type "empty" */
/ex:system/ex:service[ex:name='foo'][ex:enabled='']
/* 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]
Bjorklund Standards Track [Page 169]
RFC 7950 YANG 1.1 August 2016
10. XPath Functions
10. XPath関数
This document defines two generic XPath functions and five YANG type-specific XPath functions. The function signatures are specified with the syntax used in [XPATH].
このドキュメントでは、2つの汎用XPath関数と5つのYANGタイプ固有のXPath関数を定義しています。 関数のシグネチャは、[XPATH]で使用される構文で指定されます。
10.1. Function for Node Sets
10.1 ノードセットの機能
10.1.1. current()
10.1.1。 現在（）
node-set current()
The current() function takes no input parameters and returns a node
set with the initial context node as its only member.
current（）関数は入力パラメーターをとらず、初期コンテキストノードを唯一のメンバーとして持つノードセットを返します。
10.1.1.1. Usage Example
10.1.1.1。 使用例
With this list:
このリストで：
list interface {
key "name";
...
leaf enabled {
type boolean;
}
...
}
the following leaf defines a "must" expression that ensures that the
referred interface is enabled:
次のリーフは、参照されたインターフェイスが有効であることを保証する「必須」の式を定義しています。
leaf outgoing-interface {
type leafref {
path "/interface/name";
}
must '/interface[name=current()]/enabled = "true"';
}
10.2. Function for Strings
10.2 文字列用の関数
10.2.1. re-match()
10.2.1。 再戦（）
boolean re-match(string subject, string pattern)
The re-match() function returns "true" if the "subject" string
matches the regular expression "pattern"; otherwise, it returns
"false".
re-match（）関数は、「subject」文字列が正規表現「pattern」と一致する場合に「true」を返します。 それ以外の場合は「false」を返します。
Bjorklund Standards Track [Page 170] RFC 7950 YANG 1.1 August 2016 The re-match() function checks to see if a string matches a given regular expression. The regular expressions used are the XML Schema regular expressions [XSD-TYPES]. Note that this includes implicit anchoring of the regular expression at the head and tail.
re-match（）関数は、文字列が指定された正規表現に一致するかどうかを確認します。 使用される正規表現は、XMLスキーマの正規表現[XSD-TYPES]です。 これには、先頭と末尾での正規表現の暗黙的なアンカーが含まれることに注意してください。
10.2.1.1. Usage Example
10.2.1.1。 使用例
The expression:
re-match("1.22.333", "\d{1,3}\.\d{1,3}\.\d{1,3}")
returns "true".
To count all logical interfaces called eth0.<number>, do:
eth0。<number>と呼ばれるすべての論理インターフェースをカウントするには、次のようにします。
count(/interface[re-match(name, "eth0\.\d+")])
10.3. Function for the YANG Types "leafref" and "instance-identifier"
10.3。 YANGタイプ「leafref」および「instance-identifier」の関数
10.3.1. deref()
10.3.1。 deref（）
node-set deref(node-set nodes)
The deref() function follows the reference defined by the first node
in document order in the argument "nodes" and returns the nodes it
refers to.
deref（）関数は、引数「nodes」のドキュメント順で最初のノードによって定義された参照に従い、参照するノードを返します。
If the first argument node is of type "instance-identifier", the function returns a node set that contains the single node that the instance identifier refers to, if it exists. If no such node exists, an empty node set is returned.
最初の引数ノードのタイプが「インスタンス識別子」の場合、関数は、インスタンス識別子が存在する場合、インスタンス識別子が参照する単一ノードを含むノードセットを返します。 そのようなノードが存在しない場合、空のノードセットが返されます。
If the first argument node is of type "leafref", the function returns a node set that contains the nodes that the leafref refers to. Specifically, this set contains the nodes selected by the leafref's "path" statement (Section 9.9.2) that have the same value as the first argument node.
最初の引数ノードのタイプが「leafref」の場合、関数は、leafrefが参照するノードを含むノードセットを返します。 具体的には、このセットには、最初の引数ノードと同じ値を持つ、leafrefの「パス」ステートメント（セクション9.9.2）によって選択されたノードが含まれます。
If the first argument node is of any other type, an empty node set is returned.
最初の引数ノードが他のタイプの場合、空のノードセットが返されます。
Bjorklund Standards Track [Page 171] RFC 7950 YANG 1.1 August 2016 10.3.1.1. Usage Example
10.3.1.1。 使用例
list interface {
key "name type";
leaf name { ... }
leaf type { ... }
leaf enabled {
type boolean;
}
...
}
container mgmt-interface {
leaf name {
type leafref {
path "/interface/name";
}
}
leaf type {
type leafref {
path "/interface[name=current()/../name]/type";
}
must 'deref(.)/../enabled = "true"' {
error-message
"The management interface cannot be disabled.";
}
}
}
10.4. Functions for the YANG Type "identityref"
10.4.1. derived-from()
10.4。 YANGタイプ「identityref」の関数
boolean derived-from(node-set nodes, string identity)
The derived-from() function returns "true" if any node in the
argument "nodes" is a node of type "identityref" and its value is an
identity that is derived from (see Section 7.18.2) the identity
"identity"; otherwise, it returns "false".
引数「nodes」のいずれかのノードが「identityref」タイプのノードであり、その値がアイデンティティ「identity」から派生したアイデンティティである場合（7.18.2項を参照）、derived-from（）関数は「true」を返します。 ; それ以外の場合は「false」を返します。
The parameter "identity" is a string matching the rule "identifier-ref" in Section 14. If a prefix is present on the identity, 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. If no prefix is present, the identity refers to an identity defined in the current module or an included submodule.
パラメータ「identity」は、セクション14のルール「identifier-ref」に一致する文字列です。 IDにプレフィックスが存在する場合は、そのプレフィックスでインポートされたモジュールで定義されたID、またはプレフィックスがローカルモジュールのプレフィックスと一致する場合はローカルモジュールを指します。 プレフィックスが存在しない場合、IDは現在のモジュールまたは含まれているサブモジュールで定義されているIDを参照します。
Bjorklund Standards Track [Page 172] RFC 7950 YANG 1.1 August 2016 10.4.1.1. Usage Example
10.4.1.1。 使用例
module example-interface {
yang-version 1.1;
...
identity interface-type;
identity ethernet {
base interface-type;
}
identity fast-ethernet {
base ethernet;
}
identity gigabit-ethernet {
base ethernet;
}
list interface {
key name;
...
leaf type {
type identityref {
base interface-type;
}
}
...
}
augment "/interface" {
when 'derived-from(type, "exif:ethernet")';
// generic Ethernet definitions here
}
...
}
Bjorklund Standards Track [Page 173]
RFC 7950 YANG 1.1 August 2016
10.4.2. derived-from-or-self()
10.4.2。 派生元または自己（）
boolean derived-from-or-self(node-set nodes, string identity)
The derived-from-or-self() function returns "true" if any node in the
argument "nodes" is a node of type "identityref" and its value is an
identity that is equal to or derived from (see Section 7.18.2) the
identity "identity"; otherwise, it returns "false".
引数「nodes」のノードのいずれかが「identityref」タイプのノードであり、その値が等しいまたは派生したアイデンティティである場合、derived-from-or-self（）関数は「true」を返します（セクション7.18を参照してください）。 2）アイデンティティ「アイデンティティ」; それ以外の場合は「false」を返します。
The parameter "identity" is a string matching the rule "identifier-ref" in Section 14. If a prefix is present on the identity, 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. If no prefix is present, the identity refers to an identity defined in the current module or an included submodule.
パラメータ「identity」は、セクション14のルール「identifier-ref」に一致する文字列です。 IDにプレフィックスが存在する場合は、そのプレフィックスでインポートされたモジュールで定義されたID、またはプレフィックスがローカルモジュールのプレフィックスと一致する場合はローカルモジュールを指します。 プレフィックスが存在しない場合、IDは現在のモジュールまたは含まれているサブモジュールで定義されているIDを参照します。
10.4.2.1. Usage Example
10.4.2.1。 使用例
The module defined in Section 10.4.1.1 might also have:
セクション10.4.1.1で定義されているモジュールには、次のものも含まれる可能性があります。
augment "/interface" {
when 'derived-from-or-self(type, "exif:fast-ethernet");
// Fast-Ethernet-specific definitions here
}
10.5. Function for the YANG Type "enumeration"
10.5。 YANGタイプ「列挙型」の関数
10.5.1. enum-value()
10.5.1。 enum-value（）
number enum-value(node-set nodes)
The enum-value() function checks to see if the first node in document
order in the argument "nodes" is a node of type "enumeration" and
returns the enum's integer value. If the "nodes" node set is empty
or if the first node in "nodes" is not of type "enumeration", it
returns NaN (not a number).
enum-value（）関数は、引数「nodes」のドキュメント順の最初のノードが「enumeration」タイプのノードであるかどうかを確認し、enumの整数値を返します。 「nodes」ノードセットが空の場合、または「nodes」の最初のノードが「列挙型」ではない場合、NaN（非数）を返します。
Bjorklund Standards Track [Page 174] RFC 7950 YANG 1.1 August 2016 10.5.1.1. Usage Example
10.5.1.1。 使用例
With this data model:
list alarm {
...
leaf severity {
type enumeration {
enum cleared {
value 1;
}
enum indeterminate {
value 2;
}
enum minor {
value 3;
}
enum warning {
value 4;
}
enum major {
value 5;
}
enum critical {
value 6;
}
}
}
}
the following XPath expression selects only alarms that are of
severity "major" or higher:
次のXPath式は、「メジャー」以上の重大度のアラームのみを選択します。
/alarm[enum-value(severity) >= 5]
10.6. Function for the YANG Type "bits"
10.6。 YANGタイプ「ビット」の関数
10.6.1. bit-is-set()
10.6.1。 bit-is-set（）
boolean bit-is-set(node-set nodes, string bit-name)
The bit-is-set() function returns "true" if the first node in
document order in the argument "nodes" is a node of type "bits" and
its value has the bit "bit-name" set; otherwise, it returns "false".
引数「nodes」のドキュメント順の最初のノードがタイプ「bits」のノードであり、その値にビット「bit-name」が設定されている場合、bit-is-set（）関数は「true」を返します。 それ以外の場合は「false」を返します。
Bjorklund Standards Track [Page 175] RFC 7950 YANG 1.1 August 2016 10.6.1.1. Usage Example
10.6.1.1。 使用例
If an interface has this leaf:
leaf flags {
type bits {
bit UP;
bit PROMISCUOUS
bit DISABLED;
}
}
the following XPath expression can be used to select all interfaces
with the UP flag set:
次のXPath式を使用して、UPフラグが設定されたすべてのインターフェースを選択できます。
/interface[bit-is-set(flags, "UP")]
11. Updating a Module
11.モジュールの更新
As experience is gained with a module, it may be desirable to revise that module. However, changes to published modules 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 metadata statements, including the "organization" and "contact" statements (Sections 7.1.7 and 7.1.8).
公開された変更については、新しい「改訂」ステートメント（セクション7.1.9）を既存の「改訂」ステートメントの前に含める必要があります。 既存の「改訂」ステートメントがない場合は、新しい改訂を識別するために1つ追加する必要があります。 さらに、必要な変更は、「組織」および「連絡先」ステートメントを含むすべてのメタデータステートメントに適用する必要があります（セクション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要素は名前空間によって修飾されるため、「namespace」ステートメントを変更してはなりません（MUST NOT）。
Obsolete definitions MUST NOT be removed from published modules, since their identifiers may still be referenced by other modules.
識別子はまだ他のモジュールから参照されている可能性があるため、公開されたモジュールから古い定義を削除してはなりません。
Bjorklund Standards Track [Page 176] RFC 7950 YANG 1.1 August 2016 A definition in a published module 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. Note that inserting a new enum
before an existing enum or reordering existing enums will result
in new values for the existing enums, unless they have explicit
values assigned to them.
「列挙型」タイプには、古い列挙型の値が変更されない限り、新しい列挙型が追加される場合があります。 既存の列挙型の前に新しい列挙型を挿入するか、既存の列挙型を並べ替えると、明示的な値が割り当てられていない限り、既存の列挙型の新しい値が生成されます。
o A "bits" type may have new bits added, provided the old bit
positions do not change. Note that inserting a new bit before an
existing bit or reordering existing bits will result in new
positions for the existing bits, unless they have explicit
positions assigned to them.
「ビット」タイプには、古いビット位置が変更されない限り、新しいビットが追加される場合があります。 既存のビットの前に新しいビットを挿入したり、既存のビットを並べ替えたりすると、明示的な位置が割り当てられていない限り、既存のビットの新しい位置になります。
o A "range", "length", or "pattern" statement may expand the allowed
value space.
「範囲」、「長さ」、または「パターン」ステートメントは、許容値スペースを拡張する場合があります。
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 A "units" statement may be added.
「ユニット」ステートメントが追加される場合があります。
o A "reference" statement may be added or updated.
「参照」ステートメントが追加または更新される場合があります。
o A "must" statement may be removed or its constraint relaxed.
「必須」ステートメントを削除するか、その制約を緩和することができます。
o A "when" statement may be removed or its constraint relaxed.
「いつ」ステートメントが削除されるか、その制約が緩和されます。
o A "mandatory" statement may be removed or changed from "true" to
"false".
「必須」ステートメントは削除されるか、「true」から「false」に変更されます。
o A "min-elements" statement may be removed, or changed to require
fewer elements.
「min-elements」ステートメントは削除されるか、必要なエレメント数が少なくなるように変更されます。
o A "max-elements" statement may be removed, or changed to allow
more elements.
「max-elements」ステートメントを削除するか、より多くのエレメントを許可するように変更することができます。
o A "description" statement may be added or changed without changing
the semantics of the definition.
「説明」ステートメントは、定義のセマンティクスを変更せずに追加または変更できます。
o A "base" statement may be added to an "identity" statement.
「基本」ステートメントを「アイデンティティ」ステートメントに追加できます。
o A "base" statement may be removed from an "identityref" type,
provided there is at least one "base" statement left.
「base」ステートメントは、「identityref」タイプから削除できます。ただし、「base」ステートメントが少なくとも1つ残っています。
o New typedefs, groupings, rpcs, notifications, extensions,
features, and identities may be added.
新しいtypedef、グループ、rpcs、通知、拡張機能、機能、およびIDが追加される場合があります。
Bjorklund Standards Track [Page 177]
RFC 7950 YANG 1.1 August 2016
o New data definition statements may be added if they do not add
mandatory nodes (Section 3) 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).
新しいデータ定義ステートメントは、必須ノード（セクション3）を既存のノードに追加しない場合、またはモジュールやサブモジュールの最上位に追加しない場合、または条件付きで新しい機能に依存している場合（つまり、「if- 新機能を参照する「機能」ステートメント）。
o A new "case" statement may be added.
新しい「ケース」ステートメントが追加される場合があります。
o A node that represented state data may be changed to represent
configuration, provided it is not mandatory (Section 3).
状態データを表すノードは、必須ではない場合（セクション3）、構成を表すように変更できます。
o An "if-feature" statement may be removed, provided its node is not
mandatory (Section 3).
「if-feature」ステートメントは、そのノードが必須ではない場合に削除できます（セクション3）。
o A "status" statement may be added, or changed from "current" to
"deprecated" or "obsolete", or changed from "deprecated" to
"obsolete".
「status」ステートメントが追加されるか、「現在」から「非推奨」または「廃止」に変更されるか、または「非推奨」から「廃止」に変更される場合があります。
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.
「タイプ」ステートメントは、タイプの構文またはセマンティクスを変更しない別の「タイプ」ステートメントに置き換えることができます。 たとえば、インライン型の定義は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" statement of a grouping
with the same leafs.
データ定義ノードのセットは、構文的および意味的に等価な別のノードのセットで置き換えることができます。 たとえば、葉のセットは、同じ葉を持つグループの「uses」ステートメントで置き換えることができます。
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 way other than those allowed here.
モジュール内の定義がここで許可されている以外の方法で変更されない場合、モジュールをサブモジュールのセットに分割するか、サブモジュールを削除できます。
o The "prefix" statement may be changed, provided all local uses of
the prefix are also changed.
接頭辞のすべてのローカル使用も変更されている場合、「接頭辞」ステートメントは変更される可能性があります。
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.
それ以外の場合、以前の定義のセマンティクスが変更された場合（つまり、上記で特に許可されたもの以外の定義に編集上の変更が加えられた場合）、これは新しい識別子を持つ新しい定義によって達成されなければなりません（MUST）。
In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. If new data definition statements are added, they can be added anywhere in the sequence of existing substatements.
サブステートメントとしてデータ定義ステートメントを含むステートメントでは、それらのデータ定義サブステートメントを並べ替えてはなりません（MUST NOT）。 新しいデータ定義ステートメントが追加された場合、それらは既存のサブステートメントのシーケンスのどこにでも追加できます。
Bjorklund Standards Track [Page 178] RFC 7950 YANG 1.1 August 2016 12. Coexistence with YANG Version 1
12. YANGバージョン1との共存
A YANG version 1.1 module MUST NOT include a YANG version 1 submodule, and a YANG version 1 module MUST NOT include a YANG version 1.1 submodule.
YANGバージョン1.1モジュールにYANGバージョン1サブモジュールを含めてはならず、YANGバージョン1モジュールにYANGバージョン1.1サブモジュールを含めてはなりません。
A YANG version 1 module or submodule MUST NOT import a YANG version 1.1 module by revision.
YANGバージョン1モジュールまたはサブモジュールは、リビジョンによってYANGバージョン1.1モジュールをインポートしてはなりません。
A YANG version 1.1 module or submodule MAY import a YANG version 1 module by revision.
YANGバージョン1.1モジュールまたはサブモジュールは、リビジョンによってYANGバージョン1モジュールをインポートする場合があります。
If a YANG version 1 module A imports module B without revision and module B is updated to YANG version 1.1, a server MAY implement both of these modules (A and B) at the same time. In such cases, a NETCONF server MUST advertise both modules using the rules defined in Section 5.6.4, and SHOULD advertise module A and the latest revision of module B that is specified with YANG version 1 according to the rules defined in [RFC6020].
YANGバージョン1のモジュールAがモジュールBをリビジョンなしでインポートし、モジュールBがYANGバージョン1.1に更新された場合、サーバーはこれらのモジュール（AとB）の両方を同時に実装できます（MAY）。 そのような場合、NETCONFサーバーは、セクション5.6.4で定義されたルールを使用して両方のモジュールをアドバタイズしなければなりません。
This rule exists in order to allow implementations of existing YANG version 1 modules together with YANG version 1.1 modules. Without this rule, updating a single module to YANG version 1.1 would have a cascading effect on modules that import it, requiring all of them to also be updated to YANG version 1.1, and so on.
このルールは、既存のYANGバージョン1モジュールをYANGバージョン1.1モジュールと一緒に実装できるようにするために存在します。 このルールがないと、単一のモジュールをYANGバージョン1.1に更新すると、そのモジュールをインポートするモジュールにカスケード効果が生じ、それらのすべてもYANGバージョン1.1に更新する必要があります。
13. YIN
13. YIN
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 bidirectional 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表記を使用すると、開発者はYANGデータモデルをXMLで表すことができるため、データのフィルタリングと検証、コードとドキュメントの自動生成、およびその他のタスクに豊富な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の間のマッピングは、モデルの情報コンテンツを変更しません。 コメントと空白は保持されません。
Bjorklund Standards Track [Page 179] RFC 7950 YANG 1.1 August 2016 13.1. Formal YIN Definition
13.1。 正式な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ドキュメントのドキュメント要素（ルート）が常に<モジュール>または<サブモジュール>であることを意味します。
YIN elements corresponding to the YANG keywords belong to the namespace whose associated URI is "urn:ietf:params:xml:ns:yang:yin:1".
YANGキーワードに対応する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 (as 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 as either 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.19). The following rules hold for arguments:
YANGステートメントの引数は、XML属性またはキーワード要素のサブ要素としてYINで表されます。 表1は、YANGキーワードのセットのマッピングを定義しています。 拡張の場合、引数マッピングは「拡張」ステートメント内で指定されます（セクション7.19を参照）。 引数には次の規則が適用されます。
o If the argument is represented as an attribute, this attribute has
no namespace.
引数が属性として表される場合、この属性には名前空間がありません。
o If the argument is represented as an element, it is qualified by
the same namespace as its parent keyword element.
引数が要素として表される場合、その引数は、その親キーワード要素と同じ名前空間によって修飾されます。
o If the argument is represented as an element, it MUST be the first
child of the keyword element.
引数が要素として表される場合、それはキーワード要素の最初の子でなければなりません。
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.
YANGステートメントのサブステートメントは、キーワード要素の（追加の）子として表され、それらの相対的な順序は、YANGのサブステートメントの順序と同じでなければなりません。
Comments in YANG MAY be mapped to XML comments.
YANGのコメントはXMLコメントにマップされる場合があります。
Bjorklund Standards Track [Page 180]
RFC 7950 YANG 1.1 August 2016
+------------------+---------------+-------------+
| keyword | argument name | yin-element |
+------------------+---------------+-------------+
| action | name | false |
| anydata | name | false |
| 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 |
| modifier | 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 |
Bjorklund Standards Track [Page 181]
RFC 7950 YANG 1.1 August 2016
| 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: Mapping of Arguments of the YANG Statements
13.1.1. Usage Example
13.1.1。 使用例
The following YANG module:
module example-foo {
yang-version 1.1;
namespace "urn:example:foo";
prefix "foo";
import example-extensions {
prefix "myext";
}
list interface {
key "name";
leaf name {
type string;
}
Bjorklund Standards Track [Page 182]
RFC 7950 YANG 1.1 August 2016
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.19.3, is
translated into the following YIN:
拡張「c-define」はセクション7.19.3で定義されており、次のYINに変換されます。
<module name="example-foo"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:foo="urn:example:foo"
xmlns:myext="urn:example:extensions">
<namespace uri="urn:example:foo"/>
<prefix value="foo"/>
<import module="example-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>
Bjorklund Standards Track [Page 183]
RFC 7950 YANG 1.1 August 2016
14. YANG ABNF Grammar
14.ヤンABNF文法
In YANG, almost all statements are unordered. The ABNF grammar [RFC5234] [RFC7405] defines the canonical order. To improve module readability, it is RECOMMENDED that clauses be entered in this order.
YANGでは、ほとんどすべてのステートメントは順不同です。 ABNF文法[RFC5234] [RFC7405]は標準的な順序を定義します。 モジュールを読みやすくするために、句はこの順序で入力することをお勧めします。
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"
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
module-header-stmts = ;; these stmts can appear in any order
yang-version-stmt
namespace-stmt
prefix-stmt
submodule-header-stmts =
;; these stmts can appear in any order
yang-version-stmt
belongs-to-stmt
Bjorklund Standards Track [Page 184]
RFC 7950 YANG 1.1 August 2016
meta-stmts = ;; these stmts can appear in any order
[organization-stmt]
[contact-stmt]
[description-stmt]
[reference-stmt]
linkage-stmts = ;; these stmts can appear in any order
*import-stmt
*include-stmt
revision-stmts = *revision-stmt
body-stmts = *(extension-stmt /
feature-stmt /
identity-stmt /
typedef-stmt /
grouping-stmt /
data-def-stmt /
augment-stmt /
rpc-stmt /
notification-stmt /
deviation-stmt)
data-def-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
choice-stmt /
anydata-stmt /
anyxml-stmt /
uses-stmt
yang-version-stmt = yang-version-keyword sep yang-version-arg-str
stmtend
yang-version-arg-str = < a string that matches the rule >
< yang-version-arg >
yang-version-arg = "1.1"
import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
prefix-stmt
[revision-date-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep
Bjorklund Standards Track [Page 185]
RFC 7950 YANG 1.1 August 2016
include-stmt = include-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[revision-date-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
namespace-stmt = namespace-keyword sep uri-str stmtend
uri-str = < a string that matches the rule >
< URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
optsep
"{" stmtsep
prefix-stmt
"}" stmtsep
organization-stmt = organization-keyword sep string stmtend
contact-stmt = contact-keyword sep string stmtend
description-stmt = description-keyword sep string stmtend
reference-stmt = reference-keyword sep string stmtend
units-stmt = units-keyword sep string stmtend
revision-stmt = revision-keyword sep revision-date optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[description-stmt]
[reference-stmt]
"}") stmtsep
revision-date = date-arg-str
revision-date-stmt = revision-date-keyword sep revision-date stmtend
Bjorklund Standards Track [Page 186]
RFC 7950 YANG 1.1 August 2016
extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[argument-stmt]
[status-stmt]
[description-stmt]
[reference-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-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
*if-feature-stmt
*base-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
base-stmt = base-keyword sep identifier-ref-arg-str
stmtend
feature-stmt = feature-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
Bjorklund Standards Track [Page 187]
RFC 7950 YANG 1.1 August 2016
if-feature-stmt = if-feature-keyword sep if-feature-expr-str
stmtend
if-feature-expr-str = < a string that matches the rule >
< if-feature-expr >
if-feature-expr = if-feature-term
[sep or-keyword sep if-feature-expr]
if-feature-term = if-feature-factor
[sep and-keyword sep if-feature-term]
if-feature-factor = not-keyword sep if-feature-factor /
"(" optsep if-feature-expr optsep ")" /
identifier-ref-arg
typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
type-stmt
[units-stmt]
[default-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep
type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
[type-body-stmts]
"}") stmtsep
type-body-stmts = numerical-restrictions /
decimal64-specification /
string-restrictions /
enum-specification /
leafref-specification /
identityref-specification /
instance-identifier-specification /
bits-specification /
union-specification /
binary-specification
Bjorklund Standards Track [Page 188]
RFC 7950 YANG 1.1 August 2016
numerical-restrictions = [range-stmt]
range-stmt = range-keyword sep range-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt]
[error-app-tag-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
decimal64-specification = ;; these stmts can appear in any order
fraction-digits-stmt
[range-stmt]
fraction-digits-stmt = fraction-digits-keyword sep
fraction-digits-arg-str 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]
*pattern-stmt
length-stmt = length-keyword sep length-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt]
[error-app-tag-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
Bjorklund Standards Track [Page 189]
RFC 7950 YANG 1.1 August 2016
pattern-stmt = pattern-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[modifier-stmt]
[error-message-stmt]
[error-app-tag-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
modifier-stmt = modifier-keyword sep modifier-arg-str stmtend
modifier-arg-str = < a string that matches the rule >
< modifier-arg >
modifier-arg = invert-match-keyword
default-stmt = default-keyword sep string stmtend
enum-specification = 1*enum-stmt
enum-stmt = enum-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[value-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
leafref-specification =
;; these stmts can appear in any order
path-stmt
[require-instance-stmt]
path-stmt = path-keyword sep path-arg-str stmtend
require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend
require-instance-arg-str = < a string that matches the rule >
< require-instance-arg >
require-instance-arg = true-keyword / false-keyword
Bjorklund Standards Track [Page 190]
RFC 7950 YANG 1.1 August 2016
instance-identifier-specification =
[require-instance-stmt]
identityref-specification =
1*base-stmt
union-specification = 1*type-stmt
binary-specification = [length-stmt]
bits-specification = 1*bit-stmt
bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[position-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
position-stmt = position-keyword sep
position-value-arg-str 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
config-stmt = config-keyword sep
config-arg-str stmtend
config-arg-str = < a string that matches the rule >
< config-arg >
config-arg = true-keyword / false-keyword
Bjorklund Standards Track [Page 191]
RFC 7950 YANG 1.1 August 2016
mandatory-stmt = mandatory-keyword sep
mandatory-arg-str 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
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]
[error-app-tag-stmt]
[description-stmt]
[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
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-value-arg-str = < a string that matches the rule >
< max-value-arg >
max-value-arg = unbounded-keyword /
positive-integer-value
Bjorklund Standards Track [Page 192]
RFC 7950 YANG 1.1 August 2016
value-stmt = value-keyword sep integer-value-str stmtend
integer-value-str = < a string that matches the rule >
< integer-value >
grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
*data-def-stmt
*action-stmt
*notification-stmt
"}") stmtsep
container-stmt = container-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
*must-stmt
[presence-stmt]
[config-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
*data-def-stmt
*action-stmt
*notification-stmt
"}") stmtsep
Bjorklund Standards Track [Page 193]
RFC 7950 YANG 1.1 August 2016
leaf-stmt = leaf-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
type-stmt
[units-stmt]
*must-stmt
[default-stmt]
[config-stmt]
[mandatory-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep
leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
type-stmt stmtsep
[units-stmt]
*must-stmt
*default-stmt
[config-stmt]
[min-elements-stmt]
[max-elements-stmt]
[ordered-by-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep
Bjorklund Standards Track [Page 194]
RFC 7950 YANG 1.1 August 2016
list-stmt = list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
*must-stmt
[key-stmt]
*unique-stmt
[config-stmt]
[min-elements-stmt]
[max-elements-stmt]
[ordered-by-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
1*data-def-stmt
*action-stmt
*notification-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)
unique-stmt = unique-keyword sep unique-arg-str stmtend
unique-arg-str = < a string that matches the rule >
< unique-arg >
unique-arg = descendant-schema-nodeid
*(sep descendant-schema-nodeid)
Bjorklund Standards Track [Page 195]
RFC 7950 YANG 1.1 August 2016
choice-stmt = choice-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
[default-stmt]
[config-stmt]
[mandatory-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
*(short-case-stmt / case-stmt)
"}") stmtsep
short-case-stmt = choice-stmt /
container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
anydata-stmt /
anyxml-stmt
case-stmt = case-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*data-def-stmt
"}") stmtsep
Bjorklund Standards Track [Page 196]
RFC 7950 YANG 1.1 August 2016
anydata-stmt = anydata-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
*must-stmt
[config-stmt]
[mandatory-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
*must-stmt
[config-stmt]
[mandatory-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep
uses-stmt = uses-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*refine-stmt
*uses-augment-stmt
"}") stmtsep
Bjorklund Standards Track [Page 197]
RFC 7950 YANG 1.1 August 2016
refine-stmt = refine-keyword sep refine-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
*must-stmt
[presence-stmt]
*default-stmt
[config-stmt]
[mandatory-stmt]
[min-elements-stmt]
[max-elements-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep
refine-arg-str = < a string that matches the rule >
< refine-arg >
refine-arg = descendant-schema-nodeid
uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
1*(data-def-stmt / case-stmt /
action-stmt / notification-stmt)
"}" stmtsep
uses-augment-arg-str = < a string that matches the rule >
< uses-augment-arg >
uses-augment-arg = descendant-schema-nodeid
Bjorklund Standards Track [Page 198]
RFC 7950 YANG 1.1 August 2016
augment-stmt = augment-keyword sep augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
1*(data-def-stmt / case-stmt /
action-stmt / notification-stmt)
"}" stmtsep
augment-arg-str = < a string that matches the rule >
< augment-arg >
augment-arg = absolute-schema-nodeid
when-stmt = when-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[description-stmt]
[reference-stmt]
"}") stmtsep
rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
[input-stmt]
[output-stmt]
"}") stmtsep
Bjorklund Standards Track [Page 199]
RFC 7950 YANG 1.1 August 2016
action-stmt = action-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
[input-stmt]
[output-stmt]
"}") stmtsep
input-stmt = input-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*must-stmt
*(typedef-stmt / grouping-stmt)
1*data-def-stmt
"}" stmtsep
output-stmt = output-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*must-stmt
*(typedef-stmt / grouping-stmt)
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
*must-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
*data-def-stmt
"}") stmtsep
Bjorklund Standards Track [Page 200]
RFC 7950 YANG 1.1 August 2016
deviation-stmt = deviation-keyword sep
deviation-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[description-stmt]
[reference-stmt]
(deviate-not-supported-stmt /
1*(deviate-add-stmt /
deviate-replace-stmt /
deviate-delete-stmt))
"}" stmtsep
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-str stmtend
deviate-add-stmt = deviate-keyword sep add-keyword-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[units-stmt]
*must-stmt
*unique-stmt
*default-stmt
[config-stmt]
[mandatory-stmt]
[min-elements-stmt]
[max-elements-stmt]
"}") stmtsep
deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[units-stmt]
*must-stmt
*unique-stmt
*default-stmt
"}") stmtsep
Bjorklund Standards Track [Page 201]
RFC 7950 YANG 1.1 August 2016
deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[type-stmt]
[units-stmt]
[default-stmt]
[config-stmt]
[mandatory-stmt]
[min-elements-stmt]
[max-elements-stmt]
"}") stmtsep
not-supported-keyword-str = < a string that matches the rule >
< not-supported-keyword >
add-keyword-str = < a string that matches the rule >
< add-keyword >
delete-keyword-str = < a string that matches the rule >
< delete-keyword >
replace-keyword-str = < a string that matches the rule >
< replace-keyword >
;; represents the usage of an extension
unknown-statement = prefix ":" identifier [sep string] optsep
(";" /
"{" optsep
*((yang-stmt / unknown-statement) optsep)
"}") stmtsep
yang-stmt = action-stmt /
anydata-stmt /
anyxml-stmt /
argument-stmt /
augment-stmt /
base-stmt /
belongs-to-stmt /
bit-stmt /
case-stmt /
choice-stmt /
config-stmt /
contact-stmt /
container-stmt /
default-stmt /
description-stmt /
deviate-add-stmt /
Bjorklund Standards Track [Page 202]
RFC 7950 YANG 1.1 August 2016
deviate-delete-stmt /
deviate-not-supported-stmt /
deviate-replace-stmt /
deviation-stmt /
enum-stmt /
error-app-tag-stmt /
error-message-stmt /
extension-stmt /
feature-stmt /
fraction-digits-stmt /
grouping-stmt /
identity-stmt /
if-feature-stmt /
import-stmt /
include-stmt /
input-stmt /
key-stmt /
leaf-list-stmt /
leaf-stmt /
length-stmt /
list-stmt /
mandatory-stmt /
max-elements-stmt /
min-elements-stmt /
modifier-stmt /
module-stmt /
must-stmt /
namespace-stmt /
notification-stmt /
ordered-by-stmt /
organization-stmt /
output-stmt /
path-stmt /
pattern-stmt /
position-stmt /
prefix-stmt /
presence-stmt /
range-stmt /
reference-stmt /
refine-stmt /
require-instance-stmt /
revision-date-stmt /
revision-stmt /
rpc-stmt /
status-stmt /
submodule-stmt /
typedef-stmt /
type-stmt /
Bjorklund Standards Track [Page 203]
RFC 7950 YANG 1.1 August 2016
unique-stmt /
units-stmt /
uses-augment-stmt /
uses-stmt /
value-stmt /
when-stmt /
yang-version-stmt /
yin-element-stmt
;; Ranges
range-arg-str = < a string that matches the rule >
< range-arg >
range-arg = range-part *(optsep "|" optsep range-part)
range-part = 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-part = length-boundary
[optsep ".." optsep length-boundary]
length-boundary = 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
;; Schema Node Identifiers
schema-nodeid = absolute-schema-nodeid /
descendant-schema-nodeid
absolute-schema-nodeid = 1*("/" node-identifier)
Bjorklund Standards Track [Page 204]
RFC 7950 YANG 1.1 August 2016
descendant-schema-nodeid =
node-identifier
[absolute-schema-nodeid]
node-identifier = [prefix ":"] identifier
;; Instance Identifiers
instance-identifier = 1*("/" (node-identifier
[1*key-predicate /
leaf-list-predicate /
pos]))
key-predicate = "[" *WSP key-predicate-expr *WSP "]"
key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string
leaf-list-predicate = "[" *WSP leaf-list-predicate-expr *WSP "]"
leaf-list-predicate-expr = "." *WSP "=" *WSP quoted-string
pos = "[" *WSP positive-integer-value *WSP "]"
quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
;; 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]
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
Bjorklund Standards Track [Page 205]
RFC 7950 YANG 1.1 August 2016
rel-path-keyexpr = 1*(".." *WSP "/" *WSP)
*(node-identifier *WSP "/" *WSP)
node-identifier
;;; Keywords, using the syntax for case-sensitive strings (RFC 7405)
;; statement keywords
action-keyword = %s"action"
anydata-keyword = %s"anydata"
anyxml-keyword = %s"anyxml"
argument-keyword = %s"argument"
augment-keyword = %s"augment"
base-keyword = %s"base"
belongs-to-keyword = %s"belongs-to"
bit-keyword = %s"bit"
case-keyword = %s"case"
choice-keyword = %s"choice"
config-keyword = %s"config"
contact-keyword = %s"contact"
container-keyword = %s"container"
default-keyword = %s"default"
description-keyword = %s"description"
deviate-keyword = %s"deviate"
deviation-keyword = %s"deviation"
enum-keyword = %s"enum"
error-app-tag-keyword = %s"error-app-tag"
error-message-keyword = %s"error-message"
extension-keyword = %s"extension"
feature-keyword = %s"feature"
fraction-digits-keyword = %s"fraction-digits"
grouping-keyword = %s"grouping"
identity-keyword = %s"identity"
if-feature-keyword = %s"if-feature"
import-keyword = %s"import"
include-keyword = %s"include"
input-keyword = %s"input"
key-keyword = %s"key"
leaf-keyword = %s"leaf"
leaf-list-keyword = %s"leaf-list"
length-keyword = %s"length"
list-keyword = %s"list"
mandatory-keyword = %s"mandatory"
max-elements-keyword = %s"max-elements"
min-elements-keyword = %s"min-elements"
modifier-keyword = %s"modifier"
module-keyword = %s"module"
must-keyword = %s"must"
namespace-keyword = %s"namespace"
Bjorklund Standards Track [Page 206]
RFC 7950 YANG 1.1 August 2016
notification-keyword = %s"notification"
ordered-by-keyword = %s"ordered-by"
organization-keyword = %s"organization"
output-keyword = %s"output"
path-keyword = %s"path"
pattern-keyword = %s"pattern"
position-keyword = %s"position"
prefix-keyword = %s"prefix"
presence-keyword = %s"presence"
range-keyword = %s"range"
reference-keyword = %s"reference"
refine-keyword = %s"refine"
require-instance-keyword = %s"require-instance"
revision-keyword = %s"revision"
revision-date-keyword = %s"revision-date"
rpc-keyword = %s"rpc"
status-keyword = %s"status"
submodule-keyword = %s"submodule"
type-keyword = %s"type"
typedef-keyword = %s"typedef"
unique-keyword = %s"unique"
units-keyword = %s"units"
uses-keyword = %s"uses"
value-keyword = %s"value"
when-keyword = %s"when"
yang-version-keyword = %s"yang-version"
yin-element-keyword = %s"yin-element"
;; other keywords
add-keyword = %s"add"
current-keyword = %s"current"
delete-keyword = %s"delete"
deprecated-keyword = %s"deprecated"
false-keyword = %s"false"
invert-match-keyword = %s"invert-match"
max-keyword = %s"max"
min-keyword = %s"min"
not-supported-keyword = %s"not-supported"
obsolete-keyword = %s"obsolete"
replace-keyword = %s"replace"
system-keyword = %s"system"
true-keyword = %s"true"
unbounded-keyword = %s"unbounded"
user-keyword = %s"user"
Bjorklund Standards Track [Page 207]
RFC 7950 YANG 1.1 August 2016
and-keyword = %s"and"
or-keyword = %s"or"
not-keyword = %s"not"
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
identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string that matches the rule >
< identifier-ref-arg >
identifier-ref-arg = identifier-ref
identifier-ref = [prefix ":"] identifier
string = < an unquoted string, as returned by >
< the scanner, that matches the rule >
< yang-string >
yang-string = *yang-char
Bjorklund Standards Track [Page 208]
RFC 7950 YANG 1.1 August 2016
;; any Unicode or ISO/IEC 10646 character, including tab, carriage
;; return, and line feed but excluding the other C0 control
;; characters, the surrogate blocks, and the noncharacters
yang-char = %x09 / %x0A / %x0D / %x20-D7FF /
; exclude surrogate blocks %xD800-DFFF
%xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF
%xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF
%x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF
%x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF
%x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF
%x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF
%x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF
%x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF
%x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF
%x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF
%x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF
%xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF
%xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF
%xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF
%xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF
%xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF
%xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF
%x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF
integer-value = ("-" non-negative-integer-value) /
non-negative-integer-value
non-negative-integer-value = "0" / positive-integer-value
positive-integer-value = (non-zero-digit *DIGIT)
zero-integer-value = 1*DIGIT
stmtend = optsep (";" / "{" stmtsep "}") stmtsep
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)
Bjorklund Standards Track [Page 209]
RFC 7950 YANG 1.1 August 2016
SQUOTE = %x27
; single quote
;;; core rules from RFC 5234
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard newline
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; double quote
HTAB = %x09
; horizontal tab
LF = %x0A
; line feed
SP = %x20
; space
WSP = SP / HTAB
; whitespace
<CODE ENDS>
Bjorklund Standards Track [Page 210]
RFC 7950 YANG 1.1 August 2016
15. NETCONF Error Responses for YANG-Related Errors
15. YANG関連のエラーに対するNETCONFエラー応答
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ステートメントに「error-app-tag」サブステートメントがある場合、それは以下で指定されたデフォルト値をオーバーライドします。
15.1. Error Message for Data That Violates a "unique" Statement
15.1。 「一意の」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a "unique" constraint is invalidated, the following error MUST be returned:
NETCONF操作の結果、構成データが「一意の」制約が無効になる場合は、次のエラーを返す必要があります。
error-tag: operation-failed
エラータグ：操作失敗
error-app-tag: data-not-unique
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.
The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1").
<non-unique>：「一意の」制約を無効にするリーフを指すインスタンス識別子が含まれます。 この要素は、一意でない葉ごとに1つ存在します。 <non-unique>要素はYANGネームスペースにあります（ "urn：ietf：params：xml：ns：yang：1"）。
15.2. Error Message for Data That Violates a "max-elements" Statement
15.2。 「max-elements」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too many entries, the following error MUST be returned:
NETCONF操作の結果、リストまたはリーフリストのエントリが多すぎる構成データになる場合は、次のエラーを返す必要があります。
error-tag: operation-failed
エラータグ：操作失敗
error-app-tag: too-many-elements
error-app-tag：多すぎる要素
This error is returned once, with the error-path identifying the list node, even if there is more than one extra child present.
このエラーは1回返され、複数の子が存在する場合でも、エラーパスがリストノードを識別します。
15.3. Error Message for Data That Violates a "min-elements" Statement
15.3。 「min-elements」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too few entries, the following error MUST be returned:
NETCONF操作の結果、構成データのリストまたはリーフリストのエントリが少なすぎる場合は、次のエラーを返す必要があります。
error-tag: operation-failed
エラータグ：操作失敗
error-app-tag: too-few-elements
error-app-tag：少なすぎる要素
This error is returned once, with the error-path identifying the list node, even if there is more than one child missing.
このエラーは1回返され、複数の子が欠落している場合でも、エラーパスはリストノードを識別します。
Bjorklund Standards Track [Page 211] RFC 7950 YANG 1.1 August 2016 15.4. Error Message for Data That Violates a "must" Statement
15.4。 「必須」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where the restrictions imposed by a "must" statement are violated, the following error MUST be returned, unless a specific "error-app-tag" substatement is present for the "must" statement.
NETCONF操作の結果、「must」ステートメントによって課せられた制限に違反する構成データが生じる場合、「must」ステートメントに特定の「error-app-tag」サブステートメントが存在しない限り、次のエラーを返さなければなりません（MUST）。
error-tag: operation-failed
エラータグ：操作失敗
error-app-tag: must-violation
error-app-tag：違反する必要があります
15.5. Error Message for Data That Violates a "require-instance"
Statement
15.5。 「require-instance」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a leaf of type "instance-identifier" or "leafref" marked with require-instance "true" refers to an instance that does not exist, the following error MUST be returned:
NETCONF操作により、「instance-identifier」または「leafref」タイプのリーフがrequire-instance「true」でマークされた構成データが存在しないインスタンスを参照する場合、次のエラーを返す必要があります。
error-tag: data-missing
エラータグ：データの欠落
error-app-tag: instance-required
error-app-tag：インスタンスが必要
error-path: Path to the instance-identifier or leafref leaf.
error-path：インスタンス識別子またはleafrefリーフへのパス。
15.6. Error Message for Data That Violates a Mandatory "choice"
Statement
15.6 必須の「選択」ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where no nodes exists in a mandatory choice, the following error MUST be returned:
NETCONF操作の結果、必須の選択肢にノードが存在しない構成データになる場合は、次のエラーを返す必要があります。
error-tag: data-missing
エラータグ：データの欠落
error-app-tag: missing-choice
error-app-tag：missing-choice
error-path: Path to the element with the missing choice.
error-path：選択肢のない要素へのパス。
error-info: <missing-choice>: Contains the name of the missing
mandatory choice.
<missing-choice>：欠落している必須の選択肢の名前が含まれています。
The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1").
<missing-choice>要素は、YANGネームスペースにあります（ "urn：ietf：params：xml：ns：yang：1"）。
15.7. Error Message for the "insert" Operation
15.7。 「挿入」操作のエラーメッセージ
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 an instance that does not exist, the following error MUST be returned:
「挿入」および「キー」または「値」属性がリストまたはリーフリストノードの<edit-config>で使用され、「キー」または「値」が存在しないインスタンスを参照している場合、 次のエラーを返さなければなりません：
error-tag: bad-attribute
エラータグ：悪い属性
error-app-tag: missing-instance
error-app-tag：missing-instance
Bjorklund Standards Track [Page 212] RFC 7950 YANG 1.1 August 2016 16. IANA Considerations
16. IANAに関する考慮事項
This document registers one capability identifier URN from the "Network Configuration Protocol (NETCONF) Capability URNs" registry:
このドキュメントでは、「ネットワーク構成プロトコル（NETCONF）機能URN」レジストリから機能識別子URNを1つ登録しています。
Index Capability Identifier
------------- ---------------------------------------------------
:yang-library urn:ietf:params:netconf:capability:yang-library:1.0
17. Security Considerations
17.セキュリティに関する考慮事項
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 those for the base NETCONF protocol (see Section 9 in [RFC6241]).
基本的なNETCONFプロトコルと同じ考慮事項が関連しています（[RFC6241]のセクション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.
セキュリティの問題は、YANGでモデル化されたデータの使用に関連しています。 このような問題は、データモデルを説明するドキュメントや、データの操作に使用されるインターフェイスに関するドキュメント（NETCONFドキュメントなど）で対処する必要があります。
Data modeled in YANG is dependent upon:
YANGでモデル化されたデータは、次のものに依存しています。
o the security of the transmission infrastructure used to send
sensitive information.
機密情報の送信に使用される送信インフラストラクチャのセキュリティ。
o the security of applications that store or release such sensitive
information.
このような機密情報を保存またはリリースするアプリケーションのセキュリティ。
o adequate authentication and access control mechanisms to restrict
the usage of sensitive data.
機密データの使用を制限するための適切な認証およびアクセス制御メカニズム。
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 the privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised.
YANGパーサーは、不正な形式のドキュメントに対して堅牢である必要があります。 未知または信頼できないソースから不正な形式のドキュメントを読み取ると、攻撃者がYANGパーサーを実行しているユーザーの権限を取得する可能性があります。 極端な状況では、マシン全体が危険にさらされる可能性があります。
Bjorklund Standards Track [Page 213]
RFC 7950 YANG 1.1 August 2016
18. References
18.1. Normative References
[ISO.10646]
International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO Standard 10646:2014, 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>.
Bjorklund Standards Track [Page 214]
RFC 7950 YANG 1.1 August 2016
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation REC-xml-20081126,
November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML-NAMES]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "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>.
[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>.
[XSD-TYPES]
Biron, P. and A. Malhotra, "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>.
18.2. Informative References
[CoMI] van der Stok, P. and A. Bierman, "CoAP Management
Interface", Work in Progress,
draft-vanderstok-core-comi-09, March 2016.
[IEEE754-2008]
IEEE, "IEEE Standard for Floating-Point Arithmetic",
IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008,
<http://standards.ieee.org/findstds/
standard/754-2008.html>.
[RESTCONF]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", Work in Progress,
draft-ietf-netconf-restconf-16, August 2016.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>.
Bjorklund Standards Track [Page 215]
RFC 7950 YANG 1.1 August 2016
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780,
DOI 10.17487/RFC3780, May 2004,
<http://www.rfc-editor.org/info/rfc3780>.
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG
Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012,
<http://www.rfc-editor.org/info/rfc6643>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<http://www.rfc-editor.org/info/rfc7951>.
[XPATH2.0]
Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Path Language
(XPath) 2.0 (Second Edition)", World Wide Web Consortium
Recommendation REC-xpath20-20101214, December 2010,
<http://www.w3.org/TR/2010/REC-xpath20-20101214>.
[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>.
[YANG-Guidelines]
Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", Work in Progress,
draft-ietf-netmod-rfc6087bis-07, July 2016.
Bjorklund Standards Track [Page 216]
RFC 7950 YANG 1.1 August 2016
Acknowledgements
The editor wishes to thank the following individuals, who all
provided helpful comments on various draft versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Per Hedeland, Leif Johansson,
Ladislav Lhotka, Lionel Morand, Gerhard Muenz, Peyman Owladi, Tom
Petch, Randy Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert
Wijnen, Robert Wilton, and Dale Worley.
Contributors
The following people all contributed significantly to the initial
YANG document:
- Andy Bierman (YumaWorks)
- Balazs Lengyel (Ericsson)
- David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks)
Author's Address
Martin Bjorklund (editor)
Tail-f Systems
Email: mbj@tail-f.com
Bjorklund Standards Track [Page 217]