YANG - ネットワーク構成プロトコルのデータモデリング言語 (NETCONF)
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) M. Bjorklund, Ed.
Request for Comments: 6020 Tail-f Systems
Category: Standards Track October 2010
ISSN: 2070-1721
YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)
YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語
AbstractYANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
YANGは、ネットワーク構成プロトコル（NETCONF）、NETCONFリモートプロシージャコール、およびNETCONF通知によって操作される構成および状態データをモデル化するために使用されるデータモデリング言語です。
Status of This Memo
This is an Internet Standards Track document.
これは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 5741.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 インターネット標準の詳細については、RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6020.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6020で入手できます。
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
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に記載されているように保証なしで提供されます。
Bjorklund Standards Track [Page 1] RFC 6020 YANG October 2010 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として、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
1. Introduction ....................................................8
2. Keywords ........................................................8
3. Terminology .....................................................8
3.1. Mandatory Nodes ...........................................10
4. YANG Overview ..................................................11
4.1. Functional Overview .......................................11
4.2. Language Overview .........................................13
4.2.1. Modules and Submodules .............................13
4.2.2. Data Modeling Basics ...............................13
4.2.3. State Data .........................................18
4.2.4. Built-In Types .....................................18
4.2.5. Derived Types (typedef) ............................19
4.2.6. Reusable Node Groups (grouping) ....................20
4.2.7. Choices ............................................21
4.2.8. Extending Data Models (augment) ....................22
4.2.9. RPC Definitions ....................................23
4.2.10. Notification Definitions ..........................24
5. Language Concepts ..............................................25
5.1. Modules and Submodules ....................................25
5.1.1. Import and Include by Revision .....................26
5.1.2. Module Hierarchies .................................27
5.2. File Layout ...............................................28
5.3. XML Namespaces ............................................29
5.3.1. YANG XML Namespace .................................29
5.4. Resolving Grouping, Type, and Identity Names ..............29
5.5. Nested Typedefs and Groupings .............................29
5.6. Conformance ...............................................30
5.6.1. Basic Behavior .....................................31
5.6.2. Optional Features ..................................31
5.6.3. Deviations .........................................31
5.6.4. Announcing Conformance Information in the
<hello> Message ....................................32
5.7. Data Store Modification ...................................34
6. YANG Syntax ....................................................34
Bjorklund Standards Track [Page 2]
RFC 6020 YANG October 2010
6.1. Lexical Tokenization ......................................34
6.1.1. Comments ...........................................34
6.1.2. Tokens .............................................34
6.1.3. Quoting ............................................35
6.2. Identifiers ...............................................36
6.2.1. Identifiers and Their Namespaces ...................36
6.3. Statements ................................................37
6.3.1. Language Extensions ................................37
6.4. XPath Evaluations .........................................38
6.4.1. XPath Context ......................................38
6.5. Schema Node Identifier ....................................39
7. YANG Statements ................................................39
7.1. The module Statement ......................................39
7.1.1. The module's Substatements .........................41
7.1.2. The yang-version Statement .........................41
7.1.3. The namespace Statement ............................42
7.1.4. The prefix Statement ...............................42
7.1.5. The import Statement ...............................42
7.1.6. The include Statement ..............................43
7.1.7. The organization Statement .........................44
7.1.8. The contact Statement ..............................44
7.1.9. The revision Statement .............................44
7.1.10. Usage Example .....................................45
7.2. The submodule Statement ...................................46
7.2.1. The submodule's Substatements ......................48
7.2.2. The belongs-to Statement ...........................48
7.2.3. Usage Example ......................................49
7.3. The typedef Statement .....................................49
7.3.1. The typedef's Substatements ........................50
7.3.2. The typedef's type Statement .......................50
7.3.3. The units Statement ................................50
7.3.4. The typedef's default Statement ....................50
7.3.5. Usage Example ......................................51
7.4. The type Statement ........................................51
7.4.1. The type's Substatements ...........................51
7.5. The container Statement ...................................51
7.5.1. Containers with Presence ...........................52
7.5.2. The container's Substatements ......................53
7.5.3. The must Statement .................................53
7.5.4. The must's Substatements ...........................55
7.5.5. The presence Statement .............................56
7.5.6. The container's Child Node Statements ..............56
7.5.7. XML Mapping Rules ..................................56
7.5.8. NETCONF <edit-config> Operations ...................56
7.5.9. Usage Example ......................................57
7.6. The leaf Statement ........................................58
7.6.1. The leaf's default value ...........................58
7.6.2. The leaf's Substatements ...........................59
Bjorklund Standards Track [Page 3]
RFC 6020 YANG October 2010
7.6.3. The leaf's type Statement ..........................59
7.6.4. The leaf's default Statement .......................59
7.6.5. The leaf's mandatory Statement .....................60
7.6.6. XML Mapping Rules ..................................60
7.6.7. NETCONF <edit-config> Operations ...................60
7.6.8. Usage Example ......................................61
7.7. The leaf-list Statement ...................................62
7.7.1. Ordering ...........................................62
7.7.2. The leaf-list's Substatements ......................63
7.7.3. The min-elements Statement .........................63
7.7.4. The max-elements Statement .........................63
7.7.5. The ordered-by Statement ...........................64
7.7.6. XML Mapping Rules ..................................64
7.7.7. NETCONF <edit-config> Operations ...................65
7.7.8. Usage Example ......................................66
7.8. The list Statement ........................................67
7.8.1. The list's Substatements ...........................68
7.8.2. The list's key Statement ...........................68
7.8.3. The list's unique Statement ........................69
7.8.4. The list's Child Node Statements ...................70
7.8.5. XML Mapping Rules ..................................70
7.8.6. NETCONF <edit-config> Operations ...................71
7.8.7. Usage Example ......................................72
7.9. The choice Statement ......................................75
7.9.1. The choice's Substatements .........................76
7.9.2. The choice's case Statement ........................76
7.9.3. The choice's default Statement .....................77
7.9.4. The choice's mandatory Statement ...................79
7.9.5. XML Mapping Rules ..................................79
7.9.6. NETCONF <edit-config> Operations ...................79
7.9.7. Usage Example ......................................79
7.10. The anyxml Statement .....................................80
7.10.1. The anyxml's Substatements ........................81
7.10.2. XML Mapping Rules .................................81
7.10.3. NETCONF <edit-config> Operations ..................81
7.10.4. Usage Example .....................................82
7.11. The grouping Statement ...................................82
7.11.1. The grouping's Substatements ......................83
7.11.2. Usage Example .....................................84
7.12. The uses Statement .......................................84
7.12.1. The uses's Substatements ..........................85
7.12.2. The refine Statement ..............................85
7.12.3. XML Mapping Rules .................................86
7.12.4. Usage Example .....................................86
7.13. The rpc Statement ........................................87
7.13.1. The rpc's Substatements ...........................88
7.13.2. The input Statement ...............................88
7.13.3. The output Statement ..............................89
Bjorklund Standards Track [Page 4]
RFC 6020 YANG October 2010
7.13.4. XML Mapping Rules .................................90
7.13.5. Usage Example .....................................91
7.14. The notification Statement ...............................91
7.14.1. The notification's Substatements ..................92
7.14.2. XML Mapping Rules .................................92
7.14.3. Usage Example .....................................93
7.15. The augment Statement ....................................93
7.15.1. The augment's Substatements .......................94
7.15.2. XML Mapping Rules .................................94
7.15.3. Usage Example .....................................95
7.16. The identity Statement ...................................97
7.16.1. The identity's Substatements ......................97
7.16.2. The base Statement ................................97
7.16.3. Usage Example .....................................98
7.17. The extension Statement ..................................98
7.17.1. The extension's Substatements .....................99
7.17.2. The argument Statement ............................99
7.17.3. Usage Example ....................................100
7.18. Conformance-Related Statements ..........................100
7.18.1. The feature Statement ............................100
7.18.2. The if-feature Statement .........................102
7.18.3. The deviation Statement ..........................102
7.19. Common Statements .......................................105
7.19.1. The config Statement .............................105
7.19.2. The status Statement .............................105
7.19.3. The description Statement ........................106
7.19.4. The reference Statement ..........................106
7.19.5. The when Statement ...............................107
8. Constraints ...................................................108
8.1. Constraints on Data ......................................108
8.2. Hierarchy of Constraints .................................109
8.3. Constraint Enforcement Model .............................109
8.3.1. Payload Parsing ...................................109
8.3.2. NETCONF <edit-config> Processing ..................110
8.3.3. Validation ........................................111
9. Built-In Types ................................................111
9.1. Canonical Representation .................................112
9.2. The Integer Built-In Types ...............................112
9.2.1. Lexical Representation ............................113
9.2.2. Canonical Form ....................................114
9.2.3. Restrictions ......................................114
9.2.4. The range Statement ...............................114
9.2.5. Usage Example .....................................115
9.3. The decimal64 Built-In Type ..............................115
9.3.1. Lexical Representation ............................115
9.3.2. Canonical Form ....................................115
9.3.3. Restrictions ......................................116
9.3.4. The fraction-digits Statement .....................116
Bjorklund Standards Track [Page 5]
RFC 6020 YANG October 2010
9.3.5. Usage Example .....................................117
9.4. The string Built-In Type .................................117
9.4.1. Lexical Representation ............................117
9.4.2. Canonical Form ....................................117
9.4.3. Restrictions ......................................117
9.4.4. The length Statement ..............................117
9.4.5. Usage Example .....................................118
9.4.6. The pattern Statement .............................119
9.4.7. Usage Example .....................................119
9.5. The boolean Built-In Type ................................120
9.5.1. Lexical Representation ............................120
9.5.2. Canonical Form ....................................120
9.5.3. Restrictions ......................................120
9.6. The enumeration Built-In Type ............................120
9.6.1. Lexical Representation ............................120
9.6.2. Canonical Form ....................................120
9.6.3. Restrictions ......................................120
9.6.4. The enum Statement ................................120
9.6.5. Usage Example .....................................121
9.7. The bits Built-In Type ...................................122
9.7.1. Restrictions ......................................122
9.7.2. Lexical Representation ............................122
9.7.3. Canonical Form ....................................122
9.7.4. The bit Statement .................................122
9.7.5. Usage Example .....................................123
9.8. The binary Built-In Type .................................123
9.8.1. Restrictions ......................................124
9.8.2. Lexical Representation ............................124
9.8.3. Canonical Form ....................................124
9.9. The leafref Built-In Type ................................124
9.9.1. Restrictions ......................................124
9.9.2. The path Statement ................................124
9.9.3. Lexical Representation ............................125
9.9.4. Canonical Form ....................................125
9.9.5. Usage Example .....................................126
9.10. The identityref Built-In Type ...........................129
9.10.1. Restrictions .....................................129
9.10.2. The identityref's base Statement .................129
9.10.3. Lexical Representation ...........................130
9.10.4. Canonical Form ...................................130
9.10.5. Usage Example ....................................130
9.11. The empty Built-In Type .................................131
9.11.1. Restrictions .....................................131
9.11.2. Lexical Representation ...........................131
9.11.3. Canonical Form ...................................131
9.11.4. Usage Example ....................................131
9.12. The union Built-In Type .................................132
9.12.1. Restrictions .....................................132
Bjorklund Standards Track [Page 6]
RFC 6020 YANG October 2010
9.12.2. Lexical Representation ...........................132
9.12.3. Canonical Form ...................................133
9.13. The instance-identifier Built-In Type ...................133
9.13.1. Restrictions .....................................134
9.13.2. The require-instance Statement ...................134
9.13.3. Lexical Representation ...........................134
9.13.4. Canonical Form ...................................134
9.13.5. Usage Example ....................................134
10. Updating a Module ............................................135
11. YIN ..........................................................137
11.1. Formal YIN Definition ...................................137
11.1.1. Usage Example ....................................141
12. YANG ABNF Grammar ............................................143
13. Error Responses for YANG Related Errors ......................165
13.1. Error Message for Data That Violates a unique
Statement ...............................................165
13.2. Error Message for Data That Violates a
max-elements Statement ..................................165
13.3. Error Message for Data That Violates a
min-elements Statement ..................................165
13.4. Error Message for Data That Violates a must Statement ...166
13.5. Error Message for Data That Violates a
require-instance Statement ..............................166
13.6. Error Message for Data That Does Not Match a
leafref Type ............................................166
13.7. Error Message for Data That Violates a mandatory
choice Statement ........................................166
13.8. Error Message for the "insert" Operation ................167
14. IANA Considerations ..........................................167
14.1. Media type application/yang .............................168
14.2. Media type application/yin+xml ..........................169
15. Security Considerations ......................................170
16. Contributors .................................................171
17. Acknowledgements .............................................171
18. References ...................................................171
18.1. Normative References ....................................171
18.2. Informative References ..................................172
1.はじめに............................................... ..... 8
2.キーワード............................................... ......... 8
3.用語......................................................... ...... 8
3.1.必須ノード........................................... 10
4. YANGの概要........................................................ .... 11
4.1.機能概要................................................. 11
4.2.言語の概要................................................... 13
4.2.1.モジュールとサブモジュール............................. 13
4.2.2.データモデリングの基礎............................... 13
4.2.3.状態データ................................................... 18
4.2.4.組み込み型..................................... 18
4.2.5.派生型（typedef）............................ 19
4.2.6.再利用可能なノードグループ（グループ化）.................... 20
4.2.7.選択肢............................................ 21
4.2.8.データモデルの拡張（拡張）.................... 22
4.2.9. RPC定義................................................. 23
4.2.10.通知の定義.................................... 24
5.言語の概念.............................................................. 25
5.1.モジュールとサブモジュール.................................... 25
5.1.1.リビジョンごとのインポートとインクルード..................... 26
5.1.2.モジュール階層................................. 27
5.2.ファイルレイアウト................................................................... 28
5.3. XML名前空間............................................ 29
5.3.1. YANG XML名前空間................................. 29
5.4.グループ化、タイプ、およびID名の解決.............. 29
5.5.ネストされたTypedefとグループ............................. 29
5.6.適合性......................................................... 30
5.6.1.基本的な動作..................................... 31
5.6.2.オプション機能.................................. 31
5.6.3.偏差................................................. 31
5.6.4.での適合性情報の発表
<hello>メッセージ.................................... 32
5.7.データストアの変更................................... 34
6. YANG構文.............................................. ...... 34
6.1.字句トークン化................................................ 34
6.1.1.コメント.................................................................... 34
6.1.2.トークン.................................................. 34
6.1.3.引用............................................ 35
6.2.識別子............................................... 36
6.2.1.識別子とその名前空間................... 36
6.3.ステートメント................................................ 37
6.3.1.言語拡張機能................................ 37
6.4. XPath評価................................................... 38
6.4.1. XPathコンテキスト................................................ 38
6.5.スキーマノード識別子.................................... 39
7. YANGステートメント........................................................ ..39
7.1.モジュールステートメント................................................ 39
7.1.1.モジュールのサブステートメント......................... 41
7.1.2.陽バージョンの声明......................... 41
7.1.3.名前空間ステートメント............................ 42
7.1.4.接頭辞............................... 42
7.1.5.インポートステートメント............................... 42
7.1.6. includeステートメント.............................. 43
7.1.7.組織声明......................... 44
7.1.8.連絡先ステートメント.............................. 44
7.1.9.改訂声明............................. 44
7.1.10.使用例................................................... 45
7.2.サブモジュールステートメント................................... 46
7.2.1.サブモジュールのサブステートメント...................... 48
7.2.2.所属する声明........................... 48
7.2.3.使用例................................................ 49
7.3. typedefステートメント..................................... 49
7.3.1. typedefのサブステートメント........................ 50
7.3.2. typedefのtypeステートメント....................... 50
7.3.3.単位ステートメント................................ 50
7.3.4. typedefのデフォルトのステートメント.................... 50
7.3.5.使用例................................................ 51
7.4.タイプステートメント........................................ 51
7.4.1.タイプのサブステートメント........................... 51
7.5.コンテナステートメント................................... 51
7.5.1.存在感のあるコンテナ........................... 52
7.5.2.コンテナのサブステートメント............ 53
7.5.3.マストステートメント................................. 53
7.5.4.マストのサブステートメント........................... 55
7.5.5.プレゼンスステートメント............................. 56
7.5.6.コンテナの子ノードステートメント.............. 56
7.5.7. XMLマッピングルール.................................. 56
7.5.8. NETCONF <edit-config>操作................... 56
7.5.9.使用例................................................ 57
7.6リーフステートメント.................................................. 58
7.6.1.リーフのデフォルト値........................... 58
7.6.2.リーフのサブステートメント........................... 59
7.6.3.葉のタイプステートメント.......................... 59
7.6.4.リーフのデフォルトステートメント................................. 59
7.6.5.リーフの必須ステートメント..................... 60
7.6.6. XMLマッピングルール.................................................. 60
7.6.7. NETCONF <edit-config>操作................... 60
7.6.8.使用例................................................ 61
7.7.リーフリストステートメント................................... 62
7.7.1.注文.................................................................... 62
7.7.2.リーフリストのサブステートメント...................... 63
7.7.3. min-elementsステートメント......................... 63
7.7.4. max-elementsステートメント......................... 63
7.7.5. ordered-byステートメント........................... 64
7.7.6. XMLマッピングルール.................................. 64
7.7.7. NETCONF <edit-config>操作................... 65
7.7.8.使用例................................................ 66
7.8.リストステートメント.................................................. 67
7.8.1.リストのサブステートメント........................... 68
7.8.2.リストの重要な声明........................... 68
7.8.3.リスト固有のステートメント........................ 69
7.8.4.リストの子ノードステートメント................... 70
7.8.5. XMLマッピングルール.................................. 70
7.8.6. NETCONF <edit-config>操作................... 71
7.8.7.使用例................................................ 72
7.9.選択ステートメント................................................ 75
7.9.1.選択のサブステートメント......................... 76
7.9.2.選択のケースステートメント.................................. 76
7.9.3.選択のデフォルトステートメント..................... 77
7.9.4.選択の必須ステートメント................... 79
7.9.5. XMLマッピングルール.................................. 79
7.9.6. NETCONF <edit-config>操作................... 79
7.9.7.使用例................................................ 79
7.10. anyxmlステートメント..................................... 80
7.10.1. anyxmlのサブステートメント........................ 81
7.10.2. XMLマッピングルール................................. 81
7.10.3. NETCONF <edit-config>操作.................. 81
7.10.4.使用例................................................... 82
7.11.グループ化ステートメント................................... 82
7.11.1.グループのサブステートメント...................... 83
7.11.2.使用例................................................... 84
7.12. usesステートメント................................................. 84
7.12.1.使用のサブステートメント.......................... 85
7.12.2.洗練されたステートメント.............................. 85
7.12.3. XMLマッピングルール................................. 86
7.12.4.使用例................................................................ 86
7.13. RPCステートメント.................................................. 87
7.13.1. RPCのサブステートメント........................... 88
7.13.2.入力ステートメント............................... 88
7.13.3.出力ステートメント.............................. 89
7.13.4. XMLマッピングルール................................. 90
7.13.5.使用例................................................... 91
7.14.通知ステートメント............................... 91
7.14.1.通知のサブステートメント..... 92
7.14.2. XMLマッピング規則................................. 92
7.14.3.使用例................................................... 93
7.15.増補声明................................................. 93
7.15.1.拡張のサブステートメント....................... 94
7.15.2. XMLマッピングルール................................. 94
7.15.3.使用例................................................... 95
7.16.アイデンティティステートメント................................... 97
7.16.1.アイデンティティのサブステートメント...................... 97
7.16.2.基本声明................................ 97
7.16.3.使用例................................................................ 98
7.17.拡張ステートメント.................................. 98
7.17.1.拡張機能のサブステートメント..................... 99
7.17.2.議論声明............................ 99
7.17.3.使用例................................................... 100
7.18.適合性関連のステートメント.......................................... 100
7.18.1.機能ステートメント............................ 100
7.18.2. if-featureステートメント......................... 102
7.18.3.偏差ステートメント.......................... 102
7.19.共通の声明................................................. 105
7.19.1. configステートメント............................. 105
7.19.2.ステータスステートメント............................. 105
7.19.3.説明文.................................. 106
7.19.4.参照ステートメント.......................... 106
7.19.5. whenステートメント............................... 107
8.制約............................................... .... 108
8.1.データの制約................................................ 108
8.2.制約の階層................................. 109
8.3.制約施行モデル............................. 109
8.3.1.ペイロード解析................................... 109
8.3.2. NETCONF <edit-config>処理.................. 110
8.3.3.検証........................................ 111
9.組み込み型...................................................... .... 111
9.1.正規表現................................. 112
9.2.整数組み込み型............................... 112
9.2.1.字句表現............................ 113
9.2.2.正規形.................................... 114
9.2.3.制限事項................................................ 114
9.2.4.範囲ステートメント............................... 114
9.2.5.使用例................................................................ 115
9.3. decimal64組み込みタイプ.............................. 115
9.3.1.字句表現............................ 115
9.3.2.正規形.................................... 115
9.3.3.制限事項................................................ 116
9.3.4.小数桁ステートメント..................... 116
9.3.5.使用例................................................... 117
9.4.文字列の組み込みタイプ................................. 117
9.4.1.字句表現............................ 117
9.4.2.正規形................................................. 117
9.4.3.制限事項................................................ 117
9.4.4.長さステートメント.............................. 117
9.4.5.使用例................................................................ 118
9.4.6.パターンステートメント............................. 119
9.4.7.使用例................................................................ 119
9.5.ブール組み込み型................................ 120
9.5.1.字句表現............................ 120
9.5.2.正規形.................................... 120
9.5.3.制限事項................................................ 120
9.6.列挙型組み込みタイプ............................ 120
9.6.1.字句表現............................ 120
9.6.2.正規形.................................... 120
9.6.3.制限事項................................................ 120
9.6.4.列挙ステートメント................................ 120
9.6.5.使用例................................................................ 121
9.7.ビット内蔵タイプ................................................. 122
9.7.1.制限事項................................................ 122
9.7.2.字句表現............................ 122
9.7.3.正規形.................................... 122
9.7.4.ビットステートメント................................. 122
9.7.5.使用例................................................... 123
9.8.バイナリ組み込みタイプ................................. 123
9.8.1.制限事項................................................ 124
9.8.2.字句表現............................ 124
9.8.3.正規形................................................. 124
9.9. leafref組み込みタイプ................................ 124
9.9.1.制限事項................................................ 124
9.9.2.パスステートメント................................ 124
9.9.3.字句表現............................ 125
9.9.4.正規形................................................. 125
9.9.5.使用例................................................................ 126
9.10. identityref組み込み型........................... 129
9.10.1.制限事項................................................................ 129
9.10.2. identityrefのベースステートメント................. 129
9.10.3.字句表現........................... 130
9.10.4.正規形................................... 130
9.10.5.使用例................................................... 130
9.11.空の組み込みタイプ................................. 131
9.11.1.制限事項................................................................ 131
9.11.2.字句表現........................... 131
9.11.3.正規形................................... 131
9.11.4.使用例................................................... 131
9.12.ユニオン組み込み型................................................ 132
9.12.1.制限事項................................................................ 132
9.12.2.字句表現........................... 132
9.12.3.正規形................................... 133
9.13.インスタンス識別子の組み込みタイプ................... 133
9.13.1.制限事項................................................................ 134
9.13.2.インスタンスを必要とするステートメント................... 134
9.13.3.字句表現........................... 134
9.13.4.正規形................................... 134
9.13.5.使用例................................................... 134
10.モジュールの更新................................................................ 135
11. YIN ............................................... ........... 137
11.1正式なYINの定義................................... 137
11.1.1.使用例................................................... 141
12. YANG ABNF文法............................................ 143
13. YANGに関連するエラーのエラー応答...................... 165
13.1.一意に違反するデータのエラーメッセージ
ステートメント............................................... 165
13.2.に違反するデータのエラーメッセージ
max-elementsステートメント.................................. 165
13.3.に違反するデータのエラーメッセージ
min-elementsステートメント.................................. 165
13.4. mustステートメントに違反するデータのエラーメッセージ... 166
13.5.に違反するデータのエラーメッセージ
require-instanceステートメント........................................ 166
13.6.に一致しないデータのエラーメッセージ
leafrefタイプ............................................ 166
13.7.必須に違反するデータのエラーメッセージ
選択ステートメント................................................................. 166
13.8. 「挿入」操作のエラーメッセージ................ 167
14. IANAの考慮事項.......................................... 167
14.1.メディアタイプアプリケーション/ヤン............................. 168
14.2.メディアタイプapplication / yin + xml .......................... 169
15.セキュリティに関する考慮事項................................................ 170
16.貢献者............................................... ..171
17.謝辞....................................................... 171
18.参考資料......................................................... .... 171
18.1.規範的な参考文献.................................................... 171
18.2.参考資料................................................. 172
Bjorklund Standards Track [Page 7] RFC 6020 YANG October 2010 1. Introduction
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], Section 1.1).
YANGは、ネットワーク構成プロトコル（NETCONF）、NETCONFリモートプロシージャコール、およびNETCONF通知によって操作される構成および状態データをモデル化するために使用されるデータモデリング言語です。 YANGは、NETCONFの操作とコンテンツ層をモデル化するために使用されます（NETCONF構成プロトコル[RFC4741]、セクション1.1を参照）。
This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in the Extensible Markup Language (XML), and how NETCONF operations are used to manipulate the data.
このドキュメントでは、YANG言語の構文とセマンティクス、YANGモジュールで定義されたデータモデルが拡張マークアップ言語（XML）でどのように表現されるか、およびNETCONF操作を使用してデータを操作する方法について説明します。
2. Keywords
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」 このドキュメントのBCP 14 [RFC2119]で説明されているように解釈されます。
3. Terminology
3.用語
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データ型。
o choice: A schema node where only one of a number of identified
alternatives is valid.
選択：識別された多数の選択肢のうち1つだけが有効なスキーマノード。
o configuration data: The set of writable data that is required to
transform a system from its initial default state into its current
state [RFC4741].
構成データ：システムを初期のデフォルト状態から現在の状態[RFC4741]に変換するために必要な書き込み可能なデータのセット。
o conformance: A measure of how accurately a device 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つのインスタンスに存在する内部データノード。 コンテナには値はありませんが、子ノードのセットがあります。
Bjorklund Standards Track [Page 8]
RFC 6020 YANG October 2010
o data definition statement: A statement that defines new data
nodes. One of container, leaf, leaf-list, list, choice, case,
augment, uses, and anyxml.
データ定義ステートメント：新しいデータノードを定義するステートメント。 コンテナー、リーフ、リーフリスト、リスト、選択、ケース、拡張、使用、および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, and anyxml.
データノード：データツリーでインスタンス化できるスキーマツリーのノード。 container、leaf、leaf-list、list、およびanyxmlのいずれか。
o data tree: The instantiated tree of configuration and state data
on a device.
データツリー：デバイス上にインスタンス化された構成および状態データのツリー。
o derived type: A type that is derived from a built-in type (such as
uint32), or another derived type.
派生型：組み込み型（uint32など）から派生した型、または別の派生型。
o device deviation: A failure of the device to implement the module
faithfully.
デバイス偏差：モジュールが忠実に実装されていないデバイスの障害。
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 devices that support that feature.
機能：モデルの一部をオプションとしてマークするためのメカニズム。 定義には機能名のタグを付けることができ、その機能をサポートするデバイスでのみ有効です。
o grouping: A reusable set of schema nodes, which may be used
locally in the module, in modules that include it, and by other
modules that import from it. The grouping statement is not a data
definition statement and, as such, does not define any nodes in
the schema tree.
グループ化：モジュール内、それを含むモジュール内、およびそれからインポートする他のモジュールによってローカルで使用できる、再利用可能なスキーマノードのセット。 グループ化ステートメントはデータ定義ステートメントではないため、スキーマツリーのノードを定義しません。
o identifier: Used to identify different kinds of YANG items by
name.
識別子：さまざまな種類のYANGアイテムを名前で識別するために使用されます。
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.
葉リスト：葉ノードと同様ですが、単一のノードではなく、一意に識別可能なノードのセットを定義します。 各ノードには値がありますが、子ノードはありません。
Bjorklund Standards Track [Page 9]
RFC 6020 YANG October 2010
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 module: A YANG module defines a hierarchy of nodes that can be
used for NETCONF-based operations. With its definitions and the
definitions it imports or includes from elsewhere, a module is
self-contained and "compilable".
module：YANGモジュールは、NETCONFベースの操作に使用できるノードの階層を定義します。 モジュールの定義とそれがインポートまたは他の場所からインクルードする定義により、モジュールは自己完結型で「コンパイル可能」です。
o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
RPC：NETCONFプロトコル内で使用されるリモートプロシージャコール。
o RPC operation: A specific Remote Procedure Call, as used within
the NETCONF protocol. It is also called a protocol operation.
RPC操作：NETCONFプロトコル内で使用される特定のリモートプロシージャコール。 これは、プロトコル操作とも呼ばれます。
o schema node: A node in the schema tree. One of container, leaf,
leaf-list, list, choice, case, rpc, input, output, notification,
and anyxml.
スキーマノード：スキーマツリーのノード。 コンテナ、リーフ、リーフリスト、リスト、選択、ケース、rpc、入力、出力、通知、anyxmlのいずれか。
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 state data: The additional data on a system that is not
configuration data such as read-only status information and
collected statistics [RFC4741].
状態データ：読み取り専用のステータス情報や収集された統計[RFC4741]などの構成データではないシステムの追加データ。
o submodule: A partial module definition that contributes derived
types, groupings, data nodes, RPCs, and notifications to a module.
A YANG module can be constructed from a number of submodules.
サブモジュール：派生型、グループ化、データノード、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.
197/5000 用途：「uses」ステートメントは、グループ化ステートメントで定義されたスキーマノードのセットをインスタンス化するために使用されます。 インスタンス化されたノードは、特定のニーズに合わせて調整および拡張することができます。
3.1. Mandatory Nodes
3.1。 必須ノード
A mandatory node is one of:
必須ノードは次のいずれかです。
o A leaf, choice, or anyxml node with a "mandatory" statement with
the value "true".
リーフ、チョイス、または値が「true」の「必須」ステートメントを持つanyxmlノード。
o A list or leaf-list node with a "min-elements" statement with a
value greater than zero.
ゼロより大きい値を持つ「min-elements」ステートメントを持つリストまたはリーフリストノード。
Bjorklund Standards Track [Page 10]
RFC 6020 YANG October 2010
o A container node without a "presence" statement, which has at
least one mandatory node as a child.
子として少なくとも1つの必須ノードを持つ、「存在」ステートメントのないコンテナノード。
4. YANG Overview
4. YANGの概要
4.1. Functional Overview
4.1。 機能の概要
YANG is a language used to model data for the NETCONF protocol. A YANG module defines a hierarchy of data that can be used for NETCONF- based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data sent between a NETCONF client and server.
YANGは、NETCONFプロトコルのデータをモデル化するために使用される言語です。 YANGモジュールは、構成、状態データ、リモートプロシージャコール（RPC）、通知など、NETCONFベースの操作に使用できるデータの階層を定義します。 これにより、NETCONFクライアントとサーバーの間で送信されるすべてのデータの完全な説明が可能になります。
YANG models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes. YANG provides clear and concise descriptions of the nodes, as well as the interaction between those nodes.
YANGは、データの階層構造をツリーとしてモデル化します。各ノードには名前があり、値または子ノードのセットがあります。 YANGは、ノードの明確で簡潔な説明、およびそれらのノード間の相互作用を提供します。
YANG structures data models into modules and submodules. A module can import data from other external modules, and include data from submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation can be conditional, with new nodes appearing only if certain conditions are met.
YANGは、データモデルをモジュールとサブモジュールに構造化します。 モジュールは他の外部モジュールからデータをインポートし、サブモジュールからのデータを含めることができます。 階層を拡張して、あるモジュールが別のモジュールで定義された階層にデータノードを追加できるようにすることができます。 この拡張は条件付きにすることができ、特定の条件が満たされた場合にのみ新しいノードが表示されます。
YANG models can describe constraints to be enforced on the data, restricting the appearance or value of nodes based on the presence or value of other nodes in the hierarchy. These constraints are enforceable by either the client or the server, and valid content MUST abide by them.
YANGモデルは、データに適用される制約を記述し、階層内の他のノードの存在または値に基づいてノードの外観または値を制限できます。 これらの制約はクライアントまたはサーバーのいずれかによって強制可能であり、有効なコンテンツはそれらに従う必要があります。
YANG defines a set of built-in types, and has a type mechanism through which additional types may be defined. Derived types can restrict their base type's set of valid values using mechanisms like range or pattern restrictions that can be enforced by clients or servers. They can also define usage conventions for use of the derived type, such as a string-based type that contains a host name.
YANGは一連の組み込み型を定義し、追加の型を定義できる型メカニズムを備えています。 派生型は、クライアントやサーバーによって強制できる範囲やパターンの制限などのメカニズムを使用して、基本型の有効な値のセットを制限できます。 ホスト名を含む文字列ベースの型など、派生型を使用するための使用規則を定義することもできます。
YANG permits the definition of reusable groupings of nodes. The instantiation of these groupings can refine or augment the nodes, allowing it to tailor the nodes to its particular needs. Derived types and groupings can be defined in one module or submodule and used in either that location or in another module or submodule that imports or includes it.
YANGでは、再利用可能なノードのグループ化を定義できます。 これらのグループ化のインスタンス化により、ノードを調整または拡張し、特定のニーズに合わせてノードを調整できます。 派生型とグループは、1つのモジュールまたはサブモジュールで定義し、その場所、またはそれをインポートまたはインクルードする別のモジュールまたはサブモジュールで使用できます。
Bjorklund Standards Track [Page 11] RFC 6020 YANG October 2010 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 11), allowing applications using XML parsers and Extensible Stylesheet Language Transformations (XSLT) scripts to operate on the models. The conversion from YANG to YIN is lossless, so content in YIN can be round-tripped back into YANG.
YANGモジュールは、YANG Independent Notation（YIN）（セクション11）と呼ばれる同等のXML構文に変換できるため、XMLパーサーとExtensible Stylesheet Language Transformations（XSLT）スクリプトを使用するアプリケーションでモデルを操作できます。 YANGからYINへの変換はロスレスなので、YINのコンテンツをYANGに戻すことができます。
YANG strikes a balance between high-level data modeling and low-level bits-on-the-wire encoding. The reader of a YANG module can see the high-level view of the data model while understanding how the data will be encoded in NETCONF operations.
YANGは、高レベルのデータモデリングと低レベルのビットオンザワイヤエンコーディングのバランスをとっています。 YANGモジュールの読者は、NETCONF操作でデータがどのようにエンコードされるかを理解しながら、データモデルの概要を見ることができます。
YANG is an extensible language, allowing extension statements to be defined by standards bodies, vendors, and individuals. The statement syntax allows these extensions to coexist with standard YANG statements in a natural way, while extensions in a YANG module stand out sufficiently for the reader to notice them.
YANGは拡張可能な言語であり、標準化団体、ベンダー、および個人が拡張ステートメントを定義できるようにします。 ステートメント構文により、これらの拡張機能は標準のYANGステートメントと自然に共存できますが、YANGモジュールの拡張機能は、読者がそれらに気付くのに十分なほど目立ちます。
YANG resists the tendency to solve all possible problems, limiting the problem space to allow expression of NETCONF data models, not arbitrary XML documents or arbitrary data models. The data models described by YANG are designed to be easily operated upon by NETCONF operations.
YANGは、あらゆる問題を解決する傾向に抵抗し、問題の空間を制限して、任意のXML文書や任意のデータモデルではなく、NETCONFデータモデルを表現できるようにします。 YANGによって記述されたデータモデルは、NETCONF操作で簡単に操作できるように設計されています。
To the extent possible, YANG maintains compatibility with Simple Network Management Protocol's (SNMP's) SMIv2 (Structure of Management Information version 2 [RFC2578], [RFC2579]). SMIv2-based MIB modules can be automatically translated into YANG modules for read-only access. However, YANG is not concerned with reverse translation from YANG to SMIv2.
YANGは、可能な限り、Simple Network Management Protocol（SNMP）のSMIv2（Structure of Management Information version 2 [RFC2578]、[RFC2579]）との互換性を維持しています。 SMIv2ベースのMIBモジュールは、読み取り専用アクセス用に自動的にYANGモジュールに変換できます。 ただし、YANGは、YANGからSMIv2への逆変換とは関係ありません。
Like NETCONF, YANG targets smooth integration with the device's native management infrastructure. This allows implementations to leverage their existing access control mechanisms to protect or expose elements of the data model.
NETCONFと同様に、YANGはデバイスのネイティブ管理インフラストラクチャとのスムーズな統合を目標としています。 これにより、実装は既存のアクセス制御メカニズムを活用して、データモデルの要素を保護または公開できます。
Bjorklund Standards Track [Page 12] RFC 6020 YANG October 2010 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. This progressive approach handles the inter-related nature of YANG concepts and statements. A detailed description of YANG statements and syntax begins in Section 7.
このセクションでは、後のセクションで言語の詳細を理解するのに役立つYANGで使用されるいくつかの重要な構成要素を紹介します。 この進歩的なアプローチは、YANGの概念とステートメントの相互に関連する性質を処理します。 YANGステートメントと構文の詳細な説明は、セクション7から始まります。
4.2.1. Modules and Submodules
4.2.1。 モジュールとサブモジュール
A module contains three types of statements: module-header statements, revision statements, and definition statements. The module header statements describe the module and give information about the module itself, the revision statements give information about the history of the module, and the definition statements are the body of the module where the data model is defined.
モジュールには、モジュールヘッダーステートメント、リビジョンステートメント、定義ステートメントの3種類のステートメントが含まれています。 モジュールヘッダーステートメントはモジュールを説明し、モジュール自体に関する情報を提供し、リビジョンステートメントはモジュールの履歴に関する情報を提供し、定義ステートメントはデータモデルが定義されているモジュールの本体です。
A NETCONF server may implement a number of modules, allowing multiple views of the same data, or multiple views of disjoint subsections of the device's data. Alternatively, the server may implement only one module that defines all available data.
NETCONFサーバーは複数のモジュールを実装して、同じデータの複数のビュー、またはデバイスのデータの互いに素なサブセクションの複数のビューを許可する場合があります。 または、サーバーは、使用可能なすべてのデータを定義するモジュールを1つだけ実装することもできます。
A module may be divided into submodules, based on the needs of the module owner. The external view remains that of a single module, regardless of the presence or size of its submodules.
モジュールは、モジュール所有者のニーズに基づいて、サブモジュールに分割できます。 サブモジュールの存在やサイズに関係なく、外観は単一のモジュールの外観のままです。
The "include" statement allows a module or submodule to reference material in submodules, and the "import" statement allows references to material defined in other modules.
「include」ステートメントは、モジュールまたはサブモジュールがサブモジュール内のマテリアルを参照することを許可し、「import」ステートメントは、他のモジュールで定義されたマテリアルへの参照を許可します。
4.2.2. Data Modeling Basics
4.2.2。 データモデリングの基本
YANG defines four types of nodes for data modeling. In each of the following subsections, the example shows the YANG syntax as well as a corresponding NETCONF XML representation.
YANGは、データモデリング用に4種類のノードを定義します。 次の各サブセクションの例では、YANG構文と対応するNETCONF XML表現を示しています。
4.2.2.1. Leaf Nodes
4.2.2.1。 葉ノード
A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type and no child nodes.
リーフノードには、整数や文字列などの単純なデータが含まれます。 特定のタイプの値が1つだけあり、子ノードはありません。
YANG Example:
leaf host-name {
type string;
description "Hostname for this system";
}
Bjorklund Standards Track [Page 13]
RFC 6020 YANG October 2010
NETCONF XML 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 is a sequence of leaf nodes with exactly one value of a particular type per leaf.
リーフリストは、リーフごとに特定のタイプの値を1つだけ持つ一連のリーフノードです。
YANG Example:
leaf-list domain-search {
type string;
description "List of domain names to search";
}
NETCONF XML 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で説明しています。
4.2.2.3. Container Nodes
4.2.2.3。 コンテナノード
A container node is used to group related nodes in a subtree. A container has only child nodes and no value. A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists).
コンテナノードは、サブツリー内の関連ノードをグループ化するために使用されます。 コンテナには子ノードのみがあり、値はありません。 コンテナには、任意のタイプ（リーフ、リスト、コンテナ、リーフリストを含む）の子ノードをいくつでも含めることができます。
YANG Example:
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
}
}
Bjorklund Standards Track [Page 14]
RFC 6020 YANG October 2010
NETCONF XML Example:
<system>
<login>
<message>Good morning</message>
</login>
</system>
The "container" statement is covered in Section 7.5.
「コンテナ」ステートメントについては、セクション7.5で説明しています。
4.2.2.4. List Nodes
4.2.2.4。 ノードのリスト
A list defines a sequence of list entries. Each entry is like a structure or a record instance, and is uniquely identified by the values of its key leafs. A list can define multiple key leafs and may contain any number of child nodes of any type (including leafs, lists, containers etc.).
リストは一連のリストエントリを定義します。 各エントリは構造またはレコードインスタンスのようなものであり、キーリーフの値によって一意に識別されます。 リストは複数のキーリーフを定義でき、任意のタイプ（リーフ、リスト、コンテナなどを含む）の子ノードをいくつでも含めることができます。 。
YANG Example:
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
Bjorklund Standards Track [Page 15]
RFC 6020 YANG October 2010
NETCONF XML 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で説明しています。
4.2.2.5. Example Module
4.2.2.5。 モジュールの例
These statements are combined to define the module:
これらのステートメントを組み合わせてモジュールを定義します。
Bjorklund Standards Track [Page 16]
RFC 6020 YANG October 2010
// Contents of "acme-system.yang"
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
Bjorklund Standards Track [Page 17]
RFC 6020 YANG October 2010
4.2.3. 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, to be reported using NETCONF's <get> operation, not the <get-config> operation. Parent containers, lists, and key leafs are reported also, giving the context for the state data.
YANGは、「config」ステートメントに基づいて、構成データだけでなく状態データもモデル化できます。 ノードに「config false」のタグが付けられると、そのサブ階層には状態データとしてフラグが付けられ、<get-config>操作ではなくNETCONFの<get>操作を使用して報告されます。 親コンテナー、リスト、およびキーリーフも報告され、状態データのコンテキストが提供されます。
In this example, two leafs are defined for each interface, a configured speed and an observed speed. The observed speed is not configuration, so it can be returned with NETCONF <get> operations, but not with <get-config> operations. The observed speed is not configuration data, and it cannot be manipulated using <edit-config>.
この例では、構成済みの速度と観測された速度の2つのリーフが各インターフェースに定義されています。 観測された速度は構成ではないため、NETCONF <get>操作では返されますが、<get-config>操作では返されません。 観測された速度は構成データではなく、<edit-config>を使用して操作することはできません。
list interface {
key "name";
leaf name {
type string;
}
leaf speed {
type enumeration {
enum 10m;
enum 100m;
enum auto;
}
}
leaf observed-speed {
type uint32;
config false;
}
}
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 from the management domain. The following table summarizes the built-in types discussed in Section 9:
YANGには、多くのプログラミング言語に似た組み込み型のセットがありますが、管理ドメインからの特別な要件による違いがあります。 次の表は、セクション9で説明されている組み込み型をまとめたものです。
Bjorklund Standards Track [Page 18]
RFC 6020 YANG October 2010
+---------------------+-------------------------------------+
| Name | Description |
+---------------------+-------------------------------------+
| binary | Any binary data |
| bits | A set of bits or flags |
| boolean | "true" or "false" |
| decimal64 | 64-bit signed decimal number |
| empty | A leaf that does not have any value |
| enumeration | Enumerated strings |
| identityref | A reference to an abstract identity |
| instance-identifier | References a data tree node |
| int8 | 8-bit signed integer |
| int16 | 16-bit signed integer |
| int32 | 32-bit signed integer |
| int64 | 64-bit signed integer |
| leafref | A reference to a leaf instance |
| string | Human-readable string |
| uint8 | 8-bit unsigned integer |
| uint16 | 16-bit unsigned integer |
| uint32 | 32-bit unsigned integer |
| uint64 | 64-bit unsigned integer |
| union | Choice of member types |
+---------------------+-------------------------------------+
The "type" statement is covered in Section 7.4.
「type」ステートメントについては、セクション7.4で説明しています。
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";
}
description "Percentage";
}
leaf completed {
type percent;
}
Bjorklund Standards Track [Page 19]
RFC 6020 YANG October 2010
NETCONF XML 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」ステートメントでインスタンス化されるノードのセットを定義します。
grouping target {
leaf address {
type inet:ip-address;
description "Target IP address";
}
leaf port {
type inet:port-number;
description "Target port number";
}
}
container peer {
container destination {
uses target;
}
}
NETCONF XML Example:
<peer>
<destination>
<address>192.0.2.1</address>
<port>830</port>
</destination>
</peer>
The grouping can be refined as it is used, allowing certain
statements to be overridden. In this example, the description is
refined:
使用時にグループ化を調整して、特定のステートメントを上書きすることができます。 この例では、説明が洗練されています。
Bjorklund Standards Track [Page 20]
RFC 6020 YANG October 2010
container connection {
container source {
uses target {
refine "address" {
description "Source IP address";
}
refine "port" {
description "Source port number";
}
}
}
container destination {
uses target {
refine "address" {
description "Destination IP address";
}
refine "port" {
description "Destination port number";
}
}
}
}
The "grouping" statement is covered in Section 7.11.
「グループ化」ステートメントについては、セクション7.11で説明しています。
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つの「ケース」にしか表示されません。
When an element from one case is created, all elements from all other cases are implicitly deleted. The device handles the enforcement of the constraint, preventing incompatibilities from existing in the configuration.
1つのケースの要素が作成されると、他のすべてのケースのすべての要素が暗黙的に削除されます。 デバイスは制約の適用を処理し、構成に非互換性が存在しないようにします。
The choice and case nodes appear only in the schema tree, not in the data tree or NETCONF messages. The additional levels of hierarchy are not needed beyond the conceptual schema.
選択ノードとケースノードはスキーマツリーにのみ表示され、データツリーやNETCONFメッセージには表示されません。 概念的なスキーマを超えて、階層の追加レベルは必要ありません。
Bjorklund Standards Track [Page 21]
RFC 6020 YANG October 2010
YANG Example:
container food {
choice snack {
case sports-arena {
leaf pretzel {
type empty;
}
leaf beer {
type empty;
}
}
case late-night {
leaf chocolate {
type enumeration {
enum dark;
enum milk;
enum first-available;
}
}
}
}
}
NETCONF XML Example:
<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) or an external module. This is useful for example for vendors to add vendor- specific parameters to standard data models in an interoperable way.
YANGを使用すると、モジュールは、現在のモジュール（およびそのサブモジュール）と外部モジュールの両方を含む追加のノードをデータモデルに挿入できます。 これは、ベンダーが相互運用可能な方法でベンダー固有のパラメーターを標準データモデルに追加する場合などに役立ちます。
The "augment" statement defines the location in the data model hierarchy where new nodes are inserted, and the "when" statement defines the conditions when the new nodes are valid.
「augment」ステートメントは、新しいノードが挿入されるデータモデル階層内の場所を定義し、「when」ステートメントは、新しいノードが有効なときの条件を定義します。
Bjorklund Standards Track [Page 22]
RFC 6020 YANG October 2010
YANG Example:
augment /system/login/user {
when "class != 'wheel'";
leaf uid {
type uint16 {
range "1000 .. 30000";
}
}
}
This example defines a "uid" node that only is valid when the user's
"class" is not "wheel".
この例では、ユーザーの「クラス」が「ホイール」ではない場合にのみ有効な「uid」ノードを定義しています。
If a module augments another module, the XML representation of the data will reflect the prefix of the augmenting module. For example, if the above augmentation were in a module with prefix "other", the XML would look like:
モジュールが別のモジュールを拡張する場合、データのXML表現は拡張モジュールの接頭辞を反映します。 たとえば、上記の拡張が「other」という接頭辞を持つモジュール内にある場合、XMLは次のようになります。
NETCONF XML 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.15.
「拡張」ステートメントについては、セクション7.15で説明しています。
4.2.9. RPC Definitions
4.2.9。 RPC定義
YANG allows the definition of NETCONF RPCs. The operations' names, input parameters, and output parameters are modeled using YANG data definition statements.
YANGはNETCONF RPCの定義を許可します。 操作の名前、入力パラメーター、および出力パラメーターは、YANGデータ定義ステートメントを使用してモデル化されます。
Bjorklund Standards Track [Page 23]
RFC 6020 YANG October 2010
YANG Example:
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}
NETCONF XML Example:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://acme.example.com/system">
<image-name>acmefw-2.3</image-name>
</activate-software-image>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://acme.example.com/system">
The image acmefw-2.3 is being installed.
</status>
</rpc-reply>
The "rpc" statement is covered in Section 7.13.
「rpc」ステートメントについては、セクション7.13で説明しています。
4.2.10. Notification Definitions
4.2.10。 通知の定義
YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the content of the notification.
YANGでは、NETCONFに適した通知を定義できます。 YANGデータ定義ステートメントは、通知の内容をモデル化するために使用されます。
Bjorklund Standards Track [Page 24]
RFC 6020 YANG October 2010
YANG Example:
notification link-failure {
description "A link failure has been detected";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf if-admin-status {
type admin-status;
}
leaf if-oper-status {
type oper-status;
}
}
NETCONF XML Example:
<notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system">
<if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status>
</link-failure>
</notification>
The "notification" statement is covered in Section 7.14.
「通知」ステートメントについては、セクション7.14で説明しています。
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 define a complete, cohesive model, or 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つのモジュールにのみ属することができます。
The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name.
すべての標準モジュールとサブモジュールの名前は一意である必要があります。 エンタープライズモジュールの開発者は、標準または他のエンタープライズモジュールと競合する可能性が低いモジュールの名前を選択することをお勧めします。たとえば、モジュール名のプレフィックスとしてエンタープライズ名または組織名を使用します。
Bjorklund Standards Track [Page 25] RFC 6020 YANG October 2010 A module uses the "include" statement to include its submodules, and the "import" statement to reference external modules. Similarly, a submodule uses the "import" statement to reference other modules, and uses the "include" statement to reference other submodules within its module. A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module.
モジュールは「include」ステートメントを使用してそのサブモジュールを含め、「import」ステートメントを使用して外部モジュールを参照します。 同様に、サブモジュールは「import」ステートメントを使用して他のモジュールを参照し、「include」ステートメントを使用してモジュール内の他のサブモジュールを参照します。 モジュールまたはサブモジュールに他のモジュールのサブモジュールを含めてはならず（MUST NOT）、サブモジュールは独自のモジュールをインポートしてはなりません（MUST NOT）。
The import and include statements are used to make definitions available to other modules and submodules:
importおよびincludeステートメントは、定義を他のモジュールおよびサブモジュールで使用できるようにするために使用されます。
o For a module or submodule to reference definitions in an external
module, the external module MUST be imported.
モジュールまたはサブモジュールが外部モジュールの定義を参照するには、外部モジュールをインポートする必要があります。
o For a module to reference definitions in one of its submodules,
the module MUST include the submodule.
モジュールがサブモジュールの1つで定義を参照するには、モジュールにサブモジュールを含める必要があります。
o For a submodule to reference definitions in a second submodule of
the same module, the first submodule MUST include the second
submodule.
サブモジュールが同じモジュールの2番目のサブモジュールの定義を参照するには、最初のサブモジュールに2番目のサブモジュールを含める必要があります。
There MUST NOT be any circular chains of imports or includes. For example, if submodule "a" includes submodule "b", "b" cannot include "a".
インポートまたはインクルードの循環チェーンがあってはなりません。 たとえば、サブモジュール「a」にサブモジュール「b」が含まれている場合、「b」に「a」を含めることはできません。
When a definition in an external module is referenced, a locally defined prefix MUST be used, followed by ":", and then the external identifier. References to definitions in the local module MAY use the prefix notation. Since built-in data types do not belong to any module and have no prefix, references to built-in data types (e.g., int32) cannot use the prefix notation.
外部モジュールの定義が参照される場合、ローカルで定義された接頭辞を使用しなければならず、その後に「：」が続き、その後に外部識別子が続きます。 ローカルモジュールの定義への参照では、プレフィックス表記を使用できます。 組み込みデータ型はどのモジュールにも属しておらず、プレフィックスもないため、組み込みデータ型（int32など）への参照ではプレフィックス表記を使用できません。
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 need to be imported using specific revisions. When a module is written, it uses the current revisions of other modules, based on what is available at the time. As future revisions of the imported modules are published, the importing module is unaffected and its contents are unchanged. When the author of the module is prepared to move to the most recently published revision of an imported module, the module is republished with an updated "import" statement. By republishing with the new revision, the authors explicitly indicate their acceptance of any changes in the imported module.
公開されたモジュールは、時間の経過とともに独立して進化します。 この進化を可能にするために、特定のリビジョンを使用してモジュールをインポートする必要があります。 モジュールが作成されると、その時点で利用可能なものに基づいて、他のモジュールの現在のリビジョンが使用されます。 インポートされたモジュールの将来のリビジョンが公開されるため、インポートするモジュールは影響を受けず、その内容は変更されません。 モジュールの作成者が、インポートされたモジュールの最新の発行済みリビジョンに移動する準備ができると、モジュールは更新された「インポート」ステートメントで再発行されます。 新しいリビジョンで再発行することにより、作成者は、インポートされたモジュールの変更の受け入れを明示的に示します。
Bjorklund Standards Track [Page 26] RFC 6020 YANG October 2010 For submodules, the issue is related but simpler. A module or submodule that includes submodules needs to specify the revision of the included submodules. If a submodule changes, any module or submodule that includes it needs to be updated.
サブモジュールの場合、問題は関連していますがより単純です。 サブモジュールを含むモジュールまたはサブモジュールは、含まれるサブモジュールのリビジョンを指定する必要があります。 サブモジュールが変更された場合、それを含むすべてのモジュールまたはサブモジュールを更新する必要があります。
For example, module "b" imports module "a".
たとえば、モジュール「b」はモジュール「a」をインポートします。
module a {
revision 2008-01-01 { ... }
grouping a {
leaf eh { .... }
}
}
module b {
import a {
prefix p;
revision-date 2008-01-01;
}
container bee {
uses p:a;
}
}
When the author of "a" publishes a new revision, the changes may not
be acceptable to the author of "b". If the new revision is
acceptable, the author of "b" can republish with an updated revision
in the "import" statement.
「a」の作成者が新しいリビジョンを公開すると、「b」の作成者は変更を受け入れられない場合があります。 新しいリビジョンが受け入れられる場合、「b」の作成者は「import」ステートメントの更新されたリビジョンで再発行できます。
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. Models that have multiple top- level nodes are sometimes convenient, and are supported by YANG.
YANGを使用すると、データに複数の最上位ノードが存在する可能性がある複数の階層のデータをモデル化できます。 複数の最上位ノードを持つモデルは便利な場合があり、YANGでサポートされています。
NETCONF is capable of carrying any XML content as the payload in the <config> and <data> elements. The top-level nodes of YANG modules are encoded as child elements, in any order, within these elements. This encapsulation guarantees that the corresponding NETCONF messages are always well-formed XML documents.
NETCONFは、任意のXMLコンテンツを<config>および<data>要素のペイロードとして運ぶことができます。 YANGモジュールの最上位ノードは、これらの要素内の子要素として、任意の順序でエンコードされます。 このカプセル化により、対応するNETCONFメッセージが常に整形式のXMLドキュメントであることが保証されます。
Bjorklund Standards Track [Page 27]
RFC 6020 YANG October 2010
For example:
module my-config {
namespace "http://example.com/schema/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="http://example.com/schema/config">
<!-- system data here -->
</system>
<routing xmlns="http://example.com/schema/config">
<!-- routing data here -->
</routing>
</config>
</edit-config>
</rpc>
5.2. File Layout
5.2。 ファイルのレイアウト
YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form:
YANGモジュールとサブモジュールは、通常、ファイルに保存されます。ファイルごとに1つのモジュールまたはサブモジュールです。 ファイルの名前は次の形式にする必要があります。
module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
YANG compilers can find imported modules and included submodules via
this convention. While the YANG language defines modules, tools may
compile submodules independently for performance and manageability
reasons. Errors and warnings that cannot be detected during
submodule compilation may be delayed until the submodules are linked
into a cohesive module.
YANGコンパイラーは、この規則を使用して、インポートされたモジュールと含まれているサブモジュールを見つけることができます。 YANG言語はモジュールを定義しますが、ツールはパフォーマンスと管理性の理由からサブモジュールを個別にコンパイルする場合があります。 サブモジュールのコンパイル中に検出できないエラーと警告は、サブモジュールがまとまりのあるモジュールにリンクされるまで遅延する場合があります。
Bjorklund Standards Track [Page 28] RFC 6020 YANG October 2010 5.3. XML Namespaces
5.3。 XML名前空間
All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES], which is a globally unique URI [RFC3986]. A NETCONF client or server uses the namespace during XML encoding of data.
すべてのYANG定義は、グローバルに一意のURI [RFC3986]である特定のXML名前空間[XML-NAMES]にバインドされたモジュール内で指定されます。 NETCONFクライアントまたはサーバーは、データのXMLエンコーディング中にネームスペースを使用します。
Namespaces for modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているモジュールの名前空間は、IANAによって割り当てられる必要があります。セクション14を参照してください。
Namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces, for example by using the enterprise or organization name in the namespace.
プライベートモジュールの名前空間は、中央レジストリのないモジュールを所有する組織によって割り当てられます。 名前空間URIは、たとえば名前空間でエンタープライズ名または組織名を使用することによって、標準または他のエンタープライズ名前空間と衝突しないように選択する必要があります。
The "namespace" statement is covered in Section 7.1.3.
「名前空間」ステートメントについては、セクション7.1.3で説明しています。
5.3.1. YANG XML Namespace
5.3.1。 YANG XML名前空間
YANG defines an XML namespace for NETCONF <edit-config> operations and <error-info> content. The name of this namespace is "urn:ietf:params:xml:ns:yang:1".
YANGは、NETCONF <edit-config>操作と<error-info>コンテンツのXML名前空間を定義します。 この名前空間の名前は「urn：ietf：params：xml：ns：yang：1」です。
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 worry over conflicts if both modules define the type, since there is no ambiguity.
たとえば、モジュールがタイプを参照するグループを定義している場合、そのグループが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 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ステートメントの下にネストされて表示される場合があり、それらが表示される階層によってレキシカルにスコープを設定できるようにします。 これにより、タイプとグループを階層の最上位に配置するのではなく、使用される場所の近くに定義できます。 近接することで読みやすさが向上します。
Bjorklund Standards Track [Page 29] RFC 6020 YANG October 2010 Scoping also allows types to be defined without concern for naming conflicts between types in different submodules. Type names can be specified without adding leading strings designed to prevent name collisions within large modules.
スコープ設定により、異なるサブモジュール内のタイプ間の名前の競合を心配せずにタイプを定義することもできます。 大きなモジュール内での名前の衝突を防ぐように設計された先行文字列を追加せずに、タイプ名を指定できます。
Finally, scoping allows the module author to keep types and groupings private to their module or submodule, preventing their reuse. Since only top-level types and groupings (i.e., those appearing as substatements to a module or submodule statement) can be used outside the module or submodule, the developer has more control over what pieces of their module are presented to the outside world, supporting the need to hide internal information and maintaining a boundary between what is shared with the outside world and what is kept private.
最後に、スコーピングにより、モジュールの作成者はタイプやグループをモジュールまたはサブモジュールに対してプライベートに保ち、再利用を防ぐことができます。 最上位のタイプとグループ（つまり、モジュールまたはサブモジュールステートメントのサブステートメントとして表示されるもの）のみがモジュールまたはサブモジュールの外部で使用できるため、開発者はモジュールのどの部分を外部に提示するかをより詳細に制御でき、 内部情報を隠し、外部と共有されるものと非公開にされるものの間の境界を維持する必要性。
Scoped definitions MUST NOT shadow definitions at a higher scope. A type or grouping cannot be defined if a higher level in the schema hierarchy has a definition with a matching identifier.
スコープ定義は、より高いスコープで定義をシャドウすることはできません。 スキーマ階層の上位レベルに一致する識別子を持つ定義がある場合、タイプまたはグループを定義できません。
A reference to an unprefixed type or grouping, or one which uses the prefix of the current module, is resolved by locating the closest matching "typedef" or "grouping" statement among the immediate substatements of each ancestor statement.
接頭辞のない型またはグループ化、または現在のモジュールの接頭辞を使用するものへの参照は、各祖先ステートメントの直接のサブステートメントの中で最も一致する「typedef」または「グループ化」ステートメントを見つけることによって解決されます。
5.6. Conformance
5.6。 適合
Conformance is a measure of how accurately a device follows the model. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. Deviations from the model can reduce the utility of the model and increase fragility of applications that use it.
適合性とは、デバイスがモデルにどれだけ正確に従うかを示す尺度です。 一般的に言って、デバイスはモデルを忠実に実装する責任があり、アプリケーションはモデルを同じように実装するデバイスを扱うことができます。 モデルからの逸脱は、モデルの有用性を減らし、それを使用するアプリケーションの脆弱性を増加させる可能性があります。
YANG modelers have three mechanisms for conformance:
YANGモデラーには、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.
これらのそれぞれを順番に検討します。
Bjorklund Standards Track [Page 30] RFC 6020 YANG October 2010 5.6.1. Basic Behavior
5.6.1。 基本的な行動
The model defines a contract between the NETCONF client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract.
モデルはNETCONFクライアントとサーバー間のコントラクトを定義します。これにより、両方の当事者が、モデル化されたデータの背後にある構文とセマンティクスを相手が知っていることを確信できます。 YANGの強みは、この契約の強さにあります。
5.6.2. Optional Features
5.6.2。 オプション機能
In many models, the modeler will allow sections of the model to be conditional. The device controls whether these conditional portions of the model are supported or valid for that particular device.
多くのモデルでは、モデラーはモデルのセクションを条件付きにすることができます。 デバイスは、モデルのこれらの条件付き部分がサポートされているか、その特定のデバイスに対して有効であるかを制御します。
For example, a syslog data model may choose to include the ability to save logs locally, but the modeler will realize that this is only possible if the device has local storage. If there is no local storage, an application should not tell the device to save logs.
たとえば、syslogデータモデルはログをローカルに保存する機能を含めることを選択できますが、モデラーはこれがデバイスにローカルストレージがある場合にのみ可能であることを理解します。 ローカルストレージがない場合、アプリケーションはデバイスにログを保存するように指示するべきではありません。
YANG supports this conditional mechanism using a construct called "feature". Features give the modeler a mechanism for making portions of the module conditional in a manner that is controlled by the device. The model can express constructs that are not universally present in all devices. These features are included in the model definition, allowing a consistent view and allowing applications to learn which features are supported and tailor their behavior to the device.
YANGは、「機能」と呼ばれる構造を使用して、この条件付きメカニズムをサポートしています。 機能は、モデラーに、モジュールによって制御される方法でモジュールの一部を条件付きにするメカニズムを提供します。 モデルは、すべてのデバイスに普遍的に存在するわけではない構造を表現できます。 これらの機能はモデル定義に含まれているため、一貫性のあるビューが可能になり、アプリケーションはサポートされている機能を学習して、デバイスに合わせて動作を調整できます。
A module may declare any number of features, identified by simple strings, and may make portions of the module optional based on those features. If the device supports a feature, then the corresponding portions of the module are valid for that device. If the device doesn't support the feature, those parts of the module are not valid, and applications should behave accordingly.
モジュールは、単純な文字列で識別される任意の数の機能を宣言し、それらの機能に基づいてモジュールの一部をオプションにすることができます。 デバイスが機能をサポートしている場合、モジュールの対応する部分はそのデバイスに対して有効です。 デバイスが機能をサポートしていない場合、モジュールのそれらの部分は無効であり、アプリケーションはそれに応じて動作するはずです。
Features are defined using the "feature" statement. Definitions in the module that are conditional to the feature are noted by the "if-feature" statement with the name of the feature as its argument.
機能は「feature」ステートメントを使用して定義されます。 機能を条件とするモジュール内の定義は、引数として機能の名前を指定した「if-feature」ステートメントで示されます。
Further details are available in Section 7.18.1.
詳細については、7.18.1項を参照してください。
5.6.3. Deviations
5.6.3。 偏差
In an ideal world, all devices would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, devices are often not able or designed to implement the model as written. For YANG-based Bjorklund Standards Track [Page 31] RFC 6020 YANG October 2010 automation to deal with these device deviations, a mechanism must exist for devices to inform applications of the specifics of such deviations.
理想的な世界では、すべてのデバイスが定義どおりにモデルを実装する必要があり、モデルからの逸脱は許可されません。 しかし、現実の世界では、デバイスは多くの場合、記述されているモデルを実装することができないか、設計されていません。 YANGベースの自動化がこれらのデバイスの逸脱に対処するには、デバイスがそのような逸脱の詳細をアプリケーションに通知するためのメカニズムが必要です。
For example, a BGP module may allow any number of BGP peers, but a particular device may only support 16 BGP peers. Any application configuring the 17th peer will receive an error. While an error may suffice to let the application know it cannot add another peer, it would be far better if the application had prior knowledge of this limitation and could prevent the user from starting down the path that could not succeed.
たとえば、BGPモジュールは任意の数のBGPピアを許可しますが、特定のデバイスは16のBGPピアしかサポートしません。 17番目のピアを構成するアプリケーションはエラーを受け取ります。 エラーでアプリケーションに別のピアを追加できないことを通知するのに十分な場合がありますが、アプリケーションにこの制限に関する事前の知識があり、ユーザーが成功しなかったパスを開始できない場合は、はるかに良いでしょう。
Device deviations are declared using the "deviation" statement, which takes as its argument a string that identifies a node in the schema tree. The contents of the statement details the manner in which the device implementation deviates from the contract as defined in the module.
デバイスの偏差は、「偏差」ステートメントを使用して宣言されます。このステートメントは、スキーマツリー内のノードを識別する文字列を引数として受け取ります。 ステートメントの内容は、モジュールで定義されているように、デバイス実装がコントラクトから逸脱する方法を詳しく説明しています。
Further details are available in Section 7.18.3.
詳細については、7.18.3項を参照してください。
5.6.4. Announcing Conformance Information in the <hello> Message
5.6.4。 <hello>メッセージでの適合性情報の発表
The namespace URI MUST be advertised as a capability in the NETCONF <hello> message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form:
名前空間URIは、NETCONF <hello>メッセージの機能として通知され、NETCONFサーバーによるYANGモジュールのサポートを示す必要があります。 アドバタイズされる機能URIは、次の形式である必要があります。
capability-string = namespace-uri [ parameter-list ]
parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter /
module-parameter /
feature-parameter /
deviation-parameter
revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-date" is the revision of the module (see
Section 7.1.9) that the NETCONF server implements, "module-name" is
the name of module as it appears in the "module" statement (see
Section 7.1), "namespace-uri" is the namespace URI for the module as
it appears in the "namespace" statement (see Section 7.1.3),
"feature" is the name of an optional feature implemented by the
device (see Section 7.18.1), and "deviation" is the name of a module
defining device deviations (see Section 7.18.3).
「revision-date」は、NETCONFサーバーが実装するモジュールのリビジョン（セクション7.1.9を参照）です。「module-name」は、「module」ステートメント（セクション7.1を参照）に表示されるモジュールの名前です。 「namespace-uri」は、「namespace」ステートメントに表示されるモジュールの名前空間URIです（セクション7.1.3を参照）。「feature」は、デバイスによって実装されるオプション機能の名前です（セクション7.18.1を参照）。 、および「偏差」は、デバイス偏差を定義するモジュールの名前です（第7.18.3項を参照）。
In the parameter list, each named parameter MUST occur at most once.
パラメータリストでは、名前付きの各パラメータが1回だけ出現する必要があります。
Bjorklund Standards Track [Page 32] RFC 6020 YANG October 2010 5.6.4.1. Modules
5.6.4.1。 モジュール
Servers indicate the names of supported modules via the <hello> message. Module namespaces are encoded as the base URI in the capability string, and the module name is encoded as the "module" parameter to the base URI.
サーバーは、<hello>メッセージを介してサポートされるモジュールの名前を示します。 モジュールの名前空間は機能文字列のベースURIとしてエンコードされ、モジュール名はベースURIの「モジュール」パラメーターとしてエンコードされます。
A server MUST advertise all revisions of all modules it implements.
サーバーは、実装するすべてのモジュールのすべてのリビジョンを通知する必要があります。
For example, this <hello> message advertises one module "syslog".
たとえば、この<hello>メッセージは1つのモジュール「syslog」を通知します。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&revision=2008-04-01
</capability>
</hello>
5.6.4.2. Features
5.6.4.2。 特徴
Servers indicate the names of supported features via the <hello> message. In <hello> messages, the features are encoded in the "features" parameter within the URI. The value of this parameter is a comma-separated list of feature names that the device supports for the specific module.
サーバーは、<hello>メッセージを介して、サポートされている機能の名前を示します。 <hello>メッセージでは、機能はURI内の「features」パラメーターにエンコードされます。 このパラメーターの値は、デバイスが特定のモジュールに対してサポートする機能名のコンマ区切りリストです。
For example, this <hello> message advertises one module, informing the client that it supports the "local-storage" feature of module "syslog".
たとえば、この<hello>メッセージは1つのモジュールをアドバタイズし、モジュール「syslog」の「local-storage」機能をサポートすることをクライアントに通知します。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&features=local-storage
</capability>
</hello>
5.6.4.3. Deviations
5.6.4.3。 偏差
Device deviations are announced via the "deviations" parameter. The value of the "deviations" parameter is a comma-separated list of modules containing deviations from the capability's module.
デバイスの偏差は、「偏差」パラメータを介して通知されます。 「偏差」パラメーターの値は、機能のモジュールからの偏差を含むモジュールのコンマ区切りリストです。
For example, this <hello> message advertises two modules, informing the client that it deviates from module "syslog" according to the deviations listed in the module "my-devs".
たとえば、この<hello>メッセージは2つのモジュールをアドバタイズし、モジュール「my-devs」にリストされている逸脱に従って、モジュール「syslog」から逸脱していることをクライアントに通知します。
Bjorklund Standards Track [Page 33]
RFC 6020 YANG October 2010
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability>
http://example.com/syslog?module=syslog&deviations=my-devs
</capability>
<capability>
http://example.com/my-deviations?module=my-devs
</capability>
</hello>
5.7. Data Store Modification
5.7。 データストアの変更
Data models may allow the server to alter the configuration data store in ways not explicitly directed via NETCONF protocol messages. For example, a data model may define leafs that are assigned system- generated values when the client does not provide one. A formal mechanism for specifying the circumstances where these changes are allowed is out of scope for this specification.
データモデルにより、サーバーは、NETCONFプロトコルメッセージを介して明示的に指示されない方法で構成データストアを変更できます。 たとえば、データモデルは、クライアントが提供しない場合にシステム生成値が割り当てられるリーフを定義できます。 これらの変更が許可される状況を指定するための正式なメカニズムは、この仕様の範囲外です。
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構文を紹介します。
YANG modules use the UTF-8 [RFC3629] character encoding.
YANGモジュールはUTF-8 [RFC3629]文字エンコーディングを使用します。
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 is enclosed within "/*" and "*/".
コメントはC ++スタイルです。 単一行のコメントは「//」で始まり、行の終わりで終わります。 ブロックコメントは、「/ *」と「* /」で囲まれています。
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
Bjorklund Standards Track [Page 34]
RFC 6020 YANG October 2010
prefix identifier, followed by ":", followed by a language extension
keyword. Keywords are case sensitive. See Section 6.2 for a formal
definition of identifiers.
YANGのトークンは、キーワード、文字列、セミコロン（ ";"）、または中括弧（ "{"または "}"）のいずれかです。 文字列は引用符で囲んだり、引用符で囲んだりできます。 キーワードは、このドキュメントで定義されているYANGキーワードのいずれか、または接頭辞識別子の後に「：」が続き、その後に言語拡張キーワードが続きます。 キーワードでは大文字と小文字が区別されます。 識別子の正式な定義については、セクション6.2を参照してください。
6.1.3. Quoting
6.1.3。 引用
If a string contains any space or tab characters, a semicolon (";"),
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
it MUST be enclosed within double or single quotes.
文字列にスペースまたはタブ文字、セミコロン（ ";"）、中括弧（ "{"または "}"）、またはコメントシーケンス（ "//"、 "/ *"、または "* /"）が含まれている場合、 次に、二重引用符または単一引用符で囲む必要があります。
If the double-quoted string contains a line break followed by space or tab characters that are used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. In this process, a tab character is treated as 8 space characters.
二重引用符で囲まれた文字列に、YANGファイルのレイアウトに従ってテキストをインデントするために使用されるスペースまたはタブ文字が続く改行が含まれている場合、この先頭の空白は、文字列から二重の列まで削除されます 引用文字、または最初の空白文字以外の最初の文字。 このプロセスでは、タブ文字は8つのスペース文字として扱われます。
If the double-quoted string contains space or tab characters before a line break, this trailing whitespace is stripped from the string.
二重引用符で囲まれた文字列に改行の前にスペースまたはタブ文字が含まれている場合、この末尾の空白は文字列から削除されます。
A single-quoted string (enclosed within ' ') preserves each character within the quotes. A single quote character cannot occur in a single-quoted string, even when preceded by a backslash.
単一引用符で囲まれた文字列（ ''で囲まれている）は、引用符内の各文字を保持します。 単一引用符文字は、バックスラッシュが前に付いている場合でも、単一引用符付き文字列では使用できません。
Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash:
二重引用符で囲まれた文字列（ ""で囲まれている）内では、円記号によって特殊文字が導入されます。これは、円記号の直後の文字に依存します。
\n new line
\t a tab character
\" a double quote
\\ a single backslash
If a quoted string is followed by a plus character ("+"), followed by
another quoted string, the two strings are concatenated into one
string, allowing multiple concatenations to build one string.
Whitespace trimming and substitution of backslash-escaped characters
in double-quoted strings is done before concatenation.
引用符付き文字列の後にプラス文字（ "+"）が続き、さらに別の引用符付き文字列が続く場合、2つの文字列は1つの文字列に連結され、複数の連結で1つの文字列を作成できます。 空白のトリミングと、二重引用符で囲まれた文字列内のバックスラッシュエスケープ文字の置換は、連結の前に行われます。
6.1.3.1. Quoting Examples
6.1.3.1。 引用例
The following strings are equivalent:
次の文字列は同等です。
hello
"hello"
'hello'
"hel" + "lo"
'hel' + "lo"
Bjorklund Standards Track [Page 35]
RFC 6020 YANG October 2010
The following examples show some special strings:
次の例は、いくつかの特別な文字列を示しています。
"\"" - string containing a double quote
'"' - string containing a double quote
"\n" - string containing a new line character
'\n' - string containing a backslash followed
by the character n
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. Identifiers are case sensitive. The identifier syntax is formally defined by the rule "identifier" in Section 12. Identifiers can be specified as quoted or unquoted strings.
識別子は、さまざまな種類のYANGアイテムを名前で識別するために使用されます。 各識別子は、大文字または小文字のASCII文字またはアンダースコア文字で始まり、0個以上のASCII文字、数字、アンダースコア文字、ハイフン、ドットが続きます。 実装では、最大64文字の識別子をサポートする必要があります。 識別子は大文字と小文字が区別されます。 識別子の構文は、セクション12のルール「識別子」によって正式に定義されています。 識別子は、引用符付きまたは引用符なしの文字列として指定できます。
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識別子の名前空間を共有します。
Bjorklund Standards Track [Page 36]
RFC 6020 YANG October 2010
o All derived type names defined within a parent node or at the top
level of the module or its submodules share the same type
identifier namespace. This namespace is scoped to all descendant
nodes of the parent node or module. This means that any
descendent node may use that typedef, and it MUST NOT define a
typedef with the same name.
親ノード内、またはモジュールのトップレベルで定義されたすべての派生型名またはそのサブモジュールは、同じ型識別子の名前空間を共有します。 この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。 これは、すべての子孫ノードがそのtypedefを使用する可能性があり、同じ名前でtypedefを定義してはならないことを意味します。
o All grouping names defined within a parent node or at the top
level of the module or its submodules share the same grouping
identifier namespace. This namespace is scoped to all descendant
nodes of the parent node or module. This means that any
descendent node may use that grouping, and it MUST NOT define a
grouping with the same name.
親ノード内、またはモジュールまたはそのサブモジュールの最上位で定義されているすべてのグループ化名は、同じグループ化識別子名前空間を共有します。 この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。 これは、すべての子孫ノードがそのグループを使用できることを意味し、同じ名前のグループを定義してはなりません（MUST NOT）。
o All leafs, leaf-lists, lists, containers, choices, rpcs,
notifications, and anyxmls defined (directly or through a uses
statement) within a parent node or at the top level of the module
or its submodules share the same identifier namespace. This
namespace is scoped to the parent node or module, unless the
parent node is a case node. In that case, the namespace is scoped
to the closest ancestor node that is not a case or choice node.
親ノード内、またはモジュールの最上位レベルで定義されたすべてのリーフ、リーフリスト、リスト、コンテナー、選択肢、rpcs、通知、および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
either by a semicolon (";") or a block of substatements enclosed
within braces ("{ }"):
YANGモジュールには、一連のステートメントが含まれています。 各ステートメントはキーワードで始まり、その後にゼロまたは1つの引数が続き、その後にセミコロン（ ";"）または中括弧（ "{}"）で囲まれたサブステートメントのブロックが続きます。
statement = keyword [argument] (";" / "{" *statement "}")
The argument is a string, as defined in Section 6.1.2.
引数は、6.1.2項で定義されている文字列です。
6.3.1. Language Extensions
6.3.1。 言語拡張
A module can introduce YANG extensions by using the "extension" keyword (see Section 7.17). The extensions can be imported by other modules with the "import" statement (see Section 7.1.5). When an imported extension is used, the extension's keyword MUST be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MUST be qualified with the module's prefix.
モジュールは "extension"キーワードを使用してYANG拡張を導入できます（セクション7.17を参照）。 拡張機能は、 "import"ステートメントを使用して他のモジュールによってインポートできます（セクション7.1.5を参照）。 インポートされた拡張機能が使用される場合、拡張機能のモジュールがインポートされたときの接頭辞を使用して、拡張機能のキーワードを修飾する必要があります。 拡張が定義されているモジュールで拡張が使用されている場合、拡張のキーワードはモジュールの接頭辞で修飾する必要があります。
Bjorklund Standards Track [Page 37] RFC 6020 YANG October 2010 Since submodules cannot include the parent module, any extensions in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the extension.
サブモジュールには親モジュールを含めることができないため、サブモジュールに公開する必要があるモジュール内の拡張機能はすべてサブモジュールで定義する必要があります。 次に、サブモジュールにこのサブモジュールを含めて、拡張機能の定義を見つけることができます。
If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler.
YANGコンパイラが特定の拡張機能をサポートしていない場合、これはYANGモジュールにunknown-statement（セクション12を参照）として表示されますが、unknown-statement全体がコンパイラによって無視される場合があります（MAY）。
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. NETCONF clients and servers are not required to implement an XPath interpreter, but MUST ensure that the requirements encoded in the data model are enforced. The manner of enforcement is an implementation decision. The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context (see Section 6.4.1). An implementation may choose to implement them by hand, rather than using the XPath expression directly.
YANGは、多くのノード間参照と依存関係を指定する表記として、XMLパス言語（XPath）1.0 [XPATH]に依存しています。 NETCONFクライアントとサーバーはXPathインタープリターを実装する必要はありませんが、データモデルにエンコードされた要件が確実に適用されるようにする必要があります。 実施の仕方は実装の決定です。 XPath式は構文的に正しい必要があり、使用されるすべての接頭辞はXPathコンテキストに存在する必要があります（セクション6.4.1を参照）。 実装では、XPath式を直接使用するのではなく、手動で実装することを選択できます。
The data model used in the XPath expressions is the same as that used in XPath 1.0 [XPATH], with the same extension for root node children as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means that the root node may have any number of element nodes as its children.
XPath式で使用されるデータモデルはXPath 1.0 [XPATH]で使用されるものと同じですが、XSLT 1.0 [XSLT]（セクション3.1）で使用されるのと同じルートノードの子の拡張が使用されます。 具体的には、ルートノードは子として任意の数の要素ノードを持つことができることを意味します。
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式が指定されているモジュール内のすべての「インポート」ステートメントの接頭辞と名前空間のペアのセット、および「名前空間」ステートメントのURIに対する「接頭辞」ステートメントの接頭辞です。
o Names without a namespace prefix belong to the same namespace as
the identifier of the current node. Inside a grouping, that
namespace is affected by where the grouping is used (see
Section 7.12).
名前空間接頭辞のない名前は、現在のノードの識別子と同じ名前空間に属しています。 グループ化の内部では、その名前空間はグループ化が使用される場所に影響されます（セクション7.12を参照）。
o The function library is the core function library defined in
[XPATH], and a function "current()" that returns a node set with
the initial context node.
関数ライブラリは、[XPATH]で定義されたコア関数ライブラリであり、初期コンテキストノードでノードセットを返す関数「current（）」です。
o The set of variable bindings is empty.
変数バインディングのセットが空です。
Bjorklund Standards Track [Page 38] RFC 6020 YANG October 2010 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 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ステートメントが定義されている場所で指定されます。
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 12, respectively. A schema node identifier consists of a
path of identifiers, separated by slashes ("/"). In an absolute
schema node identifier, the first identifier after the leading slash
is any top-level schema node in the local module or in all imported
modules.
スキーマノード識別子は、スキーマツリー内のノードを識別する文字列です。 セクション12の「absolute-schema-nodeid」と「descendant-schema-nodeid」のルールでそれぞれ定義されている「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"を使用できます。
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" {
acme: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 hold detailed module information. The module name follows the rules for identifiers in Section 6.2.
「モジュール」ステートメントは、モジュールの名前を定義し、モジュールに属するすべてのステートメントをグループ化します。 「モジュール」ステートメントの引数は、モジュールの名前であり、その後に詳細なモジュール情報を保持するサブステートメントのブロックが続きます。 モジュール名は、セクション6.2の識別子の規則に従います。
Bjorklund Standards Track [Page 39] RFC 6020 YANG October 2010 Names of modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているモジュールの名前は、IANAによって割り当てられる必要があります。セクション14を参照してください。
Private module names are assigned by the organization owning the module without a central registry. It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the module name.
プライベートモジュール名は、中央レジストリのないモジュールを所有する組織によって割り当てられます。 モジュール名の接頭辞としてエンタープライズ名または組織名を使用するなどして、標準またはその他のエンタープライズモジュールおよびサブモジュールと衝突する可能性が低いモジュール名を選択することをお勧めします。
A module typically has the following layout:
通常、モジュールのレイアウトは次のとおりです。
module <module-name> {
// header information
<yang-version statement>
<namespace statement>
<prefix statement>
// linkage statements
<import statements>
<include statements>
// meta information
<organization statement>
<contact statement>
<description statement>
<reference statement>
// revision history
<revision statements>
// module definitions
<other statements>
}
Bjorklund Standards Track [Page 40]
RFC 6020 YANG October 2010
7.1.1. The module's Substatements
7.1.1。 モジュールのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| namespace | 7.1.3 | 1 |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
7.1.2. The yang-version Statement
7.1.2。 yangバージョンのステートメント
The optional "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument is a string. If present, it MUST contain the value "1", which is the current YANG version and the default value.
オプションの「yang-version」ステートメントは、モジュールの開発に使用されたYANG言語のバージョンを指定します。 ステートメントの引数は文字列です。 存在する場合は、現在のYANGバージョンとデフォルト値である値「1」を含める必要があります。
Handling of the "yang-version" statement for versions other than "1" (the version defined here) is out of scope for this specification. Any document that defines a higher version will need to define the backward compatibility of such a higher version.
「1」以外のバージョン（ここで定義されているバージョン）の「yang-version」ステートメントの処理は、この仕様の範囲外です。 より高いバージョンを定義するドキュメントは、そのようなより高いバージョンの下位互換性を定義する必要があります。
Bjorklund Standards Track [Page 41] RFC 6020 YANG October 2010 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, with the exception of data node identifiers defined inside a grouping (see Section 7.12 for details). The argument to the "namespace" statement is the URI of the namespace.
"namespace"ステートメントは、モジュール内で定義されたデータノード識別子を除いて、モジュールによって定義されたすべての識別子が修飾されるXML名前空間を定義します（詳細については、セクション7.12を参照）。 「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 to refer to definitions contained in the module, e.g., "if:ifName". A prefix follows the same rules as an identifier (see Section 6.2).
「prefix」ステートメントは、モジュールとその名前空間に関連付けられたプレフィックスを定義するために使用されます。 「prefix」ステートメントの引数は、モジュールにアクセスするためのプレフィックスとして使用されるプレフィックス文字列です。 プレフィックス文字列は、モジュールに含まれている定義を参照するために使用できます（例： "if：ifName"）。 接頭辞は識別子と同じ規則に従います（セクション6.2を参照）。
When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. To improve readability of the NETCONF XML, a NETCONF client or server that generates XML or XPath that use prefixes SHOULD use the prefix defined by the module, unless there is a conflict.
「モジュール」ステートメント内で使用される場合、「プレフィックス」ステートメントは、このモジュールがインポートされるときに使用されるプレフィックスを定義します。 NETCONF XMLの読みやすさを向上させるために、プレフィックスを使用するXMLまたはXPathを生成するNETCONFクライアントまたはサーバーは、競合がない限り、モジュールで定義されたプレフィックスを使用する必要があります（SHOULD）。
When used inside the "import" statement, the "prefix" statement
defines the prefix to be used when accessing definitions inside the
imported module. When a reference to an identifier from the imported
module is used, the prefix string for the imported module is used in
combination with a colon (":") and the identifier, e.g., "if:
ifIndex". To improve readability of YANG modules, the prefix defined
by a module SHOULD be used when the module is imported, unless there
is a conflict. If there is a conflict, i.e., two different modules
that both have defined the same prefix are imported, at least one of
them MUST be imported with a different prefix.
「インポート」ステートメント内で使用される場合、「プレフィックス」ステートメントは、インポートされたモジュール内の定義にアクセスするときに使用されるプレフィックスを定義します。 インポートされたモジュールからの識別子への参照が使用される場合、インポートされたモジュールのプレフィックス文字列は、コロン（ "："）および識別子（ "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:
「インポート」ステートメントは、あるモジュールの定義を別のモジュールまたはサブモジュール内で使用できるようにします。 引数はインポートするモジュールの名前であり、ステートメントの後には詳細なインポート情報を保持するサブステートメントのブロックが続きます。 モジュールがインポートされると、インポートモジュールは次のことを実行できます。
Bjorklund Standards Track [Page 42]
RFC 6020 YANG October 2010
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 MUST NOT be imported.
同じモジュールの複数のリビジョンをインポートしてはいけません。
The import's Substatements
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| prefix | 7.1.4 | 1 |
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
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 exact version of the module to import. The "revision-date" statement MUST match the most recent "revision" statement in the imported module.
インポートの「改訂日」ステートメントは、インポートするモジュールの正確なバージョンを指定するために使用されます。 「改訂日」ステートメントは、インポートされたモジュールの最新の「改訂」ステートメントと一致する必要があります。
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, or to another submodule of that parent module. The argument is an identifier that is the name of the submodule to include. Modules are only allowed to Bjorklund Standards Track [Page 43] RFC 6020 YANG October 2010 include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module.
「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. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule.
モジュールにサブモジュールが含まれている場合、サブモジュールのコンテンツがモジュールのノード階層に組み込まれます。 サブモジュールに別のサブモジュールが含まれている場合、ターゲットサブモジュールの定義が現在のサブモジュールで使用できるようになります。
When the optional "revision-date" substatement is present, the specified revision of the submodule is included in the module. It is an error if the specified revision of the submodule does not exist. If no "revision-date" substatement is present, it is undefined which revision of the submodule is included.
オプションの "revision-date"サブステートメントが存在する場合、指定されたサブモジュールのリビジョンがモジュールに含まれます。 サブモジュールの指定されたリビジョンが存在しない場合はエラーになります。 「改訂日」サブステートメントが存在しない場合、サブモジュールのどのリビジョンが含まれるかは未定義です。
Multiple revisions of the same submodule MUST NOT be included.
同じサブモジュールの複数のリビジョンを含めることはできません。
The includes's Substatements
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
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 initial "revision" statement. For Bjorklund Standards Track [Page 44] RFC 6020 YANG October 2010 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 Substatement
7.1.9.1。 改訂のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
7.1.10. Usage Example
7.1.10。 使用例
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
import ietf-yang-types {
prefix "yang";
}
include acme-types;
organization "ACME Inc.";
contact
"Joe L. User
ACME, Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100
EMail: joe@acme.example.com";
description
"The module for entities implementing the ACME protocol.";
revision "2007-06-09" {
description "Initial revision.";
}
// definitions follow...
}
Bjorklund Standards Track [Page 45]
RFC 6020 YANG October 2010
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 groups all statements that belong to the submodule together. The "submodule" statement's argument is the name of the submodule, followed by a block of substatements that hold detailed submodule information. The submodule name follows the rules for identifiers in Section 6.2.
「サブモジュール」ステートメントは、サブモジュールの名前を定義し、サブモジュールに属するすべてのステートメントをグループ化します。 「サブモジュール」ステートメントの引数は、サブモジュールの名前であり、その後に詳細なサブモジュール情報を保持するサブステートメントのブロックが続きます。 サブモジュール名は、セクション6.2の識別子の規則に従います。
Names of submodules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]で公開されているサブモジュールの名前は、IANAによって割り当てられる必要があります。セクション14を参照してください。
Private submodule names are assigned by the organization owning the submodule without a central registry. It is RECOMMENDED to choose submodule names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the submodule name.
プライベートサブモジュール名は、中央レジストリのないサブモジュールを所有する組織によって割り当てられます。 たとえば、エンタープライズ名または組織名をサブモジュール名の接頭辞として使用するなど、標準またはその他のエンタープライズモジュールおよびサブモジュールと衝突する可能性が低いサブモジュール名を選択することをお勧めします。
Bjorklund Standards Track [Page 46] RFC 6020 YANG October 2010 A submodule typically has the following layout:
サブモジュールは通常、次のレイアウトになっています。
submodule <module-name> {
<yang-version statement>
// module identification
<belongs-to statement>
// linkage statements
<import statements>
<include statements>
// meta information
<organization statement>
<contact statement>
<description statement>
<reference statement>
// revision history
<revision statements>
// module definitions
<other statements>
}
Bjorklund Standards Track [Page 47]
RFC 6020 YANG October 2010
7.2.1. The submodule's Substatements
7.2.1。 サブモジュールのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| belongs-to | 7.2.2 | 1 |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
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 the module to which it belongs, or by another submodule that belongs to that module.
サブモジュールは、それが属するモジュール、またはそのモジュールに属する別のサブモジュールによってのみ含まれる必要があります。
The mandatory "prefix" substatement assigns a prefix for the module to which the submodule belongs. All definitions in the local submodule and any included submodules can be accessed by using the prefix.
必須の「プレフィックス」サブステートメントは、サブモジュールが属するモジュールのプレフィックスを割り当てます。 ローカルサブモジュールおよび含まれているサブモジュールのすべての定義には、プレフィックスを使用してアクセスできます。
Bjorklund Standards Track [Page 48]
RFC 6020 YANG October 2010
The belongs-to's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| prefix | 7.1.4 | 1 |
+--------------+---------+-------------+
7.2.3. Usage Example
7.2.3。 使用例
submodule acme-types {
belongs-to "acme-system" {
prefix "acme";
}
import ietf-yang-types {
prefix "yang";
}
organization "ACME Inc.";
contact
"Joe L. User
ACME, Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100
EMail: joe@acme.example.com";
description
"This submodule defines common ACME types.";
revision "2007-06-09" {
description "Initial revision.";
}
// definitions follows...
}
7.3. The typedef Statement
7.3。 typedefステートメント
The "typedef" statement defines a new type that may be used locally in the module, in modules or submodules which include it, and by other modules that import from it, according to the rules in Bjorklund Standards Track [Page 49] RFC 6020 YANG October 2010 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.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.3.2 | 1 |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
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。 unitsステートメント
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」ステートメントは、型に関連付けられた単位のテキストによる定義を含む文字列を引数として受け取ります。
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.
基本タイプにデフォルト値があり、新しい派生タイプが新しいデフォルト値を指定していない場合、基本タイプのデフォルト値は新しい派生タイプのデフォルト値でもあります。
Bjorklund Standards Track [Page 50] RFC 6020 YANG October 2010 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 are 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のサブセクションで説明しています。
7.4.1. The type's Substatements
7.4.1。 タイプのサブステートメント
+------------------+---------+-------------+
| substatement | section | cardinality |
+------------------+---------+-------------+
| bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n |
| length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 |
| pattern | 9.4.6 | 0..n |
| range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 |
| type | 7.4 | 0..n |
+------------------+---------+-------------+
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.
コンテナノードには値はありませんが、データツリー内に子ノードのリストがあります。 子ノードは、コンテナのサブステートメントで定義されます。
Bjorklund Standards Track [Page 51] RFC 6020 YANG October 2010 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 configuration has an explicit meaning.
YANGは2つのスタイルのコンテナーをサポートします。データノードの階層を編成するためにのみ存在するものと、構成内に存在することが明確な意味を持つものです。
In the first style, the container has no meaning of its own, existing only to contain child nodes. This is the default style.
最初のスタイルでは、コンテナはそれ自体には意味がなく、子ノードを含むためだけに存在します。 これがデフォルトのスタイルです。
For example, the set of scrambling options for Synchronous Optical Network (SONET) interfaces may be placed inside a "scrambling" container to enhance the organization of the configuration hierarchy, and to keep these nodes together. The "scrambling" node itself has no meaning, so removing the node when it becomes empty relieves the user from performing this task.
たとえば、同期光ネットワーク（SONET）インターフェイスのスクランブルオプションのセットを「スクランブル」コンテナ内に配置して、構成階層の編成を強化し、これらのノードをまとめて維持することができます。 「スクランブル」ノード自体には意味がないため、ノードが空になったときにノードを削除しても、ユーザーはこのタスクを実行する必要がありません。
In the second style, the presence of the container itself is configuration data, representing a single bit of configuration data. The container acts as both a configuration knob and a means of organizing related configuration. These containers are explicitly created and deleted.
2番目のスタイルでは、コンテナー自体の存在は構成データであり、構成データの1ビットを表します。 コンテナーは、構成ノブと、関連する構成を編成する手段の両方として機能します。 これらのコンテナは明示的に作成および削除されます。
YANG calls this style a "presence container" and it is indicated using the "presence" statement, which takes as its argument a text string indicating what the presence of the node means.
YANGはこのスタイルを「プレゼンスコンテナ」と呼び、「プレゼンス」ステートメントを使用して示されます。これは、ノードの存在が何を意味するかを示すテキスト文字列を引数として取ります。
For example, an "ssh" container may turn on the ability to log into the device using ssh, but can also contain any ssh-related configuration knobs, such as connection rates or retry limits.
たとえば、「ssh」コンテナは、sshを使用してデバイスにログインする機能をオンにしますが、接続速度や再試行制限などのssh関連の設定ノブを含めることもできます。
The "presence" statement (see Section 7.5.5) is used to give semantics to the existence of the container in the data tree.
「存在」ステートメント（セクション7.5.5を参照）は、データツリー内のコンテナの存在に意味を与えるために使用されます。
Bjorklund Standards Track [Page 52] RFC 6020 YANG October 2010 7.5.2. The container's Substatements
7.5.2。 コンテナのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| must | 7.5.3 | 0..n |
| presence | 7.5.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
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 data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated.
データストアが検証されると、すべての「必須」制約は、データツリー内の各データノード、およびデフォルト値が使用されているすべてのリーフに対して概念的に一度評価されます（セクション7.6.1を参照）。 データノードがデータツリーに存在せず、デフォルト値がない場合、その「必須」ステートメントは評価されません。
All such constraints MUST evaluate to true for the data to be valid.
そのような制約はすべて、データが有効であるために真と評価されなければなりません（MUST）。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、セクション6.4.1の定義に加えて、次のコンテキストで概念的に評価されます。
o The context node is the node in the data tree for which the "must"
statement is defined.
コンテキストノードは、「必須」ステートメントが定義されているデータツリー内のノードです。
o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values in use (see Section 7.6.1).
アクセス可能なツリーは、データツリーのすべてのノードと、使用中のデフォルト値を持つすべてのリーフで構成されます（7.6.1項を参照）。
Bjorklund Standards Track [Page 53] RFC 6020 YANG October 2010 The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードによって異なります。
o If the context node represents configuration, the tree is the data
in the NETCONF datastore where the context node exists. The XPath
root node has all top-level configuration data nodes in all
modules as children.
コンテキストノードが構成を表す場合、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathルートノードには、すべてのモジュールのすべての最上位の構成データノードが子として含まれます。
o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children.
コンテキストノードが状態データを表す場合、ツリーはすべてデバイス上の状態データであり、<running />データストアです。 XPathルートノードには、すべてのモジュールのすべての最上位データノードが子として含まれます。
o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has
the element representing the notification being defined as the
only child.
コンテキストノードが通知コンテンツを表す場合、ツリーは通知XMLインスタンスドキュメントです。 XPathルートノードには、唯一の子として定義される通知を表す要素があります。
o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the
element representing the RPC operation being defined as the only
child.
コンテキストノードがRPC入力パラメーターを表す場合、ツリーはRPC XMLインスタンスドキュメントです。 XPathルートノードには、RPC操作を表す要素が唯一の子として定義されています。
o If the context node represents RPC output parameters, the tree is
the RPC reply instance document. The XPath root node has the
elements representing the RPC output parameters as children.
コンテキストノードがRPC出力パラメーターを表す場合、ツリーはRPC応答インスタンスドキュメントです。 XPathルートノードには、RPC出力パラメーターを子として表す要素があります。
The result of the XPath expression is converted to a boolean value using the standard XPath rules.
XPath式の結果は、標準のXPathルールを使用してブール値に変換されます。
Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Sections 7.6 and 7.7), any XPath comparisons are done on the canonical value.
データツリー内のすべてのリーフ値は概念的には標準形式で格納されるため（セクション7.6および7.7を参照）、XPathの比較は標準値で行われます。
Also note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. How the evaluation is done in practice is an implementation decision.
また、XPath式は概念的に評価されることに注意してください。 これは、実装がデバイスでXPathエバリュエーターを使用する必要がないことを意味します。 評価が実際にどのように行われるかは、実装の決定です。
Bjorklund Standards Track [Page 54] RFC 6020 YANG October 2010 7.5.4. The must's Substatements
7.5.4。 マストのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
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>.
オプションの「error-message」ステートメントは、引数として文字列を取ります。 制約がfalseと評価された場合、文字列は<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>.
「error-app-tag」ステートメントはオプションであり、ストリングを引数として取ります。 制約がfalseと評価された場合、文字列は<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 " +
"(ifType = 'ethernet' and ifMTU = 1500)" {
error-message "An ethernet MTU must be 1500";
}
must "ifType != 'atm' or " +
"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
error-message "An atm MTU must be 64 .. 17966";
}
}
Bjorklund Standards Track [Page 55]
RFC 6020 YANG October 2010
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", and "anyxml" statements can be used to define child nodes to the container.
コンテナ内では、「container」、「leaf」、「list」、「leaf-list」、「uses」、「choice」、および「anyxml」ステートメントを使用して、コンテナに子ノードを定義できます。
7.5.7. XML Mapping 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 input or output parameters, these subelements are encoded in the same order as they are defined within the "container" statement. Otherwise, the subelements are encoded in any order.
コンテナの子ノードは、コンテナ要素のサブ要素としてエンコードされます。 コンテナーがRPC入力または出力パラメーターを定義している場合、これらのサブエレメントは、「コンテナー」ステートメント内で定義されているのと同じ順序でエンコードされます。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, must be prepared to handle the case that a container node without a "presence" statement is not present in the XML.
<get>または<get-config>リクエストに応答するNETCONFサーバーは、コンテナノードに「存在」ステートメントがなく、子ノードが存在しない場合、コンテナ要素を送信しないことを選択できます。 したがって、<get>または<get-config>リクエストの<rpc-reply>を受信するクライアントは、「存在」ステートメントのないコンテナノードがXMLに存在しない場合に対処できるように準備する必要があります。
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 [RFC4741], Section 7.2) in the container's XML element.
コンテナーは、コンテナーのXML要素で「操作」属性（[RFC4741]、セクション7.2を参照）を使用して、<edit-config>で作成、削除、置換、および変更できます。
If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container.
コンテナーに「存在」ステートメントがなく、最後の子ノードが削除された場合、NETCONFサーバーはコンテナーを削除できます（MAY）。
Bjorklund Standards Track [Page 56] RFC 6020 YANG October 2010 When a NETCONF server processes an <edit-config> request, the elements of procedure for the container node are:
NETCONFサーバーが<edit-config>リクエストを処理する場合、コンテナーノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if
it does not exist.
操作が「マージ」または「置換」の場合、ノードが存在しなければ作成されます。
If the operation is "create", the node is created if it does not
exist. If the node already exists, a "data-exists" error is
returned.
操作が「作成」の場合、ノードが存在しなければ作成されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
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...
}
}
}
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>でコンテナを削除するには：
Bjorklund Standards Track [Page 57]
RFC 6020 YANG October 2010
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh nc:operation="delete"/>
</services>
</system>
</config>
</edit-config>
</rpc>
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 instances in the data tree.
リーフノードは、データツリーの0または1つのインスタンスに存在します。
The "leaf" statement is used to define a scalar variable of a particular built-in or derived type.
「リーフ」ステートメントは、特定の組み込み型または派生型のスカラー変数を定義するために使用されます。
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:
葉のデフォルト値は、葉がデータツリーに存在しない場合にサーバーが使用する値です。 デフォルト値の使用は、非存在コンテナではない、スキーマツリー内のリーフの最も近い祖先ノードによって異なります。
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 if
the case node is the choice's default case, and no nodes from any
other case exist in the data tree.
それ以外の場合、この祖先がケースノードである場合、ケースのノードがデータツリーに存在する場合、またはケースノードが選択肢のデフォルトケースであり、他のケースのノードがデータに存在しない場合は、デフォルト値を使用する必要があります。 木。
Bjorklund Standards Track [Page 58]
RFC 6020 YANG October 2010
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.
これらの場合、デフォルト値が使用中であると言われます。
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.
リーフに「デフォルト」ステートメントがある場合、リーフのデフォルト値は「デフォルト」ステートメントの値です。 それ以外の場合、リーフのタイプにデフォルト値があり、リーフが必須ではない場合、リーフのデフォルト値はタイプのデフォルト値です。 他のすべての場合、リーフにはデフォルト値がありません。
7.6.2. The leaf's Substatements
7.6.2。 葉のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
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.
「デフォルト」ステートメントの値は、リーフの「タイプ」ステートメントで指定されたタイプに従って有効でなければなりません。
Bjorklund Standards Track [Page 59] RFC 6020 YANG October 2010 The "default" statement MUST NOT be present on nodes where "mandatory" is true.
「デフォルト」ステートメントは、「必須」がtrueであるノード上に存在してはなりません（MUST NOT）。
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 Mapping 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 sent as character data in the element.
リーフノードの値は、タイプに従ってXMLにエンコードされ、要素内の文字データとして送信されます。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, MUST be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value.
<get>または<get-config>要求に応答するNETCONFサーバーは、その値がデフォルト値の場合、リーフ要素を送信しないことを選択できます（MAY）。 したがって、<get>または<get-config>要求の<rpc-reply>を受信するクライアントは、デフォルト値を持つリーフノードが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> Operations
When a NETCONF server processes an <edit-config> request, the elements of procedure for the leaf node are:
NETCONFサーバーが<edit-config>要求を処理するとき、リーフノードの手順の要素は次のとおりです。
Bjorklund Standards Track [Page 60]
RFC 6020 YANG October 2010
If the operation is "merge" or "replace", the node is created if
it does not exist, and its value is set to the value found in the
XML RPC data.
操作が「マージ」または「置換」の場合、ノードが存在しない場合はノードが作成され、その値はXML RPCデータで見つかった値に設定されます。
If the operation is "create", the node is created if it does not
exist. If the node already exists, a "data-exists" error is
returned.
操作が「作成」の場合、ノードが存在しなければ作成されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
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.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="http://example.com/schema/config">
<services>
<ssh>
<port>2022</port>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 61]
RFC 6020 YANG October 2010
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つの引数（識別子）を取り、その後に詳細なリーフリスト情報を保持するサブステートメントのブロックが続きます。
The values in a leaf-list MUST be unique.
リーフリストの値は一意である必要があります。
Conceptually, the values in the data tree are always in the canonical form (see Section 9.1).
概念的には、データツリーの値は常に正規の形式です（セクション9.1を参照）。
If the type referenced by the leaf-list has a default value, it has no effect in the leaf-list.
リーフリストが参照するタイプにデフォルト値がある場合、リーフリストには影響しません。
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 device is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order to the device implementor. YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system".
YANGは、リストおよびリーフリスト内のエントリの順序付けに2つのスタイルをサポートしています。 多くのリストでは、リストエントリの順序はリストの構成の実装に影響を与えず、デバイスはリストエントリを適切な順序で自由にソートできます。 リストの「説明」文字列は、デバイスの実装者に注文を示唆する場合があります。 YANGはこのスタイルのリストを「システム注文」と呼び、それらは「システムによる注文」というステートメントで示されます。
For example, a list of valid users would typically be sorted alphabetically, since the order in which the users appeared in the configuration would not impact the creation of those users' accounts.
たとえば、有効なユーザーのリストは通常、アルファベット順にソートされます。これは、ユーザーが構成に表示される順序は、それらのユーザーのアカウントの作成には影響しないためです。
In the other style of lists, the order of list entries matters for the implementation of the list's configuration and the user is responsible for ordering the entries, while the device maintains that order. YANG calls this style of list "user ordered" and they are indicated with the statement "ordered-by user".
他のスタイルのリストでは、リストエントリの順序はリストの構成の実装にとって重要であり、デバイスがその順序を維持しながら、ユーザーはエントリの順序付けを担当します。 YANGはこのスタイルのリストを「ユーザーによる注文」と呼び、「ユーザーによる注文」というステートメントで示されます。
For example, the order in which firewall filters entries are applied to incoming traffic may affect how that traffic is filtered. The user would need to decide if the filter entry that discards all TCP traffic should be applied before or after the filter entry that allows all traffic from trusted interfaces. The choice of order would be crucial.
たとえば、ファイアウォールフィルターのエントリが着信トラフィックに適用される順序は、そのトラフィックのフィルター方法に影響する場合があります。 ユーザーは、すべてのTCPトラフィックを破棄するフィルターエントリを、信頼できるインターフェイスからのすべてのトラフィックを許可するフィルターエントリの前または後に適用するかどうかを決定する必要があります。 順序の選択は重要です。
YANG provides a rich set of facilities within NETCONF's <edit-config> operation that allows the order of list entries in user-ordered lists to be controlled. List entries may be inserted or rearranged, positioned as the first or last entry in the list, or positioned before or after another specific entry.
YANGは、NETCONFの<edit-config>操作内に豊富な機能セットを提供し、ユーザーが指定したリスト内のリストエントリの順序を制御できるようにします。 リストエントリは、挿入または再配置したり、リストの最初または最後のエントリとして配置したり、別の特定のエントリの前または後に配置したりできます。
Bjorklund Standards Track [Page 62] RFC 6020 YANG October 2010 The "ordered-by" statement is covered in Section 7.7.5.
「ordered-by」ステートメントについては、セクション7.7.5で説明しています。
7.7.2. The leaf-list's Substatements
7.7.2。 リーフリストのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.4 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
7.7.3. The min-elements Statement
7.7.3。 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 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.7.4. The max-elements Statement
7.7.4。 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のエントリがあります。
Bjorklund Standards Track [Page 63] RFC 6020 YANG October 2010 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.5. The ordered-by Statement
7.7.5。 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, order 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.5.1. ordered-by system
7.7.5.1。 注文システム
The entries in the list are sorted according to an unspecified order. Thus, an implementation is free to sort the entries in the most appropriate order. An implementation SHOULD use the same order for the same data, regardless of how the data were created. Using a deterministic order will make comparisons possible using simple tools like "diff".
リスト内のエントリは、不特定の順序に従って並べ替えられています。 したがって、実装はエントリを最も適切な順序で自由にソートできます。 実装では、データの作成方法に関係なく、同じデータに同じ順序を使用する必要があります（SHOULD）。 確定的な順序を使用すると、「diff」などの単純なツールを使用して比較が可能になります。
This is the default order.
これがデフォルトの順序です。
7.7.5.2. ordered-by user
7.7.5.2。 注文したユーザー
The entries in the list are sorted according to an order defined by the user. This order is controlled by using special XML attributes in the <edit-config> request. See Section 7.7.7 for details.
リストのエントリは、ユーザーが定義した順序に従って並べ替えられます。 この順序は、<edit-config>リクエストで特別なXML属性を使用して制御されます。 詳細については、セクション7.7.7を参照してください。
7.7.6. XML Mapping Rules
7.7.6。 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 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 Bjorklund Standards Track [Page 64] RFC 6020 YANG October 2010 representing leaf-list entries MAY be interleaved with other sibling elements, unless the leaf-list defines RPC input or output parameters.
リーフリストが「ordered-by user」の場合、リーフリストエントリを表すXML要素は、ユーザーが指定した順序で出現する必要があります。 それ以外の場合、順序は実装に依存します。 リーフリストがRPC入力または出力パラメーターを定義しない限り、リーフリストエントリを表すXML要素は、他の兄弟要素とインターリーブされる場合があります。
See Section 7.7.8 for an example.
例については、セクション7.7.8を参照してください。
7.7.7. NETCONF <edit-config> Operations
7.7.7。 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 the time, in the order of the XML elements in the request.
「ordered-by user」リーフリストの複数のエントリが同じ<edit-config>リクエストで変更された場合、エントリはリクエストのXML要素の順序で一度に1つずつ変更されます。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire leaf-list, the leaf-list order is the same as the order of the XML elements in the request.
<copy-config>、またはリーフリスト全体を対象とする「replace」操作を含む<edit-config>では、リーフリストの順序は、リクエスト内のXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a leaf-list node are:
NETCONFサーバーが<edit-config>要求を処理するとき、リーフリストノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the leaf-list entry is
created if it does not exist.
操作が「マージ」または「置換」の場合、リーフリストエントリが存在しない場合は作成されます。
If the operation is "create", the leaf-list entry is created if it
does not exist. If the leaf-list entry already exists, a
"data-exists" error is returned.
操作が「作成」の場合、リーフリストエントリが存在しない場合は作成されます。 リーフリストエントリがすでに存在する場合、「data-exists」エラーが返されます。
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.
操作が「削除」の場合、エントリが存在する場合、そのエントリはリーフリストから削除されます。 リーフリストエントリが存在しない場合、「データ欠落」エラーが返されます。
Bjorklund Standards Track [Page 65] RFC 6020 YANG October 2010 7.7.8. Usage Example
7.7.8。 使用例
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="http://example.com/schema/config">
<services>
<ssh>
<allow-user>eric</allow-user>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
Given the following ordered-by user leaf-list:
次の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」を挿入するために使用されます。
Bjorklund Standards Track [Page 66]
RFC 6020 YANG October 2010
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<services>
<ssh>
<cipher nc:operation="create"
yang:insert="after"
yang:value="3des-cbc">blowfish-cbc</cipher>
</ssh>
</services>
</system>
</config>
</edit-config>
</rpc>
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 67] RFC 6020 YANG October 2010 7.8.1. The list's Substatements
7.8.1。 リストのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| key | 7.8.2 | 0..1 |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
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 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」ステートメントは、リストが構成を表す場合は必ず存在し、そうでない場合は存在する場合がありますが、このリストのリーフ識別子のスペース区切りリストを指定する文字列を引数として取ります。 リーフ識別子は、キーに複数回出現してはなりません。 このようなリーフ識別子はそれぞれ、リストの子リーフを参照する必要があります。 リーフは、リストのサブステートメントで直接定義することも、リストで使用されるグループで定義することもできます。
The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. It also implies that any mandatory statement in the key leafs are ignored.
キーで指定されたすべての葉の結合値は、リストエントリを一意に識別するために使用されます。 リストエントリの作成時に、すべてのキーリーフに値を指定する必要があります。 したがって、キーリーフのデフォルト値またはそのタイプは無視されます。 また、キーリーフの必須ステートメントは無視されます。
A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty".
キーの一部であるリーフは、組み込みタイプ「空」であってはならないことを除いて、任意の組み込みタイプまたは派生タイプにすることができます。
Bjorklund Standards Track [Page 68] RFC 6020 YANG October 2010 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 12.
キー文字列の構文は、セクション12のルール「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 12). Each such schema node identifier MUST refer to a leaf.
「ユニーク」ステートメントは、有効なリストエントリに制約を課すために使用されます。 引数として、スペースで区切られたスキーマノード識別子のリストを含む文字列を受け取ります。これは、子孫の形式で指定する必要があります（セクション12のルール「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. The constraint is enforced according to the rules in Section 8.
「一意の」制約は、デフォルト値のリーフを含む、引数文字列で指定されたすべてのリーフインスタンスの結合値が、参照されるすべてのリーフが存在するすべてのリストエントリインスタンス内で一意でなければならないことを指定します。 制約は、セクション8のルールに従って実施されます。
The unique string syntax is formally defined by the rule "unique-arg" in Section 12.
一意の文字列構文は、セクション12のルール「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 69]
RFC 6020 YANG October 2010
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", and "anyxml" statements can be used to define child nodes to the list.
リスト内では、「container」、「leaf」、「list」、「leaf-list」、「uses」、「choice」、および「anyxml」ステートメントを使用して、リストに子ノードを定義できます。
7.8.5. XML Mapping Rules
7.8.5。 XMLマッピングルール
A list is encoded as a series of XML elements, one for each entry in the list. Each element's local name is the list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リストは、リスト内の各エントリに1つずつ、一連のXML要素としてエンコードされます。 各要素のローカル名はリストの識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。
Bjorklund Standards Track [Page 70] RFC 6020 YANG October 2010 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 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」ステートメント内で定義されているのと同じ順序でエンコードされます。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
The XML elements representing list entries MUST appear in the order specified by the user if the list is "ordered-by user", otherwise the order is implementation-dependent. The XML elements representing list entries MAY be interleaved with other sibling elements, unless the list defines RPC input or output parameters.
リストが「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項を参照）のキー述語です。
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 the time, in the order of the XML elements in the request.
「ordered-by user」リストの複数のエントリが同じ<edit-config>リクエストで変更される場合、エントリはリクエストのXML要素の順序で一度に1つずつ変更されます。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire list, the list entry order is the same as the order of the XML elements in the request.
<copy-config>、またはリスト全体を対象とする「replace」操作を含む<edit-config>では、リストエントリの順序は、リクエスト内のXML要素の順序と同じです。
Bjorklund Standards Track [Page 71] RFC 6020 YANG October 2010 When a NETCONF server processes an <edit-config> request, the elements of procedure for a list node are:
NETCONFサーバーが<edit-config>要求を処理するとき、リストノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the list entry is
created if it does not exist. If the list entry already exists
and the "insert" and "key" attributes are present, the list entry
is moved according to the values of the "insert" and "key"
attributes. If the list entry exists and the "insert" and "key"
attributes are not present, the list entry is not moved.
操作が「マージ」または「置換」の場合、リストエントリが存在しない場合は作成されます。 リストエントリがすでに存在し、「挿入」および「キー」属性が存在する場合、リストエントリは「挿入」および「キー」属性の値に従って移動されます。 リストエントリが存在し、「挿入」および「キー」属性が存在しない場合、リストエントリは移動されません。
If the operation is "create", the list entry is created if it does
not exist. If the list entry already exists, a "data-exists"
error is returned.
操作が「作成」の場合、リストエントリが存在しない場合は作成されます。 リストエントリがすでに存在する場合、「data-exists」エラーが返されます。
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.
操作が「削除」の場合、エントリが存在する場合はリストから削除されます。 リストエントリが存在しない場合は、「データ欠落」エラーが返されます。
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 72]
RFC 6020 YANG October 2010
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="http://example.com/schema/config">
<user nc:operation="create">
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
</user>
</system>
</config>
</edit-config>
</rpc>
To change the type of "fred" to "superuser":
「fred」のタイプを「スーパーユーザー」に変更するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<user>
<name>fred</name>
<type>superuser</type>
</user>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 73]
RFC 6020 YANG October 2010
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 "name";
leaf name {
type string;
}
leaf type {
type string;
}
leaf full-name {
type string;
}
}
The following would be used to insert a new user "barney" after the
user "fred":
以下は、ユーザー「fred」の後に新しいユーザー「barney」を挿入するために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config"
xmlns:ex="http://example.com/schema/config">
<user nc:operation="create"
yang:insert="after"
yang:key="[ex:name='fred']">
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
</user>
</system>
</config>
</edit-config>
</rpc>
Bjorklund Standards Track [Page 74]
RFC 6020 YANG October 2010
The following would be used to move the user "barney" before the user
"fred":
次のコードは、ユーザー「barney」をユーザー「fred」の前に移動するために使用されます。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config"
xmlns:ex="http://example.com/schema/config">
<user nc:operation="merge"
yang:insert="before"
yang:key="[ex:name='fred']">
<name>barney</name>
</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 exist at any one time. The argument is an identifier, followed by a block of substatements that holds detailed choice information. The identifier is used to identify the choice node in the schema tree. A choice node does not exist in the data tree.
「選択」ステートメントは一連の選択肢を定義しますが、一度に存在できるのはそのうちの1つだけです。 引数は識別子であり、その後に詳細な選択情報を保持するサブステートメントのブロックが続きます。 識別子は、スキーマツリーで選択ノードを識別するために使用されます。 選択ノードがデータツリーに存在しません。
A choice consists of a number of branches, defined with the "case" substatement. Each branch contains a number of child nodes. The nodes from at most one of the choice's branches exist at the same time.
選択肢は、「case」サブステートメントで定義されたいくつかのブランチで構成されます。 各ブランチには、いくつかの子ノードが含まれています。 選択肢の最大で1つのブランチからのノードが同時に存在します。
See Section 8.3.2 for additional information.
詳細については、セクション8.3.2を参照してください。
Bjorklund Standards Track [Page 75] RFC 6020 YANG October 2010 7.9.1. The choice's Substatements
7.9.1。 選択のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| mandatory | 7.9.4 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
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.
The identifier is used to identify the case node in the schema tree. A case node does not exist in the data tree.
Within a "case" statement, the "anyxml", "choice", "container", "leaf", "list", "leaf-list", and "uses" statements can be used to define child nodes to the case node. The identifiers of all these child nodes MUST be unique within all cases in a choice. For example, the following is illegal:
「case」ステートメント内では、「anyxml」、「choice」、「container」、「leaf」、「list」、「leaf-list」、および「uses」ステートメントを使用して、caseノードに子ノードを定義できます。 。 これらすべての子ノードの識別子は、選択されたすべてのケースで一意である必要があります。 たとえば、以下は不正です。
choice interface-type { // This example is illegal YANG
case a {
leaf ethernet { ... }
}
case b {
container ethernet { ...}
}
}
Bjorklund Standards Track [Page 76]
RFC 6020 YANG October 2010
As a shorthand, the "case" statement can be omitted if the branch
contains a single "anyxml", "container", "leaf", "list", or
"leaf-list" statement. In this case, the identifier of the case node
is the same as the identifier in the branch statement. The following
example:
省略形として、ブランチに単一の「anyxml」、「container」、「leaf」、「list」、または「leaf-list」ステートメントが含まれている場合、「case」ステートメントは省略できます。 この場合、caseノードの識別子は、分岐ステートメントの識別子と同じです。 次の例：
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 |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
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 "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.
「デフォルト」ステートメントは、「必須」が当てはまる選択肢に存在してはなりません。
Bjorklund Standards Track [Page 77] RFC 6020 YANG October 2010 The default case is only important when considering the default values of nodes under the cases. The default values for nodes under the default case are used if none of the nodes under any of the cases are present.
デフォルトのケースは、ケースの下のノードのデフォルト値を検討する場合にのみ重要です。 デフォルトのケースのノードのデフォルト値は、どのケースのノードも存在しない場合に使用されます。
There MUST NOT be any mandatory nodes (Section 3.1) directly under the default case.
デフォルトのケースの直下に必須ノード（セクション3.1）があってはなりません。
Default values for child nodes under a case are only used if one of the nodes under that case is present, or if that case is the default case. If none of the nodes under a case are present and the case is not the default case, the default values of the cases' child nodes are ignored.
ケースの下の子ノードのデフォルト値は、そのケースの下のノードの1つが存在する場合、またはそのケースがデフォルトのケースである場合にのみ使用されます。 ケースの下にノードが存在せず、ケースがデフォルトのケースでない場合、ケースの子ノードのデフォルト値は無視されます。
In this example, the choice defaults to "interval", and the default value will be used if none of "daily", "time-of-day", or "manual" are present. If "daily" is present, the default value for "time-of-day" will be used.
この例では、デフォルトで「interval」が選択され、「daily」、「time-of-day」、または「manual」が存在しない場合はデフォルト値が使用されます。 「毎日」が存在する場合、「時刻」のデフォルト値が使用されます。
container transfer {
choice how {
default interval;
case interval {
leaf interval {
type uint16;
default 30;
units minutes;
}
}
case daily {
leaf daily {
type empty;
}
leaf time-of-day {
type string;
units 24-hour-clock;
default 1am;
}
}
case manual {
leaf manual {
type empty;
}
}
}
}
Bjorklund Standards Track [Page 78]
RFC 6020 YANG October 2010
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 which is not a non-presence container (see Section 7.5.1):
制約の動作は、スキーマツリー内の選択の最も近い祖先ノードのタイプに依存しますが、これは存在しないコンテナではありません（セクション7.5.1を参照）。
o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists.
この祖先がケースノードの場合、ケースの他のノードが存在する場合に制約が適用されます。
o 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 Mapping 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 input or output parameter definition. Otherwise, the subelements are encoded in any order.
選択された「case」ステートメントの子ノードは、RPC入力または出力パラメーター定義の一部である場合、「case」ステートメントで定義されているのと同じ順序でエンコードする必要があります。 それ以外の場合、サブ要素は任意の順序でエンコードされます。
7.9.6. NETCONF <edit-config> Operations
7.9.6。 NETCONF <edit-config>操作
Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If an <edit-config> operation creates a node from a case, the NETCONF server will delete any existing nodes that are defined in other cases inside the choice.
常に有効なのは選択肢のケースの1つだけなので、1つのケースからノードを作成すると、他のすべてのケースからすべてのノードが暗黙的に削除されます。 <edit-config>操作がケースからノードを作成する場合、NETCONFサーバーは、選択内の他のケースで定義されている既存のノードをすべて削除します。
7.9.7. Usage Example
7.9.7。 使用例
Given the following choice:
次の選択肢があるとします。
Bjorklund Standards Track [Page 79]
RFC 6020 YANG October 2010
container protocol {
choice name {
case a {
leaf udp {
type empty;
}
}
case b {
leaf tcp {
type empty;
}
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<protocol>
<tcp/>
</protocol>
To change the protocol from tcp to udp:
プロトコルをtcpからudpに変更するには：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<system xmlns="http://example.com/schema/config">
<protocol>
<udp nc:operation="create"/>
</protocol>
</system>
</config>
</edit-config>
</rpc>
7.10. The anyxml Statement
7.10。 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情報を保持するサブステートメントのブロックが続きます。
Bjorklund Standards Track [Page 80] RFC 6020 YANG October 2010 The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. This can be useful, for example, in RPC replies. An example is the <filter> parameter in the <get-config> operation.
「anyxml」ステートメントは、未知のXMLチャンクを表すために使用されます。 XMLに制限はありません。 これは、RPC応答などで役立ちます。 例は、<get-config>操作の<filter>パラメータです。
An anyxml node cannot be augmented (see Section 7.15).
anyxmlノードは拡張できません（セクション7.15を参照）。
Since the use of anyxml limits the manipulation of the content, it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data.
anyxmlを使用するとコンテンツの操作が制限されるため、構成データを表すために「anyxml」ステートメントを使用しないことをお勧めします。
An anyxml node exists in zero or one instances in the data tree.
anyxmlノードは、データツリーの0または1つのインスタンスに存在します。
7.10.1. The anyxml's Substatements
7.10.1。 anyxmlのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
7.10.2. XML Mapping Rules
7.10.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 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が異なる実装によって異なる方法でエンコードされる可能性があることを意味します。
7.10.3. NETCONF <edit-config> Operations
7.10.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サーバーによって無視されます。
Bjorklund Standards Track [Page 81] RFC 6020 YANG October 2010 When a NETCONF server processes an <edit-config> request, the elements of procedure for the anyxml node are:
NETCONFサーバーが<edit-config>要求を処理するとき、anyxmlノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if
it does not exist, and its value is set to the XML content of the
anyxml node found in the XML RPC data.
操作が「マージ」または「置換」の場合、ノードが存在しない場合はノードが作成され、その値はXML RPCデータにあるanyxmlノードのXMLコンテンツに設定されます。
If the operation is "create", the node is created if it does not
exist, and its value is set to the XML content of the anyxml node
found in the XML RPC data. If the node already exists, a
"data-exists" error is returned.
操作が「作成」の場合、ノードが存在しない場合はノードが作成され、その値はXML RPCデータにあるanyxmlノードのXMLコンテンツに設定されます。 ノードがすでに存在する場合、「data-exists」エラーが返されます。
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 "anyxml" statement:
次の「anyxml」ステートメントがあるとします。
anyxml data;
The following are two valid encodings of the same anyxml value:
以下は、同じanyxml値の2つの有効なエンコーディングです。
<data xmlns:if="http://example.com/ns/interface">
<if:interface>
<if:ifIndex>1</if:ifIndex>
</if:interface>
</data>
<data>
<interface xmlns="http://example.com/ns/interface">
<ifIndex>1</ifIndex>
</interface>
</data>
7.11. The grouping Statement
7.11。 グループ化ステートメント
The "grouping" statement is used to define a reusable block of nodes, which may be used locally in the module, in modules that include it, and by other modules that import from it, according to the rules in Section 5.5. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed grouping information.
「グループ化」ステートメントは、ノードの再利用可能なブロックを定義するために使用されます。これは、セクション5.5のルールに従って、モジュール内、それを含むモジュール内、およびそれからインポートする他のモジュールによってローカルで使用できます。 1つの引数（識別子）を受け取り、その後に詳細なグループ化情報を保持するサブステートメントのブロックが続きます。
The "grouping" statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
「グループ化」ステートメントはデータ定義ステートメントではないため、スキーマツリーのノードを定義しません。
A grouping is like a "structure" or a "record" in conventional programming languages.
グループ化は、従来のプログラミング言語における「構造」または「レコード」のようなものです。
Bjorklund Standards Track [Page 82] RFC 6020 YANG October 2010 Once a grouping is defined, it can be referenced in a "uses" statement (see Section 7.12). A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings.
グループ化が定義されると、「uses」ステートメントで参照できます（セクション7.12を参照）。 グループ化は、他のグループ化のチェーンを介して直接的または間接的にそれ自体を参照してはなりません。
If the grouping is defined at the top level of a YANG module or submodule, the grouping's identifier MUST be unique within the module.
グループ化がYANGモジュールまたはサブモジュールのトップレベルで定義されている場合、グループ化の識別子はモジュール内で一意である必要があります。
A grouping is more than just a mechanism for textual substitution, but defines a collection of nodes. Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used. Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the "grouping" statement appears. For extensions, this means that extensions are applied to the grouping node, not the uses node.
グループ化は単なるテキスト置換のメカニズムではありませんが、ノードのコレクションを定義します。 グループ内に表示される識別子は、グループが使用されている場所ではなく、グループが定義されているスコープに関連して解決されます。 接頭辞マッピング、タイプ名、グループ化名、および拡張機能の使用法は、「グループ化」ステートメントが表示される階層で評価されます。 拡張機能の場合、これは、拡張機能が使用ノードではなくグループ化ノードに適用されることを意味します。
7.11.1. The grouping's Substatements
7.11.1。 グループのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 83]
RFC 6020 YANG October 2010
7.11.2. Usage Example
7.11.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;
}
}
7.12. The uses Statement
7.12。 usesステートメント
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 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」ステートメントを介してグループ化の内容がスキーマツリーに追加されるまで、名前空間にバインドされません。 現在のモジュールの。
Bjorklund Standards Track [Page 84] RFC 6020 YANG October 2010 7.12.1. The uses's Substatements
7.12.1。 使用のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| augment | 7.15 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| refine | 7.12.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
7.12.2. The refine Statement
7.12.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 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 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, anyxml, or choice node may get a different "mandatory"
statement.
リーフ、anyxml、またはchoiceノードは、異なる「必須」ステートメントを取得する場合があります。
o A container node may get a "presence" statement.
コンテナノードは「存在」ステートメントを取得する場合があります。
o A leaf, leaf-list, list, container, or anyxml node may get
additional "must" expressions.
リーフ、リーフリスト、リスト、コンテナ、またはanyxmlノードは、追加の「必須」式を取得する場合があります。
o A leaf-list or list node may get a different "min-elements" or
"max-elements" statement.
リーフリストまたはリストノードは、異なる「最小要素」または「最大要素」ステートメントを取得する場合があります。
Bjorklund Standards Track [Page 85] RFC 6020 YANG October 2010 7.12.3. XML Mapping Rules
7.12.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.12.4. Usage Example
7.12.4。 使用例
To use the "endpoint" grouping defined in Section 7.11.2 in a definition of an HTTP server in some other module, we can do:
セクション7.11.2で定義された「エンドポイント」グループを他のモジュールのHTTPサーバーの定義で使用するには、次のようにします。
import acme-system {
prefix "acme";
}
container http-server {
leaf name {
type string;
}
uses acme:endpoint;
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<http-server>
<name>extern-web</name>
<ip>192.0.2.1</ip>
<port>80</port>
</http-server>
If port 80 should be the default for the HTTP server, default can be
added:
ポート80をHTTPサーバーのデフォルトにする必要がある場合は、デフォルトを追加できます。
container http-server {
leaf name {
type string;
}
uses acme:endpoint {
refine port {
default 80;
}
}
}
If we want to define a list of servers, and each server has the ip
and port as keys, we can do:
サーバーのリストを定義し、各サーバーがキーとしてIPとポートを持っている場合、次のようにできます。
Bjorklund Standards Track [Page 86]
RFC 6020 YANG October 2010
list server {
key "ip port";
leaf name {
type string;
}
uses acme:endpoint;
}
The following is an error:
container http-server {
uses acme:endpoint;
leaf ip { // illegal - same identifier "ip" used twice
type string;
}
}
7.13. The rpc Statement
7.13。 rpcステートメント
The "rpc" statement is used to define a NETCONF RPC operation. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed rpc information. This argument is the name of the RPC, and is used as the element name directly under the <rpc> element, as designated by the substitution group "rpcOperation" in [RFC4741].
「rpc」ステートメントは、NETCONF RPC操作を定義するために使用されます。 1つの引数（識別子）を受け取り、その後に詳細なRPC情報を保持するサブステートメントのブロックが続きます。 この引数はRPCの名前であり、[RFC4741]の置換グループ「rpcOperation」で指定されている<rpc>要素の直下の要素名として使用されます。
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」という名前のスキーマノードも定義されています。 ノード「入力」と「出力」は、モジュールの名前空間で定義されます。
Bjorklund Standards Track [Page 87] RFC 6020 YANG October 2010 7.13.1. The rpc's Substatements
7.13.1。 RPCのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
7.13.2. The input Statement
7.13.2。 入力ステートメント
The "input" statement, which is optional, is used to define input parameters to the RPC operation. It does not take an argument. The substatements to "input" define nodes under the RPC's input node.
オプションの "input"ステートメントは、RPC操作への入力パラメーターを定義するために使用されます。 引数は取りません。 「入力」のサブステートメントは、RPCの入力ノードの下のノードを定義します。
If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. Otherwise, the server MUST return a "missing-element" error.
入力ツリーのリーフに値「true」の「必須」ステートメントがある場合、リーフはNETCONF RPC呼び出しに存在している必要があります。 それ以外の場合、サーバーは「missing-element」エラーを返す必要があります。
If a leaf in the input tree has a default value, the NETCONF server MUST use this value in the same cases as described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the NETCONF RPC invocation with the default value as its value.
入力ツリーのリーフにデフォルト値がある場合、NETCONFサーバーは、セクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。 これらの場合、サーバーは、リーフがNETCONF RPC呼び出しに存在するかのように、デフォルト値をその値として使用して動作する必要があります。
If a "config" statement is present for any node in the input tree, the "config" statement is ignored.
「config」ステートメントが入力ツリーのノードに存在する場合、「config」ステートメントは無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the input tree.
いずれかのノードにfalseと評価される「when」ステートメントがある場合、このノードは入力ツリーに存在してはなりません（MUST NOT）。
Bjorklund Standards Track [Page 88] RFC 6020 YANG October 2010 7.13.2.1. The input's Substatements
7.13.2.1。 入力のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
7.13.3. The output Statement
7.13.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 RPC's output node.
オプションの「output」ステートメントは、RPC操作の出力パラメーターを定義するために使用されます。 引数は取りません。 「出力」のサブステートメントは、RPCの出力ノードの下のノードを定義します。
If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC reply.
出力ツリーのリーフに値「true」の「必須」ステートメントがある場合、リーフはNETCONF RPC応答に存在する必要があります。
If a leaf in the output tree has a default value, the NETCONF client MUST use this value in the same cases as described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF RPC reply with the default value as its value.
出力ツリーのリーフにデフォルト値がある場合、NETCONFクライアントは、セクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。 これらの場合、クライアントは、リーフがNETCONF RPC応答に存在するかのように動作し、デフォルト値をその値として使用する必要があります。
If a "config" statement is present for any node in the output tree, the "config" statement is ignored.
「config」ステートメントが出力ツリーのいずれかのノードに存在する場合、「config」ステートメントは無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the output tree.
いずれかのノードにfalseと評価される「when」ステートメントがある場合、このノードは出力ツリーに存在してはなりません（MUST NOT）。
Bjorklund Standards Track [Page 89] RFC 6020 YANG October 2010 7.13.3.1. The output's Substatements
7.13.3.1。 出力のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
7.13.4. XML Mapping Rules
7.13.4。 XMLマッピングルール
An rpc node is encoded as a child XML element to the <rpc> element defined in [RFC4741]. The element's local name is the rpc's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
rpcノードは、[RFC4741]で定義されている<rpc>要素への子XML要素としてエンコードされます。 要素のローカル名はrpcの識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。
Input parameters are encoded as child XML elements to the rpc node's XML element, in the same order as they are defined within the "input" statement.
入力パラメーターは、rpcノードのXML要素への子XML要素として、「入力」ステートメント内で定義されているのと同じ順序でエンコードされます。
If the RPC operation invocation succeeded, and no output parameters are returned, the <rpc-reply> contains a single <ok/> element defined in [RFC4741]. If output parameters are returned, they are encoded as child elements to the <rpc-reply> element defined in [RFC4741], in the same order as they are defined within the "output" statement.
RPC操作の呼び出しが成功し、出力パラメーターが返されない場合、<rpc-reply>には、[RFC4741]で定義されている単一の<ok />要素が含まれています。 出力パラメータが返される場合、それらは「output」ステートメント内で定義されているのと同じ順序で、[RFC4741]で定義されている<rpc-reply>要素の子要素としてエンコードされます。
Bjorklund Standards Track [Page 90] RFC 6020 YANG October 2010 7.13.5. Usage Example
7.13.5。 使用例
The following example defines an RPC operation:
次の例では、RPC操作を定義しています。
module rock {
namespace "http://example.net/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-応答の対応するXMLインスタンスの例：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
7.14. The notification Statement
7.14。 通知ステートメント
The "notification" statement is used to define a NETCONF notification. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed notification information. The "notification" statement defines a notification node in the schema tree.
「通知」ステートメントは、NETCONF通知を定義するために使用されます。 1つの引数（識別子）を受け取り、その後に詳細な通知情報を保持するサブステートメントのブロックが続きます。 「通知」ステートメントは、スキーマツリーの通知ノードを定義します。
If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF notification.
通知ツリーのリーフに値「true」の「必須」ステートメントがある場合、リーフはNETCONF通知に存在する必要があります。
If a leaf in the notification tree has a default value, the NETCONF client MUST use this value in the same cases as described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF notification with the default value as its value.
通知ツリーのリーフにデフォルト値がある場合、NETCONFクライアントは、セクション7.6.1で説明されているのと同じケースでこの値を使用する必要があります。 これらの場合、クライアントは、リーフがNETCONF通知に存在し、その値としてデフォルト値が存在するかのように動作する必要があります。
Bjorklund Standards Track [Page 91] RFC 6020 YANG October 2010 If a "config" statement is present for any node in the notification tree, the "config" statement is ignored.
「config」ステートメントが通知ツリーのノードに存在する場合、「config」ステートメントは無視されます。
7.14.1. The notification's Substatements
7.14.1。 通知のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
7.14.2. XML Mapping Rules
7.14.2。 XMLマッピングルール
A notification node is encoded as a child XML element to the <notification> element defined in NETCONF Event Notifications [RFC5277]. The element's local name is the notification's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
通知ノードは、NETCONFイベント通知[RFC5277]で定義されている<notification>要素への子XML要素としてエンコードされます。 要素のローカル名は通知の識別子であり、その名前空間はモジュールのXML名前空間です（セクション7.1.3を参照）。
Bjorklund Standards Track [Page 92] RFC 6020 YANG October 2010 7.14.3. Usage Example
7.14.3。 使用例
The following example defines a notification:
次の例では、通知を定義しています。
module event {
namespace "http://example.com/event";
prefix "ev";
notification event {
leaf event-class {
type string;
}
anyxml reporting-entity;
leaf severity {
type string;
}
}
}
A corresponding XML instance example of the complete notification:
完全な通知の対応するXMLインスタンスの例：
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event">
<event-class>fault</event-class>
<reporting-entity>
<card>Ethernet0</card>
</reporting-entity>
<severity>major</severity>
</event>
</notification>
7.15. The augment Statement
7.15。 拡張ステートメント
The "augment" statement allows a module or submodule to add to the schema tree defined in an external module, or the current module and its submodules, and to add to the nodes from a grouping in a "uses" statement. The argument is a string that identifies a node in the schema tree. This node is called the augment's target node. The target node MUST be either a container, list, choice, case, input, output, or notification node. It is augmented with the nodes defined in the substatements that follow the "augment" statement.
「augment」ステートメントを使用すると、モジュールまたはサブモジュールを外部モジュールで定義されているスキーマツリー、または現在のモジュールとそのサブモジュールに追加したり、「uses」ステートメントのグループからノードに追加したりできます。 引数は、スキーマツリー内のノードを識別する文字列です。 このノードは、拡張のターゲットノードと呼ばれます。 ターゲットノードは、コンテナ、リスト、選択、ケース、入力、出力、または通知ノードのいずれかである必要があります。 これは、「augment」ステートメントに続くサブステートメントで定義されたノードで拡張されます。
The argument string is a schema node identifier (see Section 6.5). If the "augment" statement is on the top level in a module or submodule, the absolute form (defined by the rule Bjorklund Standards Track [Page 93] RFC 6020 YANG October 2010 "absolute-schema-nodeid" in Section 12) of a schema node identifier MUST be used. If the "augment" statement is a substatement to the "uses" statement, the descendant form (defined by the rule "descendant-schema-nodeid" in Section 12) MUST be used.
引数文字列はスキーマノード識別子です（6.5節を参照）。 「augment」ステートメントがモジュールまたはサブモジュールの最上位にある場合は、スキーマノード識別子の絶対形式（セクション12のルール「absolute-schema-nodeid」で定義）を使用する必要があります。 「augment」ステートメントが「uses」ステートメントのサブステートメントである場合は、子孫フォーム（セクション12の「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 choice node, the "case" statement, or a case shorthand statement (see Section 7.9.2) can be used within the "augment" statement.
ターゲット・ノードが選択ノードの場合、「augment」ステートメント内で「case」ステートメントまたはcase省略ステートメント（7.9.2項を参照）を使用できます。
If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see Section 3.1).
ターゲットノードが別のモジュールにある場合、オーグメンテーションによって追加されたノードは必須ノードであってはなりません（セクション3.1を参照）。
The "augment" statement MUST NOT add multiple nodes with the same name from the same module to the target node.
"augment"ステートメントは、同じモジュールから同じ名前の複数のノードをターゲットノードに追加してはなりません（MUST NOT）。
7.15.1. The augment's Substatements
7.15.1。 拡張のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
7.15.2. XML Mapping Rules
7.15.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 94] RFC 6020 YANG October 2010 7.15.3. Usage Example
In namespace http://example.com/schema/interfaces, we have:
container interfaces {
list ifEntry {
key "ifIndex";
leaf ifIndex {
type uint32;
}
leaf ifDescr {
type string;
}
leaf ifType {
type iana:IfType;
}
leaf ifMtu {
type int32;
}
}
}
Then, in namespace http://example.com/schema/ds0, we have:
import interface-module {
prefix "if";
}
augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'";
leaf ds0ChannelNumber {
type ChannelNumber;
}
}
Bjorklund Standards Track [Page 95]
RFC 6020 YANG October 2010
A corresponding XML instance example:
対応するXMLインスタンスの例：
<interfaces xmlns="http://example.com/schema/interfaces"
xmlns:ds0="http://example.com/schema/ds0">
<ifEntry>
<ifIndex>1</ifIndex>
<ifDescr>Flintstone Inc Ethernet A562</ifDescr>
<ifType>ethernetCsmacd</ifType>
<ifMtu>1500</ifMtu>
</ifEntry>
<ifEntry>
<ifIndex>2</ifIndex>
<ifDescr>Flintstone Inc DS0</ifDescr>
<ifType>ds0</ifType>
<ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
</ifEntry>
</interfaces>
As another example, suppose we have the choice defined in
Section 7.9.7. The following construct can be used to extend the
protocol definition:
別の例として、セクション7.9.7で定義された選択肢があるとします。 次の構文を使用して、プロトコル定義を拡張できます。
augment /ex:system/ex:protocol/ex:name {
case c {
leaf smtp {
type empty;
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<ex:system>
<ex:protocol>
<ex:tcp/>
</ex:protocol>
</ex:system>
or
<ex:system>
<ex:protocol>
<other:smtp/>
</ex:protocol>
</ex:system>
Bjorklund Standards Track [Page 96]
RFC 6020 YANG October 2010
7.16. The identity Statement
7.16。 アイデンティティステートメント
The "identity" statement is used to define a new globally unique, abstract, and untyped identity. Its only purpose is to denote its name, semantics, and existence. An identity can either be defined from scratch or derived from a base identity. The identity's argument is an identifier that is the name of the identity. It is followed by a block of substatements that holds detailed identity information.
「identity」ステートメントは、グローバルに一意で抽象的で型付けされていない新しいアイデンティティを定義するために使用されます。 その唯一の目的は、その名前、セマンティクス、および存在を示すことです。 IDは、最初から定義するか、基本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.16.1. The identity's Substatements
7.16.1。 アイデンティティのサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| base | 7.16.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
7.16.2. The base Statement
7.16.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.
「base」ステートメントはオプションであり、既存の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は、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
Since submodules cannot include the parent module, any identities in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the identity.
サブモジュールには親モジュールを含めることができないため、サブモジュールに公開する必要があるモジュール内のIDは、サブモジュールで定義する必要があります。 次に、サブモジュールにこのサブモジュールを含めて、アイデンティティの定義を見つけることができます。
An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.
アイデンティティは、他のアイデンティティのチェーンを介して直接的または間接的に自分自身を参照してはなりません。
Bjorklund Standards Track [Page 97] RFC 6020 YANG October 2010 7.16.3. Usage Example
7.16.3。 使用例
module crypto-base {
namespace "http://example.com/crypto-base";
prefix "crypto";
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
}
module des {
namespace "http://example.com/des";
prefix "des";
import "crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
description "Triple DES crypto algorithm";
}
}
7.17. The extension Statement
7.17。 拡張ステートメント
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 statement's argument is an identifier that is the new keyword for the extension and must be followed by a block of substatements that holds detailed extension information. The purpose of the "extension" statement is to define a keyword, so that it can be imported and used by other modules.
ステートメントの引数は、拡張の新しいキーワードである識別子であり、その後に詳細な拡張情報を保持するサブステートメントのブロックが続く必要があります。 「拡張」ステートメントの目的は、キーワードを定義して、他のモジュールでインポートして使用できるようにすることです。
The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the
extension, and an optional block of substatements. The statement's
name is created by combining the prefix of the module in which the
Bjorklund Standards Track [Page 98]
RFC 6020 YANG October 2010
extension was defined, a colon (":"), and the extension's keyword,
with no interleaving whitespace. The substatements of an extension
are defined by the extension, using some mechanism outside the scope
of this specification. Syntactically, the substatements MUST be YANG
statements, or also defined using "extension" statements. YANG
statements in extensions MUST follow the syntactical rules in
Section 12.
拡張機能は、通常のYANGステートメントのように使用できます。拡張機能で定義されている場合はステートメント名の後に引数が続き、オプションでサブステートメントのブロックが続きます。 ステートメントの名前は、拡張が定義されたモジュールのプレフィックス、コロン（ "："）、および拡張のキーワードを組み合わせることによって作成されます。 拡張のサブステートメントは、この仕様の範囲外の何らかのメカニズムを使用して、拡張によって定義されます。 構文的には、サブステートメントはYANGステートメントであるか、「拡張」ステートメントを使用して定義する必要があります。 拡張機能のYANGステートメントは、セクション12の構文規則に従う必要があります。
7.17.1. The extension's Substatements
7.17.1。 拡張のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| argument | 7.17.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
7.17.2. The argument Statement
7.17.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.17.2.1. The argument's Substatements
7.17.2.1。 引数のサブステートメント
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| yin-element | 7.17.2.2 | 0..1 |
+--------------+----------+-------------+
7.17.2.2. The yin-element Statement
7.17.2.2。 陰要素ステートメント
The "yin-element" statement, which is optional, takes as an argument the string "true" or "false". This statement indicates if the argument is mapped to an XML element in YIN or to an XML attribute (see Section 11).
オプションの「yin-element」ステートメントは、ストリング「true」または「false」を引数として取ります。 このステートメントは、引数がYINのXML要素にマップされるか、XML属性にマップされるかを示します（セクション11を参照）。
If no "yin-element" statement is present, it defaults to "false".
「yin-element」ステートメントが存在しない場合、デフォルトで「false」になります。
Bjorklund Standards Track [Page 99] RFC 6020 YANG October 2010 7.17.3. Usage Example
7.17.3。 使用例
To define an extension:
拡張を定義するには：
module my-extensions {
...
extension c-define {
description
"Takes as argument a name string.
Makes the code generator use the given name in the
#define.";
argument "name";
}
}
To use the extension:
拡張機能を使用するには：
module my-interfaces {
...
import my-extensions {
prefix "myext";
}
...
container interfaces {
...
myext:c-define "MY_INTERFACES";
}
}
7.18. Conformance-Related Statements
7.18。 適合性関連のステートメント
This section defines statements related to conformance, as described in Section 5.6.
このセクションでは、セクション5.6で説明されているように、適合性に関連するステートメントを定義します。
7.18.1. The feature Statement
7.18.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.18.2). Schema nodes tagged with a feature are ignored by the device unless the device supports the given feature. This allows portions of the YANG module to be conditional based on conditions on the device. The model can represent the abilities of the device within the model, giving a richer model that allows for differing device abilities and roles.
「機能」ステートメントは、スキーマの一部を条件付きとしてマークするメカニズムを定義するために使用されます。 機能名は、「if-feature」ステートメントを使用して後で参照できるように定義されています（セクション7.18.2を参照）。 機能でタグ付けされたスキーマノードは、デバイスが特定の機能をサポートしていない限り、デバイスによって無視されます。 これにより、YANGモジュールの一部をデバイスの条件に基づいて条件付きにすることができます。 モデルは、モデル内のデバイスの能力を表すことができ、さまざまなデバイスの能力と役割を可能にするより豊富なモデルを提供します。
Bjorklund Standards Track [Page 100] RFC 6020 YANG October 2010 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.
"feature"ステートメントの引数は新しい機能の名前であり、セクション6.2の識別子の規則に従います。 この名前は、スキーマノードを機能に関連付けるために「if-feature」ステートメントで使用されます。
In this example, a feature called "local-storage" represents the ability for a device to store syslog messages on local storage of some sort. This feature is used to make the "local-storage-limit" leaf conditional on the presence of some sort of local storage. If the device does not report that it supports this feature, the "local-storage-limit" node is not supported.
この例では、「local-storage」と呼ばれる機能が、デバイスが何らかのローカルストレージにsyslogメッセージを保存する機能を表しています。 この機能は、「local-storage-limit」リーフをある種のローカルストレージの存在を条件とするために使用されます。 デバイスがこの機能をサポートしていることを報告しない場合、「local-storage-limit」ノードはサポートされません。
module syslog {
...
feature local-storage {
description
"This feature means the device supports local
storage (memory, flash or disk) that can be used to
store syslog messages.";
}
container syslog {
leaf local-storage-limit {
if-feature local-storage;
type uint64;
units "kilobyte";
config false;
description
"The amount of local storage that can be
used to hold syslog messages.";
}
}
}
The "if-feature" statement can be used in many places within the YANG
syntax. Definitions tagged with "if-feature" are ignored when the
device does not support that feature.
「if-feature」ステートメントは、YANG構文内の多くの場所で使用できます。 デバイスがその機能をサポートしていない場合、「if-feature」でタグ付けされた定義は無視されます。
A feature MUST NOT reference itself, neither directly nor indirectly through a chain of other features.
機能は、他の機能のチェーンを通じて直接的または間接的にそれ自体を参照してはなりません。
In order for a device to implement a feature that is dependent on any other features (i.e., the feature has one or more "if-feature" sub- statements), the device MUST also implement all the dependant features.
デバイスが他の機能に依存する機能を実装する（つまり、機能に1つ以上の「if-feature」サブステートメントがある）ために、デバイスはすべての依存機能も実装する必要があります。
Bjorklund Standards Track [Page 101] RFC 6020 YANG October 2010 7.18.1.1. The feature's Substatements
7.18.1.1。 機能のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
7.18.2. The if-feature Statement
7.18.2。 if-featureステートメント
The "if-feature" statement makes its parent statement conditional. The argument is the name of a feature, as defined by a "feature" statement. The parent statement is implemented by servers that support this feature. If a prefix is present on the feature name, it refers to a feature defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, a feature with the matching name MUST be defined in the current module or an included submodule.
「if-feature」ステートメントは、その親ステートメントを条件付きにします。 引数は、「feature」ステートメントで定義されている機能の名前です。 親ステートメントは、この機能をサポートするサーバーによって実装されます。 機能名にプレフィックスが存在する場合、そのプレフィックスでインポートされたモジュールで定義された機能、またはプレフィックスがローカルモジュールのプレフィックスと一致する場合はローカルモジュールを指します。 それ以外の場合、一致する名前の機能は、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
Since submodules cannot include the parent module, any features in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the feature.
サブモジュールには親モジュールを含めることができないため、サブモジュールに公開する必要があるモジュール内の機能は、サブモジュールで定義する必要があります。 次に、サブモジュールにこのサブモジュールを含めて、機能の定義を見つけることができます。
7.18.3. The deviation Statement
7.18.3。 偏差ステートメント
The "deviation" statement defines a hierarchy of a module that the device does not implement faithfully. The argument is a string that identifies the node in the schema tree where a deviation from the module occurs. This node is called the deviation's target node. The contents of the "deviation" statement give details about the deviation.
「偏差」ステートメントは、デバイスが忠実に実装していないモジュールの階層を定義します。 引数は、モジュールからの逸脱が発生するスキーマツリー内のノードを識別する文字列です。 このノードは、偏差のターゲットノードと呼ばれます。 「偏差」ステートメントの内容は、偏差に関する詳細を示します。
The argument string is an absolute schema node identifier (see Section 6.5).
引数文字列は、絶対スキーマノード識別子です（6.5節を参照）。
Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards.
偏差は、デバイスまたはデバイスのクラスが標準から逸脱する方法を定義します。 これは、偏差が実装と標準との違いを知るためのメカニズムであるため、偏差が公開された標準の一部であってはならないことを意味します。
Bjorklund Standards Track [Page 102] RFC 6020 YANG October 2010 Device deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. A device that deviates from a module is not fully compliant with the module.
デバイスの逸脱は強くお勧めできません。最後の手段としてのみ使用してください。 デバイスがどのように標準に準拠しないかをアプリケーションに通知することは、標準を正しく実装することの代わりにはなりません。 モジュールから逸脱したデバイスは、モジュールに完全には準拠していません。
However, in some cases, a particular device may not have the hardware or software ability to support parts of a standard module. When this occurs, the device makes a choice either to treat attempts to configure unsupported parts of the module as an error that is reported back to the unsuspecting application or ignore those incoming requests. Neither choice is acceptable.
ただし、特定のデバイスには、標準モジュールの一部をサポートするハードウェアまたはソフトウェアの機能がない場合があります。 これが発生すると、デバイスは、モジュールのサポートされていない部分を構成する試みを、疑いを持たないアプリケーションに報告されるエラーとして処理するか、それらの着信要求を無視するかのいずれかを選択します。 どちらの選択も受け入れられません。
Instead, YANG allows devices to document portions of a base module that are not supported or supported but with different syntax, by using the "deviation" statement.
代わりに、YANGは、「偏差」ステートメントを使用することにより、サポートされていない、またはサポートされているが構文が異なる基本モジュールの部分をデバイスが文書化できるようにします。
7.18.3.1. The deviation's Substatements
7.18.3.1。 偏差のサブステートメント
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 1..n |
| reference | 7.19.4 | 0..1 |
+--------------+----------+-------------+
7.18.3.2. The deviate Statement
7.18.3.2。 逸脱した声明
The "deviate" statement defines how the device's implementation of the target node deviates from its original definition. The argument is one of the strings "not-supported", "add", "replace", or "delete".
「deviate」ステートメントは、ターゲットノードのデバイスの実装が元の定義からどのように逸脱するかを定義します。 引数は、「サポートされていない」、「追加」、「置換」、または「削除」のいずれかの文字列です。
The argument "not-supported" indicates that the target node is not implemented by this device.
引数「サポートされていません」は、ターゲットノードがこのデバイスによって実装されていないことを示します。
The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node.
引数「add」は、ターゲットノードにプロパティを追加します。 追加するプロパティは、「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」ステートメントのサブステートメントによって識別されます。 置き換えるプロパティは、ターゲットノードに存在する必要があります。
Bjorklund Standards Track [Page 103] RFC 6020 YANG October 2010 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」ステートメントのサブステートメントによって識別されます。 サブステートメントのキーワードは、ターゲットノードの対応するキーワードと一致する必要があり、引数の文字列は、ターゲットノードの対応するキーワードの引数文字列と等しい必要があります。
The deviates's Substatements
逸脱者のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| mandatory | 7.6.5 | 0..1 |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| type | 7.4 | 0..1 |
| unique | 7.8.3 | 0..n |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
7.18.3.3. Usage Example
7.18.3.3。 使用例
In this example, the device is informing client applications that it does not support the "daytime" service in the style of RFC 867.
この例では、デバイスはクライアントアプリケーションに、RFC 867のスタイルの「日中」サービスをサポートしていないことを通知しています。
deviation /base:system/base:daytime {
deviate not-supported;
}
The following example sets a device-specific default value to a leaf
that does not have a default value defined:
次の例では、デバイス固有のデフォルト値を、デフォルト値が定義されていないリーフに設定しています。
deviation /base:system/base:user/base:type {
deviate add {
default "admin"; // new users are 'admin' by default
}
}
In this example, the device limits the number of name servers to 3:
この例では、デバイスはネームサーバーの数を3に制限しています。
deviation /base:system/base:name-server {
deviate replace {
max-elements 3;
}
}
Bjorklund Standards Track [Page 104]
RFC 6020 YANG October 2010
If the original definition is:
元の定義が次の場合：
container system {
must "daytime or time";
...
}
a device might remove this must constraint by doing:
デバイスは、次のようにして、このmust制約を削除する場合があります。
deviation "/base:system" {
deviate delete {
must "daytime or time";
}
}
7.19. Common Statements
7.19。 共通の声明
This section defines substatements common to several other statements.
このセクションでは、他のいくつかのステートメントに共通するサブステートメントを定義します。
7.19.1. The config Statement
7.19.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 will be part of the reply to a <get-config> request, and can be sent in a <copy-config> or <edit-config> request.
「config」ステートメントは、ストリング「true」または「false」を引数として取ります。 「config」が「true」の場合、定義は構成を表します。 構成を表すデータノードは、<get-config>要求への応答の一部となり、<copy-config>または<edit-config>要求で送信できます。
If "config" is "false", the definition represents state data. Data nodes representing state data will be part of the reply to a <get>, but not to a <get-config> request, and cannot be sent in a <copy-config> or <edit-config> request.
「config」が「false」の場合、定義は状態データを表します。 状態データを表すデータノードは、<get>への応答の一部になりますが、<get-config>要求への応答ではありません。また、<copy-config>または<edit-config>要求で送信することはできません。
If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node.
「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.19.2. The status Statement
7.19.2。 ステータスステートメント
The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete".
「ステータス」ステートメントは、「現在」、「非推奨」、「廃止」のいずれかの文字列を引数として取ります。
Bjorklund Standards Track [Page 105] RFC 6020 YANG October 2010 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 the definition is obsolete and SHOULD NOT be
implemented and/or can be removed from implementations.
「廃止された」とは、定義が廃止されており、実装すべきではない、および/または実装から削除できることを意味します。
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
}
7.19.3. The description Statement
7.19.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.19.4. The reference Statement
7.19.4。 参照ステートメント
The "reference" statement takes as an argument a string that is used to specify a textual cross-reference to an external document, either another module that defines related management information, or a document that provides additional information relevant to this definition.
「参照」ステートメントは、外部ドキュメント、関連する管理情報を定義する別のモジュール、またはこの定義に関連する追加情報を提供するドキュメントへのテキスト相互参照を指定するために使用される文字列を引数として取ります。
Bjorklund Standards Track [Page 106] RFC 6020 YANG October 2010 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.19.5. The when Statement
7.19.5。 whenステートメント
The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression (see Section 6.4), which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the node defined by the parent data definition statement is valid; otherwise, it is not.
「いつ」ステートメントは、その親データ定義ステートメントを条件付きにします。 親データ定義ステートメントで定義されたノードは、「when」ステートメントで指定された条件が満たされた場合にのみ有効です。 ステートメントの引数はXPath式（6.4節を参照）であり、この条件を正式に指定するために使用されます。 XPath式が特定のインスタンスに対して概念的に「true」と評価される場合、親データ定義ステートメントによって定義されたノードは有効です。 そうでなければ、そうではありません。
See Section 8.3.2 for additional information.
詳細については、セクション8.3.2を参照してください。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、セクション6.4.1の定義に加えて、次のコンテキストで概念的に評価されます。
o If the "when" statement is a child of an "augment" statement, then
the context node is the augment's target node in the data tree, if
the target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node that is also a data
node.
「when」ステートメントが「augment」ステートメントの子である場合、ターゲットノードがデータノードであれば、コンテキストノードはデータツリー内のaugmentのターゲットノードです。 それ以外の場合、コンテキストノードは、データノードでもあるターゲットノードに最も近い祖先ノードです。
o If the "when" statement is a child of a "uses", "choice", or
"case" statement, then the context node is the closest ancestor
node to the "uses", "choice", or "case" node that is also a data
node.
「when」ステートメントが「uses」、「choice」、または「case」ステートメントの子である場合、コンテキストノードは、「uses」、「choice」、または「case」ノードに最も近い祖先ノードです。 データノードでもあります。
o If the "when" statement is a child of any other data definition
statement, the context node is the data definition's node in the
data tree.
「when」ステートメントが他のデータ定義ステートメントの子である場合、コンテキストノードはデータツリー内のデータ定義のノードです。
o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values in use (see Section 7.6.1).
アクセス可能なツリーは、データツリーのすべてのノードと、使用中のデフォルト値を持つすべてのリーフで構成されます（7.6.1項を参照）。
Bjorklund Standards Track [Page 107] RFC 6020 YANG October 2010 The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードによって異なります。
o If the context node represents configuration, the tree is the data
in the NETCONF datastore where the context node exists. The XPath
root node has all top-level configuration data nodes in all
modules as children.
コンテキストノードが構成を表す場合、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathルートノードには、すべてのモジュールのすべての最上位の構成データノードが子として含まれます。
o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children.
コンテキストノードが状態データを表す場合、ツリーはすべてデバイス上の状態データであり、<running />データストアです。 XPathルートノードには、すべてのモジュールのすべての最上位データノードが子として含まれます。
o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has
the element representing the notification being defined as the
only child.
コンテキストノードが通知コンテンツを表す場合、ツリーは通知XMLインスタンスドキュメントです。 XPathルートノードには、唯一の子として定義される通知を表す要素があります。
o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the
element representing the RPC operation being defined as the only
child.
コンテキストノードがRPC入力パラメーターを表す場合、ツリーはRPC XMLインスタンスドキュメントです。 XPathルートノードには、RPC操作を表す要素が唯一の子として定義されています。
o If the context node represents RPC output parameters, the tree is
the RPC reply instance document. The XPath root node has the
elements representing the RPC output parameters as children.
コンテキストノードがRPC出力パラメーターを表す場合、ツリーはRPC応答インスタンスドキュメントです。 XPathルートノードには、RPC出力パラメーターを子として表す要素があります。
The result of the XPath expression is converted to a boolean value using the standard XPath rules.
XPath式の結果は、標準のXPathルールを使用してブール値に変換されます。
Note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator on the device. The "when" statement can very well be implemented with specially written code.
XPath式は概念的に評価されることに注意してください。 これは、実装がデバイスでXPathエバリュエーターを使用する必要がないことを意味します。 「when」ステートメントは、特別に記述されたコードで非常にうまく実装できます。
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
reply to a <get> operation without a filter.
制約が状態データに定義されている場合、フィルターなしの<get>操作への応答でtrueでなければなりません。
Bjorklund Standards Track [Page 108]
RFC 6020 YANG October 2010
o If the constraint is defined on notification content, it MUST be
true in any notification instance.
制約が通知コンテンツで定義されている場合、どの通知インスタンスでもtrueでなければなりません。
o If the constraint is defined on RPC input parameters, it MUST be
true in an invocation of the RPC operation.
制約がRPC入力パラメーターで定義されている場合、RPC操作の呼び出しでtrueにする必要があります。
o If the constraint is defined on RPC output parameters, it MUST be
true in the RPC reply.
制約がRPC出力パラメーターで定義されている場合、RPC応答でtrueでなければなりません。
8.2. Hierarchy of Constraints
8.2。 制約の階層
Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device.
親ノードの条件は、ノード階層の自然な結果として子ノードの制約に影響します。 親ノードに「when」または「if-feature」プロパティが現在のデバイスで満たされていない場合、「必須」、「必須」、「min-elements」、および「max-elements」制約は適用されません。
In this example, the "mandatory" constraint on the "longitude" leaf are not enforced on devices that lack the "has-gps" feature:
この例では、「経度」リーフの「必須」制約は、「has-gps」機能を持たないデバイスには適用されません。
container location {
if-feature has-gps;
leaf longitude {
mandatory true;
...
}
}
8.3. Constraint Enforcement Model
8.3。 制約施行モデル
For configuration data, there are three windows when constraints MUST be enforced:
構成データの場合、制約を適用する必要があるのは3つのウィンドウです。
o during parsing of RPC payloads
RPCペイロードの解析中
o during processing of NETCONF operations
NETCONF操作の処理中
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 device implements.
コンテンツがRPCペイロードで到着するとき、それは、デバイスが実装するモデルのセットによって定義された階層とコンテンツルールに従って、整形式のXMLである必要があります。
Bjorklund Standards Track [Page 109]
RFC 6020 YANG October 2010
o If a leaf data value does not match the type constraints for the
leaf, including those defined in the type's "range", "length", and
"pattern" properties, the server MUST reply with an
"invalid-value" error-tag in the rpc-error, and with the error-
app-tag and error-message associated with the constraint, if any
exist.
タイプの「範囲」、「長さ」、および「パターン」プロパティで定義されたものを含む、リーフデータ値がリーフのタイプ制約に一致しない場合、サーバーは「無効な値」エラータグで応答する必要があります rpc-error、および存在する場合は、制約に関連付けられたerror-app-tagとerror-message
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」エラータグを付けて応答する必要があります。
o If data for more than one case branch of a choice is present, the
server MUST reply with a "bad-element" in the rpc-error.
選択の複数のcaseブランチのデータが存在する場合、サーバーはrpc-errorに「bad-element」で応答する必要があります。
o If data for a node tagged with "if-feature" is present, and the
feature is not supported by the device, the server MUST reply with
an "unknown-element" error-tag in the rpc-error.
「if-feature」でタグ付けされたノードのデータが存在し、その機能がデバイスでサポートされていない場合、サーバーはrpc-errorに「unknown-element」エラータグを付けて応答する必要があります。
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」エラータグで応答する必要があります。
o For insert handling, if the value for the attributes "before" and
"after" are not valid for the type of the appropriate key leafs,
the server MUST reply with a "bad-attribute" error-tag in the rpc-
error.
挿入処理の場合、「before」および「after」属性の値が適切なキーリーフのタイプに対して有効でない場合、サーバーはrpc-errorに「bad-attribute」エラータグを付けて応答する必要があります。
o If the attributes "before" and "after" appears in any element that
is not a list whose "ordered-by" property is "user", the server
MUST reply with an "unknown-attribute" error-tag in the rpc-error.
「before」と「after」の属性が、「ordered-by」プロパティが「user」であるリストではない要素にある場合、サーバーはrpc-errorに「unknown-attribute」エラータグで応答する必要があります 。
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」パラメータを含むリクエストを挿入します。
Bjorklund Standards Track [Page 110] RFC 6020 YANG October 2010 During <edit-config> processing:
<edit-config>処理中：
o If the NETCONF operation creates data nodes under a "choice", any
existing nodes from other "case" branches are deleted by the
server.
NETCONF操作が「choice」の下にデータノードを作成する場合、他の「case」ブランチからの既存のノードはサーバーによって削除されます。
o If the NETCONF operation modifies a data node such that any node's
"when" expression becomes false, then the node with the "when"
expression is deleted by the server.
NETCONF操作がデータノードを変更して、ノードの「when」式がfalseになるようにすると、「when」式を持つノードはサーバーによって削除されます。
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.
データストア処理が完了すると、最終的なコンテンツはすべての検証制約に従う必要があります。 この検証処理は、データストアに応じて異なるタイミングで実行されます。 データストアが<running />または<startup />の場合、これらの制約は<edit-config>または<copy-config>操作の最後に適用する必要があります。 データストアが<candidate />の場合、制約の適用は<commit>または<validate>操作まで遅延されます。
o Any "must" constraints MUST evaluate to "true".
「必須」の制約はすべて「true」に評価される必要があります。
o Any referential integrity constraints defined via the "path"
statement MUST be satisfied.
「パス」ステートメントを介して定義された参照整合性制約は満たされなければなりません（MUST）。
o Any "unique" constraints on lists MUST be satisfied.
リストに対する「一意の」制約は満たされなければなりません。
o The "min-elements" and "max-elements" constraints are enforced for
lists and leaf-lists.
「min-elements」および「max-elements」制約は、リストとリーフリストに適用されます。
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, derived from those built-in types or from other derived types. Derived types may use subtyping to formally restrict the set of possible values.
これらの組み込み型または他の派生型から派生した追加の型を定義できます。 派生型は、サブタイピングを使用して、可能な値のセットを正式に制限できます。
The different built-in types and their derived types allow different kinds of subtyping, namely length and regular expression restrictions of strings (Sections 9.4.4 and 9.4.6) and range restrictions of numeric types (Section 9.2.4).
さまざまな組み込み型とその派生型により、さまざまな種類のサブタイプ、つまり文字列の長さと正規表現の制限（セクション9.4.4および9.4.6）と数値型の範囲の制限（セクション9.2.4）が許可されます。
The lexical representation of a value of a certain type is used in the NETCONF messages and when specifying default values and numerical ranges in YANG modules.
特定のタイプの値の字句表現は、NETCONFメッセージで、およびYANGモジュールでデフォルト値と数値範囲を指定するときに使用されます。
Bjorklund Standards Track [Page 111] RFC 6020 YANG October 2010 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 NETCONF server sends data, it MUST be in the canonical form.
NETCONFサーバーがデータを送信するときは、正規の形式でなければなりません。
Some types have a lexical representation that depends on the XML context in which they occur. These types do not have a canonical form.
一部のタイプには、それらが発生するXMLコンテキストに依存する字句表現があります。 これらの型には、標準的な形式はありません。
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.
Bjorklund Standards Track [Page 112]
RFC 6020 YANG October 2010
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, which
represents the value in a hexadecimal or octal notation. The
hexadecimal notation consists of an optional sign ("+" or "-"), the
characters "0x" followed a number of hexadecimal digits, where
letters may be uppercase or lowercase. The octal notation consists
of an optional sign ("+" or "-"), the character "0" followed a number
of octal digits.
便宜上、YANGモジュールで整数のデフォルト値を指定する場合、16進または8進表記で値を表す代替の字句表現を使用できます。 16進表記は、オプションの符号（「+」または「-」）で構成され、文字「0x」の後にいくつかの16進数字が続きます。文字は大文字でも小文字でもかまいません。 8進表記は、オプションの符号（「+」または「-」）で構成され、文字「0」の後にいくつかの8進数字が続きます。
Note that if a default value in a YANG module has a leading zero
("0"), it is interpreted as an octal number. In the XML instance
documents, an integer is always interpreted as a decimal number, and
leading zeros are allowed.
YANGモジュールのデフォルト値に先行ゼロ（ "0"）がある場合、それは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
Bjorklund Standards Track [Page 113]
RFC 6020 YANG October 2010
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 those.
「範囲」ステートメントは、「タイプ」ステートメントのオプションのサブステートメントであり、引数として範囲式ストリングを受け取ります。 整数および10進数の組み込み型、またはそれらから派生した型を制限するために使用されます。
A range consists of an explicit value, or a lower-inclusive bound, two consecutive dots "..", and an upper-inclusive bound. Multiple values or ranges can be given, separated by "|". If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a range restriction is applied to an already range-restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. Each explicit value and range boundary value given in the range expression MUST match the type being restricted, or be one of the special values "min" or "max". "min" and "max" mean the minimum and maximum value accepted for the type being restricted, respectively.
範囲は、明示的な値、または下限を含む2つの連続するドットで構成されます ".. 、および上限を含む境界。 複数の値または範囲を「|」で区切って指定できます。 複数の値または範囲を指定する場合、それらはすべてばらばらである必要があり、昇順でなければなりません。 範囲制限がすでに範囲制限されているタイプに適用される場合、新しい制限は、それ以上の制限、つまり下限を上げる、上限を下げる、明示的な値または範囲を削除する、または中間で複数の範囲に範囲を分割する必要があります ギャップ。 範囲式で指定される各明示的な値と範囲境界値は、制限されるタイプと一致するか、特別な値「min」または「max」のいずれかである必要があります。 「min」と「max」は、制限されているタイプで受け入れられる最小値と最大値をそれぞれ意味します。
The range expression syntax is formally defined by the rule "range-arg" in Section 12.
範囲式の構文は、セクション12のルール「range-arg」によって正式に定義されています。
9.2.4.1. The range's Substatements
9.2.4.1。 範囲のサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
Bjorklund Standards Track [Page 114]
RFC 6020 YANG October 2010
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 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」として表現できます。ここで、iはinteger64で、nは整数です。 1から18まで。
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 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」と表されます。
Bjorklund Standards Track [Page 115] RFC 6020 YANG October 2010 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は小数桁の引数です。
The following table lists the minimum and maximum value for each fraction-digit value:
次の表は、各小数桁の値の最小値と最大値を示しています。
+----------------+-----------------------+----------------------+
| fraction-digit | min | max |
+----------------+-----------------------+----------------------+
| 1 | -922337203685477580.8 | 922337203685477580.7 |
| 2 | -92233720368547758.08 | 92233720368547758.07 |
| 3 | -9223372036854775.808 | 9223372036854775.807 |
| 4 | -922337203685477.5808 | 922337203685477.5807 |
| 5 | -92233720368547.75808 | 92233720368547.75807 |
| 6 | -9223372036854.775808 | 9223372036854.775807 |
| 7 | -922337203685.4775808 | 922337203685.4775807 |
| 8 | -92233720368.54775808 | 92233720368.54775807 |
| 9 | -9223372036.854775808 | 9223372036.854775807 |
| 10 | -922337203.6854775808 | 922337203.6854775807 |
| 11 | -92233720.36854775808 | 92233720.36854775807 |
| 12 | -9223372.036854775808 | 9223372.036854775807 |
| 13 | -922337.2036854775808 | 922337.2036854775807 |
| 14 | -92233.72036854775808 | 92233.72036854775807 |
| 15 | -9223.372036854775808 | 9223.372036854775807 |
| 16 | -922.3372036854775808 | 922.3372036854775807 |
| 17 | -92.23372036854775808 | 92.23372036854775807 |
| 18 | -9.223372036854775808 | 9.223372036854775807 |
+----------------+-----------------------+----------------------+
Bjorklund Standards Track [Page 116]
RFC 6020 YANG October 2010
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 tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]:
文字列組み込み型は、YANGで人間が読める文字列を表します。 有効な文字は、タブ、キャリッジリターン、ラインフィード、およびUnicodeとISO / IEC 10646 [ISO.10646]の有効な文字です。
;; any Unicode character, excluding the surrogate blocks,
;; FFFE, and FFFF.
string = *char
char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
%x10000-10FFFF
9.4.1. Lexical Representation
9.4.1。 字句表現
A string value is lexically represented as character data in the XML instance documents.
文字列値は、XMLインスタンスドキュメントでは字句的に文字データとして表されます。
9.4.2. Canonical Form
9.4.2。 正規形
The canonical form is the same as the lexical representation. No Unicode normalization is performed of string values.
正規形は字句表現と同じです。 文字列値の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.6) statements.
文字列は、 "length"（セクション9.4.4）および "pattern"（セクション9.4.6）ステートメントで制限できます。
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 type "string", or types derived from "string".
「type」ステートメントのオプションのサブステートメントである「length」ステートメントは、長さ式ストリングを引数として取ります。 組み込み型「string」、または「string」から派生した型を制限するために使用されます。
A "length" statement restricts the number of Unicode characters in the string.
「長さ」ステートメントは、文字列内のUnicode文字の数を制限します。
Bjorklund Standards Track [Page 117] RFC 6020 YANG October 2010 A length range consists of an explicit value, or a lower bound, two consecutive dots "..", and an upper bound. Multiple values or ranges can be given, separated by "|". Length-restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a length restriction is applied to an already length-restricted type, the new restriction MUST be equal or more limiting, that is, raising the lower bounds, reducing the upper bounds, removing explicit length values or ranges, or splitting ranges into multiple ranges with intermediate gaps. A length value is a non-negative integer, or one of the special values "min" or "max". "min" and "max" mean the minimum and maximum length accepted for the type being restricted, respectively. An implementation is not required to support a length value larger than 18446744073709551615.
長さの範囲は、明示的な値、または下限、2つの連続するドットで構成されます。 、および上限。 複数の値または範囲を「|」で区切って指定できます。 長さ制限値は負であってはなりません。 複数の値または範囲を指定する場合、それらはすべてばらばらである必要があり、昇順でなければなりません。 長さ制限がすでに長さ制限されているタイプに適用されている場合、新しい制限は同じかそれ以上の制限でなければなりません。つまり、下限を上げる、上限を下げる、明示的な長さの値または範囲を削除する、または範囲を複数の範囲に分割する 中間のギャップがあります。 長さの値は、負でない整数、または特別な値「min」または「max」のいずれかです。 「min」と「max」は、それぞれ制限されるタイプで受け入れられる最小と最大の長さを意味します。 18446744073709551615より大きい長さの値をサポートするための実装は必要ありません。
The length expression syntax is formally defined by the rule "length-arg" in Section 12.
長さ式の構文は、セクション12のルール「length-arg」によって正式に定義されています。
9.4.4.1. The length's Substatements
9.4.4.1。 長さのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
9.4.5. Usage Example
9.4.5。 使用例
typedef my-base-str-type {
type string {
length "1..255";
}
}
type my-base-str-type {
// legal length refinement
length "11 | 42..max"; // 11 | 42..255
}
type my-base-str-type {
// illegal length refinement
length "1..999";
}
Bjorklund Standards Track [Page 118]
RFC 6020 YANG October 2010
9.4.6. The pattern Statement
9.4.6。 パターンステートメント
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 an already pattern-restricted type, values must match all patterns in the base type, in addition to the new patterns.
パターン制限がすでにパターン制限されているタイプに適用されている場合、値は、新しいパターンに加えて、基本タイプのすべてのパターンと一致する必要があります。
9.4.6.1. The pattern's Substatements
9.4.6.1。 パターンのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
9.4.7. Usage Example
9.4.7。 使用例
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 119]
RFC 6020 YANG October 2010
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.
列挙値の字句表現は、割り当てられた名前の文字列です。
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 cannot be restricted.
列挙は制限できません。
9.6.4. The enum Statement
9.6.4。 enumステートメント
The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of Unicode control codes SHOULD be avoided.
タイプが「列挙」の場合、「タイプ」ステートメントのサブステートメントである「列挙」ステートメントが存在する必要があります。 これは、列挙型の割り当てられた各名前を指定するために繰り返し使用されます。 割り当てられた名前である文字列を引数として受け取ります。 文字列は空にしてはならず、先頭または末尾に空白文字があってはなりません。 Unicode制御コードの使用は避けてください。
The statement is optionally followed by a block of substatements that holds detailed enum information.
ステートメントの後には、オプションの詳細な列挙情報を保持するサブステートメントのブロックが続きます。
Bjorklund Standards Track [Page 120] RFC 6020 YANG October 2010 All assigned names in an enumeration MUST be unique.
列挙で割り当てられた名前はすべて一意である必要があります。
9.6.4.1. The enum's Substatements
9.6.4.1。 列挙型のサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+
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. The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.
オプションの「value」ステートメントは、整数値をenumに割り当てられた名前に関連付けるために使用されます。 この整数値は-2147483648～2147483647の範囲内である必要があり、列挙型内で一意である必要があります。 この値は、YANGおよびXMLエンコードでは使用されませんが、実装者の便宜のために提供されています。
If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value.
値が指定されていない場合は、自動的に割り当てられます。 「列挙型」サブステートメントが最初に定義されたものである場合、割り当てられる値はゼロ（0）です。 それ以外の場合、割り当てられる値は、現在の最も高い列挙値よりも1つ大きくなります。
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に等しい場合、現在の最高値を持つサブステートメントに続く「列挙型」サブステートメントに列挙値を指定する必要があります。
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 121]
RFC 6020 YANG October 2010
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から始まる小さな整数の位置番号によって識別されるフラグのセットです。 各ビット番号には名前が割り当てられています。
9.7.1. Restrictions
9.7.1。 制限事項
A bits type cannot be restricted.
ビットタイプは制限できません。
9.7.2. Lexical Representation
9.7.2。 字句表現
The lexical representation of the bits type is a space-separated list of the individual bit values that are set. An empty string thus represents a value where no bits are set.
ビットタイプの字句表現は、設定されている個々のビット値のスペース区切りリストです。 したがって、空の文字列は、ビットが設定されていない値を表します。
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を参照）。
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.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+
Bjorklund Standards Track [Page 122]
RFC 6020 YANG October 2010
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. The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors.
オプションの「position」ステートメントは、仮想ビットフィールド内のビットの位置を指定する負でない整数値を引数として取ります。 位置の値は0から4294967295の範囲でなければならず、ビットタイプ内で一意である必要があります。 この値は、YANGおよびNETCONFメッセージでは使用されませんが、実装者の便宜のために提供されています。
If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position.
ビット位置が指定されていない場合は、自動的に割り当てられます。 「ビット」サブステートメントが最初に定義されたものである場合、割り当てられる値はゼロ（0）です。 それ以外の場合、割り当てられる値は、現在の最上位ビット位置より1つ大きくなります。
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に等しい場合、現在の最高位置値を持つものに続く「ビット」サブステートメントに位置値を指定する必要があります。
9.7.5. Usage Example
9.7.5。 使用例
Given the following leaf:
次の葉を与えられます：
leaf mybits {
type bits {
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
bit 10-Mb-only {
position 2;
}
}
default "auto-sense-speed";
}
The lexical representation of this leaf with bit values disable-nagle
and 10-Mb-only set would be:
このリーフの字句表現は、ビット値がdisable-nagleで、10 Mbのみが設定されています。
<mybits>disable-nagle 10-Mb-only</mybits>
9.8. The binary Built-In Type
9.8。 バイナリ組み込みタイプ
The binary built-in type represents any binary data, i.e., a sequence of octets.
バイナリ組み込みタイプは、任意のバイナリデータ、つまりオクテットのシーケンスを表します。
Bjorklund Standards Track [Page 123] RFC 6020 YANG October 2010 9.8.1. Restrictions
9.8.1。 制限事項
A binary can be restricted with the "length" (Section 9.4.4) statement. The length of a binary value is the number of octets it contains.
バイナリは、 "length"（セクション9.4.4）ステートメントで制限できます。 バイナリ値の長さは、含まれるオクテットの数です。
9.8.2. Lexical Representation
9.8.2。 字句表現
Binary values are encoded with the base64 encoding scheme (see [RFC4648], Section 4).
バイナリ値は、base64エンコードスキームでエンコードされます（[RFC4648]、セクション4を参照）。
9.8.3. Canonical Form
9.8.3。 正規形
The canonical form of a binary value follows the rules in [RFC4648].
バイナリ値の正規形式は、[RFC4648]の規則に従います。
9.9. The leafref Built-In Type
9.9。 leafref組み込みタイプ
The leafref type is used to reference a particular leaf instance in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances.
leafrefタイプは、データツリー内の特定の葉インスタンスを参照するために使用されます。 「パス」サブステートメント（セクション9.9.2）は、リーフインスタンスのセットを選択し、leafref値スペースは、これらのリーフインスタンスの値のセットです。
If the leaf with the leafref type represents configuration data, the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All leafref nodes MUST reference existing leaf instances or leafs with default values in use (see Section 7.6.1) for the data to be valid. This constraint is enforced according to the rules in Section 8.
leafrefタイプのリーフが構成データを表す場合、それが参照するリーフも構成を表す必要があります。 このようなリーフは、有効なデータに制約を課します。 すべてのleafrefノードは、既存のリーフインスタンスまたは使用中のデフォルト値（7.6.1を参照）を持つリーフを参照して、データを有効にする必要があります。 この制約は、セクション8のルールに従って実施されます。
There MUST NOT be any circular chains of leafrefs.
葉参照の循環チェーンがあってはなりません。
If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.18.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features.
leafrefが参照するリーフが1つ以上の機能に基づいて条件付きである場合（セクション7.18.2を参照）、leafrefタイプのリーフも、少なくとも同じ機能セットに基づいて条件付きである必要があります。
9.9.1. Restrictions
9.9.1。 制限事項
A leafref cannot be restricted.
leafrefは制限できません。
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」の場合に存在する必要があります。 これは、リーフまたはリーフリストノードを参照する必要がある文字列を引数として受け取ります。
Bjorklund Standards Track [Page 124] RFC 6020 YANG October 2010 The syntax for a path argument is a subset of the XPath abbreviated syntax. Predicates are used only for constraining the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 12.
パス引数の構文は、XPath省略構文のサブセットです。 述語は、リストエントリのキーノードの値を制約するためにのみ使用されます。 各述語は、キーごとに正確に1つの等価テストで構成され、リストに複数のキーがある場合、複数の隣接する述語が存在する場合があります。 構文は、セクション12のルール「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 leaf with the leafref type represents configuration data, this node set MUST be non-empty.
「パス」式は、0、1、またはそれ以上のノードで構成されるノードセットに評価されます。 leafrefタイプのリーフが構成データを表す場合、このノードセットは空でない必要があります。
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 The context node is the node in the data tree for which the "path"
statement is defined.
コンテキストノードは、「パス」ステートメントが定義されているデータツリー内のノードです。
The accessible tree depends on the context node:
アクセス可能なツリーは、コンテキストノードによって異なります。
o If the context node represents configuration data, the tree is the
data in the NETCONF datastore where the context node exists. The
XPath root node has all top-level configuration data nodes in all
modules as children.
コンテキストノードが構成データを表す場合、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathルートノードには、すべてのモジュールのすべての最上位の構成データノードが子として含まれます。
o Otherwise, the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data
nodes in all modules as children.
それ以外の場合、ツリーはデバイス上のすべての状態データと<running />データストアです。 XPathルートノードには、すべてのモジュールのすべての最上位データノードが子として含まれます。
9.9.3. Lexical Representation
9.9.3。 字句表現
A leafref value is encoded the same way as the leaf it references.
leafref値は、参照する葉と同じ方法でエンコードされます。
9.9.4. Canonical Form
9.9.4。 正規形
The canonical form of a leafref is the same as the canonical form of the leaf it references.
leafrefの標準形は、参照する葉の標準形と同じです。
Bjorklund Standards Track [Page 125] RFC 6020 YANG October 2010 9.9.5. Usage Example
9.9.5。 使用例
With the following list:
次のリストで：
list interface {
key "name";
leaf name {
type string;
}
leaf admin-status {
type admin-status;
}
list address {
key "ip";
leaf ip {
type yang:ip-address;
}
}
}
The following leafref refers to an existing interface:
次のleafrefは既存のインターフェースを参照しています。
leaf mgmt-interface {
type leafref {
path "../interface/name";
}
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
</interface>
<interface>
<name>lo</name>
</interface>
<mgmt-interface>eth0</mgmt-interface>
Bjorklund Standards Track [Page 126]
RFC 6020 YANG October 2010
The following leafrefs refer to an existing address of an interface:
次のleafrefsは、インターフェースの既存のアドレスを参照します。
container default-address {
leaf ifname {
type leafref {
path "../../interface/name";
}
}
leaf address {
type leafref {
path "../../interface[name = current()/../ifname]"
+ "/address/ip";
}
}
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<address>
<ip>192.0.2.1</ip>
</address>
<address>
<ip>192.0.2.2</ip>
</address>
</interface>
<interface>
<name>lo</name>
<admin-status>up</admin-status>
<address>
<ip>127.0.0.1</ip>
</address>
</interface>
<default-address>
<ifname>eth0</ifname>
<address>192.0.2.2</address>
</default-address>
Bjorklund Standards Track [Page 127]
RFC 6020 YANG October 2010
The following list uses a leafref for one of its keys. This is
similar to a foreign key in a relational database.
次のリストでは、そのキーの1つにleafrefを使用しています。 これは、リレーショナルデータベースの外部キーに似ています。
list packet-filter {
key "if-name filter-id";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf filter-id {
type uint32;
}
...
}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<address>
<ip>192.0.2.1</ip>
</address>
<address>
<ip>192.0.2.2</ip>
</address>
</interface>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>1</filter-id>
...
</packet-filter>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>2</filter-id>
...
</packet-filter>
Bjorklund Standards Track [Page 128]
RFC 6020 YANG October 2010
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";
}
}
}
An example of a corresponding XML notification:
対応するXML通知の例：
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-04-01T00:01:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system">
<if-name>eth0</if-name>
<admin-status>up</admin-status>
</link-failure>
</notification>
9.10. The identityref Built-In Type
9.10。 identityref組み込み型
The identityref type is used to reference an existing identity (see Section 7.16).
identityrefタイプは、既存のIDを参照するために使用されます（セクション7.16を参照）。
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 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」の場合に存在する必要があります。 引数は、「identity」ステートメントで定義されているIDの名前です。 ID名にプレフィックスが存在する場合、そのプレフィックスは、そのプレフィックスを使用してインポートされたモジュールで定義されたIDを指します。 それ以外の場合、一致する名前のIDは、現在のモジュールまたは含まれているサブモジュールで定義する必要があります。
Bjorklund Standards Track [Page 129] RFC 6020 YANG October 2010 Valid values for an identityref are any identities derived from the identityref's base identity. On a particular server, the valid values are further restricted to the set of identities defined in the modules supported by the server.
identityrefの有効な値は、identityrefの基本IDから派生したIDです。 特定のサーバーでは、有効な値は、サーバーがサポートするモジュールで定義されている一連のIDにさらに制限されます。
9.10.3. Lexical Representation
9.10.3。 字句表現
An identityref is encoded as the referred identity's qualified name as defined in [XML-NAMES]. If the prefix is not present, the namespace of the identityref is the default namespace in effect on the element that contains the identityref value.
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. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule.
identityrefに「default」ステートメントを使用してデフォルト値を指定すると、デフォルト値のID名にプレフィックスが付いている場合があります。 ID名にプレフィックスが存在する場合、そのプレフィックスは、そのプレフィックスを使用してインポートされたモジュールで定義された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.16.3 and the following module:
セクション7.16.3のID定義と次のモジュールを使用します。
module my-crypto {
namespace "http://example.com/my-crypto";
prefix mc;
import "crypto-base" {
prefix "crypto";
}
identity aes {
base "crypto:crypto-alg";
}
leaf crypto {
type identityref {
base "crypto:crypto-alg";
}
}
}
Bjorklund Standards Track [Page 130]
RFC 6020 YANG October 2010
the leaf "crypto" will be encoded as follows, if the value is the
"des3" identity defined in the "des" module:
リーフ「crypto」は、値が「des」モジュールで定義された「des3」アイデンティティである場合、次のようにエンコードされます。
<crypto xmlns:des="http://example.com/des">des:des3</crypto>
Any prefixes used in the encoding are local to each instance
encoding. This means that the same identityref may be encoded
differently by different implementations. For example, the following
example encodes the same leaf as above:
エンコーディングで使用されるプレフィックスは、各インスタンスのエンコーディングに対してローカルです。 つまり、同じidentityrefは、実装によって異なる方法でエンコードされる可能性があります。 たとえば、次の例は上記と同じリーフをエンコードします。
<crypto xmlns:x="http://example.com/des">x:des3</crypto>
If the "crypto" leaf's value instead is "aes" defined in the
"my-crypto" module, it can be encoded as:
「crypto」リーフの値が「my-crypto」モジュールで定義された「aes」である場合は、次のようにエンコードできます。
<crypto xmlns:mc="http://example.com/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.
適用できません。
9.11.4. Usage Example
9.11.4。 使用例
The following leaf
次の葉
leaf enable-qos {
type empty;
}
Bjorklund Standards Track [Page 131]
RFC 6020 YANG October 2010
will be encoded as
としてエンコードされます
<enable-qos/>
if it exists.
存在する場合。
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 used to repeatedly specify each member type of the union. It takes as an argument a string that is the name of a member type.
タイプが「共用体」の場合、「タイプ」ステートメント（セクション7.4）が存在しなければなりません（MUST）。 ユニオンの各メンバータイプを繰り返し指定するために使用されます。 引数として、メンバー型の名前である文字列を受け取ります。
A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref".
メンバーの型は、組み込み型または派生型にすることができますが、組み込み型「空」または「リーフ参照」のいずれかであってはなりません。
When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the "type" statement, until a match is found.
共用体データ型を表す文字列が検証されると、一致が見つかるまで、「type」ステートメントで指定された順序で、各メンバー型に対して文字列が検証されます。
Any default value or "units" property defined in the member types is not inherited by the union type.
メンバタイプで定義されているデフォルト値または「ユニット」プロパティは、共用体タイプには継承されません。
Example:
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
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 132] RFC 6020 YANG October 2010 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.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 12. It is used to uniquely identify a node in the data tree. Predicates are used only for specifying the values for the key nodes for list entries, a value of a leaf-list entry, or a positional index for a list without keys. For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate.
instance-identifierの構文は、XPath省略構文のサブセットであり、セクション12のルール「instance-identifier」によって正式に定義されています。 データツリー内のノードを一意に識別するために使用されます。 述語は、リストエントリのキーノードの値、リーフリストエントリの値、またはキーのないリストの位置インデックスの指定にのみ使用されます。 キーでリストエントリを識別するために、各述語はキーごとに1つの等価テストで構成され、各キーには対応する述語が必要です。
If the leaf with the instance-identifier type represents configuration data, and the "require-instance" property (Section 9.13.2) is "true", the node it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All such leaf nodes MUST reference existing nodes or leaf nodes with their default value in use (see Section 7.6.1) for the data to be valid. This constraint is enforced according to the rules in Section 8.
instance-identifierタイプのリーフが構成データを表し、「require-instance」プロパティー（セクション9.13.2）が「true」の場合、参照するノードも構成を表す必要があります。 このようなリーフは、有効なデータに制約を課します。 そのようなすべてのリーフノードは、データが有効であるために、既存のノードまたは使用中のデフォルト値（セクション7.6.1を参照）を持つリーフノードを参照する必要があります。 この制約は、セクション8のルールに従って実施されます。
The "instance-identifier" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
「インスタンス識別子」XPath式は、セクション6.4.1の定義に加えて、次のコンテキストで概念的に評価されます。
o The context node is the root node in the accessible tree.
コンテキストノードは、アクセス可能なツリーのルートノードです。
The accessible tree depends on the leaf with the instance-identifier type:
アクセス可能なツリーは、インスタンス識別子タイプを持つリーフに依存します。
o If this leaf represents configuration data, the tree is the data
in the NETCONF datastore where the leaf exists. The XPath root
node has all top-level configuration data nodes in all modules as
children.
このリーフが構成データを表す場合、ツリーは、リーフが存在するNETCONFデータストア内のデータです。 XPathルートノードには、すべてのモジュールのすべての最上位の構成データノードが子として含まれます。
o Otherwise, the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data
nodes in all modules as children.
それ以外の場合、ツリーはデバイス上のすべての状態データと<running />データストアです。 XPathルートノードには、すべてのモジュールのすべての最上位データノードが子として含まれます。
Bjorklund Standards Track [Page 133] RFC 6020 YANG October 2010 9.13.1. Restrictions
9.13.1。 制限事項
An instance-identifier can be restricted with the "require-instance" statement (Section 9.13.2).
インスタンス識別子は、「require-instance」ステートメント（9.13.2項）で制限できます。
9.13.2. The require-instance Statement
9.13.2。 require-instanceステートメント
The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "instance-identifier". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true".
「type」ステートメントのサブステートメントである「require-instance」ステートメントは、タイプが「instance-identifier」の場合に存在する場合があります。 引数として文字列「true」または「false」を取ります。 このステートメントが存在しない場合、デフォルトで「true」に設定されます。
If "require-instance" is "true", it means that the instance being referred MUST exist for the data to be valid. This constraint is enforced according to the rules in Section 8.
「require-instance」が「true」の場合、データが有効であるためには、参照されているインスタンスが存在している必要があることを意味します。 この制約は、セクション8のルールに従って実施されます。
If "require-instance" is "false", it means that the instance being referred MAY exist in valid data.
「require-instance」が「false」の場合は、参照されているインスタンスが有効なデータに存在する可能性があることを意味します。
9.13.3. Lexical Representation
9.13.3。 字句表現
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.4. Canonical Form
9.13.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.13.5. Usage Example
9.13.5。 使用例
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']
Bjorklund Standards Track [Page 134]
RFC 6020 YANG October 2010
/* instance-identifier for a leaf in a list entry */
/ex:system/ex:user[ex:name='fred']/ex:type
/* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3]
10. Updating a Module
10.モジュールの更新
As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
モジュールの経験が得られたら、そのモジュールを修正することが望ましい場合があります。 ただし、元の仕様を使用するクライアントと更新された仕様を使用するサーバーの間で相互運用性の問題を引き起こす可能性がある場合、変更は許可されません。
For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. If there are no existing "revision" statements, then one MUST be added to identify the new revision. Furthermore, any necessary changes MUST be applied to any meta-data statements, including the "organization" and "contact" statements (Sections 7.1.7, 7.1.8).
公開された変更については、新しい「改訂」ステートメント（セクション7.1.9）を既存の「改訂」ステートメントの前に含める必要があります。 既存の「改訂」ステートメントがない場合は、新しい改訂を識別するために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 modules since their identifiers may still be referenced by other modules.
識別子はまだ他のモジュールから参照されている可能性があるため、廃止された定義をモジュールから削除してはなりません。
A definition may be revised in any of the following ways:
定義は、次のいずれかの方法で変更できます。
o An "enumeration" type may have new enums added, provided the old
enums's values do not change.
「列挙型」タイプには、古い列挙型の値が変更されない限り、新しい列挙型が追加される場合があります。
o A "bits" type may have new bits added, provided the old bit
positions do not change.
「ビット」タイプには、古いビット位置が変更されない限り、新しいビットが追加される場合があります。
o A "range", "length", or "pattern" statement may expand the allowed
value space.
「範囲」、「長さ」、または「パターン」ステートメントは、許容値スペースを拡張する場合があります。
Bjorklund Standards Track [Page 135]
RFC 6020 YANG October 2010
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 "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 clarified without
changing the semantics of the definition.
定義のセマンティクスを変更せずに、「説明」ステートメントを追加または明確化できます。
o New typedefs, groupings, rpcs, notifications, extensions,
features, and identities may be added.
新しいtypedef、グループ、rpcs、通知、拡張機能、機能、およびIDが追加される場合があります。
o New data definition statements may be added if they do not add
mandatory nodes (Section 3.1) to existing nodes or at the top
level in a module or submodule, or if they are conditionally
dependent on a new feature (i.e., have an "if-feature" statement
that refers to a new feature).
新しいデータ定義ステートメントは、必須ノード（セクション3.1）を既存のノードに追加しない場合、またはモジュールやサブモジュールの最上位に追加しない場合、または条件付きで新しい機能に依存している場合（つまり、「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.1).
状態データを表すノードは、必須ではない場合（セクション3.1）、構成を表すように変更できます。
o An "if-feature" statement may be removed, provided its node is not
mandatory (Section 3.1).
「if-feature」ステートメントは、そのノードが必須ではない場合に削除できます（セクション3.1）。
o A "status" statement may be added, or changed from "current" to
"deprecated" or "obsolete", or from "deprecated" to "obsolete".
「status」ステートメントが追加、または「current」から「deprecated」または「obsolete」、または「deprecated」から「obsolete」に変更される場合があります。
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で置き換えることはできません。
Bjorklund Standards Track [Page 136]
RFC 6020 YANG October 2010
o Any set of data definition nodes may be replaced with another set
of syntactically and semantically equivalent nodes. For example,
a set of leafs may be replaced by a uses of a grouping with the
same leafs.
データ定義ノードのセットは、構文的および意味的に等価な別のノードのセットで置き換えることができます。 例えば、葉のセットは、同じ葉を持つグループの使用に置き換えることができます。
o A module may be split into a set of submodules, or a submodule may
be removed, provided the definitions in the module do not change
in any other way than allowed here.
モジュール内の定義がここで許可されている以外の方法で変更されない場合は、モジュールをサブモジュールのセットに分割するか、サブモジュールを削除できます。
o The "prefix" statement may be changed, provided all local uses of
the prefix also are 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.
サブステートメントとしてデータ定義ステートメントを含むステートメントでは、それらのデータ定義サブステートメントを並べ替えてはなりません（MUST NOT）。
11. YIN
11. 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 symmetric mapping rules between the two formats.
YANGモジュールは、YINと呼ばれる代替のXMLベースの構文に変換できます。 翻訳されたモジュールはYINモジュールと呼ばれます。 このセクションでは、2つのフォーマット間の対称マッピングルールについて説明します。
The YANG and YIN formats contain equivalent information using different notations. The YIN notation enables developers to represent YANG data models in XML and therefore use the rich set of XML-based tools for data filtering and validation, automated generation of code and documentation, and other tasks. Tools like XSLT or XML validators can be utilized.
YANGおよびYIN形式には、異なる表記法を使用した同等の情報が含まれています。 YIN表記を使用すると、開発者は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の間のマッピングは、モデルの情報コンテンツを変更しません。 コメントと空白は保持されません。
11.1. Formal YIN Definition
11.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」であるネームスペースに属しています。
Bjorklund Standards Track [Page 137] RFC 6020 YANG October 2010 YIN elements corresponding to extension keywords belong to the namespace of the YANG module where the extension keyword is declared via the "extension" statement.
拡張キーワードに対応するYIN要素は、「拡張」ステートメントを介して拡張キーワードが宣言されているYANGモジュールの名前空間に属しています。
The names of all YIN elements MUST be properly qualified with their namespaces specified above using the standard mechanisms of [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes.
すべてのYIN要素の名前は、[XML-NAMES]の標準メカニズム、つまり「xmlns」属性と「xmlns：xxx」属性を使用して、上で指定した名前空間で適切に修飾する必要があります。
The argument of a YANG statement is represented in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the mapping for the set of YANG keywords. For extensions, the argument mapping is specified within the "extension" statement (see Section 7.17). The following rules hold for arguments:
YANGステートメントの引数は、XML属性またはキーワード要素のサブ要素としてYINで表されます。 表1は、YANGキーワードのセットのマッピングを定義しています。 拡張の場合、引数マッピングは「拡張」ステートメント内で指定されます（7.17節を参照）。 引数には次の規則が適用されます。
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 138]
RFC 6020 YANG October 2010
Mapping of arguments of the YANG statements.
YANGステートメントの引数のマッピング。
+------------------+---------------+-------------+
| keyword | argument name | yin-element |
+------------------+---------------+-------------+
| anyxml | name | false |
| argument | name | false |
| augment | target-node | false |
| base | name | false |
| belongs-to | module | false |
| bit | name | false |
| case | name | false |
| choice | name | false |
| config | value | false |
| contact | text | true |
| container | name | false |
| default | value | false |
| description | text | true |
| deviate | value | false |
| deviation | target-node | false |
| enum | name | false |
| error-app-tag | value | false |
| error-message | value | true |
| extension | name | false |
| feature | name | false |
| fraction-digits | value | false |
| grouping | name | false |
| identity | name | false |
| if-feature | name | false |
| import | module | false |
| include | module | false |
| input | <no argument> | n/a |
| key | value | false |
| leaf | name | false |
| leaf-list | name | false |
| length | value | false |
| list | name | false |
| mandatory | value | false |
| max-elements | value | false |
| min-elements | value | false |
| module | name | false |
| must | condition | false |
| namespace | uri | false |
| notification | name | false |
| ordered-by | value | false |
| organization | text | true |
| output | <no argument> | n/a |
| path | value | false |
Bjorklund Standards Track [Page 139]
RFC 6020 YANG October 2010
| 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
Bjorklund Standards Track [Page 140]
RFC 6020 YANG October 2010
11.1.1. Usage Example
11.1.1。 使用例
The following YANG module:
次のYANGモジュール：
module acme-foo {
namespace "http://acme.example.com/foo";
prefix "acfoo";
import my-extensions {
prefix "myext";
}
list interface {
key "name";
leaf name {
type string;
}
leaf mtu {
type uint32;
description "The MTU of the interface.";
myext:c-define "MY_MTU";
}
}
}
where the extension "c-define" is defined in Section 7.17.3, is
translated into the following YIN:
拡張「c-define」はセクション7.17.3で定義されており、次のYINに変換されます。
Bjorklund Standards Track [Page 141]
RFC 6020 YANG October 2010
<module name="acme-foo"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:acfoo="http://acme.example.com/foo"
xmlns:myext="http://example.com/my-extensions">
<namespace uri="http://acme.example.com/foo"/>
<prefix value="acfoo"/>
<import module="my-extensions">
<prefix value="myext"/>
</import>
<list name="interface">
<key value="name"/>
<leaf name="name">
<type name="string"/>
</leaf>
<leaf name="mtu">
<type name="uint32"/>
<description>
<text>The MTU of the interface.</text>
</description>
<myext:c-define name="MY_MTU"/>
</leaf>
</list>
</module>
Bjorklund Standards Track [Page 142]
RFC 6020 YANG October 2010
12. YANG ABNF Grammar
12. YANG ABNF文法
In YANG, almost all statements are unordered. The ABNF grammar [RFC5234] defines the canonical order. To improve module readability, it is RECOMMENDED that clauses be entered in this order.
YANGでは、ほとんどすべてのステートメントは順不同です。 ABNF文法[RFC5234]は標準的な順序を定義します。 モジュールを読みやすくするために、句はこの順序で入力することをお勧めします。
Within the ABNF grammar, unordered statements are marked with comments.
ABNF文法では、順序付けられていないステートメントはコメントでマークされます。
This grammar assumes that the scanner replaces YANG comments with a single space character.
この文法は、スキャナーがYANGコメントを単一のスペース文字で置き換えることを前提としています。
<CODE BEGINS> file "yang.abnf"
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 stmtsep]
namespace-stmt stmtsep
prefix-stmt stmtsep
submodule-header-stmts =
;; these stmts can appear in any order
[yang-version-stmt stmtsep]
belongs-to-stmt stmtsep
Bjorklund Standards Track [Page 143]
RFC 6020 YANG October 2010
meta-stmts = ;; these stmts can appear in any order
[organization-stmt stmtsep]
[contact-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep)
*(include-stmt stmtsep)
revision-stmts = *(revision-stmt stmtsep)
body-stmts = *((extension-stmt /
feature-stmt /
identity-stmt /
typedef-stmt /
grouping-stmt /
data-def-stmt /
augment-stmt /
rpc-stmt /
notification-stmt /
deviation-stmt) stmtsep)
data-def-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
choice-stmt /
anyxml-stmt /
uses-stmt
yang-version-stmt = yang-version-keyword sep yang-version-arg-str
optsep stmtend
yang-version-arg-str = < a string that matches the rule
yang-version-arg >
yang-version-arg = "1"
import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep
prefix-stmt stmtsep
[revision-date-stmt stmtsep]
"}"
Bjorklund Standards Track [Page 144]
RFC 6020 YANG October 2010
include-stmt = include-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
[revision-date-stmt stmtsep]
"}")
namespace-stmt = namespace-keyword sep uri-str optsep stmtend
uri-str = < a string that matches the rule
URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str
optsep stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
optsep
"{" stmtsep
prefix-stmt stmtsep
"}"
organization-stmt = organization-keyword sep string
optsep stmtend
contact-stmt = contact-keyword sep string optsep stmtend
description-stmt = description-keyword sep string optsep
stmtend
reference-stmt = reference-keyword sep string optsep stmtend
units-stmt = units-keyword sep string optsep stmtend
revision-stmt = revision-keyword sep revision-date optsep
(";" /
"{" stmtsep
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
revision-date = date-arg-str
revision-date-stmt = revision-date-keyword sep revision-date stmtend
Bjorklund Standards Track [Page 145]
RFC 6020 YANG October 2010
extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[argument-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
argument-stmt = argument-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
[yin-element-stmt stmtsep]
"}")
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
[base-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
base-stmt = base-keyword sep identifier-ref-arg-str
optsep stmtend
feature-stmt = feature-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
Bjorklund Standards Track [Page 146]
RFC 6020 YANG October 2010
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str
optsep stmtend
typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
type-stmt stmtsep
[units-stmt stmtsep]
[default-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
type-body-stmts
"}")
type-body-stmts = numerical-restrictions /
decimal64-specification /
string-restrictions /
enum-specification /
leafref-specification /
identityref-specification /
instance-identifier-specification /
bits-specification /
union-specification
numerical-restrictions = range-stmt stmtsep
range-stmt = range-keyword sep range-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
decimal64-specification = fraction-digits-stmt
fraction-digits-stmt = fraction-digits-keyword sep
fraction-digits-arg-str stmtend
Bjorklund Standards Track [Page 147]
RFC 6020 YANG October 2010
fraction-digits-arg-str = < a string that matches the rule
fraction-digits-arg >
fraction-digits-arg = ("1" ["0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8"])
/ "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
string-restrictions = ;; these stmts can appear in any order
[length-stmt stmtsep]
*(pattern-stmt stmtsep)
length-stmt = length-keyword sep length-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
pattern-stmt = pattern-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
default-stmt = default-keyword sep string stmtend
enum-specification = 1*(enum-stmt stmtsep)
enum-stmt = enum-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[value-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
Bjorklund Standards Track [Page 148]
RFC 6020 YANG October 2010
leafref-specification =
;; these stmts can appear in any order
path-stmt stmtsep
[require-instance-stmt stmtsep]
path-stmt = path-keyword sep path-arg-str stmtend
require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend
require-instance-arg-str = < a string that matches the rule
require-instance-arg >
require-instance-arg = true-keyword / false-keyword
instance-identifier-specification =
[require-instance-stmt stmtsep]
identityref-specification =
base-stmt stmtsep
union-specification = 1*(type-stmt stmtsep)
bits-specification = 1*(bit-stmt stmtsep)
bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[position-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
"}")
position-stmt = position-keyword sep
position-value-arg-str stmtend
position-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
Bjorklund Standards Track [Page 149]
RFC 6020 YANG October 2010
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
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 stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
error-message-stmt = error-message-keyword sep string stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend
Bjorklund Standards Track [Page 150]
RFC 6020 YANG October 2010
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
value-stmt = value-keyword sep integer-value stmtend
grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
container-stmt = container-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
Bjorklund Standards Track [Page 151]
RFC 6020 YANG October 2010
leaf-stmt = leaf-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
list-stmt = list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[key-stmt stmtsep]
*(unique-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
Bjorklund Standards Track [Page 152]
RFC 6020 YANG October 2010
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
key-stmt = key-keyword sep key-arg-str stmtend
key-arg-str = < a string that matches the rule
key-arg >
key-arg = node-identifier *(sep node-identifier)
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)
choice-stmt = choice-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((short-case-stmt / case-stmt) stmtsep)
"}")
short-case-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
anyxml-stmt
case-stmt = case-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
Bjorklund Standards Track [Page 153]
RFC 6020 YANG October 2010
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(data-def-stmt stmtsep)
"}")
anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
uses-stmt = uses-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(refine-stmt stmtsep)
*(uses-augment-stmt stmtsep)
"}")
refine-stmt = refine-keyword sep refine-arg-str optsep
(";" /
"{" stmtsep
(refine-container-stmts /
refine-leaf-stmts /
refine-leaf-list-stmts /
refine-list-stmts /
refine-choice-stmts /
refine-case-stmts /
refine-anyxml-stmts)
"}")
refine-arg-str = < a string that matches the rule
refine-arg >
refine-arg = descendant-schema-nodeid
Bjorklund Standards Track [Page 154]
RFC 6020 YANG October 2010
refine-container-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-leaf-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-leaf-list-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-list-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-choice-stmts = ;; these stmts can appear in any order
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-case-stmts = ;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-anyxml-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
Bjorklund Standards Track [Page 155]
RFC 6020 YANG October 2010
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
uses-augment-arg-str = < a string that matches the rule
uses-augment-arg >
uses-augment-arg = descendant-schema-nodeid
augment-stmt = augment-keyword sep augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
augment-arg-str = < a string that matches the rule
augment-arg >
augment-arg = absolute-schema-nodeid
unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}")
unknown-statement2 = [prefix ":"] identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}")
when-stmt = when-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
Bjorklund Standards Track [Page 156]
RFC 6020 YANG October 2010
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
[input-stmt stmtsep]
[output-stmt stmtsep]
"}")
input-stmt = input-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
output-stmt = output-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
notification-stmt = notification-keyword sep
identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")
Bjorklund Standards Track [Page 157]
RFC 6020 YANG October 2010
deviation-stmt = deviation-keyword sep
deviation-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]
(deviate-not-supported-stmt /
1*(deviate-add-stmt /
deviate-replace-stmt /
deviate-delete-stmt))
"}"
deviation-arg-str = < a string that matches the rule
deviation-arg >
deviation-arg = absolute-schema-nodeid
deviate-not-supported-stmt =
deviate-keyword sep
not-supported-keyword optsep
(";" /
"{" stmtsep
"}")
deviate-add-stmt = deviate-keyword sep add-keyword optsep
(";" /
"{" stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")
deviate-delete-stmt = deviate-keyword sep delete-keyword optsep
(";" /
"{" stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
"}")
Bjorklund Standards Track [Page 158]
RFC 6020 YANG October 2010
deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
(";" /
"{" stmtsep
[type-stmt stmtsep]
[units-stmt stmtsep]
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")
;; Ranges
range-arg-str = < a string that matches the rule
range-arg >
range-arg = range-part *(optsep "|" optsep range-part)
range-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
Bjorklund Standards Track [Page 159]
RFC 6020 YANG October 2010
;; Schema Node Identifiers
schema-nodeid = absolute-schema-nodeid /
descendant-schema-nodeid
absolute-schema-nodeid = 1*("/" node-identifier)
descendant-schema-nodeid =
node-identifier
absolute-schema-nodeid
node-identifier = [prefix ":"] identifier
;; Instance Identifiers
instance-identifier = 1*("/" (node-identifier *predicate))
predicate = "[" *WSP (predicate-expr / pos) *WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP
((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE))
pos = non-negative-integer-value
;; leafref path
path-arg-str = < a string that matches the rule
path-arg >
path-arg = absolute-path / relative-path
absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*(".." "/") descendant-path
descendant-path = node-identifier
[*path-predicate absolute-path]
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 160]
RFC 6020 YANG October 2010
rel-path-keyexpr = 1*(".." *WSP "/" *WSP)
*(node-identifier *WSP "/" *WSP)
node-identifier
;;; Keywords, using abnfgen's syntax for case-sensitive strings
;; statement keywords
anyxml-keyword = 'anyxml'
argument-keyword = 'argument'
augment-keyword = 'augment'
base-keyword = 'base'
belongs-to-keyword = 'belongs-to'
bit-keyword = 'bit'
case-keyword = 'case'
choice-keyword = 'choice'
config-keyword = 'config'
contact-keyword = 'contact'
container-keyword = 'container'
default-keyword = 'default'
description-keyword = 'description'
enum-keyword = 'enum'
error-app-tag-keyword = 'error-app-tag'
error-message-keyword = 'error-message'
extension-keyword = 'extension'
deviation-keyword = 'deviation'
deviate-keyword = 'deviate'
feature-keyword = 'feature'
fraction-digits-keyword = 'fraction-digits'
grouping-keyword = 'grouping'
identity-keyword = 'identity'
if-feature-keyword = 'if-feature'
import-keyword = 'import'
include-keyword = 'include'
input-keyword = 'input'
key-keyword = 'key'
leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list'
length-keyword = 'length'
list-keyword = 'list'
mandatory-keyword = 'mandatory'
max-elements-keyword = 'max-elements'
min-elements-keyword = 'min-elements'
module-keyword = 'module'
must-keyword = 'must'
namespace-keyword = 'namespace'
notification-keyword= 'notification'
ordered-by-keyword = 'ordered-by'
organization-keyword= 'organization'
Bjorklund Standards Track [Page 161]
RFC 6020 YANG October 2010
output-keyword = 'output'
path-keyword = 'path'
pattern-keyword = 'pattern'
position-keyword = 'position'
prefix-keyword = 'prefix'
presence-keyword = 'presence'
range-keyword = 'range'
reference-keyword = 'reference'
refine-keyword = 'refine'
require-instance-keyword = 'require-instance'
revision-keyword = 'revision'
revision-date-keyword = 'revision-date'
rpc-keyword = 'rpc'
status-keyword = 'status'
submodule-keyword = 'submodule'
type-keyword = 'type'
typedef-keyword = 'typedef'
unique-keyword = 'unique'
units-keyword = 'units'
uses-keyword = 'uses'
value-keyword = 'value'
when-keyword = 'when'
yang-version-keyword= 'yang-version'
yin-element-keyword = 'yin-element'
;; other keywords
add-keyword = 'add'
current-keyword = 'current'
delete-keyword = 'delete'
deprecated-keyword = 'deprecated'
false-keyword = 'false'
max-keyword = 'max'
min-keyword = 'min'
not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete'
replace-keyword = 'replace'
system-keyword = 'system'
true-keyword = 'true'
unbounded-keyword = 'unbounded'
user-keyword = 'user'
Bjorklund Standards Track [Page 162]
RFC 6020 YANG October 2010
current-function-invocation = current-keyword *WSP "(" *WSP ")"
;; Basic Rules
prefix-arg-str = < a string that matches the rule
prefix-arg >
prefix-arg = prefix
prefix = identifier
identifier-arg-str = < a string that matches the rule
identifier-arg >
identifier-arg = identifier
;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string that matches the rule
identifier-ref-arg >
identifier-ref-arg = [prefix ":"] identifier
string = < an unquoted string as returned by
the scanner >
integer-value = ("-" non-negative-integer-value) /
non-negative-integer-value
non-negative-integer-value = "0" / positive-integer-value
positive-integer-value = (non-zero-digit *DIGIT)
zero-integer-value = 1*DIGIT
stmtend = ";" / "{" *unknown-statement "}"
sep = 1*(WSP / line-break)
; unconditional separator
optsep = *(WSP / line-break)
stmtsep = *(WSP / line-break / unknown-statement)
line-break = CRLF / LF
Bjorklund Standards Track [Page 163]
RFC 6020 YANG October 2010
non-zero-digit = %x31-39
decimal-value = integer-value ("." zero-integer-value)
SQUOTE = %x27
; ' (Single Quote)
;;
;; RFC 5234 core rules.
;;
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard new line
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
; only lower-case a..f
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
SP = %x20
; space
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB
; whitespace
<CODE ENDS>
Bjorklund Standards Track [Page 164]
RFC 6020 YANG October 2010
13. Error Responses for YANG Related Errors
13. YANG関連エラーのエラー応答
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」サブステートメントがある場合、それは以下で指定されたデフォルト値をオーバーライドします。
13.1. Error Message for Data That Violates a unique Statement
13.1。 一意のステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned:
NETCONF操作の結果、一意の制約が無効になる構成データが生成される場合、次のエラーが返されます。
error-tag: operation-failed
error-app-tag: data-not-unique
error-info: <non-unique>: Contains an instance identifier that
points to a leaf that invalidates the unique
constraint. This element is present once for each
non-unique leaf.
The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1").
13.2. Error Message for Data That Violates a max-elements Statement
13.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 is returned:
NETCONF操作の結果、リストまたはリーフリストのエントリが多すぎる構成データが生成される場合、次のエラーが返されます。
error-tag: operation-failed
error-app-tag: too-many-elements
This error is returned once, with the error-path identifying the list
node, even if there are more than one extra child present.
複数の余分な子が存在する場合でも、このエラーは1回返され、エラーパスはリストノードを識別します。
13.3. Error Message for Data That Violates a min-elements Statement
13.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 is returned:
NETCONF操作の結果、構成データがリストまたはリーフリストに含まれるエントリが少なすぎる場合、次のエラーが返されます。
error-tag: operation-failed
error-app-tag: too-few-elements
This error is returned once, with the error-path identifying the list
node, even if there are more than one child missing.
複数の子が欠落している場合でも、このエラーは1回返され、エラーパスはリストノードを識別します。
Bjorklund Standards Track [Page 165] RFC 6020 YANG October 2010 13.4. Error Message for Data That Violates a must Statement
13.4。 mustステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where the restrictions imposed by a "must" statement is violated the following error is returned, unless a specific "error-app-tag" substatement is present for the "must" statement.
NETCONF操作の結果、「必須」ステートメントによって課された制限に違反する構成データが生成される場合、「必須」ステートメントに特定の「error-app-tag」サブステートメントが存在しない限り、次のエラーが返されます。
error-tag: operation-failed
error-app-tag: must-violation
13.5. Error Message for Data That Violates a require-instance Statement
13.5。 require-instanceステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a leaf of type "instance-identifier" marked with require-instance "true" refers to a non-existing instance, the following error is returned:
NETCONF操作の結果、「instance-identifier」タイプのリーフがrequire-instance「true」でマークされているリーフが存在しないインスタンスを参照している場合、次のエラーが返されます。
error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the instance-identifier leaf.
13.6. Error Message for Data That Does Not Match a leafref Type
13.6。 leafrefタイプと一致しないデータのエラーメッセージ
If a NETCONF operation would result in configuration data where a leaf of type "leafref" refers to a non-existing instance, the following error is returned:
NETCONF操作の結果、タイプ「leafref」のリーフが存在しないインスタンスを参照する構成データになる場合、次のエラーが返されます。
error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the leafref leaf.
13.7. Error Message for Data That Violates a mandatory choice Statement
13.7。 必須選択ステートメントに違反するデータのエラーメッセージ
If a NETCONF operation would result in configuration data where no nodes exists in a mandatory choice, the following error is returned:
NETCONF操作の結果、必須の選択肢にノードが存在しない構成データになる場合、次のエラーが返されます。
error-tag: data-missing
error-app-tag: missing-choice
error-path: Path to the element with the missing choice.
error-info: <missing-choice>: Contains the name of the missing
mandatory choice.
The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1").
Bjorklund Standards Track [Page 166]
RFC 6020 YANG October 2010
13.8. Error Message for the "insert" Operation
13.8。 「挿入」操作のエラーメッセージ
If the "insert" and "key" or "value" attributes are used in an <edit-config> for a list or leaf-list node, and the "key" or "value" refers to a non-existing instance, the following error is returned:
「挿入」および「キー」または「値」属性がリストまたはリーフリストノードの<edit-config>で使用され、「キー」または「値」が存在しないインスタンスを参照している場合、 次のエラーが返されます：
error-tag: bad-attribute
error-app-tag: missing-instance
14. IANA Considerations
14. IANAに関する考慮事項
This document defines a registry for YANG module and submodule names. The name of the registry is "YANG Module Names".
このドキュメントでは、YANGモジュールとサブモジュール名のレジストリを定義しています。 レジストリの名前は「YANG Module Names」です。
The registry shall record for each entry:
レジストリは、エントリごとに記録します。
o the name of the module or submodule
モジュールまたはサブモジュールの名前
o for modules, the assigned XML namespace
モジュールの場合、割り当てられたXML名前空間
o for modules, the prefix of the module
モジュールの場合、モジュールの接頭辞
o for submodules, the name of the module it belongs to
サブモジュールの場合、それが属するモジュールの名前
o a reference to the (sub)module's documentation (e.g., the RFC
number)
（サブ）モジュールのドキュメントへの参照（RFC番号など）
There are no initial assignments.
最初の割り当てはありません。
For allocation, RFC publication is required as per RFC 5226 [RFC5226]. All registered YANG module names MUST comply with the rules for identifiers stated in Section 6.2, and MUST have a module name prefix.
割り当てには、RFC 5226 [RFC5226]に従ってRFCの公開が必要です。 登録されているすべてのYANGモジュール名は、セクション6.2に記載されている識別子の規則に準拠している必要があり、モジュール名の接頭辞が必要です。
The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844], while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams MUST have a similar suitable prefix.
モジュール名の接頭辞「ietf-」はIETFストリームドキュメント[RFC4844]用に予約されていますが、モジュール名の接頭辞「irtf-」はIRTFストリームドキュメント用に予約されています。 他のRFCストリームで公開されたモジュールには、同様の適切なプレフィックスが必要です。
All module and submodule names in the registry MUST be unique.
レジストリ内のすべてのモジュールとサブモジュールの名前は一意である必要があります。
All XML namespaces in the registry MUST be unique.
レジストリ内のすべてのXML名前空間は一意である必要があります。
This document registers two URIs for the YANG and YIN XML namespaces in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following have been registered.
このドキュメントは、IETF XMLレジストリ[RFC3688]にYANGおよびYIN XML名前空間の2つのURIを登録します。 RFC 3688のフォーマットに従い、以下が登録されています。
URI: urn:ietf:params:xml:ns:yang:yin:1
Bjorklund Standards Track [Page 167]
RFC 6020 YANG October 2010
URI: urn:ietf:params:xml:ns:yang:1
Registrant Contact: The IESG.
XML: N/A, the requested URIs are XML namespaces.
This document registers two new media types as defined in the
following sections.
このドキュメントでは、次のセクションで定義されている2つの新しいメディアタイプを登録します。
14.1. Media type application/yang
14.1。 メディアタイプアプリケーション/ヤン
MIME media type name: application
MIME subtype name: yang
Mandatory parameters: none
Optional parameters: none
Encoding considerations: 8-bit
Security considerations: See Section 15 in RFC 6020
Interoperability considerations: None
Published specification: RFC 6020
Applications that use this media type:
YANG module validators, web servers used for downloading YANG
modules, email clients, etc.
Additional information:
Magic Number: None
File Extension: .yang
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Martin Bjorklund <mbj@tail-f.com>
Intended usage: COMMON
Author:
This specification is a work item of the IETF NETMOD working group,
with mailing list address <netmod@ietf.org>.
Bjorklund Standards Track [Page 168]
RFC 6020 YANG October 2010
Change controller:
The IESG <iesg@ietf.org>
14.2. Media type application/yin+xml
14.2。 メディアタイプapplication / yin + xml
MIME media type name: application
MIME subtype name: yin+xml
Mandatory parameters: none
Optional parameters:
"charset": This parameter has identical semantics to the charset
parameter of the "application/xml" media type as specified in
[RFC3023].
Encoding considerations:
Identical to those of "application/xml" as
described in [RFC3023], Section 3.2.
Security considerations: See Section 15 in RFC 6020
Interoperability considerations: None
Published specification: RFC 6020
Applications that use this media type:
YANG module validators, web servers used for downloading YANG
modules, email clients, etc.
Additional information:
Magic Number: As specified for "application/xml" in [RFC3023],
Section 3.2.
File Extension: .yin
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Martin Bjorklund <mbj@tail-f.com>
Intended usage: COMMON
Bjorklund Standards Track [Page 169]
RFC 6020 YANG October 2010
Author:
This specification is a work item of the IETF NETMOD working group,
with mailing list address <netmod@ietf.org>.
Change controller:
The IESG <iesg@ietf.org>
15. Security Considerations
15.セキュリティに関する考慮事項
This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
このドキュメントでは、管理情報の説明を読み書きするための言語を定義します。 言語自体がインターネットにセキュリティ上の影響を与えることはありません。
The same considerations are relevant as for the base NETCONF protocol (see [RFC4741], Section 9).
基本的なNETCONFプロトコルと同じ考慮事項が関連しています（[RFC4741]、セクション9を参照）。
Data modeled in YANG might contain sensitive information. RPCs or notifications defined in YANG might transfer sensitive information.
YANGでモデル化されたデータには機密情報が含まれている可能性があります。 YANGで定義されたRPCまたは通知は、機密情報を転送する可能性があります。
Security issues are related to the usage of data modeled in YANG. Such issues shall be dealt with in documents describing the data models and documents about the interfaces used to manipulate the data e.g., the NETCONF documents.
セキュリティの問題は、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 privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised.
YANGパーサーは、不正な形式のドキュメントに対して堅牢である必要があります。 未知または信頼できないソースから不正な形式のドキュメントを読み取ると、攻撃者がYANGパーサーを実行しているユーザーの権限を取得する可能性があります。 極端な状況では、マシン全体が危険にさらされる可能性があります。
Bjorklund Standards Track [Page 170]
RFC 6020 YANG October 2010
16. Contributors
The following people all contributed significantly to the initial
YANG document:
- Andy Bierman (Brocade)
- Balazs Lengyel (Ericsson)
- David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks)
17. Acknowledgements
The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
Wijnen.
18. References
18.1. Normative References
[ISO.10646] International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO Standard 10646:2003, 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
Bjorklund Standards Track [Page 171]
RFC 6020 YANG October 2010
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A.
Layman, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-
20091208, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[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] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
18.2. Informative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next
Generation Structure of Management Information",
RFC 3780, May 2004.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[XPATH2.0] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Path Language
(XPath) 2.0", World Wide Web Consortium
Recommendation REC-xpath20-20070123, January 2007,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>.
Bjorklund Standards Track [Page 172]
RFC 6020 YANG October 2010
[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>.
Author's Address
Martin Bjorklund (editor)
Tail-f Systems
EMail: mbj@tail-f.com
Bjorklund Standards Track [Page 173]