draft-ietf-netconf-4741bis-08.txt   draft-ietf-netconf-4741bis-09.txt 
Network Working Group R. Enns, Ed. Network Working Group R. Enns, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Obsoletes: 4741 (if approved) M. Bjorklund, Ed. Obsoletes: 4741 (if approved) M. Bjorklund, Ed.
Intended status: Standards Track Tail-f Systems Intended status: Standards Track Tail-f Systems
Expires: August 15, 2011 J. Schoenwaelder, Ed. Expires: August 16, 2011 J. Schoenwaelder, Ed.
Jacobs University Jacobs University
A. Bierman, Ed. A. Bierman, Ed.
Brocade Brocade
February 11, 2011 February 12, 2011
Network Configuration Protocol (NETCONF) Network Configuration Protocol (NETCONF)
draft-ietf-netconf-4741bis-08 draft-ietf-netconf-4741bis-09
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 August 15, 2011. This Internet-Draft will expire on August 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 93, line 12 skipping to change at page 93, line 12
<CODE ENDS> <CODE ENDS>
Appendix C. YANG Module for NETCONF Protocol Operations Appendix C. YANG Module for NETCONF Protocol Operations
This section is normative. This section is normative.
The ietf-netconf YANG module imports typedefs from [10]. The ietf-netconf YANG module imports typedefs from [10].
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
<CODE BEGINS> file "ietf-netconf@2011-02-11.yang" <CODE BEGINS> file "ietf-netconf@2011-01-16.yang"
module ietf-netconf { module ietf-netconf {
// the namespace for NETCONF XML definitions has not changed // the namespace for NETCONF XML definitions has not changed
// this value is pre-determined by RFC 4741 // this value is pre-determined by RFC 4741
namespace "urn:ietf:params:xml:ns:netconf:base:1.0"; namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
prefix nc; prefix nc;
import ietf-inet-types { import ietf-inet-types {
skipping to change at page 94, line 17 skipping to change at page 94, line 17
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).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
revision 2011-02-11 { revision 2011-01-16 {
description description
"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
skipping to change at page 114, line 38 skipping to change at page 114, line 38
o Testing the new configuration. o Testing the new configuration.
o Making the change permanent (if desired). o Making the change permanent (if desired).
o Releasing the configuration lock. o Releasing the configuration lock.
Let's look at the details of each step. Let's look at the details of each step.
E.1.1. Acquiring the Configuration Lock E.1.1. Acquiring the Configuration Lock
A lock SHOULD be acquired to prevent simultaneous updates from A lock should be acquired to prevent simultaneous updates from
multiple sources. If multiple sources are affecting the device, the multiple sources. If multiple sources are affecting the device, the
application is hampered in both testing of its change to the application is hampered in both testing of its change to the
configuration and in recovery if the update fails. Acquiring a configuration and in recovery if the update fails. Acquiring a
short-lived lock is a simple defense to prevent other parties from short-lived lock is a simple defense to prevent other parties from
introducing unrelated changes. introducing unrelated changes.
The lock can be acquired using the <lock> operation. The lock can be acquired using the <lock> operation.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock> <lock>
<target> <target>
<running/> <running/>
</target> </target>
</lock> </lock>
</rpc> </rpc>
If the :candidate capability is supported, the candidate If the :candidate capability is supported, the candidate
configuration SHOULD be locked. configuration should be locked.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock> <lock>
<target> <target>
<candidate/> <candidate/>
</target> </target>
</lock> </lock>
</rpc> </rpc>
skipping to change at page 118, line 43 skipping to change at page 118, line 43
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock> <unlock>
<target> <target>
<running/> <running/>
</target> </target>
</unlock> </unlock>
</rpc> </rpc>
If the :candidate capability is supported, the candidate If the :candidate capability is supported, the candidate
configuration SHOULD be unlocked. configuration should be unlocked.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock> <unlock>
<target> <target>
<candidate/> <candidate/>
</target> </target>
</unlock> </unlock>
</rpc> </rpc>
skipping to change at page 119, line 36 skipping to change at page 119, line 36
should either be transformed into a new state or be reset to its 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 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 to a number of devices. Another example of this might be adding a
class-of-service definition. Leaving the network in a state where class-of-service definition. Leaving the network in a state where
only a portion of the devices have been updated with the new only a portion of the devices have been updated with the new
definition will lead to future failures when the definition is definition will lead to future failures when the definition is
referenced. referenced.
To give transactional semantics, the same steps used in single device To give transactional semantics, the same steps used in single device
operations listed above are used, but are performed in parallel operations listed above are used, but are performed in parallel
across all devices. Configuration locks SHOULD be acquired on all across all devices. Configuration locks should be acquired on all
target devices and kept until all devices are updated and the changes target devices and kept until all devices are updated and the changes
made permanent. Configuration changes SHOULD be uploaded and made permanent. Configuration changes should be uploaded and
validation performed across all devices. Checkpoints SHOULD be made validation performed across all devices. Checkpoints should be made
on each device. Then the running configuration can be changed, on each device. Then the running configuration can be changed,
tested, and made permanent. If any of these steps fail, the previous tested, and made permanent. If any of these steps fail, the previous
configurations can be restored on any devices upon which they were configurations can be restored on any devices upon which they were
changed. After the changes have been completely implemented or changed. After the changes have been completely implemented or
completely discarded, the locks on each device can be released. completely discarded, the locks on each device can be released.
Appendix F. Changes from RFC 4741 Appendix F. Changes from RFC 4741
This section lists major changes between this document and RFC 4741. This section lists major changes between this document and RFC 4741.
 End of changes. 11 change blocks. 
12 lines changed or deleted 12 lines changed or added

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