skip to content

When does a NETCONF client need an XPath filter instead of a subtree filter, and what must it confirm about the server before sending one?

level: seniorimportance: should knowfreq 8%

answer

  1. exact match versus expressions
  2. an optional capability in the hello
  3. an attribute on an empty element
  4. the result must be a node-set

basics

~20 s

When selection needs more than exact matches, such as comparisons, functions or conditions elsewhere in the tree. The server must advertise the :xpath capability; then the filter has type xpath, an empty <filter> element and the expression in a select attribute.

solid answer

~40 s

Subtree filtering only tests exact equality on leaf text, ANDs tests within a sibling set and expresses alternatives as repeated fragments. It cannot say "in-errors greater than zero", "name starts with eth" or "interfaces whose description is empty". An XPath 1.0 filter can. It is optional: the server must advertise `urn:ietf:params:netconf:capability:xpath:1.0`. RFC 6241 then requires `type="xpath"`, a `select` attribute holding the expression, and an **empty** `<filter>` element. Prefixes resolve against the namespace declarations in scope on `<filter>`, the context node is the root, and the expression must return a node-set, or the operation fails with `invalid-value`. The reply includes each selected node's ancestors and list keys. Use subtree where it suffices; reach for XPath only when the selection needs it.

go deeper

for a junior

Recall that NETCONF has two filter types, subtree by default and XPath when the server allows it.

for a middle

Explain what subtree filtering cannot express, and the required form of an XPath filter: capability, type, select attribute and empty element.

for a senior

Show you check :xpath per device, declare namespaces on the filter, expect ancestors and keys in the reply, and keep subtree filtering for predictable polling.

for a principal

Weigh XPath's expressive power against how hard its server-side cost is to predict across a mixed fleet, and the fallback a collector needs.

## Two filter types, one `<filter>` element `<get>` and `<get-config>` take an optional `<filter>`. Its `type` attribute chooses the language: `subtree` (the default when the attribute is absent, RFC 6241 section 6) or `xpath` (section 8.9). RFC 8526's `<get-data>` on an NMDA server offers the same choice as `subtree-filter` and `xpath-filter`, and its XPath form depends on the same capability. The XPath language itself is a separate subject; what matters here is what each filter type can **express** and what NETCONF requires around it. ## What a subtree filter cannot say A subtree filter is deliberately small. RFC 6241 describes it as useful but very limited, and notes that the server needs no data-model-specific semantics to process it, which keeps implementations simple. Its tests are: - **exact equality** on the text of a leaf (a content-match node); - **AND** between sibling content-match nodes; - **alternatives** written as separate fragments (two `<interface>` entries). There is no inequality, no ordering, no pattern and no test that refers to a node outside the sibling set. | Need | Subtree filter | XPath filter | |---|---|---| | One interface by name | yes | yes | | Interfaces eth0 and eth1 | yes, two fragments | yes, `or` or a union | | Enabled interfaces only | yes, `enabled` = `true` | yes | | Interfaces with `in-errors` above 0 | **no** | yes, a numeric predicate | | Names starting with `eth` | **no** | yes, `starts-with()` | | Entries chosen by a value in another subtree | **no** | yes, a path in the predicate | ## What the client must confirm and send 1. **The capability.** The server's hello must list `urn:ietf:params:netconf:capability:xpath:1.0`. Without it, `type="xpath"` is not something the server agreed to process. RFC 6241 permits the value only when the peer supports the capability, so expect the request to be rejected, and check before sending rather than relying on that. 2. **The form.** `type="xpath"`, a **`select` attribute** holding the expression (it MUST be present), and an **empty** `<filter>` element. The expression does not go in the element's content. 3. **The namespaces.** Prefixes in the expression resolve against the namespace declarations **in scope on the `<filter>` element**, so declare them there. The device's own module prefixes are not applied automatically. 4. **The evaluation context.** The context node is the root; the function library is XPath 1.0's core library plus any the data model defines. ```xml <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="xpath" xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" select="/if:interfaces/if:interface[if:statistics/if:in-errors &gt; 0]/if:name"/> </get> </rpc> ``` ## What comes back, and how it fails - The expression **must return a node-set**. `count(...)` returns a number, so the operation fails with error-tag `invalid-value` rather than returning the number. - For each selected node the server encodes **all ancestors**, plus any sibling or ancestor nodes needed to identify a list instance (its keys). Selecting `name` above therefore returns `interfaces` / `interface` / `name`, which is enough to see which interfaces have errors. - Data selected more than once is not duplicated. ## The same need, written both ways Fetching the names of two interfaces shows where the two forms overlap. As a subtree filter it is two fragments, `<interface><name>eth0</name></interface>` and the same for `eth1`, each returning the whole entry unless a selection node narrows it. As an XPath filter it is one `select` with an `or` in the predicate. Both are correct; the subtree version works on every server. Only when the condition is a comparison, a function or a reference to another part of the tree does XPath become the only server-side option, and the alternative is fetching more and filtering on the client. ## Choosing between them - **Default to subtree.** Every server supports it, and it is the form whose cost is easiest to predict, which matters for frequent polling. - **Use XPath when the selection is the point**: a sweep for interfaces with errors returns a few names instead of the counters of every interface. - **Keep XPath paths absolute and anchored.** An expression such as `//*[...]` asks the server to search its whole tree; a capability check proves the server accepts XPath, not that it evaluates it cheaply. - **Have a fallback.** A collector serving mixed devices needs a subtree-plus-client-side-filtering path for servers that do not advertise `:xpath`.

  • Why might a NETCONF reply to an XPath filter contain nodes the expression did not select?
    RFC 6241 section 8.9 requires the server to encode every ancestor of each selected node first, plus any sibling or ancestor nodes needed to identify a list instance, typically the list keys. A filter selecting `in-errors` therefore also returns the enclosing `interfaces`, `interface` and `name`, so the reply is a set of fully specified subtrees rather than loose leaves.
  • An XPath filter returns nothing although the data exists; what is the usual NETCONF-side cause?
    A namespace problem: the prefix in the `select` expression is undeclared or bound to the wrong URI on the `<filter>` element, so no node matches. Prefixes resolve only against declarations in scope on `<filter>`; the module's own prefix and the device's naming do not apply. Declaring the module namespace with the prefix the expression uses fixes it.

saying these in an interview costs you the question

  • Every NETCONF server accepts XPath filters; the :xpath capability is informational.
  • An XPath filter's expression goes inside the <filter> element as text.
  • XPath prefixes resolve to the device's module prefixes automatically.
  • A subtree filter cannot fetch two specific list entries in one request.
  • A select of count(...) returns the number of matching nodes in the reply.