Internet Engineering Task Force (IETF) A. Bierman
Request for Comments: 6087 Brocade
Category: Informational January 2011
ISSN: 2070-1721
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数据模型文件的基础。定义了建议和程序，旨在提高利用数据模型模块的网络配置协议（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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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.
本文档为包含[RFC6020]数据模型的标准跟踪文档定义了一套使用指南。YANG用于定义NETCONF服务器中使用的数据结构、协议操作和通知内容。支持特定YANG模块的服务器将支持客户端NETCONF操作请求，如YANG模块中定义的特定内容所示。
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，而是信息参考，旨在促进包含模块的文档的一致性。
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.
许多构造被定义为可选的，例如description语句。然而，为了最大限度地利用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模块中只能使用所有服务器都需要支持的结构。
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内容层相关的使用指南。这些指南旨在供作者和评审人员使用，以提高已发布数据模型的可读性和互操作性。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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语言表达NETMOD工作组关于模块内容的观点。符合本文件要求的模块将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编辑器为RFC的作者提供指南，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 安全考虑科
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/
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.
Internet草稿或RFC中包含的每个模块或子模块都被视为代码组件。字符串“<CODE start>”和“<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节中指定的文件名。以下示例适用于“IETFO”模块的“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>
<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.
叙述部分必须包括一个概述部分，描述规范中定义的模块的范围和应用领域，并规定这些模块与其他标准的关系（如有），特别是与包含其他模块的标准的关系。叙述部分应包括一个或多个章节，简要描述规范中定义的模块结构。
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语法编写这些模块。文档中还可能包含模块的语法版本。文档中还可能存在其他类型的模块，例如SMIv2，它们不受这些指南的影响。
See Section 4 for guidelines on YANG usage.
请参阅第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-06-16的安全注意事项模板。作者必须在上面列出的URL处检查网页，以防有更新的版本可用。
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 必须按名称明确列出可能对系统行为有害或引起重大隐私问题的操作（即“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.
为了遵守IESG政策，如http://www.ietf.org/id-info/checklist.html，提交给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.
如果Internet草案定义了一个由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注册，则必须从IANA请求新的YANG命名空间注册表项。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管理的现有模块的子模块扩展现有名称空间。在这种情况下，必须更新包含主模块的文档，以使用子模块的最新版本。
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.
模块名称中应使用独特的单词或首字母缩略词（例如，协议名称或工作组首字母缩略词）。如果正在定义新定义以扩展一个或多个现有模块，则应重复使用相同的单词或首字母缩略词，而不是创建新的。
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].
已发布模块中所有标识符的标识符长度必须介于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 |
+---------------+---------------+
+---------------+---------------+
| 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.
数据模型设计者需要仔细考虑所有模块化方面，包括使用杨条件语句。
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协议功能的支持，那么应该定义一个“feature”语句来指示数据模型中支持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”语句可以应用于数据节点，或者条件要求可以在数据节点或其祖先之一（如果有）内的“description”语句中解释。
This section describes guidelines for using the XML Path Language [W3C.REC-xpath-19991116] (XPath) within YANG modules.
本节介绍在模块中使用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'.
不应使用“位置”和“最后”功能。这也适用于“position”函数的隐式使用（例如，“//chapter[42]”）。服务器只需要维护特定用户排序列表或叶列表的所有实例的相对XML文档顺序。如果在上下文节点是用户排序的“列表”或“叶列表”的上下文中对“position”和“last”函数进行求值，则可以使用它们。
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”内置类型的数据节点。在某些边界条件下，从64位类型到XPath数的转换可能会导致不正确的结果。具体来说，XPath“双精度”浮点数字不能表示非常大的正或负64位数字，因为它只提供53位的总精度。如果值的表示精度不超过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.
数据建模人员需要小心，不要混淆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数据类型转换（例如，“string”、“boolean”或“number”函数），而不是隐式XPath数据类型转换。
The status statement MUST be present if its value is 'deprecated' or 'obsolete'.
如果status语句的值为“不推荐”或“过时”，则该语句必须存在。
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.
对于已发布的模块，命名空间必须是全局唯一的URI，如[RFC3986]中所定义。该值通常由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.
如果模块依赖于其他文档中包含的信息，而这些文档与模块中的导入声明暗示的文档不同，则必须在参考声明中标识这些文档。
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:
建议文档中只包含有效的模块，无论它们是否已发布。这允许：
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.
在IANA分配URI之前，必须为模块中的namespace语句提供建议的名称空间URI。应选择不可能与其他名称空间冲突的值。不得使用模块注册表中已列出的标准模块名称、前缀和URI字符串。
A standard namespace statement value SHOULD have the following form:
标准命名空间语句值应具有以下形式：
<URN prefix string>:<module-name>
<URN prefix string>:<module-name>
The following URN prefix string SHOULD be used for published and unpublished YANG modules:
以下URN前缀字符串应用于已发布和未发布的模块：
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将是标准跟踪模块的有效临时命名空间语句值：
urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
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-state
urn:ietf:params:xml:ns:yang:ietf-netconf
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-interfaces
http://example.com/ns/example-system
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.
如果定义了任何数据节点，则每个模块中只应定义一个顶级数据节点。
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.
对于字符串数据类型，如果可以为所需的语义定义机器可读的模式，那么应该存在一个或多个模式语句。
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”）允许的值，则应该存在一个range语句。
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.
对于“枚举”或“位”数据类型，应记录每个“枚举”或“位”的语义。应提供单独的描述语句（在每个“enum”或“bit”语句中）。
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.
如果适当的单元标识符可以与所需的语义相关联，那么应该存在一个units语句。
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.
如果类型定义语义是在外部文档中定义的（导入语句指示的另一个模块除外），则必须存在引用语句。
The description statement MUST be present in the following YANG statements:
描述语句必须出现在以下语句中：
o anyxml
o 任意XML
o augment
o 加强
o choice
o 选择
o container
o 容器
o extension
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 类型定义
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.
如果数据定义语义是在外部文档中定义的（导入语句指示的另一个模块除外），则必须存在引用语句。
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横幅可能很有用，并且可以在这种情况下使用。但是，如果可以使用其他数据节点类型来表示所需的语法和语义，则不应使用此构造。
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表示的所需语义相关联的引用完整性约束，那么应该存在一个或多个“必须”语句。
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.
如果操作语义是在外部文档中定义的（导入语句指示的另一个模块除外），则必须存在引用语句。
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.
如果通知语义是在外部文档中定义的（导入语句指示的另一个模块除外），则必须存在引用语句。
This document registers one URI in the IETF XML registry [RFC3688]. The following registration has been made:
本文档在IETF XML注册表[RFC3688]中注册了一个URI。已进行以下登记：
URI: urn:ietf:params:xml:ns:yang:ietf-template
URI: urn:ietf:params:xml:ns:yang:ietf-template
Registrant Contact: The NETMOD WG of the IETF.
注册人联系人：IETF的NETMOD工作组。
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 |
+---------------+-------------------------------------------+
+---------------+-------------------------------------------+
| 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
本文档定义了使用数据建模语言定义的NETCONF内容的文档指南。在线文档中定义了如何为YANG模块编写安全注意事项部分的指导原则
http://www.ops.ietf.org/netconf/yang-security-considerations.txt
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处检查网页，以防有更新的版本可用。
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).
定义一个或多个模块的每个规范必须包含一节，讨论与这些模块相关的安全注意事项。此部分必须按照最新批准的模板（可在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
十、安全考虑
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].
本备忘录中定义的模块旨在通过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.
-- 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:
此模块中定义了许多数据节点，这些节点是可写/可创建/可删除的（即config true，这是默认值）。在某些网络环境中，这些数据节点可能被视为敏感或易受攻击。对这些数据节点的写入操作（如编辑配置）如果没有适当的保护，可能会对网络操作产生负面影响。这些是子树和数据节点及其敏感性/漏洞：
<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)
-- 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:
在某些网络环境中，此模块中的某些可读数据节点可能被视为敏感或易受攻击。因此，控制对这些数据节点的读取访问（例如，通过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.
-- 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:
在某些网络环境中，此模块中的某些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 Schoenwaeld对本文件的广泛审查和贡献。
[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，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年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 57412009年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路径语言（xpath）1.0版”，万维网联盟建议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）的数据建模语言”，RFC6020，2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021]Schoenwaeld，J.，“常见的杨氏数据类型”，RFC 602112010年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 41812005年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]Braden，R.，Ginoza，S.，和A.Hagens，“RFC文档样式”，2009年9月<http://www.rfc-editor.org/rfc-style-guide/rfc-style>.
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模块审查的目的是审查YANG模块的技术正确性和是否符合IETF文件要求。审查互联网草案时，以下清单可能会有所帮助：
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样板--验证草稿是否包含所需的Internet草稿样板（请参阅http://www.ietf.org/id-info/guidelines.html)，包括允许作为RFC发布的适当声明，以及I-D样板文件不包含参考文件或章节号。
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/
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区域网站（http://www.OPS.ietf.org/netconf/yang Security tiverses.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 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
6. 参考文件——验证参考文件是否正确划分为规范性参考文件和信息性参考文件，如果文件中使用了RFC 2119中定义的术语，则验证RFC 2119是否包含为规范性参考文件，以及
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).
样板文件是存在的，所有包含进口项目的模块都被引用为规范性引用，并且所有引用都指向最新的RFC，除非有正当理由这样做（例如，可以包含对规范早期版本的信息性引用，以帮助解释包含的向后兼容性功能）。确保所有导入模块的引用都出现在文档文本的某个位置（模块之外）。
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. 许可证--验证草稿是否包含每个模块或子模块中的简化BSD许可证。第3.1节描述了与此要求相关的一些指南。确保在所有版权日期中使用正确的年份。使用最新信托法律规定（TLP）文件中的批准文本，可在以下网址找到：
http://trustee.ietf.org/license-info/
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
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模块文档同样重要。特别重要的是检查描述语句是否足够清晰和明确，以允许创建可互操作的实现。
<CODE BEGINS> file "ietf-template@2010-05-18.yang"
<CODE BEGINS> file "ietf-template@2010-05-18.yang"
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 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; }
// 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工作组（如适用）组织“IETF NETMOD（NETCONF数据建模语言）工作组”；
// 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>
// 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>
WG Chair: your-WG-chair
<mailto:your-WG-chair@example.com>
Editor: your-name
<mailto:your-email@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.
// 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.
版权所有（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
根据IETF信托法律条款第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改
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.";
此模块的此版本是RFC XXXX的一部分；有关完整的法律通知，请参见RFC本身。“；
// RFC Ed.: replace XXXX with actual RFC number and remove this note
// RFC Ed.: replace XXXX with actual RFC number and remove this note
reference "RFC XXXX";
参考“RFC XXXX”；
// RFC Ed.: remove this note
// Note: extracted from RFC 6087
// RFC Ed.: remove this note
// Note: extracted from RFC 6087
// replace '2010-05-18' with the module publication date
// The format is (year-month-day)
revision "2010-05-18" {
description
"Initial version";
}
// 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
//身份声明
// 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
EMail: andy.bierman@brocade.com