RFC 6241
Network Configuration Protocol (NETCONF)
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.
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>
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>
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
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.
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>
<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.
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.
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 Nodes6.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.
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.
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.
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.
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
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>
<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>
<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>
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>
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>
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>
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>
</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.
<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 page on part 3)
