draft-ietf-netconf-4741bis-03.txt   draft-ietf-netconf-4741bis-04.txt 
Network Working Group R. Enns, Ed. Network Working Group R. Enns, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track M. Bjorklund, Ed. Intended status: Standards Track M. Bjorklund, Ed.
Expires: January 13, 2011 Tail-f Systems Expires: February 24, 2011 Tail-f Systems
J. Schoenwaelder, Ed. J. Schoenwaelder, Ed.
Jacobs University Jacobs University
A. Bierman, Ed. A. Bierman, Ed.
InterWorking Labs Brocade
July 12, 2010 August 23, 2010
Network Configuration Protocol (NETCONF) Network Configuration Protocol (NETCONF)
draft-ietf-netconf-4741bis-03 draft-ietf-netconf-4741bis-04
Abstract Abstract
The Network Configuration Protocol (NETCONF) defined in this document The Network Configuration Protocol (NETCONF) defined in this document
provides mechanisms to install, manipulate, and delete the provides mechanisms to install, manipulate, and delete the
configuration of network devices. It uses an Extensible Markup configuration of network devices. It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well Language (XML)-based data encoding for the configuration data as well
as the protocol messages. The NETCONF protocol operations are as the protocol messages. The NETCONF protocol operations are
realized as Remote Procedure Calls (RPC). realized as Remote Procedure Calls (RPC).
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on February 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.3. Separation of Configuration and State Data . . . . . . . 9 1.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9
2. Transport Protocol Requirements . . . . . . . . . . . . . . . 10 1.4. Separation of Configuration and State Data . . . . . . . 10
2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 10 2. Transport Protocol Requirements . . . . . . . . . . . . . . . 12
2.2. Authentication, Integrity, and Confidentiality . . . . . 10 2.1. Connection-Oriented Operation . . . . . . . . . . . . . . 12
2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 11 2.2. Authentication, Integrity, and Confidentiality . . . . . 12
2.4. Mandatory Transport Protocol . . . . . . . . . . . . . . 11 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 13
3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 12 2.4. Mandatory Transport Protocol . . . . . . . . . . . . . . 13
3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 12 3. XML Considerations . . . . . . . . . . . . . . . . . . . . . 14
3.2. No Document Type Declarations . . . . . . . . . . . . . . 12 3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 14
4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. No Document Type Declarations . . . . . . . . . . . . . . 14
4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 13 4. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 14 4.1. <rpc> Element . . . . . . . . . . . . . . . . . . . . . . 15
4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 15 4.2. <rpc-reply> Element . . . . . . . . . . . . . . . . . . . 16
4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 18 4.3. <rpc-error> Element . . . . . . . . . . . . . . . . . . . 17
4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. <ok> Element . . . . . . . . . . . . . . . . . . . . . . 20
5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 20 4.5. Pipelining . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Configuration Datastores . . . . . . . . . . . . . . . . 20 5. Configuration Model . . . . . . . . . . . . . . . . . . . . . 22
5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Configuration Datastores . . . . . . . . . . . . . . . . 22
6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Subtree Filtering . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 22 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 22 6.2. Subtree Filter Components . . . . . . . . . . . . . . . . 24
6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 22 6.2.1. Namespace Selection . . . . . . . . . . . . . . . . . 24
6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 23 6.2.2. Attribute Match Expressions . . . . . . . . . . . . . 24
6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 23 6.2.3. Containment Nodes . . . . . . . . . . . . . . . . . . 25
6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 24 6.2.4. Selection Nodes . . . . . . . . . . . . . . . . . . . 25
6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 26 6.2.5. Content Match Nodes . . . . . . . . . . . . . . . . . 26
6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 26 6.3. Subtree Filter Processing . . . . . . . . . . . . . . . . 28
6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 26 6.4. Subtree Filtering Examples . . . . . . . . . . . . . . . 28
6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 27 6.4.1. No Filter . . . . . . . . . . . . . . . . . . . . . . 28
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 27 6.4.2. Empty Filter . . . . . . . . . . . . . . . . . . . . 29
6.4.3. Select the Entire <users> Subtree . . . . . . . . . . 29
6.4.4. Select All <name> Elements within the <users> 6.4.4. Select All <name> Elements within the <users>
Subtree . . . . . . . . . . . . . . . . . . . . . . . 29 Subtree . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 30 6.4.5. One Specific <user> Entry . . . . . . . . . . . . . . 32
6.4.6. Specific Elements from a Specific <user> Entry . . . 31 6.4.6. Specific Elements from a Specific <user> Entry . . . 33
6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 32 6.4.7. Multiple Subtrees . . . . . . . . . . . . . . . . . . 34
6.4.8. Elements with Attribute Naming . . . . . . . . . . . 34 6.4.8. Elements with Attribute Naming . . . . . . . . . . . 36
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 36 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 38
7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 36 7.1. <get-config> . . . . . . . . . . . . . . . . . . . . . . 38
7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 38 7.2. <edit-config> . . . . . . . . . . . . . . . . . . . . . . 40
7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 45 7.3. <copy-config> . . . . . . . . . . . . . . . . . . . . . . 47
7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 47 7.4. <delete-config> . . . . . . . . . . . . . . . . . . . . . 49
7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.5. <lock> . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 50 7.6. <unlock> . . . . . . . . . . . . . . . . . . . . . . . . 52
7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.7. <get> . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 53 7.8. <close-session> . . . . . . . . . . . . . . . . . . . . . 55
7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 54 7.9. <kill-session> . . . . . . . . . . . . . . . . . . . . . 56
8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 56 8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 56 8.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 58
8.2. Writable-Running Capability . . . . . . . . . . . . . . . 57 8.2. Writable-Running Capability . . . . . . . . . . . . . . . 59
8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 57 8.2.1. Description . . . . . . . . . . . . . . . . . . . . . 59
8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 57 8.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . 59
8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 57 8.2.3. Capability Identifier . . . . . . . . . . . . . . . . 59
8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 58 8.2.4. New Operations . . . . . . . . . . . . . . . . . . . 60
8.2.5. Modifications to Existing Operations . . . . . . . . 58 8.2.5. Modifications to Existing Operations . . . . . . . . 60
8.3. Candidate Configuration Capability . . . . . . . . . . . 58 8.3. Candidate Configuration Capability . . . . . . . . . . . 60
8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 58 8.3.1. Description . . . . . . . . . . . . . . . . . . . . . 60
8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 59 8.3.2. Dependencies . . . . . . . . . . . . . . . . . . . . 61
8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 59 8.3.3. Capability Identifier . . . . . . . . . . . . . . . . 61
8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 59 8.3.4. New Operations . . . . . . . . . . . . . . . . . . . 61
8.3.5. Modifications to Existing Operations . . . . . . . . 60 8.3.5. Modifications to Existing Operations . . . . . . . . 62
8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 61 8.4. Confirmed Commit Capability . . . . . . . . . . . . . . . 63
8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 61 8.4.1. Description . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 63 8.4.2. Dependencies . . . . . . . . . . . . . . . . . . . . 65
8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 63 8.4.3. Capability Identifier . . . . . . . . . . . . . . . . 65
8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 63 8.4.4. New Operations . . . . . . . . . . . . . . . . . . . 65
8.4.5. Modifications to Existing Operations . . . . . . . . 64 8.4.5. Modifications to Existing Operations . . . . . . . . 66
8.5. Rollback on Error Capability . . . . . . . . . . . . . . 66 8.5. Rollback on Error Capability . . . . . . . . . . . . . . 68
8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 66 8.5.1. Description . . . . . . . . . . . . . . . . . . . . . 68
8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 67 8.5.2. Dependencies . . . . . . . . . . . . . . . . . . . . 69
8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 67 8.5.3. Capability Identifier . . . . . . . . . . . . . . . . 69
8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 67 8.5.4. New Operations . . . . . . . . . . . . . . . . . . . 69
8.5.5. Modifications to Existing Operations . . . . . . . . 67 8.5.5. Modifications to Existing Operations . . . . . . . . 69
8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 68 8.6. Validate Capability . . . . . . . . . . . . . . . . . . . 70
8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 68 8.6.1. Description . . . . . . . . . . . . . . . . . . . . . 70
8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 68 8.6.2. Dependencies . . . . . . . . . . . . . . . . . . . . 70
8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 68 8.6.3. Capability Identifier . . . . . . . . . . . . . . . . 70
8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 68 8.6.4. New Operations . . . . . . . . . . . . . . . . . . . 70
8.6.5. Modifications to Existing Operations . . . . . . . . 69 8.6.5. Modifications to Existing Operations . . . . . . . . 71
8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 69 8.7. Distinct Startup Capability . . . . . . . . . . . . . . . 71
8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 69 8.7.1. Description . . . . . . . . . . . . . . . . . . . . . 71
8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 70 8.7.2. Dependencies . . . . . . . . . . . . . . . . . . . . 72
8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 70 8.7.3. Capability Identifier . . . . . . . . . . . . . . . . 72
8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 70 8.7.4. New Operations . . . . . . . . . . . . . . . . . . . 72
8.7.5. Modifications to Existing Operations . . . . . . . . 70 8.7.5. Modifications to Existing Operations . . . . . . . . 72
8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 71 8.8. URL Capability . . . . . . . . . . . . . . . . . . . . . 73
8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 71 8.8.1. Description . . . . . . . . . . . . . . . . . . . . . 73
8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 71 8.8.2. Dependencies . . . . . . . . . . . . . . . . . . . . 73
8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 71 8.8.3. Capability Identifier . . . . . . . . . . . . . . . . 73
8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 71 8.8.4. New Operations . . . . . . . . . . . . . . . . . . . 73
8.8.5. Modifications to Existing Operations . . . . . . . . 71 8.8.5. Modifications to Existing Operations . . . . . . . . 73
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 74
8.9. XPath Capability . . . . . . . . . . . . . . . . . . . . 72 8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 74
8.9.1. Description . . . . . . . . . . . . . . . . . . . . . 72 8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 75
8.9.2. Dependencies . . . . . . . . . . . . . . . . . . . . 73 8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 75
8.9.3. Capability Identifier . . . . . . . . . . . . . . . . 73 8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 75
8.9.4. New Operations . . . . . . . . . . . . . . . . . . . 73 8.9.5. Modifications to Existing Operations . . . . . . . . 75
8.9.5. Modifications to Existing Operations . . . . . . . . 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 77
9. Security Considerations . . . . . . . . . . . . . . . . . . . 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 79
10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . . 77 10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 79
10.2. NETCONF XML Schema . . . . . . . . . . . . . . . . . . . 77 10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 79
10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . . 77 10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 79
10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 77 11. Authors and Acknowledgements . . . . . . . . . . . . . . . . 81
11. Authors and Acknowledgements . . . . . . . . . . . . . . . . 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 82
12.1. Normative References . . . . . . . . . . . . . . . . . . 80 12.2. Informative References . . . . . . . . . . . . . . . . . 82
12.2. Informative References . . . . . . . . . . . . . . . . . 80 Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 84
Appendix A. NETCONF Error List . . . . . . . . . . . . . . . . . 82 Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 88
Appendix B. XML Schema for NETCONF Messages Layer . . . . . . . 86 Appendix C. YANG Module for NETCONF Protocol Operations . . . . 93
Appendix C. YANG Module for NETCONF Protocol Operations . . . . 91 Appendix D. Capability Template . . . . . . . . . . . . . . . . 113
Appendix D. Capability Template . . . . . . . . . . . . . . . . 111 D.1. capability-name (template) . . . . . . . . . . . . . . . 113
D.1. capability-name (template) . . . . . . . . . . . . . . . 111 D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 113
D.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 111 D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 113
D.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 111 D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 113
D.1.3. Capability Identifier . . . . . . . . . . . . . . . . 111 D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 113
D.1.4. New Operations . . . . . . . . . . . . . . . . . . . 111 D.1.5. Modifications to Existing Operations . . . . . . . . 113
D.1.5. Modifications to Existing Operations . . . . . . . . 111 D.1.6. Interactions with Other Capabilities . . . . . . . . 113
D.1.6. Interactions with Other Capabilities . . . . . . . . 111 Appendix E. Configuring Multiple Devices with NETCONF . . . . . 114
Appendix E. Configuring Multiple Devices with NETCONF . . . . . 112 E.1. Operations on Individual Devices . . . . . . . . . . . . 114
E.1. Operations on Individual Devices . . . . . . . . . . . . 112 E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 114
E.1.1. Acquiring the Configuration Lock . . . . . . . . . . 112 E.1.2. Checkpointing the Running Configuration . . . . . . . 115
E.1.2. Checkpointing the Running Configuration . . . . . . . 113 E.1.3. Loading and Validating the Incoming Configuration. . 116
E.1.3. Loading and Validating the Incoming Configuration. . 114 E.1.4. Changing the Running Configuration . . . . . . . . . 116
E.1.4. Changing the Running Configuration . . . . . . . . . 114 E.1.5. Testing the New Configuration . . . . . . . . . . . . 117
E.1.5. Testing the New Configuration . . . . . . . . . . . . 115 E.1.6. Making the Change Permanent . . . . . . . . . . . . . 117
E.1.6. Making the Change Permanent . . . . . . . . . . . . . 115 E.1.7. Releasing the Configuration Lock . . . . . . . . . . 118
E.1.7. Releasing the Configuration Lock . . . . . . . . . . 116 E.2. Operations on Multiple Devices . . . . . . . . . . . . . 119
E.2. Operations on Multiple Devices . . . . . . . . . . . . . 117 Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 120
Appendix F. Changes from RFC 4741 . . . . . . . . . . . . . . . 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
1. Introduction 1. Introduction
The NETCONF protocol defines a simple mechanism through which a The NETCONF protocol defines a simple mechanism through which a
network device can be managed, configuration data information can be network device can be managed, configuration data information can be
retrieved, and new configuration data can be uploaded and retrieved, and new configuration data can be uploaded and
manipulated. The protocol allows the device to expose a full, formal manipulated. The protocol allows the device to expose a full, formal
application programming interface (API). Applications can use this application programming interface (API). Applications can use this
straightforward API to send and receive full and partial straightforward API to send and receive full and partial
configuration data sets. configuration data sets.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
be transformed using one or more XSLT scripts from a task-oriented, 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-independent data schema into a form that is specific to the
vendor, product, operating system, and software release. The vendor, product, operating system, and software release. The
resulting data can be passed to the device using the NETCONF resulting data can be passed to the device using the NETCONF
protocol. protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
1.1. Protocol Overview 1.1. Terminology
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 may support a candidate
configuration datastore.
o capability: A functionality that supplements the base NETCONF
specification.
o client: A client invokes protocol operations on a server. In
addition, a client may subscribe to receive notifications from a
server.
o configuration 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.
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 configuration datastore: A configuration datastore is defined as
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 message: A protocol element sent over a session. Messages are
well-formed XML documents.
o notification: A server initiated message indicating that a certain
event has been recognized by the server.
o protocol operation: A specific remote procedure call, as used
within the NETCONF protocol.
o remote procedure call: A remote procedure call (RPC), realized by
exchanging <rpc> and <rpc-reply> messages.
o running configuration datastore: A configuration datastore holding
the complete configuration currently active on the device. The
running configuration datastore always exists.
o server: A server executes protocol operations invoked by a client.
In addition, a server may send notifications to a client.
o session: Client and server exchange messages using a secure,
connection-oriented session.
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 state data: State data is the additional data on a system that is
not configuration data such as read-only status information and
collected statistics.
o user: The authenticated identity of the client. The authenticated
identity of a client is commonly referred to as the NETCONF
username.
1.2. Protocol Overview
NETCONF uses a simple RPC-based mechanism to facilitate communication NETCONF uses a simple RPC-based mechanism to facilitate communication
between a client and a server. The client can be a script or between a client and a server. The client can be a script or
application typically running as part of a network manager. The application typically running as part of a network manager. The
server is typically a network device. The terms "device" and server is typically a network device. The terms "device" and
"server" are used interchangeably in this document, as are "client" "server" are used interchangeably in this document, as are "client"
and "application". and "application".
A NETCONF session is the logical connection between a network A NETCONF session is the logical connection between a network
administrator or network configuration application and a network administrator or network configuration application and a network
skipping to change at page 8, line 8 skipping to change at page 9, line 35
Figure 1: NETCONF Protocol Layers Figure 1: NETCONF Protocol Layers
1. The Secure Transport layer provides a communication path between 1. The Secure Transport layer provides a communication path between
the client and server. NETCONF can be layered over any transport the client and server. NETCONF can be layered over any transport
protocol that provides a set of basic requirements. Section 2 protocol that provides a set of basic requirements. Section 2
discusses these requirements. discusses these requirements.
2. The Messages layer provides a simple, transport-independent 2. The Messages layer provides a simple, transport-independent
framing mechanism for encoding RPCs and notifications. Section 4 framing mechanism for encoding RPCs and notifications. Section 4
documents the RPCs, and [8] documents notifications. documents the RPC messages, and [8] documents notifications.
3. The Operations layer defines a set of base operations invoked as 3. The Operations layer defines a set of base protocol operations
RPC methods with XML-encoded parameters. Section 7 details the invoked as RPC methods with XML-encoded parameters. Section 7
list of base operations. details the list of base protocol operations.
4. The Content layer is outside the scope of this document. It is 4. The Content layer is outside the scope of this document. It is
expected that separate efforts to standardize NETCONF data models expected that separate efforts to standardize NETCONF data models
will be undertaken. will be undertaken.
The YANG data modeling language [9] has been developed for specifying The YANG data modeling language [9] has been developed for specifying
NETCONF data models and operations, covering the Operations and the NETCONF data models and protocol operations, covering the Operations
Content layers of Figure 1. and the Content layers of Figure 1.
1.2. Capabilities 1.3. Capabilities
A NETCONF capability is a set of functionality that supplements the A NETCONF capability is a set of functionality that supplements the
base NETCONF specification. The capability is identified by a base NETCONF specification. The capability is identified by a
uniform resource identifier (URI). These URIs should follow the uniform resource identifier (URI). These URIs should follow the
guidelines as described in Section 8. guidelines as described in Section 8.
Capabilities augment the base operations of the device, describing Capabilities augment the base operations of the device, describing
both additional operations and the content allowed inside operations. both additional operations and the content allowed inside operations.
The client can discover the server's capabilities and use any The client can discover the server's capabilities and use any
additional operations, parameters, and content defined by those additional operations, parameters, and content defined by those
skipping to change at page 9, line 5 skipping to change at page 10, line 28
discover the server's capabilities. Section 8 also lists the set of discover the server's capabilities. Section 8 also lists the set of
capabilities defined in this document. capabilities defined in this document.
Additional capabilities can be defined at any time in external Additional capabilities can be defined at any time in external
documents, allowing the set of capabilities to expand over time. documents, allowing the set of capabilities to expand over time.
Standards bodies may define standardized capabilities, and Standards bodies may define standardized capabilities, and
implementations may define proprietary ones. A capability URI MUST implementations may define proprietary ones. A capability URI MUST
sufficiently distinguish the naming authority to avoid naming sufficiently distinguish the naming authority to avoid naming
collisions. collisions.
1.3. Separation of Configuration and State Data 1.4. Separation of Configuration and State Data
The information that can be retrieved from a running system is The information that can be retrieved from a running system is
separated into two classes, configuration data and state data. separated into two classes, configuration data and state data.
Configuration data is the set of writable data that is required to Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current transform a system from its initial default state into its current
state. State data is the additional data on a system that is not state. State data is the additional data on a system that is not
configuration data such as read-only status information and collected configuration data such as read-only status information and collected
statistics. When a device is performing configuration operations, a statistics. When a device is performing configuration operations, a
number of problems would arise if state data were included: number of problems would arise if state data were included:
skipping to change at page 10, line 8 skipping to change at page 12, line 8
example, user files and databases are not treated as configuration example, user files and databases are not treated as configuration
data by the NETCONF protocol. data by the NETCONF protocol.
For example, if a local database of user authentication data is For example, if a local database of user authentication data is
stored on the device, it is an implementation-dependent matter stored on the device, it is an implementation-dependent matter
whether it is included in configuration data. whether it is included in configuration data.
2. Transport Protocol Requirements 2. Transport Protocol Requirements
NETCONF uses an RPC-based communication paradigm. A client sends a NETCONF uses an RPC-based communication paradigm. A client sends a
series of one or more RPC request operations, which cause the server series of one or more RPC request messages, which cause the server to
to respond with a corresponding series of RPC replies. respond with a corresponding series of RPC reply messages.
The NETCONF protocol can be layered on any transport protocol that The NETCONF protocol can be layered on any transport protocol that
provides the required set of functionality. It is not bound to any provides the required set of functionality. It is not bound to any
particular transport protocol, but allows a mapping to define how it particular transport protocol, but allows a mapping to define how it
can be implemented over any specific protocol. can be implemented over any specific protocol.
The transport protocol MUST provide a mechanism to indicate the The transport protocol MUST provide a mechanism to indicate the
session type (client or server) to the NETCONF protocol layer. session type (client or server) to the NETCONF protocol layer.
This section details the characteristics that NETCONF requires from This section details the characteristics that NETCONF requires from
skipping to change at page 15, line 32 skipping to change at page 17, line 32
The <rpc-error> element is sent in <rpc-reply> messages if an error The <rpc-error> element is sent in <rpc-reply> messages if an error
occurs during the processing of an <rpc> request. occurs during the processing of an <rpc> request.
If a server encounters multiple errors during the processing of an If a server encounters multiple errors during the processing of an
<rpc> request, the <rpc-reply> MAY contain multiple <rpc-error> <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error>
elements. However, a server is not required to detect or report more elements. However, a server is not required to detect or report more
than one <rpc-error> element, if a request contains multiple errors. than one <rpc-error> element, if a request contains multiple errors.
A server is not required to check for particular error conditions in A server is not required to check for particular error conditions in
a specific sequence. A server MUST return an <rpc-error> element if a specific sequence. A server MUST return an <rpc-error> element if
any error conditions occur during processing and SHOULD return an any error conditions occur during processing.
<rpc-error> element if any warning conditions occur during
processing.
A server MUST NOT return application-level- or data-model-specific A server MUST NOT return application-level- or data-model-specific
error information in an <rpc-error> element for which the client does error information in an <rpc-error> element for which the client does
not have sufficient access rights. not have sufficient access rights.
The <rpc-error> element includes the following information: The <rpc-error> element includes the following information:
error-type: Defines the conceptual layer that the error occurred. error-type: Defines the conceptual layer that the error occurred.
Enumeration. One of: Enumeration. One of:
skipping to change at page 62, line 51 skipping to change at page 64, line 51
commit. To cancel a confirmed commit and revert changes without commit. To cancel a confirmed commit and revert changes without
waiting for the confirm timeout to expire, the client can explicitly waiting for the confirm timeout to expire, the client can explicitly
restore the configuration to its state before the confirmed commit restore the configuration to its state before the confirmed commit
was issued, by using the <cancel-commit> operation. was issued, by using the <cancel-commit> operation.
For shared configurations, this feature can cause other configuration For shared configurations, this feature can cause other configuration
changes (for example, via other NETCONF sessions) to be inadvertently changes (for example, via other NETCONF sessions) to be inadvertently
altered or removed, unless the configuration locking feature is used altered or removed, unless the configuration locking feature is used
(in other words, the lock is obtained before the edit-config (in other words, the lock is obtained before the edit-config
operation is started). Therefore, it is strongly suggested that in operation is started). Therefore, it is strongly suggested that in
order to use this feature with shared configuration databases, order to use this feature with shared configuration datastores,
configuration locking should also be used. configuration locking should also be used.
Version 1.0 of this capability was defined in [16]. The current Version 1.0 of this capability was defined in [16]. The current
version is 1.1, and is defined in this document. It extends version version is 1.1, and is defined in this document. It extends version
1.0 by adding a new operation, <cancel-commit>, and two new optional 1.0 by adding a new operation, <cancel-commit>, and two new optional
parameters, <persist> and <persist-id>. For backwards compatibility parameters, <persist> and <persist-id>. For backwards compatibility
with old clients, servers confirming to this specification MAY with old clients, servers confirming to this specification MAY
advertise version 1.0 in addition to version 1.1. advertise version 1.0 in addition to version 1.1.
8.4.2. Dependencies 8.4.2. Dependencies
skipping to change at page 66, line 46 skipping to change at page 68, line 46
This capability indicates that the server will support the This capability indicates that the server will support the
'rollback-on-error' value in the <error-option> parameter to the 'rollback-on-error' value in the <error-option> parameter to the
<edit-config> operation. <edit-config> operation.
For shared configurations, this feature can cause other configuration For shared configurations, this feature can cause other configuration
changes (for example, via other NETCONF sessions) to be inadvertently changes (for example, via other NETCONF sessions) to be inadvertently
altered or removed, unless the configuration locking feature is used altered or removed, unless the configuration locking feature is used
(in other words, the lock is obtained before the edit-config (in other words, the lock is obtained before the edit-config
operation is started). Therefore, it is strongly suggested that in operation is started). Therefore, it is strongly suggested that in
order to use this feature with shared configuration databases, order to use this feature with shared configuration datastores,
configuration locking also be used. configuration locking also be used.
8.5.2. Dependencies 8.5.2. Dependencies
None None
8.5.3. Capability Identifier 8.5.3. Capability Identifier
The :rollback-on-error capability is identified by the following The :rollback-on-error capability is identified by the following
capability string: capability string:
skipping to change at page 80, line 9 skipping to change at page 82, line 9
for his persistence and patience in assisting us with security for his persistence and patience in assisting us with security
considerations. We would also like to thank Randy Presuhn, Sharon considerations. We would also like to thank Randy Presuhn, Sharon
Chisholm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing Chisholm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing
Chen, Simon Leinen, Keith Allen, and Dave Harrington for all of their Chen, Simon Leinen, Keith Allen, and Dave Harrington for all of their
valuable advice. valuable advice.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Sperberg-McQueen, C., Maler, E., Paoli, J., and T. Bray, [1] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World "Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>. October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] DeRose, S. and J. Clark, "XML Path Language (XPath) Version [2] DeRose, S. and J. Clark, "XML Path Language (XPath) Version
1.0", World Wide Web Consortium Recommendation REC-xpath- 1.0", World Wide Web Consortium Recommendation REC-xpath-
19991116, November 1999, 19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 91, line 43 skipping to change at page 93, line 43
WG Chair: Mehmet Ersue WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com> <mailto:mehmet.ersue@nsn.com>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Editor: Juergen Schoenwaelder Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
Editor: Andy Bierman Editor: Andy Bierman
<mailto:andyb@iwl.com>"; <mailto:andy.bierman@brocade.com>";
description description
"NETCONF Protocol Data Types and RPC methods. "NETCONF Protocol Data Types and Protocol Operations.
Copyright (c) 2010 IETF Trust and the persons identified as Copyright (c) 2010 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
skipping to change at page 92, line 25 skipping to change at page 94, line 25
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: Network Configuration Protocol"; "RFC XXXX: Network Configuration Protocol";
} }
extension get-filter-element-attributes { extension get-filter-element-attributes {
description description
"If this extension is present within the "If this extension is present within the
an 'anyxml' statement named 'filter', which must be an 'anyxml' statement named 'filter', which must be
conceptually defined within the RPC input section conceptually defined within the RPC input section
for the 'get' and 'get-config' RPC operations, for the 'get' and 'get-config' protocol operations,
then the following unqualified XML attribute is then the following unqualified XML attribute is
supported within the 'filter' element, within supported within the 'filter' element, within
a 'get' or 'get-config' protocol operation: a 'get' or 'get-config' protocol operation:
type : optional attribute with allowed type : optional attribute with allowed
value strings 'subtree' and 'xpath'. value strings 'subtree' and 'xpath'.
If missing, the default value is 'subtree'. If missing, the default value is 'subtree'.
If the 'xpath' feature is supported, then the If the 'xpath' feature is supported, then the
following unqualified XML attribute is following unqualified XML attribute is
skipping to change at page 98, line 30 skipping to change at page 100, line 30
datastore. If the configuration data does not datastore. If the configuration data does not
exist, the 'remove' operation is silently ignored exist, the 'remove' operation is silently ignored
by the server."; by the server.";
} }
} }
default "merge"; default "merge";
description "NETCONF 'operation' attribute values"; description "NETCONF 'operation' attribute values";
reference "RFC XXXX, section 7.2."; reference "RFC XXXX, section 7.2.";
} }
// NETCONF Standard RPC Methods // NETCONF Standard Protocol Operations
rpc get-config { rpc get-config {
description description
"Retrieve all or part of a specified configuration."; "Retrieve all or part of a specified configuration.";
reference "RFC XXXX, section 7.1."; reference "RFC XXXX, section 7.1.";
input { input {
container source { container source {
description description
skipping to change at page 99, line 18 skipping to change at page 101, line 18
description description
"The running configuration is the config source."; "The running configuration is the config source.";
} }
leaf startup { leaf startup {
if-feature startup; if-feature startup;
type empty; type empty;
description description
"The startup configuration is the config source. "The startup configuration is the config source.
This is optional-to-implement on the server because This is optional-to-implement on the server because
not all servers will support filtering for this not all servers will support filtering for this
database."; datastore.";
} }
} }
} }
anyxml filter { anyxml filter {
description description
"Subtree or XPath filter to use."; "Subtree or XPath filter to use.";
nc:get-filter-element-attributes; nc:get-filter-element-attributes;
} }
} }
output { output {
container data { container data {
presence presence
"An empty data container indicates that the "An empty data container indicates that the
request did not produce any results."; request did not produce any results.";
description description
"Copy of the source database subset which matched "Copy of the source datastore subset which matched
the filter criteria (if any)."; the filter criteria (if any).";
} }
} }
} }
rpc edit-config { rpc edit-config {
description description
"The 'edit-config' operation loads all or part of a specified "The 'edit-config' operation loads all or part of a specified
configuration to the specified target configuration."; configuration to the specified target configuration.";
skipping to change at page 103, line 43 skipping to change at page 105, line 43
"The startup configuration is the config source."; "The startup configuration is the config source.";
} }
leaf url { leaf url {
if-feature url; if-feature url;
type inet:uri; type inet:uri;
description description
"The URL-based configuration is the config source."; "The URL-based configuration is the config source.";
} }
anyxml config { anyxml config {
description description
"Inline Config content: 'config' element. "Inline Config content: 'config' element. Represents
Represents an entire 'stand-alone' an entire configuration datastore, not
configuration database, not a subset of a subset of the running datastore.";
the running database.";
} }
} }
} }
} }
} }
rpc delete-config { rpc delete-config {
description description
"Delete a configuration datastore."; "Delete a configuration datastore.";
reference "RFC XXXX, section 7.4."; reference "RFC XXXX, section 7.4.";
skipping to change at page 106, line 40 skipping to change at page 108, line 40
nc:get-filter-element-attributes; nc:get-filter-element-attributes;
} }
} }
output { output {
container data { container data {
presence presence
"An empty data container indicates that the filter "An empty data container indicates that the filter
request did not match any results."; request did not match any results.";
description description
"Copy of the 'running' database subset and/or state "Copy of the running datastore subset and/or state
data which matched the filter criteria (if any)."; data which matched the filter criteria (if any).";
} }
} }
} }
rpc close-session { rpc close-session {
description description
"Request graceful termination of a NETCONF session."; "Request graceful termination of a NETCONF session.";
reference "RFC XXXX, section 7.8."; reference "RFC XXXX, section 7.8.";
skipping to change at page 110, line 14 skipping to change at page 112, line 14
"The startup configuration is the config source."; "The startup configuration is the config source.";
} }
leaf url { leaf url {
if-feature url; if-feature url;
type inet:uri; type inet:uri;
description description
"The URL-based configuration is the config source."; "The URL-based configuration is the config source.";
} }
anyxml config { anyxml config {
description description
"Inline Config content: 'config' element. "Inline Config content: 'config' element. Represents
Represents an entire 'stand-alone' an entire configuration datastore, not
configuration database, not a subset of a subset of the running datastore.";
the running database.";
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
skipping to change at page 118, line 23 skipping to change at page 120, line 23
o Added <persist> and <persist-id> parameters to the <commit> o Added <persist> and <persist-id> parameters to the <commit>
operation. operation.
o Updated the base protocol URI and clarified the <hello> message o Updated the base protocol URI and clarified the <hello> message
exchange to select and identify the base protocol version in use exchange to select and identify the base protocol version in use
for a particular session. for a particular session.
o Added a YANG module to model the operations and removed the o Added a YANG module to model the operations and removed the
operation layer from the XSD. operation layer from the XSD.
o Clarified lock behavior for the candidate database. o Clarified lock behavior for the candidate datastore.
o Clarified the error response server requirements for the 'delete' o Clarified the error response server requirements for the 'delete'
operation attribute enumeration value. operation attribute enumeration value.
o Added a namespace wildcarding mechanism for subtree filtering. o Added a namespace wildcarding mechanism for subtree filtering.
o Added a "test-only" value for the <test-option> parameter to the o Added a "test-only" value for the <test-option> parameter to the
<edit-config> operation. <edit-config> operation.
o Added a <cancel-commit> operation. o Added a <cancel-commit> operation.
skipping to change at page 119, line 26 skipping to change at page 121, line 26
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
Juergen Schoenwaelder (editor) Juergen Schoenwaelder (editor)
Jacobs University Jacobs University
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
Andy Bierman (editor) Andy Bierman (editor)
InterWorking Labs Brocade
Email: andyb@iwl.com Email: andy.bierman@brocade.com
 End of changes. 29 change blocks. 
171 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/