tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4741


Pages: 95
Top     in Index     Prev     Next
 

NETCONF Configuration Protocol

Part 1 of 4, p. 1 to 17
None       Next RFC Part

Obsoleted by:    6241


Top       ToC       Page 1 
Network Working Group                                       R. Enns, Ed.
Request for Comments: 4741                              Juniper Networks
Category: Standards Track                                  December 2006


                     NETCONF Configuration Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   The Network Configuration Protocol (NETCONF) defined in this document
   provides mechanisms to install, manipulate, and delete the
   configuration of network devices.  It uses an Extensible Markup
   Language (XML)-based data encoding for the configuration data as well
   as the protocol messages.  The NETCONF protocol operations are
   realized on top of a simple Remote Procedure Call (RPC) layer.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................5
      1.1. Protocol Overview ..........................................6
      1.2. Capabilities ...............................................7
      1.3. Separation of Configuration and State Data .................7
   2. Transport Protocol Requirements .................................8
      2.1. Connection-Oriented Operation ..............................9
      2.2. Authentication, Integrity, and Confidentiality .............9
      2.3. Authentication .............................................9
      2.4. Mandatory Transport Protocol ..............................10
   3. XML Considerations .............................................10
      3.1. Namespace .................................................10
      3.2. No Document Type Declarations .............................10
   4. RPC Model ......................................................10
      4.1. <rpc> Element .............................................10
      4.2. <rpc-reply> Element .......................................12
      4.3. <rpc-error> Element .......................................12
      4.4. <ok> Element ..............................................16
      4.5. Pipelining ................................................16
   5. Configuration Model ............................................16
      5.1. Configuration Datastores ..................................16
      5.2. Data Modeling .............................................17
   6. Subtree Filtering ..............................................17
      6.1. Overview ..................................................17
      6.2. Subtree Filter Components .................................18
           6.2.1. Namespace Selection ................................18
           6.2.2. Attribute Match Expressions ........................19
           6.2.3. Containment Nodes ..................................19
           6.2.4. Selection Nodes ....................................20
           6.2.5. Content Match Nodes ................................20
      6.3. Subtree Filter Processing .................................22
      6.4. Subtree Filtering Examples ................................22
           6.4.1. No Filter ..........................................22
           6.4.2. Empty Filter .......................................23
           6.4.3. Select the Entire <users> Subtree ..................23
           6.4.4. Select All <name> Elements within the
                  <users> Subtree ....................................25
           6.4.5. One Specific <user> Entry ..........................26
           6.4.6. Specific Elements from a Specific <user> Entry .....27
           6.4.7. Multiple Subtrees ..................................28
           6.4.8. Elements with Attribute Naming .....................29
   7. Protocol Operations ............................................31
      7.1. <get-config> ..............................................31
      7.2. <edit-config> .............................................34
      7.3. <copy-config> .............................................39
      7.4. <delete-config> ...........................................41
      7.5. <lock> ....................................................42

Top      ToC       Page 3 
      7.6. <unlock> ..................................................44
      7.7. <get> .....................................................45
      7.8. <close-session> ...........................................47
      7.9. <kill-session> ............................................48
   8. Capabilities ...................................................49
      8.1. Capabilities Exchange .....................................49
      8.2. Writable-Running Capability ...............................50
           8.2.1. Description ........................................50
           8.2.2. Dependencies .......................................50
           8.2.3. Capability Identifier ..............................50
           8.2.4. New Operations .....................................51
           8.2.5. Modifications to Existing Operations ...............51
      8.3. Candidate Configuration Capability ........................51
           8.3.1. Description ........................................51
           8.3.2. Dependencies .......................................52
           8.3.3. Capability Identifier ..............................52
           8.3.4. New Operations .....................................52
           8.3.5. Modifications to Existing Operations ...............53
      8.4. Confirmed Commit Capability ...............................55
           8.4.1. Description ........................................55
           8.4.2. Dependencies .......................................55
           8.4.3. Capability Identifier ..............................56
           8.4.4. New Operations .....................................56
           8.4.5. Modifications to Existing Operations ...............56
      8.5. Rollback on Error Capability ..............................57
           8.5.1. Description ........................................57
           8.5.2. Dependencies .......................................57
           8.5.3. Capability Identifier ..............................57
           8.5.4. New Operations .....................................57
           8.5.5. Modifications to Existing Operations ...............57
      8.6. Validate Capability .......................................58
           8.6.1. Description ........................................58
           8.6.2. Dependencies .......................................58
           8.6.3. Capability Identifier ..............................58
           8.6.4. New Operations .....................................58
      8.7. Distinct Startup Capability ...............................60
           8.7.1. Description ........................................60
           8.7.2. Dependencies .......................................60
           8.7.3. Capability Identifier ..............................60
           8.7.4. New Operations .....................................60
           8.7.5. Modifications to Existing Operations ...............60
      8.8. URL Capability ............................................61
           8.8.1. Description ........................................61
           8.8.2. Dependencies .......................................61
           8.8.3. Capability Identifier ..............................62
           8.8.4. New Operations .....................................62
           8.8.5. Modifications to Existing Operations ...............62

Top      ToC       Page 4 
      8.9. XPath Capability ..........................................63
           8.9.1. Description ........................................63
           8.9.2. Dependencies .......................................63
           8.9.3. Capability Identifier ..............................63
           8.9.4. New Operations .....................................63
           8.9.5. Modifications to Existing Operations ...............63
   9. Security Considerations ........................................64
   10. IANA Considerations ...........................................66
      10.1. NETCONF XML Namespace ....................................66
      10.2. NETCONF XML Schema .......................................66
      10.3. NETCONF Capability URNs ..................................66
   11. Authors and Acknowledgements ..................................68
   12. References ....................................................68
      12.1. Normative References .....................................68
      12.2. Informative References ...................................69
   Appendix A. NETCONF Error List ....................................70
   Appendix B. XML Schema for NETCONF RPC and Protocol Operations ....74
   Appendix C. Capability Template ...................................86
      C.1. capability-name (template) ................................86
           C.1.1. Overview ...........................................86
           C.1.2. Dependencies .......................................86
           C.1.3. Capability Identifier ..............................86
           C.1.4. New Operations .....................................86
           C.1.5. Modifications to Existing Operations ...............86
           C.1.6. Interactions with Other Capabilities ...............86
   Appendix D.  Configuring Multiple Devices with NETCONF ............87
      D.1. Operations on Individual Devices ..........................87
           D.1.1. Acquiring the Configuration Lock ...................87
           D.1.2. Loading the Update .................................88
           D.1.3. Validating the Incoming Configuration ..............89
           D.1.4. Checkpointing the Running Configuration ............89
           D.1.5. Changing the Running Configuration .................90
           D.1.6. Testing the New Configuration ......................91
           D.1.7. Making the Change Permanent ........................91
           D.1.8. Releasing the Configuration Lock ...................92
      D.2. Operations on Multiple Devices ............................92
   Appendix E. Deferred Features .....................................93

Top      ToC       Page 5 
1.  Introduction

   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.

   The NETCONF protocol uses a remote procedure call (RPC) paradigm.  A
   client encodes an RPC in XML [1] 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.

   A key aspect of NETCONF is that it allows the functionality of the
   management protocol to closely mirror the native functionality of the
   device.  This reduces implementation costs and allows timely access
   to new features.  In addition, applications can access both the
   syntactic and semantic content of the device's native user interface.

   NETCONF allows a client to discover the set of protocol extensions
   supported by a server.  These "capabilities" permit the client to
   adjust its behavior to take advantage of the features exposed by the
   device.  The capability definitions can be easily extended in a
   noncentralized manner.  Standard and non-standard capabilities can be
   defined with semantic and syntactic rigor.  Capabilities are
   discussed in Section 8.

   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 [8], 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.

Top      ToC       Page 6 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

1.1.  Protocol Overview

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

   A NETCONF session is the logical connection between a network
   administrator or network configuration application and a network
   device.  A device MUST support at least one NETCONF session and
   SHOULD support multiple sessions.  Global configuration attributes
   can be changed during any authorized session, and the effects are
   visible in all sessions.  Session-specific attributes affect only the
   session in which they are changed.

   NETCONF can be conceptually partitioned into four layers:

              Layer                      Example
         +-------------+      +-----------------------------+
     (4) |   Content   |      |     Configuration data      |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (3) | Operations  |      | <get-config>, <edit-config> |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (2) |     RPC     |      |    <rpc>, <rpc-reply>       |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
     (1) |  Transport  |      |   BEEP, SSH, SSL, console   |
         |   Protocol  |      |                             |
         +-------------+      +-----------------------------+

   1.  The transport protocol layer provides a communication path
       between the client and server.  NETCONF can be layered over any
       transport protocol that provides a set of basic requirements.
       Section 2 discusses these requirements.

   2.  The RPC layer provides a simple, transport-independent framing
       mechanism for encoding RPCs.  Section 4 documents this protocol.

Top      ToC       Page 7 
   3.  The operations layer defines a set of base operations invoked as
       RPC methods with XML-encoded parameters.  Section 7 details the
       list of base operations.

   4.  The content layer is outside the scope of this document.  Given
       the current proprietary nature of the configuration data being
       manipulated, the specification of this content depends on the
       NETCONF implementation.  It is expected that a separate effort to
       specify a standard data definition language and standard content
       will be undertaken.

1.2.  Capabilities

   A NETCONF capability is a set of functionality that supplements the
   base NETCONF specification.  The capability is identified by a
   uniform resource identifier (URI).  These URIs should follow the
   guidelines as described in Section 8.

   Capabilities augment the base operations of the device, describing
   both additional operations and the content allowed inside operations.
   The client can discover the server's capabilities and use any
   additional operations, parameters, and content defined by those
   capabilities.

   The capability definition may name one or more dependent
   capabilities.  To support a capability, the server MUST support any
   capabilities upon which it depends.

   Section 8 defines the capabilities exchange that allows the client to
   discover the server's capabilities.  Section 8 also lists the set of
   capabilities defined in this document.

   Additional capabilities can be defined at any time in external
   documents, allowing the set of capabilities to expand over time.
   Standards bodies may define standardized capabilities, and
   implementations may define proprietary ones.  A capability URI MUST
   sufficiently distinguish the naming authority to avoid naming
   collisions.

1.3.  Separation of Configuration and State Data

   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

Top      ToC       Page 8 
   configuration data such as read-only status information and collected
   statistics.  When a device is performing configuration operations, a
   number of problems would arise if state data were included:

   o  Comparisons of configuration data sets would be dominated by
      irrelevant entries such as different statistics.

   o  Incoming data could contain nonsensical requests, such as attempts
      to write read-only data.

   o  The data sets would be large.

   o  Archived data could contain values for read-only data items,
      complicating the processing required to restore archived data.

   To account for these issues, the NETCONF protocol recognizes the
   difference between configuration data and state data and provides
   operations for each.  The <get-config> operation retrieves
   configuration data only, while the <get> operation retrieves
   configuration and state data.

   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.

   If a local database of user authentication data is stored on the
   device, whether it is included in configuration data is an
   implementation-dependent matter.

2.  Transport Protocol Requirements

   NETCONF uses an RPC-based communication paradigm.  A client sends a
   series of one or more RPC request operations, which cause the server
   to respond with a corresponding series of RPC replies.

   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.

   The transport protocol MUST provide a mechanism to indicate the
   session type (client or server) to the NETCONF protocol layer.

   This section details the characteristics that NETCONF requires from
   the underlying transport protocol.

Top      ToC       Page 9 
2.1.  Connection-Oriented Operation

   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.  This allows the client to make changes to the state of
   the connection that will persist for the lifetime of the connection.
   For example, authentication information specified for a connection
   remains in effect until the connection is closed.

   In addition, resources requested from the server for a particular
   connection MUST be automatically released when the connection closes,
   making failure recovery simpler and more robust.  For example, when a
   lock is acquired by a client, the lock persists until either it is
   explicitly released or the server determines that the connection has
   been terminated.  If a connection is terminated while the client
   holds a lock, the server can perform any appropriate recovery.  The
   lock operation is further discussed in Section 7.5.

2.2.  Authentication, Integrity, and Confidentiality

   NETCONF connections must provide authentication, data integrity, and
   confidentiality.  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 may be encrypted in TLS [9] or
   SSH [10], depending on the underlying protocol.

2.3.  Authentication

   NETCONF connections must be authenticated.  The transport protocol is
   responsible for authentication.  The peer assumes that the
   connection's authentication information has been validated by the
   underlying protocol using sufficiently trustworthy mechanisms and
   that the peer's identity has been sufficiently proven.

   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 defined by the device.  For
   example, a device that supports RADIUS [11] should allow the use of
   RADIUS to authenticate NETCONF sessions.

   The authentication process should result in an identity whose
   permissions are known to the device.  These permissions MUST be
   enforced during the remainder of the NETCONF session.

Top      ToC       Page 10 
2.4.  Mandatory Transport Protocol

   A NETCONF implementation MUST support the SSH transport protocol
   mapping [4].

3.  XML Considerations

   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.

   This section discusses a small number of XML-related considerations
   pertaining to NETCONF.

3.1.  Namespace

   All NETCONF protocol elements are defined in the following namespace:

      urn:ietf:params:xml:ns:netconf:base:1.0

   NETCONF capability names MUST be URIs [5].  NETCONF capabilities are
   discussed in Section 8.

3.2.  No Document Type Declarations

   Document type declarations MUST NOT appear in NETCONF content.

4.  RPC Model

   The NETCONF protocol uses an RPC-based communication model.  NETCONF
   peers use <rpc> and <rpc-reply> elements to provide transport
   protocol-independent framing of NETCONF requests and responses.

4.1.  <rpc> Element

   The <rpc> element is used to enclose a NETCONF request sent from the
   client to the server.

   The <rpc> element has a mandatory attribute "message-id", which is an
   arbitrary string chosen by the sender of the RPC that will commonly
   encode a monotonically increasing integer.  The receiver of the RPC
   does not decode or interpret this string but simply saves it to be
   used as a "message-id" attribute in any resulting <rpc-reply>
   message.  For example:

Top      ToC       Page 11 
       <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <some-method>
           <!-- method parameters here... -->
         </some-method>
       </rpc>

   If additional attributes are present in an <rpc> element, a NETCONF
   peer MUST return them unmodified in the <rpc-reply> element.

   The name and parameters of an RPC are encoded as the contents of the
   <rpc> element.  The name of the RPC is an element directly inside the
   <rpc> element, and any parameters are encoded inside this element.

   The following example invokes a method called <my-own-method>, which
   has two parameters, <my-first-parameter>, with a value of "14", and
   <another-parameter>, with a value of "fred":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <my-own-method xmlns="http://example.net/me/my-own/1.0">
         <my-first-parameter>14</my-first-parameter>
         <another-parameter>fred</another-parameter>
       </my-own-method>
     </rpc>

   The following example invokes a <rock-the-house> method with a
   <zip-code> parameter of "27606-0100":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns="http://example.net/rock/1.0">
         <zip-code>27606-0100</zip-code>
       </rock-the-house>
     </rpc>

   The following example invokes the NETCONF <get> method with no
   parameters:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get/>
     </rpc>

Top      ToC       Page 12 
4.2.  <rpc-reply> Element

   The <rpc-reply> message is sent in response to an <rpc> operation.

   The <rpc-reply> element has a mandatory attribute "message-id", which
   is equal to the "message-id" attribute of the <rpc> for which this is
   a response.

   A NETCONF peer MUST also return any additional attributes included in
   the <rpc> element unmodified in the <rpc-reply> element.

   The response name and response data are encoded as the contents of
   the <rpc-reply> element.  The name of the reply is an element
   directly inside the <rpc-reply> element, and any data is encoded
   inside this element.

   For example:

   The following <rpc> element invokes the NETCONF <get> method and
   includes an additional attribute called "user-id".  Note that the
   "user-id" attribute is not in the NETCONF namespace.  The returned
   <rpc-reply> element returns the "user-id" attribute, as well as the
   requested content.

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

4.3.  <rpc-error> Element

   The <rpc-error> element is sent in <rpc-reply> messages if an error
   occurs during the processing of an <rpc> request.

   If a server encounters multiple errors during the processing of an
   <rpc> request, the <rpc-reply> MAY contain multiple <rpc-error>
   elements.  However, a server is not required to detect or report more

Top      ToC       Page 13 
   than one <rpc-error> element, if a request contains multiple errors.
   A server is not required to check for particular error conditions in
   a specific sequence.  A server MUST return an <rpc-error> element if
   any error conditions occur during processing and SHOULD return an
   <rpc-error> element if any warning conditions occur during
   processing.

   A server MUST NOT return application-level- or data-model-specific
   error information in an <rpc-error> element for which the client does
   not have sufficient access rights.

   The <rpc-error> element includes the following information:

   error-type: Defines the conceptual layer that the error occurred.
      Enumeration.  One of:

      *  transport

      *  rpc

      *  protocol

      *  application

   error-tag: Contains a string identifying the error condition.  See
      Appendix A for allowed values.

   error-severity: Contains a string identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

   error-app-tag: Contains a string identifying the data-model-specific
      or implementation-specific error condition, if one exists.  This
      element will not be present if no appropriate application error
      tag can be associated with a particular error condition.

   error-path: Contains the absolute XPath [2] expression identifying
      the element path to the node that is associated with the error
      being reported in a particular rpc-error element.  This element
      will not be present if no appropriate payload element can be
      associated with a particular error condition, or if the
      'bad-element' QString returned in the 'error-info' container is
      sufficient to identify the node associated with the error.  When

Top      ToC       Page 14 
      the XPath expression is interpreted, the set of namespace
      declarations are those in scope on the rpc-error element,
      including the default namespace.

   error-message: Contains a string suitable for human display that
      describes the error condition.  This element will not be present
      if no appropriate message is provided for a particular error
      condition.  This element SHOULD include an xml:lang attribute as
      defined in [1] and discussed in [12].

   error-info: Contains protocol- or data-model-specific error content.
      This element will not be present if no such error content is
      provided for a particular error condition.  The list in Appendix A
      defines any mandatory error-info content for each error.  After
      any protocol-mandated content, a data model definition may mandate
      that certain application-layer error information be included in
      the error-info container.  An implementation may include
      additional elements to provide extended and/or implementation-
      specific debugging information.

   Appendix A enumerates the standard NETCONF errors.

   Example:

      An error is returned if an <rpc> element is received without a
      message-id attribute.  Note that only in this case is it
      acceptable for the NETCONF peer to omit the message-id attribute
      in the <rpc-reply> element.

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

Top      ToC       Page 15 
      The following <rpc-reply> illustrates the case of returning
      multiple <rpc-error> elements.

      Note that the data models used in the examples in this section use
      the <name> element to distinguish between multiple instances of
      the <interface> element.

     <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-message xml:lang="en">
           MTU value 25000 is not within range 256..9192
         </error-message>
         <error-info>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>25000</mtu>
             </interface>
           </top>
         </error-info>
       </rpc-error>
       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-message xml:lang="en">
           Invalid IP address for interface Ethernet1/0
         </error-message>
         <error-info>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="replace">
               <name>Ethernet1/0</name>
               <address>
                 <name>1.4</name>
                 <prefix-length>24</prefix-length>
               </address>
             </interface>
           </top>
         </error-info>
       </rpc-error>
     </rpc-reply>

Top      ToC       Page 16 
4.4.  <ok> Element

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request.  For
   example:

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

4.5.  Pipelining

   NETCONF <rpc> requests MUST be processed serially by the managed
   device.  Additional <rpc> requests MAY be sent before previous ones
   have been completed.  The managed device MUST send responses only in
   the order the requests were received.

5.  Configuration Model

   NETCONF provides an initial set of operations and a number of
   capabilities that can be used to extend the base.  NETCONF peers
   exchange device capabilities when the session is initiated as
   described in Section 8.1.

5.1.  Configuration Datastores

   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.

   Only the <running> configuration datastore is present in the base
   model.  Additional configuration datastores may be defined by
   capabilities.  Such configuration datastores are available only on
   devices that advertise the capabilities.

   o  Running: The complete configuration currently active on the
      network device.  Only one configuration datastore of this type
      exists on the device, and it is always present.  NETCONF protocol
      operations refer to this datastore using the <running> element.

   The capabilities in Sections 8.3 and 8.7 define the <candidate> and
   <startup> configuration datastores, respectively.

Top      ToC       Page 17 
5.2.  Data Modeling

   Data modeling and content issues are outside the scope of the NETCONF
   protocol.  An assumption is made that the device's data model is
   well-known to the application and that both parties are aware of
   issues such as the layout, containment, keying, lookup, replacement,
   and management of the data, as well as any other constraints imposed
   by the data model.

   NETCONF carries configuration data inside the <config> element that
   is specific to 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.

   Devices and managers may support multiple data models, including both
   standard and proprietary data models.



(page 17 continued on part 2)

Next RFC Part