rfc6241.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc compact="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="6241" ipr="pre5378Trust200902" category="std" obsoletes="4741" submissionType="IETF" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="NETCONF Protocol">Network Configuration Protocol (NETCONF)</title>
    <seriesInfo name="RFC" value="6241"/>
    <author initials="R." surname="Enns" fullname="Rob Enns" role="editor">
      <organization>Juniper Networks</organization>
      <address>
        <email>rob.enns@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Bjorklund" fullname="Martin Bjorklund" role="editor">
      <organization>Tail-f Systems</organization>
      <address>
        <email>mbj@tail-f.com</email>
      </address>
    </author>
    <author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder" role="editor">
      <organization>Jacobs University</organization>
      <address>
        <email>j.schoenwaelder@jacobs-university.de</email>
      </address>
    </author>
    <author initials="A." surname="Bierman" fullname="Andy Bierman" role="editor">
      <organization>Brocade</organization>
      <address>
        <email>andy.bierman@brocade.com</email>
      </address>
    </author>
    <date month="June" year="2011"/>
    <area>Operations</area>
    <keyword>XML</keyword>
    <keyword>Configuration</keyword>
    <keyword>Network Management</keyword>
    <keyword>Extensible Markup Language</keyword>
    <abstract>
      <t>
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.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>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.
      </t>
      <t>
The NETCONF protocol uses a remote procedure call (RPC) paradigm.
A client encodes an RPC in XML
<xref target="W3C.REC-xml-20001006" format="default"/> 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.
      </t>
      <t>
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.
      </t>
      <t>
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 <xref target="capabilities" format="default"/>.
      </t>
      <t>
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 <xref target="W3C.REC-xslt-19991116" format="default"/>,
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.
      </t>
      <t>
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
<xref target="RFC2119" format="default">RFC 2119</xref>.
      </t>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <ul spacing="normal">
          <li>
            <t>
              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.
            </t>
          </li>
          <li>
            <t>
              capability: A functionality that supplements the base
              NETCONF specification.
            </t>
          </li>
          <li>
            <t>
              client: Invokes protocol operations on a
              server. In addition, a client can subscribe to receive
              notifications from a server.
            </t>
          </li>
          <li>
            <t>
              configuration data: The set of
              writable data that is required to transform a system
              from its initial default state into its current state.
            </t>
          </li>
          <li>
            <t>
              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.
            </t>
          </li>
          <li>
            <t>
              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.
            </t>
          </li>
          <li>
            <t>
              message: A protocol element sent over a session.
              Messages are well-formed XML documents.
            </t>
          </li>
          <li>
            <t>
              notification: A server-initiated message indicating that
              a certain event has been recognized by the server.
            </t>
          </li>
          <li>
            <t>
              protocol operation: A specific remote procedure call, as
              used within the NETCONF protocol.
            </t>
          </li>
          <li>
            <t>
              remote procedure call (RPC): 
              Realized by exchanging &lt;rpc&gt; and &lt;rpc‑reply&gt;
              messages.
            </t>
          </li>
          <li>
            <t>
              running configuration datastore: A configuration
              datastore holding the complete configuration currently
              active on the device. The running configuration
              datastore always exists.
            </t>
          </li>
          <li>
            <t>
              server: Executes protocol operations invoked by
              a client. In addition, a server can send notifications
              to a client.
            </t>
          </li>
          <li>
            <t>
              session: Client and server exchange messages using a
              secure, connection-oriented session.
            </t>
          </li>
          <li>
            <t>
              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.
            </t>
          </li>
          <li>
            <t>
              state data: The additional data on a
              system that is not configuration data such as read-only
              status information and collected statistics.
            </t>
          </li>
          <li>
            <t>
              user: The authenticated identity of the client. The
              authenticated identity of a client is commonly referred
              to as the NETCONF username.
            </t>
          </li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Protocol Overview</name>
        <t>
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".
        </t>
        <t>
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.
        </t>
        <t>
					NETCONF can be conceptually partitioned into four layers as
					shown in <xref target="layers" format="default"/>.
        </t>
        <figure anchor="layers">
          <name>NETCONF Protocol Layers</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
         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  |      |                                         |
    +-------------+      +-----------------------------------------+
          ]]></artwork>
        </figure>
        <ol spacing="normal" type="(%d)"><li>
            <t>
              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.  <xref target="transportRequirements" format="default"/>
              discusses these requirements.
            </t>
          </li>
          <li>
            <t>
              The Messages layer provides a simple,
              transport-independent framing mechanism for encoding
              RPCs and notifications. <xref target="rpcModel" format="default"/>
              documents the RPC messages, and <xref target="RFC5717" format="default"/>
              documents notifications.
            </t>
          </li>
          <li>
            <t>
              The Operations layer defines a set of base protocol
              operations invoked as RPC methods with XML-encoded
              parameters. <xref target="protocolOperations" format="default"/> details
              the list of base protocol operations.
            </t>
          </li>
          <li>
            <t>
              The Content layer is outside the scope of this
              document. It is expected that separate efforts to
              standardize NETCONF data models will be undertaken.
            </t>
          </li>
        </ol>
        <t>
          The YANG data modeling language
          <xref target="RFC6020" format="default"/> has been developed for
          specifying NETCONF data models and protocol operations,
          covering the Operations and the Content layers of
          <xref target="layers" format="default"/>.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Capabilities</name>
        <t>
            A NETCONF capability is a set of functionality that
            supplements the base NETCONF specification. The capability
            is identified by a uniform resource identifier (URI) <xref target="RFC3986" format="default"/>.
        </t>
        <t>
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.
        </t>
        <t>
The capability definition might name one or more dependent capabilities.
To support a capability, the server
MUST support any capabilities upon which it depends.
        </t>
        <t>
<xref target="capabilities" format="default"/> defines the capabilities exchange that allows
the client to discover the server's capabilities.
<xref target="capabilities" format="default"/> also lists
the set of capabilities defined in this document.
        </t>
        <t>
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.
        </t>
      </section>
      <section anchor="state" numbered="true" toc="default">
        <name>Separation of Configuration and State Data</name>
        <t>
          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:

        </t>
        <ul spacing="normal">
          <li>
            <t>Comparisons of configuration data sets would be dominated by irrelevant
              entries such as different statistics.</t>
          </li>
          <li>
            <t>Incoming data could contain nonsensical
            requests, such as attempts to write read-only data.</t>
          </li>
          <li>
            <t>The data sets would be large.</t>
          </li>
          <li>
            <t>Archived data could contain values for read-only data
              items, complicating the processing required to restore
              archived data.
            </t>
          </li>
        </ul>
        <t>
          To account for these issues, the NETCONF protocol recognizes the difference
          between configuration data and state data and provides
          operations for
          each. The &lt;get‑config&gt; operation
          retrieves configuration data only, while the &lt;get&gt; operation
          retrieves configuration and state data.
        </t>
        <t>
          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. 
        </t>
        <t>
          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.
        </t>
      </section>
    </section>
    <section anchor="transportRequirements" numbered="true" toc="default">
      <name>Transport Protocol Requirements</name>
      <t>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.
      </t>
      <t>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.
      </t>
      <t>
        The transport protocol MUST provide a mechanism to indicate the
        session type (client or server) to the NETCONF protocol layer.
      </t>
      <t>
        This section details the characteristics that NETCONF requires
        from the underlying transport protocol.
      </t>
      <section numbered="true" toc="default">
        <name>Connection-Oriented Operation</name>
        <t>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.
        </t>
        <t> 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 &lt;lock&gt; operation is further discussed in <xref target="lock" format="default"/>.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Authentication, Integrity, and Confidentiality</name>
        <t>
					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)
					<xref target="RFC5246" format="default"/> or Secure Shell (SSH) <xref target="RFC4251" format="default"/>,
					depending on the underlying protocol.
        </t>
        <t>
					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.
        </t>
        <t>
					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
					<xref target="RFC2865" format="default"/> might allow the use of RADIUS to
					authenticate NETCONF sessions.
        </t>
        <t>
					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 <xref target="W3C.REC-xml-20001006" format="default"/>.  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.
        </t>
        <t>
					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.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Mandatory Transport Protocol</name>
        <t>
					A NETCONF implementation MUST support the SSH transport
					protocol mapping <xref target="RFC6242" format="default"/>.
        </t>
      </section>
    </section>
    <!-- Transport Protocol Requirements -->

    <section anchor="xmlConsiderations" numbered="true" toc="default">
      <name>XML Considerations</name>
      <t>
         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.
      </t>
      <t>
				 All NETCONF messages MUST be well-formed XML, encoded in
				 UTF-8 <xref target="RFC3629" format="default"/>.  If a peer receives an
				 &lt;rpc&gt; 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.
      </t>
      <t>
				 A NETCONF message MAY begin with an XML declaration (see
				 Section 2.8 of <xref target="W3C.REC-xml-20001006" format="default"/>).
      </t>
      <t>
         This section discusses a small number of XML-related considerations
         pertaining to NETCONF.
      </t>
      <section anchor="namespace" numbered="true" toc="default">
        <name>Namespace</name>
        <t>
          All NETCONF protocol elements are defined in the following namespace:

        </t>
        <ul empty="true" spacing="normal">
          <li>
            <t>urn:ietf:params:xml:ns:netconf:base:1.0</t>
          </li>
        </ul>
        <t>
          NETCONF capability names MUST be URIs <xref target="RFC3986" format="default"/>.
          NETCONF capabilities are discussed in <xref target="capabilities" format="default"/>.
        </t>
      </section>
      <section anchor="nodtd" numbered="true" toc="default">
        <name>Document Type Declarations</name>
        <t>
          Document type declarations (see Section 2.8 of <xref target="W3C.REC-xml-20001006" format="default"/>) MUST NOT appear in NETCONF
          content.
        </t>
      </section>
    </section>
    <!-- XML Considerations -->

    <section anchor="rpcModel" numbered="true" toc="default">
      <name>RPC Model</name>
      <t>
        The NETCONF protocol uses an RPC-based communication
        model. NETCONF peers use &lt;rpc&gt; and &lt;rpc‑reply&gt;
        elements to provide transport-protocol-independent framing of
        NETCONF requests and responses.
      </t>
      <t>
				The syntax and XML encoding of the Messages-layer RPCs are
				formally defined in the XML schema in <xref target="xsdschema" format="default"/>.
      </t>
      <section numbered="true" toc="default">
        <name>&lt;rpc&gt; Element</name>
        <t>
          The &lt;rpc&gt; element is used to enclose a NETCONF request sent from
          the client to the server.
        </t>
        <t>
					The &lt;rpc&gt; 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
					&lt;rpc‑reply&gt; message. The sender MUST ensure that
					the "message-id" value is normalized according to the XML
					attribute value normalization rules defined in
					<xref target="W3C.REC-xml-20001006" format="default"/> if the sender wants
					the string to be returned unmodified. For example:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <some-method>
        <!-- method parameters here... -->
      </some-method>
    </rpc>
            ]]></artwork>
        <t>
          If additional attributes are present in an &lt;rpc&gt;
          element, a NETCONF peer MUST return them unmodified in the
          &lt;rpc‑reply&gt; element.  This includes any "xmlns"
          attributes.
        </t>
        <t>
The name and parameters of an RPC are encoded as the contents
of the &lt;rpc&gt; element. The name of the RPC is an element
directly inside the &lt;rpc&gt; element, and any parameters are
encoded inside this element.
        </t>
        <t>
The following example invokes a method called &lt;my‑own‑method&gt;,
which has two
parameters, &lt;my‑first‑parameter&gt;, with a value of "14", and
&lt;another‑parameter&gt;, with a value of "fred":
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
            ]]></artwork>
        <t>
The following example invokes a &lt;rock‑the‑house&gt; method with a
&lt;zip‑code&gt; parameter of "27606‑0100":
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
            ]]></artwork>
        <t>
The following example invokes the NETCONF &lt;get&gt;
method with no parameters:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get/>
  </rpc>

            ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;rpc‑reply&gt; Element</name>
        <t>
The &lt;rpc‑reply&gt; message is sent in response to an &lt;rpc&gt; message.
        </t>
        <t>
The &lt;rpc‑reply&gt; element has a mandatory attribute "message‑id",
which is equal to the "message-id" attribute of the &lt;rpc&gt; for
which this is a response.
        </t>
        <t>
A NETCONF server MUST also return any additional attributes
included in the &lt;rpc&gt; element unmodified in the
&lt;rpc‑reply&gt; element.
        </t>
        <t>
The response data is encoded as one or more child elements to the
&lt;rpc‑reply&gt; element.</t>
        <t>For example:</t>
        <t>The following &lt;rpc&gt; element invokes the NETCONF &lt;get&gt;
        method and includes an additional attribute called "user-id".
        Note that the "user-id" attribute is not in the NETCONF namespace.
        The returned &lt;rpc‑reply&gt; element returns the "user‑id"
        attribute, as well as the requested content.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

            ]]></artwork>
      </section>
      <section anchor="rpcError" numbered="true" toc="default">
        <name>&lt;rpc‑error&gt; Element</name>
        <t>
          The &lt;rpc‑error&gt; element is sent in
          &lt;rpc‑reply&gt; messages if an error occurs during
          the processing of an &lt;rpc&gt; request.
        </t>
        <t>
          If a server encounters multiple errors during the processing
          of an &lt;rpc&gt; request, the &lt;rpc‑reply&gt; MAY
          contain multiple &lt;rpc‑error&gt; elements.  However,
          a server is not required to detect or report more than one
          &lt;rpc‑error&gt; 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 &lt;rpc‑error&gt; element if any
          error conditions occur during processing.
        </t>
        <t>
          A server MUST NOT return application-level- or data-model-specific
          error information in an &lt;rpc‑error&gt; element for which the
          client does not have sufficient access rights.
        </t>
        <t>
          The &lt;rpc‑error&gt; element includes the following
          information:
        </t>
        <dl newline="false" spacing="normal">
          <dt>error-type:</dt>
          <dd>
            <t>
              Defines the conceptual layer that the error occurred.
              Enumeration. One of:
            </t>
            <ul spacing="normal">
              <li>
                <t>transport (layer: Secure Transport)</t>
              </li>
              <li>
                <t>rpc (layer: Messages)</t>
              </li>
              <li>
                <t>protocol (layer: Operations)</t>
              </li>
              <li>
                <t>application (layer: Content)</t>
              </li>
            </ul>
          </dd>
          <dt>error-tag:</dt>
          <dd>
              Contains a string identifying the error condition.
              See <xref target="errorList" format="default"/> for allowed values.
            </dd>
          <dt>error-severity:</dt>
          <dd>
            <t>
              Contains a string identifying the error severity, 
              as determined by the device. 
              One of:

            </t>
            <ul spacing="normal">
              <li>
                <t>error</t>
              </li>
              <li>
                <t>warning</t>
              </li>
            </ul>
            <t>
              Note that there are no &lt;error-tag&gt; values
              defined in this document that utilize the
              "warning" enumeration.  This is reserved
              for future use.
            </t>
          </dd>
          <dt>error-app-tag:</dt>
          <dd>
              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 data-model-specific and an implementation-specific error-app-tag
              both exist, then the data-model-specific value MUST
              be used by the server.
            </dd>
          <dt>error-path:</dt>
          <dd>
              Contains the absolute XPath <xref target="W3C.REC-xpath-19991116" format="default"/> expression
              identifying the element path to the node that is
              associated with the error being reported in a particular
              &lt;rpc‑error&gt; element.  This element will not be
              present if no appropriate payload element or datastore
              node can be associated with a particular error
              condition.</dd>
          <dt/>
          <dd>
            <t>
								The XPath expression is interpreted in the following context:

            </t>
            <ul spacing="normal">
              <li>
                <t>The set of namespace declarations are those in
								scope on the &lt;rpc‑error&gt; element.</t>
              </li>
              <li>
                <t>The set of variable bindings is empty.</t>
              </li>
              <li>
                <t>The function library is the core function library.</t>
              </li>
            </ul>
            <t>

							The context node depends on the node associated with the
							error being reported:
            </t>
            <ul spacing="normal">
              <li>
                <t>If a payload element can be associated with the
								error, the context node is the rpc request's document
								node (i.e., the &lt;rpc&gt; element).</t>
              </li>
              <li>
                <t>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.</t>
              </li>
            </ul>
          </dd>
          <dt>error-message:</dt>
          <dd>
              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 <xref target="W3C.REC-xml-20001006" format="default"/> and
              discussed in <xref target="RFC3470" format="default"/>.
            </dd>
          <dt>error-info:</dt>
          <dd>
              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 <xref target="errorList" format="default"/> 
              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.
            </dd>
        </dl>
        <t>
          <xref target="errorList" format="default"/> enumerates the standard NETCONF errors.
        </t>
        <dl newline="false" spacing="normal">
          <dt>Example:</dt>
          <dd>
							An error is returned if an &lt;rpc&gt; 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
							&lt;rpc‑reply&gt; element.
						</dd>
        </dl>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

            ]]></artwork>
        <t>
            The following &lt;rpc‑reply&gt; illustrates the case
            of returning multiple &lt;rpc‑error&gt; elements.
        </t>
        <t>Note that the data models used in the examples in this section use
      the &lt;name&gt; element to distinguish between multiple instances of
      the &lt;interface&gt; element.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

            ]]></artwork>
      </section>
      <section anchor="ok" numbered="true" toc="default">
        <name>&lt;ok&gt; Element</name>
        <t>
          The &lt;ok&gt; element is sent in &lt;rpc‑reply&gt; messages
          if no errors or warnings occurred during the processing of an &lt;rpc&gt;
          request, and no data was returned from the operation.  For example:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc-reply message-id="101"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
  </rpc-reply>

            ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>Pipelining</name>
        <t>
NETCONF &lt;rpc&gt; requests MUST be processed serially by the managed device.
Additional &lt;rpc&gt; requests MAY be sent before previous ones
have been completed. The managed device MUST send responses only in
the order the requests were received.
        </t>
      </section>
    </section>
    <!-- RPC Model -->

    <section numbered="true" toc="default">
      <name>Configuration Model</name>
      <t> 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
        <xref target="capabilityExchange" format="default"/>.
      </t>
      <section numbered="true" toc="default">
        <name>Configuration Datastores</name>
        <t>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.
        </t>
        <t>
          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 &lt;running&gt;
          element.
        </t>
        <t>
          Only the &lt;running&gt; 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.
        </t>
        <t>
          The capabilities in Sections
          <xref target="candidate" format="counter"/> and <xref target="startup" format="counter"/>
          define the &lt;candidate&gt; and &lt;startup&gt;
          configuration datastores, respectively.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Data Modeling</name>
        <t>
          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.
        </t>
        <t>
          NETCONF carries configuration data inside the &lt;config&gt; 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.
        </t>
        <t>
          Devices and managers can support multiple data models, 
          including both standard and proprietary data models.  
        </t>
      </section>
    </section>
    <!-- Configuration Model -->

    <section anchor="subtree" numbered="true" toc="default">
      <name>Subtree Filtering</name>
      <section numbered="true" toc="default">
        <name>Overview</name>
        <t>
          XML subtree filtering is a mechanism that allows an application to
          select particular XML subtrees to include in the &lt;rpc‑reply&gt; for a
          &lt;get&gt; or &lt;get‑config&gt; 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.
        </t>
        <t>
          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.
        </t>
        <t>
          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 &lt;filter&gt;.  
        </t>
        <t>
          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.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Subtree Filter Components</name>
        <t>
          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:
        </t>
        <ul spacing="normal">
          <li>
            <t>Namespace Selection</t>
          </li>
          <li>
            <t>Attribute Match Expressions</t>
          </li>
          <li>
            <t>Containment Nodes</t>
          </li>
          <li>
            <t>Selection Nodes</t>
          </li>
          <li>
            <t>Content Match Nodes</t>
          </li>
        </ul>
        <section anchor="NamespaceSelection" numbered="true" toc="default">
          <name>Namespace Selection</name>
          <t>
            A namespace is considered
            to match (for filter purposes) if the XML namespace associated
            with a particular node within the &lt;filter&gt; 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.
          </t>
          <t>
            An XML namespace wildcard mechanism is defined for subtree
            filtering. If an element 
            within the &lt;filter&gt; 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.
          </t>
          <t>
            Note that prefix values
            for qualified namespaces are not relevant when comparing filter 
            elements to elements in the underlying data model.
          </t>
          <t>
            Example:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <filter type="subtree">
    <top xmlns="http://example.com/schema/1.2/config"/>
  </filter>
              ]]></artwork>
          <t>
            In this example, the &lt;top&gt; 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.
          </t>
        </section>
        <section anchor="attribute-match" numbered="true" toc="default">
          <name>Attribute Match Expressions</name>
          <t>
            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.
          </t>
          <t>
            Example:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
          <t>
            In this example, the &lt;top&gt; and &lt;interfaces&gt;
            elements are containment nodes, the &lt;interface&gt;
            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.
          </t>
        </section>
        <section anchor="containment-nodes" numbered="true" toc="default">
          <name>Containment Nodes</name>
          <t>
            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.
          </t>
          <t>
            Example:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <filter type="subtree">
    <top xmlns="http://example.com/schema/1.2/config">
      <users/>
    </top>
  </filter>
              ]]></artwork>
          <t>
            In this example, the &lt;top&gt; element is a containment node.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Selection Nodes</name>
          <t>
            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., &lt;foo/&gt;) 
            or with explicit start and end tags (e.g., &lt;foo&gt;  &lt;/foo&gt;).  Any
            whitespace characters are ignored in this form.
          </t>
          <t>
            Example:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <filter type="subtree">
    <top xmlns="http://example.com/schema/1.2/config">
      <users/>
    </top>
  </filter>
              ]]></artwork>
          <t>
            In this example, the &lt;top&gt; element is a containment node, and 
            the &lt;users&gt; element is a selection node.  Only "users"
            nodes in the 
            "http://example.com/schema/1.2/config" namespace that occur
            within a &lt;top&gt; element that is the root of the configuration
            datastore will be included in the filter output.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Content Match Nodes</name>
          <t>
            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:

          </t>
          <ul spacing="normal">
            <li>
              <t>A content match node MUST NOT contain nested elements.</t>
            </li>
            <li>
              <t>Multiple content match nodes (i.e., sibling nodes) are logically
              combined in an "AND" expression.</t>
            </li>
            <li>
              <t>Filtering of mixed content is not supported.</t>
            </li>
            <li>
              <t>Filtering of list content is not supported.</t>
            </li>
            <li>
              <t>Filtering of whitespace-only content is not supported.</t>
            </li>
            <li>
              <t>A content match node MUST contain non-whitespace characters.
              An empty element (e.g., &lt;foo&gt;&lt;/foo&gt;) will be interpreted as a
              selection node (e.g., &lt;foo/&gt;).</t>
            </li>
            <li>
              <t>Leading and trailing whitespace characters are ignored, but any 
              whitespace characters within a block of text characters are not 
              ignored or modified.</t>
            </li>
          </ul>
          <t>
            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:

          </t>
          <ul spacing="normal">
            <li>
              <t>Each content match node in the sibling set is included in 
              the filter output.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
            <li>
              <t>If any selection nodes are present in the sibling set, then all
              of them are included in the filter output.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
            <li>
              <t>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.</t>
            </li>
          </ul>
          <t>
            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).
          </t>
          <t>
            Example:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <filter type="subtree">
    <top xmlns="http://example.com/schema/1.2/config">
      <users>
        <user>
          <name>fred</name>
        </user>
      </users>
    </top>
  </filter>
              ]]></artwork>
          <t>
            In this example, the &lt;users&gt; and &lt;user&gt; nodes are both containment
            nodes, and &lt;name&gt; is a content match node.  Since no sibling nodes
            of &lt;name&gt; are specified (and therefore no containment or selection 
            nodes), all of the sibling nodes of &lt;name&gt; 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 &lt;name&gt; element is equal to "fred" will be included in 
            the filter output.
          </t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Subtree Filter Processing</name>
        <t>
          The filter output (the set of selected nodes) is initially empty.
        </t>
        <t>
          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.
        </t>
        <t>
          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.
        </t>
        <t>
          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.
        </t>
        <t>
          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.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Subtree Filtering Examples</name>
        <section numbered="true" toc="default">
          <name>No Filter</name>
          <t>
            Leaving out the filter on the &lt;get&gt; operation returns the entire data
            model.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Empty Filter</name>
          <t>
            An empty filter will select nothing because no content
            match or selection nodes are present.  This is not an
            error.  The &lt;filter&gt; element's "type" attribute used in these
            examples is discussed further in Section 7.1.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Select the Entire &lt;users&gt; Subtree</name>
          <t>
            The filter in this example contains one selection node (&lt;users&gt;), so
            just that subtree is selected by the filter.  This example represents
            the fully populated &lt;users&gt; data model in most of the filter examples
            that follow.  In a real data model, the &lt;company‑info&gt; would not
            likely be returned with the list of users for a particular host or
            network.
          </t>
          <t>
            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 &lt;top&gt;.  The &lt;top&gt; element
            and its descendents represent an example configuration data model only.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
          <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>

              ]]></artwork>
          <t>
            The following filter request would have produced the same result, but
            only because the container &lt;users&gt; defines one child element
            (&lt;user&gt;).
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Select All &lt;name&gt; Elements within the &lt;users&gt; Subtree</name>
          <t>
            This filter contains two containment nodes (&lt;users&gt;, &lt;user&gt;) and one
            selection node (&lt;name&gt;).  All instances of the &lt;name&gt; element in the
            same sibling set are selected in the filter output.  The client might
            need to know that &lt;name&gt; 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.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>One Specific &lt;user&gt; Entry</name>
          <t>
            This filter contains two containment nodes (&lt;users&gt;, &lt;user&gt;) and one
            content match node (&lt;name&gt;).  All instances of the sibling set
            containing &lt;name&gt; for which the value of &lt;name&gt; equals "fred" are
            selected in the filter output.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Specific Elements from a Specific &lt;user&gt; Entry</name>
          <t>
            This filter contains two containment nodes (&lt;users&gt;, &lt;user&gt;), one
            content match node (&lt;name&gt;), and two selection nodes (&lt;type&gt;,
            &lt;full‑name&gt;).  All instances of the &lt;type&gt; and &lt;full‑name&gt; elements
            in the same sibling set containing &lt;name&gt; for which the value of
            &lt;name&gt; equals "fred" are selected in the filter output.  The
            &lt;company‑info&gt; element is not included because the sibling set
            contains selection nodes.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Multiple Subtrees</name>
          <t>
            This filter contains three subtrees (name=root, fred, barney).
          </t>
          <t>
            The "root" subtree filter contains two containment nodes
            (&lt;users&gt;, &lt;user&gt;), one content match node
            (&lt;name&gt;), and one selection node
            (&lt;company‑info&gt;).  The subtree selection
            criteria are met, and just the company-info subtree for
            "root" is selected in the filter output.
          </t>
          <t>
            The "fred" subtree filter contains three containment nodes
            (&lt;users&gt;, &lt;user&gt;, &lt;company‑info&gt;),
            one content match node (&lt;name&gt;), and one selection
            node (&lt;id&gt;).  The subtree selection criteria are met,
            and just the &lt;id&gt; element within the company‑info
            subtree for "fred" is selected in the filter output.
          </t>
          <t>
            The "barney" subtree filter contains three containment
            nodes (&lt;users&gt;, &lt;user&gt;,
            &lt;company‑info&gt;), two content match nodes
            (&lt;name&gt;, &lt;type&gt;), and one selection node
            (&lt;dept&gt;).  The subtree selection criteria are not met
            because user "barney" is not a "superuser", and the entire
            subtree for "barney" (including its parent &lt;user&gt;
            entry) is excluded from the filter output.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

  <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>
              ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Elements with Attribute Naming</name>
          <t>
            In this example, the filter contains one containment node
            (&lt;interfaces&gt;), one attribute match expression ("ifName"), and one
            selection node (&lt;interface&gt;).  All instances of the &lt;interface&gt;
            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.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
          <t>
            If "ifName" were a child node instead of an attribute, then the
            following request would produce similar results.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
              ]]></artwork>
        </section>
      </section>
    </section>
    <!-- Subtree Filtering -->

    <section anchor="protocolOperations" numbered="true" toc="default">
      <name>Protocol Operations</name>
      <t>
        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.
      </t>
      <t>
        The base protocol includes the following protocol operations:
      </t>
      <ul spacing="normal">
        <li>
          <t>get</t>
        </li>
        <li>
          <t>get-config</t>
        </li>
        <li>
          <t>edit-config</t>
        </li>
        <li>
          <t>copy-config</t>
        </li>
        <li>
          <t>delete-config</t>
        </li>
        <li>
          <t>lock</t>
        </li>
        <li>
          <t>unlock</t>
        </li>
        <li>
          <t>close-session</t>
        </li>
        <li>
          <t>kill-session</t>
        </li>
      </ul>
      <t>
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.
      </t>
      <t>
The syntax and XML encoding of the protocol operations are 
formally defined in the YANG module in <xref target="yangmodule" format="default"/>.
The following sections describe the semantics of each protocol operation.
      </t>
      <section anchor="get-config" numbered="true" toc="default">
        <name>&lt;get‑config&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
							Retrieve all or part of a specified configuration datastore.
            </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
                <dt>source:</dt>
                <dd>
									Name of the configuration datastore being queried,
									such as &lt;running/&gt;.
                </dd>
                <dt>filter:</dt>
                <dd>
                  <t>
									This parameter identifies the portions of the device
									configuration datastore to retrieve.
									If this parameter is not present, the entire configuration
									is returned.

                  </t>
                  <t>
        The &lt;filter&gt; element MAY optionally contain a "type" attribute.
        This attribute indicates the type of filtering syntax used within
        the &lt;filter&gt; element. The default filtering mechanism in NETCONF is
        referred to as subtree filtering and is described in
        <xref target="subtree" format="default"/>. The value "subtree"
        explicitly identifies this type of filtering.

                  </t>
                  <t>
        If the NETCONF peer supports <xref target="xpath" format="default">the :xpath capability</xref>,
        the value "xpath" MAY be used to indicate that the "select"
				attribute on the &lt;filter&gt; element
        contains an XPath expression.
                  </t>
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device can satisfy the request, the server sends an
    &lt;rpc‑reply&gt; element containing a &lt;data&gt; element
    with the results of the query.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
    An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <t>
              To retrieve the entire &lt;users&gt; subtree:
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
          <!-- additional <user> elements appear here... -->
        </users>
      </top>
    </data>
  </rpc-reply>
                  ]]></artwork>
          </dd>
          <dt/>
          <dd>
            <xref target="subtree" format="default"/> contains additional examples
              of subtree filtering.
            </dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;edit‑config&gt;</name>
        <dl newline="true" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
The &lt;edit‑config&gt; 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.

            </t>
            <t>
If a NETCONF peer supports <xref target="url" format="default">the :url capability</xref>,
the &lt;url&gt; element can appear instead of the &lt;config&gt; parameter.

            </t>
            <t>
The device analyzes the source and target configurations and
performs the requested changes.  The target configuration is not
necessarily
replaced, as with the &lt;copy‑config&gt; message.  Instead, the
target configuration is changed in accordance with the source's
data and requested operations.
            </t>
            <t>
If the &lt;edit‑config&gt; 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).
            </t>
          </dd>
          <dt>Attributes:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>operation:</dt>
              <dd>
                <t>
                    Elements in the &lt;config&gt; subtree MAY contain an
                    "operation" attribute, which belongs to the NETCONF 
 namespace defined in <xref target="namespace" format="default"/>. The attribute identifies the point in
                    the configuration to perform the operation and
                    MAY appear on multiple elements throughout the
                    &lt;config&gt; subtree.

                </t>
                <t>
                    If the "operation" attribute is not specified, the
                    configuration is merged into the configuration datastore.

                </t>
                <t>
                    The "operation" attribute has one of the following values:
                </t>
                <dl newline="false" spacing="normal">
                  <dt>merge:</dt>
                  <dd>
                      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 &lt;target&gt; parameter.  This is the default behavior.
                    </dd>
                  <dt>replace:</dt>
                  <dd>
                      The configuration data identified by the element
                      containing this attribute replaces any related
                      configuration in the configuration datastore
                      identified by the &lt;target&gt; parameter.  If no such
                      configuration data exists in the configuration
                      datastore, it is created. Unlike a
                      &lt;copy‑config&gt; operation, which
                      replaces the entire target configuration, only
                      the configuration actually present in the &lt;config&gt;
                      parameter is affected.

                    </dd>
                  <dt>create:</dt>
                  <dd>
                      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
                      &lt;rpc‑error&gt; element is returned with
                      an &lt;error‑tag&gt; value of
                      "data‑exists".
                    </dd>
                  <dt>delete:</dt>
                  <dd>
                      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
                      &lt;rpc‑error&gt; element is returned with
                      an &lt;error‑tag&gt; value of
                      "data‑missing".
                    </dd>
                  <dt>remove:</dt>
                  <dd>
                      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.
                    </dd>
                </dl>
              </dd>
            </dl>
          </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>target:</dt>
              <dd>
                    Name of the configuration datastore being edited, such as
                    &lt;running/&gt; or &lt;candidate/&gt;.
                </dd>
              <dt>default-operation:</dt>
              <dd>
                <t>
                    Selects the default operation (as described in the
                    "operation" attribute) for this &lt;edit‑config&gt; request.
                    The default value for the &lt;default-operation&gt;
                    parameter is "merge". 

                </t>
                <t>
                    The &lt;default-operation&gt; parameter is optional, but
										if provided, it has one of the following values:
                </t>
                <dl newline="false" spacing="normal">
                  <dt>merge:</dt>
                  <dd>
                        The configuration data in the &lt;config&gt; parameter is
                        merged with the configuration at the corresponding level in
                        the target datastore.  This is the default behavior.
                      </dd>
                  <dt>replace:</dt>
                  <dd>
                        The configuration data in the &lt;config&gt; parameter
                        completely replaces the configuration in the target
                        datastore.  This is useful for loading previously saved
                        configuration data.
                      </dd>
                  <dt>none:</dt>
                  <dd>
                        The target datastore is unaffected by the
                        configuration in the &lt;config&gt; parameter,
                        unless and until the
                        incoming configuration data uses the "operation" attribute to
                        request a different operation.  If the configuration in the
                        &lt;config&gt; parameter contains data for which there is not a
                        corresponding level in the target datastore, an &lt;rpc‑error&gt;
                        is returned with an &lt;error‑tag&gt;
                        value of data-missing.
                        Using "none" allows operations like "delete" to avoid
                        unintentionally creating the parent hierarchy of the element to
                        be deleted.
                      </dd>
                </dl>
              </dd>
              <dt>test-option:</dt>
              <dd>
                <t>

                    The &lt;test-option&gt; element MAY be specified only if the device
                    advertises the <xref target="validate" format="default">:validate:1.1
                    capability</xref>.

                </t>
                <t>
                    The &lt;test-option&gt; element has one of the following values:

                </t>
                <dl newline="false" spacing="normal">
                  <dt>test-then-set:</dt>
                  <dd>
                      Perform a validation test before attempting to set.
                      If validation errors occur, do not perform the &lt;edit‑config&gt;
                      operation. This is the default test-option.
                    </dd>
                  <dt>set:</dt>
                  <dd>
                      Perform a set without a validation test first.
                    </dd>
                  <dt>test-only:</dt>
                  <dd>
                      Perform only the validation test, without
                      attempting to set.
                    </dd>
                </dl>
              </dd>
              <dt>error-option:</dt>
              <dd>
                <t>
                    The &lt;error-option&gt; element has one of the following values:

                </t>
                <dl newline="false" spacing="normal">
                  <dt>stop-on-error:</dt>
                  <dd>
                      Abort the &lt;edit-config&gt; operation on first error. This
                      is the default error-option.
                    </dd>
                  <dt>continue-on-error:</dt>
                  <dd>
                      Continue to process configuration data on error;
                      error is recorded, and negative response is
                      generated if any errors occur.
                    </dd>
                  <dt>rollback-on-error:</dt>
                  <dd>
                      If an error condition occurs
                      such that an error severity &lt;rpc‑error&gt; element is generated,
                      the server will stop processing the &lt;edit-config&gt; operation and
                      restore the specified configuration to its complete state
                      at the start of this &lt;edit-config&gt; operation. This option
                      requires the server to support the :rollback-on-error capability
                      described in <xref target="rollback-on-error" format="default"/>.
                    </dd>
                </dl>
              </dd>
              <dt>config:</dt>
              <dd>
                    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 <xref target="capabilities" format="default"/>.
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent containing an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
    An &lt;rpc‑error&gt; response is sent if the request cannot
    be completed for any reason.  
            </dd>
          <dt>Example:</dt>
          <dd>
            <t>
      The &lt;edit‑config&gt; examples in this section utilize a simple
       data model, in which multiple instances of the &lt;interface&gt;
       element can be present, and an instance is distinguished
       by the &lt;name&gt; element within each &lt;interface&gt; element.

            </t>
            <t>
       Set the MTU to 1500 on an interface named "Ethernet0/0" in the
       running configuration:
            </t>
          </dd>
        </dl>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
        <t>
              Add an interface named "Ethernet0/0" to the
              running configuration, replacing any previous interface
              with that name:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
        <t>
              Delete the configuration for an 
              interface named "Ethernet0/0" from the running configuration:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

  <rpc-reply message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
  </rpc-reply>
                  ]]></artwork>
        <t>
              Delete interface 192.0.2.4 from an OSPF area (other
              interfaces configured in the same area are unaffected):
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;copy‑config&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
    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. 

            </t>
            <t>

If a NETCONF peer supports <xref target="url" format="default">the :url capability</xref>,
the &lt;url&gt; element can appear as the &lt;source&gt; or &lt;target&gt;
parameter.

            </t>
            <t>

Even if it advertises the :writable-running capability,
a device MAY choose not to support the &lt;running/&gt; configuration
datastore as the &lt;target&gt; parameter of a &lt;copy‑config&gt;
operation.
A device MAY choose not to support remote-to-remote copy operations,
where both the &lt;source&gt; and &lt;target&gt; parameters use the
&lt;url&gt; element.
If the &lt;source&gt; and &lt;target&gt; parameters identify the same URL or
configuration datastore, an error MUST be returned with an error-tag
containing "invalid-value".
            </t>
          </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>target:</dt>
              <dd>
                    Name of the configuration datastore to
                    use as the destination of the
                    &lt;copy‑config&gt; operation.
                </dd>
              <dt>source:</dt>
              <dd>
                    Name of the configuration datastore to use as the
                    source of the &lt;copy‑config&gt; operation, or the
                    &lt;config&gt; element containing the
                    complete configuration to copy.
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent that includes an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>

    An &lt;rpc‑error&gt; element is included within the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;delete‑config&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
    Delete a configuration
    datastore. The &lt;running&gt; configuration datastore cannot be deleted.           
            </t>
            <t>
If a NETCONF peer supports <xref target="url" format="default">the :url capability</xref>,
the &lt;url&gt; element can appear as the &lt;target&gt; parameter.
            </t>
          </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>target:</dt>
              <dd>
                    Name of the configuration datastore to delete.
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent that includes an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
    An &lt;rpc‑error&gt; element is included within the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
      <section anchor="lock" numbered="true" toc="default">
        <name>&lt;lock&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
The &lt;lock&gt; 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.

            </t>
            <t>

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.

            </t>
            <t>

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.

            </t>
            <t>

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.

            </t>
            <t>
   The &lt;lock&gt; operation takes a mandatory parameter, &lt;target&gt;.
   The &lt;target&gt; parameter names the configuration datastore that will
   be locked.
   When a lock is active, using the &lt;edit‑config&gt; operation
   on the locked
   configuration datastore and using the locked configuration as a target of the
   &lt;copy‑config&gt; 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 &lt;kill‑session&gt; 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.
            </t>
          </dd>
          <dt/>
          <dd>
            <t>
      A lock MUST NOT be granted if any of the following conditions is
      true:
</t>
            <ul spacing="normal">
              <li>
                <t>
A lock is already held by any NETCONF session or another entity.
</t>
              </li>
              <li>
                <t>
The target configuration is &lt;candidate&gt;, it has already been
modified, and these changes have not been committed or rolled back.
</t>
              </li>
              <li>
                <t>The target configuration is &lt;running&gt;, and another NETCONF
        session has an ongoing confirmed commit (<xref target="confirmed" format="default"/>).</t>
              </li>
            </ul>
          </dd>
          <dt/>
          <dd>
								The server MUST respond with either an &lt;ok&gt;
								element or an &lt;rpc‑error&gt;.
              </dd>
          <dt/>
          <dd>
                A lock will be released by the system if the session holding
                the lock is terminated for any reason.
              </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>target:</dt>
              <dd>

                    Name of the configuration datastore to lock.
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>

							If the device was able to satisfy the request, an
							&lt;rpc‑reply&gt; is sent that contains an
							&lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
            <t>

							An &lt;rpc‑error&gt; element is included in the
							&lt;rpc‑reply&gt; if the request cannot be
							completed for any reason.
							
            </t>
            <t>
							If the lock is already held, the &lt;error‑tag&gt;
							element will be "lock‑denied" and the
							&lt;error‑info&gt; element will include the
							&lt;session‑id&gt; of the lock owner. If the lock is
							held by a non-NETCONF entity, a &lt;session‑id&gt;
							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.
            </t>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t>
The following example shows a successful acquisition of a lock.
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>

                        ]]></artwork>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t>
The following example shows a failed attempt to acquire a lock
when the lock is already in use.
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[

  <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>
                        ]]></artwork>
          </dd>
        </dl>
      </section>
      <!-- end of Lock operation -->
            
          <section numbered="true" toc="default">
        <name>&lt;unlock&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
The &lt;unlock&gt; operation is used to release a configuration
lock, previously obtained with the &lt;lock&gt; operation.

            </t>
            <t>
An &lt;unlock&gt; operation will not succeed if either of the following 
conditions is true:
            </t>
            <ul spacing="normal">
              <li>
                <t>The specified lock is not currently active.</t>
              </li>
              <li>
                <t>The session issuing the &lt;unlock&gt; operation is not
                    the same session that obtained the lock.</t>
              </li>
            </ul>
            <t>

The server MUST respond with either an &lt;ok&gt; element or an &lt;rpc‑error&gt;.
            </t>
          </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>target:</dt>
              <dd>
                <t>
                    Name of the configuration datastore to unlock.
                </t>
                <t>
                      A NETCONF client is not permitted to unlock a
                      configuration datastore that it did not lock.
                </t>
              </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent that contains an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
    An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
      <!-- end of Unlock operation -->

      <section numbered="true" toc="default">
        <name>&lt;get&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
                Retrieve running configuration and device state information.
            </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>filter:</dt>
              <dd>
                <t>
        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.

                </t>
                <t>
        The &lt;filter&gt; element MAY optionally contain a "type" attribute.
        This attribute indicates the type of filtering syntax used within
        the &lt;filter&gt; element. The default filtering mechanism in NETCONF is
        referred to as subtree filtering and is described in
        <xref target="subtree" format="default"/>. The value "subtree"
        explicitly identifies this type of filtering.

                </t>
                <t>
        If the NETCONF peer supports <xref target="xpath" format="default">the :xpath capability</xref>,
        the value "xpath" MAY be used to indicate that the "select"
				attribute of the &lt;filter&gt; element
        contains an XPath expression.
                </t>
              </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent.  The &lt;data&gt; section contains the 
    appropriate subset.
            </dd>
          <dt>Negative Response:</dt>
          <dd>

    An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;close-session&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
          Request graceful termination of a NETCONF session.

            </t>
            <t>
                When a NETCONF server receives a
                &lt;close‑session&gt; 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
                &lt;close‑session&gt; request will be ignored.
            </t>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
      If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
      is sent that includes an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
      An &lt;rpc‑error&gt; element is included in the
      &lt;rpc‑reply&gt; if the request cannot be completed for
      any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>&lt;kill-session&gt;</name>
        <dl newline="false" spacing="normal">
          <dt>Description:</dt>
          <dd>
            <t>
								Force the termination of a NETCONF session.

            </t>
            <t>
                When a NETCONF entity receives a &lt;kill‑session&gt;
                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.

            </t>
            <t>
                If a NETCONF server receives a
                &lt;kill‑session&gt; request while processing a
                confirmed commit (<xref target="confirmed" format="default"/>), it MUST
                restore the configuration to its state before the
                confirmed commit was issued.

            </t>
            <t>
                Otherwise, the &lt;kill‑session&gt; operation
                does not roll back configuration or other device state
                modifications made by the entity holding the lock.
            </t>
          </dd>
          <dt>Parameters:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>session-id:</dt>
              <dd>
         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.
                </dd>
            </dl>
          </dd>
          <dt>Positive Response:</dt>
          <dd>
      If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
      is sent that includes an &lt;ok&gt; element.
            </dd>
          <dt>Negative Response:</dt>
          <dd>
      An &lt;rpc‑error&gt; element is included in the
      &lt;rpc‑reply&gt; if the request cannot be completed for
      any reason.
            </dd>
          <dt>Example:</dt>
          <dd>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="capabilities" numbered="true" toc="default">
      <name>Capabilities</name>
      <t>
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.
      </t>
      <t>
Additional capabilities can be defined using the template in
<xref target="capabilityTemplate" format="default"/>.
Future capability definitions can be published as standards by
standards bodies or published as proprietary extensions.
      </t>
      <t>
A NETCONF capability is identified with a URI.
The base capabilities are defined using URNs following
the method described in <xref target="RFC3553" format="default">RFC 3553</xref>.
Capabilities defined in this document have the following format:
      </t>
      <ul empty="true" spacing="normal">
        <li>
          <t>urn:ietf:params:netconf:capability:{name}:1.x</t>
        </li>
      </ul>
      <t>
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.
      </t>
      <section anchor="capabilityExchange" numbered="true" toc="default">
        <name>Capabilities Exchange</name>
        <t>
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 &lt;hello&gt;
element containing a list of that peer's capabilities. 
Each peer MUST send at least the 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.
        </t>
        <t>
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.
        </t>
        <t>
A server sending the &lt;hello&gt; element
MUST include a &lt;session‑id&gt; element containing the
session ID for this NETCONF session.
A client sending the &lt;hello&gt; element MUST NOT
include a &lt;session‑id&gt; element.
        </t>
        <t>
A server receiving a &lt;hello&gt; message with a
&lt;session‑id&gt; element MUST terminate the NETCONF session.
Similarly, a client that does not receive a &lt;session‑id&gt;
element in the server's &lt;hello&gt; message MUST terminate the NETCONF
session (without first sending a &lt;close‑session&gt;).
        </t>
        <t>
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.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
<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>
            ]]></artwork>
        <t>
Each peer sends its &lt;hello&gt; 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.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Writable-Running Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
The :writable-running capability indicates that the device
supports direct writes to the &lt;running&gt; configuration datastore. In other
words, the device supports &lt;edit‑config&gt; and
&lt;copy‑config&gt; operations where the &lt;running&gt; configuration is the
target.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>The :writable-running capability is identified by the
            following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:writable-running:1.0</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
        <section numbered="true" toc="default">
          <name>New Operations</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;edit‑config&gt;</name>
            <t>
            The :writable-running capability modifies the
            &lt;edit‑config&gt; operation to accept the
            &lt;running&gt; element as a &lt;target&gt;.
            </t>
          </section>
          <section numbered="true" toc="default">
            <name>&lt;copy‑config&gt;</name>
            <t>
            The :writable-running capability modifies the
            &lt;copy‑config&gt; operation to accept the
            &lt;running&gt; element as a &lt;target&gt;.
            </t>
          </section>
        </section>
      </section>
      <!-- end of writable-running capability -->

      <section anchor="candidate" numbered="true" toc="default">
        <name>Candidate Configuration Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
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 desired configuration
data. A &lt;commit&gt; operation MAY be performed
at any time that causes the device's running configuration to be
set to the value of the candidate configuration.
          </t>
          <t>
            The &lt;commit&gt; 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 <xref target="confirmed" format="default">:confirmed-commit:1.1 capability </xref>
            would make no sense as a "copy confirmed" operation.
          </t>
          <t>
   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.
          </t>
          <t>
   The client can discard any uncommitted changes to the candidate
   configuration by executing the &lt;discard‑changes&gt; operation.  This
   operation reverts the contents of the candidate configuration
   to the contents of the running configuration.
          </t>
        </section>
        <!-- end of Description -->
        
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t> The :candidate capability is identified by the
            following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:candidate:1.0</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
        <section numbered="true" toc="default">
          <name>New Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;commit&gt;</name>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
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.
                    </t>
                  </li>
                  <li>
                    <t>
To commit the candidate configuration as the device's new current
configuration, use the &lt;commit&gt; operation.
                    </t>
                  </li>
                  <li>
                    <t>
The &lt;commit&gt; 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.
                    </t>
                  </li>
                  <li>
                    <t>
If the running or candidate configuration is currently locked
by a different session, the  &lt;commit&gt; operation
MUST fail with an &lt;error‑tag&gt; value of "in‑use".
                    </t>
                  </li>
                  <li>
                    <t>
If the system does not have the :candidate
capability, the &lt;commit&gt; operation is not available.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Positive Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent that contains an &lt;ok&gt; element.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Negative Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
    An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
    if the request cannot be completed for any reason.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Example:</dt>
              <dd>
                <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                  ]]></artwork>
              </dd>
            </dl>
          </section>
          <section anchor="discard-changes" numbered="true" toc="default">
            <name>&lt;discard-changes&gt;</name>
            <t>
If the client decides that the candidate configuration is not to be
committed, the &lt;discard‑changes&gt; operation can be used to revert the
candidate configuration to the current running configuration.
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <discard-changes/>
  </rpc>
                  ]]></artwork>
            <t>
This operation discards any uncommitted changes by resetting the
candidate configuration with the content of the running configuration.
            </t>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;get‑config&gt;, &lt;edit‑config&gt;, &lt;copy‑config&gt;, and &lt;validate&gt;</name>
            <t>
              The candidate configuration can be used as a source or target of any
              &lt;get‑config&gt;, &lt;edit‑config&gt;, &lt;copy‑config&gt;, or &lt;validate&gt;
              operation as a &lt;source&gt; or &lt;target&gt; parameter.
              The &lt;candidate&gt; element is used to indicate the
              candidate configuration:
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
      <source>
        <candidate/>
      </source>
    </get-config>
  </rpc>
                ]]></artwork>
          </section>
          <section numbered="true" toc="default">
            <name>&lt;lock&gt; and &lt;unlock&gt;</name>
            <t>
The candidate configuration can be locked using the &lt;lock&gt;
operation with the &lt;candidate&gt; element as the &lt;target&gt; parameter:
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <lock>
      <target>
        <candidate/>
      </target>
    </lock>
  </rpc>
                  ]]></artwork>
            <t>
Similarly, the candidate configuration is unlocked using
the &lt;candidate&gt; element as the &lt;target&gt; parameter:
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <unlock>
      <target>
        <candidate/>
      </target>
    </unlock>
  </rpc>
                  ]]></artwork>
            <t>
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 &lt;unlock&gt; operation or implicitly from
session failure.
            </t>
          </section>
        </section>
      </section>
      <section anchor="confirmed" numbered="true" toc="default">
        <name>Confirmed Commit Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
The :confirmed-commit:1.1 capability indicates that the server will
support the &lt;cancel‑commit&gt; operation and the
&lt;confirmed&gt;, &lt;confirm‑timeout&gt;, &lt;persist&gt;, and
&lt;persist‑id&gt; parameters for the &lt;commit&gt;
operation. See <xref target="candidate" format="default"/> for further details on the
&lt;commit&gt; operation.
</t>
          <t>
	A confirmed &lt;commit&gt; 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 &lt;commit&gt; operation without the
	&lt;confirmed&gt; parameter.  The timeout period can be adjusted
	with the &lt;confirm‑timeout&gt; parameter.  If a follow-up
	confirmed &lt;commit&gt; 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 &lt;commit&gt; operation MAY
	introduce additional changes to the configuration.
</t>
          <t>
  If the &lt;persist&gt; 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
  &lt;persist&gt; element is given in the confirmed &lt;commit&gt; operation,
  a follow-up commit and the confirming commit can be given on any
  session, and they MUST include a &lt;persist‑id&gt; element
  with a value equal to the given value of the &lt;persist&gt;
  element.
</t>
          <t>
If the server also advertises the :startup capability, a
&lt;copy‑config&gt; from running to startup is also necessary to
save the changes to startup.
</t>
          <t>
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 &lt;persist&gt; element.
</t>
          <t>
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.
</t>
          <t>
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 &lt;cancel‑commit&gt; operation.
</t>
          <t>
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 &lt;edit‑config&gt;
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.
</t>
          <t>
						 Version 1.0 of this capability was defined in <xref target="RFC4741" format="default"/>.  Version 1.1 is
						 defined in this document, and extends version 1.0 by
						 adding a new operation, &lt;cancel‑commit&gt;, and
						 two new optional parameters, &lt;persist&gt; and
						 &lt;persist‑id&gt;. For backwards compatibility
						 with old clients, servers conforming to this
						 specification MAY advertise version 1.0 in addition to
						 version 1.1.
          </t>
        </section>
        <!-- end of Description -->
        
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>The :confirmed-commit:1.1 capability is only relevant if the :candidate
capability is also supported.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t> The :confirmed-commit:1.1 capability is identified by the
            following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:confirmed-commit:1.1</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
        <section numbered="true" toc="default">
          <name>New Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;cancel-commit&gt;</name>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
											Cancels an ongoing confirmed commit.  If the
											&lt;persist‑id&gt; parameter is not given, the
											&lt;cancel‑commit&gt; operation MUST be issued
											on the same session that issued the confirmed commit.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Parameters:</dt>
              <dd>
                <dl newline="false" spacing="normal">
                  <dt>persist-id:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
													Cancels a persistent confirmed commit.  The
													value MUST be equal to the value given in
													the &lt;persist&gt; parameter to the &lt;commit&gt;
													operation.  If the value does not match, the
													operation fails with an "invalid-value"
													error.
                        </t>
                      </li>
                    </ul>
                  </dd>
                </dl>
              </dd>
              <dt>Positive Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
    If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
    is sent that contains an &lt;ok&gt; element.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Negative Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
											An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
											if the request cannot be completed for any reason.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Example:</dt>
              <dd>
                <artwork name="" type="" align="left" alt=""><![CDATA[
  <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 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>
                  ]]></artwork>
              </dd>
            </dl>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;commit&gt;</name>
            <t>The :confirmed-commit:1.1 capability allows 4 additional
            parameters to the &lt;commit&gt; operation.</t>
            <dl newline="false" spacing="normal">
              <dt>Parameters:</dt>
              <dd>
                <dl newline="false" spacing="normal">
                  <dt>confirmed:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
                      Perform a confirmed &lt;commit&gt; operation.
                        </t>
                      </li>
                    </ul>
                  </dd>
                  <dt>confirm-timeout:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
                      Timeout period for confirmed commit, in seconds.
                      If unspecified, the confirm timeout defaults to
                      600 seconds.
                        </t>
                      </li>
                    </ul>
                  </dd>
                  <dt>persist:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
											Make the confirmed commit survive a session
											termination, and set a token on the ongoing
											confirmed commit.
                        </t>
                      </li>
                    </ul>
                  </dd>
                  <dt>persist-id:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
											Used to issue a follow-up confirmed commit or a
											confirming commit from any session, with the
											token from the previous &lt;commit&gt; operation.
                        </t>
                      </li>
                    </ul>
                  </dd>
                </dl>
              </dd>
              <dt>Example:</dt>
              <dd>
                <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                   ]]></artwork>
              </dd>
              <dt>Example:</dt>
              <dd>
                <artwork name="" type="" align="left" alt=""><![CDATA[
  <!-- 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>

  <!-- 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>


                   ]]></artwork>
              </dd>
            </dl>
          </section>
        </section>
      </section>
      <!-- confirmed commit capability -->

      <section anchor="rollback-on-error" numbered="true" toc="default">
        <name>Rollback-on-Error Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
            This capability indicates that the server will support the
            "rollback‑on‑error" value in the
            &lt;error‑option&gt; parameter to the
            &lt;edit‑config&gt; operation.
          </t>
          <t>
            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 &lt;edit‑config&gt; operation is
            started). Therefore, it is strongly suggested that in
            order to use this feature with shared configuration
            datastores, configuration locking also be used.
          </t>
        </section>
        <!-- end of Description -->
        
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t> The :rollback-on-error capability is identified by the
            following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:rollback-on-error:1.0</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
        <section numbered="true" toc="default">
          <name>New Operations</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;edit‑config&gt;</name>
            <t>The :rollback-on-error capability allows the
            "rollback‑on‑error" value to the
            &lt;error‑option&gt; parameter on the
            &lt;edit‑config&gt; operation.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                   ]]></artwork>
          </section>
        </section>
      </section>
      <!-- rollback-on-error capability -->

       <section anchor="validate" numbered="true" toc="default">
        <name>Validate Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
             Validation consists of checking a complete
             configuration for syntactical and semantic errors before
             applying the configuration to the device.
          </t>
          <t>
 If this capability is advertised, the device supports the
 &lt;validate&gt; protocol operation and checks at least for syntax
 errors. In addition, this capability supports the &lt;test-option&gt; parameter to the
 &lt;edit‑config&gt; operation and, when it is provided, checks at
 least for syntax errors.



          </t>
          <t>
						 Version 1.0 of this capability was defined in <xref target="RFC4741" format="default"/>.  Version 1.1 is
						 defined in this document, and extends version 1.0 by
						 adding a new value, "test-only", to the &lt;test-option&gt;
						 parameter of the &lt;edit‑config&gt; operation.  For backwards
						 compatibility with old clients, servers conforming to this
						 specification MAY advertise version 1.0 in addition to
						 version 1.1.

          </t>
        </section>
        <!-- end of Description -->
         <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>The :validate:1.1 capability is identified by the
           following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:validate:1.1</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->

         <section numbered="true" toc="default">
          <name>New Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;validate&gt;</name>
            <dl newline="false" spacing="normal">
              <dt>Description:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
                 This protocol operation validates the contents of the 
                 specified configuration.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Parameters:</dt>
              <dd>
                <dl newline="false" spacing="normal">
                  <dt>source:</dt>
                  <dd>
                    <ul empty="true" spacing="normal">
                      <li>
                        <t>
     Name of the configuration datastore to validate, such as
     &lt;candidate&gt;, or the &lt;config&gt; element containing 
     the complete configuration to validate.  
                        </t>
                      </li>
                    </ul>
                  </dd>
                </dl>
              </dd>
              <dt>Positive Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
     If the device was able to satisfy the request, an &lt;rpc‑reply&gt;
     is sent that contains an &lt;ok&gt; element.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Negative Response:</dt>
              <dd>
                <ul empty="true" spacing="normal">
                  <li>
                    <t>
     An &lt;rpc‑error&gt; element is included in the &lt;rpc‑reply&gt;
     if the request cannot be completed for any reason.
                    </t>
                  </li>
                  <li>
                    <t>
                 A &lt;validate&gt; 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.
                    </t>
                  </li>
                </ul>
              </dd>
              <dt>Example:</dt>
              <dd>
                <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                   ]]></artwork>
              </dd>
            </dl>
          </section>
          <!-- end of validate operation -->
         </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;edit‑config&gt;</name>
            <t>The :validate:1.1 capability modifies the
             &lt;edit‑config&gt; operation to accept the
             &lt;test‑option&gt; parameter.</t>
          </section>
        </section>
      </section>
      <section anchor="startup" numbered="true" toc="default">
        <name>Distinct Startup Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
     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 &lt;copy‑config&gt; operation
     from the &lt;running&gt; to the &lt;startup&gt; is used
     to update the startup configuration to the current contents of
     the running configuration.  NETCONF protocol operations refer to
     the startup datastore using the &lt;startup&gt; element.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>The :startup capability is identified by the
             following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:startup:1.0</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
         <section numbered="true" toc="default">
          <name>New Operations</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>General</name>
            <t>
               The :startup capability adds the &lt;startup/&gt;
               configuration datastore to arguments of several
               NETCONF operations.  The server MUST support the
               following additional values:
            </t>
            <table align="center">
              <thead>
                <tr>
                  <th align="left">Operation</th>
                  <th align="left">Parameters</th>
                  <th align="left">Notes</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left">&lt;get‑config&gt;</td>
                  <td align="left">&lt;source&gt;</td>
                  <td align="left"> </td>
                </tr>
                <tr>
                  <td align="left">&lt;copy‑config&gt;</td>
                  <td align="left">&lt;source&gt; &lt;target&gt;</td>
                  <td align="left"> </td>
                </tr>
                <tr>
                  <td align="left">&lt;lock&gt;</td>
                  <td align="left">&lt;target&gt;</td>
                  <td align="left"> </td>
                </tr>
                <tr>
                  <td align="left">&lt;unlock&gt;</td>
                  <td align="left">&lt;target&gt;</td>
                  <td align="left"> </td>
                </tr>
                <tr>
                  <td align="left">&lt;validate&gt;</td>
                  <td align="left">&lt;source&gt;</td>
                  <td align="left">If :validate:1.1 is advertised</td>
                </tr>
                <tr>
                  <td align="left">&lt;delete‑config&gt;</td>
                  <td align="left">&lt;target&gt;</td>
                  <td align="left">Resets the device to its factory defaults</td>
                </tr>
              </tbody>
            </table>
            <t>
               To save the startup configuration, use the &lt;copy‑config&gt;
               operation to copy the &lt;running&gt; configuration
               datastore to the &lt;startup&gt; configuration datastore.
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                   ]]></artwork>
          </section>
        </section>
      </section>
      <section anchor="url" numbered="true" toc="default">
        <name>URL Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
             The NETCONF peer has the ability to accept the &lt;url&gt;
             element in &lt;source&gt; and &lt;target&gt;
             parameters. The capability is further identified by
             URL arguments indicating the URL schemes supported.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>The :url capability is identified by the
             following capability string:
</t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}</t>
            </li>
          </ul>
          <t>
             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:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
         <section numbered="true" toc="default">
          <name>New Operations</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;edit‑config&gt;</name>
            <t>The :url capability modifies the
             &lt;edit‑config&gt; operation to accept the
             &lt;url&gt; element as an alternative to the &lt;config&gt; parameter.
            </t>
            <t>
							 The file that the url refers to contains the
							 configuration data hierarchy to be modified, encoded in
							 XML under the element &lt;config&gt; in the
							 "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
            </t>
          </section>
          <section numbered="true" toc="default">
            <name>&lt;copy‑config&gt;</name>
            <t>The :url capability modifies the
             &lt;copy‑config&gt; operation to accept the
             &lt;url&gt; element as the value of
             the &lt;source&gt; and the &lt;target&gt; parameters.</t>
            <t>
							 The file that the url refers to contains the
							 complete datastore, encoded in XML under the element
							 &lt;config&gt; in the
							 "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
            </t>
          </section>
          <section numbered="true" toc="default">
            <name>&lt;delete‑config&gt;</name>
            <t>The :url capability modifies the
             &lt;delete‑config&gt; operation to accept the
             &lt;url&gt; element as the value of
             the &lt;target&gt; parameters.
            </t>
          </section>
          <section numbered="true" toc="default">
            <name>&lt;validate&gt;</name>
            <t>The :url capability modifies the
             &lt;validate&gt; operation to accept the
             &lt;url&gt; element as the value of
             the &lt;source&gt; parameter.</t>
          </section>
        </section>
      </section>
      <!-- end of URL capability -->

       <section anchor="xpath" numbered="true" toc="default">
        <name>XPath Capability</name>
        <section numbered="true" toc="default">
          <name>Description</name>
          <t>
             The XPath capability indicates that the NETCONF
             peer supports the use of XPath expressions in the
             &lt;filter&gt; element.
             XPath is described in <xref target="W3C.REC-xpath-19991116" format="default"/>.
          </t>
          <t>
             The data model used in the XPath expression is the same
             as that used in XPath 1.0 <xref target="W3C.REC-xpath-19991116" format="default"/>, with the same
             extension for root node children as used by XSLT 1.0
             (<xref target="W3C.REC-xslt-19991116" format="default"/>, Section 3.1).
             Specifically, it means that the root node MAY have any
             number of element nodes as its children.
          </t>
          <t>The XPath expression is evaluated in the following context:
          </t>
          <ul spacing="normal">
            <li>
              <t>The set of namespace declarations are those in
						 scope on the &lt;filter&gt; element.</t>
            </li>
            <li>
              <t>The set of variable bindings is defined by the data
						 model.  If no such variable bindings are defined, the set
						 is empty.</t>
            </li>
            <li>
              <t>The function library is the core function library,
						 plus any functions defined by the data model.</t>
            </li>
            <li>
              <t>The context node is the root node.</t>
            </li>
          </ul>
          <t>
             The XPath expression MUST return a node set.  If it does
             not return a node set, the operation fails with an
             "invalid-value" error.
          </t>
          <t>
						 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.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Dependencies</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>The :xpath capability is identified by the
             following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>urn:ietf:params:netconf:capability:xpath:1.0</t>
            </li>
          </ul>
        </section>
        <!-- end of Capability & Namespace -->
         <section numbered="true" toc="default">
          <name>New Operations</name>
          <t>None.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;get‑config&gt; and &lt;get&gt;</name>
            <t>
    The :xpath capability modifies the &lt;get&gt; and &lt;get‑config&gt; operations
   to accept the value "xpath" in the "type" attribute of the &lt;filter&gt;
   element.  When the "type" attribute is set to "xpath", a "select"
   attribute MUST be present on the &lt;filter&gt; element.  The "select"
   attribute will be treated as an XPath expression and used to filter
   the returned data.  The &lt;filter&gt; element itself MUST be empty in this
   case.
            </t>
            <t>
   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:
            </t>
            <ul spacing="normal">
              <li>
                <t>All ancestor nodes of the result node MUST be encoded
        first, so the &lt;data&gt; element returned in the reply
        contains only fully specified subtrees, according
        to the underlying data model.</t>
              </li>
              <li>
                <t>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.
                </t>
              </li>
            </ul>
            <t>
               For example:
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                   ]]></artwork>
          </section>
        </section>
      </section>
      <!-- end of XPath capability -->

     </section>
    <!-- Capabilities -->

     <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
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.</t>
      <t>
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.
</t>
      <t>
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.).
</t>
      <t>
  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.
</t>
      <t>
 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.
      </t>
      <t>
 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. 
      </t>
      <t>
 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.
      </t>
      <t>
 That having been said, it is important to recognize that some
 operations are clearly more sensitive by nature than others.  For
 instance, &lt;copy‑config&gt; to the startup or running
 configurations is clearly not a normal provisioning operation,
 whereas &lt;edit‑config&gt; is.
Such global operations MUST disallow the changing of information
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 &lt;candidate&gt; configuration,
user A MUST NOT be allowed to commit the &lt;candidate&gt;
configuration.
      </t>
      <t>
 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.
</t>
      <t>
     The &lt;lock&gt; 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.
</t>
    </section>
    <!-- Security Considerations -->
   
   <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <!-- RFC 2434 -->
     <section numbered="true" toc="default">
        <name>NETCONF XML Namespace</name>
        <t>
This document registers a URI for the NETCONF XML namespace in the
<xref target="RFC3688" format="default">IETF XML registry</xref>.
        </t>
        <t>
IANA has updated the following
URI to reference this document.
        </t>
        <t>
URI: urn:ietf:params:xml:ns:netconf:base:1.0
        </t>
        <t>
Registrant Contact: The IESG.
        </t>
        <t>
XML: N/A, the requested URI is an XML namespace.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>NETCONF XML Schema</name>
        <t>
This document registers a URI for the NETCONF XML schema in the
<xref target="RFC3688" format="default">IETF XML registry</xref>.
        </t>
        <t>
IANA has updated the following
URI to reference this document.
        </t>
        <t>
URI: urn:ietf:params:xml:schema:netconf
        </t>
        <t>
Registrant Contact: The IESG.
        </t>
        <t>
XML: <xref target="xsdschema" format="default"/> of this document.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>NETCONF YANG Module</name>
        <t>
         This document registers a YANG module in the YANG Module
         Names registry <xref target="RFC6020" format="default"/>.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  name:        ietf-netconf
  namespace:   urn:ietf:params:xml:ns:netconf:base:1.0
  prefix:      nc
  reference:   RFC 6241
  ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>NETCONF Capability URNs</name>
        <t>
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.
        </t>
        <t>
IANA has updated the allocations of the following
capabilities to reference this document.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   Index 
      Capability Identifier                        
   ------------------------

   :writable-running
      urn:ietf:params:netconf:capability:writable-running:1.0
                                                                   
   :candidate 
      urn:ietf:params:netconf:capability:candidate:1.0

   :rollback-on-error 
      urn:ietf:params:netconf:capability:rollback-on-error:1.0

   :startup
      urn:ietf:params:netconf:capability:startup:1.0 
                                                                   
   :url
      urn:ietf:params:netconf:capability:url:1.0   
                                                                   
   :xpath
      urn:ietf:params:netconf:capability:xpath:1.0 
]]></artwork>
        <t>
IANA has added the following capabilities to the registry:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   Index 
      Capability Identifier                        
   ------------------------

   :base:1.1
      urn:ietf:params:netconf:base: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 
]]></artwork>
      </section>
    </section>
    <!-- IANA Considerations -->

<section numbered="true" toc="default">
      <name>Contributors</name>
      <t>
   In addition to the editors, this document was written by:

</t>
      <ul empty="true" spacing="normal">
        <li>
          <t>Ken Crozier, Cisco Systems
</t>
        </li>
        <li>
          <t>
      Ted Goddard, IceSoft
</t>
        </li>
        <li>
          <t>
      Eliot Lear, Cisco Systems
</t>
        </li>
        <li>
          <t>
      Phil Shafer, Juniper Networks
</t>
        </li>
        <li>
          <t>
      Steve Waldbusser
</t>
        </li>
        <li>
          <t>
      Margaret Wasserman, Painless Security, LLC
</t>
        </li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>
   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.
</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="W3C.REC-xml-20001006" target="http://www.w3.org/TR/2000/REC-xml-20001006">
          <front>
            <title>Extensible Markup Language (XML) 1.0 (Second Edition)</title>
            <author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
              <organization/>
            </author>
            <author initials="T." surname="Bray" fullname="Tim Bray">
              <organization/>
            </author>
            <author initials="J." surname="Paoli" fullname="Jean Paoli">
              <organization/>
            </author>
            <author initials="E." surname="Maler" fullname="Eve Maler">
              <organization/>
            </author>
            <date month="October" day="6" year="2000"/>
          </front>
          <seriesInfo name="World Wide Web Consortium" value="REC-xml-20001006"/>
        </reference>
        <reference anchor="W3C.REC-xpath-19991116" target="https://www.w3.org/TR/1999/REC-xpath-19991116/" xml:base="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xpath-19991116.xml">
          <front>
            <title>XML Path Language (XPath) Version 1.0</title>
            <author fullname="James Clark" role="editor"/>
            <author fullname="Steven DeRose" role="editor"/>
            <date day="16" month="November" year="1999"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-xpath-19991116"/>
          <seriesInfo name="W3C" value="REC-xpath-19991116"/>
        </reference>
        <!-- XPath spec -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <!-- keywords -->

<!-- 4742bis -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <!-- URI -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3553.xml"/>
        <!-- URNs for protocol params -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <!-- UTF-8 -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <!-- IETF XML registry -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5717.xml"/>
        <!-- NETCONF notifs -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <!-- YANG -->
			 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6021.xml"/>
        <!-- YANG types -->
     </references>
      <references>
        <name>Informative References</name>
        <reference anchor="W3C.REC-xslt-19991116" target="https://www.w3.org/TR/1999/REC-xslt-19991116" xml:base="https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xslt-19991116.xml">
          <front>
            <title>XSL Transformations (XSLT) Version 1.0</title>
            <author fullname="James Clark" role="editor"/>
            <date day="16" month="November" year="1999"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-xslt-19991116"/>
          <seriesInfo name="W3C" value="REC-xslt-19991116"/>
        </reference>
        <!-- XSLT spec -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
        <!-- RADIUS -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3470.xml"/>
        <!-- XML use in IETF -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml"/>
        <!-- SSH -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4741.xml"/>
        <!-- NETCONF 1.0 -->
       <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <!-- TLS -->
     </references>
    </references>
    <section anchor="errorList" numbered="true" toc="default">
      <name>NETCONF Error List</name>
      <t>
				 This section is normative.
      </t>
      <t>
				 For each error‑tag, the valid error‑type and
				 error‑severity values are listed, together with any
				 mandatory error‑info, if any.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. 

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.

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.

                <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.

                <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.

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>).

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.

                This error-tag is new in :base:1.1 and MUST NOT be
                sent to old clients.
               ]]></artwork>
    </section>
    <section anchor="xsdschema" numbered="true" toc="default">
      <name>XML Schema for NETCONF Messages Layer</name>
      <t>
				 This section is normative.
      </t>
      <sourcecode name="netconf.xsd" type="" markers="true"><![CDATA[

<?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>
  
  <!--
     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: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"/>
      </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>


]]></sourcecode>
    </section>
    <section anchor="yangmodule" numbered="true" toc="default">
      <name>YANG Module for NETCONF Protocol Operations</name>
      <t>
				 This section is normative.
      </t>
      <t>
					 The ietf-netconf YANG module imports typedefs from <xref target="RFC6021" format="default"/>.


      </t>
      <sourcecode name="ietf-netconf@2011-06-01.yang" type="" markers="true"><![CDATA[

module ietf-netconf {

  // 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;
   
  import ietf-inet-types {
    prefix inet;
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netconf/>
     WG List:  <netconf@ietf.org>

     WG Chair: Bert Wijnen
               <bertietf@bwijnen.net>

     WG Chair: Mehmet Ersue
               <mehmet.ersue@nsn.com>

     Editor:   Martin Bjorklund
               <mbj@tail-f.com>

     Editor:   Juergen Schoenwaelder
               <j.schoenwaelder@jacobs-university.de>

     Editor:   Andy Bierman
               <andy.bierman@brocade.com>";

  description 
    "NETCONF Protocol Data Types and Protocol Operations.

     Copyright (c) 2011 IETF Trust and the persons identified as
     the document authors.  All rights reserved.

     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).

     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:

         type : optional attribute with allowed
                value strings 'subtree' and 'xpath'.
                If missing, the default value is 'subtree'.

       If the 'xpath' feature is supported, then the
       following unqualified XML attribute is
       also supported:

         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 {
    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 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";
  }
  
  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.";
    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 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";
  }

  // NETCONF Simple Types

  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 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.";

       }
       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";
  }

  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.";
      }
      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
  
  rpc get-config {
    description
      "Retrieve all or part of a specified configuration.";

    reference "RFC 6241, Section 7.1";
    
    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.";
          }
        }
      }
      
      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.";
      }
    }
  }

  rpc edit-config {
    description
      "The <edit-config> operation loads all or part of a specified
       configuration to the specified target configuration.";

    reference "RFC 6241, Section 7.2";

    input {
      container target {
        description
          "Particular configuration to edit.";

        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 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.";
          }
        
          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.";
      }

      choice edit-content {
        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.";
        }
      }
    }
  }

  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";

    input {
      container target {
        description
          "Particular configuration to copy to.";

        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 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.";

        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 {
            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.";

    reference "RFC 6241, Section 7.4";
    
    input {
      container target {
        description
          "Particular configuration 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.";
          }
        }
      }
    }
  }
  
  rpc lock {
    description
      "The lock operation allows the client to lock the configuration
       system of a device.";

    reference "RFC 6241, Section 7.5";

    input {
      container target {
        description
          "Particular configuration 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.";
          }
        }
      }
    }
  }
  
  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";
    
    input {
      container target {
        description
          "Particular configuration to unlock.";

        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.";
          }
        }
      }
    }
  }
  
  rpc get {
    description
      "Retrieve running configuration and device state information.";

    reference "RFC 6241, Section 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;
      }
    }

    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.";
    
    reference "RFC 6241, Section 7.8";
  }

  rpc kill-session {
    description
      "Force the termination of a NETCONF session.";
    
    reference "RFC 6241, Section 7.9";
    
    input {
      leaf session-id {
        type session-id-type;
        mandatory true;
        description
          "Particular session to kill.";
      }
    }
  }

  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";

    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";
        }
        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.

           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.

           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";
      }

    }
  }

  rpc discard-changes {
    if-feature candidate;

    description
      "Revert the candidate configuration to the current 
       running configuration.";

    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";

    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;

    description
      "Validates the contents of the specified configuration.";

    reference "RFC 6241, Section 8.6.4.1";

    input {
      container source {
        description
          "Particular configuration 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 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.";
          }
        }
      }
    }
  }
  
}


]]></sourcecode>
    </section>
    <section anchor="capabilityTemplate" numbered="true" toc="default">
      <name>Capability Template</name>
      <t>
				 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.
      </t>
      <section numbered="true" toc="default">
        <name>capability-name (template)</name>
        <section numbered="true" toc="default">
          <name>Overview</name>
        </section>
        <section numbered="true" toc="default">
          <name>Dependencies</name>
        </section>
        <section numbered="true" toc="default">
          <name>Capability Identifier</name>
          <t>
             The {name} capability is identified by the following capability string:
          </t>
          <ul empty="true" spacing="normal">
            <li>
              <t>{capability uri}</t>
            </li>
          </ul>
        </section>
        <section numbered="true" toc="default">
          <name>New Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;op-name&gt;</name>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Modifications to Existing Operations</name>
          <section numbered="true" toc="default">
            <name>&lt;op-name&gt;</name>
            <t>If existing operations are not modified by this
             capability, this section may be omitted.</t>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Interactions with Other Capabilities</name>
          <t>If this capability does not interact with other
           capabilities, this section may be omitted.</t>
        </section>
      </section>
    </section>
    <section anchor="multidev" numbered="true" toc="default">
      <name>Configuring Multiple Devices with NETCONF</name>
      <t>
				 This section is non-normative.
      </t>
      <section numbered="true" toc="default">
        <name>Operations on Individual Devices</name>
        <t>
 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.
        </t>
        <t>
 Protecting each individual device consists of a number of steps:
        </t>
        <ul spacing="normal">
          <li>
            <t>Acquiring the configuration lock.</t>
          </li>
          <li>
            <t>Checkpointing the running configuration.</t>
          </li>
          <li>
            <t>Loading and validating the incoming configuration.</t>
          </li>
          <li>
            <t>Changing the running configuration.</t>
          </li>
          <li>
            <t>Testing the new configuration.</t>
          </li>
          <li>
            <t>Making the change permanent (if desired).</t>
          </li>
          <li>
            <t>Releasing the configuration lock.</t>
          </li>
        </ul>
        <t>
 Let's look at the details of each step.
        </t>
        <section numbered="true" toc="default">
          <name>Acquiring the Configuration Lock</name>
          <t>
 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.
          </t>
          <t>
 The lock can be acquired using the &lt;lock&gt; operation.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <lock>
      <target>
        <running/>
      </target>
    </lock>
  </rpc>
                 ]]></artwork>
          <t>
 If the :candidate capability is supported, the candidate configuration
 should be locked.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <lock>
      <target>
        <candidate/>
      </target>
    </lock>
  </rpc>
                 ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Checkpointing the Running Configuration</name>
          <t>
 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.
          </t>
          <t>
 The checkpoint file can be created using the &lt;copy‑config&gt; operation.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                 ]]></artwork>
          <t>
 To restore the checkpoint file, reverse the &lt;source&gt; and &lt;target&gt; parameters.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Loading and Validating the Incoming Configuration</name>
          <t>
 If the :candidate capability is supported, the configuration can be loaded onto the device without impacting the
 running system.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                 ]]></artwork>
          <t>
 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
 &lt;test‑option&gt; parameter with the value "set".  Full
 validation can be requested with the &lt;validate&gt; operation.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <validate>
      <source>
        <candidate/>
      </source>
    </validate>
  </rpc>
                 ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Changing the Running Configuration</name>
          <t>
 When the incoming configuration has been safely loaded onto the device
 and validated, it is ready to impact the running system.
          </t>
          <t>
 If the device supports the :candidate capability, use the &lt;commit&gt;
 operation to set the running configuration to the candidate
 configuration. Use the &lt;confirmed&gt; parameter to allow automatic
 reversion to the original configuration if connectivity to the device
 fails.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <commit>
      <confirmed/>
      <confirm-timeout>120</confirm-timeout>
    </commit>
  </rpc>
                 ]]></artwork>
          <t>
						 If the candidate is not supported by the device, the incoming configuration change is loaded directly into running.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                 ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Testing the New Configuration</name>
          <t>
 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.
          </t>
          <t>
 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).
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Making the Change Permanent</name>
          <t>
 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.
          </t>
          <t>
 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 &lt;copy‑config&gt; operation.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <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>
                 ]]></artwork>
          <t>
 If the device supports the :candidate capability and a confirmed
 commit was requested, the confirming commit must be sent before the
 timeout expires.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <commit/>
  </rpc>
                 ]]></artwork>
        </section>
        <section numbered="true" toc="default">
          <name>Releasing the Configuration Lock</name>
          <t>
 When the configuration update is complete, the lock must be
 released, allowing other applications access to the configuration.
          </t>
          <t>
 Use the &lt;unlock&gt; operation to release the configuration lock.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <unlock>
      <target>
        <running/>
      </target>
    </unlock>
  </rpc>
                 ]]></artwork>
          <t>
 If the :candidate capability is supported, the candidate configuration
 should be unlocked.
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <unlock>
      <target>
        <candidate/>
      </target>
    </unlock>
  </rpc>
                 ]]></artwork>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Operations on Multiple Devices</name>
        <t>
 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.
        </t>
        <t>
 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.
        </t>
        <t>
 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.
        </t>
        <t>
 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.
        </t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Changes from RFC 4741</name>
      <t>
				 This section lists major changes between this document and RFC 4741.
      </t>
      <ul spacing="normal">
        <li>
          <t>
						 Added the "malformed-message" error-tag.
          </t>
        </li>
        <li>
          <t>
             Added "remove" enumeration value to
             the "operation" attribute.
          </t>
        </li>
        <li>
          <t>
             Obsoleted the "partial-operation" error-tag
             enumeration value.
          </t>
        </li>
        <li>
          <t>
             Added &lt;persist&gt; and &lt;persist-id&gt;
             parameters to the &lt;commit&gt; operation.
          </t>
        </li>
        <li>
          <t>
             Updated the base protocol URI and clarified the
             &lt;hello&gt; message exchange to select and
             identify the base protocol version in use
             for a particular session.
          </t>
        </li>
        <li>
          <t>
             Added a YANG module to model the operations
             and removed the operation layer from the XSD.
          </t>
        </li>
        <li>
          <t>
             Clarified lock behavior for the candidate datastore.
          </t>
        </li>
        <li>
          <t>
             Clarified the error response server requirements for the
             "delete" enumeration value of the "operation" attribute.
          </t>
        </li>
        <li>
          <t>
						 Added a namespace wildcarding mechanism for subtree filtering.
          </t>
        </li>
        <li>
          <t>
						 Added a "test-only" value for the
						 &lt;test‑option&gt; parameter to the
						 &lt;edit‑config&gt; operation.
          </t>
        </li>
        <li>
          <t>
						 Added a &lt;cancel‑commit&gt; operation.
          </t>
        </li>
        <li>
          <t>
						 Introduced a NETCONF username and a requirement for
						 transport protocols to explain how a username is derived.
          </t>
        </li>
      </ul>
    </section>
  </back>
</rfc>
<!-- Local Variables: -->
<!-- tab-width: 2 -->
<!-- End: -->