Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 6087 Brocade
Category: Informational January 2011
ISSN: 2070-1721
Guidelines for Authors and Reviewers of YANG Data Model Documents
YANGデータモデルドキュメントの著者と査読のためのガイドライン
Abstract
抽象
This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules.
このメモはYANGデータモデルのモジュールを含む標準化過程仕様の著者と査読のためのガイドラインを提供します。該当部分は、他のYANGデータモデル文書のレビューのための基礎として使用することができます。 YANGデータモデルのモジュールを利用ネットワーク構成プロトコル（NETCONF）の実装の相互運用性と使いやすさを向上させることを意図しているに定義されている推奨事項と手順、。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6087.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6087で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . . . 4
2.3. YANG Terms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Documentation Guidelines . . . . . . . . . . . . . . . 5
3.1. Module Copyright . . . . . . . . . . . . . . . . . . . . . 5
3.2. Narrative Sections . . . . . . . . . . . . . . . . . . . . 6
3.3. Definitions Section . . . . . . . . . . . . . . . . . . . 6
3.4. Security Considerations Section . . . . . . . . . . . . . 6
3.5. IANA Considerations Section . . . . . . . . . . . . . . . 7
3.5.1. Documents that Create a New Namespace . . . . . . . . 7
3.5.2. Documents that Extend an Existing Namespace . . . . . 8
3.6. Reference Sections . . . . . . . . . . . . . . . . . . . . 8
4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 8
4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 8
4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Conditional Statements . . . . . . . . . . . . . . . . . . 10
4.5. XPath Usage . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Lifecycle Management . . . . . . . . . . . . . . . . . . . 11
4.7. Module Header, Meta, and Revision Statements . . . . . . . 12
4.8. Namespace Assignments . . . . . . . . . . . . . . . . . . 13
4.9. Top-Level Data Definitions . . . . . . . . . . . . . . . . 14
4.10. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 14
4.11. Reusable Type Definitions . . . . . . . . . . . . . . . . 15
4.12. Data Definitions . . . . . . . . . . . . . . . . . . . . . 15
4.13. Operation Definitions . . . . . . . . . . . . . . . . . . 17
4.14. Notification Definitions . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Security Considerations Section Template . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Module Review Checklist . . . . . . . . . . . . . . . 22
Appendix B. YANG Module Template . . . . . . . . . . . . . . . . 24
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) [RFC4741] requires a modular set of data models, which can be reused and extended over time.
ネットワークコンフィギュレーションプロトコル（NETCONF）[RFC4741]で使用するためのネットワーク構成インターフェイスの標準化は、経時的に再利用及び拡張可能なデータモデルのモジュールセットを必要とします。
This document defines a set of usage guidelines for Standards Track documents containing YANG [RFC6020] data models. YANG is used to define the data structures, protocol operations, and notification content used within a NETCONF server. A server that supports a particular YANG module will support client NETCONF operation requests, as indicated by the specific content defined in the YANG module.
この文書では、YANG [RFC6020]データモデルを含む標準化過程ドキュメントの使用ガイドラインのセットを定義します。 YANGは、NETCONFサーバ内で使用されるデータ構造、プロトコル動作、及び通知内容を定義するために使用されます。 YANGモジュールで定義された特定のコンテンツによって示されるように、特定のYANGモジュールをサポートするサーバーは、クライアントのNETCONF操作要求をサポートします。
This document is similar to the Structure of Management Information version 2 (SMIv2) usage guidelines specification [RFC4181] in intent and structure. However, since that document was written a decade after SMIv2 modules had been in use, it was published as a 'Best Current Practice' (BCP). This document is not a BCP, but rather an informational reference, intended to promote consistency in documents containing YANG modules.
この文書では、意図や構造における経営情報バージョン2（SMIv2の）使用上のガイドライン仕様[RFC4181]の構造に似ています。 SMIv2のモジュールが使用された後、その文書が十年を書かれていたので、それは「最も良い現在の練習」（BCP）として出版されました。この文書では、BCPのではなく、YANGモジュールを含む文書の一貫性を促進することを目的の情報の参照、ではありません。
Many YANG constructs are defined as optional to use, such as the description statement. However, in order to maximize interoperability of NETCONF implementations utilizing YANG data models, it is desirable to define a set of usage guidelines that may require a higher level of compliance than the minimum level defined in the YANG specification.
多くのYANG構築物は、そのような説明文として、使用するオプションとして定義されています。しかし、YANGデータモデルを利用NETCONF実装の相互運用性を最大にするためには、YANG仕様で定義された最小レベルよりコンプライアンスの高いレベルを必要とするかもしれ使用ガイドラインのセットを定義することが望ましいです。
In addition, YANG allows constructs such as infinite length identifiers and string values, or top-level mandatory nodes, that a compliant server is not required to support. Only constructs that all servers are required to support can be used in IETF YANG modules.
また、YANG準拠サーバをサポートするために必要とされないことを、このような無限長識別子と文字列値、または最上位必須ノードとして構築を可能にします。すべてのサーバーがサポートする必要があることを構築するだけではIETF YANGモジュールで使用することができます。
This document defines usage guidelines related to the NETCONF operations layer and NETCONF content layer, as defined in [RFC4741]. These guidelines are intended to be used by authors and reviewers to improve the readability and interoperability of published YANG data models.
[RFC4741]で定義されるように、このドキュメントは、NETCONFオペレーション層とNETCONFコンテンツレイヤに関連する使用上の注意事項を規定しています。これらのガイドラインは公表されYANGデータモデルの読みやすさと相互運用性を向上させるために、著者と査読が使用することを意図しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
RFC 2119 language is used here to express the views of the NETMOD working group regarding content for YANG modules. YANG modules complying with this document will treat the RFC 2119 terminology as if it were describing best current practices.
RFC 2119の言語がYANGモジュールの内容に関するNETMODワーキンググループの意見を表現するために、ここで使用されています。 YANGは、それが現在のベストプラクティスを説明しているかのようにRFC 2119の用語を扱います。この文書に準拠モジュール。
The following terms are defined in [RFC4741] and are not redefined here:
以下の用語は、[RFC4741]で定義されており、ここで再定義されていません。
o capabilities
O機能
o client
またはクライアント
o operation
運用O
o server
Oサーバ
The following terms are defined in [RFC6020] and are not redefined here:
以下の用語は、[RFC6020]で定義されており、ここで再定義されていません。
o data node
お だた ので
o module
Oモジュール
o namespace
Oの名前空間
o submodule
Oサブモジュール
o version
Oバージョン
o YANG
O
o YIN
MAKING O
Note that the term 'module' may be used as a generic term for a YANG module or submodule. When describing properties that are specific to submodules, the term 'submodule' is used instead.
用語「モジュール」はYANGモジュールまたはサブモジュールの総称として使用されてもよいことに留意されたいです。サブモジュールに固有の特性を説明するとき、用語「サブモジュール」は代わりに使用されています。
The following terms are used throughout this document:
以下の用語は、この文書全体で使用されています。
published: A stable release of a module or submodule, usually contained in an RFC.
公表：モジュールまたはサブモジュールの安定版リリースを、通常はRFCに含まれています。
unpublished: An unstable release of a module or submodule, usually contained in an Internet-Draft.
未発表：モジュールまたはサブモジュールの不安定なリリースは、通常、インターネットドラフトに含まれています。
YANG data model modules under review are likely to be contained in Internet-Drafts. All guidelines for Internet-Draft authors MUST be followed. The RFC Editor provides guidelines for authors of RFCs, which are first published as Internet-Drafts. These guidelines should be followed and are defined in [RFC2223] and updated in [RFC5741] and "RFC Document Style" [RFC-STYLE].
検討中YANGデータモデルモジュールは、インターネットドラフトに含まれる可能性が高いです。インターネットドラフトの作成者のためのすべてのガイドラインに従わなければなりません。 RFC Editorは、最初のインターネットドラフトとして公開されているRFCの著者、のためのガイドラインを提供します。これらのガイドラインは従わなければならないと[RFC2223]で定義されて、[RFC5741]と「RFCドキュメントスタイル」[RFC-STYLE]に更新されます。
The following sections MUST be present in an Internet-Draft containing a module:
以下のセクションでは、モジュールを含むインターネットドラフト中に存在していなければなりません。
o Narrative sections
O物語のセクション
o Definitions section
定義セクションO
o Security Considerations section
O Security Considerations部
o IANA Considerations section
O IANAの考慮事項のセクション
o References section
Oリファレンスセクション
The module description statement MUST contain a reference to the latest approved IETF Trust Copyright statement, which is available online at:
モジュールの説明文は、オンラインで利用可能である最新の承認IETFトラスト著作権声明への参照を含まなければなりません：
http://trustee.ietf.org/license-info/
ｈっｔｐ：／／ｔるｓてえ。いえｔｆ。おｒｇ／ぃせんせーいんふぉ／
Each YANG module or submodule contained within an Internet-Draft or RFC is considered to be a code component. The strings '<CODE BEGINS>' and '<CODE ENDS>' MUST be used to identify each code component.
インターネットドラフトまたはRFC内に含まれる各YANGモジュールまたはサブモジュールは、コード成分であると考えられます。文字列は、「<CODEが始まる>」と「<CODEが終了>」は、それぞれのコード成分を同定するために使用されなければなりません。
The '<CODE BEGINS>' tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [RFC6020]. The following example is for the '2010-01-18' revision of the 'ietf-foo' module:
「<CODE BEGINS>」タグは、[RFC6020]のセクション5.2で指定されたファイル名を識別する文字列が続くべきです。次の例では、「IETF-FOO」モジュールの「2010-01-18」改訂するためのものです。
<CODE BEGINS> file "ietf-foo@2010-01-18.yang"
module ietf-foo {
// ...
revision 2010-01-18 {
description "Latest revision";
reference "RFC XXXX";
}
// ...
}
<CODE ENDS>
The narrative part MUST include an overview section that describes the scope and field of application of the module(s) defined by the specification and that specifies the relationship (if any) of these modules to other standards, particularly to standards containing other YANG modules. The narrative part SHOULD include one or more sections to briefly describe the structure of the modules defined in the specification.
物語の一部は、仕様によって定義されたモジュール（単数または複数）の適用の範囲および分野を説明しているが、他の規格にこれらのモジュールの、特に他のYANGモジュールを含む標準との関係を（もしあれば）を指定概要セクションを含まなければなりません。物語の一部を簡単仕様で定義されたモジュールの構造を説明するために1つ以上のセクションを含むべきです。
If the module(s) defined by the specification imports definitions from other modules (except for those defined in the YANG [RFC6020] or YANG Types [RFC6021] documents), or are always implemented in conjunction with other modules, then those facts MUST be noted in the overview section, as MUST be noted any special interpretations of definitions in other modules.
仕様によって定義されたモジュール（単数または複数）は常に他のモジュールと組み合わせて実装され、または（YANG [RFC6020]またはYANGタイプ[RFC6021]ドキュメントで定義されたものを除く）、他のモジュールからの定義をインポートする場合は、それらの事実でなければなりません他のモジュールで定義の特別な解釈を注意しなければならないように、概要セクションで述べました。
This section contains the module(s) defined by the specification. These modules MUST be written using the YANG syntax defined in [RFC6020]. A YIN syntax version of the module MAY also be present in the document. There MAY also be other types of modules present in the document, such as SMIv2, which are not affected by these guidelines.
このセクションでは、仕様で定義されたモジュール（複数可）を含有します。これらのモジュールは、[RFC6020]で定義さYANG構文を使用して書かなければなりません。モジュールのYIN構文バージョンは、文書中に存在することができます。また、これらのガイドラインに影響されないのSMIv2、として文書に存在するモジュールの他のタイプが存在する可能性があります。
See Section 4 for guidelines on YANG usage.
YANGの使用に関するガイドラインについては第4章を参照してください。
Each specification that defines one or more modules MUST contain a section that discusses security considerations relevant to those modules.
一個の以上のモジュールを定義し、各仕様は、それらのモジュールに関連するセキュリティ上の考慮事項について説明セクションを含まなければなりません。
This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt).
このセクションでは、最新の承認テンプレート（http://www.ops.ietf.org/netconf/yang-security-considerations.txtで入手可能）の後にパターン化されなければなりません。
Section 6.1 contains the security considerations template dated 2010-06-16. Authors MUST check the webpage at the URL listed above in case there is a more recent version available.
6.1節は、2010年6月16日付けのセキュリティに関する考慮事項のテンプレートが含まれています。著者は、利用可能な、より新しいバージョンがある場合には、上記のURLでWebページをチェックしなければなりません。
In particular:
特に：
o Writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be explained.
虐待を受けた場合に特に破壊的かもしれO書き込み可能なデータ・ノードは、明示的に名前が記載されている必要があり、および関連するセキュリティリスクを説明しなければなりません。
o Readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained.
O、特に機密性の高い情報が含まれているか、それは重大なプライバシーの問題を提起読み取り可能なデータ・ノードは、明示的に名前が記載されている必要がありかつ感度/プライバシーの問題の理由を説明しなければなりません。
o Operations (i.e., YANG 'rpc' statements) that are potentially harmful to system behavior or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained.
O操作（すなわち、YANG「RPC」文）システムの動作に潜在的に有害であるか、それは重大なプライバシーの懸念が明示的に名前と感度の理由により記載されている必要があり上げる/プライバシーの問題を説明しなければなりません。
In order to comply with IESG policy as set forth in http://www.ietf.org/id-info/checklist.html, every Internet-Draft that is submitted to the IESG for publication MUST contain an IANA Considerations section. The requirements for this section vary depending on what actions are required of the IANA. If there are no IANA considerations applicable to the document, then the IANA Considerations section stating that there are no actions is removed by the RFC Editor before publication. Refer to the guidelines in [RFC5226] for more details.
http://www.ietf.org/id-info/checklist.htmlに記載のIESGポリシーに準拠するためには、公表のためにIESGに提出されているすべてのインターネットドラフトは、IANAの考慮事項のセクションを含まなければなりません。このセクションの要件は、アクションがIANAに要求されるものに応じて異なります。文書に適用されるいかなるIANA問題がない場合は、IANAの考慮事項のセクションでは、何のアクションが存在しない旨の公表前に、RFC編集者によって削除されます。詳細は[RFC5226]のガイドラインを参照してください。
If an Internet-Draft defines a new namespace that is to be administered by the IANA, then the document MUST include an IANA Considerations section that specifies how the namespace is to be administered.
インターネットドラフトは、IANAによって投与される新しい名前空間を定義する場合、その文書は、名前空間が投与される方法を指定するIANAの考慮事項のセクションを含まなければなりません。
Specifically, if any YANG module namespace statement value contained in the document is not already registered with IANA, then a new YANG Namespace registry entry MUST be requested from the IANA. The YANG [RFC6020] specification includes the procedure for this purpose in its IANA Considerations section.
文書に含まれるいかなるYANGモジュールの名前空間のステートメントの値がすでにIANAに登録されていない場合は具体的に、そして新しいYANG名前空間のレジストリエントリはIANAから要求されなければなりません。 YANG [RFC6020]仕様は、IANA Considerations部でこの目的のための手順を含みます。
It is possible to extend an existing namespace using a YANG submodule that belongs to an existing module already administered by IANA. In this case, the document containing the main module MUST be updated to use the latest revision of the submodule.
すでにIANAが管理既存のモジュールに属しYANGサブモジュールを使用して、既存の名前空間を拡張することが可能です。この場合、メインモジュールを含む文書は、サブモジュールの最新版を使用するように更新されなければなりません。
For every import or include statement that appears in a module contained in the specification, which identifies a module in a separate document, a corresponding normative reference to that document MUST appear in the Normative References section. The reference MUST correspond to the specific module version actually used within the specification.
すべてのインポートのために、または別のドキュメントにモジュールを識別明細書に含まれるモジュールに表示されるステートメントを含み、その文書に対応する規範的な参照は、引用規格のセクションに表示されなければなりません。参照は、実際には仕様の範囲内で使用される特定のモジュールバージョンに対応しなければなりません。
For every normative reference statement that appears in a module contained in the specification, which identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. The reference SHOULD correspond to the specific document version actually used within the specification. If the reference statement identifies an informative reference, which identifies a separate document, a corresponding informative reference to that document MAY appear in the Informative References section.
別の文書を識別する明細書に含まれるモジュールに表示されるすべての引用規格文に対して、その文書に対応する規範的な参照は、引用規格のセクションに表示されます。参照は、実際には仕様の範囲内で使用される特定の文書のバージョンに対応しなければなりません。参照文が別の文書を特定する有益な参照を、識別した場合、その文書に対応する有益な参照は、有益な参考資料セクションに表示されることがあります。
In general, modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG [RFC6020]. The guidelines in this section are intended to supplement the YANG specification, which is intended to define a minimum set of conformance requirements.
一般的には、IETF標準化過程仕様のモジュールは、YANG [RFC6020]のすべての構文とセマンティック要件を遵守しなければなりません。このセクションのガイドラインは、適合性要件の最小セットを定義することを意図されYANG仕様を、補完することを意図しています。
In order to promote interoperability and establish a set of practices based on previous experience, the following sections establish usage guidelines for specific YANG constructs.
相互運用性を促進し、これまでの経験に基づいた実践のセットを確立するために、次のセクションでは、YANG構築物の特定の使用ガイドラインを確立します。
Only guidelines that clarify or restrict the minimum conformance requirements are included here.
最小適合性要件を明確化または制限するだけのガイドラインはここに含まれています。
Modules contained in Standards Track documents SHOULD be named according to the guidelines in the IANA Considerations section of [RFC6020].
標準化過程文書に含まれるモジュールは、[RFC6020]のIANAの考慮事項セクションのガイドラインに従って名前を付ける必要があります。
A distinctive word or acronym (e.g., protocol name or working group acronym) SHOULD be used in the module name. If new definitions are being defined to extend one or more existing modules, then the same word or acronym should be reused, instead of creating a new one.
特有の単語または略語（例えば、プロトコル名やワーキンググループの頭字語）は、モジュール名で使用されるべきです。新しい定義は、1つまたは複数の既存のモジュールを拡張するために定義されている場合は、同じ単語や頭字語ではなく、新しいものを作成するのではなく、再利用する必要があります。
All published module names MUST be unique. For a YANG module published in an RFC, this uniqueness is guaranteed by IANA. For unpublished modules, the authors need to check that no other work in progress is using the same module name.
公開されたすべてのモジュール名は一意でなければなりません。 RFCで公開されYANGモジュールの場合、このユニークさは、IANAによって保証されています。未発表のモジュールの場合、著者は、進行中の他の作業は、同じモジュール名を使用していないことを確認する必要があります。
Once a module name is published, it MUST NOT be reused, even if the RFC containing the module is reclassified to 'Historic' status.
モジュール名が公開されたら、モジュールを含むRFCが「歴史」の状態に再分類された場合でも、再利用してはいけません。
Identifiers for all YANG identifiers in published modules MUST be between 1 and 64 characters in length. These include any construct specified as an 'identifier-arg-str' token in the ABNF in Section 12 of [RFC6020].
公表されたモジュール内のすべてのYANG識別子の識別子の長さは1〜64文字の間でなければなりません。これらは、[RFC6020]のセクション12にABNFに「識別子のarg-STR」トークンとして指定された構築物を含みます。
In general, it is suggested that substatements containing very common default values SHOULD NOT be present. The following substatements are commonly used with the default value, which would make the module difficult to read if used everywhere they are allowed.
一般的に、非常に一般的なデフォルト値を含むサブステートメントが存在すべきではないことが示唆されます。次のサブステートメントは、一般的にどこでも使用それらが許可されている場合は読みモジュールが困難になり、デフォルト値、で使用されています。
+---------------+---------------+
| Statement | Default Value |
+---------------+---------------+
| config | true |
| | |
| mandatory | false |
| | |
| max-elements | unbounded |
| | |
| min-elements | 0 |
| | |
| ordered-by | system |
| | |
| status | current |
| | |
| yin-element | false |
+---------------+---------------+
A module may be conceptually partitioned in several ways, using the 'if-feature' and/or 'when' statements.
モジュールは、概念的に「IF-機能」および/または「」ステートメントを使用して、いくつかの方法で分割することができます。
Data model designers need to carefully consider all modularity aspects, including the use of YANG conditional statements.
データモデル設計者は慎重YANG条件文の使用を含め、すべてのモジュール性の側面を考慮する必要があります。
If a data definition is optional, depending on server support for a NETCONF protocol capability, then a YANG 'feature' statement SHOULD be defined to indicate that the NETCONF capability is supported within the data model.
データ定義がオプションの場合、NETCONFプロトコル機能のためのサーバーのサポートに応じて、その後、YANG「機能」ステートメントは、NETCONF能力は、データモデル内でサポートされていることを示すために定義されるべきです。
If any notification data, or any data definition, for a non-configuration data node is not mandatory, then the server may or may not be required to return an instance of this data node. If any conditional requirements exist for returning the data node in a notification payload or retrieval request, they MUST be documented somewhere. For example, a 'when' or 'if-feature' statement could apply to the data node, or the conditional requirements could be explained in a 'description' statement within the data node or one of its ancestors (if any).
非コンフィギュレーション・データ・ノードのための任意の通知データ、又は任意のデータ定義は、必須ではない場合、サーバは、又はこのデータノードのインスタンスを戻すために必要とされなくてもよいです。いずれかの条件の要件は、通知ペイロードまたは検索要求のデータノードを返すために存在する場合、それらはどこかに文書化されなければなりません。例えば、「場合」または「IF-特徴」ステートメントは、データ・ノードに適用することができ、又は条件付きの要件は、データ・ノードまたはその祖先のいずれか（もしあれば）内の「説明」の文で説明することができます。
This section describes guidelines for using the XML Path Language [W3C.REC-xpath-19991116] (XPath) within YANG modules.
このセクションでは、YANGモジュール内のXMLパス言語[W3C.REC-のXPath-19991116]（XPathを）使用するためのガイドラインを記載しています。
The 'attribute' and 'namespace' axes are not supported in YANG, and MAY be empty in a NETCONF server implementation.
「属性」および「ネーム・スペース」の軸はYANGでサポートされていない、とNETCONFサーバの実装では空であってもよいです。
The 'position' and 'last' functions SHOULD NOT be used. This applies to implicit use of the 'position' function as well (e.g., '//chapter[42]'). A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The 'position' and 'last' functions MAY be used if they are evaluated in a context where the context node is a user-ordered 'list' or 'leaf-list'.
「位置」と「最後の」機能は使用されるべきではありません。これは、暗黙の「位置」機能の使用も（例えば、「//章[42]」）に適用されます。サーバーは、特定のユーザのみ、順序付けられたリストまたはリーフ・リストのすべてのインスタンスの相対的なXMLドキュメントの順序を維持するために必要とされます。彼らは、コンテキストノードがユーザー順序付け「リスト」や「リーフリスト」であるコンテキストで評価されている場合は、「位置」と「最後の」機能を使用することができます。
The 'preceding', and 'following' axes SHOULD NOT be used. These constructs rely on XML document order within a NETCONF server configuration database, which may not be supported consistently or produce reliable results across implementations. Predicate expressions based on static node properties (e.g., element name or value, 'ancestor' or 'descendant' axes) SHOULD be used instead. The 'preceding' and 'following' axes MAY be used if document order is not relevant to the outcome of the expression (e.g., check for global uniqueness of a parameter value).
「前の」、および軸を使用すべきでない「次」。これらの構築物は、一貫してサポートまたは実装間で信頼性のある結果を生成しなくてもよいNETCONFサーバ構成データベース内のXML文書の順序に依存しています。静的ノードの特性（例えば、要素名または値、「祖先」または「子孫」軸）に基づく述語表現が代わりに使用されるべきです。 「先行」と文書順序が式の結果に関連しない場合の軸を使用することができる「次」（例えば、パラメータ値のグローバル一意性を確認します）。
The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used. A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The 'preceding-sibling' and 'following-sibling' axes MAY be used if they are evaluated in a context where the context node is a user-ordered 'list' or 'leaf-list'.
「-兄弟の前」と「次-兄弟」軸は使用すべきではありません。サーバーは、特定のユーザのみ、順序付けられたリストまたはリーフ・リストのすべてのインスタンスの相対的なXMLドキュメントの順序を維持するために必要とされます。 「-兄弟先行」、それらがコンテキストノードがユーザ順序付け「リスト」または「リーフ・リスト」であるコンテキストで評価されている場合「以下、兄弟」軸を使用することができます。
Data nodes that use the 'int64' and 'uint64' built-in type SHOULD NOT be used within numeric expressions. There are boundary conditions in which the translation from the YANG 64-bit type to an XPath number can cause incorrect results. Specifically, an XPath 'double' precision floating point number cannot represent very large positive or negative 64-bit numbers because it only provides a total precision of 53 bits. The 'int64' and 'uint64' data types MAY be used in numeric expressions if the value can be represented with no more than 53 bits of precision.
「int64型」とビルトインタイプ「uint64型」を使用してデータノードは、数値式の中で使用されるべきではありません。 YANG 64ビット型からXPathの番号への翻訳が間違った結果を引き起こすことが可能な境界条件があります。それが唯一の53ビットの合計精度を提供するため、具体的には、XPathの「二重」精度浮動小数点数は、非常に大きな正または負の64ビット数を表すことができません。 「Int64の」と値が精度を超えない53ビットで表現することができれば「UINT64のデータタイプは数値式に使用されるかもしれません。
Data modelers need to be careful not to confuse the YANG value space and the XPath value space. The data types are not the same in both, and conversion between YANG and XPath data types SHOULD be considered carefully.
データモデラーはYANGの値空間とXPath値空間を混同しないように注意する必要があります。データタイプは、両方で同じではない、とYANGおよびXPathのデータ型の間の変換を慎重に考慮しなければなりません。
Explicit XPath data type conversions MAY be used (e.g., 'string', 'boolean', or 'number' functions), instead of implicit XPath data type conversions.
明示的なXPathデータ型の変換ではなく、暗黙的なXPathのデータ型変換を、（例えば、「文字列」、「ブール」、または「数」機能を）を使用してもよいです。
The status statement MUST be present if its value is 'deprecated' or 'obsolete'.
その値が「非推奨」または「時代遅れ」されている場合、ステータスステートメントが存在しなければなりません。
The module or submodule name MUST NOT be changed, once the document containing the module or submodule is published.
モジュールまたはサブモジュールを含むドキュメントが公開されると、モジュールまたはサブモジュール名は、変更してはいけません。
The module namespace URI value MUST NOT be changed, once the document containing the module is published.
モジュールを含むドキュメントが公開されると、モジュールの名前空間URI値は、変更しないでください。
The revision-date substatement within the imports statement SHOULD be present if any groupings are used from the external module.
いずれかのグループは、外部モジュールから使用されている場合はImportsステートメント内のリビジョン日付のサブステートメントが存在しなければなりません。
The revision-date substatement within the include statement SHOULD be present if any groupings are used from the external submodule.
いずれかのグループは、外部のサブモジュールから使用されている場合は、includeステートメント内のリビジョン最新のサブステートメントが存在しなければなりません。
If submodules are used, then the document containing the main module MUST be updated so that the main module revision date is equal or more recent than the revision date of any submodule that is (directly or indirectly) included by the main module.
サブモジュールが使用される場合、メインモジュール改訂日が（直接的または間接的に）メインモジュールに含まれる任意のサブモジュールの改訂日付より最近同等以上となるように、メインモジュールを含む文書を更新する必要があります。
For published modules, the namespace MUST be a globally unique URI, as defined in [RFC3986]. This value is usually assigned by the IANA.
公表されたモジュールの場合、名前空間は、[RFC3986]で定義されるように、グローバルにユニークなURIでなければなりません。この値は、通常、IANAによって割り当てられます。
The organization statement MUST be present. If the module is contained in a document intended for Standards Track status, then the organization SHOULD be the IETF working group chartered to write the document.
組織文は存在しなければなりません。モジュールは標準化過程の状態を対象とした文書に含まれている場合、その組織は、文書を書くためにチャーターIETFワーキンググループである必要があります。
The contact statement MUST be present. If the module is contained in a document intended for Standards Track status, then the working group web and mailing information MUST be present, and the main document author or editor contact information SHOULD be present. If additional authors or editors exist, their contact information MAY be present. In addition, the Area Director and other contact information MAY be present.
接触文は存在しなければなりません。モジュールは標準化過程の状態を対象とした文書に含まれている場合は、ワーキンググループのウェブと郵送の情報が存在しなければならない、とメイン文書の著者や編集者の連絡先情報が存在しなければなりません。追加の作家や編集者が存在する場合、その連絡先情報が存在してもよいです。また、エリアディレクターやその他の連絡先情報が存在してもよいです。
The description statement MUST be present. The appropriate IETF Trust Copyright text MUST be present, as described in Section 3.1.
説明文は存在しなければなりません。 3.1節で説明したように、適切なIETFトラスト著作権テキストは、存在しなければなりません。
If the module relies on information contained in other documents, which are not the same documents implied by the import statements present in the module, then these documents MUST be identified in the reference statement.
モジュールは、モジュール内に存在import文で暗示同じ書類ではありません他の文書に含まれる情報に依存している場合は、これらの文書は、参考書で識別されなければなりません。
A revision statement MUST be present for each published version of the module. The revision statement MUST have a reference substatement. It MUST identify the published document that contains the module. Modules are often extracted from their original documents, and it is useful for developers and operators to know how to find the original source document in a consistent manner. The revision statement MAY have a description substatement.
改正文は、モジュールの各公開バージョンのために存在しなければなりません。改正文は、参照サブステートメントを持たなければなりません。これは、モジュールが含まれて公開されたドキュメントを特定しなければなりません。モジュールは、多くの場合、元の文書から抽出され、開発者や事業者が一貫した方法で、元のソースドキュメントを見つける方法を知っておくことは有用です。改正文は記述のサブステートメントを持っているかもしれません。
Each new revision MUST include a revision date that is higher than any other revision date in the module. The revision date does not need to be updated if the module contents do not change in the new document revision.
それぞれの新しいリビジョンは、モジュール内の他のリビジョンの日付より高い改訂日を含まなければなりません。モジュールの内容は、新しい文書の改訂版では変更されない場合は、リビジョンの日付は更新する必要はありません。
It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted.
未発表のバージョン（即ち、インターネットドラフト）内で同じリビジョン文を再利用するために許容可能であるが、改訂日付が高い値にインターネットドラフトは、再投稿されるたびに更新されなければなりません。
It is RECOMMENDED that only valid YANG modules be included in documents, whether or not they are published yet. This allows:
唯一の有効なYANGモジュールは、彼らはまだ公開されているかどうかにかかわらず、文書に含まれることが推奨されます。これは、ことができます：
o the module to compile correctly instead of generating disruptive fatal errors.
Oモジュールではなく、破壊的な致命的なエラーを生成するので正しくコンパイルします。
o early implementors to use the modules without picking a random value for the XML namespace.
O初期の実装者は、XML名前空間のランダムな値を選ぶことなく、モジュールを使用します。
o early interoperability testing since independent implementations will use the same XML namespace value.
Oの独立した実装以来、早期の相互運用性テストは、同じXML名前空間の値を使用します。
Until a URI is assigned by the IANA, a proposed namespace URI MUST be provided for the namespace statement in a YANG module. A value SHOULD be selected that is not likely to collide with other YANG namespaces. Standard module names, prefixes, and URI strings already listed in the YANG Module Registry MUST NOT be used.
URIは、IANAによって割り当てられるまで、提案された名前空間URIは、YANGモジュール内の名前空間のステートメントのために提供されなければなりません。値は、他のYANG名前空間と衝突する可能性がないように選択されるべきです。すでにYANGモジュールレジストリに記載されている標準的なモジュール名、接頭辞、およびURI文字列を使用してはいけません。
A standard namespace statement value SHOULD have the following form:
標準名前空間のステートメントの値は次の形式を持っている必要があります。
<URN prefix string>:<module-name>
<URN接頭辞文字列>：<モジュール名>
The following URN prefix string SHOULD be used for published and unpublished YANG modules:
以下のURN接頭文字列が公開され、公開されていないYANGモジュールを使用する必要があります。
urn:ietf:params:xml:ns:yang:
URN：IETF：のparams：XML：NS：陽：
The following example URNs would be valid temporary namespace statement values for Standards Track modules:
次の例壺は、標準化過程モジュールの有効な一時的な名前空間のステートメントの値のようになります。
urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
URN：IETF：のparams：XML：NS：ヤン：IETF-NETCONF-パーシャル・ロック
urn:ietf:params:xml:ns:yang:ietf-netconf-state
URN：IETF：のparams：XML：NS：ヤン：IETF-NETCONF状態
urn:ietf:params:xml:ns:yang:ietf-netconf
URN：IETF：のparams：XML：NS：ヤン：IETF-NETCONF
Note that a different URN prefix string SHOULD be used for non-Standards-Track modules. The string SHOULD be selected according to the guidelines in [RFC6020].
別のURN接頭辞文字列は非標準トラック・モジュールを使用する必要があることに注意してください。文字列は、[RFC6020]のガイドラインに従って選択されるべきです。
The following examples of non-Standards-Track modules are only suggestions. There are no guidelines for this type of URN in this document:
非標準トラック・モジュールの次の例では、唯一の提案です。このドキュメントのURNのこのタイプのためのガイドラインはありません。
http://example.com/ns/example-interfaces
ｈっｔｐ：／／えぁｍｐぇ。こｍ／んｓ／えぁｍｐぇーいんてｒふぁせｓ
http://example.com/ns/example-system
ｈっｔｐ：／／えぁｍｐぇ。こｍ／んｓ／えぁｍｐぇーｓｙｓてｍ
There SHOULD only be one top-level data node defined in each YANG module, if any data nodes are defined at all.
任意のデータノードが全く定義されている場合にのみ、各YANGモジュールで定義された1つのトップレベル・データ・ノードが存在すべきです。
The top-level data organization SHOULD be considered carefully, in advance. Data model designers need to consider how the functionality for a given protocol or protocol family will grow over time.
トップレベルのデータ編成は、事前に、慎重に検討すべきです。データモデルの設計者は、与えられたプロトコルまたはプロトコルファミリ用の機能は、時間をかけて成長する方法を検討する必要があります。
The names and data organization SHOULD reflect persistent information, such as the name of a protocol. The name of the working group SHOULD NOT be used because this may change over time.
名前とデータ編成は、そのようなプロトコルの名前として、永続的な情報を反映する必要があります。これは時間の経過とともに変化する可能性があるため、ワーキンググループの名前を使用してはいけません。
A mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value.
必須データベースのデータ定義は、データベースが有効であるためには、クライアントが提供しなければならないノードとして定義されます。サーバーは、値を提供する必要はありません。
Top-level database data definitions MUST NOT be mandatory. If a mandatory node appears at the top level, it will immediately cause the database to be invalid. This can occur when the server boots or when a module is loaded dynamically at runtime.
トップレベルのデータベースのデータ定義が必須にすることはできません。必須ノードがトップレベルに表示された場合は、すぐにデータベースは無効となります。ときに、サーバの起動またはモジュールは、実行時に動的にロードされたときに発生する可能性があります。
Selection of an appropriate data type (i.e., built-in type, existing derived type, or new derived type) is very subjective, and therefore few requirements can be specified on that subject.
適切なデータ・タイプの選択（すなわち、内蔵型、派生タイプ、又は新しい派生型を既存の）非常に主観的であり、したがって、いくつかの要件は、その被写体に指定することができます。
Data model designers SHOULD use the most appropriate built-in data type for the particular application.
データモデルの設計者は、特定のアプリケーションのための最も適切なビルトインデータ型を使用すべきです。
If extensibility of enumerated values is required, then the 'identityref' data type SHOULD be used instead of an enumeration or other built-in type.
列挙値の拡張が必要な場合は、「identityref」データ型ではなく、内蔵型列挙または他の使用されるべきです。
For string data types, if a machine-readable pattern can be defined for the desired semantics, then one or more pattern statements SHOULD be present.
機械可読パターンが所望のセマンティクスのために定義することができる場合は、文字列データ型のために、1つの以上のパターン文が存在しなければなりません。
For string data types, if the length of the string is required to be bounded in all implementations, then a length statement MUST be present.
文字列の長さがすべての実装に囲まする必要がある場合は文字列データ型の場合は、その後、長さステートメントが存在しなければなりません。
For numeric data types, if the values allowed by the intended semantics are different than those allowed by the unbounded intrinsic data type (e.g., 'int32'), then a range statement SHOULD be present.
意図セマンティクスによって許可された値は、無限組み込みデータ型（例えば、「INT32」）によって許可されたものと異なる場合、数値データ・タイプの場合、その後範囲文が存在しなければなりません。
The signed numeric data types (i.e., 'int8', 'int16', 'int32', and 'int64') SHOULD NOT be used unless negative values are allowed for the desired semantics.
署名された数値データ型負の値は、所望のセマンティクスのために許可されていない限り（すなわち、「INT8」、「INT16」、「INT32」、及び「Int64の」）が使用されるべきではありません。
For 'enumeration' or 'bits' data types, the semantics for each 'enum' or 'bit' SHOULD be documented. A separate description statement (within each 'enum' or 'bit' statement) SHOULD be present.
「列挙」または「ビット」のデータタイプのために、各「列挙」または「ビット」の意味は、文書化されるべきです。 （各「列挙」または「ビット」ステートメント内の）別の説明文が存在しなければなりません。
If an appropriate derived type exists in any standard module, such as [RFC6021], then it SHOULD be used instead of defining a new derived type.
適切な派生型は、[RFC6021]などの任意の標準モジュールに存在する場合、それは新しい派生型を定義するのではなく、使用されるべきです。
If an appropriate units identifier can be associated with the desired semantics, then a units statement SHOULD be present.
適切な単位識別子が所望のセマンティクスと関連付けることができる場合には、単位文が存在しなければなりません。
If an appropriate default value can be associated with the desired semantics, then a default statement SHOULD be present.
適切なデフォルト値が所望のセマンティクスと関連付けることができる場合は、デフォルトの文は存在すべきです。
If a significant number of derived types are defined, and it is anticipated that these data types will be reused by multiple modules, then these derived types SHOULD be contained in a separate module or submodule, to allow easier reuse without unnecessary coupling.
派生型のかなりの数が定義され、これらのデータ・タイプは、複数のモジュールによって再利用されることが予想される場合、これらの派生型が不要に結合することなく、容易再利用を可能にするために、別々のモジュールまたはサブモジュールに含まれるべきです。
The description statement MUST be present.
説明文は存在しなければなりません。
If the type definition semantics are defined in an external document (other than another YANG module indicated by an import statement), then the reference statement MUST be present.
タイプ定義の意味を（import文により示される別のYANGモジュール以外の）外部の文書で定義されている場合、参照文が存在しなければなりません。
The description statement MUST be present in the following YANG statements:
説明文は次YANG文で存在している必要があります
o anyxml
AnyXMLでO
o augment
または増加
o choice
Oの選択
o container o extension
OコンテナO拡張
o feature
お ふぇあつれ
o grouping
Oのグループ化
o identity
Oアイデンティティ
o leaf
葉
o leaf-list
リーフリスト
o list
手紙
o notification
O通知
o rpc
O RPC
o typedef
Oのtypedef
If the data definition semantics are defined in an external document, (other than another YANG module indicated by an import statement), then a reference statement MUST be present.
データ定義の意味を（import文により示される別のYANGモジュール以外の）外部の文書で定義されている場合、参照文が存在しなければなりません。
The 'anyxml' construct may be useful to represent an HTML banner containing markup elements, such as '<b>' and '</b>', and MAY be used in such cases. However, this construct SHOULD NOT be used if other YANG data node types can be used instead to represent the desired syntax and semantics.
「AnyXMLで」構築物のようなHTMLバナーを含むマークアップ要素を表すために有用であり得る「<B>」と「</ B>」、及びそのような場合に使用することができます。他のYANGデータノードタイプは、所望の構文およびセマンティクスを表現するために代わりに使用することができる場合は、この構築物を使用しないでください。
If there are referential integrity constraints associated with the desired semantics that can be represented with XPath, then one or more 'must' statements SHOULD be present.
XPathので表現することができます希望の意味に関連した参照整合性制約がある場合は、1つ以上の文が存在するべきである「必要があります」。
For list and leaf-list data definitions, if the number of possible instances is required to be bounded for all implementations, then the max-elements statements SHOULD be present.
可能なインスタンスの数は、すべての実装のために境界される必要がある場合は、リストとリーフリストデータ定義については、次に最大要素文が存在しなければなりません。
If any 'must' or 'when' statements are used within the data definition, then the data definition description statement SHOULD describe the purpose of each one.
文がデータ定義内で使用される「とき」いずれか、または、その後、データ定義記述文は、それぞれの目的を説明すべきである「しなければならない」の場合。
If the operation semantics are defined in an external document (other than another YANG module indicated by an import statement), then a reference statement MUST be present.
オペレーションセマンティクスが（import文により示される別のYANGモジュール以外の）外部の文書で定義されている場合、参照文が存在しなければなりません。
If the operation impacts system behavior in some way, it SHOULD be mentioned in the description statement.
何らかの方法で操作の影響システムの挙動た場合、それは、説明文の中で言及されるべきです。
If the operation is potentially harmful to system behavior in some way, it MUST be mentioned in the Security Considerations section of the document.
操作は、いくつかの方法でシステムの動作に潜在的に有害である場合には、文書のセキュリティについての考慮事項のセクションに記載しなければなりません。
The description statement MUST be present.
説明文は存在しなければなりません。
If the notification semantics are defined in an external document (other than another YANG module indicated by an import statement), then a reference statement MUST be present.
通知セマンティクスが（import文により示される別のYANGモジュール以外の）外部の文書で定義されている場合、参照文が存在しなければなりません。
This document registers one URI in the IETF XML registry [RFC3688]. The following registration has been made:
この文書は、IETF XMLレジストリ[RFC3688]で1つのURIを登録します。以下の登録が行われています。
URI: urn:ietf:params:xml:ns:yang:ietf-template
URI：URN：IETF：のparams：XML：NS：ヤン：IETF-テンプレート
Registrant Contact: The NETMOD WG of the IETF.
登録者連絡先：IETFのNETMOD WG。
XML: N/A, the requested URI is an XML namespace.
XML：N / Aは、要求されたURIは、XML名前空間があります。
Per this document, the following assignment has been made in the YANG Module Names Registry for the YANG module template in Appendix B.
このドキュメントごとに、以下の割り当ては、付録BのYANGモジュールテンプレートのYANGモジュール名レジストリになされたものであり、
+---------------+-------------------------------------------+
| Field | Value |
+---------------+-------------------------------------------+
| Name | ietf-template |
| | |
| Namespace | urn:ietf:params:xml:ns:yang:ietf-template |
| | |
| Prefix | temp |
| | |
| Reference | RFC 6087 |
+---------------+-------------------------------------------+
This document defines documentation guidelines for NETCONF content defined with the YANG data modeling language. The guidelines for how to write a Security Considerations section for a YANG module are defined in the online document
この文書では、YANGデータモデリング言語で定義されたNETCONFのコンテンツのドキュメントのガイドラインを定義します。 YANGモジュールのセキュリティの考慮事項のセクションを作成する方法についてのガイドラインは、オンライン文書で定義されています
http://www.ops.ietf.org/netconf/yang-security-considerations.txt
ｈっｔｐ：／／ｗっｗ。おｐｓ。いえｔｆ。おｒｇ／ねｔこんｆ／やんｇーせくりｔｙーこんしでらちおんｓ。ｔｘｔ
This document does not introduce any new or increased security risks into the management system.
この文書では、管理システムに新規または強化されたセキュリティ上のリスクを導入していません。
The following section contains the security considerations template dated 2010-06-16. Be sure to check the webpage at the URL listed above in case there is a more recent version available.
次のセクションでは、2010年6月16日付けのセキュリティに関する考慮事項のテンプレートが含まれています。可能なより新しいバージョンがある場合には、上記のURLでWebページを確認してください。
Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt).
一つ以上のYANGモジュールを定義し、各仕様は、それらのモジュールに関連するセキュリティ上の考慮事項について説明セクションを含まなければなりません。このセクションでは、最新の承認テンプレート（http://www.ops.ietf.org/netconf/yang-security-considerations.txtで入手可能）の後にパターン化されなければなりません。
In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out.
具体的には、虐待を受けた場合に特に破壊的な可能性があり、書き込み可能なデータ・ノードは、明示的に名前が記載されている必要があり、および関連するセキュリティリスクが綴られなければなりません。
Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained.
同様に、特に機密性の高い情報が含まれているか、その重要なプライバシーの問題を提起読み取り可能なデータ・ノードは、明示的に名前が記載されている必要がありかつ感度/プライバシーの問題の理由を説明しなければなりません。
Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained.
新しいRPC操作が定義されている場合はさらに、その後、それぞれの新しいRPC操作のセキュリティの考慮事項を説明しなければなりません。
X. Security Considerations
X.のセキュリティの考慮事項
The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC4742].
このメモで定義されたYANGモジュールはNETCONFプロトコル[RFC4741]を介してアクセスするように設計されています。最低NETCONF層は、セキュアトランスポート層と強制的に実装安全な輸送は、SSH [RFC4742]です。
-- if you have any writable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability.
- あなたが任意の書き込み可能なデータノードがある場合（これらはすべてある - 「コンフィグ真」ノード、および覚えて、それがデフォルトです） - 彼らの特定の感度や脆弱性について説明します。
There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
（デフォルト、すなわち、コンフィグ真）書き込み可能/作成可能/削除可能であり、このYANGモジュールで定義されたデータノードの数があります。これらのデータノードは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護なしに、これらのデータノードへの書き込み操作（例えば、編集設定）は、ネットワーク操作に悪影響を与えることができます。これらは、サブツリーとデータノードとそれらの感度/脆弱性です：
<list subtrees and data nodes and state why they are sensitive>
<リストのサブツリーとデータノードと状態がなぜ彼らは敏感です>
-- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties)
- GET- - 彼らはまた、取得などの操作を経由して読み取ることができるため、ノード - ノード（それらのすべての「コンフィグ偽」のノードであるが、他のすべて - すべてYANGモジュールのためにあなたは、任意の読み取り可能なデータがあるかどうかを評価しなければなりません）権限のない者 - にさらされた場合、欧州連合（EU）のものと法律を - 顧客情報を明らかにしたり、個人のプライバシーを侵害する可能性がある - configが）彼らは例えば、場合（感受性または脆弱です
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールで読み取り可能なデータノードのいくつかは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。これらのデータノードにアクセスすること（例えば、GETを介して、または通知設定を取得する）読み取り制御することが重要です。これらは、サブツリーとデータノードとそれらの感度/脆弱性です：
<list subtrees and data nodes and state why they are sensitive>
<リストのサブツリーとデータノードと状態がなぜ彼らは敏感です>
-- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability.
あなたYANGモジュールは任意のRPC操作を定義している場合 - - 彼らの特定の感度や脆弱性について説明します。
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:
このYANGモジュールにおけるRPC操作のいくつかは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。これらの操作へのアクセスを制御することが重要です。これらは、操作とそれらの感度/脆弱性です：
<list RPC operations and state why they are sensitive>
<リストのRPC操作や状態がなぜ彼らは敏感です>
The structure and contents of this document are adapted from Guidelines for MIB Documents [RFC4181], by C. M. Heard.
この文書の構造および内容はC. M.聞いたことにより、MIB文献[RFC4181]のガイドラインに適合しています。
The working group thanks Martin Bjorklund and Juergen Schoenwaelder for their extensive reviews and contributions to this document.
彼らの豊富なレビューと、この文書への貢献のためのワーキンググループに感謝マーティンBjorklundとユルゲンSchoenwaelder。
[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月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。
[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月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5378]ブラドナー、S.およびJ.コントレラス、 "権利貢献者は、IETFトラストに提供"、BCP 78、RFC 5378、2008年11月。
[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC5741] Daigle氏、L.、Kolkman、O.、およびIAB、 "RFCストリーム、ヘッダ、およびボイラープレート"、RFC 5741、2009年12月。
[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "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>.
[W3C.REC-のxpath-19991116] DeRose、S.とJ.クラーク、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-のxpath-19991116、1999年11月、<のhttp：// WWW。 w3.org/TR/1999/REC-xpath-19991116>。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M.、 "YANG - ネットワーク構成プロトコルのためのデータモデリング言語（NETCONF）"、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J.、 "共通YANGデータ型"、RFC 6021、2010年10月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]聞いた、C.、 "MIBドキュメントの著者と査読のためのガイドライン"、BCP 111、RFC 4181、2005年9月。
[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月。
[RFC-STYLE] Braden, R., Ginoza, S., and A. Hagens, "RFC Document Style", September 2009, <http://www.rfc-editor.org/rfc-style-guide/rfc-style>.
[RFC-STYLE]ブレーデン、R.、宜野座、S.、およびA. Hagens、 "RFCドキュメント・スタイル"、2009年9月、<http://www.rfc-editor.org/rfc-style-guide/rfc-スタイル>。
Appendix A. Module Review Checklist
付録A.モジュールレビューのチェックリスト
This section is adapted from RFC 4181.
このセクションでは、RFC 4181から構成されています。
The purpose of a YANG module review is to review the YANG module both for technical correctness and for adherence to IETF documentation requirements. The following checklist may be helpful when reviewing an Internet-Draft:
YANGモジュールレビューの目的は、技術的な正確さとIETF文書化要件の遵守のために、両方のYANGモジュールを検討することです。インターネットドラフトを検討する際、以下のチェックリストが役立つかもしれません。
1. I-D Boilerplate -- verify that the draft contains the required Internet-Draft boilerplate (see http://www.ietf.org/id-info/guidelines.html), including the appropriate statement to permit publication as an RFC, and that I-D boilerplate does not contain references or section numbers.
1. IDボイラープレート - ドラフトは、RFCとして公表を可能にするために、適切な声明を含め、必要なインターネットドラフトの定型文を（http://www.ietf.org/id-info/guidelines.htmlを参照）、含まれていることを確認し、そのIDの定型を参照またはセクション番号が含まれていません。
2. Abstract -- verify that the abstract does not contain references, that it does not have a section number, and that its content follows the guidelines in http://www.ietf.org/id-info/guidelines.html.
2.概要は - それはセクションの番号を持っていないことを、抽象的には参照が含まれていないことを確認し、その内容はhttp://www.ietf.org/id-info/guidelines.htmlのガイドラインに従うこと。
3. Copyright Notice -- verify that the draft has the appropriate text regarding the rights that document contributers provide to the IETF Trust [RFC5378]. Verify that it contains the full IETF Trust copyright notice at the beginning of the document. The IETF Trust Legal Provisions (TLP) can be found at:
3.著作権 - ドラフト文書の貢献者は、IETFトラスト[RFC5378]に提供権利に関する適切なテキストを持っていることを確認してください。それは、文書の先頭に完全なIETFトラストの著作権情報が含まれていることを確認してください。 IETFトラスト法規定（TLP）はで見つけることができます：
http://trustee.ietf.org/license-info/
ｈっｔｐ：／／ｔるｓてえ。いえｔｆ。おｒｇ／ぃせんせーいんふぉ／
4. Security Considerations section -- verify that the draft uses the latest approved template from the OPS area website (http:// www.ops.ietf.org/netconf/yang-security-considerations.txt) and that the guidelines therein have been followed.
4. Security Considerations部は - ドラフトはOPSエリアのウェブサイトから最新の承認テンプレートを使用していることを確認します（http：// www.ops.ietf.org/netconf/yang-security-considerations.txt）とガイドラインは、その中に持っていること守られて。
5. IANA Considerations section -- this section must always be present. For each module within the document, ensure that the IANA Considerations section contains entries for the following IANA registries:
5. IANA条項セクション - このセクションでは、常に存在する必要があります。文書内の各モジュールのために、IANA Considerations部は、次のIANAレジストリのエントリが含まれていることを確認します。
XML Namespace Registry: Register the YANG module namespace.
XML名前空間レジストリ：YANGモジュールの名前空間を登録します。
YANG Module Registry: Register the YANG module name, prefix, namespace, and RFC number, according to the rules specified in [RFC6020].
YANGモジュールレジストリ：[RFC6020]で指定されたルールに従って、YANGモジュール名、接頭辞、名前空間、およびRFC番号を登録します。
6. References -- verify that the references are properly divided between normative and informative references, that RFC 2119 is included as a normative reference if the terminology defined therein is used in the document, that all references required by the boilerplate are present, that all YANG modules containing imported items are cited as normative references, and that all citations point to the most current RFCs unless there is a valid reason to do otherwise (for example, it is OK to include an informative reference to a previous version of a specification to help explain a feature included for backward compatibility). Be sure citations for all imported modules are present somewhere in the document text (outside the YANG module).
6.参照 - そこに定義された用語が文書内で使用される場合、参照が正しく規範と有益参考間で分割されていることを確認し、そのRFC 2119は、定型によって必要とされる全ての参考文献は、すべてことを、存在していること、規範参照として含まれますそうでなければ行う正当な理由がない限り、インポートアイテムを含むYANGモジュールが全ての引用は、最新のRFCを指していることを引用規格として引用され、（例えば、仕様の以前のバージョンへの有益な参照を含むことがOKであります）下位互換性のために含まれる特徴を説明するのに役立ちます。すべてのインポートモジュールの引用は（YANGモジュール外）文書テキストのどこかに存在していることを確認してください。
7. License -- verify that the draft contains the Simplified BSD License in each YANG module or submodule. Some guidelines related to this requirement are described in Section 3.1. Make sure that the correct year is used in all copyright dates. Use the approved text from the latest Trust Legal Provisions (TLP) document, which can be found at:
7.ライセンス - ドラフトは、各YANGモジュールまたはサブモジュールで簡体BSDライセンスが含まれていることを確認します。この要求に関連するいくつかのガイドラインは、3.1節で説明されています。正しい年は、すべての著作権の日付に使用されていることを確認してください。で発見することができ、最新のトラスト法規定（TLP）のドキュメントから承認されたテキストを使用します。
http://trustee.ietf.org/license-info/
ｈっｔｐ：／／ｔるｓてえ。いえｔｆ。おｒｇ／ぃせんせーいんふぉ／
8. Other Issues -- check for any issues mentioned in http://www.ietf.org/id-info/checklist.html that are not covered elsewhere.
8.その他の問題 - 他の場所でカバーされていないhttp://www.ietf.org/id-info/checklist.htmlで述べたすべての問題を確認してください。
9. Technical Content -- review the actual technical content for compliance with the guidelines in this document. The use of a YANG module compiler is recommended when checking for syntax errors. A list of freely available tools and other information can be found at:
9.技術的な内容 - このドキュメントのガイドラインに準拠して、実際の技術的な内容を確認します。構文エラーをチェックするときYANGモジュールコンパイラの使用が推奨されます。自由に利用できるツールやその他の情報のリストを見つけることができます：
http://trac.tools.ietf.org/wg/netconf/trac/wiki
ｈっｔｐ：／／ｔらｃ。とおｌｓ。いえｔｆ。おｒｇ／ｗｇ／ねｔこんｆ／ｔらｃ／うぃき
Checking for correct syntax, however, is only part of the job. It is just as important to actually read the YANG module document from the point of view of a potential implementor. It is particularly important to check that description statements are sufficiently clear and unambiguous to allow interoperable implementations to be created.
正しい構文のチェック、しかし、仕事の一部でしかありません。実際には潜在的な実装の観点からYANGモジュールのドキュメントを読むために同様に重要です。説明文には相互運用可能な実装を作成することができるように十分に明確であいまいでないことを確認することが特に重要です。
Appendix B. YANG Module Template
付録B. YANGモジュールテンプレート
<CODE BEGINS> file "ietf-template@2010-05-18.yang"
ファイル "ietf-template@2010-05-18.yang" <CODEが開始されます>
module ietf-template {
IETFテンプレート{モジュール
// replace this string with a unique namespace URN value
namespace
"urn:ietf:params:xml:ns:yang:ietf-template";
// replace this string, and try to pick a unique prefix prefix "temp";
//この文字列を置換し、独自の接頭辞接頭辞「TEMP」を選択してみてください。
// import statements here: e.g., // import ietf-yang-types { prefix yang; } // import ietf-inet-types { prefix inet; }
ここで、//インポートステートメント：例えば、//インポートIETF-ヤン・タイプ{プレフィックス陽。 } //インポートIETF-INET-タイプ{プレフィックスINET。 }
// identify the IETF working group if applicable organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
該当する組織「IETF NETMOD（NETCONFデータモデリング言語）ワーキンググループ」場合// IETFワーキンググループを特定します。
// update this contact statement with your info contact "WG Web: <http://tools.ietf.org/wg/your-wg-name/> WG List: <mailto:your-wg-name@ietf.org>
<http://tools.ietf.org/wg/your-wg-name/> WG一覧：：<のmailto：your-wg-name@ietf.org> //あなたの情報接触「WGのWebでこの接触ステートメントを更新
WG Chair: your-WG-chair
<mailto:your-WG-chair@example.com>
Editor: your-name <mailto:your-email@example.com>";
エディタ：あなたの名<のmailto：your-email@example.com> ";
// replace the first sentence in this description statement. // replace the copyright notice with the most recent // version, if it has been updated since the publication // of this document description "This module defines a template for other YANG modules.
//この説明文の最初の文を交換してください。 //このモジュールは、他のYANGモジュール用のテンプレートを定義し、この文書の記述」の出版//以降に更新されている場合は、最新の//バージョンと著作権情報を交換してください。
Copyright (c) <insert year> IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）<挿入年> IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFトラストの法律規定のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用
Relating to IETF Documents (http://trustee.ietf.org/license-info).
IETFドキュメント（http://trustee.ietf.org/license-info）に関連します。
This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC XXXXの一部です。完全な適法な通知についてはRFC自体を参照してください。 ";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
// RFCエド：実際のRFC番号でXXXXを交換し、このノートを削除
reference "RFC XXXX";
参照「RFC XXXX」。
// RFC Ed.: remove this note // Note: extracted from RFC 6087
// RFCエド：//注このノートを削除してください。RFC 6087から抽出されました
// replace '2010-05-18' with the module publication date // The format is (year-month-day) revision "2010-05-18" { description "Initial version"; }
//モジュールの発行日に「2010-05-18」を置き換える//フォーマットがある（年 - 月 - 日）改正「2010-05-18」{説明「初期バージョン」。 }
// extension statements
//拡張文
// feature statements
//機能ステートメント
// identity statements
//アイデンティティ文
// typedef statements
//のtypedef文
// grouping statements
//ステートメントをグループ化
// data definition statements
//データ定義ステートメント
// augment statements
//ステートメントを強化
// rpc statements
// RPCステートメント
// notification statements
//通知文
// DO NOT put deviation statements in a published module
//公表モジュールに偏差文を入れないでください
}
｝
<CODE ENDS>
<CODEはENDS>
Author's Address
著者のアドレス
Andy Bierman Brocade
アンディBiermanブロケード
EMail: andy.bierman@brocade.com
メールアドレス：andy.bierman@brocade.com