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)
Abstract
抽象
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
YANGは、ネットワーク構成プロトコル（NETCONF）、NETCONFリモート・プロシージャ・コール、およびNETCONF通知によって操作設定や状態データをモデル化するために使用されるデータモデリング言語です。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6020.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
6.1. Lexical Tokenization ......................................34
6.1.1. Comments ...........................................34
6.1.2. Tokens .............................................34
6.1.3. Quoting ............................................35
6.2. Identifiers ...............................................36
6.2.1. Identifiers and Their Namespaces ...................36
6.3. Statements ................................................37
6.3.1. Language Extensions ................................37
6.4. XPath Evaluations .........................................38
6.4.1. XPath Context ......................................38
6.5. Schema Node Identifier ....................................39
7. YANG Statements ................................................39
7.1. The module Statement ......................................39
7.1.1. The module's Substatements .........................41
7.1.2. The yang-version Statement .........................41
7.1.3. The namespace Statement ............................42
7.1.4. The prefix Statement ...............................42
7.1.5. The import Statement ...............................42
7.1.6. The include Statement ..............................43
7.1.7. The organization Statement .........................44
7.1.8. The contact Statement ..............................44
7.1.9. The revision Statement .............................44
7.1.10. Usage Example .....................................45
7.2. The submodule Statement ...................................46
7.2.1. The submodule's Substatements ......................48
7.2.2. The belongs-to Statement ...........................48
7.2.3. Usage Example ......................................49
7.3. The typedef Statement .....................................49
7.3.1. The typedef's Substatements ........................50
7.3.2. The typedef's type Statement .......................50
7.3.3. The units Statement ................................50
7.3.4. The typedef's default Statement ....................50
7.3.5. Usage Example ......................................51
7.4. The type Statement ........................................51
7.4.1. The type's Substatements ...........................51
7.5. The container Statement ...................................51
7.5.1. Containers with Presence ...........................52
7.5.2. The container's Substatements ......................53
7.5.3. The must Statement .................................53
7.5.4. The must's Substatements ...........................55
7.5.5. The presence Statement .............................56
7.5.6. The container's Child Node Statements ..............56
7.5.7. XML Mapping Rules ..................................56
7.5.8. NETCONF <edit-config> Operations ...................56
7.5.9. Usage Example ......................................57
7.6. The leaf Statement ........................................58
7.6.1. The leaf's default value ...........................58
7.6.2. The leaf's Substatements ...........................59
7.6.3. The leaf's type Statement ..........................59
7.6.4. The leaf's default Statement .......................59
7.6.5. The leaf's mandatory Statement .....................60
7.6.6. XML Mapping Rules ..................................60
7.6.7. NETCONF <edit-config> Operations ...................60
7.6.8. Usage Example ......................................61
7.7. The leaf-list Statement ...................................62
7.7.1. Ordering ...........................................62
7.7.2. The leaf-list's Substatements ......................63
7.7.3. The min-elements Statement .........................63
7.7.4. The max-elements Statement .........................63
7.7.5. The ordered-by Statement ...........................64
7.7.6. XML Mapping Rules ..................................64
7.7.7. NETCONF <edit-config> Operations ...................65
7.7.8. Usage Example ......................................66
7.8. The list Statement ........................................67
7.8.1. The list's Substatements ...........................68
7.8.2. The list's key Statement ...........................68
7.8.3. The list's unique Statement ........................69
7.8.4. The list's Child Node Statements ...................70
7.8.5. XML Mapping Rules ..................................70
7.8.6. NETCONF <edit-config> Operations ...................71
7.8.7. Usage Example ......................................72
7.9. The choice Statement ......................................75
7.9.1. The choice's Substatements .........................76
7.9.2. The choice's case Statement ........................76
7.9.3. The choice's default Statement .....................77
7.9.4. The choice's mandatory Statement ...................79
7.9.5. XML Mapping Rules ..................................79
7.9.6. NETCONF <edit-config> Operations ...................79
7.9.7. Usage Example ......................................79
7.10. The anyxml Statement .....................................80
7.10.1. The anyxml's Substatements ........................81
7.10.2. XML Mapping Rules .................................81
7.10.3. NETCONF <edit-config> Operations ..................81
7.10.4. Usage Example .....................................82
7.11. The grouping Statement ...................................82
7.11.1. The grouping's Substatements ......................83
7.11.2. Usage Example .....................................84
7.12. The uses Statement .......................................84
7.12.1. The uses's Substatements ..........................85
7.12.2. The refine Statement ..............................85
7.12.3. XML Mapping Rules .................................86
7.12.4. Usage Example .....................................86
7.13. The rpc Statement ........................................87
7.13.1. The rpc's Substatements ...........................88
7.13.2. The input Statement ...............................88
7.13.3. The output Statement ..............................89
7.13.4. XML Mapping Rules .................................90
7.13.5. Usage Example .....................................91
7.14. The notification Statement ...............................91
7.14.1. The notification's Substatements ..................92
7.14.2. XML Mapping Rules .................................92
7.14.3. Usage Example .....................................93
7.15. The augment Statement ....................................93
7.15.1. The augment's Substatements .......................94
7.15.2. XML Mapping Rules .................................94
7.15.3. Usage Example .....................................95
7.16. The identity Statement ...................................97
7.16.1. The identity's Substatements ......................97
7.16.2. The base Statement ................................97
7.16.3. Usage Example .....................................98
7.17. The extension Statement ..................................98
7.17.1. The extension's Substatements .....................99
7.17.2. The argument Statement ............................99
7.17.3. Usage Example ....................................100
7.18. Conformance-Related Statements ..........................100
7.18.1. The feature Statement ............................100
7.18.2. The if-feature Statement .........................102
7.18.3. The deviation Statement ..........................102
7.19. Common Statements .......................................105
7.19.1. The config Statement .............................105
7.19.2. The status Statement .............................105
7.19.3. The description Statement ........................106
7.19.4. The reference Statement ..........................106
7.19.5. The when Statement ...............................107
8. Constraints ...................................................108
8.1. Constraints on Data ......................................108
8.2. Hierarchy of Constraints .................................109
8.3. Constraint Enforcement Model .............................109
8.3.1. Payload Parsing ...................................109
8.3.2. NETCONF <edit-config> Processing ..................110
8.3.3. Validation ........................................111
9. Built-In Types ................................................111
9.1. Canonical Representation .................................112
9.2. The Integer Built-In Types ...............................112
9.2.1. Lexical Representation ............................113
9.2.2. Canonical Form ....................................114
9.2.3. Restrictions ......................................114
9.2.4. The range Statement ...............................114
9.2.5. Usage Example .....................................115
9.3. The decimal64 Built-In Type ..............................115
9.3.1. Lexical Representation ............................115
9.3.2. Canonical Form ....................................115
9.3.3. Restrictions ......................................116
9.3.4. The fraction-digits Statement .....................116
9.3.5. Usage Example .....................................117
9.4. The string Built-In Type .................................117
9.4.1. Lexical Representation ............................117
9.4.2. Canonical Form ....................................117
9.4.3. Restrictions ......................................117
9.4.4. The length Statement ..............................117
9.4.5. Usage Example .....................................118
9.4.6. The pattern Statement .............................119
9.4.7. Usage Example .....................................119
9.5. The boolean Built-In Type ................................120
9.5.1. Lexical Representation ............................120
9.5.2. Canonical Form ....................................120
9.5.3. Restrictions ......................................120
9.6. The enumeration Built-In Type ............................120
9.6.1. Lexical Representation ............................120
9.6.2. Canonical Form ....................................120
9.6.3. Restrictions ......................................120
9.6.4. The enum Statement ................................120
9.6.5. Usage Example .....................................121
9.7. The bits Built-In Type ...................................122
9.7.1. Restrictions ......................................122
9.7.2. Lexical Representation ............................122
9.7.3. Canonical Form ....................................122
9.7.4. The bit Statement .................................122
9.7.5. Usage Example .....................................123
9.8. The binary Built-In Type .................................123
9.8.1. Restrictions ......................................124
9.8.2. Lexical Representation ............................124
9.8.3. Canonical Form ....................................124
9.9. The leafref Built-In Type ................................124
9.9.1. Restrictions ......................................124
9.9.2. The path Statement ................................124
9.9.3. Lexical Representation ............................125
9.9.4. Canonical Form ....................................125
9.9.5. Usage Example .....................................126
9.10. The identityref Built-In Type ...........................129
9.10.1. Restrictions .....................................129
9.10.2. The identityref's base Statement .................129
9.10.3. Lexical Representation ...........................130
9.10.4. Canonical Form ...................................130
9.10.5. Usage Example ....................................130
9.11. The empty Built-In Type .................................131
9.11.1. Restrictions .....................................131
9.11.2. Lexical Representation ...........................131
9.11.3. Canonical Form ...................................131
9.11.4. Usage Example ....................................131
9.12. The union Built-In Type .................................132
9.12.1. Restrictions .....................................132
9.12.2. Lexical Representation ...........................132
9.12.3. Canonical Form ...................................133
9.13. The instance-identifier Built-In Type ...................133
9.13.1. Restrictions .....................................134
9.13.2. The require-instance Statement ...................134
9.13.3. Lexical Representation ...........................134
9.13.4. Canonical Form ...................................134
9.13.5. Usage Example ....................................134
10. Updating a Module ............................................135
11. YIN ..........................................................137
11.1. Formal YIN Definition ...................................137
11.1.1. Usage Example ....................................141
12. YANG ABNF Grammar ............................................143
13. Error Responses for YANG Related Errors ......................165
13.1. Error Message for Data That Violates a unique
Statement ...............................................165
13.2. Error Message for Data That Violates a
max-elements Statement ..................................165
13.3. Error Message for Data That Violates a
min-elements Statement ..................................165
13.4. Error Message for Data That Violates a must Statement ...166
13.5. Error Message for Data That Violates a
require-instance Statement ..............................166
13.6. Error Message for Data That Does Not Match a
leafref Type ............................................166
13.7. Error Message for Data That Violates a mandatory
choice Statement ........................................166
13.8. Error Message for the "insert" Operation ................167
14. IANA Considerations ..........................................167
14.1. Media type application/yang .............................168
14.2. Media type application/yin+xml ..........................169
15. Security Considerations ......................................170
16. Contributors .................................................171
17. Acknowledgements .............................................171
18. References ...................................................171
18.1. Normative References ....................................171
18.2. Informative References ..................................172
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], Section 1.1).
YANGは、ネットワーク構成プロトコル（NETCONF）、NETCONFリモート・プロシージャ・コール、およびNETCONF通知によって操作設定や状態データをモデル化するために使用されるデータモデリング言語です。 YANGはNETCONFの動作とコンテンツ層（NETCONF構成プロトコル[RFC4741]、セクション1.1を参照）をモデル化するために使用されます。
This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in the Extensible Markup Language (XML), and how NETCONF operations are used to manipulate the data.
この文書では、YANGモジュールで定義されたデータモデルを拡張マークアップ言語（XML）で表現され、そしてどのようにNETCONF操作は、データを操作するために使用される方法YANG言語の構文と意味論を記載します。
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"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、 "推奨NOT"、および "OPTIONAL"本書でBCP 14、[RFC2119]に記載されているように解釈されるべきです。
o anyxml: A data node that can contain an unknown chunk of XML data.
O AnyXMLで：XMLデータの未知のチャンクを含むことができ、データノード。
o augment: Adds new schema nodes to a previously defined schema node.
O増強：以前に定義されたスキーマのノードに新しいスキーマノードを追加します。
o base type: The type from which a derived type was derived, which may be either a built-in type or another derived type.
O基本型：派生型が由来したタイプ、内蔵型または他の派生型のいずれであってもよいです。
o built-in type: A YANG data type defined in the YANG language, such as uint32 or string.
O内蔵型：YANG言語で定義されYANGデータ型などUINT32またはストリング。
o choice: A schema node where only one of a number of identified alternatives is valid.
Oの選択：のみ1つの識別された選択肢の数のが有効であるスキーマノード。
o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state [RFC4741].
O構成データ：現在の状態[RFC4741]に初期デフォルト状態からシステムを変換するために必要とされる書き込み可能なデータのセット。
o conformance: A measure of how accurately a device follows a data model.
O適合：デバイスは、データモデルを、以下の方法を正確に測定します。
o container: An interior data node that exists in at most one instance in the data tree. A container has no value, but rather a set of child nodes.
Oコンテナ：データツリー内で多くても1つのインスタンス内に存在する内部データ・ノード。コンテナは値ではなく、子ノードのセットを持っていません。
o data definition statement: A statement that defines new data nodes. One of container, leaf, leaf-list, list, choice, case, augment, uses, and anyxml.
Oデータ定義文：新しいデータノードを定義する声明。コンテナ、葉、葉、リスト、リスト、選択、ケース、強化、使用、およびAnyXMLでの一つ。
o data model: A data model describes how data is represented and accessed.
Oデータモデル：データモデルはデータを表現し、アクセスされる方法を説明します。
o data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml.
Oデータノード：データツリーでインスタンス化することができるスキーマ・ツリー内のノード。コンテナ、葉、葉、リスト、リスト、およびAnyXMLでの一つ。
o data tree: The instantiated tree of configuration and state data on a device.
Oデータ・ツリー：デバイス上のコンフィギュレーション及び状態データのインスタンス化ツリー。
o derived type: A type that is derived from a built-in type (such as uint32), or another derived type.
O構造型：ビルトインタイプ（例えばUINT32など）、または他の構造型に由来するタイプ。
o device deviation: A failure of the device to implement the module faithfully.
Oデバイス偏差：忠実モジュールを実装するデバイスの障害。
o extension: An extension attaches non-YANG semantics to statements. The extension statement defines new statements to express these semantics.
O拡張：拡張機能は、書類の非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機能：オプションとして、モデルの部分をマーキングするための機構。定義は機能名でタグ付けし、その機能をサポートするデバイスにのみ有効であることができます。
o grouping: A reusable set of schema nodes, which may be used locally in the module, in modules that include it, and by other modules that import from it. The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
Oグルーピング：それを含むモジュールに、及びそこからインポート他のモジュールにより、モジュール内で局所的に使用することができるスキーマ・ノードの再利用可能なセット。グループステートメントのような、スキーマ・ツリー内の任意のノードを定義していない、データ定義文ではなく、。
o identifier: Used to identify different kinds of YANG items by name.
O識別子：名前によってYANGアイテムの種類を識別するために使用します。
o instance identifier: A mechanism for identifying a particular node in a data tree.
Oインスタンス識別子：データツリー内の特定のノードを識別するためのメカニズム。
o interior node: Nodes within a hierarchy that are not leaf nodes.
内部ノードO：リーフノードでない階層内のノード。
o leaf: A data node that exists in at most one instance in the data tree. A leaf has a value but no child nodes.
O葉：データツリー内で多くても1つのインスタンス内に存在するデータノード。葉は、値ではなく、子ノードを持っています。
o leaf-list: Like the leaf node but defines a set of uniquely identifiable nodes rather than a single node. Each node has a value but no child nodes.
Oリーフリスト：リーフノードと同様なく一意に識別可能なノードのセットではなく、単一のノードを定義します。各ノードは、値ではなく、子ノードを持っています。
o list: An interior data node that may exist in multiple instances in the data tree. A list has no value, but rather a set of child nodes.
Oリスト：データツリー内の複数のインスタンス内に存在し得る内部データ・ノード。リストは値ではなく、子ノードのセットを持っていません。
o module: A YANG module defines a hierarchy of nodes that can be used for NETCONF-based operations. With its definitions and the definitions it imports or includes from elsewhere, a module is self-contained and "compilable".
Oモジュール：YANGモジュールはNETCONFベースの操作に用いることができるノードの階層を定義します。その定義と、それは他の場所からの輸入または含ま定義で、モジュールは、自己完結型と「コンパイル」です。
o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
OのRPC：リモートプロシージャコール、NETCONFプロトコル内で使用されます。
o RPC operation: A specific Remote Procedure Call, as used within the NETCONF protocol. It is also called a protocol operation.
OのRPC操作：特定のリモートプロシージャコール、NETCONFプロトコル内で使用されます。また、プロトコルの動作と呼ばれています。
o schema node: A node in the schema tree. One of container, leaf, leaf-list, list, choice, case, rpc, input, output, notification, and anyxml.
Oスキーマノード：スキーマ・ツリー内のノード。コンテナ、葉、葉、リスト、リスト、選択、場合、RPC、入力、出力、通知、およびAnyXMLでの一つ。
o schema node identifier: A mechanism for identifying a particular node in the schema tree.
Oスキーマノード識別子：スキーマ・ツリー内の特定のノードを識別するためのメカニズム。
o schema tree: The definition hierarchy specified within a module.
Oスキーマツリー：モジュール内で指定された定義の階層。
o state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics [RFC4741].
O状態データ：そのような読み出し専用のステータス情報などのデータを構成し、統計[RFC4741]を集めていないシステム上で追加データ。
o submodule: A partial module definition that contributes derived types, groupings, data nodes, RPCs, and notifications to a module. A YANG module can be constructed from a number of submodules.
Oサブモジュール：モジュールに派生タイプ、グループ、データノード、のRPC、および通知に寄与する部分モジュール定義。 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トップレベル・データ・ノード：それは、モジュール又はサブモジュールの文の間には他のデータノードが存在しないデータ・ノード。
o uses: The "uses" statement is used to instantiate the set of schema nodes defined in a grouping statement. The instantiated nodes may be refined and augmented to tailor them to any specific needs.
oは使用：文がグループ化ステートメントで定義されたスキーマ・ノードのセットをインスタンス化するために使用される「使用します」。インスタンス化されたノードは、洗練さと任意の特定のニーズにそれらを調整するように拡張することができます。
A mandatory node is one of:
必須ノードは、次のいずれかです。
o A leaf, choice, or anyxml node with a "mandatory" statement with the value "true".
葉、選択、または値を持つ「必須」の文とAnyXMLでノード「真の」o。
o A list or leaf-list node with a "min-elements" statement with a value greater than zero.
Oゼロよりも大きい値を有する「MIN-要素」文を使用してリストまたはリーフノードリスト。
o A container node without a "presence" statement, which has at least one mandatory node as a child.
O子として少なくとも1つの必須ノードがあり、「存在」の文、なしのコンテナノード。
YANG is a language used to model data for the NETCONF protocol. A YANG module defines a hierarchy of data that can be used for NETCONF-based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data sent between a NETCONF client and server.
YANGは、NETCONFプロトコルのデータをモデル化するために使用される言語です。 YANGモジュールは、設定、状態データ、リモート・プロシージャ・コール（RPC）、および通知を含むNETCONFベースの操作に用いることができるデータの階層構造を定義します。これは、NETCONFクライアントとサーバ間で送信されるすべてのデータの完全な記述を可能にします。
YANG models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes. YANG provides clear and concise descriptions of the nodes, as well as the interaction between those nodes.
YANGモデルの各ノードは、名前を有する、木、及び値のいずれか、または子ノードのセットとしてデータの階層構造。 YANGは、明確かつ簡潔なノードの記述、ならびにそれらのノードとの間の相互作用を提供します。
YANG structures data models into modules and submodules. A module can import data from other external modules, and include data from submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation can be conditional, with new nodes appearing only if certain conditions are met.
モジュールおよびサブモジュールにYANG構造のデータモデル。モジュールは、他の外部モジュールからデータをインポートし、サブモジュールからのデータを含むことができます。階層は、一つのモジュールが他のモジュールで定義された階層にデータノードを追加することを可能にする、増強することができます。この増加は、特定の条件が満たされた場合にのみ登場する新しいノードで、条件を付けることができます。
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は、ノードの再利用可能なグループの定義が可能になります。これらのグループのインスタンス化は、その特定のニーズにノードを調整することができ、ノードを絞り込むまたは拡張することができます。派生型とグループ化は、一つのモジュール又はサブモジュールで定義され、いずれかその場所に、またはインポートするか、またはそれを含む他のモジュール又はサブモジュールで使用することができます。
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モジュールは、モデル上で動作するためにXMLパーサを使用して、アプリケーションや拡張スタイルシート言語変換（XSLT）スクリプトを許可する、YANG独立表記（YIN）（第11項）と呼ばれる同等のXML構文に変換することができます。 YINの内容はラウンドトリップバックYANGにできるよう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は、高レベルのデータモデリングとローレベルのビット・オン・ワイヤー符号化の間のバランスを打ちます。データはNETCONF操作で符号化される方法を理解しながら、YANGモジュールのリーダは、データモデルの高レベルのビューを見ることができます。
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は、NETCONFのデータモデルではなく、任意のXML文書または任意のデータモデルの発現を可能にする問題空間を制限し、可能なすべての問題を解決する傾向に抵抗します。 YANGによって記述されたデータ・モデルを容易NETCONF操作によって操作されるように設計されています。
To the extent possible, YANG maintains compatibility with Simple Network Management Protocol's (SNMP's) SMIv2 (Structure of Management Information version 2 [RFC2578], [RFC2579]). SMIv2-based MIB modules can be automatically translated into YANG modules for read-only access. However, YANG is not concerned with reverse translation from YANG to SMIv2.
可能な限り、YANGは、簡易ネットワーク管理プロトコルの（SNMPの）のSMIv2（経営情報バージョン2の構造[RFC2578]、[RFC2579]）との互換性を維持します。 SMIv2のベースのMIBモジュールが自動的に読み取り専用アクセス用にYANGモジュールに変換することができます。しかし、YANGはYANGからのSMIv2への逆変換と心配していないです。
Like NETCONF, YANG targets smooth integration with the device's native management infrastructure. This allows implementations to leverage their existing access control mechanisms to protect or expose elements of the data model.
NETCONFのように、YANGは、デバイスのネイティブ管理インフラストラクチャとのスムーズな統合を対象としています。これは、実装は、データモデルの要素を保護したり、公開するために、既存のアクセス制御メカニズムを活用することができます。
This section introduces some important constructs used in YANG that will aid in the understanding of the language specifics in later sections. This progressive approach handles the inter-related nature of YANG concepts and statements. A detailed description of YANG statements and syntax begins in Section 7.
このセクションでは、後のセクションでは、言語仕様の理解を助けるだろうYANGで使用されるいくつかの重要な構成要素を紹介します。この進歩的なアプローチは、YANGの概念と文の間の関連性を処理します。 YANG文と構文の詳細については、セクション7で始まります。
A module contains three types of statements: module-header statements, revision statements, and definition statements. The module header statements describe the module and give information about the module itself, the revision statements give information about the history of the module, and the definition statements are the body of the module where the data model is defined.
モジュールヘッダステートメント、改訂文、定義文：モジュールは、文の三種類を含んでいます。モジュールヘッダ文はモジュールを記述し、モジュール自体についての情報を与える、改正文は、モジュールの履歴に関する情報を与え、定義文は、データ・モデルが定義されているモジュールの本体です。
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サーバは、同じデータの複数のビュー、またはデバイスのデータの互いに素なサブセクションの複数のビューを可能にする、多数のモジュールを実装することができます。代替的に、サーバは、利用可能なすべてのデータを定義する唯一のモジュールを実装することができます。
A module may be divided into submodules, based on the needs of the module owner. The external view remains that of a single module, regardless of the presence or size of its submodules.
モジュールは、モジュールの所有者のニーズに基づいて、サブモジュールに分割することができます。外観に関係なく、そのサブモジュールの存在または大きさの、単一のモジュールのままです。
The "include" statement allows a module or submodule to reference material in submodules, and the "import" statement allows references to material defined in other modules.
「含む」ステートメントは、モジュールまたはサブモジュールは、サブモジュール内の材料を参照することができ、そして「インポート」文は、他のモジュールで定義された材料への参照を可能にします。
YANG defines four types of nodes for data modeling. In each of the following subsections, the example shows the YANG syntax as well as a corresponding NETCONF XML representation.
YANGは、データ・モデリングのためのノードの四種類を定義します。以下のサブセクションのそれぞれにおいて、例は、YANG構文ならびに対応するNETCONFのXML表現を示しています。
A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type and no child nodes.
リーフノードは、整数や文字列などの単純なデータが含まれています。これは、1つの特定の型の値と子ノードを持っています。
YANG Example:
例：
leaf host-name {
type string;
description "Hostname for this system";
}
NETCONF XML Example:
NETCONF XMLの例：
<host-name>my.example.com</host-name>
<ホスト名> my.example.com </ホスト名>
The "leaf" statement is covered in Section 7.6.
「リーフ」の文は、7.6節で覆われています。
A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf.
リーフリストは、リーフ当り、特定のタイプの1つの値を持つリーフノードの配列です。
YANG Example:
例：
leaf-list domain-search {
type string;
description "List of domain names to search";
}
NETCONF XML Example:
NETCONF XMLの例：
<domain-search>high.example.com</domain-search> <domain-search>low.example.com</domain-search> <domain-search>everywhere.example.com</domain-search>
<ドメイン検索> high.example.com </ドメイン検索> <ドメイン検索> low.example.com </ドメイン検索> <ドメイン検索> everywhere.example.com </ドメイン検索>
The "leaf-list" statement is covered in Section 7.7.
「リーフリスト」文は、セクション7.7に覆われています。
A container node is used to group related nodes in a subtree. A container has only child nodes and no value. A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists).
コンテナノードはサブツリーにグループ関連のノードに使用されます。コンテナは、唯一の子ノードと無価値を持っています。容器は、（リーフ、リスト、コンテナ、およびリーフリストを含む）任意のタイプの子ノードの任意の数を含んでいてもよいです。
YANG Example:
例：
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
}
}
NETCONF XML Example:
NETCONF XMLの例：
<system> <login> <message>Good morning</message> </login> </system>
<システム> <ログイン> <メッセージ>おはよう</メッセージ> </ LOGIN> </システム>
The "container" statement is covered in Section 7.5.
「コンテナ」の文は、7.5節で覆われています。
A list defines a sequence of list entries. Each entry is like a structure or a record instance, and is uniquely identified by the values of its key leafs. A list can define multiple key leafs and may contain any number of child nodes of any type (including leafs, lists, containers etc.).
リストは、リストのエントリのシーケンスを定義します。各エントリには、構造またはレコードインスタンスと同様であり、一意のキーリーフの値によって識別されます。リストには、複数のキー葉を定義することができ、（リーフ、リスト、コンテナ等を含む）任意のタイプの子ノードの任意の数を含んでいてもよいです。
YANG Example:
例：
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
NETCONF XML Example:
NETCONF XMLの例：
<user> <name>glocks</name> <full-name>Goldie Locks</full-name> <class>intruder</class> </user> <user> <name>snowey</name> <full-name>Snow White</full-name> <class>free-loader</class> </user> <user> <name>rzell</name> <full-name>Rapun Zell</full-name> <class>tower</class> </user>
<ユーザー> <名前> glocks </名前> <フルネーム>ゴールディロック</フル名> <クラス>侵入者</クラス> </ユーザー> <ユーザー> <名前> snowey </名前> <フル名前>白雪姫</フル名> <クラス>フリーローダー</クラス> </ユーザー> <ユーザー> <名前> rzell </名前> <フルネーム> Rapunツェル</フル名> <クラス>タワー</クラス> </ユーザー>
The "list" statement is covered in Section 7.8.
「リスト」文は7.8節で覆われています。
These statements are combined to define the module:
これらのステートメントは、モジュールを定義するために組み合わされます。
// Contents of "acme-system.yang"
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-06-09 { description "Initial revision."; }
リビジョン2007-06-09 {説明「初期リビジョン。」; }
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}
YANG can model state data, as well as configuration data, based on the "config" statement. When a node is tagged with "config false", its subhierarchy is flagged as state data, to be reported using NETCONF's <get> operation, not the <get-config> operation. Parent containers, lists, and key leafs are reported also, giving the context for the state data.
YANGは、「設定」の文に基づいて、状態データ、並びに構成データをモデル化することができます。ノードが「偽設定」でタグ付けされている場合、そのサブ階層は、NETCONFの<GET>の操作ではなく、<GET-config>の操作を使用して報告されるように、状態データとしてフラグが立てられています。親コンテナ、リスト、およびキー葉は、状態データのコンテキストを与えることも報告されています。
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つのリーフは、各インターフェイス、設定された速度と観測速度のために定義されています。観測された速度が構成ではありませんので、それはではなく、<GET-config>の操作で、NETCONF <GET>操作で返すことができます。観察された速度は、構成データではない、それは<編集設定>使用して操作することができません。
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;
}
}
YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements from the management domain. The following table summarizes the built-in types discussed in Section 9:
YANGは、多くのプログラミング言語と同様のビルトインタイプのセットを、持っていますが、管理ドメインからの特別な要求のためにいくつかの違いで。次の表は、第9章で述べたビルトインタイプを要約したものです。
+---------------------+-------------------------------------+
| Name | Description |
+---------------------+-------------------------------------+
| binary | Any binary data |
| bits | A set of bits or flags |
| boolean | "true" or "false" |
| decimal64 | 64-bit signed decimal number |
| empty | A leaf that does not have any value |
| enumeration | Enumerated strings |
| identityref | A reference to an abstract identity |
| instance-identifier | References a data tree node |
| int8 | 8-bit signed integer |
| int16 | 16-bit signed integer |
| int32 | 32-bit signed integer |
| int64 | 64-bit signed integer |
| leafref | A reference to a leaf instance |
| string | Human-readable string |
| uint8 | 8-bit unsigned integer |
| uint16 | 16-bit unsigned integer |
| uint32 | 32-bit unsigned integer |
| uint64 | 64-bit unsigned integer |
| union | Choice of member types |
+---------------------+-------------------------------------+
The "type" statement is covered in Section 7.4.
「タイプ」の文は、7.4節で覆われています。
YANG can define derived types from base types using the "typedef" statement. A base type can be either a built-in type or a derived type, allowing a hierarchy of derived types.
YANGは「typedefの」ステートメントを使用して、基本型から派生型を定義することができます。基本型は、派生型の階層構造を可能にする内蔵型または派生型のいずれであってもよいです。
A derived type can be used as the argument for the "type" statement.
派生型は、「タイプ」の文の引数として使用することができます。
YANG Example:
例：
typedef percent {
type uint8 {
range "0 .. 100";
}
description "Percentage";
}
leaf completed { type percent; }
葉完了{型パーセント。 }
NETCONF XML Example:
NETCONF XMLの例：
<completed>20</completed>
<完成> 20 </完成>
The "typedef" statement is covered in Section 7.3.
「typedefは」文は7.3節で覆われています。
Groups of nodes can be assembled into reusable collections using the "grouping" statement. A grouping defines a set of nodes that are instantiated with the "uses" statement:
ノードのグループは、「グループ化」ステートメントを使用して、再利用可能なコレクションに組み立てることができます。グルーピングは、ステートメント「使用」でインスタンス化されたノードのセットを定義します。
grouping target {
leaf address {
type inet:ip-address;
description "Target IP address";
}
leaf port {
type inet:port-number;
description "Target port number";
}
}
container peer { container destination { uses target; } }
容器ピア{コンテナ先{ターゲットを使用します。 }}
NETCONF XML Example:
NETCONF XMLの例：
<peer> <destination> <address>192.0.2.1</address> <port>830</port> </destination> </peer>
<ピア> <宛先> <アドレス> 192.0.2.1 </アドレス>、<ポート> 830 </ポート> </宛先> </ピア>
The grouping can be refined as it is used, allowing certain statements to be overridden. In this example, the description is refined:
それが使用されるグループは、特定の文が上書きされることを可能にする、改良することができます。この例では、説明が精製されます。
container connection {
container source {
uses target {
refine "address" {
description "Source IP address";
}
refine "port" {
description "Source port number";
}
}
}
container destination {
uses target {
refine "address" {
description "Destination IP address";
}
refine "port" {
description "Destination port number";
}
}
}
}
The "grouping" statement is covered in Section 7.11.
「グループ化」の文は、7.11節で覆われています。
YANG allows the data model to segregate incompatible nodes into distinct choices using the "choice" and "case" statements. The "choice" statement contains a set of "case" statements that define sets of schema nodes that cannot appear together. Each "case" may contain multiple nodes, but each node may appear in only one "case" under a "choice".
YANGは、データモデルは、「選択」と「ケース」ステートメントを使用して明確な選択肢に互換性のないノードを分離することができます。 「選択」ステートメントが一緒に表示することはできません、スキーマ・ノードのセットを定義する「ケース」ステートメントのセットが含まれています。各「ケース」は、複数のノードを含んでいてもよいが、各ノードは、「選択」の下に一つだけ「ケース」で表示されてもよいです。
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メッセージで、唯一のスキーマツリーに表示されます。階層の追加レベルは概念スキーマを超えて必要とされていません。
YANG Example:
例：
container food {
choice snack {
case sports-arena {
leaf pretzel {
type empty;
}
leaf beer {
type empty;
}
}
case late-night {
leaf chocolate {
type enumeration {
enum dark;
enum milk;
enum first-available;
}
}
}
}
}
NETCONF XML Example:
NETCONF XMLの例：
<food> <pretzel/> <beer/> </food>
<食べ物> <プレッツェル/> <ビール/> </食品>
The "choice" statement is covered in Section 7.9.
「選択」文は7.9節で覆われています。
YANG allows a module to insert additional nodes into data models, including both the current module (and its submodules) or an external module. This is useful for example for vendors to add vendor-specific parameters to standard data models in an interoperable way.
YANGは、モジュールが現在のモジュール（およびそのサブモジュール）や外部モジュールの両方を含むデータモデルに追加ノードを挿入することを可能にします。ベンダーが相互運用可能な方法で標準データモデルにベンダー固有のパラメータを追加するためにこれは、例えば便利です。
The "augment" statement defines the location in the data model hierarchy where new nodes are inserted, and the "when" statement defines the conditions when the new nodes are valid.
「増強」ステートメントは、新しいノードが挿入されているデータモデル階層内の位置を定義し、新しいノードが有効である場合にステートメントが条件を定義する「いつ」。
YANG Example:
例：
augment /system/login/user {
when "class != 'wheel'";
leaf uid {
type uint16 {
range "1000 .. 30000";
}
}
}
This example defines a "uid" node that only is valid when the user's "class" is not "wheel".
この例では、ユーザーの「クラス」は「車輪」でない場合にのみ有効である「UID」ノードを定義します。
If a module augments another module, the XML representation of the data will reflect the prefix of the augmenting module. For example, if the above augmentation were in a module with prefix "other", the XML would look like:
モジュールが別のモジュールを強化する場合は、データのXML表現を増強モジュールの接頭辞が反映されます。上記の増強は、「その他」の接頭辞モジュールにあった場合、例えば、XMLは次のようになります。
NETCONF XML Example:
NETCONF XMLの例：
<user> <name>alicew</name> <full-name>Alice N. Wonderland</full-name> <class>drop-out</class> <other:uid>1024</other:uid> </user>
<ユーザー> <名前> alicew </名前> <フルネーム>アリスN.ワンダーランド</フル名> <クラス>ドロップアウト</クラス> <他ます。uid> 1024 </その他ます。uid> </ユーザー>
The "augment" statement is covered in Section 7.15.
「オーグメント」文は、セクション7.15で覆われています。
YANG allows the definition of NETCONF RPCs. The operations' names, input parameters, and output parameters are modeled using YANG data definition statements.
YANGは、NETCONFのRPCを定義できます。事業者名、入力パラメータ、出力パラメータがYANGデータ定義ステートメントを使用してモデル化されています。
YANG Example:
例：
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}
NETCONF XML Example:
NETCONF XMLの例：
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <activate-software-image xmlns="http://acme.example.com/system"> <image-name>acmefw-2.3</image-name> </activate-software-image> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <アクティブ・ソフトウェア・イメージのxmlns = "http://acme.example.com/system" > <イメージ名> acmefw-2.3 </画像名> </アクティブ・ソフトウェア・イメージ> </ 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>
<RPC返信メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <状態のxmlns = "http://acme.example.com/system"> acmefw-2.3の画像がインストールされています。 </ステータス> </ RPC-返信>
The "rpc" statement is covered in Section 7.13.
「RPC」文は7.13で覆われています。
YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the content of the notification.
YANGは、NETCONFに適した通知を定義できます。 YANGデータ定義文は、通知の内容をモデル化するために使用されています。
YANG Example:
例：
notification link-failure {
description "A link failure has been detected";
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf if-admin-status {
type admin-status;
}
leaf if-oper-status {
type oper-status;
}
}
NETCONF XML Example:
NETCONF XMLの例：
<notification xmlns="urn:ietf:params:netconf:capability:notification:1.0"> <eventTime>2007-09-01T10:00:00Z</eventTime> <link-failure xmlns="http://acme.example.com/system"> <if-name>so-1/2/3.0</if-name> <if-admin-status>up</if-admin-status> <if-oper-status>down</if-oper-status> </link-failure> </notification>
<通知のxmlns = "壷：IETF：のparams：NETCONF：機能：通知：1.0"> <イベント時刻> 2007-09-01T10：00：00Z </イベント時刻> <リンク障害のxmlns = "のhttp：//acme.example .COM /システム "> <IF-name>のように-1/2 / 3.0 </ IF-名> <IF-管理ステータス> </ IF-adminのステータスアップ> <IF-OPERステータスダウン> </ IF-OPER-状態> </リンク障害> </通知>
The "notification" statement is covered in Section 7.14.
「通知」文は、セクション7.14で覆われています。
The module is the base unit of definition in YANG. A module defines a single data model. A module can define a complete, cohesive model, or augment an existing data model with additional nodes.
モジュールは、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.
サブモジュールは、モジュールに定義を貢献する部分のモジュールです。モジュールは、サブモジュールの任意の数を含んでいてもよいが、各サブモジュールは、一つのモジュールに属していてもよいです。
The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name.
すべての標準モジュールおよびサブモジュールの名前は一意でなければなりません。企業・モジュールの開発者は、モジュール名の接頭辞として、企業や組織名を使用することにより、例えば、標準または他のエンタープライズ・モジュールと衝突する確率が低いだろう彼らのモジュールの名前を選択することをお勧めします。
A module uses the "include" statement to include its submodules, and the "import" statement to reference external modules. Similarly, a submodule uses the "import" statement to reference other modules, and uses the "include" statement to reference other submodules within its module. A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module.
モジュールは、そのサブモジュールを含める「を含む」ステートメントを使用し、「インポート」文は、外部モジュールを参照すること。同様に、サブモジュールは他のモジュールを参照するために「インポート」ステートメントを使用し、そのモジュール内の他のサブモジュールを参照するために、「含む（include）」ステートメントを使用します。モジュールまたはサブモジュールは他のモジュールのサブモジュールを含んではいけません、そしてサブモジュールは、独自のモジュールをインポートしてはいけません。
The import and include statements are used to make definitions available to other modules and submodules:
インポートと文は他のモジュールおよびサブモジュールに定義を利用できるようにするために使用されている次のとおりです。
o For a module or submodule to reference definitions in an external module, the external module MUST be imported.
O外部モジュールにおける基準定義のモジュールまたはサブモジュールは、外部モジュールをインポートする必要があります。
o For a module to reference definitions in one of its submodules, the module MUST include the submodule.
Oそのサブモジュールのいずれかで基準定義のモジュールの場合、モジュールは、サブモジュールを含まなければなりません。
o For a submodule to reference definitions in a second submodule of the same module, the first submodule MUST include the second submodule.
サブモジュールは、同じモジュールの第2のサブモジュールの定義を参照するためにO、第一のサブモジュールは、第二のサブモジュールを含まなければなりません。
There MUST NOT be any circular chains of imports or includes. For example, if submodule "a" includes submodule "b", "b" cannot include "a".
任意の円形輸入の鎖または含んがあってはなりません。例えば、サブモジュール場合は「」サブモジュール「B」、「B」は「A」を含むことができない含みます。
When a definition in an external module is referenced, a locally defined prefix MUST be used, followed by ":", and then the external identifier. References to definitions in the local module MAY use the prefix notation. Since built-in data types do not belong to any module and have no prefix, references to built-in data types (e.g., int32) cannot use the prefix notation.
外部モジュール内の定義が参照される場合、局所的に定義されたプレフィックスは、使用が続かなければならない「：」、およびその後、外部識別子。ローカルモジュール内の定義への参照は、接頭表記法を使用するかもしれません。組み込みのためのデータ型の任意のモジュールに属し、接頭辞、組み込みデータ型（例えば、Int32）を接頭表記法を使用することはできませんへの参照を持っていません。
Published modules evolve independently over time. In order to allow for this evolution, modules need to be imported using specific revisions. When a module is written, it uses the current revisions of other modules, based on what is available at the time. As future revisions of the imported modules are published, the importing module is unaffected and its contents are unchanged. When the author of the module is prepared to move to the most recently published revision of an imported module, the module is republished with an updated "import" statement. By republishing with the new revision, the authors explicitly indicate their acceptance of any changes in the imported module.
公開されたモジュールは、時間の経過とともに独立して進化します。この進化を可能にするために、モジュールは、特定のリビジョンを使用してインポートする必要があります。モジュールが書かれている場合は、一度に利用可能なものに基づいて、他のモジュールの現在のリビジョンを使用しています。インポートされたモジュールの将来の改訂が公開されると、インポートモジュールは影響を受けず、その内容は変更されません。モジュールの作者は、インポートされたモジュールの最も最近発表されたリビジョンに移動する用意がある場合は、モジュールが更新され、「インポート」ステートメントを使用して再発行されます。新しいリビジョンを再発行することで、著者は明示的にインポートされたモジュールの変更の彼らの受け入れを示しています。
For submodules, the issue is related but simpler. A module or submodule that includes submodules needs to specify the revision of the included submodules. If a submodule changes, any module or submodule that includes it needs to be updated.
サブモジュールの場合、問題が関連しているが簡単です。サブモジュールを含むモジュールまたはサブモジュールが含まれるサブモジュールのリビジョンを指定する必要があります。それが更新する必要が含まれてサブモジュールを変更した場合、任意のモジュールまたはサブモジュール。
For example, module "b" imports module "a".
例えば、モジュール「B」インポートモジュール「A」。
module a { revision 2008-01-01 { ... } grouping a { leaf eh { .... } } }
{リビジョン2008-01-01 {...} EH {葉をグループ化を{...}}}モジュール
module b {
import a {
prefix p;
revision-date 2008-01-01;
}
container bee { uses p:a; } }
容器蜂は、{Pを使用します。 }}
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.
著者は「」新しいリビジョンを公開すると、変更内容は、「B」の作者に許容できない場合があります。新しいリビジョンが受け入れ可能である場合は、「B」の著者は、「インポート」文で更新リビジョンを再発行することができます。
YANG allows modeling of data in multiple hierarchies, where data may have more than one top-level node. Models that have multiple top-level nodes are sometimes convenient, and are supported by YANG.
YANGは、データが複数のトップレベルのノードを有していてもよく、複数の階層のデータのモデリングを可能にします。複数のトップレベルのノードを有するモデルは、時には便利であり、YANGによって支持されています。
NETCONF is capable of carrying any XML content as the payload in the <config> and <data> elements. The top-level nodes of YANG modules are encoded as child elements, in any order, within these elements. This encapsulation guarantees that the corresponding NETCONF messages are always well-formed XML documents.
NETCONFは、<設定>と<データ>要素内のペイロードのような任意のXMLコンテンツを搬送することが可能です。 YANGモジュールのトップレベルのノードは、これらの要素内で、任意の順序で、子要素として符号化されます。このカプセル化は、対応するNETCONFメッセージは常に整形式XML文書であることを保証します。
For example:
例えば：
module my-config {
namespace "http://example.com/schema/config";
prefix "co";
container system { ... } container routing { ... } }
容器システム{...}コンテナルーティング{...}}
could be encoded in NETCONF as:
NETCONFにとしてエンコードすることができます：
<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>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集-config>の<対象> <ランニング/> </ target>を<config>の<システムのxmlns = "http://example.com/schema/config"> <！ - ここでは、システムデータ - > </システム> <ルーティングのxmlns = "http://example.com/schema/config"> <！ - ここでは、ルーティングデータ - > </ルーティング> </ config>の</編集-config>の</ RPC>
YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form:
YANGモジュールおよびサブモジュールは、通常、ファイルに保存されたファイルごとに1つのモジュールまたはサブモジュールいます。ファイルの名前は次の形式にする必要があります。
module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
モジュールまたは - サブモジュール名[「@」改訂日付]（「.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言語モジュールを定義している間、ツールは、パフォーマンスと管理性の理由から独立してサブモジュールをコンパイルすることがあります。サブモジュールは、凝集モジュールにリンクされるまで、サブモジュールのコンパイル時に検出することができないエラーと警告を遅延させることができます。
All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES], which is a globally unique URI [RFC3986]. A NETCONF client or server uses the namespace during XML encoding of data.
すべてYANG定義はグローバルにユニークなURI [RFC3986]で特定のXML名前空間[XML-NAMES]にバインドされているモジュール内で指定されています。 NETCONFクライアントまたはサーバは、データのXMLエンコード時の名前空間を使用しています。
Namespaces for modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]に掲載されたモジュールの名前空間はIANAによって割り当てられなければならない、第14章を参照。
Namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces, for example by using the enterprise or organization name in the namespace.
プライベートモジュールの名前空間は、中央レジストリせずにモジュールを所有している組織によって割り当てられます。名前空間URIは、選択されなければならないので、名前空間に企業や組織名を使用して、例えば、標準またはその他の企業の名前空間と衝突することができません。
The "namespace" statement is covered in Section 7.1.3.
「名前空間」文は、セクション7.1.3で覆われています。
YANG defines an XML namespace for NETCONF <edit-config> operations and <error-info> content. The name of this namespace is "urn:ietf:params:xml:ns:yang:1".
YANGは、NETCONF <編集-config>の操作と<エラー情報>コンテンツのためのXML名前空間を定義します。この名前空間の名前は "URN：IETF：のparams：XML：NS：陽：1"。
Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language.
グループ、タイプ、および識別名は、彼らはむしろ、それらが使用される文脈よりも、定義されているコンテキストで解決されています。グループ、のtypedef、およびアイデンティティのユーザーはモジュールをインポートしたり、元の定義によって行われたすべての参照を満たすためにサブモジュールを含める必要はありません。これは、従来のプログラミング言語の静的スコープのように振る舞います。
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.
モジュールは、グループ化が第二のモジュールで使用されるときタイプが、参照されたグループを定義している場合、例えば、タイプは、元のモジュールではなく、第二のモジュールのコンテキストで解決されます。あいまいがないため、両方のモジュールは、タイプを定義した場合、競合を超える心配がありません。
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文の下にネストされて表示されることがあります。これは、種類やグループではなく、階層の最上位レベルでそれらを置くよりも、それらが使用されている場所の近くに定義することができます。近接は、読みやすさを向上させます。
Scoping also allows types to be defined without concern for naming conflicts between types in different submodules. Type names can be specified without adding leading strings designed to prevent name collisions within large modules.
スコープもタイプが異なるサブモジュール内の型間の競合を命名するために気にせずに定義することができます。タイプ名は、大規模なモジュール内の名前の衝突を防ぐために設計された主要な文字列を追加することなく、指定することができます。
Finally, scoping allows the module author to keep types and groupings private to their module or submodule, preventing their reuse. Since only top-level types and groupings (i.e., those appearing as substatements to a module or submodule statement) can be used outside the module or submodule, the developer has more control over what pieces of their module are presented to the outside world, supporting the need to hide internal information and maintaining a boundary between what is shared with the outside world and what is kept private.
最後に、スコープはその再利用を防止し、そのモジュールまたはサブモジュールにプライベート型とグループ化を維持するためのモジュールの作者が可能になります。唯一のトップレベルの種類とグループ化（すなわち、モジュールまたはサブモジュール文のサブステートメントとして表示されるもの）がモジュールまたはサブモジュール外で使用することができますので、開発者は、支持、外の世界に提示され、そのモジュールのどの部分をより詳細に制御を持っています内部情報とどのような外の世界と共有されており、どのような秘密に保たれているとの間の境界を維持することを非表示にする必要があります。
Scoped definitions MUST NOT shadow definitions at a higher scope. A type or grouping cannot be defined if a higher level in the schema hierarchy has a definition with a matching identifier.
スコープ定義は高いスコープで定義シャドウてはなりません。スキーマの階層のより高いレベルが、一致する識別子との定義を有する場合タイプまたはグループを定義することができません。
A reference to an unprefixed type or grouping, or one which uses the prefix of the current module, is resolved by locating the closest matching "typedef" or "grouping" statement among the immediate substatements of each ancestor statement.
接頭辞タイプまたはグループ、または現在のモジュールの接頭辞を使用するものへの言及は、各祖先文の即時サブステートメントのうち、最も近いマッチング「のtypedef」または「グループ」ステートメントを配置することによって解決されます。
Conformance is a measure of how accurately a device follows the model. Generally speaking, devices are responsible for implementing the model faithfully, allowing applications to treat devices which implement the model identically. Deviations from the model can reduce the utility of the model and increase fragility of applications that use it.
適合性は、デバイスモデルを以下の方法を正確にの尺度です。一般的に言えば、デバイスは、アプリケーションが同一のモデルを実装するデバイスを処理するためにできるように、忠実にモデルを実装するための責任があります。モデルからの逸脱は、モデルの有用性を削減し、それを使用するアプリケーションの脆弱性を高めることができます。
YANG modelers have three mechanisms for conformance:
YANGモデラーは、適合性のための3つのメカニズムがあります。
o the basic behavior of the model
モデルの基本的な振る舞いO
o optional features that are part of the model
モデルの一部であるオプション機能O
o deviations from the model
モデルからのO偏差
We will consider each of these in sequence.
私たちは、順番にこれらのそれぞれを検討します。
The model defines a contract between the NETCONF client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract.
このモデルは、両方の当事者が他のモデル化されたデータの後ろの構文と意味を知っている信仰を持つことができNETCONFクライアントとサーバの間の契約を定義します。 YANGの強さは、この契約の強さです。
In many models, the modeler will allow sections of the model to be conditional. The device controls whether these conditional portions of the model are supported or valid for that particular device.
多くのモデルでは、モデル作成者はモデルのセクションを条件付きにすることができます。デバイスは、モデルのこれらの条件部分は、その特定のデバイス用にサポートまたは有効であるかどうかを制御します。
For example, a syslog data model may choose to include the ability to save logs locally, but the modeler will realize that this is only possible if the device has local storage. If there is no local storage, an application should not tell the device to save logs.
たとえば、syslogのデータモデルは、ローカルにログを保存する機能を含めることを選択するかもしれませんが、デバイスはローカルストレージを持っている場合、モデラーは、これが唯一の可能であることを理解するであろう。ローカルストレージがない場合、アプリケーションは、ログを保存するようにデバイスを伝えるべきではありません。
YANG supports this conditional mechanism using a construct called "feature". Features give the modeler a mechanism for making portions of the module conditional in a manner that is controlled by the device. The model can express constructs that are not universally present in all devices. These features are included in the model definition, allowing a consistent view and allowing applications to learn which features are supported and tailor their behavior to the device.
YANGは、「機能」と呼ばれる構造を使用して、この条件付きのメカニズムをサポートしています。機能がモデラーに装置によって制御されるように、条件付きモジュールの部分を製造するためのメカニズムを与えます。モデルは普遍のすべてのデバイスには存在しない構造を表現することができます。これらの機能は、一貫性のあるビューを可能とするアプリケーションは、機能がサポートされている学習し、デバイスに彼らの行動を調整することができ、モデルの定義に含まれます。
A module may declare any number of features, identified by simple strings, and may make portions of the module optional based on those features. If the device supports a feature, then the corresponding portions of the module are valid for that device. If the device doesn't support the feature, those parts of the module are not valid, and applications should behave accordingly.
モジュールは単純な文字列によって識別された特徴の任意の数を宣言することができ、これらの特徴に基づいて、モジュールの任意の部分を行うことができます。デバイスが機能をサポートしている場合は、モジュールの対応する部分には、そのデバイスの有効です。デバイスが機能をサポートしていない場合は、モジュールの部分は有効ではなく、アプリケーションはそれに応じて振る舞うべき。
Features are defined using the "feature" statement. Definitions in the module that are conditional to the feature are noted by the "if-feature" statement with the name of the feature as its argument.
特長は、「機能」ステートメントを使用して定義されています。機能への条件としているモジュール内の定義は、引数としての機能の名前で、「IF-機能」文で指摘されています。
Further details are available in Section 7.18.1.
詳細は、セクション7.18.1でご利用いただけます。
In an ideal world, all devices would be required to implement the model exactly as defined, and deviations from the model would not be allowed. But in the real world, devices are often not able or designed to implement the model as written. For YANG-based automation to deal with these device deviations, a mechanism must exist for devices to inform applications of the specifics of such deviations.
理想的な世界では、すべてのデバイスが定義されたとおりにモデルを実装するために必要とされるであろうし、モデルからの偏差が許可されません。しかし、現実の世界では、デバイスは、しばしばことや書かれたモデルを実装するために設計されていません。これらのデバイスのずれに対処するためYANG・ベースの自動化のために、この機構は、このような偏差の仕様のアプリケーションに通知するデバイスのために存在している必要があります。
For example, a BGP module may allow any number of BGP peers, but a particular device may only support 16 BGP peers. Any application configuring the 17th peer will receive an error. While an error may suffice to let the application know it cannot add another peer, it would be far better if the application had prior knowledge of this limitation and could prevent the user from starting down the path that could not succeed.
例えば、BGPモジュールは、BGPピアの任意の数が、特定のデバイスのみ16個のBGPピアをサポートすることができる可能にすることができます。第17回ピアを設定する任意のアプリケーションがエラーを受信します。エラーは、アプリケーションが、それは別のピアを追加することはできません知っているようには十分かもしれないが、アプリケーションがこの制限の事前知識を持っていたし、成功することができませんでした道を開始するからユーザーを防ぐことができれば、それははるかに良いでしょう。
Device deviations are declared using the "deviation" statement, which takes as its argument a string that identifies a node in the schema tree. The contents of the statement details the manner in which the device implementation deviates from the contract as defined in the module.
デバイス偏差は、引数としてスキーマツリー内のノードを識別する文字列を取る「ずれ」の文を、使用して宣言されています。文の内容は、モジュールで定義されているデバイスの実装は、契約から逸脱する様子を詳述します。
Further details are available in Section 7.18.3.
詳細は、セクション7.18.3でご利用いただけます。
The namespace URI MUST be advertised as a capability in the NETCONF <hello> message to indicate support for the YANG module by a NETCONF server. The capability URI advertised MUST be of the form:
名前空間URIは、NETCONFサーバによってYANGモジュールのサポートを示すために、NETCONF <こんにちは>メッセージの機能として宣伝されなければなりません。 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 )
機能文字列=名前空間-URI [パラメータリスト]パラメータリスト= "？"パラメータ*（「＆」パラメータ）パラメータ=リビジョンパラメータ/モジュールのパラメータ/特徴パラメータ/偏差パラメータリビジョンパラメータ=「リビジョン=」改訂日付モジュールパラメータ=「モジュール=」モジュール名機能パラメータ= "機能=" 機能*（ "" 機能）偏差パラメータ= "偏差=" 偏差*（ "" 偏差）
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).
「リビジョン日付は」モジュールのリビジョンが（セクション7.1.9を参照）、それは「モジュール」の文に指定されているNETCONFサーバを実装、「モジュール名が」モジュールの名前であることである場合には、（7.1節を参照してください）それは「名前空間」の文に指定されている「名前空間URIが」（7.1.3項を参照）、モジュールの名前空間URIで、「機能」（セクション7.18.1を参照）、デバイスによって実装オプション機能の名前です。 「ずれ」が（セクション7.18.3を参照）、デバイス偏差を規定するモジュールの名前です。
In the parameter list, each named parameter MUST occur at most once.
パラメータリストでは、それぞれの名前付きパラメータは、最高1回行わなければなりません。
Servers indicate the names of supported modules via the <hello> message. Module namespaces are encoded as the base URI in the capability string, and the module name is encoded as the "module" parameter to the base URI.
サーバーは、<ハロー>メッセージを介してサポートされるモジュールの名前を示しています。モジュールの名前空間は、機能文字列内のベースURIとしてエンコードされ、モジュール名は、ベースURIに「モジュール」のパラメータとしてエンコードされます。
A server MUST advertise all revisions of all modules it implements.
サーバーは、それが実装されたすべてのモジュールのすべてのリビジョンを宣伝しなければなりません。
For example, this <hello> message advertises one module "syslog".
たとえば、これは<こんにちは>メッセージは、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>
<ハローのxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <機能> http://example.com/syslog?module=syslog&アンプ;リビジョン= 2008-04-01 </能力> </こんにちは>
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.
サーバーは、<ハロー>メッセージを介してサポートされている機能の名称を示しています。 <こんにちは>メッセージでは、機能はURI内の「機能」パラメータでエンコードされています。このパラメータの値は、デバイスが特定のモジュールのサポート機能名のカンマ区切りリストです。
For example, this <hello> message advertises one module, informing the client that it supports the "local-storage" feature of module "syslog". <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capability> http://example.com/syslog?module=syslog&features=local-storage </capability> </hello>
たとえば、これは<こんにちは>メッセージは、モジュール「のsyslog」の「ローカル・ストレージ」機能をサポートしていることをクライアントに通知する、一つのモジュールをアドバタイズします。 <ハローのxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <機能> http://example.com/syslog?module=syslog&アンプ;機能=ローカル・ストレージ</機能> < /こんにちは>
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".
たとえば、これは<こんにちは>メッセージは、モジュール「私、開発者」に記載された偏差に応じてモジュール「のsyslog」から逸脱し、クライアントに通知する、二つのモジュールをアドバタイズします。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capability> http://example.com/syslog?module=syslog&deviations=my-devs </capability> <capability> http://example.com/my-deviations?module=my-devs </capability> </hello>
<ハローのxmlns = "壷：IETF：のparams：XML：NS：NETCONF：ベース：1.0"> <機能> http://example.com/syslog?module=syslog&アンペア;偏差=私の-開発者</機能> <機能> http://example.com/my-deviations?module=my-devs </機能> </こんにちは>
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プロトコルメッセージを介して向けられていない方法で、構成データストアを変更することを可能にします。例えば、データ・モデルは、クライアントが1つを提供しない場合、システム生成された値が割り当てられているリーフを定義することができます。これらの変更が許可されている状況を指定するための正式な機構は、本明細書の範囲外です。
The YANG syntax is similar to that of SMIng [RFC3780] and programming languages like C and C++. This C-like syntax was chosen specifically for its readability, since YANG values the time and effort of the readers of models above those of modules writers and YANG tool-chain developers. This section introduces the YANG syntax.
YANG構文はSMIng [RFC3780]とCとC ++のようなプログラミング言語の場合と同様です。 YANG、モジュールライターとYANGツールチェーンの開発のものの上にモデルの読者の時間と労力値ので、このCのような構文は、その読みやすさのために特別に選ばれました。このセクションでは、YANG構文を紹介します。
YANG modules use the UTF-8 [RFC3629] character encoding.
YANGモジュールはUTF-8 [RFC3629]文字エンコーディングを使用しています。
YANG modules are parsed as a series of tokens. This section details the rules for recognizing tokens from an input stream. YANG tokenization rules are both simple and powerful. The simplicity is driven by a need to keep the parsers easy to implement, while the power is driven by the fact that modelers need to express their models in readable formats.
YANGモジュールは、一連のトークンとして解析されます。このセクションでは、入力ストリームからトークンを認識するための規則を詳述します。 YANGのトークン化ルールはシンプルかつパワフルな両方です。シンプルさは、電源をモデラーが読める形式で自分のモデルを表現する必要があるという事実によって駆動される一方で、実装が容易パーサを維持する必要性によって駆動されます。
Comments are C++ style. A single line comment starts with "//" and
ends at the end of the line. A block comment is enclosed within "/*"
and "*/".
A token in YANG is either a keyword, a string, a semicolon (";"), or braces ("{" or "}"). A string can be quoted or unquoted. A keyword is either one of the YANG keywords defined in this document, or a prefix identifier, followed by ":", followed by a language extension keyword. Keywords are case sensitive. See Section 6.2 for a formal definition of identifiers.
YANGにおけるトークンは、キーワード、文字列、セミコロン（「;」）のいずれかであるか、または括弧（「{」または「}」）。文字列を引用符で囲むか、引用符で囲まれていないことができます。キーワードが続くこの文書、またはプレフィックス識別子で定義されてYANGキーワード、のいずれかである「：」、言語拡張キーワードが続きます。キーワードは大文字と小文字が区別されます。識別子の正式な定義については、セクション6.2を参照してください。
If a string contains any space or tab characters, a semicolon (";"),
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
it MUST be enclosed within double or single quotes.
If the double-quoted string contains a line break followed by space or tab characters that are used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. In this process, a tab character is treated as 8 space characters.
二重引用符で囲まれた文字列は、YANGファイル内のレイアウトに応じてテキストをインデントするために使用されているスペースやタブ文字が続く改行が含まれている場合は、この先頭の空白は文字列から取り除かれ、二重の列を含めへとアップ引用符文字、またはいずれか早い方最初の非空白文字に。このプロセスでは、タブ文字は8つの空白文字として扱われます。
If the double-quoted string contains space or tab characters before a line break, this trailing whitespace is stripped from the string.
二重引用符で囲まれた文字列が改行の前にスペースまたはタブ文字が含まれている場合は、この末尾の空白は文字列から取り除かれます。
A single-quoted string (enclosed within ' ') preserves each character within the quotes. A single quote character cannot occur in a single-quoted string, even when preceded by a backslash.
（「'で囲まれた）の単一引用符で囲まれた文字列は引用符内の各文字を保持します。単一引用符文字はバックスラッシュが先行した場合であっても、単一引用符で囲まれた文字列で発生することはできません。
Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash:
二重引用符で囲まれた文字列（「"で囲まれた）の中では、バックスラッシュ文字はすぐにバックスラッシュの後に続く文字に依存の特殊文字を、導入されています。
\n new line \t a tab character \" a double quote \\ a single backslash
\ nは改行\ Tタブ文字\」二重引用符\\単一のバックスラッシュ
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.
引用符で囲まれた文字列は、プラス記号（「+」）が続いている場合は、別の引用符で囲まれた文字列が続き、二つの文字列は、複数の連結は、1つの文字列を構築することができ、1つの文字列に連結されています。空白の切捨てと二重引用符で囲まれた文字列でバックスラッシュでエスケープ文字の置換は、連結前に行われます。
The following strings are equivalent:
以下の文字列は等価です。
hello "hello" 'hello' "hel" + "lo" 'hel' + "lo"
「ハロー」ハロー「こんにちは」「全体」+「イオ」「たくさん」+「イオ」
The following examples show some special strings:
次の例では、いくつかの特別な文字列を示しています。
"\"" - string containing a double quote '"' - string containing a double quote "\n" - string containing a new line character '\n' - string containing a backslash followed by the character n
「\」「 - 文字列の二重引用符を含む「」」 - 文字列は二重引用符を含む 『\ n』は - 文字列が改行文字を含む 『\ n』は - 文字nはバックスラッシュを含む文字列
The following examples show some illegal strings:
次の例では、いくつかの違法な文字列を示しています。
'''' - a single-quoted string cannot contain single quotes """ - a double quote must be escaped in a double-quoted string
「」「」 - 単一引用符で囲まれた文字列は、単一引用符を含めることはできません「」」 - 二重引用符は、二重引用符で囲まれた文字列にエスケープする必要があります
The following strings are equivalent:
以下の文字列は等価です。
"first line
second line"
"first line\n" + " second line"
「最初の行\ n」+「セカンドライン」
Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. Implementations MUST support identifiers up to 64 characters in length. Identifiers are case sensitive. The identifier syntax is formally defined by the rule "identifier" in Section 12. Identifiers can be specified as quoted or unquoted strings.
識別子は名前でYANGアイテムの種類を識別するために使用されています。各識別子は、ゼロ個以上のASCII文字に続く大文字または小文字のASCII文字またはアンダースコア文字で始まり、数字は、文字、ハイフン、ドットを強調する。実装は、長さは64文字までの識別子をサポートしなければなりません。識別子は大文字と小文字が区別されます。識別子の構文は、正式に12識別子が引用されたか、引用符で囲まれていない文字列として指定することができ、セクション内のルール「識別子」によって定義されます。
Each identifier is valid in a namespace that depends on the type of the YANG item being defined. All identifiers defined in a namespace MUST be unique.
各識別子は定義されているYANGアイテムの種類によって異なり、ネームスペースで有効です。名前空間で定義されたすべての識別子はユニークでなければなりません。
o All module and submodule names share the same global module identifier namespace.
Oすべてのモジュールおよびサブモジュール名が同じグローバルモジュール識別子の名前空間を共有しています。
o All extension names defined in a module and its submodules share the same extension identifier namespace.
Oモジュールとそのサブモジュールで定義されたすべての拡張子名は同じ拡張識別子の名前空間を共有しています。
o All feature names defined in a module and its submodules share the same feature identifier namespace.
Oモジュールとそのサブモジュールで定義されたすべての機能名は、同じ機能の識別子の名前空間を共有しています。
o All identity names defined in a module and its submodules share the same identity identifier namespace.
Oモジュールとそのサブモジュールで定義されたすべてのID名が同じID識別子の名前空間を共有しています。
o All derived type names defined within a parent node or at the top level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that typedef, and it MUST NOT define a typedef with the same name.
O親ノード内またはモジュールまたはサブモジュールのトップレベルで定義されたすべての派生型の名前は、同じタイプの識別子の名前空間を共有します。この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。これは、任意の子孫ノードは、そのtypedefをを使用することができ、そしてそれは同じ名前でのtypedefを定義してはならないことを意味します。
o All grouping names defined within a parent node or at the top level of the module or its submodules share the same grouping identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that grouping, and it MUST NOT define a grouping with the same name.
O親ノード内またはモジュールまたはサブモジュールのトップレベルで定義されたすべてのグループ名が同じグループ識別子の名前空間を共有します。この名前空間は、親ノードまたはモジュールのすべての子孫ノードにスコープされます。これは、任意の子孫ノードは、そのグループ化を使用することができ、そしてそれは同じ名前のグループを定義してはならないことを意味します。
o All leafs, leaf-lists, lists, containers, choices, rpcs, notifications, and anyxmls defined (directly or through a uses statement) within a parent node or at the top level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the closest ancestor node that is not a case or choice node.
O親ノード内またはモジュールまたはそのサブモジュールのトップレベルに（直接またはステートメントを使用して）定義されたすべてのリーフ、リーフリスト、リスト、コンテナ、選択肢、RPCを、通知、およびanyxmlsは同じ識別子の名前空間を共有しています。親ノードは、ケースノードでない限り、この名前空間は、親ノードまたはモジュールにスコープされています。その場合には、名前空間は、ケースまたは選択ノードではない、最も近い祖先ノードにスコープされます。
o All cases within a choice share the same case identifier namespace. This namespace is scoped to the parent choice node.
O選択内のすべての例は、同じケース識別子の名前空間を共有しています。この名前空間は、親の選択ノードにスコープされます。
Forward references are allowed in YANG.
前方参照はYANGで許可されています。
A YANG module contains a sequence of statements. Each statement starts with a keyword, followed by zero or one argument, followed either by a semicolon (";") or a block of substatements enclosed within braces ("{ }"):
YANGモジュールは、一連の文が含まれています。各ステートメントはキーワードで始まり、ゼロまたは1つの引数が続く、いずれかセミコロン（「;」）が続く（「{}」）、または括弧で囲まれサブステートメントのブロック：
statement = keyword [argument] (";" / "{" *statement "}")
文=キーワード[引数]（ ";" / "{" *ステートメント "}"）
The argument is a string, as defined in Section 6.1.2.
6.1.2項で定義されるように引数は、文字列です。
A module can introduce YANG extensions by using the "extension" keyword (see Section 7.17). The extensions can be imported by other modules with the "import" statement (see Section 7.1.5). When an imported extension is used, the extension's keyword MUST be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MUST be qualified with the module's prefix.
モジュールは、「拡張子」のキーワード（7.17項を参照）を使用してYANG拡張を導入することができます。拡張子が「インポート」文を使用して、他のモジュールによってインポートすることができます（7.1.5項を参照してください）。インポートされた拡張子を使用する場合は、拡張機能のキーワードは、拡張機能のモジュールがインポートされたとの接頭辞を使用して修飾する必要があります。拡張は、それが定義されているモジュールで使用されている場合、拡張機能のキーワードは、モジュールの接頭辞で修飾する必要があります。
Since submodules cannot include the parent module, any extensions in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the extension.
サブモジュールは親モジュールを含めることはできませんので、サブモジュールにさらされる必要があるモジュール内の任意の拡張子はサブモジュールで定義する必要があります。サブモジュールは、拡張子の定義を見つけるために、このサブモジュールを含めることができます。
If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler.
YANGコンパイラは、未知の文としてYANGモジュールに表示され、特定の拡張子を、（セクション12を参照）をサポートしていない場合は、全体の未知の文は、コンパイラによって無視されるかもしれません。
YANG relies on XML Path Language (XPath) 1.0 [XPATH] as a notation for specifying many inter-node references and dependencies. NETCONF clients and servers are not required to implement an XPath interpreter, but MUST ensure that the requirements encoded in the data model are enforced. The manner of enforcement is an implementation decision. The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context (see Section 6.4.1). An implementation may choose to implement them by hand, rather than using the XPath expression directly.
YANGは、多くのノード間の参照および依存関係を指定するための表記法として、XMLパス言語（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.
XSLT 1.0 [XSLT]（セクション3.1）で使用されるXPath式で使用されるデータモデルは、ルートノードの子のための同じ拡張子で、XPath 1.0の[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.
O名前空間宣言のセットは、XPath式が指定されたモジュール内のすべての「インポート」文プレフィックスと名前空間のペアのセット、および 『名前空間』のステートメントのURIのための 『接頭辞』文の接頭辞があります。
o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used (see Section 7.12).
名前空間接頭辞なしのO名前は、現在のノードの識別子と同じ名前空間に属します。グループ内では、その名前空間は、グループ化を使用した場合の影響を受けている（7.12節を参照してください）。
o The function library is the core function library defined in [XPATH], and a function "current()" that returns a node set with the initial context node.
関数ライブラリO [XPATH]で定義されたコア関数ライブラリ、および初期コンテキストノードとノードセットを返す関数「電流（）」です。
o The set of variable bindings is empty.
O変数バインディングのセットは空です。
The mechanism for handling unprefixed names is adopted from XPath 2.0 [XPATH2.0], and helps simplify XPath expressions in YANG. No ambiguity may ever arise because YANG node identifiers are always qualified names with a non-null namespace URI.
接頭辞名を処理するための機構は、XPath 2.0 [XPATH2.0]から採用し、YANGでXPath式を簡素化されています。 YANGノード識別子は常に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文が定義される指定されています。
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のルール「絶対スキーマNODEID」および「子孫-スキーマNODEID」によって定義された2つの形態、「絶対」及び「子孫」を有します。スキーマノード識別子は、スラッシュで区切られた識別子のパス（「/」）から成ります。絶対的なスキーマのノード識別子は、スラッシュの後の最初の識別子は、ローカル・モジュール内のまたはすべてのインポートされたモジュール内の任意の最上位スキーマノードです。
References to identifiers defined in external modules MUST be qualified with appropriate prefixes, and references to identifiers defined in the current module and its submodules MAY use a prefix.
外部モジュールで定義された識別子への参照は、適切な接頭辞で修飾する必要があり、かつ現在のモジュールで定義された識別子とそのサブモジュールへの参照は、接頭辞を使用するかもしれません。
For example, to identify the child node "b" of top-level node "a", the string "/a/b" can be used.
例えば、トップレベルノード「A」の子ノードを識別するために、「B」、文字列「/ A / B」を使用することができます。
The following sections describe all of the YANG statements.
次のセクションでは、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で定義されたすべてのサブステートメントを持っていなくても文がサブステートメントとしてベンダー固有の拡張機能を持つことができることに注意してください。たとえば、「説明」の文は、YANGで定義されたすべてのサブステートメントはありませんが、以下が有効です。
description "some text" { acme:documentation-flag 5; }
DESCRIPTION「テキスト」{ACME：ドキュメントフラグ5。 }
The "module" statement defines the module's name, and groups all statements that belong to the module together. The "module" statement's argument is the name of the module, followed by a block of substatements that hold detailed module information. The module name follows the rules for identifiers in Section 6.2.
「モジュール」のステートメントは、モジュールの名前を定義し、一緒にグループモジュールに属するすべての文を。 「モジュール」文の引数には、詳細なモジュール情報を保持するサブステートメントのブロックに続いて、モジュールの名前です。モジュール名は、6.2節での識別子の規則に従います。
Names of modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]に掲載されたモジュールの名前は、IANAによって割り当てなければならない、セクション14を参照してください。
Private module names are assigned by the organization owning the module without a central registry. It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the module name.
プライベートモジュール名は、中央レジストリせずにモジュールを所有している組織によって割り当てられます。モジュール名の接頭辞として、企業や組織名を使用することにより、例えば、標準または他のエンタープライズ・モジュールとサブモジュールとの衝突の確率が低いだろうモジュール名を選択することをお勧めします。
A module typically has the following layout:
モジュールは、一般的に次のようなレイアウトになっています。
module <module-name> {
モジュール<モジュール名> {
// header information
<yang-version statement>
<namespace statement>
<prefix statement>
// linkage statements <import statements> <include statements>
//リンケージ文<import文> <include文を>
// meta information <organization statement> <contact statement> <description statement> <reference statement>
//メタ情報<組織声明> <接触声明> <説明書> <参考書>
// revision history <revision statements>
//改訂履歴<改正文>
// module definitions <other statements> }
//モジュール定義<他の文>}
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| namespace | 7.1.3 | 1 |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
The optional "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument is a string. If present, it MUST contain the value "1", which is the current YANG version and the default value.
オプションの「ヤン・バージョン」のステートメントは、モジュールの開発に使用されたYANG言語のバージョンを指定します。文の引数は文字列です。存在する場合、それは現在の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」以外のバージョンについては、「ヤン・バージョン」文（ここで定義されたバージョン）の取り扱いについては、この仕様の範囲外です。より高いバージョンを定義する任意の文書は、そのようなより高いバージョンの下位互換性を定義する必要があります。
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.
「名前空間」ステートメントは（詳細については、セクション7.12を参照）のグループ内で定義されたデータノード識別子を除いて、モジュールで定義されているすべての識別子がで修飾されたXML名前空間を定義します。 「名前空間」の文への引数は、名前空間のURIです。
See also Section 5.3.
また、5.3節を参照してください。
The "prefix" statement is used to define the prefix associated with the module and its namespace. The "prefix" statement's argument is the prefix string that is used as a prefix to access a module. The prefix string MAY be used to refer to definitions contained in the module, e.g., "if:ifName". A prefix follows the same rules as an identifier (see Section 6.2).
「接頭辞」文はモジュールとその名前空間に関連付けられている接頭辞を定義するために使用されます。 「接頭辞」文の引数には、モジュールにアクセスするための接頭辞として使用されるプレフィックス文字列です。接頭文字列は、「：のifName場合」、例えば、モジュールに含まれる定義を指すために使用することができます。接頭語（セクション6.2を参照）識別子と同じ規則に従います。
When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. To improve readability of the NETCONF XML, a NETCONF client or server that generates XML or XPath that use prefixes SHOULD use the prefix defined by the module, unless there is a conflict.
「モジュール」文の中で使用する場合、「接頭辞」の文では、このモジュールをインポートするときに使用する接頭辞を定義します。競合がある場合を除きNETCONFのXMLの可読性を向上させるために、接頭辞を使用するXMLやXPathを生成NETCONFクライアントまたはサーバは、モジュールで定義された接頭辞を使用すべきです。
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モジュールの可読性を向上させるために、モジュールによって定義されたプレフィックスを使用すべきです。競合がある場合、すなわち、両方が同じプレフィックスを定義している二つの異なるモジュールがインポートされ、それらの少なくとも1つは、異なる接頭辞でインポートする必要があります。
All prefixes, including the prefix for the module itself MUST be unique within the module or submodule.
モジュール自体のプレフィックスを含むすべてのプレフィックスは、モジュールまたはサブモジュール内で一意でなければなりません。
The "import" statement makes definitions from one module available inside another module or submodule. The argument is the name of the module to import, and the statement is followed by a block of substatements that holds detailed import information. When a module is imported, the importing module may: o use any grouping and typedef defined at the top level in the imported module or its submodules.
「インポート」の文は、別のモジュールまたはサブモジュール内の一つのモジュールからの定義を使用できるようになります。引数には、インポートするモジュールの名前で、文は、詳細なインポート情報を保持しているサブステートメントのブロックが続いています。モジュールがインポートされると、インポートモジュールができる：Oインポートモジュールまたはサブモジュールのトップレベルで定義された任意のグループとのtypedefを使用します。
o use any extension, feature, and identity defined in the imported module or its submodules.
Oインポートモジュールまたはサブモジュールで定義された拡張、機能、およびアイデンティティを使用します。
o use any node in the imported module's schema tree in "must", "path", and "when" statements, or as the target node in "augment" and "deviation" statements.
Oでインポートモジュールのスキーマ・ツリー内の任意のノードを使用して「必要」、「パス」、および「いつ」文、または「増強」と「ずれ」ステートメント内のターゲットノードとして。
The mandatory "prefix" substatement assigns a prefix for the imported module that is scoped to the importing module or submodule. Multiple "import" statements may be specified to import from different modules.
必須の「接頭辞」サプは、インポートモジュールまたはサブモジュールにスコープされ、インポートモジュールのプレフィックスを割り当てます。複数の「インポート」ステートメントが別のモジュールからインポートする指定することができます。
When the optional "revision-date" substatement is present, any typedef, grouping, extension, feature, and identity referenced by definitions in the local module are taken from the specified revision of the imported module. It is an error if the specified revision of the imported module does not exist. If no "revision-date" substatement is present, it is undefined from which revision of the module they are taken.
オプションの「改訂日付」サプが存在する場合、ローカルモジュールの定義によって参照される任意のtypedef、グループ化、拡張、機能、及び同一性は、インポートモジュールの指定されたリビジョンから取られます。インポートされたモジュールの指定されたリビジョンが存在しない場合は、エラーになります。何の「改訂日付」サブステートメントが存在しない場合、それは彼らが撮影されているモジュールのどのリビジョンから定義されていません。
Multiple revisions of the same module MUST NOT be imported.
同じモジュールの複数のリビジョンを輸入してはなりません。
The import's Substatements
インポートのサブステートメント
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| prefix | 7.1.4 | 1 |
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The import's "revision-date" statement is used to specify the exact version of the module to import. The "revision-date" statement MUST match the most recent "revision" statement in the imported module.
インポートの「改訂日付」文はインポートするモジュールの正確なバージョンを指定するために使用されます。 「改正-日」の文は、インポートされたモジュール内の最新の「改正」の文と一致しなければなりません。
The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. The argument is an identifier that is the name of the submodule to include. Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module.
文はそのサブモジュールの親モジュールへ、またはその親モジュールの別のサブモジュールが利用可能なサブモジュールからコンテンツを作るために使用されている「が含まれます」。引数が含まれるようにサブモジュールの名前である識別子です。モジュールは、唯一の「所属-に」（7.2.2項を参照）文によって定義されるように、そのモジュールに属しているサブモジュールを含めることが許可されています。サブモジュールは、同じモジュールに属する他のサブモジュールを含めることが許可されています。
When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule.
モジュールは、サブモジュールを含む場合、それはモジュールのノード階層にサブモジュールの内容を組み込みます。サブモジュールは、別のサブモジュールが含まれている場合、対象のサブモジュールの定義は、現在のサブモジュールで使用可能になります。
When the optional "revision-date" substatement is present, the specified revision of the submodule is included in the module. It is an error if the specified revision of the submodule does not exist. If no "revision-date" substatement is present, it is undefined which revision of the submodule is included.
オプションの「改訂日付」サプが存在する場合、サブモジュールの指定されたリビジョンは、モジュールに含まれています。サブモジュールの指定されたリビジョンが存在しない場合は、エラーになります。何の「改訂日付」サブステートメントが存在しない場合には、サブモジュールのリビジョンが含まれている定義されていません。
Multiple revisions of the same submodule MUST NOT be included.
同じサブモジュールの複数のリビジョンを含んではいけません。
The includes's Substatements
サブステートメントを含んでいます
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+
The "organization" statement defines the party responsible for this module. The argument is a string that is used to specify a textual description of the organization(s) under whose auspices this module was developed.
「組織」の文は、このモジュールの責任者を定義します。引数には、このモジュールが開発されたその後援の下、組織（複数可）のテキスト記述を指定するために使用される文字列です。
The "contact" statement provides contact information for the module. The argument is a string that is used to specify contact information for the person or persons to whom technical queries concerning this module should be sent, such as their name, postal address, telephone number, and electronic mail address.
「連絡先」のステートメントは、モジュールの連絡先情報を提供します。引数には、自分の名前、住所、電話番号、電子メールアドレスとして、送信されるべき人や、このモジュールに関する技術的な問い合わせを誰に人のための連絡先情報を指定するために使用される文字列です。
The "revision" statement specifies the editorial revision history of the module, including the initial revision. A series of revision statements detail the changes in the module's definition. The argument is a date string in the format "YYYY-MM-DD", followed by a block of substatements that holds detailed revision information. A module SHOULD have at least one initial "revision" statement. For every published editorial change, a new one SHOULD be added in front of the revisions sequence, so that all revisions are in reverse chronological order.
「改正」の文は、最初のリビジョンを含むモジュールの編集改訂履歴を、指定します。改正文の詳細一連のモジュールの定義の変更。引数には、詳細なリビジョン情報を保持しているサブステートメントのブロックが続くフォーマット「YYYY-MM-DD」の日付文字列です。モジュールは、少なくとも一つの初期の「改正」の文を持っているべきです。すべてのリビジョンが新しい順になるように、すべての出版され社説変更のために、新しいものは、改正シーケンスの前に追加する必要があります。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
import ietf-yang-types {
prefix "yang";
}
include acme-types;
アクメ・タイプが含まれます。
organization "ACME Inc."; contact "Joe L. User
組織「ACME社」。 「ジョーL.ユーザーに連絡
ACME, Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100 EMail: joe@acme.example.com";
電話：+1 800 555 0100 Eメール：joe@acme.example.com ";
description "The module for entities implementing the ACME protocol.";
説明「ACMEプロトコルを実装するエンティティのためのモジュール。」;
revision "2007-06-09" { description "Initial revision."; }
リビジョン「2007-06-09」{説明「初期リビジョン。」; }
// definitions follow... }
//定義は} ...続きます
While the primary unit in YANG is a module, a YANG module can itself be constructed out of several submodules. Submodules allow a module designer to split a complex model into several pieces where all the submodules contribute to a single namespace, which is defined by the module that includes the submodules.
YANG一次ユニットがモジュールであるが、YANGモジュールは、それ自体がいくつかのサブモジュールから構成することができます。サブモジュールは、モジュールの設計者は、すべてのサブモジュールは、サブモジュールを含むモジュールによって定義される単一の名前空間に寄与するいくつかの部分に複雑なモデルを分割することを可能にします。
The "submodule" statement defines the submodule's name, and groups all statements that belong to the submodule together. The "submodule" statement's argument is the name of the submodule, followed by a block of substatements that hold detailed submodule information. The submodule name follows the rules for identifiers in Section 6.2.
「サブモジュール」の文は、サブモジュールの名前を定義し、一緒にグループサブモジュールに属するすべての文を。 「サブモジュール」文の引数には、詳細なサブモジュールの情報を保持するサブステートメントのブロックが続き、サブモジュールの名前です。サブモジュール名は、6.2節での識別子の規則に従います。
Names of submodules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14.
RFCストリーム[RFC4844]に掲載されたサブモジュールの名前は、IANAによって割り当てなければならない、セクション14を参照してください。
Private submodule names are assigned by the organization owning the submodule without a central registry. It is RECOMMENDED to choose submodule names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the submodule name.
プライベートサブモジュール名は、中央レジストリせずにサブモジュールを所有している組織によって割り当てられます。サブモジュール名の接頭辞として、企業や組織名を使用することにより、例えば、標準または他のエンタープライズ・モジュールとサブモジュールとの衝突の確率が低いだろうサブモジュール名を選択することをお勧めします。
A submodule typically has the following layout:
サブモジュールは、一般的に次のようなレイアウトになっています。
submodule <module-name> {
サブモジュール<モジュール名> {
<yang-version statement>
<文・バージョン>
// module identification <belongs-to statement>
//モジュールの識別<所属-に声明>
// linkage statements <import statements> <include statements>
//リンケージ文<import文> <include文を>
// meta information <organization statement> <contact statement> <description statement> <reference statement>
//メタ情報<組織声明> <接触声明> <説明書> <参考書>
// revision history <revision statements>
//改訂履歴<改正文>
// module definitions <other statements> }
//モジュール定義<他の文>}
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| belongs-to | 7.2.2 | 1 |
| choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 |
| reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+
The "belongs-to" statement specifies the module to which the submodule belongs. The argument is an identifier that is the name of the module.
「所属-に」文はサブモジュールが属するモジュールを指定します。引数には、モジュールの名前である識別子です。
A submodule MUST only be included by the module to which it belongs, or by another submodule that belongs to that module.
サブモジュールは、それが属するモジュールが含まれ、またはそのモジュールに属する別のサブモジュールによってなければなりません。
The mandatory "prefix" substatement assigns a prefix for the module to which the submodule belongs. All definitions in the local submodule and any included submodules can be accessed by using the prefix.
必須の「接頭辞」サプサブモジュールが属するモジュールのプレフィックスを割り当てます。地元のサブモジュールのすべての定義とどの含まサブモジュールは、接頭辞を使用してアクセスすることができます。
The belongs-to's Substatements
所属-にサブステートメント
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| prefix | 7.1.4 | 1 |
+--------------+---------+-------------+
submodule acme-types {
サブモジュールACME、タイプ{
belongs-to "acme-system" {
prefix "acme";
}
import ietf-yang-types { prefix "yang"; }
インポートIETF-ヤン・タイプ{接頭辞「陽」。 }
organization "ACME Inc."; contact "Joe L. User
組織「ACME社」。 「ジョーL.ユーザーに連絡
ACME, Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
Phone: +1 800 555 0100 EMail: joe@acme.example.com";
電話：+1 800 555 0100 Eメール：joe@acme.example.com ";
description "This submodule defines common ACME types.";
説明は「このサブモジュールは、一般的なACMEタイプを定義します。」;
revision "2007-06-09" { description "Initial revision."; }
リビジョン「2007-06-09」{説明「初期リビジョン。」; }
// definitions follows... }
//定義} ...次の
The "typedef" statement defines a new type that may be used locally in the module, in modules or submodules which include it, and by other modules that import from it, according to the rules in
「typedefの」ステートメントは、の規則に従って、それを含むモジュールまたはサブモジュールに、及びそこからインポート他のモジュールにより、モジュール内で局所的に使用することができる新しいタイプを定義します
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.
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ビルトインタイプのいずれかにすることはできません。 typedefがYANGモジュールまたはサブモジュールのトップレベルで定義されている場合、定義されるタイプの名前は、モジュール内で一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| default | 7.3.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.3.2 | 1 |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
The "type" statement, which MUST be present, defines the base type from which this type is derived. See Section 7.4 for details.
存在しなければならない「タイプ」の文では、このタイプが由来する塩基の種類を定義します。詳細については、7.4節を参照してください。
The "units" statement, which is optional, takes as an argument a string that contains a textual definition of the units associated with the type.
オプションである「単位」の文では、引数としてタイプに関連付けられているユニットのテキスト定義を含む文字列を取ります。
The "default" statement takes as an argument a string that contains a default value for the new type.
「デフォルト」の文は、引数として新しいタイプのデフォルト値を含む文字列を取ります。
The value of the "default" statement MUST be valid according to the type specified in the "type" statement.
「デフォルト」の文の値は、「タイプ」文で指定された型に応じて有効である必要があります。
If the base type has a default value, and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type.
基本型は、デフォルト値を持っており、新しい派生型は、新しいデフォルト値を指定しない場合は、基本型のデフォルト値は、新しい派生型のデフォルト値です。
If the type's default value is not valid according to the new restrictions specified in a derived type or leaf definition, the derived type or leaf definition MUST specify a new default value compatible with the restrictions.
型のデフォルト値は派生型や葉の定義で指定された新しい制限に応じて有効でない場合は、派生型や葉の定義が制約と互換性のある新しいデフォルト値を指定する必要があります。
typedef listen-ipv4-address {
type inet:ipv4-address;
default "0.0.0.0";
}
The "type" statement takes as an argument a string that is the name of a YANG built-in type (see Section 9) or a derived type (see Section 7.3), followed by an optional block of substatements that are used to put further restrictions on the type.
「タイプ」は文が引数としてビルトインタイプYANGの名前である文字列を受け取り、さらに置くために使用されているサブステートメントの任意のブロックに続いて、（セクション9を参照）、または派生型は、（7.3節を参照してください）種類の制限。
The restrictions that can be applied depend on the type being restricted. The restriction statements for all built-in types are described in the subsections of Section 9.
適用可能な制限が制限されているタイプによって異なります。すべてのビルトインタイプのための制限文は、第9のサブセクションで説明されています。
+------------------+---------+-------------+
| substatement | section | cardinality |
+------------------+---------+-------------+
| bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n |
| length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 |
| pattern | 9.4.6 | 0..n |
| range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 |
| type | 7.4 | 0..n |
+------------------+---------+-------------+
The "container" statement is used to define an interior data node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed container information.
「コンテナ」の文は、スキーマツリー内の内部データノードを定義するために使用されます。これは、詳細なコンテナ情報を保持するサブステートメントのブロックが続く識別子であり、一つの引数を取ります。
A container node does not have a value, but it has a list of child nodes in the data tree. The child nodes are defined in the container's substatements.
コンテナノードは値を持ちませんが、それはデータツリー内の子ノードのリストを持っています。子ノードは、コンテナのサブステートメントで定義されています。
YANG supports two styles of containers, those that exist only for organizing the hierarchy of data nodes, and those whose presence in the configuration has an explicit meaning.
YANGは、容器の2つのスタイル、データノードの階層を整理するためにのみ存在するもの、およびその存在がコンフィギュレーション内の明示的な意味を持っていたものをサポートしています。
In the first style, the container has no meaning of its own, existing only to contain child nodes. This is the default style.
最初のスタイルでは、コンテナは、子ノードを格納するだけで、既存の、それ自身の意味がありません。これはデフォルトのスタイルです。
For example, the set of scrambling options for Synchronous Optical Network (SONET) interfaces may be placed inside a "scrambling" container to enhance the organization of the configuration hierarchy, and to keep these nodes together. The "scrambling" node itself has no meaning, so removing the node when it becomes empty relieves the user from performing this task.
例えば、同期光ネットワーク（SONET）インターフェイスのオプションをスクランブリングのセットは、構成階層の組織を強化するために、一緒にこれらのノードを維持するために、「スクランブル」容器内に配置することができます。 「スクランブル」ノード自体が意味を持たないので、それが空になったときにノードを除去してこのタスクを実行することからユーザを解放します。
In the second style, the presence of the container itself is configuration data, representing a single bit of configuration data. The container acts as both a configuration knob and a means of organizing related configuration. These containers are explicitly created and deleted.
第二の様式において、容器自体の存在は、コンフィギュレーション・データの単一ビットを表し、コンフィギュレーションデータです。コンテナは、設定ノブと関連する構成を編成する手段の両方として作用します。これらの容器は、明示的に作成され、削除されます。
YANG calls this style a "presence container" and it is indicated using the "presence" statement, which takes as its argument a text string indicating what the presence of the node means.
YANGは、「プレゼンスコンテナ」このスタイルを呼び出し、それがその引数としてノードの存在が何を意味するのかを示すテキスト文字列を受け取り、「プレゼンス」の文を、使用して示されています。
For example, an "ssh" container may turn on the ability to log into the device using ssh, but can also contain any ssh-related configuration knobs, such as connection rates or retry limits.
例えば、「SSH」コンテナは、SSHを使用してデバイスにログインする機能をオンにすることができるだけでなく、そのような接続速度のような任意のSSH関連の設定ノブを含むまたは制限を再試行することができます。
The "presence" statement (see Section 7.5.5) is used to give semantics to the existence of the container in the data tree.
「プレゼンス」の文（7.5.5項を参照）は、データツリー内のコンテナの存在に意味を与えるために使用されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| must | 7.5.3 | 0..n |
| presence | 7.5.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "must" statement, which is optional, takes as an argument a string that contains an XPath expression (see Section 6.4). It is used to formally declare a constraint on valid data. The constraint is enforced according to the rules in Section 8.
オプションである「しなければならない」文は、引数としてXPath式を（6.4節を参照）を含む文字列を取ります。正式に有効なデータ上の制約を宣言するために使用されます。制約は、第8章の規則に従って実施されます。
When a datastore is validated, all "must" constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated.
データストアが確認された場合、すべての制約は、概念的には、データツリー内の各データノードのために一度だけ評価され、「しなければならない」と、使用中のデフォルト値で、すべてのリーフのために（セクション7.6.1を参照してください）。データノードは、データツリーに存在しない、それがデフォルト値を持っていない場合、そのステートメントは評価されません「しなければなりません」。
All such constraints MUST evaluate to true for the data to be valid.
データが有効であるためには、すべてのそのような制約が真と評価されなければなりません。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、概念的6.4.1における定義に加えて、次のコンテキストで評価されています。
o The context node is the node in the data tree for which the "must" statement is defined.
コンテキストノードO「しなければならない」文が定義されているデータツリー内のノードです。
o The accessible tree is made up of all nodes in the data tree, and all leafs with default values in use (see Section 7.6.1).
Oアクセスツリーは、データツリー内のすべてのノードで構成され、かつ、使用中のデフォルト値を持つすべてのリーフ（セクション7.6.1を参照）されます。
The accessible tree depends on the context node:
アクセスツリーはコンテキストノードによって異なります。
o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
コンテキストノードが構成を表す場合、O、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベルのコンフィギュレーションデータノードを有します。
o If the context node represents state data, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
コンテキストノードが状態データを表す場合、O、ツリーは、デバイス上のすべての状態データ、及び<ランニング/>データストアです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベル・データ・ノードを有します。
o If the context node represents notification content, the tree is the notification XML instance document. The XPath root node has the element representing the notification being defined as the only child.
コンテキストノードは、通知内容を表す場合、O、ツリー通知XMLインスタンスドキュメントです。 XPathのルートノードは、唯一の子として定義される通知を表す要素を有します。
o If the context node represents RPC input parameters, the tree is the RPC XML instance document. The XPath root node has the element representing the RPC operation being defined as the only child.
コンテキストノードがRPC入力パラメータを表す場合、O、ツリーは、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出力パラメータを表す場合、O、ツリーは、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エバリュエータを使用する必要がないことを意味します。評価は、実際に行われているどのような実装決定です。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
The "error-message" statement, which is optional, takes a string as an argument. If the constraint evaluates to false, the string is passed as <error-message> in the <rpc-error>.
オプションである「エラーメッセージ」の文では、引数として文字列を取ります。制約がfalseと評価された場合、文字列は、<RPC-エラー>に<エラーメッセージ>として渡されます。
The "error-app-tag" statement, which is optional, takes a string as an argument. If the constraint evaluates to false, the string is passed as <error-app-tag> in the <rpc-error>.
オプションである「エラーアプリ内タグ」の文では、引数として文字列を取ります。制約がfalseと評価された場合、文字列は、<RPC-エラー>内の<error-APP-タグ>として渡されます。
container interface {
leaf ifType {
type enumeration {
enum ethernet;
enum atm;
}
}
leaf ifMTU {
type uint32;
}
must "ifType != 'ethernet' or " +
"(ifType = 'ethernet' and ifMTU = 1500)" {
error-message "An ethernet MTU must be 1500";
}
must "ifType != 'atm' or " +
"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
error-message "An atm MTU must be 64 .. 17966";
}
}
The "presence" statement assigns a meaning to the presence of a container in the data tree. It takes as an argument a string that contains a textual description of what the node's presence means.
「プレゼンス」のステートメントは、データツリー内のコンテナの存在に意味を割り当てます。これは、引数として、ノードの存在が何を意味するのかの説明テキストを含む文字列を取ります。
If a container has the "presence" statement, the container's existence in the data tree carries some meaning. Otherwise, the container is used to give some structure to the data, and it carries no meaning by itself.
コンテナは、「プレゼンス」の文を持っている場合は、データツリー内のコンテナの存在は、いくつかの意味を運びます。そうしないと、コンテナは、データに何らかの構造を与えるために使用され、それはそれ自体では意味を運びません。
See Section 7.5.1 for additional information.
追加情報については、セクション7.5.1を参照してください。
Within a container, the "container", "leaf", "list", "leaf-list", "uses", "choice", and "anyxml" statements can be used to define child nodes to the container.
コンテナ内では、「コンテナ」、「葉」、「リスト」、「リーフリスト」、「用途」、「選択」、および「AnyXMLで」ステートメントがコンテナに子ノードを定義するために使用することができます。
A container node is encoded as an XML element. The element's local name is the container's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
コンテナノードは、XML要素として符号化されます。要素のローカル名は、コンテナの識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
The container's child nodes are encoded as subelements to the container element. If the container defines RPC input or output parameters, these subelements are encoded in the same order as they are defined within the "container" statement. Otherwise, the subelements are encoded in any order.
コンテナの子ノードは、コンテナ要素のサブ要素としてエンコードされています。容器は、RPC入力または出力パラメータを定義している場合、これらのサブエレメントは、それらが「コンテナ」ステートメント内で定義されているのと同じ順序で符号化されます。それ以外の場合は、サブ要素は任意の順序で符号化されています。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, must be prepared to handle the case that a container node without a "presence" statement is not present in the XML.
コンテナノードは、「プレゼンス」の文を持っていないと、子ノードが存在しない場合は、<こちら>または<GET-config>の要求に応答NETCONFサーバは、コンテナ要素を送信しないこともできます。このように、<GET>または<GET-config>の要求のための<RPC-返信>を受け取るクライアントは、「プレゼンス」の文のないコンテナノードは、XMLに存在しない場合に対処するために準備する必要があります。
Containers can be created, deleted, replaced, and modified through <edit-config>, by using the "operation" attribute (see [RFC4741], Section 7.2) in the container's XML element.
コンテナは、作成、削除、置き換え、およびコンテナのXML要素に「オペレーション」属性（[RFC4741]を参照してください、セクション7.2）を使用して、<編集-config>のを介して変更することができます。
If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container.
コンテナは、「プレゼンス」の文と最後の子ノードが削除されていない場合は、NETCONFサーバは、コンテナを削除することができます。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the container node are:
NETCONFサーバは<編集設定>要求を処理するとき、コンテナノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist.
操作は「マージ」または「置換」である場合、それが存在しない場合、ノードが作成されます。
If the operation is "create", the node is created if it does not exist. If the node already exists, a "data-exists" error is returned.
操作は、「作成」されている場合は、それが存在しない場合、ノードが作成されます。ノードがすでに存在する場合は、「データが存在する」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作は「削除」されている場合は、それが存在する場合、ノードが削除されます。ノードが存在しない場合は、「データ・行方不明」エラーが返されます。
Given the following container definition:
次のコンテナの定義を考えます：
container system {
description "Contains various system parameters";
container services {
description "Configure externally available services";
container "ssh" {
presence "Enables SSH";
description "SSH service specific configuration";
// more leafs, containers and stuff here...
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<system> <services> <ssh/> </services> </system>
<システム> <サービス> <SSH /> </サービス> </システム>
Since the <ssh> element is present, ssh is enabled.
<SSH>要素が存在しているので、SSHが有効になっています。
To delete a container with an <edit-config>:
<編集-config>の持つコンテナを削除するには：
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config"> <services> <ssh nc:operation="delete"/> </services> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集-config>の<対象> <ランニング/> </ target>を<config>の<システムのxmlns = "http://example.com/schema/config"> <サービス> <SSH NC：操作= "削除" / > </サービス> </システム> </ config>の</編集-config>の</ RPC>
The "leaf" statement is used to define a leaf node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf information.
「リーフ」の文は、スキーマツリー内のリーフ・ノードを定義するために使用されます。これは、詳細な葉の情報を保持するサブステートメントのブロックが続く識別子であり、一つの引数を取ります。
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.
「リーフ」の文は、特定の内蔵または派生型のスカラ変数を定義するために使用されます。
The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container:
葉のデフォルト値は、葉がデータツリーに存在しない場合、サーバーが使用する値です。デフォルト値の使用は非存在コンテナではありませんスキーマツリーのリーフの最も近い祖先ノードによって異なります。
o If no such ancestor exists in the schema tree, the default value MUST be used.
そのような祖先は、スキーマ・ツリーに存在しない場合はO、デフォルト値が使用されなければなりません。
o Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree, or if the case node is the choice's default case, and no nodes from any other case exist in the data tree.
Oそれ以外の場合、この祖先がケースノードである場合にケースから任意のノードは、データツリーに存在する場合、デフォルト値が使用されなければならない、またはケース・ノードは、選択のデフォルトのケースであり、そして他のケースからのノードに存在しない場合データツリー。
o Otherwise, the default value MUST be used if the ancestor node exists in the data tree.
祖先ノードがデータツリー内に存在する場合にOそうでない場合、デフォルト値が使用されなければなりません。
In these cases, the default value is said to be in use.
これらのケースでは、デフォルト値が使用中であると言われています。
When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value.
デフォルト値が使用されている場合は、サーバが運用葉がその値としてデフォルト値を持つデータツリーに存在したかのように振る舞う必要があります。
If a leaf has a "default" statement, the leaf's default value is the value of the "default" statement. Otherwise, if the leaf's type has a default value, and the leaf is not mandatory, then the leaf's default value is the type's default value. In all other cases, the leaf does not have a default value.
葉は「デフォルト」の文を持っている場合は、葉のデフォルト値は、「デフォルト」の文の値です。葉の形は、デフォルト値を持ち、葉は必須ではありませんそれ以外の場合、その後、葉のデフォルト値は、型のデフォルト値です。他のすべての場合で、葉はデフォルト値はありません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "type" statement, which MUST be present, takes as an argument the name of an existing built-in or derived type. The optional substatements specify restrictions on this type. See Section 7.4 for details.
存在しなければならない「タイプ」ステートメントは、引数として既存の内蔵または派生型の名前を取ります。オプションのサブステートメントは、このタイプの制限を指定します。詳細については、7.4節を参照してください。
The "default" statement, which is optional, takes as an argument a string that contains a default value for the leaf.
オプションである「デフォルト」の文では、引数として葉のデフォルト値を含む文字列を取ります。
The value of the "default" statement MUST be valid according to the type specified in the leaf's "type" statement.
「デフォルト」の文の値は、葉の「タイプ」文で指定された型に応じて有効である必要があります。
The "default" statement MUST NOT be present on nodes where "mandatory" is true.
「デフォルト」の文では「必須」は真であるノード上に存在してはなりません。
The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If not specified, the default is "false".
オプションである「必須」の文では、引数の文字列「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):
「必須」は「真」である場合には、制約の動作は非存在コンテナではありませんスキーマツリーのリーフの最も近い祖先ノードの種類によって異なります（第7.5.1項を参照してください）：
o If no such ancestor exists in the schema tree, the leaf MUST exist.
そのような祖先がスキーマツリーに存在しない場合は、O、葉が存在しなければなりません。
o Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists in the data tree.
この祖先がケースノードである場合にケースから任意のノードは、データツリーに存在する場合、Oそうでない場合、リーフが存在しなければなりません。
o Otherwise, the leaf MUST exist if the ancestor node exists in the data tree.
祖先ノードがデータツリー内に存在する場合にOそうでない場合には、リーフが存在しなければなりません。
This constraint is enforced according to the rules in Section 8.
この制約は、第8章の規則に従って実施されます。
A leaf node is encoded as an XML element. The element's local name is the leaf's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リーフノードは、XML要素として符号化されます。要素のローカル名は、葉の識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
The value of the leaf node is encoded to XML according to the type, and sent as character data in the element.
リーフノードの値は、種類に応じてXMLにエンコードされ、そして要素の文字データとして送信されます。
A NETCONF server that replies to a <get> or <get-config> request MAY choose not to send the leaf element if its value is the default value. Thus, a client that receives an <rpc-reply> for a <get> or <get-config> request, MUST be prepared to handle the case that a leaf node with a default value is not present in the XML. In this case, the value used by the server is known to be the default value.
<GET>または<GET-config>の要求に応答NETCONFサーバは、その値がデフォルト値である場合には、リーフ要素を送信しないこともできます。このように、<GET>または<GET-config>の要求のために<RPC返信>を受け取るクライアントは、デフォルト値を持つリーフノードがXMLに存在しない場合に対処するために準備しなければなりません。この場合、サーバによって使用される値は、デフォルト値であることが知られています。
See Section 7.6.8 for an example.
例えば、セクション7.6.8を参照してください。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the leaf node are:
NETCONFサーバは<編集設定>要求を処理するとき、リーフノードのための手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the value found in the XML RPC data.
操作は「マージ」または「置換」である場合は、それが存在しない場合、ノードが作成され、その値は、XML RPCデータで見つかった値に設定されています。
If the operation is "create", the node is created if it does not exist. If the node already exists, a "data-exists" error is returned.
操作は、「作成」されている場合は、それが存在しない場合、ノードが作成されます。ノードがすでに存在する場合は、「データが存在する」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作は「削除」されている場合は、それが存在する場合、ノードが削除されます。ノードが存在しない場合は、「データ・行方不明」エラーが返されます。
Given the following "leaf" statement, placed in the previously defined "ssh" container (see Section 7.5.9):
以前に定義された「SSH」の容器に入れ、以下の「リーフ」の文を、与えられた（セクション7.5.9を参照してください）：
leaf port {
type inet:port-number;
default 22;
description "The port to which the SSH server listens"
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<port>2022</port>
2022 <ポート> </ポート>
To set the value of a leaf with an <edit-config>:
<編集-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>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集-config>の<対象> <ランニング/> </ target>を<config>の<システムのxmlns = "http://example.com/schema/config"> <サービス> <SSH> <ポート> 2022 </ポート> </ SSH> </サービス> </システム> </ config>の</編集-config>の</ RPC>
Where the "leaf" statement is used to define a simple scalar variable of a particular type, the "leaf-list" statement is used to define an array of a particular type. The "leaf-list" statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf-list information.
「リーフ」文は、特定のタイプの単純なスカラー変数を定義するために使用される場合、「リーフリスト」の文は、特定の型の配列を定義するために使用されます。 「リーフリスト」の文では、詳細なリーフリスト情報を保持しているサブステートメントのブロックが続く識別子、1つの引数を取ります。
The values in a leaf-list MUST be unique.
リーフリストの値は一意である必要があります。
Conceptually, the values in the data tree are always in the canonical form (see Section 9.1).
概念的には、データツリーの値が標準的な形式で常にある（9.1節を参照してください）。
If the type referenced by the leaf-list has a default value, it has no effect in the leaf-list.
リーフリストで参照されるタイプは、デフォルト値を持つ場合、それは葉のリストでは効果がありません。
YANG supports two styles for ordering the entries within lists and leaf-lists. In many lists, the order of list entries does not impact the implementation of the list's configuration, and the device is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order to the device implementor. YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system".
YANGは、リストや葉のリスト内のエントリを注文するための2つのスタイルをサポートしています。多くのリストでは、リストのエントリの順序は、リストの設定の実装に影響を与えない、デバイスは任意の合理的な順序でリストのエントリをソートして自由です。リストについては、「説明」列には、デバイスの実装に順序を提案することができます。 YANGは、リストのこのスタイルを呼び出し、「システム命じた」と、彼らは「注文-によりシステム」声明で示されています。
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の<編集-config>の操作内の施設の豊富なセットを提供します。リストのエントリは、挿入または再配置され、リストの最初または最後のエントリとして配置、又は他の特定のエントリの前または後に配置することができます。
The "ordered-by" statement is covered in Section 7.7.5.
「注文・バイ」文は、セクション7.7.5で覆われています。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| type | 7.4 | 1 |
| units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "min-elements" statement, which is optional, takes as an argument a non-negative integer that puts a constraint on valid list entries. A valid leaf-list or list MUST have at least min-elements entries.
オプションである「最小要素」文は、引数として有効なリスト項目に制約を置く非負の整数をとります。有効なリーフリストまたはリストには、少なくとも最小の要素エントリを持たなければなりません。
If no "min-elements" statement is present, it defaults to zero.
ない「最小の要素」文は、ゼロがデフォルト、存在しない場合。
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、制約が適用されます。
o Otherwise, it is enforced if the ancestor node exists.
先祖ノードが存在する場合にOそうでない場合、それが適用されます。
The constraint is further enforced according to the rules in Section 8.
制約は、さらに、第8章の規則に従って実施されます。
The "max-elements" statement, which is optional, takes as an argument a positive integer or the string "unbounded", which puts a constraint on valid list entries. A valid leaf-list or list always has at most max-elements entries.
オプションである「MAX-要素」文は、引数として正の整数または有効なリスト項目に制約を置く「無制限」の文字列を取ります。有効なリーフリストまたはリストは、常に、最大max-要素のエントリがあります。
If no "max-elements" statement is present, it defaults to "unbounded".
何の「MAX-要素」文は、デフォルト「無制限」に存在しない場合。
The "max-elements" constraint is enforced according to the rules in Section 8.
「MAX-要素」制約は、第8章の規則に従って実施されます。
The "ordered-by" statement defines whether the order of entries within a list are determined by the user or the system. The argument is one of the strings "system" or "user". If not present, order defaults to "system".
「注文-で」文は、リスト内のエントリの順序は、ユーザまたはシステムによって決定されているかどうかを定義します。引数は、文字列「システム」または「ユーザー」の一つです。存在しない場合は、「システム」にデフォルトを注文します。
This statement is ignored if the list represents state data, RPC output parameters, or notification content.
リストには、状態データ、RPC出力パラメータ、または通知内容を表す場合、この文は無視されます。
See Section 7.7.1 for additional information.
詳細については、7.7.1項を参照してください。
The entries in the list are sorted according to an unspecified order. Thus, an implementation is free to sort the entries in the most appropriate order. An implementation SHOULD use the same order for the same data, regardless of how the data were created. Using a deterministic order will make comparisons possible using simple tools like "diff".
リスト内のエントリは、不特定の順序に従ってソートされています。このため、実装が最も適切な順序でエントリをソートして自由です。実装は関係なく、データが作成されたかの、同じデータに対して同じ順序を使用すべきです。決定論的順序を使用すると、「差分」のような簡単なツールを使用して比較が可能になります。
This is the default order.
これがデフォルトの順序です。
The entries in the list are sorted according to an order defined by the user. This order is controlled by using special XML attributes in the <edit-config> request. See Section 7.7.7 for details.
リストのエントリは、ユーザによって定義された順序に従ってソートされます。このためには、<編集-config>の要求に特別なXML属性を使用することによって制御されています。詳細については、セクション7.7.7を参照してください。
A leaf-list node is encoded as a series of XML elements. Each element's local name is the leaf-list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リーフ・リストのノードは、XML要素の系列として符号化されます。各要素のローカル名は、リーフ・リストの識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
The value of each leaf-list entry is encoded to XML according to the type, and sent as character data in the element.
各リーフ・リストのエントリの値は、種類に応じてXMLにエンコードされ、そして要素の文字データとして送信されます。
The XML elements representing leaf-list entries MUST appear in the order specified by the user if the leaf-list is "ordered-by user"; otherwise, the order is implementation-dependent. The XML elements representing leaf-list entries MAY be interleaved with other sibling elements, unless the leaf-list defines RPC input or output parameters.
葉のリストは、「注文-によってユーザー」されている場合、リーフ・リストのエントリを表すXML要素は、ユーザーが指定した順序で表示されなければなりません。そうでない場合は、順序は実装依存です。リーフリストは、RPC入力または出力パラメータを定義しない限り、リーフ・リスト・エントリを表すXML要素は、他の兄弟要素と交互配置されるかもしれません。
See Section 7.7.8 for an example.
例えば、セクション7.7.8を参照してください。
Leaf-list entries can be created and deleted, but not modified, through <edit-config>, by using the "operation" attribute in the leaf-list entry's XML element.
リーフ・リストのエントリは、<編集-config>の通じ、葉リストエントリのXML要素に「操作」属性を使用して、作成され、削除されたが、修正されないことができます。
In an "ordered-by user" leaf-list, the attributes "insert" and "value" in the YANG XML namespace (Section 5.3.1) can be used to control where in the leaf-list the entry is inserted. These can be used during "create" operations to insert a new leaf-list entry, or during "merge" or "replace" operations to insert a new leaf-list entry or move an existing one.
「ユーザ順序付けバイ」リーフリストに、YANG XML名前空間（セクション5.3.1）の属性「挿入」と「値」がリーフリストにエントリが挿入される場所を制御するために使用することができます。これらは、新しい葉リストエントリを挿入する操作を「作成」、または「マージ」や新葉リストエントリを挿入するか、既存のものを移動するための操作を「置き換え」の間に間に使用することができます。
The "insert" attribute can take the values "first", "last", "before", and "after". If the value is "before" or "after", the "value" attribute MUST also be used to specify an existing entry in the leaf-list.
属性が「最後」、「前」、および「後」、「最初」の値を取ることができ、「挿入」。値が「前」または「後」である場合は、「値」属性もリーフリストの既存のエントリを指定するために使用しなければなりません。
If no "insert" attribute is present in the "create" operation, it defaults to "last".
何の「挿入」属性が「作成」操作中に存在しない場合は、デフォルトの「最後」。
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.
「注文-により、ユーザ」リーフリスト内の複数のエントリは同じ<編集-config>の要求に変更された場合は、エントリは、要求内のXML要素の順序で、一度に一つを修正しています。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire leaf-list, the leaf-list order is the same as the order of the XML elements in the request.
全体の葉のリストをカバーして、「置換」操作で<コピー設定>、または<編集-config>のでは、リーフリストの順序は、要求内のXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a leaf-list node are:
NETCONFサーバは<編集-config>の要求を処理するときに、リーフリストノードのための手順の要素は次のとおりです。
If the operation is "merge" or "replace", the leaf-list entry is created if it does not exist.
操作は「マージ」または「置換」である場合、それが存在しない場合は、リーフリストのエントリが作成されます。
If the operation is "create", the leaf-list entry is created if it does not exist. If the leaf-list entry already exists, a "data-exists" error is returned.
操作は、「作成」されている場合は、それが存在しない場合は、リーフリストのエントリが作成されます。リーフリストのエントリがすでに存在する場合は、「データが存在する」エラーが返されます。
If the operation is "delete", the entry is deleted from the leaf-list if it exists. If the leaf-list entry does not exist, a "data-missing" error is returned.
操作は「削除」されている場合は、それが存在する場合、エントリがリーフリストから削除されます。リーフリストのエントリが存在しない場合は、「データ・行方不明」エラーが返されます。
leaf-list allow-user {
type string;
description "A list of user name patterns to allow";
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<allow-user>alice</allow-user> <allow-user>bob</allow-user>
<許可ユーザ>アリス</許可ユーザ> <許可ユーザ>ボブ</許可ユーザ>
To create a new element in this list, using the default <edit-config> operation "merge":
このリストに新しい要素を作成するには、デフォルトを使用して、<編集-config>の操作は、「マージ」：
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config"> <services> <ssh> <allow-user>eric</allow-user> </ssh> </services> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集-config>の<対象> <ランニング/> </ target>を<config>の<システムのxmlns = "http://example.com/schema/config"> <サービス> <SSH> <許可ユーザ>エリック< /許可ユーザ> </ SSH> </サービス> </システム> </ config>の</編集-config>の</ RPC>
Given the following ordered-by user leaf-list:
与えられた次の順序の-により、ユーザーの葉-リスト：
leaf-list cipher {
type string;
ordered-by user;
description "A list of ciphers";
}
The following would be used to insert a new cipher "blowfish-cbc" after "3des-cbc":
以下は、「3DES-CBC」の後に新しい暗号「フグ-CBC」を挿入するために使用されます。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config"> <services> <ssh> <cipher nc:operation="create" yang:insert="after" yang:value="3des-cbc">blowfish-cbc</cipher> </ssh> </services> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns ：陽= "URN：IETF：paramsは：XML：NS：陽：1"> <編集設定> <ターゲット> <実行/> </ターゲット> <設定> <システムのxmlns = "http://example.com /スキーマ/ configの "> <サービス> <SSH> <暗号NC：操作="」陽：挿入= "作成した後、" 陽：値= "" 3DES-CBC>フグ-CBC </サイファ> </ SSH> < /サービス> </システム> </ config>の</編集-config>の</ RPC>
The "list" statement is used to define an interior data node in the schema tree. A list node may exist in multiple instances in the data tree. Each such instance is known as a list entry. The "list" statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed list information.
「リスト」の文は、スキーマツリー内の内部データノードを定義するために使用されます。リスト・ノードは、データツリーの複数のインスタンス内に存在してもよいです。このような各インスタンスは、リストのエントリとして知られています。 「リスト」の文では、詳細なリスト情報を保持しているサブステートメントのブロックが続く識別子、1つの引数を取ります。
A list entry is uniquely identified by the values of the list's keys, if defined.
定義されている場合、リストのエントリを一意に、リストのキーの値によって識別されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| key | 7.8.2 | 0..1 |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| max-elements | 7.7.4 | 0..1 |
| min-elements | 7.7.3 | 0..1 |
| must | 7.5.3 | 0..n |
| ordered-by | 7.7.5 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "key" statement, which MUST be present if the list represents configuration, and MAY be present otherwise, takes as an argument a string that specifies a space-separated list of leaf identifiers of this list. A leaf identifier MUST NOT appear more than once in the key. Each such leaf identifier MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list, or in groupings used in the list.
リストには、コンフィギュレーションを表し、それ以外の場合に存在する可能性がある場合存在しなければならない「キー」の文では、引数としてこのリストの葉の識別子のスペース区切りのリストを指定する文字列を取ります。葉の識別子は、一度キーでより多く見えてはいけません。そのようなそれぞれの葉の識別子は、リストの子葉を参照する必要があります。リーフリストにサブステートメントで、またはリストで使用されるグループ内で直接定義することができます。
The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. It also implies that any mandatory statement in the key leafs are ignored.
キーで指定されたすべてのリーフの合成値は一意リストエントリを識別するために使用されます。リストのエントリが作成されたときにすべてのキーのリーフは、値を指定しなければなりません。このように、キー葉またはそれらの型のいずれかのデフォルト値は無視されます。また、キーの葉のいずれかの必須の文が無視されることを意味します。
A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty".
それは、内蔵型の「空」にすることはできませんを除いてキーの一部である葉は、任意の内蔵または派生型のものとすることができます。
All key leafs in a list MUST have the same value for their "config" as the list itself.
リスト内のすべてのキーのリーフは、リスト自体としての「設定」の同じ値を持たなければなりません。
The key string syntax is formally defined by the rule "key-arg" in Section 12.
キー文字列の構文は、正式ルール第12節で、「キーのarg」によって定義されます。
The "unique" statement is used to put constraints on valid list entries. It takes as an argument a string that contains a space-separated list of schema node identifiers, which MUST be given in the descendant form (see the rule "descendant-schema-nodeid" in Section 12). Each such schema node identifier MUST refer to a leaf.
「ユニークな」文は、有効なリスト項目に制約を置くために使用されています。これは引数として子孫の形で与えられなければならないスキーマノード識別子、のスペースで区切られたリストを含む文字列をとる（セクション12内のルール「子孫-スキーマNODEID」を参照）。このような各スキーマのノード識別子は、リーフを参照しなければなりません。
If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data.
参照されるリーフの一方はコンフィギュレーションデータを表す場合、参照されるリーフの全ては、構成データを表現しなければなりません。
The "unique" constraint specifies that the combined values of all the leaf instances specified in the argument string, including leafs with default values, MUST be unique within all list entry instances in which all referenced leafs exist. The constraint is enforced according to the rules in Section 8.
「ユニークな」制約は、デフォルト値を持つ葉を含む引数文字列で指定されたすべてのリーフインスタンスの結合値は、参照されるすべてのリーフが存在するすべてのリストエントリのインスタンス内で一意でなければならないことを指定します。制約は、第8章の規則に従って実施されます。
The unique string syntax is formally defined by the rule "unique-arg" in Section 12.
一意の文字列の構文は正式に第12節でルール「ユニーク-argに」で定義されています。
With the following list:
以下のリストの場合：
list server {
key "name";
unique "ip port";
leaf name {
type string;
}
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
}
}
The following configuration is not valid:
以下の設定は有効ではありません。
<server> <name>smtp</name> <ip>192.0.2.1</ip> <port>25</port> </server>
<サーバー> <名前> SMTP </名前> <IP> 192.0.2.1 </ IP> <ポート> 25 </ポート> </サーバ>
<server> <name>http</name> <ip>192.0.2.1</ip> <port>25</port> </server>
<サーバー> <名前> HTTP </名前> <IP> 192.0.2.1 </ IP> <ポート> 25 </ポート> </サーバ>
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>
<サーバー> <名前> SMTP </名前> <IP> 192.0.2.1 </ IP> <ポート> 25 </ポート> </サーバ>
<server> <name>http</name> <ip>192.0.2.1</ip> </server>
<サーバー> <名前> HTTP </名前> <IP> 192.0.2.1 </ IP> </サーバー>
<server> <name>ftp</name> <ip>192.0.2.1</ip> </server>
<サーバー> <名前> FTP </名前> <IP> 192.0.2.1 </ IP> </サーバー>
Within a list, the "container", "leaf", "list", "leaf-list", "uses", "choice", and "anyxml" statements can be used to define child nodes to the list.
リスト内では、「コンテナ」、「葉」、「リスト」、「リーフリスト」、「用途」、「選択」、および「AnyXMLで」文はリストに子ノードを定義するために使用することができます。
A list is encoded as a series of XML elements, one for each entry in the list. Each element's local name is the list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
リストは、XML要素、リストの各エントリのための1つの系列として符号化されます。各要素のローカル名は、リストの識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
The list's key nodes are encoded as subelements to the list's identifier element, in the same order as they are defined within the "key" statement.
リストのキーのノードは、それらが「鍵」ステートメント内に定義されているのと同じ順番で、リストの識別子要素にサブ要素としてエンコードされています。
The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order.
リストの子ノードの残りの部分は、キーの後に、リスト要素のサブ要素としてエンコードされています。リストには、RPC入力または出力パラメータを定義している場合、サブ要素は、それらが「リスト」ステートメント内に定義されているのと同じ順序で符号化されます。それ以外の場合は、サブ要素は任意の順序で符号化されています。
The XML elements representing list entries MUST appear in the order specified by the user if the list is "ordered-by user", otherwise the order is implementation-dependent. The XML elements representing list entries MAY be interleaved with other sibling elements, unless the list defines RPC input or output parameters.
リストは、「注文-によってユーザー」された場合は、リスト項目を表すXML要素は、ユーザーが指定した順番に表示される必要があり、そうでない場合は順序は実装依存です。リストは、RPC入力または出力パラメータを定義しない限り、リストのエントリを表すXML要素は、他の兄弟要素と交互配置されるかもしれません。
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要素に「操作」属性を使用して、<編集-config>のを介して変更することができます。それぞれの場合に、すべてのキーの値は一意にリストエントリを識別するために使用されます。すべてのキーがリストのエントリに指定されていない場合は、「不足している要素」エラーが返されます。
In an "ordered-by user" list, the attributes "insert" and "key" in the YANG XML namespace (Section 5.3.1) can be used to control where in the list the entry is inserted. These can be used during "create" operations to insert a new list entry, or during "merge" or "replace" operations to insert a new list entry or move an existing one.
「順序付け-によってユーザ」リストに、属性「インサート」とYANG XML名前空間に「キー」（セクション5.3.1）リスト内のエントリが挿入される場所を制御するために使用することができます。これらは、新しいリスト項目を挿入する操作を「作成」、または「マージ」、または新しいリストエントリを挿入するか、既存のものを移動するための操作を「置き換え」の間に間に使用することができます。
The "insert" attribute can take the values "first", "last", "before", and "after". If the value is "before" or "after", the "key" attribute MUST also be used, to specify an existing element in the list. The value of the "key" attribute is the key predicates of the full instance identifier (see Section 9.13) for the list entry.
属性が「最後」、「前」、および「後」、「最初」の値を取ることができ、「挿入」。値が「前」または「後」である場合は、「キー」属性は、リスト内の既存の要素を指定するために、使用しなければなりません。 「キー」属性の値は、リストのエントリのために（セクション9.13を参照）のフルインスタンス識別子の重要な述語です。
If no "insert" attribute is present in the "create" operation, it defaults to "last".
何の「挿入」属性が「作成」操作中に存在しない場合は、デフォルトの「最後」。
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.
「ユーザー命じ・バイ」リスト内の複数のエントリは同じ<編集-config>の要求に変更された場合は、エントリは、要求内のXML要素の順序で、一度に一つを修正しています。
In a <copy-config>, or an <edit-config> with a "replace" operation that covers the entire list, the list entry order is the same as the order of the XML elements in the request.
リスト全体をカバーして、「置換」操作で<コピー設定>、または<編集-config>のでは、リストのエントリの順序は、要求内のXML要素の順序と同じです。
When a NETCONF server processes an <edit-config> request, the elements of procedure for a list node are:
NETCONFサーバは<編集設定>要求を処理するときに、リスト・ノードのための手順の要素は次のとおりです。
If the operation is "merge" or "replace", the list entry is created if it does not exist. If the list entry already exists and the "insert" and "key" attributes are present, the list entry is moved according to the values of the "insert" and "key" attributes. If the list entry exists and the "insert" and "key" attributes are not present, the list entry is not moved.
操作は「マージ」または「置換」である場合、それが存在しない場合は、リストのエントリが作成されます。リストのエントリがすでに存在し、「挿入」と「キー」の属性が存在している場合は、リストの項目が「挿入」と「キー」の値に応じて移動される属性。リストのエントリが存在し、「挿入」と「キー」の属性が存在しない場合は、リストのエントリが移動されません。
If the operation is "create", the list entry is created if it does not exist. If the list entry already exists, a "data-exists" error is returned.
操作は、「作成」されている場合は、それが存在しない場合は、リストのエントリが作成されます。リストエントリがすでに存在する場合は、「データが存在する」エラーが返されます。
If the operation is "delete", the entry is deleted from the list if it exists. If the list entry does not exist, a "data-missing" error is returned.
操作は「削除」されている場合は、それが存在する場合、エントリがリストから削除されます。リストのエントリが存在しない場合は、「データ・行方不明」エラーが返されます。
Given the following list:
以下のリストを考えます：
list user {
key "name";
config true;
description "This is a list of users in the system.";
leaf name {
type string;
}
leaf type {
type string;
}
leaf full-name {
type string;
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> </user>
<ユーザー> <名前>フレッド</名前> <タイプ>管理者</入力> <フルネーム>フレッド・フリントストーン</フルネーム> </ユーザー>
To create a new user "barney":
新しいユーザー「バーニー」を作成するには：
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config"> <user nc:operation="create"> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> </user> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集-config>の<対象> <ランニング/> </ target>を<config>の<システムのxmlns = "http://example.com/schema/config"> <ユーザーNC：操作は= "作成"> <名前>バーニー</名前> <タイプ>管理者</入力> <フルネーム>バーニー瓦礫</フルネーム> </ユーザー> </システム> </ config>の</編集-config>の</ RPC>
To change the type of "fred" to "superuser":
「スーパーユーザ」に「フレッド」の種類を変更するには：
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config"> <user> <name>fred</name> <type>superuser</type> </user> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </ターゲット> <設定> <システムのxmlns = "http://example.com/schema/config"> <ユーザー> <名前>フレッド</名前> <タイプ>スーパー</タイプ> </ユーザー> </システム> </ config>の</編集-config>の</ RPC>
Given the following ordered-by user list:
以下は、注文した-でユーザーリストを考えます：
list user {
description "This is a list of users in the system.";
ordered-by user;
config true;
key "name";
キーの「名前」。
leaf name {
type string;
}
leaf type {
type string;
}
leaf full-name {
type string;
}
}
The following would be used to insert a new user "barney" after the user "fred":
以下では、ユーザ「フレッド」の後に新しいユーザー「バーニー」を挿入するために使用されます。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config" xmlns:ex="http://example.com/schema/config"> <user nc:operation="create" yang:insert="after" yang:key="[ex:name='fred']"> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> </user> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns ：陽= "URN：IETF：paramsは：XML：NS：陽：1"> <編集設定> <ターゲット> <実行/> </ターゲット> <設定> <システムのxmlns = "http://example.com /スキーマ/設定 "のxmlns：EX = "http://example.com/schema/config"> <ユーザーNC：操作= "作成" ヤン：挿入= "の後に" 陽：キー=" [例：名=」フレッド '] "> <名前>バーニー</名前> <タイプ>管理者</入力> <フルネーム>バーニー瓦礫</フルネーム> </ユーザー> </システム> </ config>の</編集 - 設定> </ RPC>
The following would be used to move the user "barney" before the user "fred":
以下では、ユーザ「フレッド」の前に、ユーザ「バーニー」を移動するために使用されます。
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1"> <edit-config> <target> <running/> </target> <config> <system xmlns="http://example.com/schema/config" xmlns:ex="http://example.com/schema/config"> <user nc:operation="merge" yang:insert="before" yang:key="[ex:name='fred']"> <name>barney</name> </user> </system> </config> </edit-config> </rpc>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns ：陽= "URN：IETF：paramsは：XML：NS：陽：1"> <編集設定> <ターゲット> <実行/> </ターゲット> <設定> <システムのxmlns = "http://example.com /スキーマ/設定 "のxmlns：EX = "http://example.com/schema/config"> <ユーザーNC：操作= "" ヤン：=挿入する "合併前に" 陽：キー=" [例：名=」フレッド '] "> <名前>バーニー</名前> </ユーザー> </システム> </ config>の</編集-config>の</ RPC>
The "choice" statement defines a set of alternatives, only one of which may exist at any one time. The argument is an identifier, followed by a block of substatements that holds detailed choice information. The identifier is used to identify the choice node in the schema tree. A choice node does not exist in the data tree.
「選択」文は、いずれかの時点で存在し得るの一つだけを選択肢の集合を定義します。引数は、詳細な選択情報を保持するサブステートメントのブロック続いて、識別子です。識別子は、スキーマツリーで選択ノードを識別するために使用されます。選択ノードは、データツリーには存在しません。
A choice consists of a number of branches, defined with the "case" substatement. Each branch contains a number of child nodes. The nodes from at most one of the choice's branches exist at the same time.
選択肢は、「ケース」のサブステートメントで定義された枝の数、構成されています。各ブランチは、子ノードの数が含まれています。選択肢の支店の多くても1つのノードが同時に存在します。
See Section 8.3.2 for additional information.
追加情報については、8.3.2項を参照してください。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| mandatory | 7.9.4 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "case" statement is used to define branches of the choice. It takes as an argument an identifier, followed by a block of substatements that holds detailed case information.
「ケース」文は、選択した枝を定義するために使用されます。これは引数として、詳細なケースの情報を保持するサブステートメントのブロックが続く識別子をとります。
The identifier is used to identify the case node in the schema tree. A case node does not exist in the data tree.
識別子は、スキーマツリーのケースノードを識別するために使用されます。ケースノードは、データツリーに存在しません。
Within a "case" statement, the "anyxml", "choice", "container", "leaf", "list", "leaf-list", and "uses" statements can be used to define child nodes to the case node. The identifiers of all these child nodes MUST be unique within all cases in a choice. For example, the following is illegal:
「ケース」声明、「AnyXMLで」、「選択」、「コンテナ」、「葉」、「リスト」、「リーフリスト」、および内のステートメントは、ケースノードに子ノードを定義するために使用することができ、「使用しています」 。これらすべての子ノードの識別子は、選択中のすべてのケース内で一意でなければなりません。例えば、以下は違法です。
choice interface-type { // This example is illegal YANG case a { leaf ethernet { ... } } case b { container ethernet { ...} } }
選択インタフェース型{//この例では、違法YANGの場合は{リーフイーサネット{...}}ケースb {容器イーサネット{...}}}
As a shorthand, the "case" statement can be omitted if the branch contains a single "anyxml", "container", "leaf", "list", or "leaf-list" statement. In this case, the identifier of the case node is the same as the identifier in the branch statement. The following example:
ブランチは、単一の「AnyXMLで」、「コンテナ」、「葉」、「リスト」、または「リーフリスト」のステートメントが含まれている場合は省略形として、「ケース」文は省略することができます。この場合、ケースノードの識別子は、分岐文の識別子と同じです。次の例：
choice interface-type { container ethernet { ... } }
選択インタフェース型{容器イーサネット{...}}
is equivalent to:
と同等です。
choice interface-type { case ethernet { container ethernet { ... } } }
選択インタフェース型{ケースイーサネット{容器イーサネット{...}}}
The case identifier MUST be unique within a choice.
ケース識別子は、選択内で一意でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
The "default" statement indicates if a case should be considered as the default if no child nodes from any of the choice's cases exist. The argument is the identifier of the "case" statement. If the "default" statement is missing, there is no default case.
選択の例の任意の子ノードが存在しない場合場合は、デフォルトとして考慮されるべきである場合、「デフォルト」の文を示します。引数が「ケース」の文の識別子です。 「デフォルト」の文が欠落している場合は、デフォルトの場合はありません。
The "default" statement MUST NOT be present on choices where "mandatory" is true.
「デフォルト」の文では「必須」は真である選択肢に存在してはなりません。
The default case is only important when considering the default values of nodes under the cases. The default values for nodes under the default case are used if none of the nodes under any of the cases are present.
例下のノードのデフォルト値を検討する際に、デフォルトの場合にのみ重要です。いずれの場合も下のノードのいずれも存在しない場合、デフォルトのケース下ノードのデフォルト値が使用されています。
There MUST NOT be any mandatory nodes (Section 3.1) directly under the default case.
直接デフォルトのケースの下で任意の必須ノード（3.1節）があってはなりません。
Default values for child nodes under a case are only used if one of the nodes under that case is present, or if that case is the default case. If none of the nodes under a case are present and the case is not the default case, the default values of the cases' child nodes are ignored.
その場合、下のいずれかのノードが存在する場合、またはその場合は、デフォルトの場合であればケースの下の子ノードのデフォルト値にのみ使用されます。ケースの下のノードのどれもが存在しないと場合は、デフォルトでない場合、例子ノードのデフォルト値は無視されます。
In this example, the choice defaults to "interval", and the default value will be used if none of "daily", "time-of-day", or "manual" are present. If "daily" is present, the default value for "time-of-day" will be used.
この例では、「間隔」、およびデフォルト値に選択のデフォルトが使用される場合、「毎日」、「時刻」、または「手動」存在しているのなし。 「毎日」が存在する場合は、「時間帯」のデフォルト値が使用されます。
container transfer {
choice how {
default interval;
case interval {
leaf interval {
type uint16;
default 30;
units minutes;
}
}
case daily {
leaf daily {
type empty;
}
leaf time-of-day {
type string;
units 24-hour-clock;
default 1am;
}
}
case manual {
leaf manual {
type empty;
}
}
}
}
The "mandatory" statement, which is optional, takes as an argument the string "true" or "false", and puts a constraint on valid data. If "mandatory" is "true", at least one node from exactly one of the choice's case branches MUST exist.
オプションである「必須」の文では、引数の文字列「true」または「false」として受け取り、有効なデータに制約を置きます。 「必須」は「真」である場合は、選択肢のケースの枝のちょうど1から少なくとも1つのノードが存在しなければなりません。
If not specified, the default is "false".
指定しない場合、デフォルトは「false」です。
The behavior of the constraint depends on the type of the choice's closest ancestor node in the schema tree which is not a non-presence container (see Section 7.5.1):
制約の動作は非存在コンテナではありませんスキーマツリーでの選択の最も近い祖先ノードの種類によって異なります（第7.5.1項を参照してください）：
o If this ancestor is a case node, the constraint is enforced if any other node from the case exists.
この祖先がケースノードである場合はケースから他のノードが存在する場合、O、制約が適用されます。
o Otherwise, it is enforced if the ancestor node exists.
先祖ノードが存在する場合にOそうでない場合、それが適用されます。
The constraint is further enforced according to the rules in Section 8.
制約は、さらに、第8章の規則に従って実施されます。
The choice and case nodes are not visible in XML.
選択とケースのノードは、XMLには表示されません。
The child nodes of the selected "case" statement MUST be encoded in the same order as they are defined in the "case" statement if they are part of an RPC input or output parameter definition. Otherwise, the subelements are encoded in any order.
選択された「ケース」ステートメントの子ノードは、それらがRPC入力または出力パラメータの定義の一部である場合、それらは「ケース」ステートメントで定義されているのと同じ順序で符号化されなければなりません。それ以外の場合は、サブ要素は任意の順序で符号化されています。
Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If an <edit-config> operation creates a node from a case, the NETCONF server will delete any existing nodes that are defined in other cases inside the choice.
選択肢の例だけが任意の時点で有効であることができるので、1ケースからのノードの作成は暗黙のうちに他のすべてのケースからすべてのノードを削除します。 <編集設定>操作がケースからノードを作成した場合、NETCONFサーバは、選択内の他の場合に定義されている既存のノードを削除します。
Given the following choice:
以下の選択肢を考えます：
container protocol {
choice name {
case a {
leaf udp {
type empty;
}
}
case b {
leaf tcp {
type empty;
}
}
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<protocol> <tcp/> </protocol>
<プロトコル> <TCP /> </プロトコル>
To change the protocol from tcp to udp:
UDPにTCPからプロトコルを変更するには：
<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>
<RPCメッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0" のxmlns：NC = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <編集設定> <ターゲット> <実行/> </ターゲット> <設定> <システムのxmlns = "http://example.com/schema/config"> <プロトコル> <UDP NC：動作= "作成" / > </プロトコル> </システム> </ config>の</編集設定> </ RPC>
The "anyxml" statement defines an interior node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed anyxml information.
「AnyXMLで」文は、スキーマツリーの内部ノードを定義します。これは、詳細AnyXMLで情報を保持するサブステートメントのブロックが続く識別子であり、一つの引数を取ります。
The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. This can be useful, for example, in RPC replies. An example is the <filter> parameter in the <get-config> operation.
「AnyXMLで」文はXMLの未知のチャンクを表すために使用されます。何の制限は、XMLの上に置かれていません。これは、RPCの応答で、例えば、便利です。一例では、<GET-config>の操作で<フィルタ>パラメータです。
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の場合に存在します。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
An anyxml node is encoded as an XML element. The element's local name is the anyxml's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of the anyxml node is encoded as XML content of this element.
AnyXMLでノードは、XML要素として符号化されます。要素のローカル名はAnyXMLでの識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。 AnyXMLでノードの値は、この要素のXMLコンテンツとして符号化されます。
Note that any prefixes used in the encoding are local to each instance encoding. This means that the same XML may be encoded differently by different implementations.
符号化に使用される任意のプレフィックスが各インスタンスのエンコーディングに対してローカルであることに留意されたいです。これは、同じXMLは、異なる実装によって異なって符号化することができることを意味します。
An anyxml node is treated as an opaque chunk of data. This data can be modified in its entirety only.
AnyXMLでノードがデータの不透明なチャンクとして処理されます。このデータは、全体的に変更することができます。
Any "operation" attributes present on subelements of an anyxml node are ignored by the NETCONF server.
任意の「動作」がNETCONFサーバによって無視されAnyXMLでノードのサブエレメントに存在する属性。
When a NETCONF server processes an <edit-config> request, the elements of procedure for the anyxml node are:
NETCONFサーバは<編集設定>要求を処理するとき、AnyXMLでノードの手順の要素は次のとおりです。
If the operation is "merge" or "replace", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data.
操作は「マージ」または「置換」である場合は、それが存在しない場合、ノードが作成され、その値は、XML RPCデータで見つかったAnyXMLでノードのXMLコンテンツに設定されています。
If the operation is "create", the node is created if it does not exist, and its value is set to the XML content of the anyxml node found in the XML RPC data. If the node already exists, a "data-exists" error is returned.
操作は、「作成」であるならば、それが存在しない場合、ノードが作成され、その値は、XML RPCデータで見つかったAnyXMLでノードのXMLコンテンツに設定されています。ノードがすでに存在する場合は、「データが存在する」エラーが返されます。
If the operation is "delete", the node is deleted if it exists. If the node does not exist, a "data-missing" error is returned.
操作は「削除」されている場合は、それが存在する場合、ノードが削除されます。ノードが存在しない場合は、「データ・行方不明」エラーが返されます。
Given the following "anyxml" statement:
以下の「AnyXMLで」文を考えます：
anyxml data;
AnyXMLでデータ;
The following are two valid encodings of the same anyxml value:
同じAnyXMLで値の2つの有効なエンコーディングは、次のとおりです。
<data xmlns:if="http://example.com/ns/interface"> <if:interface> <if:ifIndex>1</if:ifIndex> </if:interface> </data>
<データのxmlns = "http://example.com/ns/interface" IF> <場合：インタフェース> <場合：ifIndexの> 1 </ IF：のifIndex> </ IF：インターフェイス> </データ>
<data> <interface xmlns="http://example.com/ns/interface"> <ifIndex>1</ifIndex> </interface> </data>
<データ> <インターフェイスのxmlns = "http://example.com/ns/interface"> <ifIndexの> 1 </ ifIndexの> </インターフェイス> </データ>
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の規則に従って、それを含むモジュールに、及びそこからインポート他のモジュールにより、モジュール内で局所的に使用することができる、ノードの再利用可能なブロックを定義するために使用されます。これは、詳細なグルーピング情報を保持しているサブステートメントのブロックが続く識別子であり、一つの引数を取ります。
The "grouping" statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
「グループ化」の文は、次のような、スキーマツリーの任意のノードを定義していない、データ定義文ではありませんと。
A grouping is like a "structure" or a "record" in conventional programming languages.
グルーピングは、「構造」または従来のプログラミング言語で「記録」のようなものです。
Once a grouping is defined, it can be referenced in a "uses" statement (see Section 7.12). A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings.
グループが定義されると、それは「使用する」文で参照することができます（7.12節を参照してください）。グループ化は、他のグループのチェーンを介しても直接でも間接的に自分自身を参照してはなりません。
If the grouping is defined at the top level of a YANG module or submodule, the grouping's identifier MUST be unique within the module.
グルーピングがYANGモジュールまたはサブモジュールのトップレベルで定義されている場合、グループの識別子は、モジュール内で一意でなければなりません。
A grouping is more than just a mechanism for textual substitution, but defines a collection of nodes. Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used. Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the "grouping" statement appears. For extensions, this means that extensions are applied to the grouping node, not the uses node.
グループ分けは、テキスト置換のための単なるメカニズム以上のものですが、ノードのコレクションを定義します。グルーピング内部に現れる識別子は、グループが定義されている、ではない、それがどこで使用される範囲に対して解決されます。プレフィックスのマッピング、タイプ名、グループ名、および拡張の使用量は、「グループ化」文が表示された階層で評価されています。拡張のために、これは、拡張がグループ化ノードではなく、用途のノードに適用されることを意味します。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
import ietf-inet-types {
prefix "inet";
}
grouping endpoint {
description "A reusable endpoint group.";
leaf ip {
type inet:ip-address;
}
leaf port {
type inet:port-number;
}
}
The "uses" statement is used to reference a "grouping" definition. It takes one argument, which is the name of the grouping.
声明は、「グループ化」の定義を参照するために使用され、「使用しています」。これは、グループの名前を1つの引数を取ります。
The effect of a "uses" reference to a grouping is that the nodes defined by the grouping are copied into the current schema tree, and then updated according to the "refine" and "augment" statements.
グループへの参照を「使用」の効果は、グループによって定義されたノードが現在のスキーマ・ツリーにコピーし、「絞り込み」及び「増強」ステートメントに応じて更新されることです。
The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module.
グループ分けの内容がスキーマツリーに追加されるまで、グループで定義された識別子は、それらが名前空間にバインドされた時点で、「グループ化」文の中に表示されない文を、「使用する」を経由して名前空間にバインドされていません現在のモジュールの。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| augment | 7.15 | 0..1 |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| refine | 7.12.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
Some of the properties of each node in the grouping can be refined with the "refine" statement. The argument is a string that identifies a node in the grouping. This node is called the refine's target node. If a node in the grouping is not present as a target node of a "refine" statement, it is not refined, and thus used exactly as it was defined in the grouping.
グループ内の各ノードのプロパティの一部は、「洗練」声明で精製することができます。引数は、グループ内のノードを識別する文字列です。このノードは、絞り込みの対象ノードと呼ばれています。グループ内のノードは、「絞り込み」ステートメントのターゲットノードとして存在しない場合、それは洗練され、従ってそれはグループで定義されたとおりに使用されていません。
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.
それは既に1を持っていた場合、O葉または選択ノードには、デフォルト値、または新しいデフォルト値を得ることができます。
o Any node may get a specialized "description" string.
O任意のノードは、専用の「説明」の文字列を取得することがあります。
o Any node may get a specialized "reference" string.
O任意のノードは、専用の「参照」の文字列を取得することがあります。
o Any node may get a different "config" statement.
O任意のノードは異なる「設定」の文を得ることができます。
o A leaf, anyxml, or choice node may get a different "mandatory" statement.
O葉、AnyXMLで、または選択ノードが異なる「必須」の文を得ることができます。
o A container node may get a "presence" statement.
Oコンテナノードは、「プレゼンス」の文を得ることができます。
o A leaf, leaf-list, list, container, or anyxml node may get additional "must" expressions.
O葉、葉、リスト、リスト、コンテナ、またはAnyXMLでノードが「必要」の表現の追加かもしれません。
o A leaf-list or list node may get a different "min-elements" or "max-elements" statement.
Oリーフリストまたはリストのノードが異なる「MIN-要素」または「MAX-要素」文を得ることができます。
Each node in the grouping is encoded as if it was defined inline, even if it is imported from another module with another XML namespace.
それはインラインで定義されたかのようにグループ内の各ノードは、それが別のXML名前空間を持つ別のモジュールからインポートされた場合でも、符号化されます。
To use the "endpoint" grouping defined in Section 7.11.2 in a definition of an HTTP server in some other module, we can do:
グループ化するいくつかの他のモジュール内のHTTPサーバの定義にセクション7.11.2で定義された「エンドポイント」を使用するには、我々は行うことができます。
import acme-system { prefix "acme"; }
インポートACME系{接頭辞「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>
<HTTPサーバ> <名前>はextern-ウェブ</名前> <IP> 192.0.2.1 </ IP> <ポート> 80 </ポート> </ HTTPサーバ>
If port 80 should be the default for the HTTP server, default can be added:
ポート80はHTTPサーバのデフォルトにする必要がある場合は、デフォルトでは、追加することができます。
container http-server {
leaf name {
type string;
}
uses acme:endpoint {
refine port {
default 80;
}
}
}
If we want to define a list of servers, and each server has the ip and port as keys, we can do:
私たちは、サーバのリストを定義すると、各サーバーがキーとしてIPアドレスとポートがある場合、我々は行うことができます。
list server {
key "ip port";
leaf name {
type string;
}
uses acme:endpoint;
}
The following is an error:
次はエラーです。
container http-server {
uses acme:endpoint;
leaf ip { // illegal - same identifier "ip" used twice
type string;
}
}
The "rpc" statement is used to define a NETCONF RPC operation. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed rpc information. This argument is the name of the RPC, and is used as the element name directly under the <rpc> element, as designated by the substitution group "rpcOperation" in [RFC4741].
「RPC」文はNETCONFのRPC操作を定義するために使用されます。これは、詳細な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ノードの下に、名前「入力」、及び名称「出力」のスキーマノードとスキーマノードは、定義されています。ノード「入力」と「出力」は、モジュールの名前空間で定義されています。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
The "input" statement, which is optional, is used to define input parameters to the RPC operation. It does not take an argument. The substatements to "input" define nodes under the RPC's input node.
オプションである「入力」ステートメントは、RPC操作への入力パラメータを定義するために使用されます。これは、引数を取りません。 「入力」のサブステートメントは、RPCの入力ノードの下のノードを定義します。
If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC invocation. Otherwise, the server MUST return a "missing-element" error.
入力ツリーのリーフが値「真」と「必須」の文を持っている場合は、葉がNETCONFのRPCの呼び出し中に存在しなければなりません。そうしないと、サーバは「不足している要素」エラーを返さなければなりません。
If a leaf in the input tree has a default value, the NETCONF server MUST use this value in the same cases as described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the NETCONF RPC invocation with the default value as its value.
入力ツリーのリーフにデフォルト値がある場合、セクション7.6.1で説明したように、NETCONFサーバが同じ場合に、この値を使用する必要があります。葉は、その値としてデフォルト値を持つNETCONF RPC呼び出しに存在したかのようにこれらの例では、サーバが運用に動作しなければなりません。
If a "config" statement is present for any node in the input tree, the "config" statement is ignored.
「設定」の文は、入力ツリー内の任意のノードのために存在している場合は、「設定」の文は無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the input tree.
任意のノードがfalseと評価されてしまうからです「と、」ステートメントを持っている場合、このノードは入力ツリーに存在してはなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
The "output" statement, which is optional, is used to define output parameters to the RPC operation. It does not take an argument. The substatements to "output" define nodes under the RPC's output node.
オプションである「出力」文は、RPC操作に出力パラメータを定義するために使用されます。これは、引数を取りません。 「出力」へのサブステートメントは、RPCの出力ノードの下のノードを定義します。
If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF RPC reply.
出力ツリーのリーフが値「真」と「必須」の文を持っている場合は、葉が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.
出力ツリーのリーフにデフォルト値がある場合、セクション7.6.1で説明したように、NETCONFクライアントが同じ場合に、この値を使用する必要があります。これらのケースでは、クライアントは、運用上の葉は、その値として、デフォルト値でNETCONFのRPC応答に存在したかのように振る舞う必要があります。
If a "config" statement is present for any node in the output tree, the "config" statement is ignored.
「設定」の文は、出力ツリー内の任意のノードのために存在している場合は、「設定」の文は無視されます。
If any node has a "when" statement that would evaluate to false, then this node MUST NOT be present in the output tree.
任意のノードがfalseと評価されてしまうからです「と、」ステートメントを持っている場合、このノードは、出力ツリーに存在してはなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
An rpc node is encoded as a child XML element to the <rpc> element defined in [RFC4741]. The element's local name is the rpc's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
RPCノードは[RFC4741]で定義された<RPC>要素の子のXML要素として符号化されます。要素のローカル名は、RPCの識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
Input parameters are encoded as child XML elements to the rpc node's XML element, in the same order as they are defined within the "input" statement.
入力パラメータは、それらが「入力」ステートメント内に定義されているのと同じ順序で、RPCノードのXML要素の子のXML要素としてエンコードされています。
If the RPC operation invocation succeeded, and no output parameters are returned, the <rpc-reply> contains a single <ok/> element defined in [RFC4741]. If output parameters are returned, they are encoded as child elements to the <rpc-reply> element defined in [RFC4741], in the same order as they are defined within the "output" statement.
RPC操作呼び出しが成功し、何も出力パラメータが返されない場合は、<RPC返信>は、[RFC4741]で定義された単一の<OK />要素を含んでいます。出力パラメータが返された場合、それらはそれらが「出力」ステートメント内で定義されているのと同じ順序で、[RFC4741]で定義された<RPC返信>要素の子要素として符号化されます。
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; } } } }
RPCロック・ハウス{入力{葉ジップコード{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メッセージID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <ロック・ハウスのxmlns = "http://example.net/rock"> <郵便番号> 27606-0100 </郵便番号> </ロック・ハウス> </ RPC>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
<RPC応答メッセージ-ID = "101" のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：塩基：1.0"> <OK /> </ RPC返信>
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通知を定義するために使用されます。これは、詳細な通知情報を保持しているサブステートメントのブロックが続く識別子であり、一つの引数を取ります。 「通知」の文は、スキーマツリーに通知ノードを定義します。
If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF notification.
通知ツリーのリーフが値「真」と「必須」の文を持っている場合は、葉が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.
通知ツリーのリーフにデフォルト値がある場合、セクション7.6.1で説明したように、NETCONFクライアントが同じ場合に、この値を使用する必要があります。これらのケースでは、クライアントは、運用上の葉は、その値として、デフォルト値でNETCONF通知に存在したかのように振る舞う必要があります。
If a "config" statement is present for any node in the notification tree, the "config" statement is ignored.
「設定」文は通知ツリー内の任意のノードのために存在している場合は、「設定」の文は無視されます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+
A notification node is encoded as a child XML element to the <notification> element defined in NETCONF Event Notifications [RFC5277]. The element's local name is the notification's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
通知ノードはNETCONFイベント通知[RFC5277]で定義された<通知>要素の子のXML要素として符号化されます。要素のローカル名は、通知の識別子であり、その名前空間は、モジュールのXML名前空間（セクション7.1.3を参照）です。
The following example defines a notification:
次の例では、通知を定義します。
module event {
モジュール・イベント{
namespace "http://example.com/event";
prefix "ev";
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>
<通知のxmlns = "URN：IETF：paramsは：XML：NS：NETCONF：通知：1.0"> <イベント時刻> 2008-07-08T00：01：00Z </イベント時刻> <イベントのxmlns = "http://example.com /イベント "> <イベント-class>の障害</イベント・クラス> <報告-エンティティ> <カード> Ethernet0に</カード> </レポーティング・エンティティ> <重要度>主要</重症度> </イベント> </通知>
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.
ステートメントは、モジュールまたはサブモジュールは、外部モジュールで定義されたスキーマ・ツリーに追加することができ、又は現在のモジュールとそのサブモジュール、および文を「使用」にグループからのノードに追加し、「増強」。引数は、スキーマツリー内のノードを識別する文字列です。このノードは、補填の対象ノードと呼ばれています。ターゲットノードは、コンテナ、リスト、選択、の場合、入力、出力、または通知ノードのいずれかでなければなりません。それは、「増やす」の文に続くサブステートメントで定義されたノードで拡張されます。
The argument string is a schema node identifier (see Section 6.5). If the "augment" statement is on the top level in a module or submodule, the absolute form (defined by the rule
引数文字列は、スキーマノード識別子（セクション6.5を参照）です。ステートメントは、モジュール又はサブモジュールのトップレベルである「増強」、絶対的な形（規則によって定義されている場合
"absolute-schema-nodeid" in Section 12) of a schema node identifier MUST be used. If the "augment" statement is a substatement to the "uses" statement, the descendant form (defined by the rule "descendant-schema-nodeid" in Section 12) MUST be used.
スキーマノード識別子の節12）で「絶対スキーマNODEID」が使用されなければなりません。 「増強」ステートメントがステートメントを「使用」にサプである場合、（セクション12内のルール「子孫-スキーマ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.
ターゲット・ノードは、コンテナ、リスト、ケース、入力、出力、または通知ノードである場合は、「コンテナ」、「葉」、「リスト」、「リーフリスト」、「用途」、および「選択」のステートメントは、することができ「強化」声明の中で使用。
If the target node is a choice node, the "case" statement, or a case shorthand statement (see Section 7.9.2) can be used within the "augment" statement.
ターゲットノードが選択ノードである場合は、「ケース」の文、またはケースの速記文は（7.9.2項を参照）の文を「強化」内で使用することができます。
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.
文は、同じモジュールからターゲット・ノードに同じ名前で複数のノードを追加してはならない「強化」。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+
All data nodes defined in the "augment" statement are defined as XML elements in the XML namespace of the module where the "augment" is specified.
「強化」文で定義されたすべてのデータノードが指定されている「増補」モジュールのXML名前空間内のXML要素として定義されています。
When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order.
ノードが拡張されると、増強子ノードは、任意の順序で、拡張ノードの下位要素として符号化されます。
In namespace http://example.com/schema/interfaces, we have:
名前空間http://example.com/schema/interfacesでは、我々は持っています：
container interfaces { list ifEntry { key "ifIndex";
コンテナインターフェイス{リストのifEntry {キー「のifIndex」。
leaf ifIndex {
type uint32;
}
leaf ifDescr {
type string;
}
leaf ifType {
type iana:IfType;
}
leaf ifMtu {
type int32;
}
}
}
Then, in namespace http://example.com/schema/ds0, we have:
次に、名前空間http://example.com/schema/ds0に、我々は持っています：
import interface-module {
prefix "if";
}
augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'";
leaf ds0ChannelNumber {
type ChannelNumber;
}
}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<interfaces xmlns="http://example.com/schema/interfaces" xmlns:ds0="http://example.com/schema/ds0"> <ifEntry> <ifIndex>1</ifIndex> <ifDescr>Flintstone Inc Ethernet A562</ifDescr> <ifType>ethernetCsmacd</ifType> <ifMtu>1500</ifMtu> </ifEntry> <ifEntry> <ifIndex>2</ifIndex> <ifDescr>Flintstone Inc DS0</ifDescr> <ifType>ds0</ifType> <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber> </ifEntry> </interfaces>
<インターフェイスのxmlns = "http://example.com/schema/interfaces" のxmlns：DS0 = "http://example.com/schema/ds0"> <ifEntryを> <ifIndexの> 1 </ ifIndexの> <のifDescr>フリントストーンINCイーサネットA562 </のifDescr> <ifTypeが> ethernetCsmacd </ ifTypeが> <ifMtu> 1500 </ ifMtu> </ ifEntryを> <ifEntryを> <ifIndexの> 2 </ ifIndexの> <のifDescr>フリントストーン社DS0 </のifDescr> <のifType > DS0 </ ifTypeが> <DS0：ds0ChannelNumber> 1 </ DS0：ds0ChannelNumber> </ ifEntryを> </インターフェイス>
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; } } }
増強/ EX：システム/ EX：プロトコル/ EX：名前{ケースc {葉SMTP {タイプ空。 }}}
A corresponding XML instance example:
対応するXMLインスタンスの例：
<ex:system> <ex:protocol> <ex:tcp/> </ex:protocol> </ex:system>
<例：システム> <例：プロトコル> <例：TCP /> </ EX：プロトコル> </ EX：システム>
or
または
<ex:system> <ex:protocol> <other:smtp/> </ex:protocol> </ex:system>
<例：システム> <例：プロトコル> <その他：SMTP /> </ EX：プロトコル> </ EX：システム>
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.
「アイデンティティ」文は、新しいグローバルにユニークな抽象的、および型なしアイデンティティを定義するために使用されます。その唯一の目的は、その名前、意味論、および存在を示すためにです。同一性は、いずれかのスクラッチから定義又は塩基の同一性に由来することができます。アイデンティティの引数は、アイデンティティの名前である識別子です。これは、詳細な識別情報を保持しているサブステートメントのブロックが続いています。
The built-in datatype "identityref" (see Section 9.10) can be used to reference identities within a data model.
組込みデータ型「identityrefは」（セクション9.10を参照）データモデル内で識別情報を参照するために使用することができます。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| base | 7.16.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
The "base" statement, which is optional, takes as an argument a string that is the name of an existing identity, from which the new identity is derived. If no "base" statement is present, the identity is defined from scratch.
オプションである「ベース」の文では、引数として新しいアイデンティティが由来する既存の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.
接頭辞がベース名に存在する場合、それはその接頭辞、または接頭辞がローカルモジュールのプレフィックスと一致した場合、ローカルモジュールをインポートされたモジュールで定義された同一性をいいます。そうでない場合は、一致する名前を持つアイデンティティは、現在のモジュールまたは含まサブモジュールで定義されなければなりません。
Since submodules cannot include the parent module, any identities in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the identity.
サブモジュールは親モジュールを含めることはできませんので、サブモジュールにさらされる必要があるモジュール内の任意のアイデンティティは、サブモジュールで定義する必要があります。サブモジュールは、アイデンティティの定義を見つけるために、このサブモジュールを含めることができます。
An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.
アイデンティティは、他のアイデンティティの連鎖を通じてどちらも直接にも間接的に、自分自身を参照してはなりません。
module crypto-base {
namespace "http://example.com/crypto-base";
prefix "crypto";
identity crypto-alg { description "Base identity from which all crypto algorithms are derived."; } }
同一の暗号ALG {説明「すべての暗号アルゴリズムが由来するベースアイデンティティ。」; }}
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";
}
}
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 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で構文規則に従わなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| argument | 7.17.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
The "argument" statement, which is optional, takes as an argument a string that is the name of the argument to the keyword. If no argument statement is present, the keyword expects no argument when it is used.
オプションである「引数」の文では、引数としてキーワードへの引数の名前である文字列を取ります。引数の文が存在しない場合、キーワードは、それが使用されている引数を期待していません。
The argument's name is used in the YIN mapping, where it is used as an XML attribute or element name, depending on the argument's "yin-element" statement.
引数の名前は、引数の「陰の要素」文に応じて、それがXML属性または要素名として使用されYINマッピングで使用されています。
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| yin-element | 7.17.2.2 | 0..1 |
+--------------+----------+-------------+
The "yin-element" statement, which is optional, takes as an argument the string "true" or "false". This statement indicates if the argument is mapped to an XML element in YIN or to an XML attribute (see Section 11).
オプションである「陰-要素」文は、引数として受け取り、文字列「true」または「false」。引数は（セクション11を参照）YINでのXML要素またはXML属性にマップされている場合、この文は示しています。
If no "yin-element" statement is present, it defaults to "false".
「偽」への「陰-要素」文が存在しない場合、それがデフォルトになります。
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"; } ...
私-インターフェースをモジュール{...私、拡張子{接頭辞「MYEXT」をインポートします。 } ...
container interfaces { ... myext:c-define "MY_INTERFACES"; } }
容器インタフェース{... MYEXT：C-定義 "MY_INTERFACES"。 }}
This section defines statements related to conformance, as described in Section 5.6.
このセクションは、セクション5.6で説明したように、適合性に関連した文を定義します。
The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see Section 7.18.2). Schema nodes tagged with a feature are ignored by the device unless the device supports the given feature. This allows portions of the YANG module to be conditional based on conditions on the device. The model can represent the abilities of the device within the model, giving a richer model that allows for differing device abilities and roles.
「機能」ステートメントは、スキーマの一部が条件としてマークされるメカニズムを定義するために使用されます。機能名が後に「IF-機能」ステートメントを使用して参照できるように定義される（セクション7.18.2を参照してください）。デバイスが特定の機能をサポートしていない限り、機能でタグ付けスキーマのノードは、デバイスによって無視されます。これは、YANGモジュールの部分は、デバイス上の条件に基づいて、条件付きにすることができます。このモデルは、デバイスの能力や役割の違いを可能にし、より豊かなモデルを与えて、モデル内のデバイスの能力を表すことができます。
The argument to the "feature" statement is the name of the new feature, and follows the rules for identifiers in Section 6.2. This name is used by the "if-feature" statement to tie the schema nodes to the feature.
「機能」文の引数には、新しい機能の名前で、6.2節での識別子の規則に従います。この名前は機能にスキーマノードを結びつけるために、「IF-機能」文で使用されています。
In this example, a feature called "local-storage" represents the ability for a device to store syslog messages on local storage of some sort. This feature is used to make the "local-storage-limit" leaf conditional on the presence of some sort of local storage. If the device does not report that it supports this feature, the "local-storage-limit" node is not supported.
この例では、「ローカル・ストレージ」と呼ばれる機能は、ある種のローカルストレージ上のsyslogメッセージを格納するデバイスの能力を表しています。この機能は、ローカルストレージのいくつかの並べ替えの存在に「ローカルストレージ・リミット」の葉を条件付きにするために使用されます。デバイスがこの機能をサポートしていることを報告しない場合は、「ローカルストレージ・リミット」ノードがサポートされていません。
module syslog { ... feature local-storage { description "This feature means the device supports local storage (memory, flash or disk) that can be used to store syslog messages."; }
「syslogメッセージを格納するために使用することができ、この機能は、デバイスは、ローカルストレージ（メモリ、フラッシュまたはディスク）をサポートすることを意味する。」モジュールのsyslog {...ローカルストレージ{フィーチャー。 }
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-機能」の文は、YANG構文内の多くの場所で使用することができます。デバイスがその機能をサポートしていないとき、「IF-機能」のタグが付いた定義は無視されます。
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-機能」サブステートメントを有する）任意の他の機能に依存している機能を実装するデバイスのためのために、デバイスは、すべての依存機能を実装しなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
The "if-feature" statement makes its parent statement conditional. The argument is the name of a feature, as defined by a "feature" statement. The parent statement is implemented by servers that support this feature. If a prefix is present on the feature name, it refers to a feature defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, a feature with the matching name MUST be defined in the current module or an included submodule.
「IF-機能」の文は、その親ステートメントは、条件付きになります。 「機能」の文で定義された引数は、機能の名前です。親文は、この機能をサポートするサーバーによって実装されます。接頭辞が機能名に存在する場合、それはその接頭辞、または接頭辞がローカルモジュールのプレフィックスと一致した場合、ローカルモジュールをインポートされたモジュールで定義された機能を指します。そうでない場合は、一致する名前を持つ機能は、現在のモジュールまたは含まサブモジュールで定義されなければなりません。
Since submodules cannot include the parent module, any features in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the feature.
サブモジュールは親モジュールを含めることはできませんので、サブモジュールにさらされる必要があるモジュール内のすべての機能は、サブモジュールで定義する必要があります。サブモジュールは、機能の定義を見つけるために、このサブモジュールを含めることができます。
The "deviation" statement defines a hierarchy of a module that the device does not implement faithfully. The argument is a string that identifies the node in the schema tree where a deviation from the module occurs. This node is called the deviation's target node. The contents of the "deviation" statement give details about the deviation.
「ずれ」の文は、デバイスが忠実に実装していないモジュールの階層を定義します。引数は、モジュールからのずれが発生するスキーマ・ツリー内のノードを識別する文字列です。このノードは、偏差のターゲットノードと呼ばれています。 「ずれ」の文の内容は、偏差についての詳細を与えます。
The argument string is an absolute schema node identifier (see Section 6.5).
引数文字列は、絶対スキーマノード識別子（セクション6.5を参照）です。
Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards.
偏差は、デバイスまたはデバイスのクラスは標準から逸脱する方法を定義します。これは、彼らが実装は標準からどのように変化するかを学習するための仕組みであるため、偏差は、公表標準の一部にすることはできませんことを意味します。
Device deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. A device that deviates from a module is not fully compliant with the module.
デバイス偏差が強く推奨されており、最後の手段としてのみ使用しなければなりません。デバイスが標準に従うことを失敗したかのアプリケーションを伝えることは正しく標準を実装するため代わるものではありません。モジュールから逸脱デバイスは、モジュールに完全に準拠していません。
However, in some cases, a particular device may not have the hardware or software ability to support parts of a standard module. When this occurs, the device makes a choice either to treat attempts to configure unsupported parts of the module as an error that is reported back to the unsuspecting application or ignore those incoming requests. Neither choice is acceptable.
しかし、いくつかのケースでは、特定のデバイスは、標準モジュールの一部をサポートするためのハードウェアまたはソフトウェアの能力を有していなくてもよいです。これが発生すると、デバイスが戻って疑いを持たないアプリケーションに報告されたエラーとしてモジュールのサポートされていない部分を設定したり、これらの着信要求を無視しようとする試みを治療するためのいずれかを選択します。どちらの選択が可能です。
Instead, YANG allows devices to document portions of a base module that are not supported or supported but with different syntax, by using the "deviation" statement.
その代わりに、YANGは、デバイスが「ずれ」ステートメントを使用して、サポートまたはサポートされているが、別の構文を使用していないベースモジュールの部分を文書化することを可能にします。
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 1..n |
| reference | 7.19.4 | 0..1 |
+--------------+----------+-------------+
The "deviate" statement defines how the device's implementation of the target node deviates from its original definition. The argument is one of the strings "not-supported", "add", "replace", or "delete".
「逸脱」の文は、ターゲットノードのデバイスの実装は、元の定義から外れる方法を定義します。引数は、文字列「 - サポートされていません」の一つである「追加」、「置換」、または「削除」。
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.
「追加」引数は、ターゲット・ノードにプロパティを追加します。プロパティは「外れ」の文にサブステートメントで識別されている追加します。プロパティは1度だけ表示することができた場合は、プロパティがターゲットノードに存在してはなりません。
The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node.
引数「置き換え」は、対象ノードのプロパティを置き換えます。プロパティは「逸脱」声明へのサブステートメントで識別されている交換します。交換するプロパティは、ターゲット・ノードに存在しなければなりません。
The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node.
引数「削除」は、対象ノードからプロパティを削除します。削除するプロパティは、「削除」ステートメントにサブステートメントによって識別されます。サプのキーワードがターゲットノードに対応するキーワードに一致しなければならない、引数の文字列がターゲットノードに対応するキーワードの引数文字列に等しくなければなりません。
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 |
+--------------+---------+-------------+
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 } }
偏差/塩基：システム/ベース：ユーザー/塩基：タイプ{{デフォルト「admin」を追加逸脱。 //新しいユーザーは、デフォルトでは「管理者」}}です
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; } }
偏差/塩基：システム/ベース：ネームサーバ{{MAX-要素3を交換逸脱。 }}
If the original definition is:
オリジナルの定義がある場合：
container system { must "daytime or time"; ... }
容器システム{しなければならない「昼間又は時間」。 ...}
a device might remove this must constraint by doing:
デバイスが実行して制約する必要があります。これを除去することがあります：
deviation "/base:system" { deviate delete { must "daytime or time"; } }
偏差「/塩基：システム」{削除逸脱{しなければならない「昼間又は時間」。 }}
This section defines substatements common to several other statements.
このセクションでは、いくつかの他の文に共通のサブステートメントを定義します。
The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration will be part of the reply to a <get-config> request, and can be sent in a <copy-config> or <edit-config> request.
「設定」の文は、引数として文字列を取り、「true」または「false」。 「設定」は「真」である場合には、定義が設定を表します。コンフィギュレーションを表すデータノードは、<GET-config>の要求に対する応答の一部となり、そして、<コピー設定>または<編集-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.
「設定」は「偽」である場合には、定義が状態データを表します。状態データを表すデータノードは、への応答の一部となる<GET>が、<GET-config>の要求に、そして<コピー設定>または<編集-config>の要求で送信することができないではありません。
If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node.
「設定」が指定されていない場合、デフォルトでは親スキーマノードの「設定」の値と同じです。親ノードが「ケース」のノードである場合、値は「ケース」ノードの親「選択」ノードと同じです。
If the top node does not specify a "config" statement, the default is "true".
トップノードは、「設定」の文を指定しない場合、デフォルトは「true」です。
If a node has "config" set to "false", no node underneath it can have "config" set to "true".
ノードは「偽」に設定し、「設定」、それが「真」に設定し、「設定」を持つことができるの下にいないノードがある場合。
The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete".
「状態」の文では、引数の文字列「現在」の一つ、「非推奨」、または「時代遅れ」となります。
o "current" means that the definition is current and valid.
o「は、現在は」定義が現在、有効であることを意味しています。
o "deprecated" indicates an obsolete definition, but it permits new/ continued implementation in order to foster interoperability with older/existing implementations.
O「非推奨」時代遅れの定義を示し、それは、古い/既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
o "obsolete" means the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations.
o「は時代遅れ」と定義が廃止され、実装されてはならず、/または実装から除去することができることを意味します。
If no status is specified, the default is "current".
何の状態が指定されていない場合、デフォルトでは「現在」です。
If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module.
定義は、「現在」である場合は、同じモジュール内の「非推奨」または「時代遅れ」の定義を参照してはなりません。
If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module.
定義は、「非推奨」されている場合は、同じモジュール内で「時代遅れ」の定義を参照してはなりません。
For example, the following is illegal:
例えば、以下は違法です。
typedef my-type {
status deprecated;
type int32;
}
leaf my-leaf { status current; type my-type; // illegal, since my-type is deprecated }
葉私の葉{現在の状態。私のタイプを入力します。 }私のタイプは廃止されているので、//違法
The "description" statement takes as an argument a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability, it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module.
「説明」の文は、引数として、この定義の人間が読めるテキスト記述を含む文字列を取ります。テキストは、モジュール開発者が選択した言語（または言語）に設けられています。相互運用性のために、広くモジュールを使用するネットワーク管理者のコミュニティの中で理解されている言語を選択することをお勧めします。
The "reference" statement takes as an argument a string that is used to specify a textual cross-reference to an external document, either another module that defines related management information, or a document that provides additional information relevant to this definition.
「参照」ステートメントは、引数として、外部文書へのテキストの相互参照を指定するために使用される文字列、関連する管理情報を定義する別のモジュール、またはこの定義に関連する追加情報を提供するドキュメントのいずれかをとります。
For example, a typedef for a "uri" data type could look like:
たとえば、「URI」データ型のtypedefは、次のようになります。
typedef uri {
type string;
reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax";
...
}
The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression (see Section 6.4), which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the node defined by the parent data definition statement is valid; otherwise, it is not.
「とき」の文は、条件付きの親データ定義文を作ります。親データ定義文で定義されたノードにのみ有効ですときで指定された条件文が成立している「とき」。文の引数には、正式にこの条件を指定するために使用されるXPath式（6.4節を参照）、です。 XPath式は、概念的に特定のインスタンスのための「真」に評価された場合、そのノードの親データ定義によって定義されたステートメントが有効です。それ以外の場合は、そうではありません。
See Section 8.3.2 for additional information.
追加情報については、8.3.2項を参照してください。
The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
XPath式は、概念的6.4.1における定義に加えて、次のコンテキストで評価されています。
o If the "when" statement is a child of an "augment" statement, then the context node is the augment's target node in the data tree, if the target node is a data node. Otherwise, the context node is the closest ancestor node to the target node that is also a data node.
声明文を「増やす」の子である「と、」ターゲット・ノードがデータノードである場合、O場合は、コンテキストノードは、データツリー内のオーグメントのターゲット・ノードです。そうでない場合は、コンテキスト・ノードは、データノードであるターゲットノードに最も近い祖先ノードです。
o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node.
声明は「用途」、「選択」の子である、または「ケース」文「とき」O、その後、コンテキストノードは、「用途」、「選択」、または「ケース」ノードに最も近い祖先ノードである場合それはまた、データノードです。
o If the "when" statement is a child of any other data definition statement, the context node is the data definition's node in the data tree.
O文は、他のデータ定義文の子である「とき」、コンテキストノードがデータツリー内のデータ定義のノードがある場合。
o The accessible tree is made up of all nodes in the data tree, and all leafs with default values in use (see Section 7.6.1).
Oアクセスツリーは、データツリー内のすべてのノードで構成され、かつ、使用中のデフォルト値を持つすべてのリーフ（セクション7.6.1を参照）されます。
The accessible tree depends on the context node:
アクセスツリーはコンテキストノードによって異なります。
o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
コンテキストノードが構成を表す場合、O、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベルのコンフィギュレーションデータノードを有します。
o If the context node represents state data, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
コンテキストノードが状態データを表す場合、O、ツリーは、デバイス上のすべての状態データ、及び<ランニング/>データストアです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベル・データ・ノードを有します。
o If the context node represents notification content, the tree is the notification XML instance document. The XPath root node has the element representing the notification being defined as the only child.
コンテキストノードは、通知内容を表す場合、O、ツリー通知XMLインスタンスドキュメントです。 XPathのルートノードは、唯一の子として定義される通知を表す要素を有します。
o If the context node represents RPC input parameters, the tree is the RPC XML instance document. The XPath root node has the element representing the RPC operation being defined as the only child.
コンテキストノードがRPC入力パラメータを表す場合、O、ツリーは、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出力パラメータを表す場合、O、ツリーは、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エバリュエータを使用する必要がないことを意味します。 「とき」の文は非常によく、特別に書かれたコードで実現することができます。
Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines.
いくつかのYANG文は有効なデータに制約を定義します。これらの制約は、文が定義するデータの種類に応じて、異なる方法で適用されます。
o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree.
制約が構成データに定義されている場合は、O、それは有効な構成データツリーに真でなければなりません。
o If the constraint is defined on state data, it MUST be true in a reply to a <get> operation without a filter.
制約が状態データに定義されている場合は、O、それはフィルタなし<GET>操作への応答に真でなければなりません。
o If the constraint is defined on notification content, it MUST be true in any notification instance.
制約が通知内容に定義されている場合、O、それは任意の通知インスタンスに真でなければなりません。
o If the constraint is defined on RPC input parameters, it MUST be true in an invocation of the RPC operation.
制約がRPC入力パラメータに定義されている場合、O、それは、RPC操作の呼び出しに真でなければなりません。
o If the constraint is defined on RPC output parameters, it MUST be true in the RPC reply.
制約がRPC出力パラメータに定義されている場合は、O、それは、RPC応答で真でなければなりません。
Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device.
親ノード上の条件は、ノードの階層の自然な結果として、子ノード上の制約に影響を与えます。親ノードが現在のデバイスで満たされていない「」または「IF-機能」性質を持っている場合は、「しなければならない」「必須」、「最小要素」、および「MAX-要素」制約は適用されません。
In this example, the "mandatory" constraint on the "longitude" leaf are not enforced on devices that lack the "has-gps" feature:
この例では、「経度」の葉の「必須」制約「を持っているA-GPS」機能が不足しているデバイスには適用されません。
container location {
if-feature has-gps;
leaf longitude {
mandatory true;
...
}
}
For configuration data, there are three windows when constraints MUST be enforced:
コンフィギュレーション・データの場合は、制約が適用されなければならない3つの窓があります。
o during parsing of RPC payloads
O RPCペイロードの解析中
o during processing of NETCONF operations
NETCONF動作の処理中にO
o during validation
検証中のO
Each of these scenarios is considered in the following sections.
これらのシナリオのそれぞれは、以下のセクションで考えられています。
When content arrives in RPC payloads, it MUST be well-formed XML, following the hierarchy and content rules defined by the set of models the device implements.
コンテンツは、RPCペイロードに到着すると、それは、モデルデバイス実装のセットによって定義された階層とコンテンツルールに従って、XMLを十分に形成されなければなりません。
o If a leaf data value does not match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties, the server MUST reply with an "invalid-value" error-tag in the rpc-error, and with the error-app-tag and error-message associated with the constraint, if any exist.
O葉のデータ値は、タイプの「レンジ」、「長さ」に定義されたものを含む葉の型制約、及び「パターン」の特性と一致しない場合は、「無効値」エラータグで応答しなければならないサーバRPCエラーで、エラーアプリタグとエラーメッセージとが存在する場合、制約に関連付けられています。
o If all keys of a list entry are not present, the server MUST reply with a "missing-element" error-tag in the rpc-error.
リストのエントリのすべてのキーが存在しない場合は、O、サーバーは、RPCエラーで「欠けている要素」エラータグと返答しなければなりません。
o If data for more than one case branch of a choice is present, the server MUST reply with a "bad-element" in the rpc-error.
選択した複数のケースブランチのデータが存在する場合は、O、サーバーは、RPCエラーで「悪い要素」と返答しなければなりません。
o If data for a node tagged with "if-feature" is present, and the feature is not supported by the device, the server MUST reply with an "unknown-element" error-tag in the rpc-error.
Oノードのデータが「IF-機能」でタグ付けされた場合は存在し、そして機能がデバイスによってサポートされていない、サーバは、RPCエラーの「未知要素」エラータグで応答しなければなりません。
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.
「いつ」存在し、条件が「偽」と評価された「いつ」、サーバーは、RPCエラーの「未知要素」エラータグで応答しなければならないでタグ付けされたノードのデータであれば、O。
o For insert handling, if the value for the attributes "before" and "after" are not valid for the type of the appropriate key leafs, the server MUST reply with a "bad-attribute" error-tag in the rpc-error.
挿入処理のためのO、適切なキー葉の種類は有効ではありません「の後に」「前」属性の値とは、サーバは、RPCエラーで「悪い属性」エラータグで返答しなければならない場合。
o If the attributes "before" and "after" appears in any element that is not a list whose "ordered-by" property is "user", the server MUST reply with an "unknown-attribute" error-tag in the rpc-error.
「注文-で」プロパティリストではありません任意の要素に表示され、「後」、「前」と属性が「ユーザー」である場合には、O、サーバはRPC-に「未知の属性」エラータグで返答しなければなりませんエラー。
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サーバは、コンフィギュレーションデータストアにデータを適用することによって、<編集設定>動作を行います。この処理中に、次のエラーが検出されなければなりません。
o Delete requests for non-existent data.
O存在しないデータの要求を削除します。
o Create requests for existent data.
既存のデータの要求を作成します。
o Insert requests with "before" or "after" parameters that do not exist.
Oまたはパラメータ「の後に」それは存在しない「前」とのリクエストを挿入します。
During <edit-config> processing:
<編集-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操作は、「選択」の下でデータ・ノードを作成する場合は、O、他の「ケース」の枝から既存のノードがサーバーによって削除されます。
o If the NETCONF operation modifies a data node such that any node's "when" expression becomes false, then the node with the "when" expression is deleted by the server.
O NETCONF操作はデータノードを変更する場合は、そのようなことで任意のノードの式が偽になる「」、そしてノード表現がサーバーによって削除された「とき」。
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.
データストアの処理が完了すると、最終的内容は、すべての検証の制約に従わなければなりません。この検証処理は、データストアに応じて異なる時間に実行されます。データストアは<ランニング/>または<スタートアップ/>されている場合は、これらの制約は、<編集-config設定>または<コピー-config>の操作の終了時に実施されなければなりません。データストアは<候補/>である場合には、制約の施行は、<コミット>または<検証>操作まで延期されます。
o Any "must" constraints MUST evaluate to "true".
Oはいずれも制約は、「真」と評価されなければならない「しなければなりません」。
o Any referential integrity constraints defined via the "path" statement MUST be satisfied.
O「パス」文を経由して定義された参照整合性制約を満たさなければなりません。
o Any "unique" constraints on lists MUST be satisfied.
Oリスト上の任意の「ユニーク」の制約が満たさなければなりません。
o The "min-elements" and "max-elements" constraints are enforced for lists and leaf-lists.
「MIN-要素」と「MAX-要素」O制約がリストとリーフリストに対して適用されます。
YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements from the management information model.
YANGは、多くのプログラミング言語と同様のビルトインタイプのセットを、持っていますが、管理情報モデルから特別な要求のためにいくつかの違いで。
Additional types may be defined, derived from those built-in types or from other derived types. Derived types may use subtyping to formally restrict the set of possible values.
付加的なタイプは、定義されたビルトインタイプから又は他の派生型に由来してもよいです。派生型は、正式に可能な値のセットを制限するためにサブタイプを使用することができます。
The different built-in types and their derived types allow different kinds of subtyping, namely length and regular expression restrictions of strings (Sections 9.4.4 and 9.4.6) and range restrictions of numeric types (Section 9.2.4).
異なる内蔵型とその派生型はサブタイプ、すなわち、長さと文字列（セクション9.4.4と9.4.6）と数値型（セクション9.2.4）の範囲の制限の正規表現の制約の種類を許可します。
The lexical representation of a value of a certain type is used in the NETCONF messages and when specifying default values and numerical ranges in YANG modules.
YANGモジュールのデフォルト値と数値範囲を指定するとき、特定のタイプの値の字句表現は、NETCONFメッセージで使用されています。
For most types, there is a single canonical representation of the type's values. Some types allow multiple lexical representations of the same value, for example, the positive integer "17" can be represented as "+17" or "17". Implementations MUST support all lexical representations specified in this document.
ほとんどのタイプでは、タイプの値の単一の標準表現があります。いくつかのタイプは、例えば、正の整数「17」が「17」または「17」のように表すことができ、同じ値の複数の語彙表現を可能にします。実装は、この文書で指定されたすべての字句表現をサポートしなければなりません。
When a NETCONF server sends data, it MUST be in the canonical form.
NETCONFサーバがデータを送信するときに、正規の形式でなければなりません。
Some types have a lexical representation that depends on the XML context in which they occur. These types do not have a canonical form.
いくつかの種類は、彼らが発生したXMLコンテキストに依存字句表現を持っています。これらのタイプは、標準的な形式を持っていません。
The integer built-in types are int8, int16, int32, int64, uint8, uint16, uint32, and uint64. They represent signed and unsigned integers of different sizes:
組み込み型整数INT8、INT16、INT32、Int64の、UINT8、uint16の、UINT32、およびUINT64です。彼らは、異なるサイズの符号付きと符号なし整数を表します。
int8 represents integer values between -128 and 127, inclusively.
INT8は包括的に、-128と127の間の整数値を表します。
int16 represents integer values between -32768 and 32767, inclusively.
INT16は、包括的に、-32768から32767の間の整数値を表します。
int32 represents integer values between -2147483648 and 2147483647, inclusively.
INT32は、包括的に、-2147483648と2147483647の間の整数値を表します。
int64 represents integer values between -9223372036854775808 and 9223372036854775807, inclusively.
Int64のは、包括的、-9223372036854775808と9223372036854775807間の整数値を表します。
uint8 represents integer values between 0 and 255, inclusively.
UINT8は包括的に、0〜255の整数値を表します。
uint16 represents integer values between 0 and 65535, inclusively.
uint16のは、包括的に、0〜65535の整数値を表します。
uint32 represents integer values between 0 and 4294967295, inclusively.
UINT32は包括的に、0から4294967295までの整数値を表します。
uint64 represents integer values between 0 and 18446744073709551615, inclusively.
UINT64は包括的に、0と18446744073709551615の間の整数値を表します。
An integer value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits. If no sign is specified, "+" is assumed.
整数値は、辞書的に任意の符号として表される（「+」または「 - 」）、桁のシーケンスが続きます。兆候が指定されていない場合は、「+」と想定されます。
For convenience, when specifying a default value for an integer in a YANG module, an alternative lexical representation can be used, which represents the value in a hexadecimal or octal notation. The hexadecimal notation consists of an optional sign ("+" or "-"), the characters "0x" followed a number of hexadecimal digits, where letters may be uppercase or lowercase. The octal notation consists of an optional sign ("+" or "-"), the character "0" followed a number of octal digits.
YANGモジュールの整数のデフォルト値を指定する際の便宜のために、代替的な語彙表現は、16進数または8進数の表記で値を表す、使用することができます。 16進数は、オプションの符号から成る（「+」または「 - 」）、文字「0X」は文字が大文字または小文字とすることができる16進数字の数に従いました。進表記は、オプションの符号から成る（「+」または「 - 」）、文字「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」）、それは進数として解釈されていることに留意されたいです。 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
//有効な値4711 //法的正の値4711 //法的正の値-123 //法的負値0xf00f //法的正の16進値-0xf //法的負の16進数値052 //法的正進値
// illegal values - 1 // illegal intermediate space
//不正な値 - 1つの//違法中間空間
The canonical form of a positive integer does not include the sign "+". Leading zeros are prohibited. The value zero is represented as "0".
正の整数の正規の形式は、記号「+」が含まれていません。先行ゼロは禁止されています。ゼロの値は「0」として表されます。
All integer types can be restricted with the "range" statement (Section 9.2.4).
すべての整数型は、「範囲」の文（9.2.4項）で制限することができます。
The "range" statement, which is an optional substatement to the "type" statement, takes as an argument a range expression string. It is used to restrict integer and decimal built-in types, or types derived from those.
「タイプ」文とオプションのサブステートメントである「範囲」の文では、引数として範囲式の文字列を取ります。組み込み型、またはそれらから派生型整数と小数を制限するために使用されます。
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.
範囲は、「..」の明示的な値は、以下の包括的な結合し、二つの連続したドットで構成され、上部フルバウンド。 「|」は、複数の値または範囲を区切っ挙げることができます。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。範囲制限が既に範囲制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間体を複数の範囲に明示的な値または範囲、または分割範囲を削除してギャップ。範囲式で与えられるそれぞれの明示的な値及び範囲の境界値は制限されるタイプと一致、または特別な値「分」または「最大」のいずれかでなければなりません。 「最小」および「最大」は、それぞれ、制限されるタイプのために受け入れ最小値と最大値を意味します。
The range expression syntax is formally defined by the rule "range-arg" in Section 12.
範囲式の構文は、正式に第12節でルール「の範囲-argに」で定義されています。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
typedef my-base-int32-type {
type int32 {
range "1..4 | 10..20";
}
}
typedef my-type1 { type my-base-int32-type { // legal range restriction range "11..max"; // 11..20 } }
私-TYPE1のtypedef {私の塩基INT32型{//有効範囲の制限範囲 "11..max" と入力。 // 11..20}}
typedef my-type2 { type my-base-int32-type { // illegal range restriction range "11..100"; } }
MY-TYPE2のtypedef {私の塩基INT32型{//不正範囲の制限範囲 "11..100" を入力。 }}
The decimal64 type represents a subset of the real numbers, which can be represented by decimal numerals. The value space of decimal64 is the set of numbers that can be obtained by multiplying a 64-bit signed integer by a negative power of ten, i.e., expressible as "i x 10^-n" where i is an integer64 and n is an integer between 1 and 18, inclusively.
decimal64型は、小数点の数字で表すことができる実数のサブセットを表しています。 decimal64の値空間iはinteger64であり、nは整数である「IX 10 ^ -n」として表現10の負のパワーにより64ビット符号付き整数を乗算して得られる数値のセット、すなわち、あります1〜18、包括。
A decimal64 value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits. If no sign is specified, "+" is assumed.
decimal64値は字句オプションの符号として表される - （「」）（「+」または「an」）、桁のシーケンスが続く、任意に周期小数点インジケータと桁のシーケンスとして続きます。兆候が指定されていない場合は、「+」と想定されます。
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の正規の形式は、記号「+」が含まれていません。小数点が必要です。先頭と末尾のゼロは、小数点の前後少なくとも一桁が存在しなければならないことルールに従う禁止されています。ゼロの値を「0.0」として表されます。
A decimal64 type can be restricted with the "range" statement (Section 9.2.4).
decimal64タイプは「範囲」の文（9.2.4項）で制限することができます。
The "fraction-digits" statement, which is a substatement to the "type" statement, MUST be present if the type is "decimal64". It takes as an argument an integer between 1 and 18, inclusively. It controls the size of the minimum difference between values of a decimal64 type, by restricting the value space to numbers that are expressible as "i x 10^-n" where n is the fraction-digits argument.
タイプが「decimal64」であれば「タイプ」の文にサブステートメントである「端数桁」の文では、存在しなければなりません。これは、包括的、引数として1と18の間の整数をとります。これは、nが小数桁引数である「私は10 ^ -n×」として表現されている番号に値空間を制限することによりdecimal64型の値との間の最小の差の大きさを制御します。
The following table lists the minimum and maximum value for each fraction-digit value:
次の表は、各画分桁の値の最小値と最大値を示します。
+----------------+-----------------------+----------------------+
| fraction-digit | min | max |
+----------------+-----------------------+----------------------+
| 1 | -922337203685477580.8 | 922337203685477580.7 |
| 2 | -92233720368547758.08 | 92233720368547758.07 |
| 3 | -9223372036854775.808 | 9223372036854775.807 |
| 4 | -922337203685477.5808 | 922337203685477.5807 |
| 5 | -92233720368547.75808 | 92233720368547.75807 |
| 6 | -9223372036854.775808 | 9223372036854.775807 |
| 7 | -922337203685.4775808 | 922337203685.4775807 |
| 8 | -92233720368.54775808 | 92233720368.54775807 |
| 9 | -9223372036.854775808 | 9223372036.854775807 |
| 10 | -922337203.6854775808 | 922337203.6854775807 |
| 11 | -92233720.36854775808 | 92233720.36854775807 |
| 12 | -9223372.036854775808 | 9223372.036854775807 |
| 13 | -922337.2036854775808 | 922337.2036854775807 |
| 14 | -92233.72036854775808 | 92233.72036854775807 |
| 15 | -9223.372036854775808 | 9223.372036854775807 |
| 16 | -922.3372036854775808 | 922.3372036854775807 |
| 17 | -92.23372036854775808 | 92.23372036854775807 |
| 18 | -9.223372036854775808 | 9.223372036854775807 |
+----------------+-----------------------+----------------------+
typedef my-decimal {
type decimal64 {
fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max";
}
}
The string built-in type represents human-readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]:
ビルトインタイプの文字列は、YANGで判読可能な文字列を表します。有効な文字は、[ISO.10646]タブ、キャリッジリターン、ラインフィード、およびUnicodeとISO / IEC 10646の法的な文字です。
;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. string = *char char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / %x10000-10FFFF
;;任意のUnicode文字、サロゲートブロックを除く、;; FFFE、そしてFFFF。ストリング= * CHARチャー=％X9 /％をxA /％のXD /％X20-D7FF /％のxE000-FFFD /％x10000-10FFFF
A string value is lexically represented as character data in the XML instance documents.
文字列値は、辞書的にXMLインスタンス文書中の文字データとして表現されます。
The canonical form is the same as the lexical representation. No Unicode normalization is performed of string values.
標準形式は、語彙表現と同じです。いいえUnicode正規化は、文字列値の実行されません。
A string can be restricted with the "length" (Section 9.4.4) and "pattern" (Section 9.4.6) statements.
文字列は、「長さ」（9.4.4項）と「パターン」（9.4.6項）文で制限することができます。
The "length" statement, which is an optional substatement to the "type" statement, takes as an argument a length expression string. It is used to restrict the built-in type "string", or types derived from "string".
「タイプ」文とオプションのサブステートメントである「長さ」の文では、引数の長さの表現文字列として取ります。ビルトインタイプの「文字列」、または「文字列」から派生型を制限するために使用されます。
A "length" statement restricts the number of Unicode characters in the string.
「長さ」の文は、文字列内のUnicode文字の数を制限します。
A length range consists of an explicit value, or a lower bound, two consecutive dots "..", and an upper bound. Multiple values or ranges can be given, separated by "|". Length-restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a length restriction is applied to an already length-restricted type, the new restriction MUST be equal or more limiting, that is, raising the lower bounds, reducing the upper bounds, removing explicit length values or ranges, or splitting ranges into multiple ranges with intermediate gaps. A length value is a non-negative integer, or one of the special values "min" or "max". "min" and "max" mean the minimum and maximum length accepted for the type being restricted, respectively. An implementation is not required to support a length value larger than 18446744073709551615.
長さの範囲は、「..」の明示的な値、または下限、二つの連続したドットで構成され、上限。 「|」は、複数の値または範囲を区切っ挙げることができます。長さ制限値が負であってはなりません。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。長さの制限は、すでに長制限タイプに適用した場合、新たな制限は、明示的な長さの値または範囲を、下限を上げる上限を減少、除去、つまり、制限同等以上であるか、または分割が複数の範囲に及びます中間ギャップが。長さの値は負でない整数、または特別な値「分」または「最大」の一つです。 「最小」および「最大」は、それぞれ、最小および制限されるタイプの許容最大長を意味します。実装は18446744073709551615より大きい長さの値をサポートするために必要とされません。
The length expression syntax is formally defined by the rule "length-arg" in Section 12.
長さの表現の構文は、正式に第12節でルール「長さ-argに」で定義されています。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
typedef my-base-str-type {
type string {
length "1..255";
}
}
type my-base-str-type { // legal length refinement length "11 | 42..max"; // 11 | 42..255 }
タイプ私の塩基STR型{//法的長洗練長「11 | 42..max」。 // 11 | 42..255}
type my-base-str-type { // illegal length refinement length "1..999"; }
私の塩基STR型{//不正な長さの洗練長「1..999」と入力。 }
The "pattern" statement, which is an optional substatement to the "type" statement, takes as an argument a regular expression string, as defined in [XSD-TYPES]. It is used to restrict the built-in type "string", or types derived from "string", to values that match the pattern.
[XSD-TYPES]で定義されるように、「タイプ」ステートメントの任意サプある「パターン」の文では、引数として正規表現文字列をとります。パターンに一致する値に内蔵型「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.
パターンの制限は、すでにパターン制限タイプに適用した場合、値が新しいパターンに加えて、基本型のすべてのパターンに一致しなければなりません。
+---------------+---------+-------------+
| substatement | section | cardinality |
+---------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+
With the following type:
以下のタイプの場合：
type string {
length "0..4";
pattern "[0-9a-fA-F]*";
}
the following strings match:
以下の文字列が一致します：
AB // legal 9A00 // legal
AB //法的// 9A00法的
and the following strings do not match:
そして次の文字列が一致しません。
00ABAB // illegal, too long xx00 // illegal, bad characters
00ABAB //違法、長すぎるXX00 //違法、不正な文字
The boolean built-in type represents a boolean value.
ブールビルトインタイプは、ブール値を表します。
The lexical representation of a boolean value is a string with a value of "true" or "false". These values MUST be in lowercase.
ブール値の字句表現は、「true」または「false」の値を持つ文字列です。これらの値は小文字でなければなりません。
The canonical form is the same as the lexical representation.
標準形式は、語彙表現と同じです。
A boolean cannot be restricted.
ブール値を制限することはできません。
The enumeration built-in type represents values from a set of assigned names.
内蔵型列挙は、割り当てられた名前のセットからの値を表します。
The lexical representation of an enumeration value is the assigned name string.
列挙値の字句表現は、割り当てられた名前の文字列です。
The canonical form is the assigned name string.
正規の形式は、割り当てられた名前の文字列です。
An enumeration cannot be restricted.
列挙は制限することができません。
The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of Unicode control codes SHOULD be avoided.
タイプが「列挙」であれば「タイプ」の文にサブステートメントである「列挙型」の文は、存在しなければなりません。これを繰り返し列挙型のそれぞれに割り当てられた名前を指定するために使用されます。これは、引数として割り当てられた名前である文字列を取ります。文字列は空にすることはできませんし、任意の先頭や末尾の空白文字があってはなりません。 Unicodeの制御コードの使用は避けるべきです。
The statement is optionally followed by a block of substatements that holds detailed enum information.
ステートメントは、必要に応じて詳細な列挙情報を保持するサブステートメントのブロックが続きます。
All assigned names in an enumeration MUST be unique.
列挙のすべての割り当てられた名前は固有でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+
The "value" statement, which is optional, is used to associate an integer value with the assigned name for the enum. This integer value MUST be in the range -2147483648 to 2147483647, and it MUST be unique within the enumeration type. The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.
オプションである「値」文は、列挙型のために割り当てられた名前と整数値を関連付けるために使用されます。この整数値は2147483647の範囲-2147483648でなければなりません、そして、それは列挙型内で一意でなければなりません。値はYANGとXMLエンコーディングによって未使用であるが、実装者への便宜として実施されます。
If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value.
値が指定されていない場合は、1が自動的に割り当てられます。 「列挙」サプが定義されている最初のものである場合は、割り当てられた値は、ゼロ（0）です。それ以外の場合は、割り当てられた値は、現在の最高列挙値よりも大きいものです。
If the current highest value is equal to 2147483647, then an enum value MUST be specified for "enum" substatements following the one with the current highest value.
現在の最高値は2147483647に等しい場合、列挙値は、現在の最高値とのいずれかを、以下、「列挙」サブステートメントに指定されなければなりません。
leaf myenum {
type enumeration {
enum zero;
enum one;
enum seven {
value 7;
}
}
}
The lexical representation of the leaf "myenum" with value "seven" is:
「7」の値を持つ葉「myenum」の字句表現は次のとおりです。
<myenum>seven</myenum>
<myenum> 7 </ myenum>
The bits built-in type represents a bit set. That is, a bits value is a set of flags identified by small integer position numbers starting at 0. Each bit number has an assigned name.
内蔵型ビットは、ビットセットを表します。つまり、ビット値は、各ビット数は0に割り当てられた名前を持つ開始小さな整数位置番号で識別フラグのセットです。
A bits type cannot be restricted.
ビットの種類を制限することはできません。
The lexical representation of the bits type is a space-separated list of the individual bit values that are set. An empty string thus represents a value where no bits are set.
ビットタイプの字句表現が設定されている個々のビットの値のスペースで区切られたリストです。空の文字列は、このように何ビットが設定されていない値を表します。
In the canonical form, the bit values are separated by a single space character and they appear ordered by their position (see Section 9.7.4.2).
標準的な形式で、ビット値は、単一の空白文字で区切られており、彼らは（セクション9.7.4.2を参照）の位置によって順序付けされて表示されます。
The "bit" statement, which is a substatement to the "type" statement, MUST be present if the type is "bits". It is repeatedly used to specify each assigned named bit of a bits type. It takes as an argument a string that is the assigned name of the bit. It is followed by a block of substatements that holds detailed bit information. The assigned name follows the same syntax rules as an identifier (see Section 6.2).
タイプが「ビット」であれば「タイプ」ステートメントにサプある「ビット」の文では、存在しなければなりません。繰り返しビットタイプのそれぞれ割り当てられた名前のビットを指定するために使用されます。これは、引数としてビットの割り当てられた名前である文字列を取ります。なお、詳細なビットの情報を保持するサブステートメントのブロックが続きます。割り当てられた名前は、識別子と同じ構文規則に従う（セクション6.2を参照）。
All assigned names in a bits type MUST be unique.
ビットタイプのすべての割り当てられた名前は固有でなければなりません。
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+
The "position" statement, which is optional, takes as an argument a non-negative integer value that specifies the bit's position within a hypothetical bit field. The position value MUST be in the range 0 to 4294967295, and it MUST be unique within the bits type. The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors.
オプションである「位置」の文では、引数として仮想的なビットフィールド内のビットの位置を指定する非負の整数値をとります。位置の値は4294967295の範囲0でなければなりません、そして、それはビットタイプ内で一意でなければなりません。値はYANGとNETCONFメッセージによって未使用であるが、実装者への便宜として実施されます。
If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position.
ビット位置が指定されていない場合は、1が自動的に割り当てられます。 「ビット」サプが定義されている最初のものである場合は、割り当てられた値は、ゼロ（0）です。そうでない場合、割り当てられた値は現在の最上位のビット位置よりも大きいものです。
If the current highest bit position value is equal to 4294967295, then a position value MUST be specified for "bit" substatements following the one with the current highest position value.
現在の最上位ビット位置値は4294967295に等しい場合、位置の値は、現在の最も高い位置の値を持つものを、以下「ビット」サブステートメントに指定されなければなりません。
Given the following leaf:
次の葉を考えます：
leaf mybits {
type bits {
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
bit 10-Mb-only {
position 2;
}
}
default "auto-sense-speed";
}
The lexical representation of this leaf with bit values disable-nagle and 10-Mb-only set would be:
ビット値でこの葉の字句表現が、ネーグルを無効にし、10-MB-のみセットは次のようになります。
<mybits>disable-nagle 10-Mb-only</mybits>
<mybits>無効-ネーグル10-MB-のみ</ mybits>
The binary built-in type represents any binary data, i.e., a sequence of octets.
内蔵型のバイナリは、任意のバイナリデータ、オクテット、すなわち、配列を表します。
A binary can be restricted with the "length" (Section 9.4.4) statement. The length of a binary value is the number of octets it contains.
バイナリは、「長さ」（9.4.4項）文で制限することができます。バイナリ値の長さは、それが含まれているオクテットの数です。
Binary values are encoded with the base64 encoding scheme (see [RFC4648], Section 4).
バイナリ値（[RFC4648]、セクション4を参照）BASE64符号化方式で符号化されます。
The canonical form of a binary value follows the rules in [RFC4648].
バイナリ値の標準形式は、[RFC4648]のルールに従います。
The leafref type is used to reference a particular leaf instance in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances.
leafrefタイプは、データ・ツリー内の特定のリーフ・インスタンスを参照するために使用されます。 「パス」サプ（セクション9.9.2）は、リーフ・インスタンスのセットを選択し、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.
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が参照葉は、一つ以上の特徴に基づいて条件付きである場合（セクション7.18.2を参照）、次いでleafrefタイプの葉はまた、特徴の少なくとも同じセットに基づいて、条件付きでなければなりません。
A leafref cannot be restricted.
leafrefを制限することはできません。
The "path" statement, which is a substatement to the "type" statement, MUST be present if the type is "leafref". It takes as an argument a string that MUST refer to a leaf or leaf-list node.
タイプが「leafref」であれば「タイプ」の文にサブステートメントである「パス」の文は、存在しなければなりません。これは、引数として、葉または葉-リストノードを参照する必要があります文字列を取ります。
The syntax for a path argument is a subset of the XPath abbreviated syntax. Predicates are used only for constraining the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 12.
path引数の構文は、XPath省略構文のサブセットです。述語は、唯一のリストエントリのためのキーのノードの値を拘束するために使用されています。各述語は、キーごとに1つの平等のテストで構成されており、リストは複数のキーを持っている場合は、複数の隣接する述語が存在してもよいです。構文は正式に第12節でルール「パス引数」によって定義されます。
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.
複数のキー参照を一意葉インスタンスを識別するために必要とされる場合述語にのみ使用されます。リストには、複数のキー、または必要とされ、リスト内のキー以外のリーフへの参照を持っている場合に発生します。これらのケースでは、複数leafrefsは、典型的に指定され、述語は、それらを一緒に結ぶために使用されます。
The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the leaf with the leafref type represents configuration data, this node set MUST be non-empty.
「経路」という表現は、ゼロ、1つ、または複数のノードからなるノードセットに評価します。 leafrefタイプの葉は、構成データを表す場合、このノードセットが非空でなければなりません。
The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1:
「パス」XPath式は、概念的6.4.1における定義に加えて、次のコンテキストで評価されています。
o The context node is the node in the data tree for which the "path" statement is defined.
コンテキストノードO「パス」文が定義されているデータツリー内のノードです。
The accessible tree depends on the context node:
アクセスツリーはコンテキストノードによって異なります。
o If the context node represents configuration data, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.
コンテキストノードが構成データを表す場合、O、ツリーは、コンテキストノードが存在するNETCONFデータストア内のデータです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベルのコンフィギュレーションデータノードを有します。
o Otherwise, the tree is all state data on the device, and the <running/> datastore. The XPath root node has all top-level data nodes in all modules as children.
Oそれ以外の場合は、ツリーには、デバイス上のすべての状態データ、および<ランニング/>データストアです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベル・データ・ノードを有します。
A leafref value is encoded the same way as the leaf it references.
leafref値は、参照葉と同じように符号化されています。
The canonical form of a leafref is the same as the canonical form of the leaf it references.
leafrefの正規の形式は、それが参照する葉の正規の形式と同じです。
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"; } }
葉MGMTインターフェイス{型leafref {パス「../interface/name」。 }}
An example of a corresponding XML snippet:
対応するXMLスニペットの例：
<interface> <name>eth0</name> </interface> <interface> <name>lo</name> </interface>
<インターフェース> <名前>はeth0 </名前> </インターフェイス> <インターフェイス> <名前> LO </名前> </インターフェイス>
<mgmt-interface>eth0</mgmt-interface>
<MGMTインターフェイス> eth0の</ MGMTインターフェイス>
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>
<インターフェース> <名前>はeth0 </名前> </管理ステータス>アップ<管理ステータス> <アドレス> <IP> 192.0.2.1 </ IP> </アドレス> <アドレス> <IP> 192.0.2.2 < </管理ステータス> <アドレス> <IP> 127.0.0.1 </ IP> </アドレスアップ/ IP> </アドレス> </インターフェイス> <インターフェイス> <名前> LO </名前> <管理状況> > </インターフェイス>
<default-address> <ifname>eth0</ifname> <address>192.0.2.2</address> </default-address>
<デフォルト・アドレス> <ifnameの>はeth0 </ ifnameの> <アドレス> 192.0.2.2 </アドレス> </デフォルトアドレス>
The following list uses a leafref for one of its keys. This is similar to a foreign key in a relational database.
以下のリストは、そのキーのいずれかのために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>
<インターフェース> <名前>はeth0 </名前> </管理ステータス>アップ<管理ステータス> <アドレス> <IP> 192.0.2.1 </ IP> </アドレス> <アドレス> <IP> 192.0.2.2 < / IP> </アドレス> </インターフェイス>
<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>
<パケットフィルタ> <IF-名> eth0の</ IF-名> <フィルタ-ID> 1 </フィルタ-ID> ... </パケットフィルタ> <パケットフィルタ> <IF-名> eth0の< / IF-名> <フィルタ-ID> 2 </フィルタ-ID> ... </パケットフィルタ>
The following notification defines two leafrefs to refer to an existing admin-status:
次の通知は、既存の管理ステータスを参照するには、2つのleafrefsを定義しています。
notification link-failure {
leaf if-name {
type leafref {
path "/interface/name";
}
}
leaf admin-status {
type leafref {
path
"/interface[name = current()/../if-name]"
+ "/admin-status";
}
}
}
An example of a corresponding XML notification:
対応するXML通知の例：
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2008-04-01T00:01:00Z</eventTime> <link-failure xmlns="http://acme.example.com/system"> <if-name>eth0</if-name> <admin-status>up</admin-status> </link-failure> </notification>
<通知のxmlns = "壷：IETF：のparams：XML：NS：NETCONF：通知：1.0"> <イベント時刻> 2008-04-01T00：01：00Z </イベント時刻> <リンク障害のxmlns = "のhttp：//アクメ.example.comと/システム "> <IF-名>はeth0 </ IF-名> </管理ステータスアップ<管理ステータス>> </リンク障害> </通知>
The identityref type is used to reference an existing identity (see Section 7.16).
identityrefタイプが既存のIDを参照するために使用されている（7.16項を参照してください）。
An identityref cannot be restricted.
identityrefを制限することはできません。
The "base" statement, which is a substatement to the "type" statement, MUST be present if the type is "identityref". The argument is the name of an identity, as defined by an "identity" statement. If a prefix is present on the identity name, it refers to an identity defined in the module that was imported with that prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule.
タイプが「identityref」であれば「タイプ」の文にサブステートメントである「ベース」の文は、存在しなければなりません。 「アイデンティティ」の文で定義された引数は、アイデンティティーの名前です。接頭辞がID名に存在する場合、それはその接頭辞でインポートされたモジュールで定義された同一性をいいます。そうでない場合は、一致する名前を持つアイデンティティは、現在のモジュールまたは含まサブモジュールで定義されなければなりません。
Valid values for an identityref are any identities derived from the identityref's base identity. On a particular server, the valid values are further restricted to the set of identities defined in the modules supported by the server.
identityrefの有効な値はidentityrefの基本アイデンティティ由来の任意のIDです。特定のサーバーでは、有効な値は、さらに、サーバでサポートされているモジュールで定義されたアイデンティティのセットに制限されています。
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.
[XML-NAMES]で定義されているようidentityrefは呼ばアイデンティティの修飾名としてエンコードされます。接頭辞が存在しない場合は、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が「デフォルト」の文を使用してデフォルト値が与えられた場合、デフォルト値のID名は、接頭辞を持っているかもしれません。接頭辞がID名に存在する場合、それはその接頭辞でインポートされたモジュールで定義された同一性をいいます。そうでない場合は、一致する名前を持つアイデンティティは、現在のモジュールまたは含まサブモジュールで定義されなければなりません。
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
字句形式は、値が発生するXMLコンテキストに依存するため、このタイプの標準形を有していません。
With the identity definitions in Section 7.16.3 and the following module:
セクション7.16.3でのアイデンティティの定義と、次のモジュールでは：
module my-crypto {
{私の-暗号をモジュール
namespace "http://example.com/my-crypto";
prefix mc;
import "crypto-base" { prefix "crypto"; }
インポート「暗号ベース」{接頭辞「暗号」。 }
identity aes { base "crypto:crypto-alg"; }
アイデンティティAES {塩基「暗号：暗号-ALG」。 }
leaf crypto { type identityref { base "crypto:crypto-alg"; } } }
リーフ暗号{型identityref {塩基「暗号：暗号-ALG」。 }}}
the leaf "crypto" will be encoded as follows, if the value is the "des3" identity defined in the "des" module:
葉「暗号」は値が「デ」モジュールで定義された「DES3」同一である場合は、次のようにエンコードされます。
<crypto xmlns:des="http://example.com/des">des:des3</crypto>
<暗号のxmlns：デ= "http://example.com/des">デ：DES3 </暗号>
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>
<暗号のxmlns：X = "http://example.com/des"> X：DES3 </暗号>
If the "crypto" leaf's value instead is "aes" defined in the "my-crypto" module, it can be encoded as:
「暗号」の葉の値ではなく、「私の-暗号」モジュールで定義された「AES」であれば、それはとしてエンコードすることができます。
<crypto xmlns:mc="http://example.com/my-crypto">mc:aes</crypto>
<暗号のxmlns：MC = "http://example.com/my-crypto"> MC：AES </暗号>
or, using the default namespace:
または、デフォルトの名前空間を使用しました：
<crypto>aes</crypto>
<暗号> AES </暗号>
The empty built-in type represents a leaf that does not have any value, it conveys information by its presence or absence.
空のビルトインタイプは、それがその存在または不在によって情報を伝える、任意の値を持っていない葉を表します。
An empty type cannot have a default value.
空のタイプは、デフォルト値を持つことができません。
An empty type cannot be restricted.
空のタイプを制限することはできません。
Not applicable.
適用できません。
Not applicable.
適用できません。
The following leaf
次葉
leaf enable-qos { type empty; }
リーフ有効-QOS {タイプ空。 }
will be encoded as
エンコードされます
<enable-qos/>
<有効-QOS />
if it exists.
それが存在する場合。
The union built-in type represents a value that corresponds to one of its member types.
内蔵型組合は、そのメンバーの種類のいずれかに対応する値を表しています。
When the type is "union", the "type" statement (Section 7.4) MUST be present. It is used to repeatedly specify each member type of the union. It takes as an argument a string that is the name of a member type.
タイプが「労働組合」である場合には、「タイプ」の文（7.4節）が存在しなければなりません。これを繰り返し組合の各メンバーの種類を指定するために使用されます。これは、引数としてメンバ型の名前である文字列を取ります。
A member type can be of any built-in or derived type, except it MUST NOT be one of the built-in types "empty" or "leafref".
それは組み込み型「空」又は「leafref」のいずれかであるはずがありません以外メンバー型は、任意の組み込みまたは派生タイプのものとすることができます。
When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the "type" statement, until a match is found.
組合のデータ型を表す文字列が検証されると、文字列が一致するものが見つかるまで、「タイプ」文で指定された順に、各メンバーのタイプに対して検証されます。
Any default value or "units" property defined in the member types is not inherited by the union type.
メンバーの種類で定義されたデフォルト値または「単位」プロパティは、労働組合の種類によって継承されていません。
Example:
例：
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
A union cannot be restricted. However, each member type can be restricted, based on the rules defined in Section 9.
労働組合は、制限することはできません。しかし、各メンバーの種類は、セクション9で定義された規則に基づいて、制限することができます。
The lexical representation of a union is a value that corresponds to the representation of any one of the member types.
組合の字句表現は、部材の種類のいずれかの表現に対応する値です。
The canonical form of a union value is the same as the canonical form of the member type of the value.
組合値の標準形式は、値のメンバー型の正規の形式と同じです。
The instance-identifier built-in type is used to uniquely identify a particular instance node in the data tree.
内蔵型インスタンス識別子は、一意のデータ・ツリー内の特定のインスタンスのノードを識別するために使用されます。
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.
インスタンス識別子の構文は正式にそれを一意のデータツリー内のノードを識別するために使用される部12にルール「インスタンス識別子」によって定義されたXPath省略構文のサブセットです。述語のみリストエントリ、リーフリストエントリの値、またはキーなしのリストのための位置インデックスのキーのノードの値を指定するために使用されます。キーを使用してリスト項目を識別するため、各述語は、キーごとに等価のテストで構成され、各キーは、対応する述語を持たなければなりません。
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.
インスタンス識別子タイプの葉は、構成データを表し、そして「必要インスタンスを」プロパティ（セクション9.13.2）が「真」である場合、それが指すノードは、構成を表現しなければなりません。このような葉は、有効なデータに制約を置きます。このようなすべてのリーフノードは、データが有効であるために（セクション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.
Oコンテキストノードがアクセス可能ツリーのルートノードがあります。
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.
この葉は、コンフィギュレーションデータを表す場合、O、ツリーがリーフが存在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.
Oそれ以外の場合は、ツリーには、デバイス上のすべての状態データ、および<ランニング/>データストアです。 XPathのルートノードを子としてすべてのモジュール内のすべてのトップレベル・データ・ノードを有します。
An instance-identifier can be restricted with the "require-instance" statement (Section 9.13.2).
インスタンス識別子は、「必要-インスタンスを」文（セクション9.13.2）で制限することができます。
The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "instance-identifier". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true".
タイプが「インスタンス識別子」であれば「タイプ」の文にサブステートメントである「必要-インスタンスを」文は、存在することができます。これは、引数として文字列を取り、「true」または「false」。この文は、デフォルト値「真」に存在しない場合。
If "require-instance" is "true", it means that the instance being referred MUST exist for the data to be valid. This constraint is enforced according to the rules in Section 8.
「必要-インスタンスは、」「真」であれば、それはインスタンスが参照されることを意味したデータが有効であるために存在しなければなりません。この制約は、第8章の規則に従って実施されます。
If "require-instance" is "false", it means that the instance being referred MAY exist in valid data.
「必要-インスタンスは、」「偽」である場合、それは言及されているインスタンスが有効なデータで存在し得ることを意味します。
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.
符号化に使用される任意の接頭辞は、各インスタンスのエンコーディングに対してローカルです。これは、同じインスタンス識別子は、異なる実装によって異なって符号化することができることを意味します。
Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form.
字句形式は、値が発生するXMLコンテキストに依存するため、このタイプの標準形を有していません。
The following are examples of instance identifiers:
以下は、インスタンス識別子の例です：
/* instance-identifier for a container */
/ex:system/ex:services/ex:ssh
/* instance-identifier for a leaf */
/ex:system/ex:services/ex:ssh/ex:port
/* instance-identifier for a list entry */
/ex:system/ex:user[ex:name='fred']
/* instance-identifier for a leaf in a list entry */
/ex:system/ex:user[ex:name='fred']/ex:type
/* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3]
As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
経験がモジュールで獲得されるので、そのモジュールを改訂することが望ましい場合があります。彼らは元の仕様と、更新の仕様を使用してサーバを使用して、クライアント間の相互運用性の問題を引き起こすあらゆる可能性を持っている場合は、変更が許可されていません。
For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. If there are no existing "revision" statements, then one MUST be added to identify the new revision. Furthermore, any necessary changes MUST be applied to any meta-data statements, including the "organization" and "contact" statements (Sections 7.1.7, 7.1.8).
任意の公表の変更については、新たに「改正」の文（セクション7.1.9）は、既存の「改正」の文の前に含めなければなりません。既存の「改正」の文が存在しない場合には、一つは新しいリビジョンを識別するために加えなければなりません。また、必要な変更は、「組織」と「接触」文（セクション7.1.7、7.1.8）を含む、任意のメタデータ・ステートメントに適用されなければなりません。
Note that definitions contained in a module are available to be imported by any other module, and are referenced in "import" statements via the module name. Thus, a module name MUST NOT be changed. Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are qualified by the namespace.
モジュールに含まれる定義は、他のモジュールによってインポートされるために利用可能であり、モジュール名を経由して「インポート」ステートメントで参照されていることに注意してください。このように、モジュール名を変更してはいけません。すべてのXML要素が名前空間で修飾されているので、「名前空間」の文では、変更してはいけません。
Obsolete definitions MUST NOT be removed from modules since their identifiers may still be referenced by other modules.
その識別子は、まだ他のモジュールによって参照することができるので、廃止された定義は、モジュールから削除されてはなりません。
A definition may be revised in any of the following ways:
定義は、以下のいずれかの方法で変更することがあります。
o An "enumeration" type may have new enums added, provided the old enums's values do not change.
Oアン「列挙」タイプは、新しい列挙型が古い列挙型の値が変更されません提供、追加があります。
o A "bits" type may have new bits added, provided the old bit positions do not change.
O「ビット」タイプが持っている可能性のある新しいビットは、追加の古いビット位置は変更されません提供しました。
o A "range", "length", or "pattern" statement may expand the allowed value space.
○「レンジ」、「長さ」、または「パターン」の文は、許容値の空間を拡張することができます。
o A "default" statement may be added to a leaf that does not have a default value (either directly or indirectly through its type).
O「デフォルト」の文は、（直接または間接的にそのタイプを介して）デフォルト値を持たない葉に添加してもよいです。
o A "units" statement may be added.
O「単位」の文を追加してもよいです。
o A "reference" statement may be added or updated.
O「参照」ステートメントが追加または更新することができます。
o A "must" statement may be removed or its constraint relaxed.
O文は削除してもよいし、その制約を緩和「しなければなりません」。
o A "mandatory" statement may be removed or changed from "true" to "false".
O「必須」文を削除または「false」を「true」に変更することができます。
o A "min-elements" statement may be removed, or changed to require fewer elements.
O「MIN-要素」ステートメントを除去し、又はより少ない要素を必要とするように変更することができます。
o A "max-elements" statement may be removed, or changed to allow more elements.
o「の最大要素」文を削除、または複数の要素を許可するように変更することができます。
o A "description" statement may be added or clarified without changing the semantics of the definition.
O「説明」の文は、定義の意味を変更することなく、追加または明確化することができます。
o New typedefs, groupings, rpcs, notifications, extensions, features, and identities may be added.
O新しいtypedefは、グループ化、RPCを、通知、拡張、機能、およびアイデンティティを添加してもよいです。
o New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature).
O新しいデータ定義文は、彼らが既存のノードへのモジュールまたはサブモジュールのトップレベルで必須のノード（3.1節）を追加、または彼らはすなわち新機能（上の条件付きで依存している場合は、「あれば持っていない場合は追加してもよいです新しい機能を指し-feature」文）。
o A new "case" statement may be added.
O新しい「ケース」の文を追加してもよいです。
o A node that represented state data may be changed to represent configuration, provided it is not mandatory (Section 3.1).
O状態のデータ構成を表すように変更されてもよい表されるノードが、それは必須ではない（セクション3.1）を得ました。
o An "if-feature" statement may be removed, provided its node is not mandatory (Section 3.1).
O「IF-機能」ステートメントを除去することができる、そのノードは必須ではない（セクション3.1）を得ました。
o A "status" statement may be added, or changed from "current" to "deprecated" or "obsolete", or from "deprecated" to "obsolete".
O「状態」ステートメントを追加、または「非推奨」から「現在」または「廃止」から、または「廃止」と「非推奨」から変更することができます。
o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change.
O「タイプ」の文は、型の構文や意味を変更しない別の「タイプ」の文に置き換えてもよいです。例えば、インラインタイプ定義はtypedefで置き換えてもよいが、INT8タイプは構文が変化するため、INT16で置き換えることができません。
o Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs.
Oデータ定義ノードの任意のセットは、構文的および意味的に等価なノードの別のセットに置き換えてもよいです。例えば、葉のセットは、同じリーフとグルーピングの使用によって置き換えられてもよいです。
o A module may be split into a set of submodules, or a submodule may be removed, provided the definitions in the module do not change in any other way than allowed here.
Oモジュールは、サブモジュールの集合に分割することができる、またはサブモジュールを除去することができる、ここで許可さよりもモジュール内の定義は、他の方法で変化しない提供。
o The "prefix" statement may be changed, provided all local uses of the prefix also are changed.
O「接頭辞」の文は、接頭辞のすべてのローカルの使用も変更されて、変更することができます。
Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier.
以前の定義のセマンティクスが変更された場合（非編集上の変更は、特に上記許可以外の任意の定義がなされた場合、すなわち、）そうでなければ、これは新しい識別子と新しい定義によって達成されなければなりません。
In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered.
サブステートメントとして任意のデータ定義文を持っている文では、これらのデータ定義のサブステートメントは、並べ替えてはなりません。
A YANG module can be translated into an alternative XML-based syntax called YIN. The translated module is called a YIN module. This section describes symmetric mapping rules between the two formats.
YANGモジュールはYINと呼ばれる代替XMLベースの構文に変換することができます。翻訳されたモジュールは、YINモジュールと呼ばれています。このセクションでは、2つのフォーマット間の対称マッピングルールを記述する。
The YANG and YIN formats contain equivalent information using different notations. The YIN notation enables developers to represent YANG data models in XML and therefore use the rich set of XML-based tools for data filtering and validation, automated generation of code and documentation, and other tasks. Tools like XSLT or XML validators can be utilized.
YANGとYINフォーマットが異なる表記を使用して同等の情報が含まれています。 YIN表記はXMLでYANGデータモデルを表すため、データフィルタリングおよび検証のためのXMLベースのツールの豊富なセット、コードとドキュメントの自動生成、および他のタスクを使用するために開発を可能にします。 XSLTまたはXMLバリデータのようなツールを利用することができます。
The mapping between YANG and YIN does not modify the information content of the model. Comments and whitespace are not preserved.
陰と陽の間のマッピングは、モデルの情報内容は変更されません。コメントと空白は保持されません。
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 "：IETF：のparams：XML：NS：陽：陰：1 URN" である名前空間に属します。
YIN elements corresponding to extension keywords belong to the namespace of the YANG module where the extension keyword is declared via the "extension" statement.
拡張キーワードに対応するYIN要素は、拡張キーワードが「拡張子」の文で宣言されYANGモジュールの名前空間に属します。
The names of all YIN elements MUST be properly qualified with their namespaces specified above using the standard mechanisms of [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes.
全てYIN要素の名前は、[XML-NAMES]の標準メカニズムを使用して、上記指定されたそれらの名前空間と適切に修飾する必要があり、すなわち、「のxmlns」と「のxmlns：XXX」属性。
The argument of a YANG statement is represented in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the mapping for the set of YANG keywords. For extensions, the argument mapping is specified within the "extension" statement (see Section 7.17). The following rules hold for arguments:
YANG文の引数は、YINのいずれかでXML属性またはキーワード要素のサブ要素として表現されます。表1は、YANGキーワードのセットのマッピングを定義します。拡張機能の場合、引数のマッピングは、「拡張子」ステートメント内に指定されます（セクション7.17を参照してください）。次の規則は、引数のために保持します：
o If the argument is represented as an attribute, this attribute has no namespace.
引数は属性として表現されている場合は、O、この属性には、名前空間を持っていません。
o If the argument is represented as an element, it is qualified by the same namespace as its parent keyword element.
引数が要素として表現されている場合は、O、それはその親キーワード要素と同じ名前空間で修飾されます。
o If the argument is represented as an element, it MUST be the first child of the keyword element.
引数が要素として表現されている場合は、O、それはキーワード要素の最初の子でなければなりません。
Substatements of a YANG statement are represented as (additional) children of the keyword element and their relative order MUST be the same as the order of substatements in YANG.
YANG文のサブステートメントは、キーワード要素の（追加の）子どもとの相対的な順序YANGにおけるサブステートメントの順序と同じでなければならないとして表現されています。
Comments in YANG MAY be mapped to XML comments.
YANG内のコメントは、XMLコメントにマッピングされてもよいです。
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 |
| pattern | value | false |
| position | value | false |
| prefix | value | false |
| presence | value | false |
| range | value | false |
| reference | text | true |
| refine | target-node | false |
| require-instance | value | false |
| revision | date | false |
| revision-date | date | false |
| rpc | name | false |
| status | value | false |
| submodule | name | false |
| type | name | false |
| typedef | name | false |
| unique | tag | false |
| units | name | false |
| uses | name | false |
| value | value | false |
| when | condition | false |
| yang-version | value | false |
| yin-element | value | false |
+------------------+---------------+-------------+
Table 1
表1
The following YANG module:
次YANGモジュール：
module acme-foo {
namespace "http://acme.example.com/foo";
prefix "acfoo";
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-定義」は、セクション7.17.3に定義されている場合、次のYINに翻訳されます。
<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">
<モジュール名= "ACME-FOO" のxmlns = "URN：IETF：paramsは：XML：NS：陽：陰：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"/>
<名前空間URI = "http://acme.example.com/foo" /> <プレフィックス値= "acfoo" />
<import module="my-extensions"> <prefix value="myext"/> </import>
<インポートモジュール= "私の-拡張子"> <プレフィックス値= "MYEXT" /> </インポート>
<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>
<リスト名= "インターフェース"> <キーの値= "名前" /> <葉名= "名前"> <型名= "文字列" /> </葉> <葉名= "MTU"> <タイプ名= "UINT32" /> <説明> <テキスト>インターフェースのMTU </テキスト> </記述> <MYEXT：C-定義名= "MY_MTU" /> </リーフ> </リスト> </モジュール>
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"
<CODEが始まる>ファイル "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
モジュールSTMT = optsepモジュールキーワード9月識別子のarg-STR optsep "{" stmtsepモジュールヘッダSTMTS連携STMTSメタSTMTSリビジョンSTMTS体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
サブモジュール-STMT = optsepサブモジュールキーワード9月識別子のarg-STR optsep "{" stmtsepサブモジュール・ヘッダSTMTS連携STMTSメタSTMTSリビジョンSTMTS体STMTS "}" optsep
module-header-stmts = ;; these stmts can appear in any order [yang-version-stmt stmtsep] namespace-stmt stmtsep prefix-stmt stmtsep
モジュールヘッダSTMTS = ;;これらSTMTSは任意の順序で表示されます[ヤン・バージョンのstmtのstmtsep]名前空間のstmt stmtsepプレフィックスのstmtのstmtsep
submodule-header-stmts = ;; these stmts can appear in any order [yang-version-stmt stmtsep] belongs-to-stmt stmtsep
サブモジュール・ヘッダSTMTS = ;;これらSTMTSは、任意の順序[ヤン・バージョンのstmtのstmtsep]に表示されることが属しツーのstmt stmtsep
meta-stmts = ;; these stmts can appear in any order [organization-stmt stmtsep] [contact-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep]
メタSTMTS = ;;これらSTMTSは任意の順番[組織STMTのstmtsep]に表示されることができる[非接触STMTのstmtsep] [説明-STMTのstmtsep] [参照STMT stmtsep]
linkage-stmts = ;; these stmts can appear in any order *(import-stmt stmtsep) *(include-stmt stmtsep)
リンケージSTMTS = ;;これらSTMTSは、任意の順序*（輸入-STMTのstmtsep）に表示されます*（含ま-stmtはstmtsepを）
revision-stmts = *(revision-stmt stmtsep)
改正-STMTS = *（改訂-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)
ボディSTMTS = *（（拡張-STMT /特徴STMT /アイデンティティ-STMT / typedefは、STMT /グルーピング-STMT /データ-DEF-STMT /増強-STMT / RPC-STMT /通知STMT /偏差-STMT）stmtsep ）
data-def-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / choice-stmt / anyxml-stmt / uses-stmt
データ-DEF-のstmt =コンテナのstmt /リーフのstmt /リーフリストのstmt /リストのstmt /選択-のstmt / AnyXMLで-のstmt /は使用しています-のstmtを
yang-version-stmt = yang-version-keyword sep yang-version-arg-str optsep stmtend
これは、バージョン間STMT =キーワードSEP--バージョンのArg-STR optsep stmtend
yang-version-arg-str = < a string that matches the rule yang-version-arg >
ヤン・バージョンのarg-STR = <ルールに一致する文字列ヤン・バージョン、引数>
yang-version-arg = "1"
どのバージョン、引数=「1」
import-stmt = import-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep [revision-date-stmt stmtsep] "}"
インポートSTMT =インポートキーワード9月識別子のarg-STR optsep "{" stmtsepプレフィックスSTMTのstmtsep [改訂日付STMTのstmtsep] "}"
include-stmt = include-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [revision-date-stmt stmtsep] "}")
包含STMT =含むキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep [改訂日付STMTのstmtsep] "}"）
namespace-stmt = namespace-keyword sep uri-str optsep stmtend
名前空間のstmt =名前空間キーワード9月のURI-STR optsep stmtend
uri-str = < a string that matches the rule URI in RFC 3986 >
URI-STR = <RFC 3986でルールURIに一致する文字列>
prefix-stmt = prefix-keyword sep prefix-arg-str optsep stmtend
プレフィックスのstmt =プレフィックスキーワード9月接頭引数-STR optsep stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep "}"
所属ツーSTMT =属するツーキーワード9月識別子のarg-STR optsep "{" stmtsepプレフィックスSTMTのstmtsep "}"
organization-stmt = organization-keyword sep string optsep stmtend
組織のstmt =組織-キーワード9月の文字列optsepのstmtend
contact-stmt = contact-keyword sep string optsep stmtend
非接触型のstmt =接触キーワード9月の文字列optsepのstmtend
description-stmt = description-keyword sep string optsep stmtend
説明-のstmt =説明、キーワード9月の文字列optsepのstmtend
reference-stmt = reference-keyword sep string optsep stmtend
参照のstmt =参照-キーワード9月の文字列optsepのstmtend
units-stmt = units-keyword sep string optsep stmtend
単位-のstmt =単位-キーワード9月の文字列optsepのstmtend
revision-stmt = revision-keyword sep revision-date optsep (";" / "{" stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] "}")
リビジョンSTMT =リビジョンキーワード9月改訂日付optsep（ ";" / "{" stmtsep [記述-STMTのstmtsep] [参照STMTのstmtsep] "}"）
revision-date = date-arg-str
改訂日付=日付-argを-STR
revision-date-stmt = revision-date-keyword sep revision-date stmtend extension-stmt = extension-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [argument-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}")
改訂日付STMT =改訂日付、キーワード9月改訂日付stmtend延長-STMT =拡張キーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[引数-stmt stmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep] "}"）
argument-stmt = argument-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [yin-element-stmt stmtsep] "}")
引数STMT =引数キーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep [陰元素STMTのstmtsep] "}"）
yin-element-stmt = yin-element-keyword sep yin-element-arg-str stmtend
陰-要素のstmt =陰-要素キーワード9月陰-要素、引数-STRのstmtend
yin-element-arg-str = < a string that matches the rule yin-element-arg >
陰元素のarg-STR = <ルール陰元素引数と一致する文字列>
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] "}")
アイデンティティSTMT =アイデンティティキーワード9月識別子のarg-STRのoptsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[ベースSTMTのstmtsep]に表示されることができる[ステータスSTMTのstmtsep] [説明-STMT stmtsep] [参照STMT stmtsep] "}"）
base-stmt = base-keyword sep identifier-ref-arg-str optsep stmtend
ベースSTMT =ベースキーワード9月識別子-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] "}")
特徴STMT =機能キーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTSは、任意の順序*（IF-特徴STMTのstmtsep）ステータスSTMTのstmtsep〕〔の説明 - で表示されることSTMT stmtsep] [参照STMTのstmtsep] "}"）
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str optsep stmtend
IF-機能-のstmt = IF-機能・キーワード9月の識別子-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] "}"
typedefの-STMT = typedefのキーワード9月識別子のarg-STR optsep "{" stmtsep ;;これらSTMTSは、任意の順序タイプSTMTのstmtsepに表示できる[単位-STMTのstmtsep] [デフォルト-STMTのstmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep] "}"
type-stmt = type-keyword sep identifier-ref-arg-str optsep (";" / "{" stmtsep type-body-stmts "}")
タイプSTMT =タイプキーワード9月識別子-REF-のarg-STR optsep（ ";" / "{" stmtsep型ボディ-STMTS "}"）
type-body-stmts = numerical-restrictions / decimal64-specification / string-restrictions / enum-specification / leafref-specification / identityref-specification / instance-identifier-specification / bits-specification / union-specification
型ボディSTMTS =数値、制限/ decimal64仕様/文字列の制限/列挙仕様/ leafref仕様/ identityref仕様/インスタンス識別子仕様/ビット仕様/共用仕様
numerical-restrictions = range-stmt stmtsep
数値-制約=レンジ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] "}")
範囲-STMT =レンジキーワード09月範囲、引数-STR optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[エラーメッセージSTMTのstmtsep] [エラーAPP-タグSTMT stmtsep] [説明-STMT stmtsep] [参照STMTのstmtsep] "}"）
decimal64-specification = fraction-digits-stmt
decimal64仕様=小数桁-のstmt
fraction-digits-stmt = fraction-digits-keyword sep fraction-digits-arg-str stmtend
小数桁-のstmt =小数桁キーワード9月小数桁-argを-STR stmtend
fraction-digits-arg-str = < a string that matches the rule fraction-digits-arg >
小数桁-argを-STR = <ルールの一致する文字列端数桁を、引数>
fraction-digits-arg = ("1" ["0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8"]) / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
小数桁、引数=（ "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)
文字列の制限= ;;これらSTMTSは、任意の順序[長さSTMT stmtsep] *（パターン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] "}")
長STMT =長キーワード9月長さのarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[エラーメッセージSTMTのstmtsep] [エラーAPP-タグSTMTのstmtsep] [説明-STMT stmtsep] [参照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] "}")
パターンSTMT =パターンキーワード9月列optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[エラーメッセージSTMTのstmtsep] [エラーAPP-タグSTMTのstmtsep] [説明-STMT stmtsep] [参照STMTのstmtsep] "}"）
default-stmt = default-keyword sep string stmtend
デフォルト-のstmt =デフォルト・キーワード9月の文字列stmtend
enum-specification = 1*(enum-stmt stmtsep)
列挙仕様= 1 *（列挙-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] "}")
列挙-STMT =列挙キーワード9月列optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[値-STMTのstmtsep]に表示されることができる[ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMT stmtsep] "}"）
leafref-specification = ;; these stmts can appear in any order path-stmt stmtsep [require-instance-stmt stmtsep]
leafref仕様= ;;これらSTMTSは、任意の順序のパスSTMTのstmtsepに表示できる[stmtsepインスタンス-STMTの必要】
path-stmt = path-keyword sep path-arg-str stmtend
パスのstmt =パス・キーワード9月パス、引数-STRのstmtend
require-instance-stmt = require-instance-keyword sep require-instance-arg-str stmtend
stmtend-インスタンスのarg-STRの必要SEP必要-インスタンスのstmt =必要-インスタンスのキーワード
require-instance-arg-str = < a string that matches the rule require-instance-arg >
必要-インスタンス引数-STR = <ルールに一致する文字列が必要とするインスタンスを、引数>
require-instance-arg = true-keyword / false-keyword
必要-インスタンスのarg =真のキーワード/偽のキーワード
instance-identifier-specification = [require-instance-stmt stmtsep]
インスタンス識別子仕様= [必要-インスタンスSTMTのstmtsep]
identityref-specification = base-stmt stmtsep
identityref仕様=ベースSTMTのstmtsep
union-specification = 1*(type-stmt stmtsep)
組合仕様= 1 *（タイプSTMT stmtsep）
bits-specification = 1*(bit-stmt stmtsep)
ビット仕様= 1 *（ビット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] "}" "}")
ビットSTMT =ビットキーワード9月識別子のarg-STRのoptsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[位置STMTのstmtsep]に表示されることができる[ステータスSTMTのstmtsep] [説明-STMT stmtsep] [参照STMT stmtsep] "}" "}"）
position-stmt = position-keyword sep position-value-arg-str stmtend
位置のstmt =位置-キーワード9月位置値、引数-STRのstmtend
position-value-arg-str = < a string that matches the rule position-value-arg >
位置値は、引数-STR = <ルール位置値、引数と一致する文字列>
position-value-arg = non-negative-integer-value
位置値は、引数=非負整数値
status-stmt = status-keyword sep status-arg-str stmtend status-arg-str = < a string that matches the rule status-arg >
ステータスのstmt =ステータスキーワード9月の状態、引数-STR stmtend状況、引数-STR = <ルールの状態、引数にマッチした文字列>
status-arg = current-keyword / obsolete-keyword / deprecated-keyword
状態、引数=現在のキーワード/時代遅れ-キーワード/非推奨のキーワード
config-stmt = config-keyword sep config-arg-str stmtend
コンフィグ-のstmt = configのキーワード9月コンフィグ-argを-STR stmtend
config-arg-str = < a string that matches the rule config-arg >
コンフィグ-argを-STR = <ルールの設定、引数にマッチした文字列>
config-arg = true-keyword / false-keyword
設定、引数=真のキーワード/偽のキーワード
mandatory-stmt = mandatory-keyword sep mandatory-arg-str stmtend
必須-のstmt =必須キーワード9月必須-argを-STR stmtend
mandatory-arg-str = < a string that matches the rule mandatory-arg >
必須-argを-STR = <ルールに一致する文字列必須、引数>
mandatory-arg = true-keyword / false-keyword
必須、引数=真のキーワード/偽のキーワード
presence-stmt = presence-keyword sep string stmtend
プレゼンスのstmt =存在キーワード9月の文字列stmtend
ordered-by-stmt = ordered-by-keyword sep ordered-by-arg-str stmtend
注文したバイのstmt =注文・バイ・キーワード9月命じ-により、引数-STR stmtend
ordered-by-arg-str = < a string that matches the rule ordered-by-arg >
注文ごとの引数-STR = <命じ-により、引数のルールにマッチした文字列>
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] "}")
マストSTMT =マストキーワード9月列optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[エラーメッセージSTMTのstmtsep] [エラーAPP-タグSTMTのstmtsep] [説明-STMT stmtsep] [参照STMTのstmtsep] "}"）
error-message-stmt = error-message-keyword sep string stmtend
エラー・メッセージのstmt =エラー・メッセージ・キーワード9月の文字列stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend min-elements-stmt = min-elements-keyword sep min-value-arg-str stmtend
= MIN-要素キーワード9月最小値、引数-STR stmtend要素-STMT分エラーアプリTAG-STMT =エラーアプリタグキーワード9月列stmtend
min-value-arg-str = < a string that matches the rule min-value-arg >
最小値は、引数-STR = <最小値、引数ルールに一致する文字列>
min-value-arg = non-negative-integer-value
最小値は、引数=非負整数値
max-elements-stmt = max-elements-keyword sep max-value-arg-str stmtend
MAX-要素-のstmt = MAX-要素キーワード9月の最大値、引数-STR stmtend
max-value-arg-str = < a string that matches the rule max-value-arg >
最大値、引数-STR = <ルールの最大値、引数に一致する文字列>
max-value-arg = unbounded-keyword / positive-integer-value
最大値、引数=無制限のキーワード/正の整数値
value-stmt = value-keyword sep integer-value stmtend
値-STMT =値キーワード9月整数値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) "}")
グルーピング-STMT =グルーピングキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[ステータス-STMTのstmtsep] [説明-STMTのstmtsep]に表示されることができる[参照STMTのstmtsep] *（（のtypedef-STMT /グルーピング-STMT）stmtsep）*（データ-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) "}")
コンテナSTMT =コンテナキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）*（必須-stmt stmtsep）プレゼンスSTMTのstmtsep] [CONFIG-STMTのstmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep] *（（のtypedef-STMT /グルーピング-STMT）stmtsep）*（データ-def-STMT stmtsep） "}"）
leaf-stmt = leaf-keyword sep identifier-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) type-stmt stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}"
リーフSTMT =リーフキーワード9月識別子のarg-STR optsep "{" stmtsep ;;これらSTMTSは、*は任意の順序[とき-のstmt stmtsep]に表示されます（IF-機能-のstmt stmtsep）を入力-のstmtのstmtsep [単位-のstmtのstmtsep] *（必要-STMTのstmtsep）[デフォルト-のstmtのstmtsep] [設定-のstmtのstmtsep ] [必須-STMTのstmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照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] "}"
リーフリストSTMT =リーフリストキーワード9月識別子のarg-STR optsep "{" stmtsep ;;これらSTMTSは、MIN-elements- [TYPE-STMTをstmtsep [単位-STMTのstmtsep] *（マストSTMTのstmtsep）[CONFIG-STMTのstmtsep]任意の順番[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）に表示されることがSTMT stmtsep] [MAX-要素-STMTのstmtsep] [順序付けバイSTMT stmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照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]
リストSTMT =リストキーワード9月識別子のarg-STR optsep "{" stmtsep ;;これらSTMTSは、任意の順序で表示されます[とき-のstmtのstmtsep] *（IF-機能-のstmt stmtsep）*（必要-STMTのstmtsep）[キーのstmtのstmtsep] *（ユニーク-STMTのstmtsep）[設定-のstmtのstmtsep] [分-elements-STMTのstmtsep] [MAX-要素-STMTのstmtsep] [順序付けバイSTMT stmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"
key-stmt = key-keyword sep key-arg-str stmtend
キーのstmt =キーのキーワード9月キーのarg-STR stmtend
key-arg-str = < a string that matches the rule key-arg >
キーのarg-STR = <ルールに一致する文字列のキーのarg>
key-arg = node-identifier *(sep node-identifier)
キー引数=ノード識別子*（SEPノード識別子）
unique-stmt = unique-keyword sep unique-arg-str stmtend
ユニーク-のstmt =ユニークなキーワード9月のユニークな-argを-STR stmtend
unique-arg-str = < a string that matches the rule unique-arg >
ユニーク-argを-STR = <ルールに一致する文字列のユニークな、引数>
unique-arg = descendant-schema-nodeid *(sep descendant-schema-nodeid)
一意のarg =子孫-スキーマNODEIDの*（SEP子孫-スキーマ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) "}")
選択-STMT =選択キーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）に表示されることができます[default- STMT stmtsep] [CONFIG-STMTのstmtsep] [必須-STMTのstmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep] *（（短ケースSTMT /ケースSTMT）stmtsep）「} 「）
short-case-stmt = container-stmt / leaf-stmt / leaf-list-stmt / list-stmt / anyxml-stmt
短ケースSTMT =コンテナSTMT /リーフSTMT /リーフリストSTMT /リスト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]
ケースSTMT =ケースキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）に表示されることができる[ステータス - stmtはstmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(data-def-stmt stmtsep)
"}")
anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) *(must-stmt stmtsep) [config-stmt stmtsep] [mandatory-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}")
AnyXMLで-STMT = AnyXMLでキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）に表示されることができる*（必須-stmt stmtsep）CONFIG-STMTのstmtsep] [必須-STMTのstmtsep] [ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照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) "}")
使用-STMT =使用キーワード9月識別子-REF-のarg-STR optsep（ ";" / "{" stmtsepは;;これらSTMTSは、[任意の順番[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）に表示されることがステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMTのstmtsep] *（絞り込み-STMT stmtsepを）*（stmtsep-増強-STMTの使用） "}"）
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) "}")
絞り込み-STMT =絞り込みキーワード絞り込み、引数-STR SEP optsep（ ";" / "{" stmtsep（リファイン・コンテナSTMTS /絞り込み-リーフSTMTS /絞り込み-リーフリストSTMTSを/絞り込みリスト-STMTS / ） "}" /リファインケース-STMTS /絞り込み-AnyXMLで-STMTS）の選択肢-STMTSを絞り込みます
refine-arg-str = < a string that matches the rule refine-arg >
洗練-argを-STR = <ルール絞り込み、引数にマッチした文字列>
refine-arg = descendant-schema-nodeid refine-container-stmts = ;; these stmts can appear in any order *(must-stmt stmtsep) [presence-stmt stmtsep] [config-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep]
絞り込み、引数=子孫-スキーマNODEID絞り込み-コンテナSTMTS = ;;これらSTMTSは（必要-STMTのstmtsep）プレゼンスSTMTのstmtsep] [CONFIG-STMTのstmtsep] [説明-STMTのstmtsep] [参照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]
洗練葉-STMTS = ;;これらSTMTSは、任意の順序*に現れることができる（マストSTMTのstmtsep）[デフォルト-STMTのstmtsep] [CONFIG-STMTのstmtsep] [必須-STMTのstmtsep] [説明-STMTのstmtsep] [参照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]
洗練葉-リストSTMTS = ;;これらSTMTSは、任意の順序*に現れることができる（マストSTMTのstmtsep）[CONFIG-STMTのstmtsep] [MIN-要素-STMTのstmtsep] [MAX-要素-STMTのstmtsep] [説明-STMTのstmtsep] [参照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]
洗練リスト-STMTS = ;;これらSTMTSは、任意の順序*に現れることができる（マストSTMTのstmtsep）[CONFIG-STMTのstmtsep] [MIN-要素-STMTのstmtsep] [MAX-要素-STMTのstmtsep] [説明-STMTのstmtsep] [参照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]
洗練-選択-STMTS = ;;これらSTMTSは、任意の順序で現れることができる[デフォルト-STMTのstmtsep] [CONFIG-STMTのstmtsep] [必須-STMTのstmtsep] [説明-STMTのstmtsep] [参照STMT stmtsep]
refine-case-stmts = ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep]
洗練ケース-STMTS = ;;これらSTMTS任意の順序【説明-STMTのstmtsep]に表示されることができる[参照STMT stmtsep]
refine-anyxml-stmts = ;; these stmts can appear in any order *(must-stmt stmtsep) [config-stmt stmtsep]
洗練-AnyXMLで-STMTS = ;;これらSTMTSは、任意の順序の*に表示されます（必要-STMTのstmtsep）[設定-のstmtのstmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] 1*((data-def-stmt stmtsep) / (case-stmt stmtsep)) "}"
使用-増強-STMT = 9月キーワードが増強-使用-増強、引数-STR optsep "{" stmtsep ;;これらSTMTSは、任意の順序[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMT stmtsep] 1 *（（データ-DEF-STMTのstmtsepに表示できます）/（ケースSTMTのstmtsep）） "}"
uses-augment-arg-str = < a string that matches the rule uses-augment-arg >
使用しています-オーグメント-argを-STR = <ルールに一致した文字列は、オーグメントを使用して、引数>
uses-augment-arg = descendant-schema-nodeid
使用-増強、引数=子孫-スキーマ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)) "}"
増強-STMT =増強キーワード増強、引数-STR SEP optsepを "{" stmtsep ;;これらSTMTSは、任意の順序[-STMTのstmtsep] *（IF-特徴STMTのstmtsep）ステータスSTMTのstmtsep] [説明-STMTのstmtsep] [参照STMT stmtsep] 1 *（（データ-DEF-STMTのstmtsepに表示できます）/（ケースSTMTのstmtsep）） "}"
augment-arg-str = < a string that matches the rule augment-arg >
増補、引数-STR = <ルールオーグメント、引数にマッチした文字列>
augment-arg = absolute-schema-nodeid
増強、引数=絶対スキーマNODEID
unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement2 "}")
未知文=接頭辞 "：" 識別子[9月ストリング] optsep（ ";" / "{" *未知文2 "}"）
unknown-statement2 = [prefix ":"] identifier [sep string] optsep (";" / "{" *unknown-statement2 "}")
未知文2 = [接頭辞 "："]識別子[9月ストリング] optsep（ ";" / "{" *未知文2 "}"）
when-stmt = when-keyword sep string optsep (";" / "{" stmtsep ;; these stmts can appear in any order
-STMTは=とき、キーワード9月列optsep（ ";" / "{" stmtsep ;;これらSTMTSは任意の順序で表示することができ
[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] "}")
RPC-STMT = RPCキーワード9月識別子のarg-STR optsep（ ";" / "{" stmtsep ;;これらSTMTS任意の順序*（IF-特徴STMTのstmtsep）ステータスSTMTのstmtsep〕〔の説明 - で表示されることSTMT stmtsep] [参照STMTのstmtsep] *（（のtypedef-STMT /グルーピング-STMT）stmtsep）入力STMTのstmtsep] [出力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) "}"
入力STMT =入力キーワードoptsep "{" stmtsep ;;これらSTMTSは（（のtypedef-STMT /グルーピング-STMT）stmtsep 1）*（データ-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) "}"
出力STMT =出力キーワードoptsep "{" stmtsep ;;これらSTMTSは（（のtypedef-STMT /グルーピング-STMT）stmtsep 1）*（データ-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) "}")
通知STMT =通知キーワード9月識別子のarg-STRのoptsep（ ";" / "{" stmtsep ;;これらSTMTSは（任意の順序*に表示されることができれば、特徴STMT stmtsep）ステータスSTMTのstmtsep] [の説明 - STMT stmtsep] [参照STMTのstmtsep] *（（のtypedef-STMT /グルーピング-STMT）stmtsep）*（データ-DEF-STMTのstmtsep） "}"）
deviation-stmt = deviation-keyword sep deviation-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] (deviate-not-supported-stmt / 1*(deviate-add-stmt / deviate-replace-stmt / deviate-delete-stmt)) "}"
偏差-STMT =偏差キーワード9月偏差のarg-STR optsep "{" stmtsep ;;これらSTMTSは任意の順序で現れることができる[説明-STMTのstmtsep] [参照STMTのstmtsep]（ずれ-サポートされていない-STMT / 1 *（ずれ-アドインSTMT /逸脱-置き換える-STMT /逸脱-DELETE-STMT）） "}"
deviation-arg-str = < a string that matches the rule deviation-arg >
偏差のarg-STR = <ルール偏差引数と一致する文字列>
deviation-arg = absolute-schema-nodeid
偏差引数=絶対スキーマNODEID
deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword optsep (";" / "{" stmtsep "}")
=ずれキーワードSEP-サポートされていないキーワードoptsep（ ";" / "{" stmtsep "}"）、 - サポートされていない-STMTを逸脱
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] "}")
逸脱-アドインSTMT =ずれキーワード追加キーワードSEP optsep（ ";" / "{" stmtsep [単位-STMTのstmtsep] *（マストSTMTのstmtsep）*（一意-STMTのstmtsep）[デフォルト-STMTのstmtsep] [ CONFIG-STMTのstmtsep] [必須-STMTのstmtsep] [MIN-要素-STMTのstmtsep] [MAX-要素-STMTのstmtsep] "}"）
deviate-delete-stmt = deviate-keyword sep delete-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}")
逸脱-DELETE-STMT =ずれキーワード削除キーワードSEP optsep（ ";" / "{" stmtsep [単位-STMTのstmtsep] *（マストSTMTのstmtsep）*（一意-STMTのstmtsep）[デフォルト-STMTのstmtsep] " } "）
deviate-replace-stmt = deviate-keyword sep replace-keyword optsep (";" / "{" stmtsep [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}")
逸脱-交換-STMT =ずれキーワード置き換えるキーワードSEP optsep（ ";" / "{" stmtsep [タイプSTMTのstmtsep] [単位-STMTのstmtsep] [デフォルト-STMTのstmtsep] [CONFIG-STMTのstmtsep] [mandatory- STMT stmtsep] [MIN-要素-STMTのstmtsep] [MAX-要素-STMTのstmtsep] "}"）
;; Ranges
;;レンジ
range-arg-str = < a string that matches the rule range-arg >
レンジのarg-STR = <ルール範囲、引数と一致する文字列>
range-arg = range-part *(optsep "|" optsep range-part)
範囲、引数=レンジパート*（optsep「|」optsep範囲の部分）
range-part = range-boundary [optsep ".." optsep range-boundary]
範囲の部分=範囲境界[optsep「..」optsep範囲境界]
range-boundary = min-keyword / max-keyword / integer-value / decimal-value
範囲境界=分キーワード/ MAX-キーワード/整数値/ 10進値
;; Lengths
;;長さ
length-arg-str = < a string that matches the rule length-arg >
長さのarg-STR = <ルール長引数と一致する文字列>
length-arg = length-part *(optsep "|" optsep length-part)
長さは、引数=長さの部分から*（optsep「|」optsep長の部分）
length-part = length-boundary [optsep ".." optsep length-boundary]
長さの部分=長境界[optsep「..」optsep長境界]
length-boundary = min-keyword / max-keyword / non-negative-integer-value
長境界=分キーワード/ MAX-キーワード/非負整数値
;; Date
;;日付
date-arg-str = < a string that matches the rule date-arg >
日付引数-STR = <一致する文字列ルールの日付のarg>
date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT
日付引数= 4 DIGIT " - " 2 DIGIT " - " 2 DIGIT
;; Schema Node Identifiers
;;スキーマのノード識別子
schema-nodeid = absolute-schema-nodeid / descendant-schema-nodeid
スキーマNODEID =絶対スキーマNODEID /子孫-スキーマNODEID
absolute-schema-nodeid = 1*("/" node-identifier)
絶対スキーマNODEID = 1 *（「/」ノード識別子）
descendant-schema-nodeid = node-identifier absolute-schema-nodeid
子孫-スキーマNODEID =ノード識別子絶対スキーマNODEID
node-identifier = [prefix ":"] identifier
ノード識別子= [接頭辞「：」]識別子
;; Instance Identifiers
;;インスタンス識別子
instance-identifier = 1*("/" (node-identifier *predicate))
インスタンス識別子= 1 *（ "/"（ノード識別子*述語））
predicate = "[" *WSP (predicate-expr / pos) *WSP "]"
述語= "[" * WSP（述語-exprの/ POS）* WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE))
述語のexpr =（ノード識別子/ ""）* WSP "=" * WSP（（DQUOTE列DQUOTE）/（SQUOTE列SQUOTE））
pos = non-negative-integer-value
POS =非負整数値
;; leafref path
;; leafrefパス
path-arg-str = < a string that matches the rule path-arg >
パスのarg-STR = <ルールパス引数と一致する文字列>
path-arg = absolute-path / relative-path
パス引数=絶対パス/相対パス
absolute-path = 1*("/" (node-identifier *path-predicate))
絶対パス= 1 *（「/」（ノード識別子*パス述語））
relative-path = 1*(".." "/") descendant-path
相対パス= 1 *（ ".." "/"）子孫パス
descendant-path = node-identifier [*path-predicate absolute-path]
子孫パス=ノード識別子[*パス述語絶対パス]
path-predicate = "[" *WSP path-equality-expr *WSP "]"
パス述語= "[" * WSPパス平等-exprのの*のWSP "]"
path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr
パス平等-exprの=ノード識別子* WSP "=" * WSPパス・キー式expr
path-key-expr = current-function-invocation *WSP "/" *WSP rel-path-keyexpr
パス-keyexpr =電流機能の呼び出し* WSP "/" * WSP相対パス-keyexpr
rel-path-keyexpr = 1*(".." *WSP "/" *WSP) *(node-identifier *WSP "/" *WSP) node-identifier
REL-経路keyexpr = 1 *（ ".." * WSP "/" * WSP）*（*ノード識別子WSP "/" * WSP）ノード識別子
;;; Keywords, using abnfgen's syntax for case-sensitive strings
;;;大文字と小文字を区別した文字列のためにabnfgenの構文を使用してキーワード、
;; statement keywords anyxml-keyword = 'anyxml' argument-keyword = 'argument' augment-keyword = 'augment' base-keyword = 'base' belongs-to-keyword = 'belongs-to' bit-keyword = 'bit' case-keyword = 'case' choice-keyword = 'choice' config-keyword = 'config' contact-keyword = 'contact' container-keyword = 'container' default-keyword = 'default' description-keyword = 'description' enum-keyword = 'enum' error-app-tag-keyword = 'error-app-tag' error-message-keyword = 'error-message' extension-keyword = 'extension' deviation-keyword = 'deviation' deviate-keyword = 'deviate' feature-keyword = 'feature' fraction-digits-keyword = 'fraction-digits' grouping-keyword = 'grouping' identity-keyword = 'identity' if-feature-keyword = 'if-feature' import-keyword = 'import' include-keyword = 'include' input-keyword = 'input' key-keyword = 'key' leaf-keyword = 'leaf' leaf-list-keyword = 'leaf-list' length-keyword = 'length' list-keyword = 'list' mandatory-keyword = 'mandatory' max-elements-keyword = 'max-elements' min-elements-keyword = 'min-elements' module-keyword = 'module' must-keyword = 'must' namespace-keyword = 'namespace' notification-keyword= 'notification' ordered-by-keyword = 'ordered-by' organization-keyword= 'organization' output-keyword = 'output' path-keyword = 'path' pattern-keyword = 'pattern' position-keyword = 'position' prefix-keyword = 'prefix' presence-keyword = 'presence' range-keyword = 'range' reference-keyword = 'reference' refine-keyword = 'refine' require-instance-keyword = 'require-instance' revision-keyword = 'revision' revision-date-keyword = 'revision-date' rpc-keyword = 'rpc' status-keyword = 'status' submodule-keyword = 'submodule' type-keyword = 'type' typedef-keyword = 'typedef' unique-keyword = 'unique' units-keyword = 'units' uses-keyword = 'uses' value-keyword = 'value' when-keyword = 'when' yang-version-keyword= 'yang-version' yin-element-keyword = 'yin-element'
;;ステートメントキーワードAnyXMLで、キーワード=「AnyXMLで」引数キーワード=「引数」増補キーワード=「オーグメント」ベース - キーワード=「ベースが」=に-キーワード属する「所属-に」ビットキーワード=「ビット」大文字キーワード= 'ケースチョイス-キーワード=「選択」設定キーワード='設定の連絡先、キーワード=「コンタクト」コンテナのキーワード=「コンテナ」のデフォルトキーワード=「デフォルト」の記述キーワード=「説明」列挙キーワード=「列挙」エラーアプリタグキーワード=「エラーアプリタグ」エラーメッセージキーワード=「エラーメッセージ」拡張キーワード=「拡張」偏差キーワード=「偏差」ずれキーワード=「ずれます『IF-機能-キーワード=『の場合、機能』インポート・キーワード=「インポート『をアイデンティティキーワード=』アイデンティティをグループ化」機能-キーワード=『』機能端数桁キーワード= '小数桁の区切りキーワード=』 「含むキーワード= 『』入力キーワード= 『入力』キーキーワード= 『キー』葉キーワード= 『リーフ』リーフリストキーワード= 『リーフリスト』長キーワード= 『長さ』リストキーワードを含みます= 'list' の必須キーワード= '必須' 最大要素キーワード=「MAX-ELEメント最小要素-キーワード= '分-要素のモジュール、キーワード= 『モジュール』しなければならないキーワード= 『』名前空間キーワードは= 『名前空間』通知-キーワードは= 『通知しなければならない』注文・バイ・キーワード=「ordered- 「組織キーワード= 『組織』出力キーワード= 『出力』パスキーワード= 『パス』パターンキーワード= 『パターン』位置キーワード= 『位置』プレフィックスキーワード= 『プレフィックス』存在キーワード=」存在によって「レンジキーワードは= 『範囲』参照キーワード= 『参照』絞り込みキーワードを= 『絞り込み』必要インスタンスキーワード= 『インスタンスを必要』リビジョンキーワード= 『リビジョン』改訂日付、キーワード=」改訂日付「RPCキーワード= 『RPC』ステータスキーワード= 『ステータス』サブモジュール、キーワード= 『サブモジュール』タイプキーワード= 『タイプ』のtypedefキーワード= 『『』ユニークキーワード=『ユニーク』単位キーワード=』単位のtypedef使用キーワード=「用途」値キーワード=「値」キーワード=「とき」ヤン・バージョンキーワード=「陽バージョン」陰元素キーワード=「陰要素」
;; other keywords
;;他のキーワード
add-keyword = 'add' current-keyword = 'current' delete-keyword = 'delete' deprecated-keyword = 'deprecated' false-keyword = 'false' max-keyword = 'max' min-keyword = 'min' not-supported-keyword = 'not-supported' obsolete-keyword = 'obsolete' replace-keyword = 'replace' system-keyword = 'system' true-keyword = 'true' unbounded-keyword = 'unbounded' user-keyword = 'user' current-function-invocation = current-keyword *WSP "(" *WSP ")"
追加キーワード=非推奨のキーワード「を削除」=現在のキーワード=「現在」を削除-キーワードを「を追加」=「非推奨の」偽のキーワード=「偽の」MAX-キーワード=「最大」最小 - キーワード=「分」ではありません担持さ-キーワードは、= '=時代遅れキーワード=「時代遅れ」を置換キーワード=システム・キーワード「を置き換える」='システムの真のキーワード=「true」を無制限キーワード=「無制限」は、ユーザ・キーワード「を、サポートされていません」ユーザの現在の機能-呼び出し=現在のキーワード* WSP "（" * WSP "）"
;; Basic Rules
;;基本的なルール
prefix-arg-str = < a string that matches the rule prefix-arg >
接頭引数-STR = <ルールの接頭辞、引数にマッチした文字列>
prefix-arg = prefix
接頭引数=接頭辞
prefix = identifier
接頭辞=識別子
identifier-arg-str = < a string that matches the rule identifier-arg >
識別子のarg-STR = <ルール識別子、引数と一致する文字列>
identifier-arg = identifier
ログイン-argを=ログイン
;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".")
;;識別子=（ALPHA / "_"）*（ALPHA / DIGIT /識別子は（| 'X'）（ 'M' | | 'M'）（ 'L' 'L'）（ 'X'）で始めることはできません"_" / " - " /） ""
identifier-ref-arg-str = < a string that matches the rule identifier-ref-arg >
識別子-REF-のarg-STR = <ルール識別子-REF-引数と一致する文字列>
identifier-ref-arg = [prefix ":"] identifier
識別子-REF-argに= [接頭辞 "："]識別子
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
非負整数値=「0」/正の整数値
positive-integer-value = (non-zero-digit *DIGIT)
正の整数値=（非ゼロ桁*のDIGIT）
zero-integer-value = 1*DIGIT
ゼロ整数値= 1 * DIGIT
stmtend = ";" / "{" *unknown-statement "}"
stmtend = ";" / "{" *不明文 "}"
sep = 1*(WSP / line-break) ; unconditional separator
9月= 1 *（WSP /改行）;無条件のセパレータ
optsep = *(WSP / line-break)
optsep = *（WSP /改行）
stmtsep = *(WSP / line-break / unknown-statement)
stmtsep = *（WSP /改行/未知の文）
line-break = CRLF / LF non-zero-digit = %x31-39
改行= CRLF / LF非ゼロ桁=％x31-39
decimal-value = integer-value ("." zero-integer-value)
進値=整数値（「」ゼロ整数値）
SQUOTE = %x27 ; ' (Single Quote)
SQUOTE =％X27。 '（単一引用符）
;;
;; RFC 5234 core rules.
;;
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA =％x41-5A /％x61-7A。 -Z / Z-
CR = %x0D ; carriage return
CR =％x0D。キャリッジリターン
CRLF = CR LF ; Internet standard new line
CRLF = CR LF。インターネット標準の新ライン
DIGIT = %x30-39 ; 0-9
DIGIT =％x30-39。 0-9
DQUOTE = %x22 ; " (Double Quote)
DQUOTE =％X22。 "（二重引用符）
HEXDIG = DIGIT / %x61 / %x62 / %x63 / %x64 / %x65 / %x66 ; only lower-case a..f
HEXDIG = DIGIT /％X61 /％X62 / X63％/％のx64 /％X65 /％X66。唯一の小文字のA〜F
HTAB = %x09 ; horizontal tab
HTAB =％X09。水平タブ
LF = %x0A ; linefeed
LF =％X0A。改行
SP = %x20 ; space
SP =％のX20。スペース
VCHAR = %x21-7E ; visible (printing) characters
VCHAR =％x21-7E。可視（印刷）文字
WSP = SP / HTAB ; whitespace
WSP = SP / HTAB;空白
<CODE ENDS>
<CODEはENDS>
A number of NETCONF error responses are defined for error cases related to the data-model handling. If the relevant YANG statement has an "error-app-tag" substatement, that overrides the default value specified below.
NETCONFエラー応答の数は、データモデルの取り扱いに関連するエラーの場合のために定義されています。関連YANG文は以下の指定されたデフォルト値を上書きします「というエラー・アプリ・タグ」サブステートメントを、持っている場合。
If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned:
NETCONF操作がユニーク制約が無効化された構成データにつながる場合は、次のエラーが返されます。
error-tag: operation-failed error-app-tag: data-not-unique error-info: <non-unique>: Contains an instance identifier that points to a leaf that invalidates the unique constraint. This element is present once for each non-unique leaf.
エラータグ：操作して失敗したエラーアプリタグ：データ固有ではないエラー情報：<非ユニーク>：一意制約を無効に葉を指すインスタンス識別子が含まれています。この要素は、各非ユニークな葉に一度存在しています。
The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1").
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too many entries the following error is returned:
NETCONF操作がリストまたはリーフリストは、次のエラーが返され、あまりにも多くのエントリを持つことになり、構成データにつながる場合：
error-tag: operation-failed error-app-tag: too-many-elements
エラータグ：操作に失敗したエラーアプリタグ：あまりにも多くの要素
This error is returned once, with the error-path identifying the list node, even if there are more than one extra child present.
このエラーは、複数の余分な子が存在している場合でも、リストのノードを特定するエラーパスで、一度返されます。
If a NETCONF operation would result in configuration data where a list or a leaf-list would have too few entries the following error is returned:
NETCONF操作がリストまたはリーフリストは、次のエラーが返される数が少なすぎるのエントリを持つことになり、構成データにつながる場合：
error-tag: operation-failed error-app-tag: too-few-elements
エラータグ：操作に失敗したエラーアプリタグ：あまりにもいくつかの要素
This error is returned once, with the error-path identifying the list node, even if there are more than one child missing.
このエラーは、不足している複数の子があっても、リストのノードを特定するエラーパスで、一度返されます。
If a NETCONF operation would result in configuration data where the restrictions imposed by a "must" statement is violated the following error is returned, unless a specific "error-app-tag" substatement is present for the "must" statement.
NETCONF操作は「しなければならない」文によって課される制限は、次のエラーに違反しているコンフィギュレーション・データにつながる場合は、特定の「エラー・アプリ - タグ」サブステートメントは「しなければならない」文の存在しない限り、返されます。
error-tag: operation-failed error-app-tag: must-violation
エラータグ：操作に失敗したエラーアプリタグ：必要があり、違反
If a NETCONF operation would result in configuration data where a leaf of type "instance-identifier" marked with require-instance "true" refers to a non-existing instance, the following error is returned:
NETCONF操作はでマークされた「インスタンス識別子」タイプの葉が「真」以外の既存のインスタンスを参照するインスタンスが必要と構成データにつながる場合は、次のエラーが返されます。
error-tag: data-missing error-app-tag: instance-required error-path: Path to the instance-identifier leaf.
エラータグ：データ欠落誤りアプリタグ：インスタンスに必要なエラーパス：インスタンス識別子の葉へのパス。
If a NETCONF operation would result in configuration data where a leaf of type "leafref" refers to a non-existing instance, the following error is returned:
NETCONF操作がタイプ「leafref」の葉は、非既存のインスタンスを指すコンフィギュレーションデータをもたらす場合には、次のエラーが返されます。
error-tag: data-missing error-app-tag: instance-required error-path: Path to the leafref leaf.
エラータグ：データ欠落誤りアプリタグ：インスタンスに必要なエラーパス：leafrefの葉へのパス。
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").
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:
「挿入」と「キー」または「値」属性は、<編集-config>の中で使用されている場合は、リストまたはリーフ・リストノードのための、および「キー」または「値」とは、非既存のインスタンスを指し、次のエラーが返されます。
error-tag: bad-attribute error-app-tag: missing-instance
エラータグ：悪い属性エラーアプリタグ：欠落しているインスタンス
This document defines a registry for YANG module and submodule names. The name of the registry is "YANG Module Names".
この文書では、YANGモジュールおよびサブモジュール名のレジストリを定義します。レジストリの名前は「YANGモジュール名」です。
The registry shall record for each entry:
レジストリは、各エントリのために記録しなければなりません：
o the name of the module or submodule
モジュールまたはサブモジュールの名前O
o for modules, the assigned XML namespace
モジュールのO、割り当てられているXML名前空間
o for modules, the prefix of the module
モジュールのO、モジュールの接頭辞
o for submodules, the name of the module it belongs to
Oサブモジュールのために、モジュールの名前は、それが属しています
o a reference to the (sub)module's documentation (e.g., the RFC number)
O（サブ）モジュールの文書への参照（例えば、RFC番号）
There are no initial assignments.
何の初期の割り当てはありません。
For allocation, RFC publication is required as per RFC 5226 [RFC5226]. All registered YANG module names MUST comply with the rules for identifiers stated in Section 6.2, and MUST have a module name prefix.
割り当てのために、RFC公報は、RFC 5226 [RFC5226]に従って必要とされます。すべての登録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.
モジュール名の接頭辞「irtf-」がIRTFストリーム文書のために予約されている間、モジュール名接頭辞は「ietf-」、IETFストリーム文書[RFC4844]のために予約されています。他のRFCストリームに掲載されたモジュールは、類似した、適切な接頭辞を持たなければなりません。
All module and submodule names in the registry MUST be unique.
レジストリ内のすべてのモジュールおよびサブモジュールの名前は一意でなければなりません。
All XML namespaces in the registry MUST be unique.
レジストリ内のすべてのXML名前空間は一意でなければなりません。
This document registers two URIs for the YANG and YIN XML namespaces in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following have been registered.
この文書は、IETF XMLレジストリ[RFC3688]でYANGとYIN XML名前空間のための2つのURIを登録します。 RFC 3688でフォーマットした後、次のように登録されています。
URI: urn:ietf:params:xml:ns:yang:yin:1
URI：URN：IETF：のparams：XML：NS：陽：陰：1
URI: urn:ietf:params:xml:ns:yang:1
URI：URN：IETF：のparams：XML：NS：陽：1
Registrant Contact: The IESG.
登録者連絡先：IESG。
XML: N/A, the requested URIs are XML namespaces.
XML：N / A、要求されたURIは、XML名前空間です。
This document registers two new media types as defined in the following sections.
次のセクションで定義されたこの文書は、2つの新しいメディアタイプを登録します。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: yang
MIMEサブタイプ名：陽
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: 8-bit
エンコードの考慮事項：8ビット
Security considerations: See Section 15 in RFC 6020
セキュリティの考慮事項：RFC 6020でセクション15を参照してください。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 6020
公開された仕様：RFC 6020
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
YANG module validators, web servers used for downloading YANG modules, email clients, etc.
などYANGモジュールバリ、YANGモジュールをダウンロードするために使用されるWebサーバ、電子メールクライアント、
Additional information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .yang
ファイル拡張子：.Its
Macintosh file type code: 'TEXT'
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Martin Bjorklund <mbj@tail-f.com>
詳しくは、個人やメールアドレス：マーティンBjorklund <mbj@tail-f.com>
Intended usage: COMMON
意図している用法：COMMON
Author: This specification is a work item of the IETF NETMOD working group, with mailing list address <netmod@ietf.org>.
著者：この仕様は、メーリングリストのアドレスで、IETF NETMODワーキンググループの作業項目である<netmod@ietf.org>。
Change controller: The IESG <iesg@ietf.org>
変更コントローラ：IESG <iesg@ietf.org>
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: yin+xml
MIMEサブタイプ名：陰+ 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].
「文字セット」：このパラメータは、[RFC3023]で指定されるように、「アプリケーション/ XML」メディアタイプのcharsetパラメータと同じ意味を有します。
Encoding considerations:
エンコードの考慮事項：
Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
[RFC3023]に記載されているように、「アプリケーション/ XML」のものと同じ、セクション3.2。
Security considerations: See Section 15 in RFC 6020
セキュリティの考慮事項：RFC 6020でセクション15を参照してください。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 6020
公開された仕様：RFC 6020
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
YANG module validators, web servers used for downloading YANG modules, email clients, etc.
などYANGモジュールバリ、YANGモジュールをダウンロードするために使用されるWebサーバ、電子メールクライアント、
Additional information:
追加情報：
Magic Number: As specified for "application/xml" in [RFC3023], Section 3.2.
マジックナンバー：[RFC3023]で "アプリケーション/ XML" のために指定されているように、3.2節。
File Extension: .yin
ファイル拡張子：.yin
Macintosh file type code: 'TEXT'
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Martin Bjorklund <mbj@tail-f.com>
詳しくは、個人やメールアドレス：マーティンBjorklund <mbj@tail-f.com>
Intended usage: COMMON
意図している用法：COMMON
Author: This specification is a work item of the IETF NETMOD working group, with mailing list address <netmod@ietf.org>.
著者：この仕様は、メーリングリストのアドレスで、IETF NETMODワーキンググループの作業項目である<netmod@ietf.org>。
Change controller: The IESG <iesg@ietf.org>
変更コントローラ：IESG <iesg@ietf.org>
This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
この文書では、書き込みと管理情報の記述を読むことで言語を定義します。言語自体は、インターネット上ではセキュリティへの影響はありません。
The same considerations are relevant as for the base NETCONF protocol (see [RFC4741], Section 9).
同じ考察は、ベースNETCONFプロトコル（[RFC4741]を参照して、第9）のような関連しています。
Data modeled in YANG might contain sensitive information. RPCs or notifications defined in YANG might transfer sensitive information.
YANGでモデル化されたデータは、機密情報が含まれている場合があります。 YANGで定義されたRPCまたは通知は、機密情報を転送することがあります。
Security issues are related to the usage of data modeled in YANG. Such issues shall be dealt with in documents describing the data models and documents about the interfaces used to manipulate the data e.g., the NETCONF documents.
セキュリティの問題は、YANGでモデル化されたデータの利用に関連しています。そのような問題は、例えばNETCONF文書データを操作するために使用されるインタフェースに関するデータ・モデルと文書を記述する文書で対処しなければなりません。
Data modeled in YANG is dependent upon:
YANGでモデル化されたデータは、依存しています：
o the security of the transmission infrastructure used to send sensitive information.
機密情報を送信するために使用される伝送インフラストラクチャのセキュリティO。
o the security of applications that store or release such sensitive information.
保存したり、そのような機密情報を公開するアプリケーションのセキュリティO。
o adequate authentication and access control mechanisms to restrict the usage of sensitive data.
O十分な認証およびアクセス制御メカニズムは、機密データの使用を制限します。
YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised.
YANGパーサは、不正な形式の文書に関しては堅牢にする必要があります。未知あるいは信頼できないソースからの不正な形式の文書を読むことYANGパーサを実行するユーザの権限を獲得し、攻撃者につながる可能性があります。極端な状況では、マシン全体が損なわれる可能性があります。
The following people all contributed significantly to the initial YANG document:
次の人はすべて、初期YANGの文書に大きく貢献しました。
- Andy Bierman (Brocade) - Balazs Lengyel (Ericsson) - David Partain (Ericsson) - Juergen Schoenwaelder (Jacobs University Bremen) - Phil Shafer (Juniper Networks)
- アンディBierman（ブロケード） - バラージュLengyel（エリクソン） - デヴィッド・パーテイン（エリクソン） - ユルゲンSchoenwaelder（ジェイコブス大学ブレーメン） - フィル・シェーファー（ジュニパーネットワークス）
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.
メフメットErsue、Washamファン、ジョエル・ハルパーン、レイフ・ヨハンソン、ラディスラフLhotka、ゲルハルトMuenz、トム・ペッチ、ランディPresuhn、デイビット・リード、およびバート：エディタはすべて、このドキュメントのさまざまなバージョンに有益なコメントを提供する以下の個人を、感謝したいですWijnenの。
[ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO Standard 10646:2003, 2003.
[ISO.10646]国際標準化機構、 "情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS）"、ISO規格10646：2003、2003。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]チザム、S.およびH.トレビノ、 "NETCONFイベント通知"、RFC 5277、2008年7月。
[XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Layman, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XML-NAMES]オランダ、D.、トービン、R.、トンプソン、H.、ブレイ、T.、およびA.素人、 "XML 1.0での名前空間（第3版）"、ワールドワイドウェブコンソーシアム勧告REC-XML-名前-20091208、2009年12月、<http://www.w3.org/TR/2009/REC-xml-names-20091208>。
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPATH]クラーク、J.とS. DeRose、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-のxpath-19991116、1999年11月、<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>.
[XSD-TYPES]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、ワールドワイドウェブコンソーシアム勧告REC-XMLSCHEMA-2から20041028、2004年10月、<のhttp：//www.w3。 ORG / TR / 2004 / REC-XMLSCHEMA-2から20041028>。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、エド。、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation Structure of Management Information", RFC 3780, May 2004.
[RFC3780]シュトラウス、F.およびJ. Schoenwaelder、 "SMIng - 経営情報の次世代構造"、RFC 3780、2004年5月。
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844] Daigle氏、L.およびインターネットアーキテクチャ委員会、 "RFCシリーズとRFCエディタ"、RFC 4844、2007年7月。
[XPATH2.0] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, January 2007, <http://www.w3.org/TR/2007/REC-xpath20-20070123>.
【XPATH2.0]ベルグルンド、A.、ボーグ、S.、チェン、D.、フェルナンデス、M.、ケイ、M.、Robie、J.、およびJ.シメオン、 "XMLパス言語（XPath）2.0"、 World Wide Web Consortium（W3C）の勧告REC-xpath20-20070123、2007年1月、<http://www.w3.org/TR/2007/REC-xpath20-20070123>。
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[XSLT]クラーク、J.、 "XSL変換（XSLT）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-XSLT-19991116、1999年11月、<http://www.w3.org/TR/1999/REC-xslt -19991116>。
Author's Address
著者のアドレス
Martin Bjorklund (editor) Tail-f Systems
マーティンBjorklund（編集者）テール-Fシステム
EMail: mbj@tail-f.com
メールアドレス：mbj@tail-f.com