Internet Engineering Task Force (IETF) P. Shafer
Request for Comments: 6244 Juniper Networks
Category: Informational June 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Shafer
Request for Comments: 6244 Juniper Networks
Category: Informational June 2011
ISSN: 2070-1721
An Architecture for Network Management Using NETCONF and YANG
基于NETCONF和YANG的网络管理体系结构
Abstract
摘要
The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.
网络配置协议（NETCONF）允许访问网络中设备的本机功能，定义操作配置数据库、检索操作数据和调用特定操作的方法。YANG提供了定义通过NETCONF承载的内容的方法，包括数据和操作。使用这两种技术，可以定义标准模块，为设备提供互操作性和通用性，同时仍然允许设备表达其独特的功能。
This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators.
本文档介绍NETCONF和YANG如何帮助构建满足网络运营商需求的网络管理应用程序。
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/rfc6244.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6244.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 5
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 7
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Building NETCONF- and YANG-Based Solutions . . . . . . . . 14
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19
3.3.4. Application Developer . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 5
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 7
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Building NETCONF- and YANG-Based Solutions . . . . . . . . 14
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19
3.3.4. Application Developer . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Networks are increasing in complexity and capacity, as well as the density of the services deployed upon them. Uptime, reliability, and predictable latency requirements drive the need for automation. The problems with network management are not simple. They are complex and intricate. But these problems must be solved for networks to meet the stability needs of existing services while incorporating new services in a world where the growth of networks is exhausting the supply of qualified networking engineers.
网络的复杂性和容量以及部署在其上的服务的密度都在增加。正常运行时间、可靠性和可预测的延迟要求推动了对自动化的需求。网络管理的问题并不简单。它们是复杂的。但这些问题必须得到解决，才能使网络满足现有服务的稳定性需求，同时在网络增长耗尽合格网络工程师供应的世界中纳入新服务。
In June of 2002, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535]. The members of this workshop made a number of observations and recommendations for the IETF's consideration concerning the issues operators were facing in their network management-related work as well as issues they were having with the direction of the IETF activities in this area.
2002年6月，互联网体系结构委员会（IAB）举办了一次网络管理研讨会[RFC3535]。该研讨会的成员就运营商在网络管理相关工作中面临的问题以及他们在该领域指导IETF活动时遇到的问题提出了一些意见和建议，供IETF考虑。
The output of this workshop was focused on current problems. The observations were reasonable and straightforward, including the need for transactions, rollback, low implementation costs, and the ability to save and restore the device's configuration data. Many of the observations give insight into the problems operators were having with existing network management solutions, such as the lack of full coverage of device capabilities and the ability to distinguish between configuration data and other types of data.
本次研讨会的成果侧重于当前的问题。这些观察结果是合理而直接的，包括对事务的需求、回滚、低实现成本以及保存和恢复设备配置数据的能力。许多观察结果让我们深入了解了运营商在现有网络管理解决方案中遇到的问题，例如缺乏对设备功能的全面覆盖以及区分配置数据和其他类型数据的能力。
Based on these directions, the NETCONF working group was formed and the Network Configuration (NETCONF) protocol was created. This protocol defines a simple mechanism where network management applications, acting as clients, can invoke operations on the devices, which act as servers. The NETCONF specification [RFC4741] defines a small set of operations, but goes out of its way to avoid making any requirements on the data carried in those operations, preferring to allow the protocol to carry any data. This "data model agnostic" approach allows data models to be defined independently.
根据这些指示，成立了NETCONF工作组，并创建了网络配置（NETCONF）协议。该协议定义了一种简单的机制，在该机制中，作为客户端的网络管理应用程序可以调用作为服务器的设备上的操作。NETCONF规范[RFC4741]定义了一组小的操作，但避免了对这些操作中携带的数据提出任何要求，更倾向于允许协议携带任何数据。这种“数据模型不可知”的方法允许独立定义数据模型。
But lacking a means of defining data models, the NETCONF protocol was not usable for standards-based work. Existing data modeling languages such as the XML Schema Definition (XSD) [W3CXSD] and the Document Schema Definition Languages (DSDL) [ISODSDL] were considered, but were rejected because of the problem that domains have little natural overlap. Defining a data model or protocol that is encoded in XML is a distinct problem from defining an XML document. The use of NETCONF operations places requirements on the data content that are not shared with the static document problem domain addressed by schema languages like XSD or RELAX NG.
但由于缺乏定义数据模型的方法，NETCONF协议无法用于基于标准的工作。考虑了现有的数据建模语言，如XML模式定义（XSD）[W3CXSD]和文档模式定义语言（DSDL）[ISODSDL]，但由于域几乎没有自然重叠的问题而被拒绝。定义用XML编码的数据模型或协议与定义XML文档是截然不同的问题。NETCONF操作的使用对数据内容提出了要求，这些数据内容不与XSD或RELAXNG等模式语言处理的静态文档问题域共享。
In 2007 and 2008, the issue of a data modeling language for NETCONF was discussed in the OPS and APP areas of IETF 70 and 71, and a design team was tasked with creating a requirements document [RCDML]. After discussing the available options at the CANMOD BoF at IETF 71, the community wrote a charter for the NETMOD working group. An excellent description of this time period is available at <http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>.
In 2007 and 2008, the issue of a data modeling language for NETCONF was discussed in the OPS and APP areas of IETF 70 and 71, and a design team was tasked with creating a requirements document [RCDML]. After discussing the available options at the CANMOD BoF at IETF 71, the community wrote a charter for the NETMOD working group. An excellent description of this time period is available at <http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>.translate error, please retry
In 2008 and 2009, the NETMOD working group produced a specification for YANG [RFC6020] as a means for defining data models for NETCONF, allowing both standard and proprietary data models to be published in a form that is easily digestible by human readers and satisfies many of the issues raised in the IAB NM workshop. This brings NETCONF to a point where is can be used to develop standard data models within the IETF.
2008年和2009年，NETMOD工作组为YANG[RFC6020]制定了一份规范，作为定义NETCONF数据模型的一种手段，允许标准和专有数据模型以人类读者易于理解的形式发布，并满足IAB NM研讨会上提出的许多问题。这使NETCONF达到了可以在IETF中使用is开发标准数据模型的程度。
YANG allows a modeler to create a data model, to define the organization of the data in that model, and to define constraints on that data. Once published, the YANG module acts as a contract between the client and server, with both parties understanding how their peer will expect them to behave. A client knows how to create valid data for the server, and knows what data will be sent from the server. A server knows the rules that govern the data and how it should behave.
YANG允许建模人员创建数据模型，定义该模型中的数据组织，并定义对该数据的约束。一旦发布，YANG模块就充当客户机和服务器之间的契约，双方都了解对方期望他们的行为。客户机知道如何为服务器创建有效数据，并知道将从服务器发送哪些数据。服务器知道管理数据的规则及其行为方式。
YANG also incorporates a level of extensibility and flexibility not present in other model languages. New modules can augment the data hierarchies defined in other modules, seamlessly adding data at appropriate places in the existing data organization. YANG also allows new statements to be defined, allowing the language itself to be expanded in a consistent way.
YANG还具有其他模型语言所不具备的可扩展性和灵活性。新模块可以扩展其他模块中定义的数据层次结构，在现有数据组织中的适当位置无缝添加数据。杨还允许定义新的语句，允许以一致的方式扩展语言本身。
This document presents an architecture for YANG, describing how YANG-related technologies work and how solutions built on them can address the network management problem domain.
本文档介绍了YANG的体系结构，描述了YANG相关技术的工作原理以及基于这些技术构建的解决方案如何解决网络管理领域的问题。
NETCONF defines an XML-based remote procedure call (RPC) mechanism that leverages the simplicity and availability of high-quality XML parsers. XML gives a rich, flexible, hierarchical, standard representation of data that matches the needs of networking devices. NETCONF carries configuration data and operations as requests and replies using RPCs encoded in XML over a connection-oriented transport.
NETCONF定义了一种基于XML的远程过程调用（RPC）机制，该机制利用了高质量XML解析器的简单性和可用性。XML提供了一种丰富、灵活、分层、标准的数据表示形式，符合网络设备的需要。NETCONF使用XML编码的RPC通过面向连接的传输将配置数据和操作作为请求和响应进行传输。
XML's hierarchical data representation allows complex networking data to be rendered in a natural way. For example, the following configuration places interfaces in OSPF areas. The <ospf> element contains a list of <area> elements, each of which contain a list of <interface> elements. The <name> element identifies the specific area or interface. Additional configuration for each area or interface appears directly inside the appropriate element.
XML的分层数据表示允许以自然的方式呈现复杂的网络数据。例如，以下配置将接口放置在OSPF区域中。<ospf>元素包含<area>元素的列表，每个元素都包含<interface>元素的列表。<name>元素标识特定区域或接口。每个区域或接口的附加配置直接显示在相应的元素中。
<ospf xmlns="http://example.org/netconf/ospf">
<ospf xmlns="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<!-- The priority for this interface -->
<priority>30</priority>
<metric>100</metric>
<dead-interval>120</dead-interval>
</interface>
<interface>
<name>ge-0/0/0.0</name>
<!-- The priority for this interface -->
<priority>30</priority>
<metric>100</metric>
<dead-interval>120</dead-interval>
</interface>
<interface>
<name>ge-0/0/1.0</name>
<metric>140</metric>
</interface>
</area>
<interface>
<name>ge-0/0/1.0</name>
<metric>140</metric>
</interface>
</area>
<area>
<name>10.1.2.0</name>
<area>
<name>10.1.2.0</name>
<interface>
<name>ge-0/0/2.0</name>
<metric>100</metric>
</interface>
<interface>
<name>ge-0/0/2.0</name>
<metric>100</metric>
</interface>
<interface>
<name>ge-0/0/3.0</name>
<metric>140</metric>
<dead-interval>120</dead-interval>
</interface>
</area>
</ospf>
<interface>
<name>ge-0/0/3.0</name>
<metric>140</metric>
<dead-interval>120</dead-interval>
</interface>
</area>
</ospf>
NETCONF includes mechanisms for controlling configuration datastores. Each datastore is a specific collection of configuration data that can be used as source or target of the configuration-related operations. The device can indicate whether it has a distinct "startup" configuration datastore, whether the current or "running"
NETCONF包括用于控制配置数据存储的机制。每个数据存储都是特定的配置数据集合，可以用作配置相关操作的源或目标。设备可以指示其是否具有独特的“启动”配置数据存储，是当前的还是“正在运行的”
datastore is directly writable, or whether there is a "candidate" configuration datastore where configuration changes can be made that will not affect the device until a "commit-configuration" operation is invoked.
数据存储是可直接写入的，或者是否存在“候选”配置数据存储，在该数据存储中可以进行配置更改，这些更改在调用“提交配置”操作之前不会影响设备。
NETCONF defines operations that are invoked as RPCs from the client (the application) to the server (running on the device). The following table lists some of these operations:
NETCONF定义了作为RPC从客户端（应用程序）调用到服务器（在设备上运行）的操作。下表列出了其中一些操作：
+---------------+---------------------------------------------------+
| Operation | Description |
+---------------+---------------------------------------------------+
| commit | Commit the "candidate" configuration to "running" |
| copy-config | Copy one configuration datastore to another |
| delete-config | Delete a configuration datastore |
| edit-config | Change the contents of a configuration datastore |
| get-config | Retrieve all or part of a configuration datastore |
| lock | Prevent changes to a datastore from another party |
| unlock | Release a lock on a datastore |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Operation | Description |
+---------------+---------------------------------------------------+
| commit | Commit the "candidate" configuration to "running" |
| copy-config | Copy one configuration datastore to another |
| delete-config | Delete a configuration datastore |
| edit-config | Change the contents of a configuration datastore |
| get-config | Retrieve all or part of a configuration datastore |
| lock | Prevent changes to a datastore from another party |
| unlock | Release a lock on a datastore |
+---------------+---------------------------------------------------+
NETCONF's "capability" mechanism allows the device to announce the set of capabilities that the device supports, including protocol operations, datastores, data models, and other abilities. These are announced during session establishment as part of the <hello> message. A client can inspect the hello message to determine what the device is capable of and how to interact with the device to perform the desired tasks.
NETCONF的“能力”机制允许设备宣布设备支持的能力集，包括协议操作、数据存储、数据模型和其他能力。这些消息在会话建立期间作为<hello>消息的一部分发布。客户机可以检查hello消息，以确定设备的功能以及如何与设备交互以执行所需任务。
NETCONF also defines a means of sending asynchronous notifications from the server to the client, described in [RFC5277].
NETCONF还定义了一种从服务器向客户端发送异步通知的方法，如[RFC5277]所述。
In addition, NETCONF can fetch state data, receive notifications, and invoke additional RPC methods defined as part of a capability. Complete information about NETCONF can be found in [RFC4741].
此外，NETCONF可以获取状态数据、接收通知并调用作为功能一部分定义的其他RPC方法。有关NETCONF的完整信息可在[RFC4741]中找到。
NETCONF can run over any transport protocol that meets the requirements defined in RFC 4741, including
NETCONF可以在满足RFC 4741中定义的要求的任何传输协议上运行，包括
o connection-oriented operation
o 面向连接的操作
o authentication
o 认证
o integrity
o 诚实正直
o confidentiality
o 保密性
[RFC4742] defines a mapping for the Secure Shell (SSH) [RFC4251] protocol, which is the mandatory transport protocol. Others include SOAP [RFC4743], the Blocks Extensible Exchange Protocol (BEEP) [RFC4744], and Transport Layer Security (TLS) [RFC5539].
[RFC4742]定义了安全Shell（SSH）[RFC4251]协议的映射，该协议是强制传输协议。其他包括SOAP[RFC4743]、块可扩展交换协议（BEEP）[RFC4744]和传输层安全性（TLS）[RFC5539]。
YANG is a data modeling language for NETCONF. It allows the description of hierarchies of data nodes ("nodes") and the constraints that exist among them. YANG defines data models and how to manipulate those models via NETCONF protocol operations.
YANG是NETCONF的数据建模语言。它允许描述数据节点（“节点”）的层次结构以及它们之间存在的约束。YANG定义了数据模型以及如何通过NETCONF协议操作操作这些模型。
Each YANG module defines a data model, uniquely identified by a namespace URI. These data models are extensible in a manner that allows tight integration of standard data models and proprietary data models. Models are built from organizational containers, lists of data nodes, and data-node-forming leafs of the data tree.
每个模块定义一个数据模型，由名称空间URI唯一标识。这些数据模型以允许标准数据模型和专有数据模型紧密集成的方式进行扩展。模型由组织容器、数据节点列表和构成数据树叶子的数据节点构建。
module example-ospf {
namespace "http://example.org/netconf/ospf";
prefix ospf;
module example-ospf {
namespace "http://example.org/netconf/ospf";
prefix ospf;
import network-types { // Access another module's def'ns
prefix nett;
}
import network-types { // Access another module's def'ns
prefix nett;
}
container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint8; // The type is a constraint on
// valid values for "priority".
}
leaf metric {
type uint16 {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint16 {
range 1..65535;
}
}
}
}
}
}
container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint8; // The type is a constraint on
// valid values for "priority".
}
leaf metric {
type uint16 {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint16 {
range 1..65535;
}
}
}
}
}
}
A YANG module defines a data model in terms of the data, its hierarchical organization, and the constraints on that data. YANG defines how this data is represented in XML and how that data is used in NETCONF operations.
YANG模块根据数据、其层次结构和对该数据的约束定义数据模型。YANG定义了如何用XML表示这些数据，以及如何在NETCONF操作中使用这些数据。
The following table briefly describes some common YANG statements:
下表简要介绍了一些常见的杨陈述：
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| augment | Extends existing data hierarchies |
| choice | Defines mutually exclusive alternatives |
| container | Defines a layer of the data hierarchy |
| extension | Allows new statements to be added to YANG |
| feature | Indicates parts of the model that are optional |
| grouping | Groups data definitions into reusable sets |
| key | Defines the key leafs for lists |
| leaf | Defines a leaf node in the data hierarchy |
| leaf-list | A leaf node that can appear multiple times |
| list | A hierarchy that can appear multiple times |
| notification | Defines notification |
| rpc | Defines input and output parameters for an RPC |
| | operation |
| typedef | Defines a new type |
| uses | Incorporates the contents of a "grouping" |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| augment | Extends existing data hierarchies |
| choice | Defines mutually exclusive alternatives |
| container | Defines a layer of the data hierarchy |
| extension | Allows new statements to be added to YANG |
| feature | Indicates parts of the model that are optional |
| grouping | Groups data definitions into reusable sets |
| key | Defines the key leafs for lists |
| leaf | Defines a leaf node in the data hierarchy |
| leaf-list | A leaf node that can appear multiple times |
| list | A hierarchy that can appear multiple times |
| notification | Defines notification |
| rpc | Defines input and output parameters for an RPC |
| | operation |
| typedef | Defines a new type |
| uses | Incorporates the contents of a "grouping" |
+--------------+----------------------------------------------------+
YANG allows the modeler to add constraints to the data model to prevent impossible or illogical data. These constraints give clients information about the data being sent from the device, and also allow the client to know as much as possible about the data the device will accept, so the client can send correct data. These constraints apply to configuration data, but can also be used for rpc and notification data.
YANG允许建模者向数据模型添加约束，以防止不可能或不合逻辑的数据。这些约束为客户端提供有关从设备发送的数据的信息，还允许客户端尽可能多地了解设备将接受的数据，以便客户端可以发送正确的数据。这些约束适用于配置数据，但也可用于rpc和通知数据。
The principal constraint is the "type" statement, which limits the contents of a leaf node to that of the named type. The following table briefly describes some other common YANG constraints:
主要约束是“type”语句，它将叶节点的内容限制为命名类型的内容。下表简要介绍了一些其他常见的限制条件：
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| length | Limits the length of a string |
| mandatory | Requires the node appear |
| max-elements | Limits the number of instances in a list |
| min-elements | Limits the number of instances in a list |
| must | XPath expression must be true |
| pattern | Regular expression must be satisfied |
| range | Value must appear in range |
| reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| length | Limits the length of a string |
| mandatory | Requires the node appear |
| max-elements | Limits the number of instances in a list |
| min-elements | Limits the number of instances in a list |
| must | XPath expression must be true |
| pattern | Regular expression must be satisfied |
| range | Value must appear in range |
| reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+
The "must" and "when" statements use XPath [W3CXPATH] expressions to specify conditions that are semantically evaluated against the data hierarchy, but neither the client nor the server are required to implement the XPath specification. Instead they can use any means to ensure these conditions are met.
“must”和“when”语句使用XPath[W3CXPATH]表达式指定根据数据层次结构进行语义计算的条件，但实现XPath规范不需要客户端和服务器。相反，他们可以使用任何手段来确保满足这些条件。
YANG uses the "union" type and the "choice" and "feature" statements to give modelers flexibility in defining their data models. The "union" type allows a single leaf to accept multiple types, like an integer or the word "unbounded":
YANG使用“union”类型、“choice”和“feature”语句为建模者定义数据模型提供了灵活性。“union”类型允许单个叶接受多个类型，如整数或单词“unbounded”：
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
The "choice" statement lists a set of mutually exclusive nodes, so a valid configuration can choose any one node (or case). The "feature" statement allows the modeler to identify parts of the model that can be optional, and allows the device to indicate whether it implements these optional portions.
“choice”语句列出了一组互斥节点，因此有效配置可以选择任何一个节点（或案例）。“feature”语句允许建模者识别模型中可供选择的部分，并允许设备指示是否实现这些可选部分。
The "deviation" statement allows the device to indicate parts of a YANG module that the device does not faithfully implement. While devices are encouraged to fully abide according to the contract presented in the YANG module, real-world situations may force the device to break the contract. Deviations give a means of declaring this limitation, rather than leaving it to be discovered via run-time errors.
“偏差”语句允许设备指示设备未忠实执行的模块部分。虽然鼓励设备完全遵守YANG模块中的合同，但现实情况可能会迫使设备违反合同。偏差提供了一种声明此限制的方法，而不是让它通过运行时错误被发现。
XML includes the concept of namespaces, allowing XML elements from different sources to be combined in the same hierarchy without risking collision. YANG modules define content for specific namespaces, but one module may augment the definition of another module, introducing elements from that module's namespace into the first module's hierarchy.
XML包含名称空间的概念，允许将来自不同来源的XML元素组合到同一层次结构中，而不存在冲突的风险。模块为特定的名称空间定义内容，但一个模块可能会扩展另一个模块的定义，将该模块名称空间中的元素引入到第一个模块的层次结构中。
Since one module can augment another module's definition, hierarchies of definitions are allowed to grow, as definitions from multiple sources are added to the base hierarchy. These augmentations are qualified using the namespace of the source module, helping to avoid issues with name conflicts as the modules change over time.
由于一个模块可以扩展另一个模块的定义，因此定义的层次结构允许增长，因为来自多个源的定义被添加到基本层次结构中。这些扩充是使用源模块的名称空间限定的，有助于避免模块随着时间的推移而发生名称冲突的问题。
For example, if the above OSPF configuration were the standard, a vendor module may augment this with vendor-specific extensions.
例如，如果上述OSPF配置是标准配置，则供应商模块可能会使用特定于供应商的扩展来扩展此配置。
module vendorx-ospf {
namespace "http://vendorx.example.com/ospf";
prefix vendorx;
module vendorx-ospf {
namespace "http://vendorx.example.com/ospf";
prefix vendorx;
import example-ospf {
prefix ospf;
}
import example-ospf {
prefix ospf;
}
augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}
augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}
The <no-neighbor-down-notification> element is then placed in the vendorx namespace:
然后将<no neighbor down notification>元素放置在vendorx命名空间中：
<ospf xmlns="http://example.org/netconf/ospf"
xmlns:vendorx="http://vendorx.example.com/ospf">
<ospf xmlns="http://example.org/netconf/ospf"
xmlns:vendorx="http://vendorx.example.com/ospf">
<area>
<name>0.0.0.0</name>
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
</area>
</ospf>
Augmentations are seamlessly integrated with base modules, allowing them to be fetched, archived, loaded, and deleted within their natural hierarchy. If a client application asks for the configuration for a specific OSPF area, it will receive the sub-hierarchy for that area, complete with any augmented data.
扩展与基本模块无缝集成，允许在其自然层次结构中获取、归档、加载和删除它们。如果客户机应用程序请求特定OSPF区域的配置，它将收到该区域的子层次结构，以及任何扩展数据。
The YANG data modeling language is the central piece of a group of related technologies. The YANG language itself, described in [RFC6020], defines the syntax of the language and its statements, the meaning of those statements, and how to combine them to build the hierarchy of nodes that describe a data model.
YANG数据建模语言是一组相关技术的核心部分。[RFC6020]中描述的YANG语言本身定义了语言及其语句的语法、这些语句的含义，以及如何将它们结合起来以构建描述数据模型的节点层次结构。
That document also defines the "on the wire" XML content for NETCONF operations on data models defined in YANG modules. This includes the basic mapping between YANG data tree nodes and XML elements, as well as mechanisms used in <edit-config> content to manipulate that data, such as arranging the order of nodes within a list.
该文档还为模块中定义的数据模型上的NETCONF操作定义了“在线”XML内容。这包括数据树节点和XML元素之间的基本映射，以及<edit config>内容中用于操作该数据的机制，例如在列表中排列节点顺序。
YANG uses a syntax that is regular and easily described, primarily designed for human readability. YANG's syntax is friendly to email, diff, patch, and the constraints of RFC formatting.
YANG使用了一种规则且易于描述的语法，主要是为人类可读性而设计的。YANG的语法对电子邮件、diff、patch和RFC格式的约束都很友好。
In some environments, incorporating a YANG parser may not be an acceptable option. For those scenarios, an XML grammar for YANG is defined as YIN (YANG Independent Notation). YIN allows the use of XML parsers that are readily available in both open source and commercial versions. Conversion between YANG and YIN is direct, loss-less, and reversible. YANG statements are converted to XML elements, preserving the structure and content of YANG, but enabling
在某些环境中，合并YANG解析器可能不是一个可接受的选项。对于这些场景，YANG的XML语法被定义为YIN（独立于YANG的表示法）。YIN允许使用XML解析器，这些解析器在开源和商业版本中都很容易获得。阳和阴之间的转换是直接的，损失少，可逆的。YANG语句被转换为XML元素，保留了YANG的结构和内容，但支持
the use of off-the-shelf XML parsers rather than requiring the integration of a YANG parser. YIN maintains complete semantic equivalence with YANG.
使用现成的XML解析器，而不需要集成XML解析器。阴与阳保持着完全的语义对等。
Since NETCONF content is encoded in XML, it is natural to use XML schema languages for their validation. To facilitate this, YANG offers a standardized mapping of YANG modules into Document Schema Definition Languages [RFC6110], of which RELAX NG is a major component.
由于NETCONF内容是用XML编码的，因此使用XML模式语言进行验证是很自然的。为了实现这一点，YANG提供了YANG模块到文档模式定义语言[RFC6110]的标准化映射，RELAXNG是其中的一个主要组件。
DSDL is considered to be the best choice as a standard schema language because it addresses not only grammar and datatypes of XML documents but also semantic constraints and rules for modifying the information set of the document.
DSDL被认为是作为标准模式语言的最佳选择，因为它不仅处理XML文档的语法和数据类型，而且还处理用于修改文档信息集的语义约束和规则。
In addition, DSDL offers formal means for coordinating multiple independent schemas and specifying how to apply the schemas to the various parts of the document. This is useful since YANG content is typically composed of multiple vocabularies.
此外，DSDL提供了协调多个独立模式并指定如何将模式应用于文档的各个部分的正式方法。这很有用，因为内容通常由多个词汇组成。
YANG supports a number of builtin types, and allows additional types to be derived from those types in an extensible manner. New types can add additional restrictions to allowable data values.
YANG支持许多内置类型，并允许以可扩展的方式从这些类型派生其他类型。新类型可以为允许的数据值添加其他限制。
A standard type library for use by YANG is available [RFC6021]. These YANG modules define commonly used data types for IETF-related standards.
YANG使用的标准类型库可用[RFC6021]。这些模块定义了IETF相关标准的常用数据类型。
A set of additional guidelines is defined that indicate desirable usage for authors and reviewers of Standards-Track specifications containing YANG data model modules [RFC6087]. These guidelines should be used as a basis for reviews of other YANG data model documents.
定义了一套附加指南，用于说明标准跟踪规范（包含数据模型模块[RFC6087]）的作者和评审人员的理想用途。这些指南应作为审查其他YANG数据模型文件的基础。
In the typical YANG-based solution, the client and server are driven by the content of YANG modules. The server includes the definitions of the modules as meta-data that is available to the NETCONF engine. This engine processes incoming requests, uses the meta-data to parse
在典型的基于YANG的解决方案中，客户端和服务器由YANG模块的内容驱动。服务器将模块的定义作为元数据包含在NETCONF引擎中。这个引擎处理传入的请求，使用元数据进行解析
and verify the request, performs the requested operation, and returns the results to the client.
和验证请求，执行请求的操作，并将结果返回给客户端。
+----------------------------+
|Server (device) |
| +--------------------+ |
| | configuration | |
+----+ | | ---------------| |
|YANG|+ | | m d state data | |
|mods||+ | | e a ---------------| |
+----+|| -----> | t t notifications | |
+----+| | | a a ---------------| |
+----+ | | operations | |
| +--------------------+ |
| ^ |
| | |
| v |
+------+ | +-------------+ |
| | -------------> | | |
|Client| <rpc> | | NETCONF | |
| (app)| | | engine | |
| | <------------ | | |
+------+ <rpc-reply> +-------------+ |
| / \ |
| / \ |
| / \ |
| +--------+ +---------+ |
| | config | |system |+ |
| | data- | |software ||+ |
| | base | |component||| |
| +--------+ +---------+|| |
| +---------+| |
| +---------+ |
+----------------------------+
+----------------------------+
|Server (device) |
| +--------------------+ |
| | configuration | |
+----+ | | ---------------| |
|YANG|+ | | m d state data | |
|mods||+ | | e a ---------------| |
+----+|| -----> | t t notifications | |
+----+| | | a a ---------------| |
+----+ | | operations | |
| +--------------------+ |
| ^ |
| | |
| v |
+------+ | +-------------+ |
| | -------------> | | |
|Client| <rpc> | | NETCONF | |
| (app)| | | engine | |
| | <------------ | | |
+------+ <rpc-reply> +-------------+ |
| / \ |
| / \ |
| / \ |
| +--------+ +---------+ |
| | config | |system |+ |
| | data- | |software ||+ |
| | base | |component||| |
| +--------+ +---------+|| |
| +---------+| |
| +---------+ |
+----------------------------+
To use YANG, YANG modules must be defined to model the specific problem domain. These modules are then loaded, compiled, or coded into the server.
要使用YANG，必须定义YANG模块以对特定问题域建模。然后将这些模块加载、编译或编码到服务器中。
The sequence of events for the typical client/server interaction may be as follows:
典型客户机/服务器交互的事件顺序可能如下所示：
o A client application ([C]) opens a NETCONF session to the server (device) ([S])
o 客户端应用程序（[C]）打开到服务器（设备）（[S]）的NETCONF会话
o [C] and [S] exchange <hello> messages containing the list of capabilities supported by each side, allowing [C] to learn the modules supported by [S]
o [C] 和[S]交换<hello>消息，其中包含各方支持的功能列表，允许[C]学习[S]支持的模块
o [C] builds and sends an operation defined in the YANG module, encoded in XML, within NETCONF's <rpc> element
o [C] 在NETCONF的<rpc>元素中构建并发送在模块中定义的操作，该操作用XML编码
o [S] receives and parses the <rpc> element
o [S] 接收并解析<rpc>元素
o [S] verifies the contents of the request against the data model defined in the YANG module
o [S] 根据模块中定义的数据模型验证请求的内容
o [S] performs the requested operation, possibly changing the configuration datastore
o [S] 执行请求的操作，可能会更改配置数据存储
o [S] builds the response, containing the response, any requested data, and any errors
o [S] 生成响应，其中包含响应、任何请求的数据和任何错误
o [S] sends the response, encoded in XML, within NETCONF's <rpc-reply> element
o [S] 在NETCONF的<rpc reply>元素中发送以XML编码的响应
o [C] receives and parses the <rpc-reply> element
o [C] 接收并解析<rpc reply>元素
o [C] inspects the response and processes it as needed
o [C] 检查响应并根据需要进行处理
Note that there is no requirement for the client or server to process the YANG modules in this way. The server may hard code the contents of the data model, rather than handle the content via a generic engine. Or the client may be targeted at the specific YANG model, rather than being driven generically. Such a client might be a simple shell script that stuffs arguments into an XML payload template and sends it to the server.
请注意，客户机或服务器不需要以这种方式处理模块。服务器可以硬编码数据模型的内容，而不是通过通用引擎处理内容。或者，客户可能针对特定的YANG模型，而不是一般的驱动。这样的客户机可能是一个简单的shell脚本，它将参数填充到XML有效负载模板中并将其发送到服务器。
NETCONF and YANG address many of the issues raised in the IAB NM workshop.
NETCONF和YANG解决了IAB NM研讨会中提出的许多问题。
o Ease of use: YANG is designed to be human friendly, simple, and readable. Many tricky issues remain due to the complexity of the problem domain, but YANG strives to make them more visible and easier to deal with.
o 易用性：YANG设计为人性化、简单易读。由于问题领域的复杂性，许多棘手的问题仍然存在，但杨努力使这些问题更加明显，更容易处理。
o Configuration and state data: YANG clearly divides configuration data from other types of data.
o 配置和状态数据：YANG清楚地将配置数据与其他类型的数据区分开来。
o Transactions: NETCONF provides a simple transaction mechanism.
o 事务：NETCONF提供了一个简单的事务机制。
o Generation of deltas: A YANG module gives enough information to generate the delta needed to change between two configuration data sets.
o 增量的生成：YANG模块提供足够的信息来生成在两个配置数据集之间更改所需的增量。
o Dump and restore: NETCONF gives the ability to save and restore configuration data. This can also be performed for a specific YANG module.
o 转储和恢复：NETCONF提供了保存和恢复配置数据的功能。这也可以针对特定模块执行。
o Network-wide configuration: NETCONF supports robust network-wide configuration transactions via the commit and confirmed-commit capabilities. When a change is attempted that affects multiple devices, these capabilities simplify the management of failure scenarios, resulting in the ability to have transactions that will dependably succeed or fail atomically.
o 网络范围配置：NETCONF通过提交和确认提交功能支持健壮的网络范围配置事务。当试图进行影响多个设备的更改时，这些功能简化了故障场景的管理，从而使事务能够可靠地在原子上成功或失败。
o Text-friendly: YANG modules are very text friendly, as is the data they define.
o 文本友好：模块非常文本友好，它们定义的数据也是如此。
o Configuration handling: NETCONF addresses the ability to distinguish between distributing configuration data and activating it.
o 配置处理：NETCONF解决了区分分发配置数据和激活配置数据的能力。
o Task-oriented: A YANG module can define specific tasks as RPC operations. A client can choose to invoke the RPC operation or to access any underlying data directly.
o 面向任务：模块可以将特定任务定义为RPC操作。客户端可以选择调用RPC操作或直接访问任何底层数据。
o Full coverage: YANG modules can be defined that give full coverage to all the native abilities of the device. Giving this access avoids the need to resort to the command line interface (CLI) using tools such as Expect [SWEXPECT].
o 全覆盖：可以定义完全覆盖设备所有本机功能的模块。授予此访问权限可以避免使用Expect[SWEXPECT]等工具求助于命令行界面（CLI）。
o Timeliness: YANG modules can be tied to CLI operations, so all native operations and data are immediately available.
o 及时性：模块可以绑定到CLI操作，因此所有本机操作和数据都立即可用。
o Implementation difficulty: YANG's flexibility enables modules that can be more easily implemented. Adding "features" and replacing "third normal form" with a natural data hierarchy should reduce complexity.
o 实现难度：YANG的灵活性使模块更易于实现。添加“特性”并用自然数据层次结构替换“第三范式”应该可以降低复杂性。
o Simple data modeling language: YANG has sufficient power to be usable in other situations. In particular, on-box API and native CLI can be integrated to achieve simplification of the infrastructure.
o 简单数据建模语言：YANG有足够的能力在其他情况下使用。特别是，可以集成on-box API和本机CLI，以简化基础架构。
o Internationalization: YANG uses UTF-8 [RFC3629] encoded Unicode characters.
o 国际化：YANG使用UTF-8[RFC3629]编码的Unicode字符。
o Event correlation: YANG integrates RPC operations, notification, configuration, and state data, enabling internal references. For example, a field in a notification can be tagged as pointing to a BGP peer, and the client application can easily find that peer in the configuration data.
o 事件关联：YANG集成RPC操作、通知、配置和状态数据，从而启用内部引用。例如，通知中的字段可以标记为指向BGP对等方，并且客户端应用程序可以在配置数据中轻松找到该对等方。
o Implementation costs: Significant effort has been made to keep implementation costs as low as possible.
o 实施成本：已作出重大努力，尽可能降低实施成本。
o Human-friendly syntax: YANG's syntax is optimized for the reader, specifically the reviewer on the basis that this is the most common human interaction.
o 人性化语法：YANG的语法针对读者，特别是审稿人进行了优化，因为这是最常见的人机交互。
o Post-processing: Use of XML will maximize the opportunities for post-processing of data, possibly using XML-based technologies like XPath [W3CXPATH], XQuery [W3CXQUERY], and XSLT [W3CXSLT].
o 后处理：使用XML将最大限度地增加数据后处理的机会，可能使用基于XML的技术，如XPath[W3CXPATH]、XQuery[W3CXQUERY]和XSLT[W3CXSLT]。
o Semantic mismatch: Richer, more descriptive data models will reduce the possibility of semantic mismatch. With the ability to define new primitives, YANG modules will be more specific in content, allowing more enforcement of rules and constraints.
o 语义不匹配：更丰富、更具描述性的数据模型将减少语义不匹配的可能性。有了定义新原语的能力，YANG模块的内容将更加具体，允许更多规则和约束的实施。
o Security: NETCONF runs over transport protocols secured by SSH or TLS, allowing secure communications and authentication using well-trusted technology. The secure transport can use existing key and credential management infrastructure, reducing deployment costs.
o 安全性：NETCONF通过SSH或TLS保护的传输协议运行，允许使用可靠的技术进行安全通信和身份验证。安全传输可以使用现有的密钥和凭据管理基础架构，从而降低部署成本。
o Reliable: NETCONF and YANG are solid and reliable technologies. NETCONF is connection based, and includes automatic recovery mechanisms when the connection is lost.
o 可靠：NETCONF和YANG是可靠的技术。NETCONF是基于连接的，并包括连接丢失时的自动恢复机制。
o Delta friendly: YANG-based models support operations that are delta friendly. Add, change, insert, and delete operations are all well defined.
o 三角洲友好型：基于YANG的模型支持三角洲友好型操作。添加、更改、插入和删除操作都有很好的定义。
o Method-oriented: YANG allows new RPC operations to be defined, including an operation name, which is essentially a method. The input and output parameters of the RPC operations are also defined in the YANG module.
o 面向方法：YANG允许定义新的RPC操作，包括操作名，它本质上是一个方法。RPC操作的输入和输出参数也在模块中定义。
Building NETCONF- and YANG-based solutions requires interacting with many distinct groups. Modelers must understand how to build useful models that give structure and meaning to data while maximizing the flexibility of that data to "future proof" their work. Reviewers need to quickly determine if that structure is accurate. Device developers need to code that data model into their devices, and application developers need to code their applications to take advantage of that data model. There are a variety of strategies for performing each piece of this work. This section discusses some of those strategies.
构建基于NETCONF和YANG的解决方案需要与许多不同的组进行交互。建模人员必须了解如何构建有用的模型，为数据提供结构和意义，同时最大限度地提高数据的灵活性，以“证明未来”他们的工作。评审员需要快速确定该结构是否准确。设备开发人员需要将该数据模型编码到他们的设备中，而应用程序开发人员需要编码他们的应用程序以利用该数据模型。执行这项工作的每一部分都有多种策略。本节讨论其中一些策略。
The modeler defines a data model based on their in-depth knowledge of the problem domain being modeled. This model should be as simple as possible, but should balance complexity with expressiveness. The organization of the model not only should target the current model but also should allow for extensibility from other modules and for adaptability to future changes.
建模者根据他们对所建模的问题域的深入了解来定义数据模型。该模型应尽可能简单，但应平衡复杂性和表达能力。模型的组织不仅应以当前模型为目标，还应考虑到其他模块的可扩展性以及对未来变化的适应性。
Additional modeling issues are discussed in Section 4.
第4节讨论了其他建模问题。
The reviewer role is perhaps the most important and the time reviewers are willing to give is precious. To help the reviewer, YANG stresses readability, with a human-friendly syntax, natural data hierarchy, and simple, concise statements.
审稿人的角色也许是最重要的，审稿人愿意付出的时间是宝贵的。为了帮助审稿人，杨强调可读性，使用人性化的语法、自然的数据层次结构和简单简洁的语句。
The YANG model tells the device developer what data is being modeled. The developer reads the YANG models and writes code that supports the model. The model describes the data hierarchy and associated constraints, and the description and reference material helps the developer understand how to transform the model's view into the device's native implementation.
YANG模型告诉设备开发人员正在建模哪些数据。开发人员阅读YANG模型并编写支持该模型的代码。模型描述了数据层次结构和相关约束，描述和参考资料帮助开发人员理解如何将模型视图转换为设备的本机实现。
The YANG model can be compiled into a YANG-based engine for either the client or server side. Incoming data can be validated, as can outgoing data. The complete configuration datastore may be validated in accordance with the constraints described in the data model.
YANG模型可以编译成一个基于YANG的引擎，用于客户端或服务器端。可以验证传入数据，也可以验证传出数据。可以根据数据模型中描述的约束来验证完整的配置数据存储。
Serializers and de-serializers for generating and receiving NETCONF content can be driven by the meta-data in the model. As data is received, the meta-data is consulted to ensure the validity of incoming XML elements.
用于生成和接收NETCONF内容的序列化程序和反序列化程序可以由模型中的元数据驱动。在接收数据时，将参考元数据以确保传入XML元素的有效性。
The YANG module dictates the XML encoding for data sent via NETCONF. The rules that define the encoding are fixed, so the YANG module can be used to ascertain whether a specific NETCONF payload is obeying the rules.
YANG模块为通过NETCONF发送的数据指定XML编码。定义编码的规则是固定的，因此YANG模块可用于确定特定NETCONF负载是否遵守规则。
The YANG module tells the application developer what data can be modeled. Developers can inspect the modules and take one of three distinct views. In this section, we will consider them and the impact of YANG on their design. In the real world, most applications are a mixture of these approaches.
YANG模块告诉应用程序开发人员可以对哪些数据进行建模。开发人员可以检查模块并从三个不同的视图中选择一个。在这一节中，我们将考虑它们以及YANG对其设计的影响。在现实世界中，大多数应用程序都是这些方法的混合体。
An application can be coded against the specific, well-known contents of YANG modules, implementing their organization, rules, and logic directly with explicit knowledge. For example, a script could be written to change the domain name of a set of devices using a standard YANG module that includes such a leaf node. This script takes the new domain name as an argument and inserts it into a string containing the rest of the XML encoding as required by the YANG module. This content is then sent via NETCONF to each of the devices.
应用程序可以根据模块的特定、众所周知的内容进行编码，使用明确的知识直接实现它们的组织、规则和逻辑。例如，可以编写一个脚本，使用包含此类叶节点的标准模块更改一组设备的域名。此脚本将新域名作为参数，并根据模块的要求将其插入包含其余XML编码的字符串中。然后通过NETCONF将此内容发送到每个设备。
This type of application is useful for small, fixed problems where the cost and complexity of flexibility are overwhelmed by the ease of hard coding direct knowledge into the application.
这种类型的应用程序对于小的、固定的问题非常有用，因为在这些问题中，将知识硬编码到应用程序中的难易程度压倒了灵活性的成本和复杂性。
An application may take a generic, bottom-up approach to configuration, concentrating on the device's data directly and treating that data without specific understanding.
应用程序可以采用一种通用的、自底向上的配置方法，直接关注设备的数据，并且在没有特定理解的情况下处理这些数据。
YANG modules may be used to drive the operation of the YANG equivalent of a "MIB browser". Such an application manipulates the device's configuration data based on the data organization contained in the YANG module. For example, a GUI may present a straightforward visualization where elements of the YANG hierarchy are depicted in a hierarchy of folders or GUI panels. Clicking on a line expands to the contents of the matching XML hierarchy.
YANG模块可用于驱动相当于“MIB浏览器”的YANG操作。这样的应用程序基于模块中包含的数据组织来操作设备的配置数据。例如，GUI可以呈现直观的可视化，其中YANG层次结构的元素在文件夹或GUI面板的层次结构中进行描述。单击一行可扩展到匹配的XML层次结构的内容。
This type of GUI can easily be built by generating XSLT stylesheets from the YANG data models. An XSLT engine can then be used to turn configuration data into a set of web pages.
通过从数据模型生成XSLT样式表，可以轻松构建这种类型的GUI。然后可以使用XSLT引擎将配置数据转换为一组网页。
The YANG modules allow the application to enforce a set of constraints without understanding the semantics of the YANG module.
YANG模块允许应用程序在不理解YANG模块语义的情况下强制执行一组约束。
In contrast to the bottom-up approach, the top-down approach allows the application to take a view of the configuration data that is distinct from the standard and/or proprietary YANG modules. The application is free to construct its own model for data organization and to present this model to the user. When the application needs to transmit data to a device, the application transforms its data from the problem-oriented view of the world into the data needed for that particular device. This transformation is under the control and maintenance of the application, allowing the transformation to be changed and updated without affecting the device.
与自下而上的方法不同，自上而下的方法允许应用程序查看不同于标准和/或专有模块的配置数据。应用程序可以自由构建自己的数据组织模型，并向用户展示该模型。当应用程序需要向设备传输数据时，应用程序将其数据从面向问题的世界视图转换为该特定设备所需的数据。此转换由应用程序控制和维护，允许在不影响设备的情况下更改和更新转换。
For example, an application could be written that models VPNs in a network-oriented view. The application would need to transform these high-level VPN definitions into the configuration data that would be handed to any particular device within a VPN.
例如，可以编写一个应用程序，在面向网络的视图中对VPN进行建模。应用程序需要将这些高级VPN定义转换为配置数据，这些配置数据将传递给VPN中的任何特定设备。
Even in this approach, YANG is useful since it can be used to model the VPN. For example, the following VPN straw-man models a list of VPNs, each with a protocol, a topology, a list of member interfaces, and a list of classifiers.
即使在这种方法中，YANG也很有用，因为它可以用来建模VPN。例如，下面的VPN Strowman建模了一个VPN列表，每个VPN都有一个协议、一个拓扑、一个成员接口列表和一个分类器列表。
list example-bgpvpn {
key name;
leaf name { ... }
leaf protocol {
type enumeration {
enum bgpvpn;
enum l2vpn;
}
}
leaf topology {
type enumeration {
enum hub-n-spoke;
enum mesh;
}
}
list members {
key "device interface";
leaf device { ... }
leaf interface { ... }
}
list classifiers {
...
}
}
list example-bgpvpn {
key name;
leaf name { ... }
leaf protocol {
type enumeration {
enum bgpvpn;
enum l2vpn;
}
}
leaf topology {
type enumeration {
enum hub-n-spoke;
enum mesh;
}
}
list members {
key "device interface";
leaf device { ... }
leaf interface { ... }
}
list classifiers {
...
}
}
The application can use such a YANG module to drive its operation, building VPN instances in a database and then pushing the configuration for those VPNs to individual devices either using a standard device model (e.g., example-bgpvpn.yang) or by transforming that standard device content into some proprietary format for devices that do not support that standard.
应用程序可以使用此类模块来驱动其操作，在数据库中构建VPN实例，然后使用标准设备模型（例如bgpvpn.YANG）将这些VPN的配置推送到各个设备或者将标准设备内容转换为不支持该标准的设备的某些专有格式。
This section discusses considerations the modeler should be aware of while developing models in YANG.
本节讨论建模人员在YANG中开发模型时应注意的事项。
The concept of default values is simple, but their details, representation, and interaction with configuration data can be difficult issues. NETCONF leaves default values as a data model issue, and YANG gives flexibility to the device implementation in terms of how default values are handled. The requirement is that the device "MUST operationally behave as if the leaf was present in the data tree with the default value as its value". This gives the device implementation choices in how default values are handled.
默认值的概念很简单，但它们的细节、表示以及与配置数据的交互可能是一个困难的问题。NETCONF将默认值作为数据模型问题，YANG在如何处理默认值方面为设备实现提供了灵活性。要求是设备“必须在操作上表现得像叶子出现在数据树中一样，并以默认值作为其值”。这使设备实现可以选择如何处理默认值。
One choice is to view the configuration as a set of instructions for how the device should be configured. If a data value that is given as part of those instructions is the default value, then it should be retained as part of the configuration, but if it is not explicitly given, then the value is not considered to be part of the configuration.
一种选择是将配置视为设备应如何配置的一组说明。如果作为这些指令的一部分给出的数据值是默认值，则应将其作为配置的一部分保留，但如果未明确给出，则该值不被视为配置的一部分。
Another choice is to trim values that are identical to the default values, implicitly removing them from the configuration datastore. The act of setting a leaf to its default value effectively deletes that leaf.
另一种选择是修剪与默认值相同的值，隐式地将它们从配置数据存储中删除。将叶设置为其默认值的行为会有效地删除该叶。
The device could also choose to report all default values, regardless of whether they were explicitly set. This choice eases the work of a client that needs default values, but may significantly increase the size of the configuration data.
设备也可以选择报告所有默认值，而不管它们是否被显式设置。这种选择简化了需要默认值的客户机的工作，但可能会显著增加配置数据的大小。
These choices reflect the default handling schemes of widely deployed networking devices and supporting them allows YANG to reduce implementation and deployment costs of YANG-based models.
这些选择反映了广泛部署的网络设备的默认处理方案，对它们的支持使YANG能够降低基于YANG的模型的实施和部署成本。
When the client retrieves data from the device, it must be prepared to handle the absence of leaf nodes with the default value, since the server is not required to send such leaf elements. This permits the device to implement either of the first two default handling schemes given above.
当客户端从设备检索数据时，它必须准备好用默认值处理缺少叶节点的情况，因为服务器不需要发送这样的叶元素。这允许设备实现上述前两种默认处理方案中的任意一种。
Regardless of the implementation choice, the device can support the "with-defaults" capability [RFC6243] and give the client the ability to select the desired handling of default values.
无论选择何种实现方式，设备都可以支持“带默认值”功能[RFC6243]，并使客户端能够选择所需的默认值处理。
When evaluating the XPath expressions for constraints like "must" and "when", the evaluation context for the expressions will include any appropriate default values, so the modeler can depend on consistent behavior from all devices.
当评估XPath表达式的约束（如“必须”和“何时”）时，表达式的评估上下文将包括任何适当的默认值，因此建模者可以依赖所有设备的一致行为。
In developing good data models, there are many conflicting interests the data modeler must keep in mind. Modelers need to be aware of five issues with models and devices:
在开发好的数据模型时，数据建模人员必须牢记许多相互冲突的利益。建模人员需要注意模型和设备的五个问题：
o usefulness
o 有用性
o compliance
o 顺从
o flexibility
o 灵活性
o extensibility
o 扩展性
o deviations
o 偏差
For a model to be interesting, it must be useful, solving a problem in a more direct or more powerful way than can be accomplished without the model. The model should maximize the usefulness of the model within the problem domain.
对于一个有趣的模型，它必须是有用的，以一种比没有模型更直接或更强大的方式解决问题。模型应在问题域内最大限度地发挥模型的效用。
Modelers should build models that maximize the number of devices that can faithfully implement the model. If the model is drawn too narrowly, or includes too many assumptions about the device, then the difficulty and cost of accurately implementing the model will lead to low-quality implementations and interoperability issues, and will reduce the value of the model.
建模者应该构建能够最大化能够忠实实现模型的设备数量的模型。如果模型的范围太窄，或者包含了太多关于设备的假设，那么准确实现模型的难度和成本将导致低质量的实现和互操作性问题，并将降低模型的价值。
Modelers can use the "feature" statement in their models to give the device some flexibility by partitioning their model and allowing the device to indicate which portions of the model are implemented on the
建模者可以在他们的模型中使用“feature”语句，通过对他们的模型进行分区并允许设备指示模型的哪些部分是在服务器上实现的，从而为设备提供一些灵活性
device. For example, if the model includes some "logging" feature, a device with no storage facilities for the log can tell the client that it does not support this feature of the model.
装置例如，如果模型包含一些“日志”功能，则没有日志存储设施的设备可以告诉客户端它不支持模型的此功能。
Models can be extended via the "augment" statement, and the modeler should consider how their model is likely to be extended. These augmentations can be defined by vendors, applications, or standards bodies.
模型可以通过“扩充”语句来扩展，建模者应该考虑如何扩展它们的模型。这些扩展可以由供应商、应用程序或标准机构定义。
Deviations are a means of allowing the devices to indicate where its implementation is not in full compliance with the model. For example, once a model is published, an implementer may decide to make a particular node configurable, where the standard model describes it as state data. The implementation reports the value normally and may declare a deviation that this device behaves in a different manner than the standard. Applications capable of discovering this deviation can make allowances, but applications that do not discover the deviation can continue treating the implementation as if it were compliant.
偏差是一种允许设备指示其实施不完全符合模型的方式。例如，模型发布后，实现者可能会决定对特定节点进行配置，其中标准模型将其描述为状态数据。实现正常报告该值，并可能声明该设备的行为方式与标准不同的偏差。能够发现此偏差的应用程序可以考虑，但没有发现偏差的应用程序可以继续将实现视为符合要求。
Rarely, implementations may make decisions that prevent compliance with the standard. Such occasions are regrettable, but they remain a part of reality, and modelers and application writers ignore them at their own risk. An implementation that emits an integer leaf as "cow" would be difficult to manage, but applications should expect to encounter such misbehaving devices in the field.
很少情况下，实现可能会做出阻止遵守标准的决策。这样的情况令人遗憾，但它们仍然是现实的一部分，建模者和应用程序编写者忽视它们的风险自负。以“cow”形式发出整数叶子的实现将很难管理，但应用程序应该会在现场遇到此类行为不端的设备。
Despite this, both client and server should view the YANG module as a contract, with both sides agreeing to abide by the terms. The modeler should be explicit about the terms of such a contract, and both client and server implementations should strive to faithfully and accurately implement the data model described in the YANG module.
尽管如此，客户机和服务器都应将YANG模块视为合同，双方同意遵守条款。建模人员应该明确此类合同的条款，客户机和服务器实现都应该努力忠实准确地实现模块中描述的数据模型。
The distinction between configuration data, operational state data, and statistics is important to understand for data model writers and people who plan to extend the NETCONF protocol. This section first discusses some background and then provides a definition and some examples.
配置数据、操作状态数据和统计数据之间的区别对于数据模型编写者和计划扩展NETCONF协议的人员来说非常重要。本节首先讨论一些背景，然后提供定义和一些示例。
During the IAB NM workshop, operators did formulate the following two requirements, as listed in [RFC3535]:
在IAB NM车间期间，操作员制定了以下两项要求，如[RFC3535]所列：
2. It is necessary to make a clear distinction between configuration data, data that describes operational state, and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols.
2. 必须明确区分配置数据、描述操作状态的数据和统计数据。有些设备很难确定哪些参数是通过管理配置的，哪些是通过其他机制（如路由协议）获得的。
3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices.
3. 它需要能够从设备中分别获取配置数据、操作状态数据和统计数据，并能够在设备之间进行比较。
The NETCONF protocol defined in RFC 4741 distinguishes two types of data -- namely, configuration data and state data:
RFC 4741中定义的NETCONF协议区分两种类型的数据——即配置数据和状态数据：
Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state.
配置数据是将系统从初始默认状态转换为当前状态所需的一组可写数据。
State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics.
状态数据是系统上非配置数据（如只读状态信息和收集的统计数据）的附加数据。
NETCONF does not follow the distinction formulated by the operators between configuration data, operational state data, and statistical data, since it considers state data to include both statistics and operational state data.
NETCONF不遵循操作员在配置数据、运行状态数据和统计数据之间的区别，因为它认为状态数据包括统计数据和运行状态数据。
Below is a definition for configuration data, operational state data, and statistical data. The definition borrows from previous work.
下面是配置数据、运行状态数据和统计数据的定义。这个定义借鉴了以前的工作。
o Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state [RFC4741].
o 配置数据是将系统从初始默认状态转换为当前状态所需的一组可写数据[RFC4741]。
o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols.
o 操作状态数据是系统在运行时获得的一组数据，它影响系统的行为，类似于配置数据。与配置数据不同，操作状态是瞬态的，通过与内部组件或其他系统的交互，通过专用协议进行修改。
o Statistical data is the set of read-only data created by a system itself. It describes the performance of the system and its components.
o 统计数据是由系统本身创建的只读数据集。它描述了系统及其组件的性能。
The following examples help to clarify the difference between configuration data, operational state data, and statistical data.
以下示例有助于澄清配置数据、运行状态数据和统计数据之间的差异。
IP routing tables can contain entries that are statically configured (configuration data) as well as entries obtained from routing protocols such as OSPF (operational state data). In addition, a routing engine might collect statistics like how often a particular routing table entry has been used.
IP路由表可以包含静态配置的条目（配置数据）以及从路由协议（如OSPF）获得的条目（操作状态数据）。此外，路由引擎可能会收集统计信息，如特定路由表项的使用频率。
Network interfaces usually come with a large number of attributes that are specific to the interface type and in some cases specific to the cable plugged into an interface. Examples are the maximum transmission unit of an interface or the speed detected by an Ethernet interface.
网络接口通常具有大量特定于接口类型的属性，在某些情况下，这些属性特定于插入接口的电缆。例如，接口的最大传输单位或以太网接口检测到的速度。
In many deployments, systems use the interface attributes detected when an interface is initialized. As such, these attributes constitute operational state. However, there are usually provisions to overwrite the discovered attributes with static configuration data, like for example configuring the interface MTU to use a specific value or forcing an Ethernet interface to run at a given speed.
在许多部署中，系统使用初始化接口时检测到的接口属性。因此，这些属性构成操作状态。然而，通常有使用静态配置数据覆盖发现的属性的规定，例如配置接口MTU以使用特定值或强制以太网接口以给定速度运行。
The system will record statistics (counters) measuring the number of packets, bytes, and errors received and transmitted on each interface.
系统将记录统计数据（计数器），测量每个接口上接收和传输的数据包数、字节数和错误数。
Systems usually maintain static configuration information about the accounts on the system. In addition, systems can obtain information about accounts from other sources (e.g., Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS)) dynamically, leading to operational state data. Information about account usage is an example of statistical data.
系统通常维护关于系统上帐户的静态配置信息。此外，系统可以从其他来源（例如，轻量级目录访问协议（LDAP）、网络信息服务（NIS））动态获取有关帐户的信息，从而生成操作状态数据。有关帐户使用情况的信息是统计数据的一个示例。
Note that configuration data supplied to a system in order to create a new account might be supplemented with additional configuration information determined by the system when the account is being created (such as a unique account id). Even though the system might create such information, it usually becomes part of the static configuration of the system since this data is not transient.
请注意，为创建新帐户而提供给系统的配置数据可能会在创建帐户时由系统确定的其他配置信息（例如唯一的帐户id）进行补充。即使系统可能会创建这样的信息，它通常也会成为系统静态配置的一部分，因为这些数据不是瞬态的。
The primary focus of YANG is configuration data. There is no single mechanism defined for the separation of operational state data and statistics since NETCONF treats them both as state data. This section describes several different options for addressing this issue.
YANG的主要关注点是配置数据。由于NETCONF将操作状态数据和统计数据都视为状态数据，因此没有为分离操作状态数据和统计数据定义单一的机制。本节介绍了解决此问题的几个不同选项。
The first option is to have data models that explicitly differentiate between configuration data and operational state data. This leads to duplication of data structures and might not scale well from a modeling perspective.
第一种选择是建立明确区分配置数据和运行状态数据的数据模型。这会导致数据结构的重复，并且从建模的角度来看可能无法很好地扩展。
For example, the configured duplex value and the operational duplex value would be distinct leafs in the data model.
例如，在数据模型中，配置的双工值和操作双工值将是不同的LEAF。
The NETCONF protocol can be extended with new protocol operations that specifically allow the retrieval of all operational state, e.g., by introducing a <get-ops> operation (and perhaps also a <get-stats> operation).
NETCONF协议可以通过新的协议操作进行扩展，新的协议操作专门允许检索所有操作状态，例如，通过引入<get ops>操作（以及<get stats>操作）。
Another option could be to introduce a new "configuration" data store that represents the operational state. A <get-config> operation on the <operational> data store would then return the operational state determining the behavior of the box instead of its static and explicit configuration state.
另一个选择是引入一个新的“配置”数据存储，它表示操作状态。然后，<operational>数据存储上的<get config>操作将返回确定框行为的操作状态，而不是其静态和显式配置状态。
At this time, the only viable solution is to distinctly model the configuration and operational values. The configuration leaf would indicate the desired value, as given by the user, and the operational leaf would indicate the current value, as observed on the device.
此时，唯一可行的解决方案是对配置和操作值进行清晰的建模。配置叶将指示用户给定的期望值，操作叶将指示设备上观察到的当前值。
In the duplex example, this would result in two distinct leafs being defined, "duplex" and "op-duplex", one with "config true" and one with "config false".
在双工示例中，这将导致定义两个不同的leaf，“duplex”和“op duplex”，一个是“config true”，另一个是“config false”。
In some cases, distinct leafs would be used, but in others, distinct lists might be used. Distinct lists allows the list to be organized in different ways, with different constraints. Keys, sorting, and constraint statements like must, unique, or when may differ between configuration data and operational data.
在某些情况下，可以使用不同的leaf，但在其他情况下，可以使用不同的列表。不同的列表允许以不同的方式组织列表，并具有不同的约束。键、排序和约束语句（如必须、唯一或何时）可能在配置数据和操作数据之间有所不同。
For example, configured static routes might be a distinct list from the operational routing table, since the use of keys and sorting might differ.
例如，配置的静态路由可能是与操作路由表不同的列表，因为键的使用和排序可能不同。
This document discusses an architecture for network management using NETCONF and YANG. It has no security impact on the Internet.
本文档讨论使用NETCONF和YANG的网络管理体系结构。它对互联网没有安全影响。
[ISODSDL] International Organization for Standardization, "Document Schema Definition Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1, November 2004.
[ISODSDL]国际标准化组织，“文件模式定义语言（DSDL）-第1部分：概述”，ISO/IEC 19757-12004年11月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535]Schoenwaeld，J.，“2002年IAB网络管理研讨会概述”，RFC 3535，2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742]Wasserman，M.和T.Goddard，“在安全外壳（SSH）上使用NETCONF配置协议”，RFC 4742，2006年12月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743]Goddard，T.，“通过简单对象访问协议（SOAP）使用NETCONF”，RFC 4743，2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744]Lear，E.和K.Crozier，“在块可扩展交换协议（BEEP）上使用NETCONF协议”，RFC 47442006年12月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]Chisholm，S.和H.Trevino，“NETCONF事件通知”，RFC 5277，2008年7月。
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5539]Badra，M.，“传输层安全（TLS）上的网络配置”，RFC 5539，2009年5月。
[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月。
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011.
[RFC6087]Bierman，A.，“YANG数据模型文件的作者和评审指南”，RFC 6087，2011年1月。
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, February 2011.
[RFC6110]Lhotka，L.“将YANG映射到文档模式定义语言并验证NETCONF内容”，RFC61102011年2月。
[RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, June 2011.
[RFC6243]Bierman，A.和B.Lengyel，“NETCONF的默认功能”，RFC 62432011年6月。
[SWEXPECT] "The Expect Home Page", <http://expect.sourceforge.net/>.
[SWEXPECT]“Expect主页”<http://expect.sourceforge.net/>.
[W3CXPATH] 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>.
[W3CXPATH]DeRose，S.和J.Clark，“XML路径语言（XPath）1.0版”，万维网联盟建议REC-XPath-19991116，1999年11月<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3CXQUERY] Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD-xquery-20050915, September 2005.
[W3CXQUERY]Boag，S.，“XQuery 1.0:一种XML查询语言”，W3C WD-XQuery-20050915，2005年9月。
[W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[W3CXSD]Walmsley，P.和D.Fallside，“XML模式第0部分：入门第二版”，万维网联盟建议REC-xmlschema-0-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[W3CXSLT]Clark，J.，“XSL转换（XSLT）1.0版”，万维网联盟建议REC-XSLT-19991116，1999年11月<http://www.w3.org/TR/1999/REC-xslt-19991116>.
[RCDML] Presuhn, R., Ed., "Requirements for a Configuration Data Modeling Language", Work in Progress, February 2008.
[RCDML]Presohn，R.，Ed.“配置数据建模语言的要求”，正在进行的工作，2008年2月。
Author's Address
作者地址
Phil Shafer Juniper Networks
Phil Shafer Juniper网络公司
EMail: phil@juniper.net
EMail: phil@juniper.net