tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6241

 
 
 

Network Configuration Protocol (NETCONF)

Part 2 of 5, p. 13 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
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.

   The syntax and XML encoding of the Messages-layer RPCs are formally
   defined in the XML schema in Appendix B.

4.1.  <rpc> Element

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

Top      Up      ToC       Page 14 
   The <rpc> element has a mandatory attribute "message-id", which is a
   string chosen by the sender of the RPC that will commonly encode a
   monotonically increasing integer.  The receiver of the RPC does not
   decode or interpret this string but simply saves it to be used as a
   "message-id" attribute in any resulting <rpc-reply> message.  The
   sender MUST ensure that the "message-id" value is normalized
   according to the XML attribute value normalization rules defined in
   [W3C.REC-xml-20001006] if the sender wants the string to be returned
   unmodified.  For example:

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

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

   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>

Top      Up      ToC       Page 15 
   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>

4.2.  <rpc-reply> Element

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

   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 server MUST also return any additional attributes included
   in the <rpc> element unmodified in the <rpc-reply> element.

   The response data is encoded as one or more child elements to the
   <rpc-reply> 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>

Top      Up      ToC       Page 16 
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
   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.

   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 (layer: Secure Transport)

      *  rpc (layer: Messages)

      *  protocol (layer: Operations)

      *  application (layer: Content)

   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

      Note that there are no <error-tag> values defined in this document
      that utilize the "warning" enumeration.  This is reserved for
      future use.

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

Top      Up      ToC       Page 17 
      data-model-specific and an implementation-specific error-app-tag
      both exist, then the data-model-specific value MUST be used by the
      server.

   error-path:  Contains the absolute XPath [W3C.REC-xpath-19991116]
      expression identifying the element path to the node that is
      associated with the error being reported in a particular
      <rpc-error> element.  This element will not be present if no
      appropriate payload element or datastore node can be associated
      with a particular error condition.

      The XPath expression is interpreted in the following context:

      *  The set of namespace declarations are those in scope on the
         <rpc-error> element.

      *  The set of variable bindings is empty.

      *  The function library is the core function library.

      The context node depends on the node associated with the error
      being reported:

      *  If a payload element can be associated with the error, the
         context node is the rpc request's document node (i.e., the
         <rpc> element).

      *  Otherwise, the context node is the root of all data models,
         i.e., the node that has the top-level nodes from all data
         models as children.

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

   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.

Top      Up      ToC       Page 18 
   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>

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

Top      Up      ToC       Page 19 
         <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>

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, and no
   data was returned from the operation.  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.

Top      Up      ToC       Page 20 
   The running configuration datastore holds the complete configuration
   currently active on the network device.  Only one configuration
   datastore of this type exists on the device, and it is always
   present.  NETCONF protocol operations refer to this datastore using
   the <running> element.

   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.

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

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

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

6.  Subtree Filtering

6.1.  Overview

   XML subtree filtering is a mechanism that allows an application to
   select particular XML subtrees to include in the <rpc-reply> for a
   <get> or <get-config> operation.  A small set of filters for
   inclusion, simple content exact-match, and selection is provided,
   which allows some useful, but also very limited, selection
   mechanisms.  The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.

Top      Up      ToC       Page 21 
   Conceptually, a subtree filter is comprised of zero or more element
   subtrees, which represent the filter selection criteria.  At each
   containment level within a subtree, the set of sibling nodes is
   logically processed by the server to determine if its subtree and
   path of elements to the root are included in the filter output.

   Each node specified in a subtree filter represents an inclusive
   filter.  Only associated nodes in underlying data model(s) within the
   specified datastore on the server are selected by the filter.  A node
   is selected if it matches the selection criteria and hierarchy of
   elements given in the filter data, except that the filter absolute
   path name is adjusted to start from the layer below <filter>.

   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.

6.2.  Subtree Filter Components

   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:

   o  Namespace Selection

   o  Attribute Match Expressions

   o  Containment Nodes

   o  Selection Nodes

   o  Content Match Nodes

6.2.1.  Namespace Selection

   A namespace is considered to match (for filter purposes) if the XML
   namespace associated with a particular node within the <filter>
   element is the same as in the underlying data model.  Note that
   namespace selection cannot be used by itself.  At least one element
   MUST be specified in the filter if any elements are to be included in
   the filter output.

Top      Up      ToC       Page 22 
   An XML namespace wildcard mechanism is defined for subtree filtering.
   If an element within the <filter> element is not qualified by a
   namespace (e.g., xmlns=""), then the server MUST evaluate all the XML
   namespaces it supports, when processing that subtree filter node.
   This wildcard mechanism is not applicable to XML attributes.

   Note that prefix values for qualified namespaces are not relevant
   when comparing filter elements to elements in the underlying data
   model.

   Example:

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config"/>
     </filter>

   In this example, the <top> element is a selection node, and only this
   node in the "http://example.com/schema/1.2/config" namespace and any
   child nodes (from the underlying data model) will be included in the
   filter output.

6.2.2.  Attribute Match Expressions

   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.

   Example:

     <filter type="subtree">
       <t:top xmlns:t="http://example.com/schema/1.2/config">
         <t:interfaces>
           <t:interface t:ifName="eth0"/>
         </t:interfaces>
       </t:top>
     </filter>

   In this example, the <top> and <interfaces> elements are containment
   nodes, the <interface> element is a selection node, and "ifName" is
   an attribute match expression.  Only "interface" nodes in the
   "http://example.com/schema/1.2/config" namespace that have an
   "ifName" attribute with the value "eth0" and occur within
   "interfaces" nodes within "top" nodes will be included in the filter
   output.

Top      Up      ToC       Page 23 
6.2.3.  Containment Nodes

   Nodes that contain child elements within a subtree filter are called
   "containment nodes".  Each child element can be any type of node,
   including another containment node.  For each containment node
   specified in a subtree filter, all data model instances that exactly
   match the specified namespaces, element hierarchy, and any attribute
   match expressions are included in the filter output.

   Example:

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

   In this example, the <top> element is a containment node.

6.2.4.  Selection Nodes

   An empty leaf node within a filter is called a "selection node", and
   it represents an "explicit selection" filter on the underlying data
   model.  Presence of any selection nodes within a set of sibling nodes
   will cause the filter to select the specified subtree(s) and suppress
   automatic selection of the entire set of sibling nodes in the
   underlying data model.  For filtering purposes, an empty leaf node
   can be declared either with an empty tag (e.g., <foo/>) or with
   explicit start and end tags (e.g., <foo> </foo>).  Any whitespace
   characters are ignored in this form.

   Example:

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

   In this example, the <top> element is a containment node, and the
   <users> element is a selection node.  Only "users" nodes in the
   "http://example.com/schema/1.2/config" namespace that occur within a
   <top> element that is the root of the configuration datastore will be
   included in the filter output.

Top      Up      ToC       Page 24 
6.2.5.  Content Match Nodes

   A leaf node that contains simple content is called a "content match
   node".  It is used to select some or all of its sibling nodes for
   filter output, and it represents an exact-match filter on the leaf
   node element content.  The following constraints apply to content
   match nodes:

   o  A content match node MUST NOT contain nested elements.

   o  Multiple content match nodes (i.e., sibling nodes) are logically
      combined in an "AND" expression.

   o  Filtering of mixed content is not supported.

   o  Filtering of list content is not supported.

   o  Filtering of whitespace-only content is not supported.

   o  A content match node MUST contain non-whitespace characters.  An
      empty element (e.g., <foo></foo>) will be interpreted as a
      selection node (e.g., <foo/>).

   o  Leading and trailing whitespace characters are ignored, but any
      whitespace characters within a block of text characters are not
      ignored or modified.

   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:

   o  Each content match node in the sibling set is included in the
      filter output.

   o  If any containment nodes are present in the sibling set, then they
      are processed further and included if any nested filter criteria
      are also met.

   o  If any selection nodes are present in the sibling set, then all of
      them are included in the filter output.

   o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

Top      Up      ToC       Page 25 
   o  Otherwise (i.e., there are no selection or containment nodes in
      the filter sibling set), all the nodes defined at this level in
      the underlying data model (and their subtrees, if any) are
      returned in the filter output.

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

   Example:

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>

   In this example, the <users> and <user> nodes are both containment
   nodes, and <name> is a content match node.  Since no sibling nodes of
   <name> are specified (and therefore no containment or selection
   nodes), all of the sibling nodes of <name> are returned in the filter
   output.  Only "user" nodes in the
   "http://example.com/schema/1.2/config" namespace that match the
   element hierarchy and for which the <name> element is equal to "fred"
   will be included in the filter output.

6.3.  Subtree Filter Processing

   The filter output (the set of selected nodes) is initially empty.

   Each subtree filter can contain one or more data model fragments,
   which represent portions of the data model that will be selected
   (with all child nodes) in the filter output.

   Each subtree data fragment is compared by the server to the internal
   data models supported by the server.  If the entire subtree data-
   fragment filter (starting from the root to the innermost element
   specified in the filter) exactly matches a corresponding portion of
   the supported data model, then that node and all its children are
   included in the result data.

   The server processes all nodes with the same parent node (sibling
   set) together, starting from the root to the leaf nodes.  The root

Top      Up      ToC       Page 26 
   elements in the filter are considered in the same sibling set
   (assuming they are in the same namespace), even though they do not
   have a common parent.

   For each sibling set, the server determines which nodes are included
   (or potentially included) in the filter output, and which sibling
   subtrees are excluded (pruned) from the filter output.  The server
   first determines which types of nodes are present in the sibling set
   and processes the nodes according to the rules for their type.  If
   any nodes in the sibling set are selected, then the process is
   recursively applied to the sibling sets of each selected node.  The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

6.4.  Subtree Filtering Examples

6.4.1.  No Filter

   Leaving out the filter on the <get> operation returns the entire data
   model.

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

6.4.2.  Empty Filter

   An empty filter will select nothing because no content match or
   selection nodes are present.  This is not an error.  The <filter>
   element's "type" attribute used in these examples is discussed
   further in Section 7.1.

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

Top      Up      ToC       Page 27 
     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
       </data>
     </rpc-reply>

6.4.3.  Select the Entire <users> Subtree

   The filter in this example contains one selection node (<users>), so
   just that subtree is selected by the filter.  This example represents
   the fully populated <users> data model in most of the filter examples
   that follow.  In a real data model, the <company-info> would not
   likely be returned with the list of users for a particular host or
   network.

   NOTE: The filtering and configuration examples used in this document
   appear in the namespace "http://example.com/schema/1.2/config".  The
   root element of this namespace is <top>.  The <top> element and its
   descendents represent an example configuration data model only.

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

Top      Up      ToC       Page 28 
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>2</id>
               </company-info>
             </user>
             <user>
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>3</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

   The following filter request would have produced the same result, but
   only because the container <users> defines one child element
   (<user>).

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

Top      Up      ToC       Page 29 
6.4.4.  Select All <name> Elements within the <users> Subtree

   This filter contains two containment nodes (<users>, <user>) and one
   selection node (<name>).  All instances of the <name> element in the
   same sibling set are selected in the filter output.  The client might
   need to know that <name> is used as an instance identifier in this
   particular data structure, but the server does not need to know that
   meta-data in order to process the request.

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

Top      Up      ToC       Page 30 
6.4.5.  One Specific <user> Entry

   This filter contains two containment nodes (<users>, <user>) and one
   content match node (<name>).  All instances of the sibling set
   containing <name> for which the value of <name> equals "fred" are
   selected in the filter output.

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

Top      Up      ToC       Page 31 
6.4.6.  Specific Elements from a Specific <user> Entry

   This filter contains two containment nodes (<users>, <user>), one
   content match node (<name>), and two selection nodes (<type>,
   <full-name>).  All instances of the <type> and <full-name> elements
   in the same sibling set containing <name> for which the value of
   <name> equals "fred" are selected in the filter output.  The
   <company-info> element is not included because the sibling set
   contains selection nodes.

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

Top      Up      ToC       Page 32 
6.4.7.  Multiple Subtrees

   This filter contains three subtrees (name=root, fred, barney).

   The "root" subtree filter contains two containment nodes (<users>,
   <user>), one content match node (<name>), and one selection node
   (<company-info>).  The subtree selection criteria are met, and just
   the company-info subtree for "root" is selected in the filter output.

   The "fred" subtree filter contains three containment nodes (<users>,
   <user>, <company-info>), one content match node (<name>), and one
   selection node (<id>).  The subtree selection criteria are met, and
   just the <id> element within the company-info subtree for "fred" is
   selected in the filter output.

   The "barney" subtree filter contains three containment nodes
   (<users>, <user>, <company-info>), two content match nodes (<name>,
   <type>), and one selection node (<dept>).  The subtree selection
   criteria are not met because user "barney" is not a "superuser", and
   the entire subtree for "barney" (including its parent <user> entry)
   is excluded from the filter output.

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

Top      Up      ToC       Page 33 
             </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>

6.4.8.  Elements with Attribute Naming

   In this example, the filter contains one containment node
   (<interfaces>), one attribute match expression ("ifName"), and one
   selection node (<interface>).  All instances of the <interface>
   subtree that have an "ifName" attribute equal to "eth0" are selected
   in the filter output.  The filter data elements and attributes are
   qualified because the "ifName" attribute will not be considered part
   of the "schema/1.2" namespace if it is unqualified.

Top      Up      ToC       Page 34 
     <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>

   If "ifName" were a child node instead of an attribute, then the
   following request would produce similar results.

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


Next RFC Part