Internet Engineering Task Force (IETF) R. Enns, Ed.
Request for Comments: 6241 Juniper Networks
Obsoletes: 4741 M. Bjorklund, Ed.
Category: Standards Track Tail-f Systems
ISSN: 2070-1721 J. Schoenwaelder, Ed.
Jacobs University
A. Bierman, Ed.
Brocade
June 2011
Internet Engineering Task Force (IETF) R. Enns, Ed.
Request for Comments: 6241 Juniper Networks
Obsoletes: 4741 M. Bjorklund, Ed.
Category: Standards Track Tail-f Systems
ISSN: 2070-1721 J. Schoenwaelder, Ed.
Jacobs University
A. Bierman, Ed.
Brocade
June 2011
Network Configuration Protocol (NETCONF)
网络配置协议（NETCONF）
Abstract
摘要
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741.
本文档中定义的网络配置协议（NETCONF）提供了安装、操作和删除网络设备配置的机制。它对配置数据和协议消息使用基于可扩展标记语言（XML）的数据编码。NETCONF协议操作通过远程过程调用（rpc）实现。本文件废除了RFC 4741。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6241.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6241.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Separation of Configuration and State Data . . . . . . . 10
2. Transport Protocol Requirements . . . . . . . . . . . . . . . 11
2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 11
2.2. Authentication, Integrity, and Confidentiality . . . . . 12
2.3. Mandatory Transport Protocol . . . . . . . . . . . . . . 12
3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 13
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Document Type Declarations . . . . . . . . . . . . . . . 13
4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 13
4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 16
4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 19
5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 19
5.1. Configuration Datastores . . . . . . . . . . . . . . . . 19
5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 20
6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 21
6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 21
6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 22
6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 23
6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 23
6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 24
6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 25
6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 26
6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 26
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 27
6.4.4. Select All <name> Elements within the <users>
Subtree . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 30
6.4.6. Specific Elements from a Specific <user> Entry . . . 31
6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 32
6.4.8. Elements with Attribute Naming . . . . . . . . . . . 33
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 35
7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 35
7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 37
7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 43
7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 44
7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Separation of Configuration and State Data . . . . . . . 10
2. Transport Protocol Requirements . . . . . . . . . . . . . . . 11
2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 11
2.2. Authentication, Integrity, and Confidentiality . . . . . 12
2.3. Mandatory Transport Protocol . . . . . . . . . . . . . . 12
3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 13
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Document Type Declarations . . . . . . . . . . . . . . . 13
4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 13
4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 16
4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 19
5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 19
5.1. Configuration Datastores . . . . . . . . . . . . . . . . 19
5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 20
6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 21
6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 21
6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 22
6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 23
6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 23
6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 24
6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 25
6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 26
6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 26
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 27
6.4.4. Select All <name> Elements within the <users>
Subtree . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 30
6.4.6. Specific Elements from a Specific <user> Entry . . . 31
6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 32
6.4.8. Elements with Attribute Naming . . . . . . . . . . . 33
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 35
7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 35
7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 37
7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 43
7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 44
7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 49
7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 50
8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 51
8.2. Writable-Running Capability . . . . . . . . . . . . . . . 53
8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 53
8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 53
8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 53
8.2.5. Modifications to Existing Operations . . . . . . . . 53
8.3. Candidate Configuration Capability . . . . . . . . . . . 53
8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 54
8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 54
8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 54
8.3.5. Modifications to Existing Operations . . . . . . . . 56
8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 57
8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 57
8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 58
8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 58
8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 59
8.4.5. Modifications to Existing Operations . . . . . . . . 60
8.5. Rollback-on-Error Capability . . . . . . . . . . . . . . 61
8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 61
8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 62
8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 62
8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 62
8.5.5. Modifications to Existing Operations . . . . . . . . 62
8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 63
8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 63
8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 63
8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 63
8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 63
8.6.5. Modifications to Existing Operations . . . . . . . . 64
8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 64
8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 64
8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 65
8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 65
8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 65
8.7.5. Modifications to Existing Operations . . . . . . . . 65
8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 66
8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 66
8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 66
8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 66
8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 66
8.8.5. Modifications to Existing Operations . . . . . . . . 66
7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 49
7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 50
8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 51
8.2. Writable-Running Capability . . . . . . . . . . . . . . . 53
8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 53
8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 53
8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 53
8.2.5. Modifications to Existing Operations . . . . . . . . 53
8.3. Candidate Configuration Capability . . . . . . . . . . . 53
8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 53
8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 54
8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 54
8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 54
8.3.5. Modifications to Existing Operations . . . . . . . . 56
8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 57
8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 57
8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 58
8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 58
8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 59
8.4.5. Modifications to Existing Operations . . . . . . . . 60
8.5. Rollback-on-Error Capability . . . . . . . . . . . . . . 61
8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 61
8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 62
8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 62
8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 62
8.5.5. Modifications to Existing Operations . . . . . . . . 62
8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 63
8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 63
8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 63
8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 63
8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 63
8.6.5. Modifications to Existing Operations . . . . . . . . 64
8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 64
8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 64
8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 65
8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 65
8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 65
8.7.5. Modifications to Existing Operations . . . . . . . . 65
8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 66
8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 66
8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 66
8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 66
8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 66
8.8.5. Modifications to Existing Operations . . . . . . . . 66
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 67
8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 67
8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 68
8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 68
8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 68
8.9.5. Modifications to Existing Operations . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 71
10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 71
10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 72
10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 72
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 76
Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 80
Appendix C. YANG Module for NETCONF Protocol Operations . . . . 85
Appendix D. Capability Template . . . . . . . . . . . . . . . . 105
D.1. capability-name (template) . . . . . . . . . . . . . . . 105
D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 105
D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 105
D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 105
D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 105
D.1.5. Modifications to Existing Operations . . . . . . . . 105
D.1.6. Interactions with Other Capabilities . . . . . . . . 105
Appendix E. Configuring Multiple Devices with NETCONF . . . . . 106
E.1. Operations on Individual Devices . . . . . . . . . . . . 106
E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 106
E.1.2. Checkpointing the Running Configuration . . . . . . . 107
E.1.3. Loading and Validating the Incoming Configuration . . 108
E.1.4. Changing the Running Configuration . . . . . . . . . 108
E.1.5. Testing the New Configuration . . . . . . . . . . . . 109
E.1.6. Making the Change Permanent . . . . . . . . . . . . . 109
E.1.7. Releasing the Configuration Lock . . . . . . . . . . 110
E.2. Operations on Multiple Devices . . . . . . . . . . . . . 111
Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 112
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 67
8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 67
8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 68
8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 68
8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 68
8.9.5. Modifications to Existing Operations . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 71
10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 71
10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 72
10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 72
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 73
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 76
Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 80
Appendix C. YANG Module for NETCONF Protocol Operations . . . . 85
Appendix D. Capability Template . . . . . . . . . . . . . . . . 105
D.1. capability-name (template) . . . . . . . . . . . . . . . 105
D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 105
D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 105
D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 105
D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 105
D.1.5. Modifications to Existing Operations . . . . . . . . 105
D.1.6. Interactions with Other Capabilities . . . . . . . . 105
Appendix E. Configuring Multiple Devices with NETCONF . . . . . 106
E.1. Operations on Individual Devices . . . . . . . . . . . . 106
E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 106
E.1.2. Checkpointing the Running Configuration . . . . . . . 107
E.1.3. Loading and Validating the Incoming Configuration . . 108
E.1.4. Changing the Running Configuration . . . . . . . . . 108
E.1.5. Testing the New Configuration . . . . . . . . . . . . 109
E.1.6. Making the Change Permanent . . . . . . . . . . . . . 109
E.1.7. Releasing the Configuration Lock . . . . . . . . . . 110
E.2. Operations on Multiple Devices . . . . . . . . . . . . . 111
Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 112
The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets.
NETCONF协议定义了一种简单的机制，通过该机制可以管理网络设备、检索配置数据信息以及上载和操作新的配置数据。该协议允许设备公开完整、正式的应用程序编程接口（API）。应用程序可以使用这个简单的API发送和接收完整和部分配置数据集。
The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML [W3C.REC-xml-20001006] and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange.
NETCONF协议使用远程过程调用（RPC）范例。客户端用XML[W3C.REC-XML-20001006]对RPC进行编码，并使用安全的、面向连接的会话将其发送到服务器。服务器用XML编码的回复进行响应。请求和响应的内容都用XML DTD或XML模式（或两者）完全描述，允许双方识别施加在交换上的语法约束。
A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native functionality of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface.
NETCONF的一个关键方面是，它允许管理协议的功能紧密镜像设备的本机功能。这降低了实施成本，并允许及时访问新功能。此外，应用程序可以访问设备本机用户界面的语法和语义内容。
NETCONF allows a client to discover the set of protocol extensions supported by a server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. Standard and non-standard capabilities can be defined with semantic and syntactic rigor. Capabilities are discussed in Section 8.
NETCONF允许客户端发现服务器支持的协议扩展集。这些“功能”允许客户端调整其行为，以利用设备公开的功能。能力定义可以以非集中的方式轻松扩展。标准和非标准功能可以通过严格的语义和语法定义。功能在第8节中讨论。
The NETCONF protocol is a building block in a system of automated configuration. XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XML-based transformation technologies, such as XSLT [W3C.REC-xslt-19991116], to provide a system for automated generation of full and partial configurations. The system can query one or more databases for data about networking topologies, links, policies, customers, and services. This data can be transformed using one or more XSLT scripts from a task-oriented, vendor-independent data schema into a form that is specific to the vendor, product, operating system, and software release. The resulting data can be passed to the device using the NETCONF protocol.
NETCONF协议是自动配置系统中的一个构建块。XML是交换的通用语言，为分层内容提供了灵活但完全指定的编码机制。NETCONF可以与基于XML的转换技术（如XSLT[W3C.REC-XSLT-19991116]）配合使用，以提供一个自动生成完整和部分配置的系统。系统可以查询一个或多个数据库中有关网络拓扑、链接、策略、客户和服务的数据。可以使用一个或多个XSLT脚本将这些数据从面向任务、独立于供应商的数据模式转换为特定于供应商、产品、操作系统和软件版本的形式。生成的数据可以使用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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
o candidate configuration datastore: A configuration datastore that can be manipulated without impacting the device's current configuration and that can be committed to the running configuration datastore. Not all devices support a candidate configuration datastore.
o 候选配置数据存储：可以在不影响设备当前配置的情况下操作的配置数据存储，并且可以提交到正在运行的配置数据存储。并非所有设备都支持候选配置数据存储。
o capability: A functionality that supplements the base NETCONF specification.
o 功能：补充基本NETCONF规范的功能。
o client: Invokes protocol operations on a server. In addition, a client can subscribe to receive notifications from a server.
o 客户端：调用服务器上的协议操作。此外，客户端可以订阅以接收来自服务器的通知。
o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state.
o 配置数据：将系统从初始默认状态转换为当前状态所需的一组可写数据。
o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof.
o 数据存储：存储和访问信息的概念性场所。例如，可以使用文件、数据库、闪存位置或其组合来实现数据存储。
o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state.
o 配置数据存储：保存将设备从初始默认状态转换为所需操作状态所需的完整配置数据集的数据存储。
o message: A protocol element sent over a session. Messages are well-formed XML documents.
o 消息：通过会话发送的协议元素。消息是格式良好的XML文档。
o notification: A server-initiated message indicating that a certain event has been recognized by the server.
o 通知：服务器启动的消息，指示服务器已识别某个事件。
o protocol operation: A specific remote procedure call, as used within the NETCONF protocol.
o 协议操作：在NETCONF协议中使用的特定远程过程调用。
o remote procedure call (RPC): Realized by exchanging <rpc> and <rpc-reply> messages.
o 远程过程调用（RPC）：通过交换<RPC>和<RPC reply>消息来实现。
o running configuration datastore: A configuration datastore holding the complete configuration currently active on the device. The running configuration datastore always exists.
o 运行配置数据存储：保存设备上当前活动的完整配置的配置数据存储。正在运行的配置数据存储始终存在。
o server: Executes protocol operations invoked by a client. In addition, a server can send notifications to a client.
o 服务器：执行客户端调用的协议操作。此外，服务器可以向客户端发送通知。
o session: Client and server exchange messages using a secure, connection-oriented session.
o 会话：客户端和服务器使用安全的、面向连接的会话交换消息。
o startup configuration datastore: The configuration datastore holding the configuration loaded by the device when it boots. Only present on devices that separate the startup configuration datastore from the running configuration datastore.
o 启动配置数据存储：配置数据存储，保存设备启动时加载的配置。仅存在于将启动配置数据存储区与运行配置数据存储区分开的设备上。
o state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics.
o 状态数据：系统上非配置数据的附加数据，如只读状态信息和收集的统计数据。
o user: The authenticated identity of the client. The authenticated identity of a client is commonly referred to as the NETCONF username.
o 用户：客户端的经过身份验证的标识。客户机的身份验证通常称为NETCONF用户名。
NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server. The client can be a script or application typically running as part of a network manager. The server is typically a network device. The terms "device" and "server" are used interchangeably in this document, as are "client" and "application".
NETCONF使用一种简单的基于RPC的机制来促进客户端和服务器之间的通信。客户端可以是脚本或应用程序，通常作为网络管理器的一部分运行。服务器通常是一个网络设备。术语“设备”和“服务器”在本文档中互换使用，“客户端”和“应用程序”也是如此。
A NETCONF session is the logical connection between a network administrator or network configuration application and a network device. A device MUST support at least one NETCONF session and SHOULD support multiple sessions. Global configuration attributes can be changed during any authorized session, and the effects are visible in all sessions. Session-specific attributes affect only the session in which they are changed.
NETCONF会话是网络管理员或网络配置应用程序与网络设备之间的逻辑连接。设备必须至少支持一个NETCONF会话，并且应支持多个会话。全局配置属性可以在任何授权会话期间更改，并且效果在所有会话中都可见。特定于会话的属性仅影响更改它们的会话。
NETCONF can be conceptually partitioned into four layers as shown in Figure 1.
NETCONF可以在概念上划分为四个层，如图1所示。
Layer Example
+-------------+ +-----------------+ +----------------+
(4) | Content | | Configuration | | Notification |
| | | data | | data |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------+ |
(3) | Operations | | <edit-config> | |
| | | | |
+-------------+ +-----------------+ |
| | |
+-------------+ +-----------------+ +----------------+
(2) | Messages | | <rpc>, | | <notification> |
| | | <rpc-reply> | | |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------------------------------+
(1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
| Transport | | |
+-------------+ +-----------------------------------------+
Layer Example
+-------------+ +-----------------+ +----------------+
(4) | Content | | Configuration | | Notification |
| | | data | | data |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------+ |
(3) | Operations | | <edit-config> | |
| | | | |
+-------------+ +-----------------+ |
| | |
+-------------+ +-----------------+ +----------------+
(2) | Messages | | <rpc>, | | <notification> |
| | | <rpc-reply> | | |
+-------------+ +-----------------+ +----------------+
| | |
+-------------+ +-----------------------------------------+
(1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
| Transport | | |
+-------------+ +-----------------------------------------+
Figure 1: NETCONF Protocol Layers
图1:NETCONF协议层
(1) The Secure Transport layer provides a communication path between the client and server. NETCONF can be layered over any transport protocol that provides a set of basic requirements. Section 2 discusses these requirements.
(1) 安全传输层提供客户端和服务器之间的通信路径。NETCONF可以在提供一组基本需求的任何传输协议上分层。第2节讨论了这些要求。
(2) The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications. Section 4 documents the RPC messages, and [RFC5717] documents notifications.
(2) 消息层为编码RPC和通知提供了一种简单的、独立于传输的帧机制。第4节记录RPC消息，[RFC5717]记录通知。
(3) The Operations layer defines a set of base protocol operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base protocol operations.
(3) 操作层定义了一组基本协议操作，这些操作作为带有XML编码参数的RPC方法调用。第7节详细介绍了基本协议操作列表。
(4) The Content layer is outside the scope of this document. It is expected that separate efforts to standardize NETCONF data models will be undertaken.
(4) 内容层不在本文档的范围内。预计将单独努力使NETCONF数据模型标准化。
The YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations, covering the Operations and the Content layers of Figure 1.
YANG数据建模语言[RFC6020]用于指定NETCONF数据模型和协议操作，涵盖了图1中的操作和内容层。
A NETCONF capability is a set of functionality that supplements the base NETCONF specification. The capability is identified by a uniform resource identifier (URI) [RFC3986].
NETCONF功能是一组补充基本NETCONF规范的功能。该能力由统一资源标识符（URI）[RFC3986]标识。
Capabilities augment the base operations of the device, describing both additional operations and the content allowed inside operations. The client can discover the server's capabilities and use any additional operations, parameters, and content defined by those capabilities.
功能增强了设备的基本操作，描述了附加操作和操作中允许的内容。客户端可以发现服务器的功能，并使用这些功能定义的任何其他操作、参数和内容。
The capability definition might name one or more dependent capabilities. To support a capability, the server MUST support any capabilities upon which it depends.
功能定义可以命名一个或多个相关功能。要支持某项功能，服务器必须支持它所依赖的任何功能。
Section 8 defines the capabilities exchange that allows the client to discover the server's capabilities. Section 8 also lists the set of capabilities defined in this document.
第8节定义了允许客户端发现服务器功能的功能交换。第8节还列出了本文件中定义的一组功能。
Additional capabilities can be defined at any time in external documents, allowing the set of capabilities to expand over time. Standards bodies can define standardized capabilities, and implementations can define proprietary ones. A capability URI MUST sufficiently distinguish the naming authority to avoid naming collisions.
可以随时在外部文档中定义其他功能，从而允许功能集随时间扩展。标准机构可以定义标准化功能，实现可以定义专有功能。功能URI必须充分区分命名机构，以避免命名冲突。
The information that can be retrieved from a running system is separated into two classes, configuration data and state data. 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. When a device is performing configuration operations, a number of problems would arise if state data were included:
可以从正在运行的系统中检索的信息分为两类：配置数据和状态数据。配置数据是将系统从初始默认状态转换为当前状态所需的一组可写数据。状态数据是系统上非配置数据（如只读状态信息和收集的统计数据）的附加数据。当设备执行配置操作时，如果包含状态数据，则会出现许多问题：
o Comparisons of configuration data sets would be dominated by irrelevant entries such as different statistics.
o 配置数据集的比较主要是不相关的条目，如不同的统计数据。
o Incoming data could contain nonsensical requests, such as attempts to write read-only data.
o 传入数据可能包含无意义的请求，例如试图写入只读数据。
o The data sets would be large.
o 数据集将会很大。
o Archived data could contain values for read-only data items, complicating the processing required to restore archived data.
o 归档数据可能包含只读数据项的值，从而使恢复归档数据所需的处理复杂化。
To account for these issues, the NETCONF protocol recognizes the difference between configuration data and state data and provides operations for each. The <get-config> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data.
为了解决这些问题，NETCONF协议识别配置数据和状态数据之间的差异，并为每种数据提供操作。<get config>操作仅检索配置数据，而<get>操作检索配置和状态数据。
Note that the NETCONF protocol is focused on the information required to get the device into its desired running state. The inclusion of other important, persistent data is implementation specific. For example, user files and databases are not treated as configuration data by the NETCONF protocol.
请注意，NETCONF协议主要关注使设备进入所需运行状态所需的信息。包含其他重要的持久性数据是特定于实现的。例如，NETCONF协议不将用户文件和数据库视为配置数据。
For example, if a local database of user authentication data is stored on the device, it is an implementation-dependent matter whether it is included in configuration data.
例如，如果用户认证数据的本地数据库存储在设备上，则其是否包括在配置数据中取决于实现。
NETCONF uses an RPC-based communication paradigm. A client sends a series of one or more RPC request messages, which cause the server to respond with a corresponding series of RPC reply messages.
NETCONF使用基于RPC的通信范例。客户端发送一系列的一个或多个RPC请求消息，这会导致服务器使用相应的一系列RPC回复消息进行响应。
The NETCONF protocol can be layered on any transport protocol that provides the required set of functionality. It is not bound to any particular transport protocol, but allows a mapping to define how it can be implemented over any specific protocol.
NETCONF协议可以在提供所需功能集的任何传输协议上分层。它不绑定到任何特定的传输协议，但允许映射定义如何在任何特定协议上实现它。
The transport protocol MUST provide a mechanism to indicate the session type (client or server) to the NETCONF protocol layer.
传输协议必须提供向NETCONF协议层指示会话类型（客户端或服务器）的机制。
This section details the characteristics that NETCONF requires from the underlying transport protocol.
本节详细介绍了NETCONF对底层传输协议的要求。
NETCONF is connection-oriented, requiring a persistent connection between peers. This connection MUST provide reliable, sequenced data delivery. NETCONF connections are long-lived, persisting between protocol operations.
NETCONF是面向连接的，需要对等方之间的持久连接。此连接必须提供可靠、有序的数据传输。NETCONF连接是长期的，在协议操作之间保持。
In addition, resources requested from the server for a particular connection MUST be automatically released when the connection closes, making failure recovery simpler and more robust. For example, when a lock is acquired by a client, the lock persists until either it is explicitly released or the server determines that the connection has been terminated. If a connection is terminated while the client holds a lock, the server can perform any appropriate recovery. The <lock> operation is further discussed in Section 7.5.
此外，当连接关闭时，必须自动释放为特定连接从服务器请求的资源，从而使故障恢复更简单、更可靠。例如，当客户端获取锁时，该锁将一直保持，直到显式释放该锁或服务器确定连接已终止。如果在客户端持有锁时终止连接，则服务器可以执行任何适当的恢复。第7.5节将进一步讨论<lock>操作。
NETCONF connections MUST provide authentication, data integrity, confidentiality, and replay protection. NETCONF depends on the transport protocol for this capability. A NETCONF peer assumes that appropriate levels of security and confidentiality are provided independently of this document. For example, connections could be encrypted using Transport Layer Security (TLS) [RFC5246] or Secure Shell (SSH) [RFC4251], depending on the underlying protocol.
NETCONF连接必须提供身份验证、数据完整性、机密性和重播保护。NETCONF依赖于此功能的传输协议。NETCONF对等方假定提供了与本文档无关的适当级别的安全性和机密性。例如，根据底层协议，可以使用传输层安全性（TLS）[RFC5246]或安全外壳（SSH）[RFC4251]对连接进行加密。
NETCONF connections MUST be authenticated. The transport protocol is responsible for authentication of the server to the client and authentication of the client to the server. A NETCONF peer assumes that the connection's authentication information has been validated by the underlying transport protocol using sufficiently trustworthy mechanisms and that the peer's identity has been sufficiently proven.
NETCONF连接必须经过身份验证。传输协议负责服务器到客户端的身份验证和客户端到服务器的身份验证。NETCONF对等方假定连接的身份验证信息已由底层传输协议使用足够可靠的机制进行验证，并且对等方的身份已得到充分证明。
One goal of NETCONF is to provide a programmatic interface to the device that closely follows the functionality of the device's native interface. Therefore, it is expected that the underlying protocol uses existing authentication mechanisms available on the device. For example, a NETCONF server on a device that supports RADIUS [RFC2865] might allow the use of RADIUS to authenticate NETCONF sessions.
NETCONF的一个目标是为设备提供一个编程接口，该接口紧密遵循设备本机接口的功能。因此，预期底层协议使用设备上可用的现有身份验证机制。例如，支持RADIUS[RFC2865]的设备上的NETCONF服务器可能允许使用RADIUS对NETCONF会话进行身份验证。
The authentication process MUST result in an authenticated client identity whose permissions are known to the server. The authenticated identity of a client is commonly referred to as the NETCONF username. The username is a string of characters that match the "Char" production from Section 2.2 of [W3C.REC-xml-20001006]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. The transport protocol MUST provide a username to be used by the other NETCONF layers.
身份验证过程必须产生一个经过身份验证的客户端标识，服务器知道该标识的权限。客户机的身份验证通常称为NETCONF用户名。用户名是与[W3C.REC-xml-20001006]第2.2节中的“Char”产品相匹配的字符串。用于派生用户名的算法特定于传输协议，并且特定于传输协议使用的身份验证机制。传输协议必须提供一个用户名，供其他NETCONF层使用。
The access permissions of a given client, identified by its NETCONF username, are part of the configuration of the NETCONF server. These permissions MUST be enforced during the remainder of the NETCONF session. The details of how access control is configured is outside the scope of this document.
给定客户端的访问权限（由其NETCONF用户名标识）是NETCONF服务器配置的一部分。这些权限必须在NETCONF会话的剩余时间内强制执行。如何配置访问控制的详细信息不在本文档的范围内。
A NETCONF implementation MUST support the SSH transport protocol mapping [RFC6242].
NETCONF实现必须支持SSH传输协议映射[RFC6242]。
XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.
XML作为NETCONF的编码格式，允许以文本格式表示复杂的层次结构数据，可以使用传统的文本工具和特定于XML的工具来读取、保存和操作文本格式。
All NETCONF messages MUST be well-formed XML, encoded in UTF-8 [RFC3629]. If a peer receives an <rpc> message that is not well-formed XML or not encoded in UTF-8, it SHOULD reply with a "malformed-message" error. If a reply cannot be sent for any reason, the server MUST terminate the session.
所有NETCONF消息必须是格式良好的XML，以UTF-8[RFC3629]编码。如果对等方收到的<rpc>消息不是格式良好的XML或不是UTF-8编码的，它应该以“格式错误的消息”错误进行回复。如果由于任何原因无法发送回复，服务器必须终止会话。
A NETCONF message MAY begin with an XML declaration (see Section 2.8 of [W3C.REC-xml-20001006]).
NETCONF消息可以以XML声明开头（参见[W3C.REC-XML-20001006]的第2.8节）。
This section discusses a small number of XML-related considerations pertaining to NETCONF.
本节讨论与NETCONF有关的少量XML相关注意事项。
All NETCONF protocol elements are defined in the following namespace:
所有NETCONF协议元素都在以下命名空间中定义：
urn:ietf:params:xml:ns:netconf:base:1.0
urn:ietf:params:xml:ns:netconf:base:1.0
NETCONF capability names MUST be URIs [RFC3986]. NETCONF capabilities are discussed in Section 8.
NETCONF功能名称必须是URI[RFC3986]。第8节讨论了NETCONF功能。
Document type declarations (see Section 2.8 of [W3C.REC-xml-20001006]) MUST NOT appear in NETCONF content.
文件类型声明（见[W3C.REC-xml-20001006]第2.8节）不得出现在NETCONF内容中。
The NETCONF protocol uses an RPC-based communication model. NETCONF peers use <rpc> and <rpc-reply> elements to provide transport-protocol-independent framing of NETCONF requests and responses.
NETCONF协议使用基于RPC的通信模型。NETCONF对等方使用<rpc>和<rpc reply>元素提供NETCONF请求和响应的传输协议独立框架。
The syntax and XML encoding of the Messages-layer RPCs are formally defined in the XML schema in Appendix B.
消息层RPC的语法和XML编码在附录B的XML模式中正式定义。
The <rpc> element is used to enclose a NETCONF request sent from the client to the server.
元素用于封装从客户端发送到服务器的NETCONF请求。
The <rpc> element has a mandatory attribute "message-id", which is a string chosen by the sender of the RPC that will commonly encode a monotonically increasing integer. The receiver of the RPC does not decode or interpret this string but simply saves it to be used as a "message-id" attribute in any resulting <rpc-reply> message. The sender MUST ensure that the "message-id" value is normalized according to the XML attribute value normalization rules defined in [W3C.REC-xml-20001006] if the sender wants the string to be returned unmodified. For example:
<rpc>元素有一个强制属性“message id”，这是rpc的发送者选择的字符串，它通常编码一个单调递增的整数。RPC的接收者不解码或解释此字符串，而只是将其保存为任何结果<RPC reply>消息中的“消息id”属性。如果发送方希望返回未修改的字符串，则发送方必须确保根据[W3C.REC-XML-20001006]中定义的XML属性值规范化规则对“消息id”值进行规范化。例如：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>
<!-- method parameters here... -->
</some-method>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>
<!-- method parameters here... -->
</some-method>
</rpc>
If additional attributes are present in an <rpc> element, a NETCONF peer MUST return them unmodified in the <rpc-reply> element. This includes any "xmlns" attributes.
如果<rpc>元素中存在其他属性，则NETCONF对等方必须在<rpc reply>元素中返回未经修改的属性。这包括任何“xmlns”属性。
The name and parameters of an RPC are encoded as the contents of the <rpc> element. The name of the RPC is an element directly inside the <rpc> element, and any parameters are encoded inside this element.
RPC的名称和参数被编码为<RPC>元素的内容。RPC的名称是直接位于<RPC>元素内的元素，任何参数都在该元素内编码。
The following example invokes a method called <my-own-method>, which has two parameters, <my-first-parameter>, with a value of "14", and <another-parameter>, with a value of "fred":
下面的示例调用一个名为<my own method>的方法，该方法有两个参数，<my first parameter>，值为“14”，和<Other parameter>，值为“fred”：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<my-own-method xmlns="http://example.net/me/my-own/1.0">
<my-first-parameter>14</my-first-parameter>
<another-parameter>fred</another-parameter>
</my-own-method>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<my-own-method xmlns="http://example.net/me/my-own/1.0">
<my-first-parameter>14</my-first-parameter>
<another-parameter>fred</another-parameter>
</my-own-method>
</rpc>
The following example invokes a <rock-the-house> method with a <zip-code> parameter of "27606-0100":
以下示例使用参数“27606-0100”调用<rock The house>方法：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock/1.0">
<zip-code>27606-0100</zip-code>
</rock-the-house>
</rpc>
The following example invokes the NETCONF <get> method with no parameters:
以下示例不带参数调用NETCONF<get>方法：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
The <rpc-reply> message is sent in response to an <rpc> message.
<rpc reply>消息是响应<rpc>消息而发送的。
The <rpc-reply> element has a mandatory attribute "message-id", which is equal to the "message-id" attribute of the <rpc> for which this is a response.
<rpc reply>元素有一个强制属性“message id”，它等于<rpc>的“message id”属性，这是对该属性的响应。
A NETCONF server MUST also return any additional attributes included in the <rpc> element unmodified in the <rpc-reply> element.
NETCONF服务器还必须返回<rpc reply>元素中未修改的<rpc>元素中包含的任何附加属性。
The response data is encoded as one or more child elements to the <rpc-reply> element.
响应数据被编码为<rpc reply>元素的一个或多个子元素。
For example:
例如：
The following <rpc> element invokes the NETCONF <get> method and includes an additional attribute called "user-id". Note that the "user-id" attribute is not in the NETCONF namespace. The returned <rpc-reply> element returns the "user-id" attribute, as well as the requested content.
下面的<rpc>元素调用NETCONF<get>方法，并包含一个名为“user id”的附加属性。请注意，“用户id”属性不在NETCONF命名空间中。返回的<rpc reply>元素返回“user id”属性以及请求的内容。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<get/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<data>
<!-- contents here... -->
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ex="http://example.net/content/1.0"
ex:user-id="fred">
<data>
<!-- contents here... -->
</data>
</rpc-reply>
The <rpc-error> element is sent in <rpc-reply> messages if an error occurs during the processing of an <rpc> request.
如果在处理<rpc>请求期间发生错误，则在<rpc reply>消息中发送<rpc error>元素。
If a server encounters multiple errors during the processing of an <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error> elements. However, a server is not required to detect or report more than one <rpc-error> element, if a request contains multiple errors. A server is not required to check for particular error conditions in a specific sequence. A server MUST return an <rpc-error> element if any error conditions occur during processing.
如果服务器在处理<rpc>请求期间遇到多个错误，<rpc reply>可能包含多个<rpc error>元素。但是，如果请求包含多个错误，则服务器不需要检测或报告多个<rpc error>元素。服务器不需要按特定顺序检查特定错误条件。如果在处理过程中出现任何错误情况，服务器必须返回<rpc error>元素。
A server MUST NOT return application-level- or data-model-specific error information in an <rpc-error> element for which the client does not have sufficient access rights.
服务器不得在客户端没有足够访问权限的<rpc error>元素中返回特定于应用程序级别或数据模型的错误信息。
The <rpc-error> element includes the following information:
<rpc error>元素包含以下信息：
error-type: Defines the conceptual layer that the error occurred. Enumeration. One of:
错误类型：定义发生错误的概念层。枚举。什么之中的一个：
* transport (layer: Secure Transport)
* 传输（层：安全传输）
* rpc (layer: Messages)
* rpc（层：消息）
* protocol (layer: Operations)
* 协议（层：操作）
* application (layer: Content)
* 应用程序（层：内容）
error-tag: Contains a string identifying the error condition. See Appendix A for allowed values.
错误标记：包含标识错误条件的字符串。允许值见附录A。
error-severity: Contains a string identifying the error severity, as determined by the device. One of:
错误严重性：包含一个字符串，标识由设备确定的错误严重性。什么之中的一个：
* error
* 错误
* warning
* 警告
Note that there are no <error-tag> values defined in this document that utilize the "warning" enumeration. This is reserved for future use.
请注意，本文档中没有定义使用“警告”枚举的<error tag>值。这是留作将来使用的。
error-app-tag: Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error-tag can be associated with a particular error condition. If a
error app tag：包含一个字符串，标识特定于数据模型或特定于实现的错误条件（如果存在）。如果没有合适的应用程序错误标记与特定错误条件相关联，则此元素将不存在。如果
data-model-specific and an implementation-specific error-app-tag both exist, then the data-model-specific value MUST be used by the server.
特定于数据模型和特定于实现的错误应用标记都存在，那么服务器必须使用特定于数据模型的值。
error-path: Contains the absolute XPath [W3C.REC-xpath-19991116] expression identifying the element path to the node that is associated with the error being reported in a particular <rpc-error> element. This element will not be present if no appropriate payload element or datastore node can be associated with a particular error condition.
错误路径：包含绝对XPath[W3C.REC-XPath-19991116]表达式，该表达式标识与特定<rpc error>元素中报告的错误相关联的节点的元素路径。如果没有适当的有效负载元素或数据存储节点可以与特定错误条件相关联，则此元素将不存在。
The XPath expression is interpreted in the following context:
XPath表达式在以下上下文中解释：
* The set of namespace declarations are those in scope on the <rpc-error> element.
* 命名空间声明集是<rpc error>元素作用域中的声明。
* The set of variable bindings is empty.
* 变量绑定集为空。
* The function library is the core function library.
* 函数库是核心函数库。
The context node depends on the node associated with the error being reported:
上下文节点取决于与报告的错误关联的节点：
* If a payload element can be associated with the error, the context node is the rpc request's document node (i.e., the <rpc> element).
* 如果有效负载元素可以与错误关联，则上下文节点是rpc请求的文档节点（即<rpc>元素）。
* Otherwise, the context node is the root of all data models, i.e., the node that has the top-level nodes from all data models as children.
* 否则，上下文节点是所有数据模型的根，即，将所有数据模型的顶级节点作为子节点的节点。
error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an "xml:lang" attribute as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470].
错误消息：包含一个适合人工显示的字符串，用于描述错误条件。如果没有为特定错误条件提供适当的消息，则此元素将不存在。此元素应包括[W3C.REC-xml-20001006]中定义并在[RFC3470]中讨论的“xml:lang”属性。
error-info: Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in Appendix A defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition MAY mandate that certain application-layer error information be included in the error-info container. An implementation MAY include additional elements to provide extended and/or implementation-specific debugging information.
错误信息：包含协议或数据模型特定的错误内容。如果没有为特定错误条件提供此类错误内容，则此元素将不存在。附录A中的列表定义了每个错误的任何强制性错误信息内容。在任何协议授权的内容之后，数据模型定义可以授权将某些应用层错误信息包括在错误信息容器中。实现可以包括额外的元素，以提供扩展的和/或实现特定的调试信息。
Appendix A enumerates the standard NETCONF errors.
附录A列举了标准NETCONF错误。
Example: An error is returned if an <rpc> element is received without a "message-id" attribute. Note that only in this case is it acceptable for the NETCONF peer to omit the "message-id" attribute in the <rpc-reply> element.
示例：如果接收到的<rpc>元素没有“message id”属性，则返回错误。注意，只有在这种情况下，NETCONF对等方才可以忽略<rpc reply>元素中的“message id”属性。
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>rpc</error-type>
<error-tag>missing-attribute</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>rpc</error-type>
<error-tag>missing-attribute</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
The following <rpc-reply> illustrates the case of returning multiple <rpc-error> elements.
下面的<rpc reply>说明了返回多个<rpc error>元素的情况。
Note that the data models used in the examples in this section use the <name> element to distinguish between multiple instances of the <interface> element.
请注意，本节示例中使用的数据模型使用<name>元素来区分<interface>元素的多个实例。
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
</error-path>
<error-message xml:lang="en">
MTU value 25000 is not within range 256..9192
</error-message>
</rpc-error>
<rpc-error>
<error-type>application</error-type>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
</error-path>
<error-message xml:lang="en">
MTU value 25000 is not within range 256..9192
</error-message>
</rpc-error>
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
</error-path>
<error-message xml:lang="en">
Invalid IP address for interface Ethernet1/0
</error-message>
</rpc-error>
</rpc-reply>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:t="http://example.com/schema/1.2/config">
/t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
</error-path>
<error-message xml:lang="en">
Invalid IP address for interface Ethernet1/0
</error-message>
</rpc-error>
</rpc-reply>
The <ok> element is sent in <rpc-reply> messages if no errors or warnings occurred during the processing of an <rpc> request, and no data was returned from the operation. For example:
如果在处理<rpc>请求期间未发生错误或警告，并且操作未返回任何数据，则在<rpc reply>消息中发送<ok>元素。例如：
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
NETCONF <rpc> requests MUST be processed serially by the managed device. Additional <rpc> requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.
NETCONF<rpc>请求必须由受管设备串行处理。其他<rpc>请求可能在以前的请求完成之前发送。受管设备必须仅按照接收请求的顺序发送响应。
NETCONF provides an initial set of operations and a number of capabilities that can be used to extend the base. NETCONF peers exchange device capabilities when the session is initiated as described in Section 8.1.
NETCONF提供了一组初始操作和一些可用于扩展基础的功能。如第8.1节所述，当会话启动时，NETCONF对等交换设备功能。
NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them. A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands.
NETCONF定义一个或多个配置数据存储的存在，并允许对其进行配置操作。配置数据存储定义为使设备从初始默认状态进入所需操作状态所需的完整配置数据集。配置数据存储不包括状态数据或执行命令。
The running configuration datastore holds the complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. NETCONF protocol operations refer to this datastore using the <running> element.
正在运行的配置数据存储保存网络设备上当前处于活动状态的完整配置。设备上仅存在一个此类型的配置数据存储，并且始终存在。NETCONF协议操作使用<running>元素引用此数据存储。
Only the <running> configuration datastore is present in the base model. Additional configuration datastores MAY be defined by capabilities. Such configuration datastores are available only on devices that advertise the capabilities.
基本模型中仅存在<running>配置数据存储。其他配置数据存储可能由功能定义。此类配置数据存储仅在发布功能的设备上可用。
The capabilities in Sections 8.3 and 8.7 define the <candidate> and <startup> configuration datastores, respectively.
第8.3节和第8.7节中的功能分别定义了<candidate>和<startup>配置数据存储。
Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model.
数据建模和内容问题不在NETCONF协议的范围内。假设应用程序熟知设备的数据模型，并且双方都知道数据的布局、包含、键控、查找、替换和管理等问题，以及数据模型施加的任何其他约束。
NETCONF carries configuration data inside the <config> element that is specific to the device's data model. The protocol treats the contents of that element as opaque data. The device uses capabilities to announce the set of data models that the device implements. The capability definition details the operation and constraints imposed by data model.
NETCONF在<config>元素中携带特定于设备数据模型的配置数据。协议将该元素的内容视为不透明数据。设备使用功能宣布设备实现的数据模型集。能力定义详细说明了数据模型施加的操作和约束。
Devices and managers can support multiple data models, including both standard and proprietary data models.
设备和管理器可以支持多种数据模型，包括标准和专有数据模型。
XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the <rpc-reply> for a <get> or <get-config> operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model-specific semantics during processing, allowing for simple and centralized implementation strategies.
XML子树过滤是一种机制，允许应用程序为<get>或<get config>操作选择要包含在<rpc reply>中的特定XML子树。提供了一组用于包含、简单内容精确匹配和选择的过滤器，允许一些有用但也非常有限的选择机制。在处理过程中，服务器不需要使用任何特定于数据模型的语义，从而实现简单而集中的实现策略。
Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output.
从概念上讲，子树过滤器由零个或多个元素子树组成，这些子树表示过滤器选择标准。在子树中的每个包含级别上，服务器对同级节点集进行逻辑处理，以确定其子树和元素到根的路径是否包含在过滤器输出中。
Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below <filter>.
子树筛选器中指定的每个节点表示一个包含筛选器。筛选器仅选择服务器上指定数据存储中的基础数据模型中的关联节点。如果节点符合筛选数据中给定的选择标准和元素层次结构，则会选择该节点，但筛选绝对路径名称会调整为从<filter>下面的层开始。
Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data.
响应消息仅包含筛选器选择的子树。响应中还包括请求中存在的、特定选定子树中的任何选择标准。请注意，过滤器中表示为叶节点的某些元素将在过滤器输出中展开（即包括子树）。如果请求包含多个选择相同数据的筛选器子树表达式，则特定数据实例不会在响应中重复。
A subtree filter is comprised of XML elements and their XML attributes. There are five types of components that can be present in a subtree filter:
子树过滤器由XML元素及其XML属性组成。子树筛选器中可以存在五种类型的组件：
o Namespace Selection
o 名称空间选择
o Attribute Match Expressions
o 属性匹配表达式
o Containment Nodes
o 包容节点
o Selection Nodes
o 选择节点
o Content Match Nodes
o 内容匹配节点
A namespace is considered to match (for filter purposes) if the XML namespace associated with a particular node within the <filter> element is the same as in the underlying data model. Note that namespace selection cannot be used by itself. At least one element MUST be specified in the filter if any elements are to be included in the filter output.
如果<filter>元素中与特定节点关联的XML名称空间与基础数据模型中的相同，则认为名称空间匹配（出于筛选目的）。请注意，名称空间选择本身不能使用。如果要在过滤器输出中包含任何元素，则必须在过滤器中至少指定一个元素。
An XML namespace wildcard mechanism is defined for subtree filtering. If an element within the <filter> element is not qualified by a namespace (e.g., xmlns=""), then the server MUST evaluate all the XML namespaces it supports, when processing that subtree filter node. This wildcard mechanism is not applicable to XML attributes.
为子树筛选定义了XML命名空间通配符机制。如果<filter>元素中的某个元素未被命名空间限定（例如，xmlns=“”），则服务器在处理该子树筛选器节点时必须评估其支持的所有XML命名空间。此通配符机制不适用于XML属性。
Note that prefix values for qualified namespaces are not relevant when comparing filter elements to elements in the underlying data model.
请注意，在将筛选器元素与基础数据模型中的元素进行比较时，限定名称空间的前缀值不相关。
Example:
例子：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>
In this example, the <top> element is a selection node, and only this node in the "http://example.com/schema/1.2/config" namespace and any child nodes (from the underlying data model) will be included in the filter output.
在本例中，<top>元素是一个选择节点，并且在http://example.com/schema/1.2/config“命名空间和任何子节点（来自基础数据模型）将包含在筛选器输出中。
An attribute that appears in a subtree filter is part of an "attribute match expression". Any number of (unqualified or qualified) XML attributes MAY be present in any type of filter node. In addition to the selection criteria normally applicable to that node, the selected data MUST have matching values for every attribute specified in the node. If an element is not defined to include a specified attribute, then it is not selected in the filter output.
出现在子树筛选器中的属性是“属性匹配表达式”的一部分。任何类型的筛选器节点中都可能存在任意数量的（非限定的或限定的）XML属性。除了通常适用于该节点的选择标准外，所选数据必须具有节点中指定的每个属性的匹配值。如果未将元素定义为包含指定属性，则不会在过滤器输出中选择该元素。
Example:
例子：
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/config">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/config">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
In this example, the <top> and <interfaces> elements are containment nodes, the <interface> element is a selection node, and "ifName" is an attribute match expression. Only "interface" nodes in the "http://example.com/schema/1.2/config" namespace that have an "ifName" attribute with the value "eth0" and occur within "interfaces" nodes within "top" nodes will be included in the filter output.
在本例中，<top>和<interfaces>元素是包含节点，<interface>元素是选择节点，“ifName”是属性匹配表达式。仅“接口”节点位于http://example.com/schema/1.2/config“具有值为“eth0”的“ifName”属性且出现在“top”节点中的“interfaces”节点中的命名空间将包含在筛选器输出中。
Nodes that contain child elements within a subtree filter are called "containment nodes". Each child element can be any type of node, including another containment node. For each containment node specified in a subtree filter, all data model instances that exactly match the specified namespaces, element hierarchy, and any attribute match expressions are included in the filter output.
子树过滤器中包含子元素的节点称为“包含节点”。每个子元素可以是任何类型的节点，包括另一个包含节点。对于子树过滤器中指定的每个包含节点，过滤器输出中包括与指定名称空间、元素层次结构和任何属性匹配表达式完全匹配的所有数据模型实例。
Example:
例子：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
In this example, the <top> element is a containment node.
在本例中，<top>元素是一个包含节点。
An empty leaf node within a filter is called a "selection node", and it represents an "explicit selection" filter on the underlying data model. Presence of any selection nodes within a set of sibling nodes will cause the filter to select the specified subtree(s) and suppress automatic selection of the entire set of sibling nodes in the underlying data model. For filtering purposes, an empty leaf node can be declared either with an empty tag (e.g., <foo/>) or with explicit start and end tags (e.g., <foo> </foo>). Any whitespace characters are ignored in this form.
过滤器中的空叶节点称为“选择节点”，它表示基础数据模型上的“显式选择”过滤器。如果一组同级节点中存在任何选择节点，则过滤器将选择指定的子树，并禁止在基础数据模型中自动选择整个同级节点集。出于筛选目的，可以使用空标记（例如，<foo/>）或显式的开始和结束标记（例如，<foo></foo>）声明空叶节点。在此表单中忽略任何空白字符。
Example:
例子：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
In this example, the <top> element is a containment node, and the <users> element is a selection node. Only "users" nodes in the "http://example.com/schema/1.2/config" namespace that occur within a <top> element that is the root of the configuration datastore will be included in the filter output.
在本例中，<top>元素是包含节点，<users>元素是选择节点。仅“用户”节点位于http://example.com/schema/1.2/config“作为配置数据存储根的<top>元素中出现的命名空间将包含在筛选器输出中。
A leaf node that contains simple content is called a "content match node". It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content. The following constraints apply to content match nodes:
包含简单内容的叶节点称为“内容匹配节点”。它用于选择过滤器输出的部分或全部同级节点，并表示叶节点元素内容上的精确匹配过滤器。以下约束适用于内容匹配节点：
o A content match node MUST NOT contain nested elements.
o 内容匹配节点不得包含嵌套元素。
o Multiple content match nodes (i.e., sibling nodes) are logically combined in an "AND" expression.
o 多个内容匹配节点（即同级节点）在逻辑上组合在一个“和”表达式中。
o Filtering of mixed content is not supported.
o 不支持筛选混合内容。
o Filtering of list content is not supported.
o 不支持筛选列表内容。
o Filtering of whitespace-only content is not supported.
o 不支持过滤纯空白内容。
o A content match node MUST contain non-whitespace characters. An empty element (e.g., <foo></foo>) will be interpreted as a selection node (e.g., <foo/>).
o 内容匹配节点必须包含非空白字符。空元素（例如，<foo></foo>）将被解释为选择节点（例如，<foo/>）。
o Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified.
o 将忽略前导和尾随空白字符，但不会忽略或修改文本字符块中的任何空白字符。
If all specified sibling content match nodes in a subtree filter expression are "true", then the filter output nodes are selected in the following manner:
如果子树筛选器表达式中所有指定的同级内容匹配节点均为“true”，则将按以下方式选择筛选器输出节点：
o Each content match node in the sibling set is included in the filter output.
o 同级集中的每个内容匹配节点都包含在过滤器输出中。
o If any containment nodes are present in the sibling set, then they are processed further and included if any nested filter criteria are also met.
o 如果同级集中存在任何包含节点，则会进一步处理这些节点，并在满足任何嵌套筛选条件时将其包括在内。
o If any selection nodes are present in the sibling set, then all of them are included in the filter output.
o 如果兄弟节点集中存在任何选择节点，则所有选择节点都将包含在过滤器输出中。
o If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output.
o 如果选择节点的任何同级节点是概念数据结构（例如，列表键叶）的实例标识符组件，则它们也可以包括在过滤器输出中。
o Otherwise (i.e., there are no selection or containment nodes in the filter sibling set), all the nodes defined at this level in the underlying data model (and their subtrees, if any) are returned in the filter output.
o 否则（即，过滤器同级集合中没有选择或包含节点），在基础数据模型（及其子树，如果有的话）中在该级别定义的所有节点都将在过滤器输出中返回。
If any of the sibling content match node tests are "false", then no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match node(s).
如果任何同级内容匹配节点测试为“false”，则不会对该同级集执行进一步的筛选处理，并且筛选器不会选择任何同级子树，包括内容匹配节点。
Example:
例子：
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
In this example, the <users> and <user> nodes are both containment nodes, and <name> is a content match node. Since no sibling nodes of <name> are specified (and therefore no containment or selection nodes), all of the sibling nodes of <name> are returned in the filter output. Only "user" nodes in the "http://example.com/schema/1.2/config" namespace that match the element hierarchy and for which the <name> element is equal to "fred" will be included in the filter output.
在本例中，<users>和<user>节点都是包含节点，<name>是内容匹配节点。由于没有指定<name>的同级节点（因此没有包含或选择节点），因此<name>的所有同级节点都将在过滤器输出中返回。仅“用户”节点位于http://example.com/schema/1.2/config与元素层次结构匹配且<name>元素等于“fred”的命名空间将包含在过滤器输出中。
The filter output (the set of selected nodes) is initially empty.
过滤器输出（所选节点集）最初为空。
Each subtree filter can contain one or more data model fragments, which represent portions of the data model that will be selected (with all child nodes) in the filter output.
每个子树筛选器都可以包含一个或多个数据模型片段，这些片段表示将在筛选器输出中选择（与所有子节点一起）的数据模型部分。
Each subtree data fragment is compared by the server to the internal data models supported by the server. If the entire subtree data-fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data.
服务器将每个子树数据片段与服务器支持的内部数据模型进行比较。如果整个子树数据片段过滤器（从根到过滤器中指定的最内层元素）完全匹配受支持数据模型的相应部分，则该节点及其所有子节点都将包含在结果数据中。
The server processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root
服务器一起处理具有相同父节点（同级节点集）的所有节点，从根节点到叶节点。根
elements in the filter are considered in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent.
筛选器中的元素被视为在同一个同级集中（假定它们位于同一命名空间中），即使它们没有公共父级。
For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed.
对于每个同级集，服务器确定过滤器输出中包括（或可能包括）哪些节点，以及从过滤器输出中排除（修剪）哪些同级子树。服务器首先确定同级集中存在哪些类型的节点，并根据其类型的规则处理这些节点。如果选择了同级节点集中的任何节点，则该过程将递归应用于每个选定节点的同级节点集。该算法将继续，直到处理完筛选器中指定的所有子树中的所有同级集。
Leaving out the filter on the <get> operation returns the entire data model.
在<get>操作中省略过滤器将返回整个数据模型。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<!-- ... entire set of data returned ... -->
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<!-- ... entire set of data returned ... -->
</data>
</rpc-reply>
An empty filter will select nothing because no content match or selection nodes are present. This is not an error. The <filter> element's "type" attribute used in these examples is discussed further in Section 7.1.
空筛选器将不选择任何内容，因为不存在内容匹配或选择节点。这不是一个错误。第7.1节将进一步讨论这些示例中使用的<filter>元素的“type”属性。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
</filter>
</get>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
</data>
</rpc-reply>
The filter in this example contains one selection node (<users>), so just that subtree is selected by the filter. This example represents the fully populated <users> data model in most of the filter examples that follow. In a real data model, the <company-info> would not likely be returned with the list of users for a particular host or network.
本例中的过滤器包含一个选择节点（<users>），因此过滤器仅选择该子树。这个例子代表了后面大多数过滤器例子中完全填充的<users>数据模型。在实际数据模型中，<company info>不可能与特定主机或网络的用户列表一起返回。
NOTE: The filtering and configuration examples used in this document appear in the namespace "http://example.com/schema/1.2/config". The root element of this namespace is <top>. The <top> element and its descendents represent an example configuration data model only.
注意：本文档中使用的筛选和配置示例出现在命名空间中“http://example.com/schema/1.2/config". 此命名空间的根元素是<top>。<top>元素及其子元素仅代表一个示例配置数据模型。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
<user>
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
<company-info>
<dept>2</dept>
<id>3</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
<user>
<name>barney</name>
<type>admin</type>
<full-name>Barney Rubble</full-name>
<company-info>
<dept>2</dept>
<id>3</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
The following filter request would have produced the same result, but only because the container <users> defines one child element (<user>).
以下筛选器请求将产生相同的结果，但这只是因为容器<users>定义了一个子元素（<user>）。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user/>
</users>
</top>
</filter>
</get-config>
</rpc>
This filter contains two containment nodes (<users>, <user>) and one selection node (<name>). All instances of the <name> element in the same sibling set are selected in the filter output. The client might need to know that <name> is used as an instance identifier in this particular data structure, but the server does not need to know that meta-data in order to process the request.
此筛选器包含两个包含节点（<users>，<user>）和一个选择节点（<name>）。在过滤器输出中选择同一同级集中<name>元素的所有实例。客户机可能需要知道<name>在这个特定的数据结构中用作实例标识符，但服务器不需要知道元数据来处理请求。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
</user>
<user>
<name>fred</name>
</user>
<user>
<name>barney</name>
</user>
</users>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
</user>
<user>
<name>fred</name>
</user>
<user>
<name>barney</name>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains two containment nodes (<users>, <user>) and one content match node (<name>). All instances of the sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output.
此筛选器包含两个包含节点（<users>，<user>）和一个内容匹配节点（<name>）。在过滤器输出中选择包含<name>的同级集合的所有实例，其中<name>的值等于“fred”。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
<company-info>
<dept>2</dept>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains two containment nodes (<users>, <user>), one content match node (<name>), and two selection nodes (<type>, <full-name>). All instances of the <type> and <full-name> elements in the same sibling set containing <name> for which the value of <name> equals "fred" are selected in the filter output. The <company-info> element is not included because the sibling set contains selection nodes.
此筛选器包含两个包含节点（<users>，<user>），一个内容匹配节点（<name>），和两个选择节点（<type>，<full name>）。在过滤器输出中选择同一同级集合中包含<name>且<name>值等于“fred”的<type>和<full name>元素的所有实例。不包括<company info>元素，因为同级集合包含选择节点。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type/>
<full-name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type/>
<full-name/>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
</user>
</users>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<type>admin</type>
<full-name>Fred Flintstone</full-name>
</user>
</users>
</top>
</data>
</rpc-reply>
This filter contains three subtrees (name=root, fred, barney).
此筛选器包含三个子树（name=root、fred、barney）。
The "root" subtree filter contains two containment nodes (<users>, <user>), one content match node (<name>), and one selection node (<company-info>). The subtree selection criteria are met, and just the company-info subtree for "root" is selected in the filter output.
“根”子树筛选器包含两个包含节点（<users>，<user>）、一个内容匹配节点（<name>）和一个选择节点（<company info>）。满足子树选择条件，并且仅在过滤器输出中选择“根”的公司信息子树。
The "fred" subtree filter contains three containment nodes (<users>, <user>, <company-info>), one content match node (<name>), and one selection node (<id>). The subtree selection criteria are met, and just the <id> element within the company-info subtree for "fred" is selected in the filter output.
“fred”子树筛选器包含三个包含节点（<users>、<user>、<company info>）、一个内容匹配节点（<name>）和一个选择节点（<id>）。满足子树选择标准，并且在过滤器输出中仅选择公司信息子树中“fred”的<id>元素。
The "barney" subtree filter contains three containment nodes (<users>, <user>, <company-info>), two content match nodes (<name>, <type>), and one selection node (<dept>). The subtree selection criteria are not met because user "barney" is not a "superuser", and the entire subtree for "barney" (including its parent <user> entry) is excluded from the filter output.
“barney”子树筛选器包含三个包含节点（<users>、<users>、<company info>）、两个内容匹配节点（<name>、<type>）和一个选择节点（<dept>）。未满足子树选择条件，因为用户“barney”不是“超级用户”，并且“barney”的整个子树（包括其父<user>条目）从过滤器输出中排除。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<type>superuser</type>
<company-info>
<dept/>
</company-info>
</user>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info/>
</user>
<user>
<name>fred</name>
<company-info>
<id/>
</company-info>
</user>
<user>
<name>barney</name>
<type>superuser</type>
<company-info>
<dept/>
</company-info>
</user>
</users>
</top>
</filter>
</get-config>
</rpc>
</users>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
In this example, the filter contains one containment node (<interfaces>), one attribute match expression ("ifName"), and one selection node (<interface>). All instances of the <interface> subtree that have an "ifName" attribute equal to "eth0" are selected in the filter output. The filter data elements and attributes are qualified because the "ifName" attribute will not be considered part of the "schema/1.2" namespace if it is unqualified.
在此示例中，筛选器包含一个包含节点（<interface>），一个属性匹配表达式（“ifName”）和一个选择节点（<interface>）。在过滤器输出中选择具有等于“eth0”的“ifName”属性的<interface>子树的所有实例。筛选器数据元素和属性是合格的，因为如果“ifName”属性是不合格的，则它不会被视为“schema/1.2”命名空间的一部分。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
</get>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0">
<t:ifInOctets>45621</t:ifInOctets>
<t:ifOutOctets>774344</t:ifOutOctets>
</t:interface>
</t:interfaces>
</t:top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<t:top xmlns:t="http://example.com/schema/1.2/stats">
<t:interfaces>
<t:interface t:ifName="eth0">
<t:ifInOctets>45621</t:ifInOctets>
<t:ifOutOctets>774344</t:ifOutOctets>
</t:interface>
</t:interfaces>
</t:top>
</data>
</rpc-reply>
If "ifName" were a child node instead of an attribute, then the following request would produce similar results.
如果“ifName”是子节点而不是属性，那么下面的请求将产生类似的结果。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
The NETCONF protocol provides a small set of low-level operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration datastores. Additional operations are provided, based on the capabilities advertised by the device.
NETCONF协议提供了一小部分低级操作，用于管理设备配置和检索设备状态信息。基本协议提供检索、配置、复制和删除配置数据存储的操作。根据设备公布的功能，提供附加操作。
The base protocol includes the following protocol operations:
基本协议包括以下协议操作：
o get
o 收到
o get-config
o 获取配置
o edit-config
o 编辑配置
o copy-config
o 复制配置
o delete-config
o 删除配置
o lock
o 锁
o unlock
o 解锁
o close-session
o 闭门会议
o kill-session
o 终止会话
A protocol operation can fail for various reasons, including "operation not supported". An initiator SHOULD NOT assume that any operation will always succeed. The return values in any RPC reply SHOULD be checked for error responses.
协议操作可能因各种原因而失败，包括“不支持操作”。发起者不应假定任何操作总是成功的。应检查任何RPC回复中的返回值是否有错误响应。
The syntax and XML encoding of the protocol operations are formally defined in the YANG module in Appendix C. The following sections describe the semantics of each protocol operation.
协议操作的语法和XML编码在附录C的YANG模块中正式定义。以下各节描述了每个协议操作的语义。
Description: Retrieve all or part of a specified configuration datastore.
描述：检索指定配置数据存储的全部或部分。
Parameters:
参数：
source: Name of the configuration datastore being queried, such as <running/>.
source：正在查询的配置数据存储的名称，例如<running/>。
filter: This parameter identifies the portions of the device configuration datastore to retrieve. If this parameter is not present, the entire configuration is returned.
筛选器：此参数标识要检索的设备配置数据存储的部分。如果此参数不存在，则返回整个配置。
The <filter> element MAY optionally contain a "type" attribute. This attribute indicates the type of filtering syntax used within the <filter> element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value "subtree" explicitly identifies this type of filtering.
<filter>元素可以选择性地包含一个“type”属性。此属性指示<filter>元素中使用的过滤语法的类型。NETCONF中的默认过滤机制称为子树过滤，第6节对此进行了描述。值“subtree”明确标识这种类型的筛选。
If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" MAY be used to indicate that the "select" attribute on the <filter> element contains an XPath expression.
如果NETCONF对等方支持：xpath功能（第8.9节），则值“xpath”可用于指示<filter>元素上的“select”属性包含xpath表达式。
Positive Response: If the device can satisfy the request, the server sends an <rpc-reply> element containing a <data> element with the results of the query.
肯定响应：如果设备能够满足请求，服务器将发送一个<rpc reply>元素，其中包含一个<data>元素以及查询结果。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example: To retrieve the entire <users> subtree:
示例：要检索整个<users>子树，请执行以下操作：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</data>
</rpc-reply>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</data>
</rpc-reply>
Section 6 contains additional examples of subtree filtering.
第6节包含子树过滤的其他示例。
Description:
说明：
The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration datastore does not exist, it will be created.
<edit config>操作将指定配置的全部或部分加载到指定的目标配置数据存储。此操作允许以多种方式表示新配置，例如使用本地文件、远程文件或内联文件。如果目标配置数据存储不存在，将创建它。
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear instead of the <config> parameter.
如果NETCONF对等机支持：url功能（第8.8节），则可以显示<url>元素而不是<config>参数。
The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the <copy-config> message. Instead, the target configuration is changed in accordance with the source's data and requested operations.
设备分析源和目标配置，并执行请求的更改。与<copy config>消息一样，不必替换目标配置。相反，目标配置会根据源的数据和请求的操作进行更改。
If the <edit-config> operation contains multiple sub-operations that apply to the same conceptual node in the underlying data model, then the result of the operation is undefined (i.e., outside the scope of the NETCONF protocol).
如果<edit config>操作包含多个子操作，这些子操作应用于基础数据模型中的同一概念节点，则该操作的结果未定义（即，在NETCONF协议的范围之外）。
Attributes:
属性：
operation: Elements in the <config> subtree MAY contain an "operation" attribute, which belongs to the NETCONF namespace defined in Section 3.1. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the <config> subtree.
操作：<config>子树中的元素可能包含“operation”属性，该属性属于第3.1节中定义的NETCONF名称空间。该属性标识配置中执行操作的点，并可能出现在整个<config>子树的多个元素上。
If the "operation" attribute is not specified, the configuration is merged into the configuration datastore.
如果未指定“操作”属性，则配置将合并到配置数据存储中。
The "operation" attribute has one of the following values:
“操作”属性具有以下值之一：
merge: The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the <target> parameter. This is the default behavior.
合并：包含此属性的元素标识的配置数据与<target>参数标识的配置数据存储中相应级别的配置合并。这是默认行为。
replace: The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the <target> parameter. If no such configuration data exists in the configuration datastore, it is created. Unlike a <copy-config> operation, which replaces the entire target configuration, only the configuration actually present in the <config> parameter is affected.
替换：由包含此属性的元素标识的配置数据替换由<target>参数标识的配置数据存储中的任何相关配置。如果配置数据存储中不存在此类配置数据，则会创建该数据。与替换整个目标配置的<copy config>操作不同，只有<config>参数中实际存在的配置会受到影响。
create: The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist in the configuration datastore. If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of "data-exists".
创建：当且仅当配置数据存储中不存在配置数据时，由包含此属性的元素标识的配置数据才会添加到配置中。如果配置数据存在，则返回一个<rpc error>元素，其<error tag>值为“data exists”。
delete: The configuration data identified by the element containing this attribute is deleted from the configuration if and only if the configuration data currently exists in the configuration datastore. If the configuration data does not exist, an <rpc-error> element is returned with an <error-tag> value of "data-missing".
删除：当且仅当配置数据存储中当前存在配置数据时，由包含此属性的元素标识的配置数据才会从配置中删除。如果配置数据不存在，则返回一个<rpc error>元素，其<error tag>值为“data missing”。
remove: The configuration data identified by the element containing this attribute is deleted from the configuration if the configuration data currently exists in the configuration datastore. If the configuration data does not exist, the "remove" operation is silently ignored by the server.
删除：如果配置数据存储中当前存在配置数据，则包含此属性的元素标识的配置数据将从配置中删除。如果配置数据不存在，服务器将自动忽略“删除”操作。
Parameters:
参数：
target: Name of the configuration datastore being edited, such as <running/> or <candidate/>.
目标：正在编辑的配置数据存储的名称，例如<running/>或<candidate/>。
default-operation: Selects the default operation (as described in the "operation" attribute) for this <edit-config> request. The default value for the <default-operation> parameter is "merge".
默认操作：为此<edit config>请求选择默认操作（如“操作”属性中所述）。<default operation>参数的默认值为“merge”。
The <default-operation> parameter is optional, but if provided, it has one of the following values:
<default operation>参数是可选的，但如果提供，它具有以下值之一：
merge: The configuration data in the <config> parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior.
合并：<config>参数中的配置数据与目标数据存储中相应级别的配置合并。这是默认行为。
replace: The configuration data in the <config> parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data.
替换：<config>参数中的配置数据完全替换目标数据存储中的配置。这对于加载以前保存的配置数据非常有用。
none: The target datastore is unaffected by the configuration in the <config> parameter, unless and until the incoming configuration data uses the "operation" attribute to request a different operation. If the configuration in the <config> parameter contains data for which there is not a corresponding level in the target datastore, an <rpc-error> is returned with an <error-tag> value of data-missing. Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted.
无：目标数据存储不受<config>参数中配置的影响，除非传入的配置数据使用“operation”属性请求不同的操作。如果<config>参数中的配置包含目标数据存储中没有相应级别的数据，则返回<rpc error>，其中缺少<error tag>数据值。使用“none”允许像“delete”这样的操作，以避免无意中创建要删除的元素的父层次结构。
test-option: The <test-option> element MAY be specified only if the device advertises the :validate:1.1 capability (Section 8.6).
测试选项：仅当设备宣传：验证：1.1功能（第8.6节）时，才可指定<test option>元素。
The <test-option> element has one of the following values:
<test option>元素具有以下值之一：
test-then-set: Perform a validation test before attempting to set. If validation errors occur, do not perform the <edit-config> operation. This is the default test-option.
测试然后设置：在尝试设置之前执行验证测试。如果出现验证错误，请不要执行<edit config>操作。这是默认的测试选项。
set: Perform a set without a validation test first.
set：先执行set而不进行验证测试。
test-only: Perform only the validation test, without attempting to set.
仅测试：仅执行验证测试，而不尝试设置。
error-option: The <error-option> element has one of the following values:
错误选项：<error option>元素具有以下值之一：
stop-on-error: Abort the <edit-config> operation on first error. This is the default error-option.
错误时停止：在出现第一个错误时中止<edit config>操作。这是默认的错误选项。
continue-on-error: Continue to process configuration data on error; error is recorded, and negative response is generated if any errors occur.
出错时继续：出错时继续处理配置数据；记录错误，如果出现任何错误，将生成否定响应。
rollback-on-error: If an error condition occurs such that an error severity <rpc-error> element is generated, the server will stop processing the <edit-config> operation and restore the specified configuration to its complete state at the start of this <edit-config> operation. This option requires the server to support the :rollback-on-error capability described in Section 8.5.
错误时回滚：如果出现错误情况，导致生成错误严重性<rpc error>元素，服务器将停止处理<edit config>操作，并在该<edit config>操作开始时将指定的配置恢复到其完整状态。此选项要求服务器支持第8.5节中描述的：错误时回滚功能。
config: A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. Capabilities are discussed in Section 8.
配置：由设备数据模型之一定义的配置数据层次结构。内容必须放置在适当的名称空间中，以允许设备检测适当的数据模型，并且内容必须遵循该数据模型的约束，如其功能定义所定义。功能在第8节中讨论。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> response is sent if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，将发送<rpc error>响应。
Example: The <edit-config> examples in this section utilize a simple data model, in which multiple instances of the <interface> element can be present, and an instance is distinguished by the <name> element within each <interface> element.
示例：本节中的<edit config>示例使用一个简单的数据模型，其中可以存在<interface>元素的多个实例，每个<interface>元素中的<name>元素可以区分一个实例。
Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration:
在运行配置中名为“Ethernet0/0”的接口上将MTU设置为1500：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Add an interface named "Ethernet0/0" to the running configuration, replacing any previous interface with that name:
将名为“Ethernet0/0”的接口添加到正在运行的配置中，用该名称替换以前的任何接口：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="replace">
<name>Ethernet0/0</name>
<mtu>1500</mtu>
<address>
<name>192.0.2.4</name>
<prefix-length>24</prefix-length>
</address>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete the configuration for an interface named "Ethernet0/0" from the running configuration:
从正在运行的配置中删除名为“Ethernet0/0”的接口的配置：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
</interface>
</top>
</config>
</edit-config>
</rpc>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Delete interface 192.0.2.4 from an OSPF area (other interfaces configured in the same area are unaffected):
从OSPF区域删除接口192.0.2.4（在同一区域中配置的其他接口不受影响）：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<protocols>
<ospf>
<area>
<name>0.0.0.0</name>
<interfaces>
<interface xc:operation="delete">
<name>192.0.2.4</name>
</interface>
</interfaces>
</area>
</ospf>
</protocols>
</top>
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<protocols>
<ospf>
<area>
<name>0.0.0.0</name>
<interfaces>
<interface xc:operation="delete">
<name>192.0.2.4</name>
</interface>
</interfaces>
</area>
</ospf>
</protocols>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description: Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed.
描述：使用另一个完整配置数据存储的内容创建或替换整个配置数据存储。如果目标数据存储存在，它将被覆盖。否则，如果允许，将创建一个新的。
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <source> or <target> parameter.
如果NETCONF对等机支持：url功能（第8.8节），则<url>元素可以显示为<source>或<target>参数。
Even if it advertises the :writable-running capability, a device MAY choose not to support the <running/> configuration datastore as the <target> parameter of a <copy-config> operation. A device MAY choose not to support remote-to-remote copy operations, where both the <source> and <target> parameters use the <url> element. If the <source> and <target> parameters identify the same URL or configuration datastore, an error MUST be returned with an error-tag containing "invalid-value".
即使它宣传：可写运行功能，设备也可能选择不支持<running/>配置数据存储作为<copy config>操作的<target>参数。设备可以选择不支持远程到远程复制操作，其中<source>和<target>参数都使用<url>元素。如果<source>和<target>参数标识相同的URL或配置数据存储，则必须返回包含“无效值”的错误标记。
Parameters:
参数：
target: Name of the configuration datastore to use as the destination of the <copy-config> operation.
target：用作<copy config>操作目标的配置数据存储的名称。
source: Name of the configuration datastore to use as the source of the <copy-config> operation, or the <config> element containing the complete configuration to copy.
source：用作<copy config>操作源的配置数据存储的名称，或包含要复制的完整配置的<config>元素的名称。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc reply>中包含<rpc error>元素。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user:password@example.com/cfg/new.txt</url>
</source>
</copy-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user:password@example.com/cfg/new.txt</url>
</source>
</copy-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description: Delete a configuration datastore. The <running> configuration datastore cannot be deleted.
描述：删除配置数据存储。无法删除<running>配置数据存储。
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear as the <target> parameter.
如果NETCONF对等机支持：url功能（第8.8节），则<url>元素可以显示为<target>参数。
Parameters:
参数：
target: Name of the configuration datastore to delete.
目标：要删除的配置数据存储的名称。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc reply>中包含<rpc error>元素。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description: The <lock> operation allows the client to lock the entire configuration datastore system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users.
描述：<lock>操作允许客户端锁定设备的整个配置数据存储系统。此类锁的使用期限很短，允许客户端进行更改，而无需担心与其他NETCONF客户端、非NETCONF客户端（例如SNMP和命令行界面（CLI）脚本）以及人类用户的交互。
An attempt to lock the configuration datastore MUST fail if an existing session or other entity holds a lock on any portion of the lock target.
如果现有会话或其他实体持有锁定目标任何部分的锁，则锁定配置数据存储的尝试必须失败。
When the lock is acquired, the server MUST prevent any changes to the locked resource other than those requested by this session. SNMP and CLI requests to modify the resource MUST fail with an appropriate error.
获取锁后，服务器必须防止对锁定的资源进行除此会话请求的更改以外的任何更改。修改资源的SNMP和CLI请求必须失败，并出现相应错误。
The duration of the lock is defined as beginning when the lock is acquired and lasting until either the lock is released or the NETCONF session closes. The session closure can be explicitly performed by the client, or implicitly performed by the server based on criteria such as failure of the underlying transport, simple inactivity timeout, or detection of abusive behavior on the part of the client. These criteria are dependent on the implementation and the underlying transport.
锁的持续时间定义为从获取锁时开始，持续到释放锁或NETCONF会话关闭。会话关闭可以由客户端显式执行，也可以由服务器基于以下标准隐式执行：底层传输失败、简单的不活动超时或检测到客户端的滥用行为。这些标准取决于实施和基础传输。
The <lock> operation takes a mandatory parameter, <target>. The <target> parameter names the configuration datastore that will be locked. When a lock is active, using the <edit-config> operation on the locked configuration datastore and using the locked configuration as a target of the <copy-config> operation will be disallowed by any other NETCONF session. Additionally, the system will ensure that these locked configuration resources will not be modified by other non-NETCONF management operations such as SNMP and CLI. The <kill-session> operation can be used to force the release of a lock owned by another NETCONF session. It is beyond the scope of this document to define how to break locks held by other entities.
<lock>操作采用一个强制参数<target>。<target>参数命名将被锁定的配置数据存储。当锁定处于活动状态时，任何其他NETCONF会话都不允许在锁定的配置数据存储上使用<edit config>操作并将锁定的配置用作<copy config>操作的目标。此外，系统将确保这些锁定的配置资源不会被其他非NETCONF管理操作（如SNMP和CLI）修改。<kill session>操作可用于强制释放另一个NETCONF会话拥有的锁。定义如何打破其他实体持有的锁超出了本文档的范围。
A lock MUST NOT be granted if any of the following conditions is true:
如果满足以下任何条件，则不得授予锁定：
* A lock is already held by any NETCONF session or another entity.
* 任何NETCONF会话或其他实体都已持有锁。
* The target configuration is <candidate>, it has already been modified, and these changes have not been committed or rolled back.
* 目标配置是<candidate>，它已被修改，并且这些更改尚未提交或回滚。
* The target configuration is <running>, and another NETCONF session has an ongoing confirmed commit (Section 8.4).
* 目标配置正在<running>，另一个NETCONF会话正在进行确认提交（第8.4节）。
The server MUST respond with either an <ok> element or an <rpc-error>.
服务器必须使用<ok>元素或<rpc error>进行响应。
A lock will be released by the system if the session holding the lock is terminated for any reason.
如果持有锁的会话因任何原因终止，系统将释放锁。
Parameters:
参数：
target: Name of the configuration datastore to lock.
目标：要锁定的配置数据存储的名称。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
If the lock is already held, the <error-tag> element will be "lock-denied" and the <error-info> element will include the <session-id> of the lock owner. If the lock is held by a non-NETCONF entity, a <session-id> of 0 (zero) is included. Note that any other entity performing a lock on even a partial piece of a target will prevent a NETCONF lock (which is global) from being obtained on that target.
如果锁已经被持有，<error tag>元素将被“lock denied”，并且<error info>元素将包括锁所有者的<session id>。如果锁由非NETCONF实体持有，则包含0（零）的<session id>。请注意，任何其他实体即使对目标的一部分执行锁定，也会阻止在该目标上获得NETCONF锁（全局）。
Example: The following example shows a successful acquisition of a lock.
示例：以下示例显示成功获取锁。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <!-- lock succeeded -->
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <!-- lock succeeded -->
</rpc-reply>
Example: The following example shows a failed attempt to acquire a lock when the lock is already in use.
示例：以下示例显示了当锁已在使用时获取锁的失败尝试。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <!-- lock failed -->
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>
<!-- lock is held by NETCONF session 454 -->
</error-info>
</rpc-error>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <!-- lock failed -->
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>
<!-- lock is held by NETCONF session 454 -->
</error-info>
</rpc-error>
</rpc-reply>
Description: The <unlock> operation is used to release a configuration lock, previously obtained with the <lock> operation.
说明：<unlock>操作用于释放配置锁，该配置锁先前通过<lock>操作获得。
An <unlock> operation will not succeed if either of the following conditions is true:
如果满足以下任一条件，<unlock>操作将不会成功：
* The specified lock is not currently active.
* 指定的锁当前未处于活动状态。
* The session issuing the <unlock> operation is not the same session that obtained the lock.
* 发出<unlock>操作的会话与获得锁的会话不同。
The server MUST respond with either an <ok> element or an <rpc-error>.
服务器必须使用<ok>元素或<rpc error>进行响应。
Parameters:
参数：
target: Name of the configuration datastore to unlock.
目标：要解锁的配置数据存储的名称。
A NETCONF client is not permitted to unlock a configuration datastore that it did not lock.
不允许NETCONF客户端解锁未锁定的配置数据存储。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description: Retrieve running configuration and device state information.
描述：检索正在运行的配置和设备状态信息。
Parameters:
参数：
filter: This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is not present, all the device configuration and state information is returned.
筛选器：此参数指定要检索的系统配置和状态数据的部分。如果此参数不存在，则返回所有设备配置和状态信息。
The <filter> element MAY optionally contain a "type" attribute. This attribute indicates the type of filtering syntax used within the <filter> element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value "subtree" explicitly identifies this type of filtering.
<filter>元素可以选择性地包含一个“type”属性。此属性指示<filter>元素中使用的过滤语法的类型。NETCONF中的默认过滤机制称为子树过滤，第6节对此进行了描述。值“subtree”明确标识这种类型的筛选。
If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" MAY be used to indicate that the "select" attribute of the <filter> element contains an XPath expression.
如果NETCONF对等方支持：xpath功能（第8.9节），则值“xpath”可用于指示<filter>元素的“select”属性包含xpath表达式。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent. The <data> section contains the appropriate subset.
肯定响应：如果设备能够满足请求，则发送<rpc reply>。<data>部分包含适当的子集。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
</interface>
</interfaces>
</top>
</filter>
</get>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
<ifInOctets>45621</ifInOctets>
<ifOutOctets>774344</ifOutOctets>
</interface>
</interfaces>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/stats">
<interfaces>
<interface>
<ifName>eth0</ifName>
<ifInOctets>45621</ifInOctets>
<ifOutOctets>774344</ifOutOctets>
</interface>
</interfaces>
</top>
</data>
</rpc-reply>
Description: Request graceful termination of a NETCONF session.
描述：请求终止NETCONF会话。
When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a <close-session> request will be ignored.
当NETCONF服务器收到<close session>请求时，它将正常关闭会话。服务器将释放与会话关联的所有锁和资源，并正常关闭所有关联的连接。在<close session>请求之后收到的任何NETCONF请求都将被忽略。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Description: Force the termination of a NETCONF session.
描述：强制终止NETCONF会话。
When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections.
当NETCONF实体收到打开会话的<kill session>请求时，它将中止当前正在进行的任何操作，释放与会话相关的所有锁和资源，并关闭所有相关连接。
If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued.
如果NETCONF服务器在处理确认提交（第8.4节）时收到<kill session>请求，则必须将配置恢复到发出确认提交之前的状态。
Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock.
否则，<kill session>操作不会回滚持有锁的实体所做的配置或其他设备状态修改。
Parameters:
参数：
session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an "invalid-value" error is returned.
会话id：要终止的NETCONF会话的会话标识符。如果此值等于当前会话ID，则返回“无效值”错误。
Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
肯定响应：如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
否定响应：如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
This section defines a set of capabilities that a client or a server MAY implement. Each peer advertises its capabilities by sending them during an initial capabilities exchange. Each peer needs to understand only those capabilities that it might use and MUST ignore any capability received from the other peer that it does not require or does not understand.
本节定义了客户机或服务器可以实现的一组功能。每个对等方通过在初始功能交换期间发送功能来宣传其功能。每个对等方只需要了解它可能使用的那些功能，并且必须忽略从另一个对等方收到的它不需要或不了解的任何功能。
Additional capabilities can be defined using the template in Appendix D. Future capability definitions can be published as standards by standards bodies or published as proprietary extensions.
可使用附录D中的模板定义其他功能。未来的功能定义可由标准机构作为标准发布，或作为专有扩展发布。
A NETCONF capability is identified with a URI. The base capabilities are defined using URNs following the method described in RFC 3553 [RFC3553]. Capabilities defined in this document have the following format:
NETCONF功能由URI标识。根据RFC 3553[RFC3553]中描述的方法，使用URN定义基本能力。本文档中定义的功能具有以下格式：
urn:ietf:params:netconf:capability:{name}:1.x
urn:ietf:params:netconf:capability:{name}:1.x
where {name} is the name of the capability. Capabilities are often referenced in discussions and email using the shorthand :{name}, or :{name}:{version} if the capability exists in multiple versions. For example, the foo capability would have the formal name "urn:ietf:params:netconf:capability:foo:1.0" and be called ":foo". The shorthand form MUST NOT be used inside the protocol.
其中{name}是功能的名称。功能通常在讨论和电子邮件中使用缩写：{name}，或者：{name}:{version}引用（如果功能存在于多个版本中）。例如，foo功能的正式名称为“urn:ietf:params:netconf:capability:foo:1.0”，并称为“：foo”。协议中不得使用速记形式。
Capabilities are advertised in messages sent by each peer during session establishment. When the NETCONF session is opened, each peer (both client and server) MUST send a <hello> element containing a list of that peer's capabilities. Each peer MUST send at least the
在会话建立期间，在每个对等方发送的消息中公布功能。打开NETCONF会话时，每个对等方（客户端和服务器）都必须发送一个<hello>元素，其中包含该对等方的功能列表。每个对等方必须至少发送
base NETCONF capability, "urn:ietf:params:netconf:base:1.1". A peer MAY include capabilities for previous NETCONF versions, to indicate that it supports multiple protocol versions.
基本网络配置功能，“urn:ietf:params:NETCONF:base:1.1”。对等机可能包括以前NETCONF版本的功能，以表明它支持多个协议版本。
Both NETCONF peers MUST verify that the other peer has advertised a common protocol version. When comparing protocol version capability URIs, only the base part is used, in the event any parameters are encoded at the end of the URI string. If no protocol version capability in common is found, the NETCONF peer MUST NOT continue the session. If more than one protocol version URI in common is present, then the highest numbered (most recent) protocol version MUST be used by both peers.
两个NETCONF对等方都必须验证另一个对等方是否发布了公共协议版本。在比较协议版本功能URI时，如果在URI字符串末尾对任何参数进行编码，则只使用基本部分。如果找不到通用的协议版本功能，NETCONF对等方不得继续会话。如果存在多个共同的协议版本URI，则两个对等方必须使用编号最高（最新）的协议版本。
A server sending the <hello> element MUST include a <session-id> element containing the session ID for this NETCONF session. A client sending the <hello> element MUST NOT include a <session-id> element.
发送<hello>元素的服务器必须包含包含此NETCONF会话会话id的<session id>元素。发送<hello>元素的客户端不得包含<session id>元素。
A server receiving a <hello> message with a <session-id> element MUST terminate the NETCONF session. Similarly, a client that does not receive a <session-id> element in the server's <hello> message MUST terminate the NETCONF session (without first sending a <close-session>).
接收带有<session id>元素的<hello>消息的服务器必须终止NETCONF会话。类似地，在服务器的<hello>消息中未接收<session id>元素的客户端必须终止NETCONF会话（无需先发送<close session>）。
In the following example, a server advertises the base NETCONF capability, one NETCONF capability defined in the base NETCONF document, and one implementation-specific capability.
在下面的示例中，一个服务器公布基本NETCONF功能、一个在基本NETCONF文档中定义的NETCONF功能和一个特定于实现的功能。
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
http://example.net/router/2.3/myfeature
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
http://example.net/router/2.3/myfeature
</capability>
</capabilities>
<session-id>4</session-id>
</hello>
Each peer sends its <hello> element simultaneously as soon as the connection is open. A peer MUST NOT wait to receive the capability set from the other side before sending its own set.
一旦连接打开，每个对等方都会同时发送其<hello>元素。对等方在发送自己的能力集之前，不能等待从另一方接收能力集。
The :writable-running capability indicates that the device supports direct writes to the <running> configuration datastore. In other words, the device supports <edit-config> and <copy-config> operations where the <running> configuration is the target.
：writable running功能表示设备支持直接写入<running>配置数据存储。换句话说，设备支持<edit config>和<copy config>操作，其中<running>配置是目标。
None.
没有一个
The :writable-running capability is identified by the following capability string:
可写运行功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:writable-running:1.0
urn:ietf:params:netconf:capability:writable-running:1.0
None.
没有一个
The :writable-running capability modifies the <edit-config> operation to accept the <running> element as a <target>.
：writable running功能修改<edit config>操作以接受<running>元素作为<target>。
The :writable-running capability modifies the <copy-config> operation to accept the <running> element as a <target>.
：writable running功能修改<copy config>操作以接受<running>元素作为<target>。
The candidate configuration capability, :candidate, indicates that the device supports a candidate configuration datastore, which is used to hold configuration data that can be manipulated without impacting the device's current configuration. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes can be made to this data to construct the
候选配置功能：candidate表示设备支持候选配置数据存储，该存储用于保存配置数据，这些数据可以在不影响设备当前配置的情况下进行操作。候选配置是一个完整的配置数据集，用作创建和操作配置数据的工作场所。可以对此数据进行添加、删除和更改，以构建
desired configuration data. A <commit> operation MAY be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration.
所需的配置数据。任何时候都可以执行<commit>操作，从而将设备的运行配置设置为候选配置的值。
The <commit> operation effectively sets the running configuration to the current contents of the candidate configuration. While it could be modeled as a simple copy, it is done as a distinct operation for a number of reasons. In keeping high-level concepts as first-class operations, we allow developers to see more clearly both what the client is requesting and what the server must perform. This keeps the intentions more obvious, the special cases less complex, and the interactions between operations more straightforward. For example, the :confirmed-commit:1.1 capability (Section 8.4) would make no sense as a "copy confirmed" operation.
<commit>操作有效地将正在运行的配置设置为候选配置的当前内容。虽然它可以建模为一个简单的副本，但出于许多原因，它是作为一个独特的操作来完成的。在将高级概念保持为一流操作的过程中，我们允许开发人员更清楚地看到客户机请求的内容和服务器必须执行的内容。这使得意图更加明显，特殊情况不那么复杂，操作之间的交互更加直观。例如：confirated commit:1.1功能（第8.4节）作为“复制确认”操作毫无意义。
The candidate configuration can be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it MUST assume that other sessions are able to modify the candidate configuration at the same time. It is therefore prudent for a client to lock the candidate configuration before modifying it.
候选配置可以在多个会话之间共享。除非客户机具有未共享候选配置的特定信息，否则它必须假定其他会话能够同时修改候选配置。因此，客户机在修改候选配置之前锁定该配置是谨慎的。
The client can discard any uncommitted changes to the candidate configuration by executing the <discard-changes> operation. This operation reverts the contents of the candidate configuration to the contents of the running configuration.
客户端可以通过执行<discard changes>操作放弃对候选配置的任何未提交的更改。此操作将候选配置的内容还原为正在运行的配置的内容。
None.
没有一个
The :candidate capability is identified by the following capability string:
：候选能力由以下能力字符串标识：
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:candidate:1.0
Description:
说明：
When the candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration.
当候选配置的内容完成时，可以提交配置数据，将数据集发布到设备的其余部分，并请求设备符合新配置中描述的行为。
To commit the candidate configuration as the device's new current configuration, use the <commit> operation.
要将候选配置提交为设备的新当前配置，请使用<commit>操作。
The <commit> operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration.
<commit>操作指示设备实现候选配置中包含的配置数据。如果设备无法提交候选配置数据存储中的所有更改，则运行的配置必须保持不变。如果设备确实成功提交，则必须使用候选配置的内容更新正在运行的配置。
If the running or candidate configuration is currently locked by a different session, the <commit> operation MUST fail with an <error-tag> value of "in-use".
如果正在运行或候选配置当前被其他会话锁定，则<commit>操作必须失败，且<error tag>值为“in use”。
If the system does not have the :candidate capability, the <commit> operation is not available.
如果系统没有：候选功能，则<commit>操作不可用。
Positive Response:
积极回应：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response:
否定回答：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
If the client decides that the candidate configuration is not to be committed, the <discard-changes> operation can be used to revert the candidate configuration to the current running configuration.
如果客户端决定不提交候选配置，则可以使用<discard changes>操作将候选配置还原为当前正在运行的配置。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration.
此操作通过使用运行配置的内容重置候选配置来丢弃任何未提交的更改。
The candidate configuration can be used as a source or target of any <get-config>, <edit-config>, <copy-config>, or <validate> operation as a <source> or <target> parameter. The <candidate> element is used to indicate the candidate configuration:
候选配置可以用作任何<get config>、<edit config>、<copy config>或<validate>操作的源或目标，作为<source>或<target>参数。<candidate>元素用于指示候选配置：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
</get-config>
</rpc>
The candidate configuration can be locked using the <lock> operation with the <candidate> element as the <target> parameter:
可以使用<lock>操作将<candidate>元素作为<target>参数来锁定候选配置：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
Similarly, the candidate configuration is unlocked using the <candidate> element as the <target> parameter:
类似地，使用<candidate>元素作为<target>参数解锁候选配置：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the <unlock> operation or implicitly from session failure.
当客户机出现故障并对候选配置进行了未完成的更改时，恢复可能会很困难。为了便于恢复，释放锁时，无论是显式地使用<unlock>操作还是隐式地从会话失败中释放，都会丢弃任何未完成的更改。
The :confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation and the <confirmed>, <confirm-timeout>, <persist>, and <persist-id> parameters for the <commit> operation. See Section 8.3 for further details on the <commit> operation.
：confirm commit:1.1功能表示服务器将支持<cancel commit>操作以及<commit>操作的<confirm>、<confirm timeout>、<persist>和<persist id>参数。有关<commit>操作的更多详细信息，请参见第8.3节。
A confirmed <commit> operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a <commit> operation without the <confirmed> parameter. The timeout period can be adjusted with the <confirm-timeout> parameter. If a follow-up confirmed <commit> operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed <commit> operation MAY introduce additional changes to the configuration.
如果在超时期间（默认情况下600秒=10分钟）内未发出确认提交，则必须还原确认的<commit>操作。确认提交是一个没有<confirm>参数的<commit>操作。可以使用<confirm timeout>参数调整超时时间。如果在计时器到期之前发出后续确认的<commit>操作，计时器将重置为新值（默认为600秒）。确认提交和后续确认的<commit>操作都可能会对配置引入额外的更改。
If the <persist> element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the <persist> element is given in the confirmed <commit> operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a <persist-id> element with a value equal to the given value of the <persist> element.
如果确认提交操作中未给出<persist>元素，则必须在发出确认提交的同一会话上发出任何后续提交和确认提交。如果在确认的<commit>操作中给出了<persist>元素，则可以在任何会话上给出后续提交和确认提交，并且它们必须包含一个<persist id>元素，其值等于<persist>元素的给定值。
If the server also advertises the :startup capability, a <copy-config> from running to startup is also necessary to save the changes to startup.
如果服务器还播发：startup功能，则还需要从running到startup的<copy config>来保存对startup的更改。
If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a <persist> element.
如果发出确认提交的会话在确认超时到期之前因任何原因终止，则服务器必须将配置恢复到发出确认提交之前的状态，除非确认提交还包含<persist>元素。
If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued.
如果设备在确认超时过期之前因任何原因重新启动，服务器必须将配置恢复到发出确认提交之前的状态。
If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. To cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued, by using the <cancel-commit> operation.
如果未发出确认提交，则设备将其配置恢复到发出确认提交之前的状态。要在不等待确认超时过期的情况下取消确认提交并还原更改，客户端可以使用<cancel commit>操作将配置显式还原到发出确认提交之前的状态。
For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the <edit-config> operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration datastores, configuration locking SHOULD also be used.
对于共享配置，此功能可能会导致其他配置更改（例如，通过其他NETCONF会话）被意外更改或删除，除非使用了配置锁定功能（换句话说，锁定是在<edit config>操作启动之前获得的）。因此，强烈建议为了在共享配置数据存储中使用此功能，还应使用配置锁定。
Version 1.0 of this capability was defined in [RFC4741]. Version 1.1 is defined in this document, and extends version 1.0 by adding a new operation, <cancel-commit>, and two new optional parameters, <persist> and <persist-id>. For backwards compatibility with old clients, servers conforming to this specification MAY advertise version 1.0 in addition to version 1.1.
[RFC4741]中定义了该功能的1.0版。版本1.1在本文档中定义，并通过添加一个新操作<cancel commit>，以及两个新的可选参数<persist>和<persist id>来扩展版本1.0。为了与旧客户端向后兼容，符合本规范的服务器可能会在1.1版之外发布1.0版。
The :confirmed-commit:1.1 capability is only relevant if the :candidate capability is also supported.
：confirfied commit:1.1功能仅在：candidate功能也受支持时才相关。
The :confirmed-commit:1.1 capability is identified by the following capability string:
确认提交：1.1功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
Description:
说明：
Cancels an ongoing confirmed commit. If the <persist-id> parameter is not given, the <cancel-commit> operation MUST be issued on the same session that issued the confirmed commit.
取消正在进行的确认提交。如果未给出<persist id>参数，则必须在发出确认提交的同一会话上发出<cancel commit>操作。
Parameters:
参数：
persist-id:
持久id:
Cancels a persistent confirmed commit. The value MUST be equal to the value given in the <persist> parameter to the <commit> operation. If the value does not match, the operation fails with an "invalid-value" error.
取消持久确认提交。该值必须等于<commit>操作的<persist>参数中给定的值。如果值不匹配，则操作失败，并出现“无效值”错误。
Positive Response:
积极回应：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response:
否定回答：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
</commit>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-commit/>
</rpc>
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-commit/>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The :confirmed-commit:1.1 capability allows 4 additional parameters to the <commit> operation.
：confirm commit:1.1功能允许为<commit>操作添加4个额外参数。
Parameters:
参数：
confirmed:
确认：
Perform a confirmed <commit> operation.
执行确认的<commit>操作。
confirm-timeout:
确认超时：
Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds.
确认提交的超时时间，以秒为单位。如果未指定，确认超时默认为600秒。
persist:
坚持：
Make the confirmed commit survive a session termination, and set a token on the ongoing confirmed commit.
使确认的提交在会话终止后仍然有效，并在正在进行的确认提交上设置令牌。
persist-id:
持久id:
Used to issue a follow-up confirmed commit or a confirming commit from any session, with the token from the previous <commit> operation.
用于使用上一次<commit>操作中的令牌从任何会话发出后续确认提交或确认提交。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Example:
例子：
<!-- start a persistent confirmed-commit -->
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<persist>IQ,d4668</persist>
</commit>
</rpc>
<!-- start a persistent confirmed-commit -->
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<persist>IQ,d4668</persist>
</commit>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<!-- confirm the persistent confirmed-commit,
possibly from another session -->
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<persist-id>IQ,d4668</persist-id>
</commit>
</rpc>
<!-- confirm the persistent confirmed-commit,
possibly from another session -->
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<persist-id>IQ,d4668</persist-id>
</commit>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
This capability indicates that the server will support the "rollback-on-error" value in the <error-option> parameter to the <edit-config> operation.
此功能表示服务器将支持<edit config>操作的<error option>参数中的“rollback on error”值。
For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the <edit-config> operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration datastores, configuration locking also be used.
对于共享配置，此功能可能会导致其他配置更改（例如，通过其他NETCONF会话）被意外更改或删除，除非使用了配置锁定功能（换句话说，锁定是在<edit config>操作启动之前获得的）。因此，强烈建议为了在共享配置数据存储中使用此功能，还应使用配置锁定。
None.
没有一个
The :rollback-on-error capability is identified by the following capability string:
错误时回滚功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:rollback-on-error:1.0
None.
没有一个
The :rollback-on-error capability allows the "rollback-on-error" value to the <error-option> parameter on the <edit-config> operation.
：rollback on error功能允许将“rollback on error”值添加到<edit config>操作的<error option>参数中。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Validation consists of checking a complete configuration for syntactical and semantic errors before applying the configuration to the device.
验证包括在将配置应用于设备之前检查完整配置的语法和语义错误。
If this capability is advertised, the device supports the <validate> protocol operation and checks at least for syntax errors. In addition, this capability supports the <test-option> parameter to the <edit-config> operation and, when it is provided, checks at least for syntax errors.
如果公布此功能，则设备支持<validate>协议操作，并至少检查语法错误。此外，此功能支持<edit config>操作的<test option>参数，并且在提供该参数时，至少检查语法错误。
Version 1.0 of this capability was defined in [RFC4741]. Version 1.1 is defined in this document, and extends version 1.0 by adding a new value, "test-only", to the <test-option> parameter of the <edit-config> operation. For backwards compatibility with old clients, servers conforming to this specification MAY advertise version 1.0 in addition to version 1.1.
[RFC4741]中定义了该功能的1.0版。本文档中定义了1.1版，并通过在<edit config>操作的<test option>参数中添加一个新值“仅测试”，对1.0版进行了扩展。为了与旧客户端向后兼容，符合本规范的服务器可能会在1.1版之外发布1.0版。
None.
没有一个
The :validate:1.1 capability is identified by the following capability string:
验证：1.1功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:validate:1.1
Description:
说明：
This protocol operation validates the contents of the specified configuration.
此协议操作验证指定配置的内容。
Parameters:
参数：
source:
资料来源：
Name of the configuration datastore to validate, such as <candidate>, or the <config> element containing the complete configuration to validate.
要验证的配置数据存储的名称，例如<candidate>，或包含要验证的完整配置的<config>元素。
Positive Response:
积极回应：
If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element.
如果设备能够满足请求，则发送包含<ok>元素的<rpc reply>。
Negative Response:
否定回答：
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
如果由于任何原因无法完成请求，则<rpc error>元素将包含在<rpc reply>中。
A <validate> operation can fail for a number of reasons, such as syntax errors, missing parameters, references to undefined configuration data, or any other violations of rules established by the underlying data model.
<validate>操作可能由于多种原因而失败，例如语法错误、缺少参数、对未定义的配置数据的引用或任何其他违反基础数据模型建立的规则的行为。
Example:
例子：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The :validate:1.1 capability modifies the <edit-config> operation to accept the <test-option> parameter.
：validate:1.1功能修改<edit config>操作以接受<test option>参数。
The device supports separate running and startup configuration datastores. The startup configuration is loaded by the device when it boots. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit <copy-config> operation from the <running> to the <startup> is used to update the startup configuration to the current contents of the
该设备支持单独的运行和启动配置数据存储。启动配置由设备在引导时加载。影响运行配置的操作不会自动复制到启动配置。从<running>到<startup>的显式<copy config>操作用于将启动配置更新为
running configuration. NETCONF protocol operations refer to the startup datastore using the <startup> element.
运行配置。NETCONF协议操作是指使用<startup>元素的启动数据存储。
None.
没有一个
The :startup capability is identified by the following capability string:
：启动功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:startup:1.0
urn:ietf:params:netconf:capability:startup:1.0
None.
没有一个
The :startup capability adds the <startup/> configuration datastore to arguments of several NETCONF operations. The server MUST support the following additional values:
：startup功能将<startup/>配置数据存储添加到几个NETCONF操作的参数中。服务器必须支持以下附加值：
+--------------------+--------------------------+-------------------+
| Operation | Parameters | Notes |
+--------------------+--------------------------+-------------------+
| <get-config> | <source> | |
| | | |
| <copy-config> | <source> <target> | |
| | | |
| <lock> | <target> | |
| | | |
| <unlock> | <target> | |
| | | |
| <validate> | <source> | If :validate:1.1 |
| | | is advertised |
| | | |
| <delete-config> | <target> | Resets the device |
| | | to its factory |
| | | defaults |
+--------------------+--------------------------+-------------------+
+--------------------+--------------------------+-------------------+
| Operation | Parameters | Notes |
+--------------------+--------------------------+-------------------+
| <get-config> | <source> | |
| | | |
| <copy-config> | <source> <target> | |
| | | |
| <lock> | <target> | |
| | | |
| <unlock> | <target> | |
| | | |
| <validate> | <source> | If :validate:1.1 |
| | | is advertised |
| | | |
| <delete-config> | <target> | Resets the device |
| | | to its factory |
| | | defaults |
+--------------------+--------------------------+-------------------+
To save the startup configuration, use the <copy-config> operation to copy the <running> configuration datastore to the <startup> configuration datastore.
要保存启动配置，请使用<copy config>操作将<running>配置数据存储复制到<startup>配置数据存储。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
The NETCONF peer has the ability to accept the <url> element in <source> and <target> parameters. The capability is further identified by URL arguments indicating the URL schemes supported.
NETCONF对等方能够接受<source>和<target>参数中的<url>元素。该功能通过指示支持的URL方案的URL参数进一步标识。
None.
没有一个
The :url capability is identified by the following capability string:
：url功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}
The :url capability URI MUST contain a "scheme" argument assigned a comma-separated list of scheme names indicating which schemes the NETCONF peer supports. For example:
：url功能URI必须包含一个“scheme”参数，该参数指定了一个逗号分隔的方案名称列表，该列表指示NETCONF对等方支持哪些方案。例如：
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file
None.
没有一个
The :url capability modifies the <edit-config> operation to accept the <url> element as an alternative to the <config> parameter.
：url功能修改<edit config>操作以接受<url>元素作为<config>参数的替代。
The file that the url refers to contains the configuration data hierarchy to be modified, encoded in XML under the element <config> in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
url引用的文件包含要修改的配置数据层次结构，在“urn:ietf:params:XML:ns:netconf:base:1.0”命名空间中的元素<config>下用XML编码。
The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters.
：url功能修改<copy config>操作以接受<url>元素作为<source>和<target>参数的值。
The file that the url refers to contains the complete datastore, encoded in XML under the element <config> in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
url引用的文件包含完整的数据存储，在“urn:ietf:params:XML:ns:netconf:base:1.0”命名空间中的元素<config>下以XML编码。
The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters.
：url功能修改<delete config>操作以接受<url>元素作为<target>参数的值。
The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.
：url功能修改<validate>操作以接受<url>元素作为<source>参数的值。
The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the <filter> element. XPath is described in [W3C.REC-xpath-19991116].
XPath功能表明NETCONF对等方支持在<filter>元素中使用XPath表达式。[W3C.REC-XPath-19991116]中描述了XPath。
The data model used in the XPath expression is the same as that used in XPath 1.0 [W3C.REC-xpath-19991116], with the same extension for root node children as used by XSLT 1.0 ([W3C.REC-xslt-19991116], Section 3.1). Specifically, it means that the root node MAY have any number of element nodes as its children.
XPath表达式中使用的数据模型与XPath 1.0中使用的数据模型相同[W3C.REC-XPath-19991116]，根节点子节点的扩展与XSLT 1.0使用的相同（[W3C.REC-XSLT-19991116]，第3.1节）。具体来说，这意味着根节点可以有任意数量的元素节点作为其子节点。
The XPath expression is evaluated in the following context:
XPath表达式在以下上下文中求值：
o The set of namespace declarations are those in scope on the <filter> element.
o 命名空间声明集是<filter>元素作用域中的声明。
o The set of variable bindings is defined by the data model. If no such variable bindings are defined, the set is empty.
o 变量绑定集由数据模型定义。如果未定义此类变量绑定，则该集为空。
o The function library is the core function library, plus any functions defined by the data model.
o 函数库是核心函数库，加上数据模型定义的任何函数。
o The context node is the root node.
o 上下文节点是根节点。
The XPath expression MUST return a node set. If it does not return a node set, the operation fails with an "invalid-value" error.
XPath表达式必须返回节点集。如果不返回节点集，操作将失败，并出现“无效值”错误。
The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. Specific data instances are not duplicated in the response.
响应消息包含筛选器表达式选择的子树。对于每个这样的子树，响应消息中包括从数据模型根节点到子树的路径，包括唯一标识子树所需的任何元素或属性。响应中不复制特定的数据实例。
None.
没有一个
The :xpath capability is identified by the following capability string:
：xpath功能由以下功能字符串标识：
urn:ietf:params:netconf:capability:xpath:1.0
urn:ietf:params:netconf:capability:xpath:1.0
None.
没有一个
The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the "type" attribute of the <filter> element. When the "type" attribute is set to "xpath", a "select" attribute MUST be present on the <filter> element. The "select" attribute will be treated as an XPath expression and used to filter the returned data. The <filter> element itself MUST be empty in this case.
：xpath功能修改<get>和<get config>操作，以接受<filter>元素的“type”属性中的值“xpath”。当“type”属性设置为“xpath”时，<filter>元素上必须存在一个“select”属性。“select”属性将被视为XPath表达式，并用于过滤返回的数据。在这种情况下，<filter>元素本身必须为空。
The XPath result for the select expression MUST be a node-set. Each node in the node-set MUST correspond to a node in the underlying data model. In order to properly identify each node, the following encoding rules are defined:
select表达式的XPath结果必须是节点集。节点集中的每个节点必须对应于基础数据模型中的一个节点。为了正确识别每个节点，定义了以下编码规则：
o All ancestor nodes of the result node MUST be encoded first, so the <data> element returned in the reply contains only fully specified subtrees, according to the underlying data model.
o 必须首先对结果节点的所有祖先节点进行编码，因此根据底层数据模型，回复中返回的<data>元素只包含完全指定的子树。
o If any sibling or ancestor nodes of the result node are needed to identify a particular instance within a conceptual data structure, then these nodes MUST also be encoded in the response.
o 如果需要结果节点的任何兄弟节点或祖先节点来标识概念数据结构中的特定实例，那么这些节点也必须在响应中进行编码。
For example:
例如：
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<!-- get the user named fred -->
<filter xmlns:t="http://example.com/schema/1.2/config"
type="xpath"
select="/t:top/t:users/t:user[t:name='fred']"/>
</get-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<!-- get the user named fred -->
<filter xmlns:t="http://example.com/schema/1.2/config"
type="xpath"
select="/t:top/t:users/t:user[t:name='fred']"/>
</get-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
<company-info>
<id>2</id>
</company-info>
</user>
</users>
</top>
</data>
</rpc-reply>
This section provides security considerations for the base NETCONF message layer and the base operations of the NETCONF protocol. Security considerations for the NETCONF transports are provided in the transport documents, and security considerations for the content manipulated by NETCONF can be found in the documents defining data models.
本节提供基本NETCONF消息层和NETCONF协议的基本操作的安全注意事项。传输文档中提供了NETCONF传输的安全注意事项，NETCONF操作的内容的安全注意事项可以在定义数据模型的文档中找到。
This document does not specify an authorization scheme, as such a scheme will likely be tied to a meta-data model or a data model. Implementors SHOULD provide a comprehensive authorization scheme with NETCONF.
本文档未指定授权方案，因为此类方案可能与元数据模型或数据模型相关联。实现者应该使用NETCONF提供一个全面的授权方案。
Authorization of individual users via the NETCONF server may or may not map 1:1 to other interfaces. First, the data models might be incompatible. Second, it could be desirable to authorize based on mechanisms available in the Secure Transport layer (e.g., SSH, Blocks Extensible Exchange Protocol (BEEP), etc.).
通过NETCONF服务器对单个用户的授权可能会也可能不会将1:1映射到其他接口。首先，数据模型可能不兼容。其次，可能需要基于安全传输层中可用的机制（例如SSH、块可扩展交换协议（BEEP）等）进行授权。
In addition, operations on configurations could have unintended consequences if those operations are also not guarded by the global lock on the files or objects being operated upon. For instance, if the running configuration is not locked, a partially complete access list could be committed from the candidate configuration unbeknownst to the owner of the lock of the candidate configuration, leading to either an insecure or inaccessible device.
此外，如果配置上的操作也不受正在操作的文件或对象的全局锁保护，则这些操作可能会产生意外后果。例如，如果未锁定正在运行的配置，则可能会在未知的情况下将部分完整的访问列表从候选配置提交给候选配置锁的所有者，从而导致设备不安全或无法访问。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces.
配置信息本质上是敏感的。它以清晰且无完整性检查的方式传输，使设备容易受到经典的窃听和虚假数据注入攻击。配置信息通常包含密码、用户名、服务描述和拓扑信息，所有这些信息都是敏感的。因此，应仔细实施该协议，并充分注意可能在其他管理接口中遇到的各种攻击。
The protocol, therefore, MUST minimally support options for both confidentiality and authentication. It is anticipated that the underlying protocol (SSH, BEEP, etc.) will provide for both confidentiality and authentication, as is required. It is further expected that the identity of each end of a NETCONF session will be available to the other in order to determine authorization for any given request. One could also easily envision additional information, such as transport and encryption methods, being made available for purposes of authorization. NETCONF itself provides no means to re-authenticate, much less authenticate. All such actions occur at lower layers.
因此，协议必须至少支持机密性和身份验证选项。预计底层协议（SSH、BEEP等）将根据需要提供机密性和身份验证。此外，还期望NETCONF会话的每一端的标识将可供另一端使用，以便确定对任何给定请求的授权。人们还可以很容易地设想为授权目的提供额外的信息，如传输和加密方法。NETCONF本身不提供重新验证的方法，更不用说验证了。所有这些动作都发生在较低层。
Different environments may well allow different rights prior to and then after authentication. Thus, an authorization model is not specified in this document. When an operation is not properly authorized, a simple "access denied" is sufficient. Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection.
在身份验证之前和之后，不同的环境可能允许不同的权限。因此，本文档中未指定授权模型。当一个操作没有得到适当授权时，简单的“拒绝访问”就足够了。请注意，可以以配置信息的形式交换授权信息，这更是确保连接安全的原因。
That having been said, it is important to recognize that some operations are clearly more sensitive by nature than others. For instance, <copy-config> to the startup or running configurations is clearly not a normal provisioning operation, whereas <edit-config> is. Such global operations MUST disallow the changing of information
尽管如此，重要的是要认识到，某些行动显然比其他行动更敏感。例如，<copy config>到启动或运行配置显然不是正常的配置操作，而<edit config>则是。这种全球行动必须禁止信息的更改
that an individual does not have authorization to perform. For example, if user A is not allowed to configure an IP address on an interface but user B has configured an IP address on an interface in the <candidate> configuration, user A MUST NOT be allowed to commit the <candidate> configuration.
个人没有执行的授权。例如，如果不允许用户A在接口上配置IP地址，但用户B在<candidate>配置中在接口上配置了IP地址，则不得允许用户A提交<candidate>配置。
Similarly, just because someone says "go write a configuration through the URL capability at a particular place", this does not mean that an element will do it without proper authorization.
类似地，仅仅因为有人说“在特定位置通过URL功能编写配置”，这并不意味着元素将在没有适当授权的情况下进行配置。
The <lock> operation will demonstrate that NETCONF is intended for use by systems that have at least some trust of the administrator. As specified in this document, it is possible to lock portions of a configuration that a principal might not otherwise have access to. After all, the entire configuration is locked. To mitigate this problem, there are two approaches. It is possible to kill another NETCONF session programmatically from within NETCONF if one knows the session identifier of the offending session. The other possible way to break a lock is to provide a function within the device's native user interface. These two mechanisms suffer from a race condition that could be ameliorated by removing the offending user from an Authentication, Authorization, and Accounting (AAA) server. However, such a solution is not useful in all deployment scenarios, such as those where SSH public/private key pairs are used.
<lock>操作将证明NETCONF供至少对管理员有一定信任的系统使用。如本文所述，可以锁定主体可能无法访问的配置部分。毕竟，整个配置都被锁定了。要缓解此问题，有两种方法。如果知道有问题会话的会话标识符，可以从NETCONF中以编程方式终止另一个NETCONF会话。打破锁定的另一种可能方式是在设备的本机用户界面中提供功能。这两种机制存在竞争情况，可以通过从身份验证、授权和记帐（AAA）服务器中删除违规用户来改善这种情况。但是，这样的解决方案并不是在所有部署场景中都有用，例如使用SSH公钥/私钥对的场景。
This document registers a URI for the NETCONF XML namespace in the IETF XML registry [RFC3688].
本文档在IETF XML注册表[RFC3688]中注册NETCONF XML命名空间的URI。
IANA has updated the following URI to reference this document.
IANA已更新以下URI以引用此文档。
URI: urn:ietf:params:xml:ns:netconf:base:1.0
URI: urn:ietf:params:xml:ns:netconf:base:1.0
Registrant Contact: The IESG.
注册人联系人：IESG。
XML: N/A, the requested URI is an XML namespace.
XML:N/A，请求的URI是一个XML名称空间。
This document registers a URI for the NETCONF XML schema in the IETF XML registry [RFC3688].
本文档在IETF XML注册表[RFC3688]中注册NETCONF XML模式的URI。
IANA has updated the following URI to reference this document.
IANA已更新以下URI以引用此文档。
URI: urn:ietf:params:xml:schema:netconf
URI: urn:ietf:params:xml:schema:netconf
Registrant Contact: The IESG.
注册人联系人：IESG。
XML: Appendix B of this document.
XML：本文件附录B。
This document registers a YANG module in the YANG Module Names registry [RFC6020].
本文档在YANG模块名称注册表[RFC6020]中注册YANG模块。
name: ietf-netconf
namespace: urn:ietf:params:xml:ns:netconf:base:1.0
prefix: nc
reference: RFC 6241
name: ietf-netconf
namespace: urn:ietf:params:xml:ns:netconf:base:1.0
prefix: nc
reference: RFC 6241
IANA has created and now maintains a registry "Network Configuration Protocol (NETCONF) Capability URNs" that allocates NETCONF capability identifiers. Additions to the registry require IETF Standards Action.
IANA已经创建并维护了一个注册表“网络配置协议（NETCONF）能力URN”，用于分配NETCONF能力标识符。添加到注册表需要IETF标准操作。
IANA has updated the allocations of the following capabilities to reference this document.
IANA已更新了以下功能的分配，以参考本文档。
Index
Capability Identifier
------------------------
Index
Capability Identifier
------------------------
:writable-running
urn:ietf:params:netconf:capability:writable-running:1.0
:writable-running
urn:ietf:params:netconf:capability:writable-running:1.0
:candidate
urn:ietf:params:netconf:capability:candidate:1.0
:candidate
urn:ietf:params:netconf:capability:candidate:1.0
:rollback-on-error
urn:ietf:params:netconf:capability:rollback-on-error:1.0
:rollback-on-error
urn:ietf:params:netconf:capability:rollback-on-error:1.0
:startup
urn:ietf:params:netconf:capability:startup:1.0
:startup
urn:ietf:params:netconf:capability:startup:1.0
:url
urn:ietf:params:netconf:capability:url:1.0
:url
urn:ietf:params:netconf:capability:url:1.0
:xpath
urn:ietf:params:netconf:capability:xpath:1.0
:xpath
urn:ietf:params:netconf:capability:xpath:1.0
IANA has added the following capabilities to the registry:
IANA已将以下功能添加到注册表中：
Index
Capability Identifier
------------------------
Index
Capability Identifier
------------------------
:base:1.1
urn:ietf:params:netconf:base:1.1
:base:1.1
urn:ietf:params:netconf:base:1.1
:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
:confirmed-commit:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
:validate:1.1
urn:ietf:params:netconf:capability:validate:1.1
:validate:1.1
urn:ietf:params:netconf:capability:validate:1.1
In addition to the editors, this document was written by:
除编辑外，本文件由以下人员编写：
Ken Crozier, Cisco Systems
Ken Crozier，思科系统公司
Ted Goddard, IceSoft
特德·戈达德，冰软
Eliot Lear, Cisco Systems
艾略特·李尔，思科系统公司
Phil Shafer, Juniper Networks
Phil Shafer，Juniper Networks
Steve Waldbusser
史蒂夫·瓦尔德布瑟
Margaret Wasserman, Painless Security, LLC
Margaret Wasserman，无痛安全有限责任公司
The authors would like to acknowledge the members of the NETCONF working group. In particular, we would like to thank Wes Hardaker for his persistence and patience in assisting us with security considerations. We would also like to thank Randy Presuhn, Sharon Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch, and Kent Watsen for all of their valuable advice.
提交人要感谢NETCONF工作组的成员。特别是，我们要感谢韦斯·哈达克（Wes Hardaker）在协助我们处理安全问题方面的坚持不懈和耐心。我们还要感谢Randy Presohn、Sharon Chisholm、Glenn Waters、David Perkins、Weijing Chen、Simon Leinen、Keith Allen、Dave Harrington、Ladislav Lhotka、Tom Petch和Kent Watsen提供的宝贵建议。
[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月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，2003年6月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009.
[RFC5717]Lengyel，B.和M.Bjorklund，“NETCONF的部分锁远程过程调用（RPC）”，RFC 57172009年12月。
[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月。
[RFC6242] Wasserman, M., "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", RFC 6242, June 2011.
[RFC6242]Wasserman，M.“在安全外壳（SSH）上使用NETCONF配置协议”，RFC6242，2011年6月。
[W3C.REC-xml-20001006] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-xml-20001006]Sperberg McQueen，C.，Bray，T.，Paoli，J.，和E.Maler，“可扩展标记语言（xml）1.0（第二版）”，万维网联盟REC-xml-20001006，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
[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>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[W3C.REC-xslt-19991116] 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>.
[W3C.REC-xslt-19991116]Clark，J.，“XSL转换（xslt）1.0版”，万维网联盟建议REC-xslt-19991116，1999年11月<http://www.w3.org/TR/1999/REC-xslt-19991116>.
This section is normative.
本节是规范性的。
For each error-tag, the valid error-type and error-severity values are listed, together with any mandatory error-info, if any.
对于每个错误标记，将列出有效的错误类型和错误严重性值，以及任何必需的错误信息（如果有）。
error-tag: in-use error-type: protocol, application error-severity: error error-info: none Description: The request requires a resource that already is in use.
错误标记：正在使用错误类型：协议，应用程序错误严重性：错误信息：无描述：请求需要已在使用的资源。
error-tag: invalid-value error-type: protocol, application error-severity: error error-info: none Description: The request specifies an unacceptable value for one or more parameters.
错误标记：无效值错误类型：协议，应用程序错误严重性：错误信息：无说明：请求为一个或多个参数指定了不可接受的值。
error-tag: too-big error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle.
错误标记：太大错误类型：传输、rpc、协议、应用程序错误严重性：错误信息：无描述：请求或响应（将生成）太大，实现无法处理。
error-tag: missing-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the missing attribute <bad-element> : name of the element that is supposed to contain the missing attribute Description: An expected attribute is missing.
错误标记：缺少属性错误类型：rpc、协议、应用程序错误严重性：错误信息：<bad attribute>：缺少属性的名称<bad element>：应该包含缺少属性的元素的名称描述：缺少预期属性。
error-tag: bad-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the attribute w/ bad value <bad-element> : name of the element that contains the attribute with the bad value Description: An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch.
错误标签：错误属性错误类型：rpc、协议、应用程序错误严重性：错误信息：<bad attribute>：属性名称w/错误值<bad element>：包含具有错误值的属性的元素名称说明：属性值不正确；e、 例如，类型错误、超出范围、图案不匹配。
error-tag: unknown-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the unexpected attribute <bad-element> : name of the element that contains the unexpected attribute Description: An unexpected attribute is present.
错误标记：未知属性错误类型：rpc、协议、应用程序错误严重性：错误信息：<bad attribute>：意外属性的名称<bad element>：包含意外属性的元素的名称描述：存在意外属性。
error-tag: missing-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the missing element Description: An expected element is missing.
错误标记：缺少元素错误类型：协议，应用程序错误严重性：错误信息：<bad element>：缺少元素的名称说明：缺少预期的元素。
error-tag: bad-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch.
错误标签：错误元素错误类型：协议，应用程序错误严重性：错误错误信息：<bad element>：元素名称w/错误值说明：元素值不正确；e、 例如，类型错误、超出范围、图案不匹配。
error-tag: unknown-element error-type: protocol, application error-severity: error error-info: <bad-element> : name of the unexpected element Description: An unexpected element is present.
错误标记：未知元素错误类型：协议，应用程序错误严重性：错误信息：<bad element>：意外元素的名称说明：存在意外元素。
error-tag: unknown-namespace error-type: protocol, application error-severity: error error-info: <bad-element> : name of the element that contains the unexpected namespace <bad-namespace> : name of the unexpected namespace Description: An unexpected namespace is present.
错误标记：未知命名空间错误类型：协议，应用程序错误严重性：错误错误信息：<bad element>：包含意外命名空间的元素名称<bad namespace>：意外命名空间的名称说明：存在意外命名空间。
error-tag: access-denied error-type: protocol, application error-severity: error error-info: none Description: Access to the requested protocol operation or data model is denied because authorization failed.
错误标记：访问被拒绝错误类型：协议，应用程序错误严重性：错误信息：无描述：由于授权失败，对请求的协议操作或数据模型的访问被拒绝。
error-tag: lock-denied error-type: protocol error-severity: error error-info: <session-id> : session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock Description: Access to the requested lock is denied because the lock is currently held by another entity.
错误标记：锁被拒绝错误类型：协议错误严重性：错误错误信息：<session id>：持有请求锁的会话的会话id，或零表示非NETCONF实体持有锁描述：拒绝访问请求的锁，因为锁当前由另一个实体持有。
error-tag: resource-denied error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: Request could not be completed because of insufficient resources.
错误标记：资源被拒绝错误类型：传输、rpc、协议、应用程序错误严重性：错误信息：无描述：由于资源不足，无法完成请求。
error-tag: rollback-failed error-type: protocol, application error-severity: error error-info: none Description: Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason.
错误标记：回滚失败错误类型：协议，应用程序错误严重性：错误错误信息：无描述：由于某种原因，回滚某些配置更改的请求（通过错误时回滚或<discard changes>操作）未完成。
error-tag: data-exists error-type: application error-severity: error error-info: none Description: Request could not be completed because the relevant data model content already exists. For example, a "create" operation was attempted on data that already exists.
错误标记：数据存在错误类型：应用程序错误严重性：错误信息：无描述：无法完成请求，因为相关数据模型内容已存在。例如，尝试对已存在的数据执行“创建”操作。
error-tag: data-missing error-type: application error-severity: error error-info: none Description: Request could not be completed because the relevant data model content does not exist. For example, a "delete" operation was attempted on data that does not exist.
错误标记：数据丢失错误类型：应用程序错误严重性：错误信息：无描述：由于相关数据模型内容不存在，无法完成请求。例如，尝试对不存在的数据执行“删除”操作。
error-tag: operation-not-supported error-type: protocol, application error-severity: error error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation.
错误标记：操作不受支持错误类型：协议，应用程序错误严重性：错误信息：无描述：无法完成请求，因为此实现不支持请求的操作。
error-tag: operation-failed error-type: rpc, protocol, application error-severity: error error-info: none Description: Request could not be completed because the requested operation failed for some reason not covered by any other error condition.
错误标记：操作失败错误类型：rpc、协议、应用程序错误严重性：错误错误信息：无描述：请求无法完成，因为请求的操作因某些原因失败，而不包括在任何其他错误条件中。
error-tag: partial-operation error-type: application error-severity: error error-info: <ok-element> : identifies an element in the data model for which the requested operation has been completed for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.
错误标记：部分操作错误类型：应用程序错误严重性：错误错误信息：<ok element>：标识数据模型中已完成该节点及其所有子节点的请求操作的元素。此元素可以在<error info>容器中出现零次或多次。
<err-element> : identifies an element in the data model for which the requested operation has failed for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.
<err element>：标识数据模型中该节点及其所有子节点的请求操作失败的元素。此元素可以在<error info>容器中出现零次或多次。
<noop-element> : identifies an element in the data model for which the requested operation was not attempted for that node and all its child nodes. This element can appear zero or more times in the <error-info> container.
<noop element>：标识数据模型中的一个元素，该节点及其所有子节点未尝试对该元素执行请求的操作。此元素可以在<error info>容器中出现零次或多次。
Description: This error-tag is obsolete, and SHOULD NOT be sent by servers conforming to this document.
说明：此错误标签已过时，不应由符合本文件要求的服务器发送。
Some part of the requested operation failed or was not attempted for some reason. Full cleanup has not been performed (e.g., rollback not supported) by the server. The error-info container is used to identify which portions of the application data model content for which the requested operation has succeeded (<ok-element>), failed (<bad-element>), or not been attempted (<noop-element>).
请求的操作的某些部分失败或由于某种原因未尝试。服务器尚未执行完全清理（例如，不支持回滚）。错误信息容器用于标识请求的操作已成功（<ok element>）、失败（<bad element>）或未尝试（<noop element>）的应用程序数据模型内容的哪些部分。
error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set.
错误标记：格式错误的消息错误类型：rpc错误严重性：错误信息：无描述：无法处理消息，因为无法正确分析该消息。例如，消息不是格式良好的XML，或者它使用了无效的字符集。
This error-tag is new in :base:1.1 and MUST NOT be sent to old clients.
此错误标记在：base:1.1中是新的，不能发送到旧客户端。
This section is normative.
本节是规范性的。
<CODE BEGINS> file "netconf.xsd"
<CODE start>文件“netconf.xsd”
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en"
version="1.1">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xml:lang="en"
version="1.1">
<xs:annotation>
<xs:documentation>
This schema defines the syntax for the NETCONF Messages layer
messages 'hello', 'rpc', and 'rpc-reply'.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation>
This schema defines the syntax for the NETCONF Messages layer
messages 'hello', 'rpc', and 'rpc-reply'.
</xs:documentation>
</xs:annotation>
<!--
import standard XML definitions
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xs:annotation>
<xs:documentation>
This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element.
</xs:documentation>
</xs:annotation>
</xs:import>
<!--
message-id attribute
-->
<!--
import standard XML definitions
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xs:annotation>
<xs:documentation>
This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element.
</xs:documentation>
</xs:annotation>
</xs:import>
<!--
message-id attribute
-->
<xs:simpleType name="messageIdType">
<xs:restriction base="xs:string">
<xs:maxLength value="4095"/>
</xs:restriction>
</xs:simpleType>
<!--
Types used for session-id
-->
<xs:simpleType name="SessionId">
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SessionIdOrZero">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<!--
<rpc> element
-->
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType"
use="required"/>
<!--
Arbitrary attributes can be supplied with <rpc> element.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
<!--
data types and elements used to construct rpc-errors
-->
<xs:simpleType name="ErrorType">
<xs:restriction base="xs:string">
<xs:enumeration value="transport"/>
<xs:enumeration value="rpc"/>
<xs:enumeration value="protocol"/>
<xs:enumeration value="application"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorTag">
<xs:restriction base="xs:string">
<xs:enumeration value="in-use"/>
<xs:enumeration value="invalid-value"/>
<xs:enumeration value="too-big"/>
<xs:enumeration value="missing-attribute"/>
<xs:simpleType name="messageIdType">
<xs:restriction base="xs:string">
<xs:maxLength value="4095"/>
</xs:restriction>
</xs:simpleType>
<!--
Types used for session-id
-->
<xs:simpleType name="SessionId">
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SessionIdOrZero">
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<!--
<rpc> element
-->
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType"
use="required"/>
<!--
Arbitrary attributes can be supplied with <rpc> element.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
<!--
data types and elements used to construct rpc-errors
-->
<xs:simpleType name="ErrorType">
<xs:restriction base="xs:string">
<xs:enumeration value="transport"/>
<xs:enumeration value="rpc"/>
<xs:enumeration value="protocol"/>
<xs:enumeration value="application"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorTag">
<xs:restriction base="xs:string">
<xs:enumeration value="in-use"/>
<xs:enumeration value="invalid-value"/>
<xs:enumeration value="too-big"/>
<xs:enumeration value="missing-attribute"/>
<xs:enumeration value="bad-attribute"/>
<xs:enumeration value="unknown-attribute"/>
<xs:enumeration value="missing-element"/>
<xs:enumeration value="bad-element"/>
<xs:enumeration value="unknown-element"/>
<xs:enumeration value="unknown-namespace"/>
<xs:enumeration value="access-denied"/>
<xs:enumeration value="lock-denied"/>
<xs:enumeration value="resource-denied"/>
<xs:enumeration value="rollback-failed"/>
<xs:enumeration value="data-exists"/>
<xs:enumeration value="data-missing"/>
<xs:enumeration value="operation-not-supported"/>
<xs:enumeration value="operation-failed"/>
<xs:enumeration value="partial-operation"/>
<xs:enumeration value="malformed-message"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorSeverity">
<xs:restriction base="xs:string">
<xs:enumeration value="error"/>
<xs:enumeration value="warning"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="errorInfoType">
<xs:sequence>
<xs:choice>
<xs:element name="session-id" type="SessionIdOrZero"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:sequence>
<xs:element name="bad-attribute" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="ok-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="err-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="noop-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-namespace" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
<!-- elements from any other namespace are also allowed
to follow the NETCONF elements -->
<xs:any namespace="##other" processContents="lax"
<xs:enumeration value="bad-attribute"/>
<xs:enumeration value="unknown-attribute"/>
<xs:enumeration value="missing-element"/>
<xs:enumeration value="bad-element"/>
<xs:enumeration value="unknown-element"/>
<xs:enumeration value="unknown-namespace"/>
<xs:enumeration value="access-denied"/>
<xs:enumeration value="lock-denied"/>
<xs:enumeration value="resource-denied"/>
<xs:enumeration value="rollback-failed"/>
<xs:enumeration value="data-exists"/>
<xs:enumeration value="data-missing"/>
<xs:enumeration value="operation-not-supported"/>
<xs:enumeration value="operation-failed"/>
<xs:enumeration value="partial-operation"/>
<xs:enumeration value="malformed-message"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ErrorSeverity">
<xs:restriction base="xs:string">
<xs:enumeration value="error"/>
<xs:enumeration value="warning"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="errorInfoType">
<xs:sequence>
<xs:choice>
<xs:element name="session-id" type="SessionIdOrZero"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:sequence>
<xs:element name="bad-attribute" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="ok-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="err-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="noop-element" type="xs:QName"
minOccurs="0" maxOccurs="1"/>
<xs:element name="bad-namespace" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
<!-- elements from any other namespace are also allowed
to follow the NETCONF elements -->
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rpcErrorType">
<xs:sequence>
<xs:element name="error-type" type="ErrorType"/>
<xs:element name="error-tag" type="ErrorTag"/>
<xs:element name="error-severity" type="ErrorSeverity"/>
<xs:element name="error-app-tag" type="xs:string"
minOccurs="0"/>
<xs:element name="error-path" type="xs:string" minOccurs="0"/>
<xs:element name="error-message" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="error-info" type="errorInfoType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--
operation attribute used in <edit-config>
-->
<xs:simpleType name="editOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="merge"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="create"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="remove"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="operation" type="editOperationType"/>
<!--
<rpc-reply> element
-->
<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:sequence>
<xs:element ref="rpc-error"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="rpcResponse"
minOccurs="0" maxOccurs="unbounded"/>
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rpcErrorType">
<xs:sequence>
<xs:element name="error-type" type="ErrorType"/>
<xs:element name="error-tag" type="ErrorTag"/>
<xs:element name="error-severity" type="ErrorSeverity"/>
<xs:element name="error-app-tag" type="xs:string"
minOccurs="0"/>
<xs:element name="error-path" type="xs:string" minOccurs="0"/>
<xs:element name="error-message" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="error-info" type="errorInfoType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!--
operation attribute used in <edit-config>
-->
<xs:simpleType name="editOperationType">
<xs:restriction base="xs:string">
<xs:enumeration value="merge"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="create"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="remove"/>
</xs:restriction>
</xs:simpleType>
<xs:attribute name="operation" type="editOperationType"/>
<!--
<rpc-reply> element
-->
<xs:complexType name="rpcReplyType">
<xs:choice>
<xs:element name="ok"/>
<xs:sequence>
<xs:element ref="rpc-error"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="rpcResponse"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:choice>
<xs:attribute name="message-id" type="messageIdType"
use="optional"/>
<!--
Any attributes supplied with <rpc> element must be returned
on <rpc-reply>.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc-reply" type="rpcReplyType"/>
<!--
<rpc-error> element
-->
<xs:element name="rpc-error" type="rpcErrorType"/>
<!--
rpcOperationType: used as a base type for all
NETCONF operations
-->
<xs:complexType name="rpcOperationType"/>
<xs:element name="rpcOperation" type="rpcOperationType"
abstract="true"/>
<!--
rpcResponseType: used as a base type for all
NETCONF responses
-->
<xs:complexType name="rpcResponseType"/>
<xs:element name="rpcResponse" type="rpcResponseType"
abstract="true"/>
<!--
<hello> element
-->
<xs:element name="hello">
<xs:complexType>
<xs:sequence>
<xs:element name="capabilities">
<xs:complexType>
<xs:sequence>
<xs:element name="capability" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="session-id" type="SessionId"
minOccurs="0"/>
</xs:sequence>
</xs:choice>
<xs:attribute name="message-id" type="messageIdType"
use="optional"/>
<!--
Any attributes supplied with <rpc> element must be returned
on <rpc-reply>.
-->
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc-reply" type="rpcReplyType"/>
<!--
<rpc-error> element
-->
<xs:element name="rpc-error" type="rpcErrorType"/>
<!--
rpcOperationType: used as a base type for all
NETCONF operations
-->
<xs:complexType name="rpcOperationType"/>
<xs:element name="rpcOperation" type="rpcOperationType"
abstract="true"/>
<!--
rpcResponseType: used as a base type for all
NETCONF responses
-->
<xs:complexType name="rpcResponseType"/>
<xs:element name="rpcResponse" type="rpcResponseType"
abstract="true"/>
<!--
<hello> element
-->
<xs:element name="hello">
<xs:complexType>
<xs:sequence>
<xs:element name="capabilities">
<xs:complexType>
<xs:sequence>
<xs:element name="capability" type="xs:anyURI"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="session-id" type="SessionId"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<CODE ENDS>
<代码结束>
This section is normative.
本节是规范性的。
The ietf-netconf YANG module imports typedefs from [RFC6021].
ietf网络配置模块从[RFC6021]导入TypeDef。
<CODE BEGINS> file "ietf-netconf@2011-06-01.yang"
<CODE BEGINS> file "ietf-netconf@2011-06-01.yang"
module ietf-netconf {
ietf网络配置模块{
// the namespace for NETCONF XML definitions is unchanged
// from RFC 4741, which this document replaces
namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
// the namespace for NETCONF XML definitions is unchanged
// from RFC 4741, which this document replaces
namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
prefix nc;
前缀nc；
import ietf-inet-types {
prefix inet;
}
import ietf-inet-types {
prefix inet;
}
organization "IETF NETCONF (Network Configuration) Working Group";
组织“IETF网络配置工作组”；
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <netconf@ietf.org>
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <netconf@ietf.org>
WG Chair: Bert Wijnen
<bertietf@bwijnen.net>
WG Chair: Bert Wijnen
<bertietf@bwijnen.net>
WG Chair: Mehmet Ersue
<mehmet.ersue@nsn.com>
WG Chair: Mehmet Ersue
<mehmet.ersue@nsn.com>
Editor: Martin Bjorklund
<mbj@tail-f.com>
Editor: Martin Bjorklund
<mbj@tail-f.com>
Editor: Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de>
Editor: Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de>
Editor: Andy Bierman
<andy.bierman@brocade.com>";
Editor: Andy Bierman
<andy.bierman@brocade.com>";
description "NETCONF Protocol Data Types and Protocol Operations.
说明“NETCONF协议数据类型和协议操作。
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 Relating to IETF Documents (http://trustee.ietf.org/license-info).
根据IETF信托有关IETF文件的法律规定第4.c节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 6241; see
the RFC itself for full legal notices.";
revision 2011-06-01 {
description
"Initial revision";
reference
"RFC 6241: Network Configuration Protocol";
}
This version of this YANG module is part of RFC 6241; see
the RFC itself for full legal notices.";
revision 2011-06-01 {
description
"Initial revision";
reference
"RFC 6241: Network Configuration Protocol";
}
extension get-filter-element-attributes { description "If this extension is present within an 'anyxml' statement named 'filter', which must be conceptually defined within the RPC input section for the <get> and <get-config> protocol operations, then the following unqualified XML attribute is supported within the <filter> element, within a <get> or <get-config> protocol operation:
扩展获取筛选器元素属性{说明“如果此扩展名存在于名为'filter'的'anyxml'语句中，必须在RPC输入节中为<get>和<get config>协议操作从概念上定义该语句，则<filter>元素中的<get>或<get config>协议操作中支持以下非限定XML属性：
type : optional attribute with allowed value strings 'subtree' and 'xpath'. If missing, the default value is 'subtree'.
类型：可选属性，具有允许的值字符串“subtree”和“xpath”。如果缺少，默认值为“子树”。
If the 'xpath' feature is supported, then the following unqualified XML attribute is also supported:
如果支持“xpath”功能，则还支持以下非限定XML属性：
select: optional attribute containing a
string representing an XPath expression.
The 'type' attribute must be equal to 'xpath'
if this attribute is present.";
}
select: optional attribute containing a
string representing an XPath expression.
The 'type' attribute must be equal to 'xpath'
if this attribute is present.";
}
// NETCONF capabilities defined as features feature writable-running {
//NETCONF功能定义为功能可写运行{
description
"NETCONF :writable-running capability;
If the server advertises the :writable-running
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.2";
}
description
"NETCONF :writable-running capability;
If the server advertises the :writable-running
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.2";
}
feature candidate {
description
"NETCONF :candidate capability;
If the server advertises the :candidate
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.3";
}
feature candidate {
description
"NETCONF :candidate capability;
If the server advertises the :candidate
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.3";
}
feature confirmed-commit {
if-feature candidate;
description
"NETCONF :confirmed-commit:1.1 capability;
If the server advertises the :confirmed-commit:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
feature confirmed-commit {
if-feature candidate;
description
"NETCONF :confirmed-commit:1.1 capability;
If the server advertises the :confirmed-commit:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.4";
}
reference "RFC 6241, Section 8.4";
}
feature rollback-on-error {
description
"NETCONF :rollback-on-error capability;
If the server advertises the :rollback-on-error
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.5";
}
feature rollback-on-error {
description
"NETCONF :rollback-on-error capability;
If the server advertises the :rollback-on-error
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.5";
}
feature validate {
description
"NETCONF :validate:1.1 capability;
If the server advertises the :validate:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
feature validate {
description
"NETCONF :validate:1.1 capability;
If the server advertises the :validate:1.1
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.6";
}
reference "RFC 6241, Section 8.6";
}
feature startup {
description
"NETCONF :startup capability;
If the server advertises the :startup
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.7";
}
feature startup {
description
"NETCONF :startup capability;
If the server advertises the :startup
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.7";
}
feature url {
description
"NETCONF :url capability;
If the server advertises the :url
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.8";
}
feature url {
description
"NETCONF :url capability;
If the server advertises the :url
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.8";
}
feature xpath {
description
"NETCONF :xpath capability;
If the server advertises the :xpath
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.9";
}
feature xpath {
description
"NETCONF :xpath capability;
If the server advertises the :xpath
capability for a session, then this feature must
also be enabled for that session. Otherwise,
this feature must not be enabled.";
reference "RFC 6241, Section 8.9";
}
// NETCONF Simple Types
//NETCONF简单类型
typedef session-id-type {
type uint32 {
range "1..max";
}
description
"NETCONF Session Id";
}
typedef session-id-type {
type uint32 {
range "1..max";
}
description
"NETCONF Session Id";
}
typedef session-id-or-zero-type {
type uint32;
description
"NETCONF Session Id or Zero to indicate none";
}
typedef session-id-or-zero-type {
type uint32;
description
"NETCONF Session Id or Zero to indicate none";
}
typedef error-tag-type {
type enumeration {
enum in-use {
description
"The request requires a resource that
already is in use.";
}
enum invalid-value {
description
"The request specifies an unacceptable value for one
or more parameters.";
}
enum too-big {
description
"The request or response (that would be generated) is
too large for the implementation to handle.";
}
enum missing-attribute {
description
"An expected attribute is missing.";
}
enum bad-attribute {
description
"An attribute value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-attribute {
description
"An unexpected attribute is present.";
}
enum missing-element {
description
"An expected element is missing.";
}
enum bad-element {
description
"An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-element {
description
"An unexpected element is present.";
}
enum unknown-namespace {
description
"An unexpected namespace is present.";
}
enum access-denied {
typedef error-tag-type {
type enumeration {
enum in-use {
description
"The request requires a resource that
already is in use.";
}
enum invalid-value {
description
"The request specifies an unacceptable value for one
or more parameters.";
}
enum too-big {
description
"The request or response (that would be generated) is
too large for the implementation to handle.";
}
enum missing-attribute {
description
"An expected attribute is missing.";
}
enum bad-attribute {
description
"An attribute value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-attribute {
description
"An unexpected attribute is present.";
}
enum missing-element {
description
"An expected element is missing.";
}
enum bad-element {
description
"An element value is not correct; e.g., wrong type,
out of range, pattern mismatch.";
}
enum unknown-element {
description
"An unexpected element is present.";
}
enum unknown-namespace {
description
"An unexpected namespace is present.";
}
enum access-denied {
description
"Access to the requested protocol operation or
data model is denied because authorization failed.";
}
enum lock-denied {
description
"Access to the requested lock is denied because the
lock is currently held by another entity.";
}
enum resource-denied {
description
"Request could not be completed because of
insufficient resources.";
}
enum rollback-failed {
description
"Request to roll back some configuration change (via
rollback-on-error or <discard-changes> operations)
was not completed for some reason.";
description
"Access to the requested protocol operation or
data model is denied because authorization failed.";
}
enum lock-denied {
description
"Access to the requested lock is denied because the
lock is currently held by another entity.";
}
enum resource-denied {
description
"Request could not be completed because of
insufficient resources.";
}
enum rollback-failed {
description
"Request to roll back some configuration change (via
rollback-on-error or <discard-changes> operations)
was not completed for some reason.";
}
enum data-exists {
description
"Request could not be completed because the relevant
data model content already exists. For example,
a 'create' operation was attempted on data that
already exists.";
}
enum data-missing {
description
"Request could not be completed because the relevant
data model content does not exist. For example,
a 'delete' operation was attempted on
data that does not exist.";
}
enum operation-not-supported {
description
"Request could not be completed because the requested
operation is not supported by this implementation.";
}
enum operation-failed {
description
"Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.";
}
enum partial-operation {
description
}
enum data-exists {
description
"Request could not be completed because the relevant
data model content already exists. For example,
a 'create' operation was attempted on data that
already exists.";
}
enum data-missing {
description
"Request could not be completed because the relevant
data model content does not exist. For example,
a 'delete' operation was attempted on
data that does not exist.";
}
enum operation-not-supported {
description
"Request could not be completed because the requested
operation is not supported by this implementation.";
}
enum operation-failed {
description
"Request could not be completed because the requested
operation failed for some reason not covered by
any other error condition.";
}
enum partial-operation {
description
"This error-tag is obsolete, and SHOULD NOT be sent
by servers conforming to this document.";
}
enum malformed-message {
description
"A message could not be handled because it failed to
be parsed correctly. For example, the message is not
well-formed XML or it uses an invalid character set.";
}
}
description "NETCONF Error Tag";
reference "RFC 6241, Appendix A";
}
"This error-tag is obsolete, and SHOULD NOT be sent
by servers conforming to this document.";
}
enum malformed-message {
description
"A message could not be handled because it failed to
be parsed correctly. For example, the message is not
well-formed XML or it uses an invalid character set.";
}
}
description "NETCONF Error Tag";
reference "RFC 6241, Appendix A";
}
typedef error-severity-type {
type enumeration {
enum error {
description "Error severity";
}
enum warning {
description "Warning severity";
}
}
description "NETCONF Error Severity";
reference "RFC 6241, Section 4.3";
}
typedef error-severity-type {
type enumeration {
enum error {
description "Error severity";
}
enum warning {
description "Warning severity";
}
}
description "NETCONF Error Severity";
reference "RFC 6241, Section 4.3";
}
typedef edit-operation-type {
type enumeration {
enum merge {
description
"The configuration data identified by the
element containing this attribute is merged
with the configuration at the corresponding
level in the configuration datastore identified
by the target parameter.";
}
enum replace {
description
"The configuration data identified by the element
containing this attribute replaces any related
configuration in the configuration datastore
identified by the target parameter. If no such
configuration data exists in the configuration
datastore, it is created. Unlike a
<copy-config> operation, which replaces the
entire target configuration, only the configuration
actually present in the config parameter is affected.";
typedef edit-operation-type {
type enumeration {
enum merge {
description
"The configuration data identified by the
element containing this attribute is merged
with the configuration at the corresponding
level in the configuration datastore identified
by the target parameter.";
}
enum replace {
description
"The configuration data identified by the element
containing this attribute replaces any related
configuration in the configuration datastore
identified by the target parameter. If no such
configuration data exists in the configuration
datastore, it is created. Unlike a
<copy-config> operation, which replaces the
entire target configuration, only the configuration
actually present in the config parameter is affected.";
}
enum create {
description
"The configuration data identified by the element
containing this attribute is added to the
configuration if and only if the configuration
data does not already exist in the configuration
datastore. If the configuration data exists, an
<rpc-error> element is returned with an
<error-tag> value of 'data-exists'.";
}
enum delete {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if and only if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, an <rpc-error> element is returned with
an <error-tag> value of 'data-missing'.";
}
enum remove {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, the 'remove' operation is silently ignored
by the server.";
}
}
default "merge";
description "NETCONF 'operation' attribute values";
reference "RFC 6241, Section 7.2";
}
}
enum create {
description
"The configuration data identified by the element
containing this attribute is added to the
configuration if and only if the configuration
data does not already exist in the configuration
datastore. If the configuration data exists, an
<rpc-error> element is returned with an
<error-tag> value of 'data-exists'.";
}
enum delete {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if and only if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, an <rpc-error> element is returned with
an <error-tag> value of 'data-missing'.";
}
enum remove {
description
"The configuration data identified by the element
containing this attribute is deleted from the
configuration if the configuration
data currently exists in the configuration
datastore. If the configuration data does not
exist, the 'remove' operation is silently ignored
by the server.";
}
}
default "merge";
description "NETCONF 'operation' attribute values";
reference "RFC 6241, Section 7.2";
}
// NETCONF Standard Protocol Operations
//NETCONF标准协议操作
rpc get-config {
description
"Retrieve all or part of a specified configuration.";
rpc get-config {
description
"Retrieve all or part of a specified configuration.";
reference "RFC 6241, Section 7.1";
参考“RFC 6241，第7.1节”；
input {
container source {
description
input {
container source {
description
"Particular configuration to retrieve.";
“要检索的特定配置。”；
choice config-source {
mandatory true;
description
"The configuration to retrieve.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.
This is optional-to-implement on the server because
not all servers will support filtering for this
datastore.";
}
}
}
choice config-source {
mandatory true;
description
"The configuration to retrieve.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.
This is optional-to-implement on the server because
not all servers will support filtering for this
datastore.";
}
}
}
anyxml filter {
description
"Subtree or XPath filter to use.";
nc:get-filter-element-attributes;
}
}
anyxml filter {
description
"Subtree or XPath filter to use.";
nc:get-filter-element-attributes;
}
}
output {
anyxml data {
description
"Copy of the source datastore subset that matched
the filter criteria (if any). An empty data container
indicates that the request did not produce any results.";
}
}
}
output {
anyxml data {
description
"Copy of the source datastore subset that matched
the filter criteria (if any). An empty data container
indicates that the request did not produce any results.";
}
}
}
rpc edit-config { description
rpc编辑配置{说明
"The <edit-config> operation loads all or part of a specified configuration to the specified target configuration.";
“操作将指定配置的全部或部分加载到指定的目标配置。”；
reference "RFC 6241, Section 7.2";
参考“RFC 6241，第7.2节”；
input {
container target {
description
"Particular configuration to edit.";
input {
container target {
description
"Particular configuration to edit.";
choice config-target {
mandatory true;
description
"The configuration target.";
choice config-target {
mandatory true;
description
"The configuration target.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config source.";
}
}
}
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config source.";
}
}
}
leaf default-operation {
type enumeration {
enum merge {
description
"The default operation is merge.";
}
enum replace {
description
"The default operation is replace.";
}
enum none {
description
"There is no default operation.";
}
}
default "merge";
description
"The default operation to use.";
leaf default-operation {
type enumeration {
enum merge {
description
"The default operation is merge.";
}
enum replace {
description
"The default operation is replace.";
}
enum none {
description
"There is no default operation.";
}
}
default "merge";
description
"The default operation to use.";
}
}
leaf test-option {
if-feature validate;
type enumeration {
enum test-then-set {
description
"The server will test and then set if no errors.";
}
enum set {
description
"The server will set without a test first.";
}
leaf test-option {
if-feature validate;
type enumeration {
enum test-then-set {
description
"The server will test and then set if no errors.";
}
enum set {
description
"The server will set without a test first.";
}
enum test-only {
description
"The server will only test and not set, even
if there are no errors.";
}
}
default "test-then-set";
description
"The test option to use.";
}
enum test-only {
description
"The server will only test and not set, even
if there are no errors.";
}
}
default "test-then-set";
description
"The test option to use.";
}
leaf error-option {
type enumeration {
enum stop-on-error {
description
"The server will stop on errors.";
}
enum continue-on-error {
description
"The server may continue on errors.";
}
enum rollback-on-error {
description
"The server will roll back on errors.
This value can only be used if the 'rollback-on-error'
feature is supported.";
}
}
default "stop-on-error";
description
"The error option to use.";
}
leaf error-option {
type enumeration {
enum stop-on-error {
description
"The server will stop on errors.";
}
enum continue-on-error {
description
"The server may continue on errors.";
}
enum rollback-on-error {
description
"The server will roll back on errors.
This value can only be used if the 'rollback-on-error'
feature is supported.";
}
}
default "stop-on-error";
description
"The error option to use.";
}
choice edit-content {
选择编辑内容{
mandatory true;
description
"The content for the edit operation.";
mandatory true;
description
"The content for the edit operation.";
anyxml config {
description
"Inline Config content.";
}
leaf url {
if-feature url;
type inet:uri;
description
"URL-based config content.";
}
}
}
}
anyxml config {
description
"Inline Config content.";
}
leaf url {
if-feature url;
type inet:uri;
description
"URL-based config content.";
}
}
}
}
rpc copy-config {
description
"Create or replace an entire configuration datastore with the
contents of another complete configuration datastore.";
rpc copy-config {
description
"Create or replace an entire configuration datastore with the
contents of another complete configuration datastore.";
reference "RFC 6241, Section 7.3";
参考“RFC 6241，第7.3节”；
input {
container target {
description
"Particular configuration to copy to.";
input {
container target {
description
"Particular configuration to copy to.";
choice config-target {
mandatory true;
description
"The configuration target of the copy operation.";
choice config-target {
mandatory true;
description
"The configuration target of the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config target.
This is optional-to-implement on the server.";
}
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
if-feature writable-running;
type empty;
description
"The running configuration is the config target.
This is optional-to-implement on the server.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
container source {
description
"Particular configuration to copy from.";
container source {
description
"Particular configuration to copy from.";
choice config-source {
mandatory true;
description
"The configuration source for the copy operation.";
choice config-source {
mandatory true;
description
"The configuration source for the copy operation.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
rpc delete-config {
description
"Delete a configuration datastore.";
rpc delete-config {
description
"Delete a configuration datastore.";
reference "RFC 6241, Section 7.4";
参考“RFC 6241，第7.4节”；
input {
container target {
description
"Particular configuration to delete.";
input {
container target {
description
"Particular configuration to delete.";
choice config-target {
mandatory true;
description
"The configuration target to delete.";
choice config-target {
mandatory true;
description
"The configuration target to delete.";
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
}
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config target.";
}
}
}
}
}
rpc lock {
description
"The lock operation allows the client to lock the configuration
system of a device.";
rpc lock {
description
"The lock operation allows the client to lock the configuration
system of a device.";
reference "RFC 6241, Section 7.5";
参考“RFC 6241，第7.5节”；
input {
container target {
description
"Particular configuration to lock.";
input {
container target {
description
"Particular configuration to lock.";
choice config-target {
mandatory true;
description
"The configuration target to lock.";
choice config-target {
mandatory true;
description
"The configuration target to lock.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
rpc unlock {
description
"The unlock operation is used to release a configuration lock,
previously obtained with the 'lock' operation.";
rpc unlock {
description
"The unlock operation is used to release a configuration lock,
previously obtained with the 'lock' operation.";
reference "RFC 6241, Section 7.6";
参考“RFC 6241，第7.6节”；
input {
container target {
description
"Particular configuration to unlock.";
input {
container target {
description
"Particular configuration to unlock.";
choice config-target {
mandatory true;
choice config-target {
mandatory true;
description "The configuration target to unlock.";
说明“要解锁的配置目标。”；
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config target.";
}
leaf running {
type empty;
description
"The running configuration is the config target.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config target.";
}
}
}
}
}
rpc get {
description
"Retrieve running configuration and device state information.";
rpc get {
description
"Retrieve running configuration and device state information.";
reference "RFC 6241, Section 7.7";
参考“RFC 6241，第7.7节”；
input {
anyxml filter {
description
"This parameter specifies the portion of the system
configuration and state data to retrieve.";
nc:get-filter-element-attributes;
}
}
input {
anyxml filter {
description
"This parameter specifies the portion of the system
configuration and state data to retrieve.";
nc:get-filter-element-attributes;
}
}
output {
anyxml data {
description
"Copy of the running datastore subset and/or state
data that matched the filter criteria (if any).
An empty data container indicates that the request did not
produce any results.";
}
output {
anyxml data {
description
"Copy of the running datastore subset and/or state
data that matched the filter criteria (if any).
An empty data container indicates that the request did not
produce any results.";
}
}
}
}
}
rpc close-session {
description
"Request graceful termination of a NETCONF session.";
rpc close-session {
description
"Request graceful termination of a NETCONF session.";
reference "RFC 6241, Section 7.8";
}
reference "RFC 6241, Section 7.8";
}
rpc kill-session {
description
"Force the termination of a NETCONF session.";
rpc kill-session {
description
"Force the termination of a NETCONF session.";
reference "RFC 6241, Section 7.9";
参考“RFC 6241，第7.9节”；
input {
leaf session-id {
type session-id-type;
mandatory true;
description
"Particular session to kill.";
}
}
}
input {
leaf session-id {
type session-id-type;
mandatory true;
description
"Particular session to kill.";
}
}
}
rpc commit {
if-feature candidate;
rpc commit {
if-feature candidate;
description "Commit the candidate configuration as the device's new current configuration.";
描述“将候选配置作为设备的新当前配置提交。”；
reference "RFC 6241, Section 8.3.4.1";
参考“RFC 6241，第8.3.4.1节”；
input {
leaf confirmed {
if-feature confirmed-commit;
type empty;
description
"Requests a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
input {
leaf confirmed {
if-feature confirmed-commit;
type empty;
description
"Requests a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf confirm-timeout {
if-feature confirmed-commit;
type uint32 {
range "1..max";
leaf confirm-timeout {
if-feature confirmed-commit;
type uint32 {
range "1..max";
}
units "seconds";
default "600"; // 10 minutes
description
"The timeout interval for a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
}
units "seconds";
default "600"; // 10 minutes
description
"The timeout interval for a confirmed commit.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf persist {
if-feature confirmed-commit;
type string;
description
"This parameter is used to make a confirmed commit
persistent. A persistent confirmed commit is not aborted
if the NETCONF session terminates. The only way to abort
a persistent confirmed commit is to let the timer expire,
or to use the <cancel-commit> operation.
leaf persist {
if-feature confirmed-commit;
type string;
description
"This parameter is used to make a confirmed commit
persistent. A persistent confirmed commit is not aborted
if the NETCONF session terminates. The only way to abort
a persistent confirmed commit is to let the timer expire,
or to use the <cancel-commit> operation.
The value of this parameter is a token that must be given in the 'persist-id' parameter of <commit> or <cancel-commit> operations in order to confirm or cancel the persistent confirmed commit.
此参数的值是一个令牌，必须在<commit>或<cancel commit>操作的“persist id”参数中给出，以便确认或取消持久确认的提交。
The token should be a random string.";
reference "RFC 6241, Section 8.3.4.1";
}
The token should be a random string.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf persist-id {
if-feature confirmed-commit;
type string;
description
"This parameter is given in order to commit a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
reference "RFC 6241, Section 8.3.4.1";
}
leaf persist-id {
if-feature confirmed-commit;
type string;
description
"This parameter is given in order to commit a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
reference "RFC 6241, Section 8.3.4.1";
}
}
}
}
}
rpc discard-changes {
if-feature candidate;
rpc discard-changes {
if-feature candidate;
description "Revert the candidate configuration to the current running configuration.";
说明“将候选配置还原为当前正在运行的配置。”；
reference "RFC 6241, Section 8.3.4.2";
}
reference "RFC 6241, Section 8.3.4.2";
}
rpc cancel-commit {
if-feature confirmed-commit;
description
"This operation is used to cancel an ongoing confirmed commit.
If the confirmed commit is persistent, the parameter
'persist-id' must be given, and it must match the value of the
'persist' parameter.";
reference "RFC 6241, Section 8.4.4.1";
rpc cancel-commit {
if-feature confirmed-commit;
description
"This operation is used to cancel an ongoing confirmed commit.
If the confirmed commit is persistent, the parameter
'persist-id' must be given, and it must match the value of the
'persist' parameter.";
reference "RFC 6241, Section 8.4.4.1";
input {
leaf persist-id {
type string;
description
"This parameter is given in order to cancel a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
}
}
}
input {
leaf persist-id {
type string;
description
"This parameter is given in order to cancel a persistent
confirmed commit. The value must be equal to the value
given in the 'persist' parameter to the <commit> operation.
If it does not match, the operation fails with an
'invalid-value' error.";
}
}
}
rpc validate {
if-feature validate;
rpc validate {
if-feature validate;
description "Validates the contents of the specified configuration.";
description“验证指定配置的内容。”；
reference "RFC 6241, Section 8.6.4.1";
参考“RFC 6241，第8.6.4.1节”；
input {
container source {
description
"Particular configuration to validate.";
input {
container source {
description
"Particular configuration to validate.";
choice config-source {
mandatory true;
description
"The configuration source to validate.";
choice config-source {
mandatory true;
description
"The configuration source to validate.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
leaf candidate {
if-feature candidate;
type empty;
description
"The candidate configuration is the config source.";
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
}
leaf running {
type empty;
description
"The running configuration is the config source.";
}
leaf startup {
if-feature startup;
type empty;
description
"The startup configuration is the config source.";
}
leaf url {
if-feature url;
type inet:uri;
description
"The URL-based configuration is the config source.";
}
anyxml config {
description
"Inline Config content: <config> element. Represents
an entire configuration datastore, not
a subset of the running datastore.";
}
}
}
}
}
}
}
<CODE ENDS>
<代码结束>
This non-normative section defines a template that can be used to define protocol capabilities. Data models written in YANG usually do not need to define protocol capabilities since the usage of YANG automatically leads to a capability announcing the data model and any optional portions of the data model, so called features in YANG terminology. The capabilities template is intended to be used in cases where the YANG mechanisms are not powerful enough (e.g., for handling parameterized features) or a different data modeling language is used.
本非规范性章节定义了可用于定义协议功能的模板。用YANG编写的数据模型通常不需要定义协议功能，因为使用YANG会自动产生一种功能，宣布数据模型和数据模型的任何可选部分，在YANG术语中称为功能。功能模板旨在用于YANG机制功能不够强大（例如，用于处理参数化特征）或使用不同数据建模语言的情况。
The {name} capability is identified by the following capability string:
{name}功能由以下功能字符串标识：
{capability uri}
{capability uri}
If existing operations are not modified by this capability, this section may be omitted.
如果现有操作未通过此功能进行修改，则可省略本节。
If this capability does not interact with other capabilities, this section may be omitted.
如果此功能不与其他功能交互，则可以省略此部分。
This section is non-normative.
本节是非规范性的。
Consider the work involved in performing a configuration update against a single individual device. In making a change to the configuration, the application needs to build trust that its change has been made correctly and that it has not impacted the operation of the device. The application (and the application user) should feel confident that their change has not damaged the network.
考虑对单个设备执行配置更新所涉及的工作。在对配置进行更改时，应用程序需要建立信任，确保其更改已正确进行，并且未影响设备的操作。应用程序（和应用程序用户）应该确信他们的更改没有损坏网络。
Protecting each individual device consists of a number of steps:
保护每个单独的设备包括多个步骤：
o Acquiring the configuration lock.
o 获取配置锁。
o Checkpointing the running configuration.
o 检查正在运行的配置。
o Loading and validating the incoming configuration.
o 加载和验证传入配置。
o Changing the running configuration.
o 更改正在运行的配置。
o Testing the new configuration.
o 测试新配置。
o Making the change permanent (if desired).
o 使更改永久化（如果需要）。
o Releasing the configuration lock.
o 释放配置锁。
Let's look at the details of each step.
让我们看看每个步骤的细节。
A lock should be acquired to prevent simultaneous updates from multiple sources. If multiple sources are affecting the device, the application is hampered in both testing of its change to the configuration and in recovery if the update fails. Acquiring a short-lived lock is a simple defense to prevent other parties from introducing unrelated changes.
应获取锁以防止来自多个源的同时更新。如果多个源影响设备，则应用程序在测试其对配置的更改以及在更新失败时进行恢复时都会受到阻碍。获取短期锁是一种简单的防御措施，可以防止其他方引入不相关的更改。
The lock can be acquired using the <lock> operation.
可以使用<lock>操作获取锁。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
If the :candidate capability is supported, the candidate configuration should be locked.
如果支持：候选功能，则应锁定候选配置。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>
The running configuration can be saved into a local file as a checkpoint before loading the new configuration. If the update fails, the configuration can be restored by reloading the checkpoint file.
在加载新配置之前，可以将正在运行的配置保存到本地文件中作为检查点。如果更新失败，可以通过重新加载检查点文件来恢复配置。
The checkpoint file can be created using the <copy-config> operation.
可以使用<copy config>操作创建检查点文件。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<url>file://checkpoint.conf</url>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<url>file://checkpoint.conf</url>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
To restore the checkpoint file, reverse the <source> and <target> parameters.
要恢复检查点文件，请反转<source>和<target>参数。
If the :candidate capability is supported, the configuration can be loaded onto the device without impacting the running system.
如果支持：候选功能，则可以将配置加载到设备上，而不会影响正在运行的系统。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
If the device supports the :validate:1.1 capability, it will by default validate the incoming configuration when it is loaded into the candidate. To avoid this validation, pass the <test-option> parameter with the value "set". Full validation can be requested with the <validate> operation.
如果设备支持：validate:1.1功能，则在将其加载到候选设备时，默认情况下将验证传入配置。要避免此验证，请使用值“set”传递<test option>参数。可以通过<validate>操作请求完全验证。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
When the incoming configuration has been safely loaded onto the device and validated, it is ready to impact the running system.
当传入配置已安全加载到设备上并经过验证后，它就可以影响正在运行的系统。
If the device supports the :candidate capability, use the <commit> operation to set the running configuration to the candidate configuration. Use the <confirmed> parameter to allow automatic reversion to the original configuration if connectivity to the device fails.
如果设备支持：候选功能，请使用<commit>操作将正在运行的配置设置为候选配置。如果设备连接失败，使用<confirm>参数允许自动恢复到原始配置。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<confirm-timeout>120</confirm-timeout>
</commit>
</rpc>
If the candidate is not supported by the device, the incoming configuration change is loaded directly into running.
如果设备不支持候选者，则传入的配置更改将直接加载到running中。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<!-- place incoming configuration changes here -->
</config>
</edit-config>
</rpc>
Now that the incoming configuration has been integrated into the running configuration, the application needs to gain trust that the change has affected the device in the way intended without affecting it negatively.
既然传入的配置已集成到正在运行的配置中，应用程序需要获得信任，即更改已以预期方式影响设备，而不会对其产生负面影响。
To gain this confidence, the application can run tests of the operational state of the device. The nature of the test is dependent on the nature of the change and is outside the scope of this document. Such tests may include reachability from the system running the application (using ping), changes in reachability to the rest of the network (by comparing the device's routing table), or inspection of the particular change (looking for operational evidence of the BGP peer that was just added).
为了获得这种信心，应用程序可以运行设备运行状态的测试。测试的性质取决于变更的性质，不在本文件的范围内。此类测试可能包括运行应用程序的系统的可达性（使用ping）、对网络其余部分的可达性的更改（通过比较设备的路由表）或对特定更改的检查（寻找刚刚添加的BGP对等方的操作证据）。
When the configuration change is in place and the application has sufficient faith in the proper function of this change, the application is expected to make the change permanent.
当配置更改到位并且应用程序对该更改的正确功能有足够的信心时，应用程序将使更改永久化。
If the device supports the :startup capability, the current configuration can be saved to the startup configuration by using the startup configuration as the target of the <copy-config> operation.
如果设备支持：启动功能，则可以将启动配置用作<copy config>操作的目标，将当前配置保存到启动配置中。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
If the device supports the :candidate capability and a confirmed commit was requested, the confirming commit must be sent before the timeout expires.
如果设备支持：候选功能并且请求了确认提交，则必须在超时过期之前发送确认提交。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
When the configuration update is complete, the lock must be released, allowing other applications access to the configuration.
配置更新完成后，必须释放锁，以允许其他应用程序访问配置。
Use the <unlock> operation to release the configuration lock.
使用<unlock>操作释放配置锁。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
If the :candidate capability is supported, the candidate configuration should be unlocked.
如果支持：候选功能，则应解锁候选配置。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>
When a configuration change requires updates across a number of devices, care needs to be taken to provide the required transaction semantics. The NETCONF protocol contains sufficient primitives upon which transaction-oriented operations can be built. Providing complete transactional semantics across multiple devices is prohibitively expensive, but the size and number of windows for failure scenarios can be reduced.
当配置更改需要跨多个设备进行更新时，需要注意提供所需的事务语义。NETCONF协议包含足够的原语，在这些原语上可以构建面向事务的操作。跨多个设备提供完整的事务语义代价高昂，但可以减少故障场景的窗口大小和数量。
There are two classes of multi-device operations. The first class allows the operation to fail on individual devices without requiring all devices to revert to their original state. The operation can be retried at a later time, or its failure simply reported to the user. An example of this class might be adding an NTP server. For this class of operations, failure avoidance and recovery are focused on the individual device. This means recovery of the device, reporting the failure, and perhaps scheduling another attempt.
有两类多设备操作。第一类允许操作在单个设备上失败，而不要求所有设备恢复到其原始状态。该操作可以在以后重试，或者将其失败简单地报告给用户。此类的一个示例可能是添加NTP服务器。对于这类操作，故障避免和恢复的重点是单个设备。这意味着恢复设备，报告故障，并可能安排另一次尝试。
The second class is more interesting, requiring that the operation should complete on all devices or be fully reversed. The network should either be transformed into a new state or be reset to its original state. For example, a change to a VPN may require updates to a number of devices. Another example of this might be adding a class-of-service definition. Leaving the network in a state where only a portion of the devices have been updated with the new definition will lead to future failures when the definition is referenced.
第二类更有趣，要求操作应在所有设备上完成或完全反转。网络应转换为新状态或重置为其原始状态。例如，对VPN的更改可能需要对多个设备进行更新。另一个例子可能是添加一个服务定义类。如果将网络保持在仅使用新定义更新了部分设备的状态，则在引用该定义时，将导致将来的故障。
To give transactional semantics, the same steps used in single-device operations listed above are used, but are performed in parallel across all devices. Configuration locks should be acquired on all target devices and kept until all devices are updated and the changes made permanent. Configuration changes should be uploaded and validation performed across all devices. Checkpoints should be made on each device. Then the running configuration can be changed, tested, and made permanent. If any of these steps fail, the previous configurations can be restored on any devices upon which they were changed. After the changes have been completely implemented or completely discarded, the locks on each device can be released.
为了给出事务语义，可以使用上面列出的单个设备操作中使用的相同步骤，但在所有设备上并行执行。应在所有目标设备上获取配置锁，并保留配置锁，直到所有设备都更新并且更改永久化。应上传配置更改，并在所有设备上执行验证。应在每个设备上设置检查点。然后可以更改、测试运行配置并使其永久化。如果这些步骤中的任何一个失败，则可以在更改之前的配置的任何设备上恢复这些配置。在完全实现更改或完全放弃更改后，可以释放每个设备上的锁。
This section lists major changes between this document and RFC 4741.
本节列出了本文件与RFC 4741之间的主要变更。
o Added the "malformed-message" error-tag.
o 添加了“格式错误的消息”错误标记。
o Added "remove" enumeration value to the "operation" attribute.
o 在“操作”属性中添加了“删除”枚举值。
o Obsoleted the "partial-operation" error-tag enumeration value.
o 已废弃“部分操作”错误标记枚举值。
o Added <persist> and <persist-id> parameters to the <commit> operation.
o 在<commit>操作中添加了<persist>和<persist id>参数。
o Updated the base protocol URI and clarified the <hello> message exchange to select and identify the base protocol version in use for a particular session.
o 更新了基本协议URI并澄清了<hello>消息交换，以选择和标识特定会话使用的基本协议版本。
o Added a YANG module to model the operations and removed the operation layer from the XSD.
o 添加了一个模块来模拟操作，并从XSD中删除了操作层。
o Clarified lock behavior for the candidate datastore.
o 阐明了候选数据存储的锁定行为。
o Clarified the error response server requirements for the "delete" enumeration value of the "operation" attribute.
o 阐明了错误响应服务器对“操作”属性的“删除”枚举值的要求。
o Added a namespace wildcarding mechanism for subtree filtering.
o 添加了用于子树筛选的命名空间通配符机制。
o Added a "test-only" value for the <test-option> parameter to the <edit-config> operation.
o 将<test option>参数的“仅测试”值添加到<edit config>操作中。
o Added a <cancel-commit> operation.
o 添加了一个<cancel commit>操作。
o Introduced a NETCONF username and a requirement for transport protocols to explain how a username is derived.
o 介绍了NETCONF用户名和传输协议的要求，以解释用户名是如何派生的。
Authors' Addresses
作者地址
Rob Enns (editor) Juniper Networks
Rob Enns（编辑）Juniper Networks
EMail: rob.enns@gmail.com
EMail: rob.enns@gmail.com
Martin Bjorklund (editor) Tail-f Systems
Martin Bjorklund（编辑）Tail-f系统
EMail: mbj@tail-f.com
EMail: mbj@tail-f.com
Juergen Schoenwaelder (editor) Jacobs University
雅各布斯大学Juergen Schoenwaeld（编辑）
EMail: j.schoenwaelder@jacobs-university.de
EMail: j.schoenwaelder@jacobs-university.de
Andy Bierman (editor) Brocade
安迪·比尔曼（编辑）博科
EMail: andy.bierman@brocade.com
EMail: andy.bierman@brocade.com