[要約] RFC 6087は、YANGデータモデルドキュメントの著者とレビュアーのためのガイドラインです。その目的は、YANGデータモデルの作成とレビューの品質を向上させることです。
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 Data Model Documentsの著者およびレビュアーのガイドライン
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 Data Modelモジュールを含む標準の著者と標準のレビュアーを追跡するためのガイドラインを提供します。適用される部分は、他のヤンデータモデルドキュメントのレビューの基礎として使用できます。Yang Data Modelモジュールを利用するネットワーク構成プロトコル（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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モジュールが使用されてから10年後に書かれていたため、「Best Current Practice」（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データモデルを使用している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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 クライアント
o operation
o 手術
o server
o サーバ
The following terms are defined in [RFC6020] and are not redefined here:
次の用語は[RFC6020]で定義されており、ここでは再定義されていません。
o data node
o データノード
o module
o モジュール
o namespace
o 名前空間
o submodule
o サブモジュール
o version
o バージョン
o YANG
o ヤン
o YIN
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エディターは、最初にインターネットドラフトとして公開されるRFCSの著者にガイドラインを提供します。これらのガイドラインに従って、[RFC2223]で定義され、[RFC5741]および「RFCドキュメントスタイル」[RFCスタイル]で更新されます。
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 セキュリティ上の考慮事項セクション
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 Trust Copyright Statementへの参照が含まれている必要があります。
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 begins>'および '<code ends>'を使用して、各コードコンポーネントを識別する必要があります。
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.
1つ以上のモジュールを定義する各仕様には、それらのモジュールに関連するセキュリティに関する考慮事項を議論するセクションを含める必要があります。
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-06-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の考慮事項がない場合、公開前にRFCエディターによってアクションが削除されないことを示すIANAの考慮事項セクション。詳細については、[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 Module Namespaceステートメント値がまだIANAに登録されていない場合は、IANAから新しいYang NameSpaceレジストリエントリを要求する必要があります。Yang [RFC6020]仕様には、IANAの考慮事項セクションにこの目的の手順が含まれています。
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.
相互運用性を促進し、以前の経験に基づいて一連のプラクティスを確立するために、次のセクションでは、特定のヤンコンストラクトの使用ガイドラインを確立します。
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-feature」および/または「when」ステートメントを使用して、いくつかの方法で概念的に分割される場合があります。
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).
非構成データノードの通知データまたはデータ定義が必須ではない場合、サーバーはこのデータノードのインスタンスを返す必要がある場合とそうでない場合があります。通知のペイロードまたは取得要求でデータノードを返すために条件付き要件がある場合は、どこかで文書化する必要があります。たとえば、「when」または「if-feature」ステートメントがデータノードに適用されるか、条件付き要件をデータノードまたはその祖先のいずれか内の「説明」ステートメントで説明できます（もしあれば）。
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 Server構成データベース内の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'.
「先行するsibling」および「次の兄弟」軸は使用しないでください。サーバーは、特定のユーザー注文リストまたはリーフリストのすべてのインスタンスの相対的な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数への翻訳が誤った結果を引き起こす可能性がある境界条件があります。具体的には、Xpathの「ダブル」精度の浮動小数点数は、53ビットの合計精度のみを提供するため、非常に大きな正または負の64ビット数を表すことはできません。値を53ビット以下の精度で表現できる場合、「INT64」および「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.
データモデラーは、ヤンバリュースペースと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.
外部モジュールからのグループが使用される場合は、輸入ステートメント内の改訂版の表現が存在する必要があります。
The revision-date substatement within the include statement SHOULD be present if any groupings are used from the external submodule.
外部サブモジュールからのグループが使用される場合は、インクルードステートメント内の改訂版の置換が存在する必要があります。
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.
連絡先ステートメントが存在する必要があります。モジュールが標準の追跡ステータスを目的としたドキュメントに含まれている場合、ワーキンググループWebと郵送情報が存在する必要があり、メインドキュメント著者または編集者の連絡先情報が存在する必要があります。追加の著者または編集者が存在する場合、連絡先情報が存在する場合があります。さらに、エリアディレクターとその他の連絡先情報が存在する場合があります。
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.
モジュールが、モジュールに存在するインポートステートメントで暗示されている同じドキュメントではない他のドキュメントに含まれる情報に依存している場合、これらのドキュメントは参照ステートメントで特定する必要があります。
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によって割り当てられるまで、Yangモジュールの名前空間ステートメントに提案された名前空間URIを提供する必要があります。他のヤンネームスペースと衝突する可能性が低い値を選択する必要があります。Yangモジュールレジストリに既にリストされている標準モジュール名、プレフィックス、およびURI文字列は使用してはなりません。
A standard namespace statement value SHOULD have the following form:
標準の名前空間ステートメント値には、次の形式が必要です。
<URN prefix string>:<module-name>
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：yang：
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:yang:ietf-netconf-state
urn:ietf:params:xml:ns:yang: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.
列挙された値の拡張性が必要な場合は、列挙または他の内蔵型の代わりに「IDEFREF」データ型を使用する必要があります。
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.
タイプ定義セマンティクスが外部ドキュメントで定義されている場合（インポートステートメントで示された別のYangモジュール以外）、参照ステートメントが存在する必要があります。
The description statement MUST be present in the following YANG statements:
説明ステートメントは、次のヤンステートメントに存在する必要があります。
o anyxml
o anyxml
o augment
o 増強
o choice
o 選択
o container o extension
o コンテナO拡張機能
o feature
o 特徴
o grouping
o グループ化
o identity
o 身元
o leaf
o 葉
o leaf-list
o リーフリスト
o list
o リスト
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.
データ定義セマンティクスが外部ドキュメントで定義されている場合（インポートステートメントで示されている別の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」コンストラクトは、「<b>」や「</b>」などのマークアップ要素を含むHTMLバナーを表すのに役立ち、そのような場合に使用される場合があります。ただし、他の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.
リストおよびリーフリストのデータ定義の場合、すべての実装に可能なインスタンスの数を制限する必要がある場合、Max-Elementsステートメントが存在する必要があります。
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.
操作セマンティクスが外部ドキュメントで定義されている場合（インポートステートメントで示された別の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.
通知セマンティクスが外部ドキュメントで定義されている場合（インポートステートメントで示された別の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
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 Data Modeling Languageで定義された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-06-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).
1つ以上の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]を介してアクセスするように設計されています。最低のネットコン層は安全な輸送層であり、実装対象の安全な輸送は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モジュールには、書き込み可能/クリエーション/削除可能な（つまり、デフォルトである構成）。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（例：編集Config）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノードとその感度/脆弱性です。
<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)
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、get config、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。
<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.
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。HeardによってMIBドキュメント[RFC4181]のガイドラインから採用されています。
The working group thanks Martin Bjorklund and Juergen Schoenwaelder for their extensive reviews and contributions to this document.
ワーキンググループは、この文書への広範なレビューと貢献について、Martin BjorklundとJuergen Schoenwaelderに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5378] Bradner、S。およびJ. Contreras、「権利貢献者が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. Clark、「XML Path Language（XPath）バージョン1.0」、World Wide Webコンソーシアムの推奨REC-XPATH-1991116、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。、「Common Yangデータ型」、RFC 6021、2010年10月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181] Heard、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スタイル] Braden、R.、Ginoza、S。、およびA. Hagens、「RFC Document Style」、2009年9月、<http://www.rfc-editor.org/rfc-style-guide/rfc--スタイル>。
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. I-Dボイラープレート - ドラフトに必要なインターネットドラフトボイラープレートが含まれていることを確認します（http://www.ietf.org/id-info/guidelines.htmlを参照）。ボイラープレートには、参照またはセクション番号が含まれていません。
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. セキュリティ上の考慮事項セクション - ドラフトがOPSエリアのWebサイト（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の考慮事項セクションに次のIANAレジストリのエントリが含まれていることを確認してください。
XML Namespace Registry: Register the YANG module namespace.
XML名空間レジストリ：Yang Module Namespaceを登録します。
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. 参照 - 参照が規範的参照と有益な参照の間に適切に分割されていることを確認します。RFC2119は、そこで定義されている用語がドキュメントで使用されている場合、ボイラープレートで必要なすべての参照が存在する場合、すべてのYangモジュールが存在することを規範的参照として含めますインポートされたアイテムを含む項目は規範的な参照として引用されており、すべての引用は、特に行う必要のある正当な理由がない限り、最新のRFCを指していることを指します（たとえば、説明を支援するために以前のバージョンの仕様への有益な参照を含めても構いません。後方互換性のための機能）。すべてのインポートされたモジュールの引用が、ドキュメントテキストのどこかに（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 Moduleドキュメントを実際に読むことも同様に重要です。相互運用可能な実装を作成するために、説明ステートメントが十分に明確で明確であることを確認することが特に重要です。
<CODE BEGINS> file "ietf-template@2010-05-18.yang"
module ietf-template {
モジュールietf-template {
// 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; }
// identify the IETF working group if applicable organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
//該当する組織「IETF NetMod（NetConf Data Modeling Language）ワーキンググループ」の場合、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>
WG Chair: your-WG-chair
<mailto:your-WG-chair@example.com>
Editor: your-name
<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.
Copyright (c) <insert year> IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）<insert year> ietf Trustおよびコードの著者として特定された人。全著作権所有。
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 Relating to IETF Documents (http://trustee.ietf.org/license-info).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている簡略化されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。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 ed。：xxxxを実際のRFC番号に置き換えて、このメモを削除します
reference "RFC XXXX";
参照「rfc xxxx」;
// RFC Ed.: remove this note // Note: extracted from RFC 6087
// RFC ed。：このメモを削除//注：RFC 6087から抽出
// replace '2010-05-18' with the module publication date
// The format is (year-month-day)
revision "2010-05-18" {
description
"Initial version";
}
// extension statements
//拡張ステートメント
// feature statements
//機能ステートメント
// identity statements
// IDステートメント
// 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>Author's Address
<コードエンド>著者のアドレス
Andy Bierman Brocade
アンディ・ビアマン・ブロケード
EMail: andy.bierman@brocade.com