Monitoring

There are several builtin operations for retrieving YANG data from the server.

Operation	Reference	Notes
<get>	RFC 6241 Section 7.7	Contains config=true from 'running' and all config='false'
<get-bulk>	N/A	Contains list entries from the specified datastore.
<get-config>	RFC 6241 Section 7.1	Contains config=true from the specified datastore
<get-data>	RFC 8526 Section 3.1.1	Contains all data from the specified NMDA datastore
<get-ha-status>	N/A	Retrieve the High Availability (YP-HA) status for the server
<get-module-tags>	N/A	Retrieve the module-tag mappings enabled on the server
<get-my-session>	N/A	Retrieve info about your NETCONF session
<get-schema>	RFC 6022 Section 4.2	Retrieve a YANG module
<get-server-version>	N/A	Retrieve the server version and build date
<get-sm-yanglib>	N/A	Retrieve the YANG library for the Schema Mount mountpoint
<get-support-save>	N/A	Retrieve server information for a support ticket.
<get-yang-sid-data>	N/A	Retrieve the YANG to SID mapping information for the server.

Notes:

• The <get> and <get-config> operations are fully supported for retrieving data from the <candidate> and <running> configuration databases.

• The <get-config> operation is not supported for the <startup> configuration.

• The <copy-config> operation is only supported copying the <running> configuration to the <startup> configuration.

NACM Filtering:

If the NACM access control policy denies permission to read a particular node, then that node is silently skipped in the output. No error or warning messages will be generated.

Client applications should be prepared to receive XML subtrees that have been pruned by access control. The <data> element will always be present, so an empty <data/> element indicates that no data was returned, either because the <filter> did not match, or because access control pruned the requested nodes.

Filter Types

Type	Description
is_config()	Choose the <get> operation for all objects, or <get-config> for just config=true objects
is_default()	Set the <with-defaults> parameter to 'trim'
is_client_set()	Set the <with-defaults> parameter to 'explicit'
subtree filtering	Use a subtree filter to retrieve portions of the <candidate> or <running> configurations.
XPath filtering	Use <filter type="xpath" select="expr"/> to retrieve portions of the <candidate> or <running> configurations.
module-tag filtering	Use the --module-tag parameter

Using Subtree Filters

The subtree filtering feature defined in RFC 6241 is fully supported.

The order of nodes within the <filter> element is not relevant. Data returned in the <rpc-reply> should follow the same top-level order as the request, but this should not be relied on to always be the case.

Duplicate or overlapping subtrees within the request will be combined in the output, so the common ancestor nodes are not duplicated in the reply.

• The /filters subtree from ietf-subscribed-notifications.yang is fully supported for storing reusable subtree and XPath filters in the server.

The following operations support a subtree filter parameter for selecting node-sets.

Operation	Parameter	Notes
<create-subscription>	filter type='subtree'	RFC 5277 Section 3.6
<establish-subscription>	datastore-subtree-filter	Datastore subscription
<establish-subscription>	stream-subtree-filter	Event Stream subscription
<get>	filter type='subtree'	RFC 6241 Section 7.7
<get-config>	filter type='subtree'	RFC 6241 Section 7.1
<get-data>	subtree-filter	RFC 8526 Section 3.1.1

XML Namespaces

XML namespaces are optional to use:

• If there is no namespace in affect for a filter component, or the 'NETCONF' namespace is in effect, the server will attempt to find any top-level data node which matches.

• Namespaces within descendant nodes of the <filter> node children are inherited from their parent. If none is in effect, then the first matching child node for the current parent node will be used.

• Invalid namespace errors for the <filter> element are suppressed in the server. An invalid namespace or unknown element is simply a 'no-match' condition.

For example, the following PDU would be valid, even though it is not technically valid XML:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="8">
  <nc:get>
    <nc:filter>
      <nacm />
    </nc:filter>
  </nc:get>
</nc:rpc>

Note that there is no default namespace in effect for the <nacm> subtree. However, the server will accept this filter as if the ietf-netconf-acm.yang module namespace was properly declared.

The following request is shown with the proper XML namespace declaration.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="9" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
 </get>
</rpc>

Content Match Filters

Subtree filters can select specific list entries using content match nodes. The following example would return the entire contents of the <interface> entry for 'eth0':

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="9">
  <nc:get>
    <nc:filter type="subtree">
      <if:interfaces xmlns:if="http://netconfcentral.org/ns/yuma-interfaces">
        <if:interface>
          <if:name>eth0</if:name>
        </if:interface>
      </if:interfaces>
    </nc:filter>
  </nc:get>
</nc:rpc>

To retrieve only specific nodes (such as counters) from a single list entry, use select nodes for the desired counter(s), and include a content match node for each key leaf. A missing key leaf will match any entry for that key.

The following example request shows how just the <inBytes> and <outBytes> counters could be retrieved from the <interface> entry for 'eth0'.

Example Request:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="10">
  <nc:get>
    <nc:filter type="subtree">
      <if:interfaces xmlns:if="http://netconfcentral.org/ns/yuma-interfaces">
        <if:interface>
          <if:name>eth0</if:name>
          <if:counters>
            <if:inBytes/>
            <if:outBytes/>
          </if:counters>
        </if:interface>
      </if:interfaces>
    </nc:filter>
  </nc:get>
</nc:rpc>

Example Reply:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="10">
  <nc:data>
    <if:interfaces xmlns:if="http://netconfcentral.org/ns/interfaces">
      <if:interface>
        <if:name>eth0</if:name>
        <if:counters>
          <if:inBytes>290046042</if:inBytes>
          <if:outBytes>112808406</if:outBytes>
        </if:counters>
      </if:interface>
    </if:interfaces>
  </nc:data>
</nc:rpc-reply>

Using Regex Filters

A standard subtree filter content-match expression is an exact-match test. If the --with-regex-filter CLI parameter is set to 'true' (default) then regular expressions can also be used in content match expressions.

Regex Language Types

Both YANG and POSIX formats are supported for regular expression syntax. An expression prefix is used to identify the language.

• r1 : YANG pattern syntax

• r2 : POSIX (ocpattern) syntax

Regex Template

If enabled, then the server will check content-match expressions for the correct syntax:

prefix '(' expr ')'

If the string matches this template then it will be checked against data node values using the regex test, not an exact match.

Regex Example

• Retrieve the 'interface' entries that have a name that starts with the string eno

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="3"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="subtree">
   <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
     <name>r1(eno.*)</name>
    </interface>
   </interfaces-state>
  </filter>
 </get>
</rpc>

The server might reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="3"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-09T21:13:16Z" ncx:etag="31046"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
   <interface>
    <name>eno1</name>
    <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
    <oper-status>up</oper-status>
    <phys-address>88:ae:dd:55:16:11</phys-address>
    <speed>1000000000</speed>
    <statistics>
     <in-octets>19099920850</in-octets>
     <in-unicast-pkts>18510467</in-unicast-pkts>
     <in-multicast-pkts>1176410</in-multicast-pkts>
     <in-discards>2203</in-discards>
     <in-errors>0</in-errors>
     <out-octets>3324564010</out-octets>
     <out-unicast-pkts>10004507</out-unicast-pkts>
     <out-discards>0</out-discards>
     <out-errors>0</out-errors>
    </statistics>
   </interface>
  </interfaces-state>
 </data>
</rpc-reply>

Using XPath Filters

XPath is a powerful standard that can be used many ways with YANG data.

• 'must' and 'when' XPath expressions must have a 'boolean' result

• 'instance-identifier' restricted XPath expression must have a node-set result with at most one entry

• 'filter' XPath expression must have a node-set result

This section focuses on using XPath filters to select node-sets.

Full XPath Support

The XML Path Language (XPath) 1.0 is supported in netconfd-pro and YumaPro client programs (e.g. xget command) for selecting a subset of YANG data nodes from the server.

• The NETCONF XPath Capability (:xpath) is fully supported.

• The /filters subtree from ietf-subscribed-notifications.yang is fully supported for storing reusable subtree and XPath filters in the server.

The following operations support an XPath filter parameter for selecting node-sets.

Operation	Parameter	Notes
<create-subscription>	filter type='xpath'	RFC 5277 Section 3.6
<establish-subscription>	datastore-xpath-filter	Datastore subscription
<establish-subscription>	stream-xpath-filter	Event Stream subscription
<get>	filter type='xpath'	RFC 6241 Section 7.7
<get-bulk>	list-test	List node docroot
<get-config>	filter type='xpath'	RFC 6241 Section 7.1
<get-data>	xpath-filter	RFC 8526 Section 3.1.1

XPath Usage

The XPath 2.0 rule for default XML namespace behavior is used, not XPath 1.0 rules, as specified by the YANG language. This means that any module with a node with the same local-name, in the same position in the schema tree, will match a missing XML prefix. This allows much simpler specification of XPath filters, but it may match more nodes than intended. Remember that any nodes added via an external YANG augment statement may have the same local-name, even though they are bound to a different XML namespace.

If the XPath expression does not return a node-set result, then the empty <data/> element will be returned in the <rpc-reply>.

If no nodes in the node-set result exist in the specified target database, then an empty <data/> element will be returned in the <rpc-reply>.

If a node in the result node-set matches a node in the target database, then it is included in the <rpc-reply>,

If a node selected for retrieval are contained within a YANG list node, then all the key leaf nodes for the specific list entry will be returned in the response.

The powerful '//' operator (equivalent to "descendant-or-self::node()") can be used to construct really simple XPath expressions.

The following example shows how a simple filter like '//name' will return nodes from all over the database, yet they can all be fully identified because the path from root is part of the response data.

Using the descendant-or-self Axis

XPath has a powerful feature that allows an entire subtree to be scanned for objects with the same name. The double-slash operator // is defined to represent this operator.

• The string // is short for /descendant-or-self::node()/.

Example: Retrieve all the data with a node called name

Example yangcli-pro request:

xget //name

Example Client Request:

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="43">
  <nc:get>
    <nc:filter type="xpath" select="//name"/>
  </nc:get>
</nc:rpc>

Example Reply:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
   message-id="43">
   <nc:data>
      <nacm:nacm xmlns:nacm="http://netconfcentral.org/ns/nacm">
         <nacm:rules>
            <nacm:data-rule>
               <nacm:name>nacm-tree</nacm:name>
            </nacm:data-rule>
            <nacm:data-rule>
               <nacm:name>itf-1</nacm:name>
            </nacm:data-rule>
         </nacm:rules>
      </nacm:nacm>
      <t:xpath.1 xmlns:t="http://netconfcentral.org/ns/test">
         <t:name>barney</t:name>
      </t:xpath.1>
      <if:interfaces xmlns:if="http://netconfcentral.org/ns/interfaces">
         <if:interface>
            <if:name>lo</if:name>
         </if:interface>
         <if:interface>
            <if:name>eth0</if:name>
         </if:interface>
         <if:interface>
            <if:name>virbr0</if:name>
         </if:interface>
         <if:interface>
            <if:name>pan0</if:name>
         </if:interface>
      </if:interfaces>
      <ns:netconf-state              xmlns:ns="urn:ietf:params:xml:ns:netconf:monitoring">
         <ns:datastores>
            <ns:datastore>
               <ns:name>
                  <ns:candidate/>
               </ns:name>
            </ns:datastore>
            <ns:datastore>
               <ns:name>
                  <ns:running/>
               </ns:name>
            </ns:datastore>
            <ns:datastore>
               <ns:name>
                  <ns:startup/>
               </ns:name>
            </ns:datastore>
         </ns:datastores>
      </ns:netconf-state>
      <manageEvent:netconf   xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification">
         <manageEvent:streams>
            <manageEvent:stream>
               <manageEvent:name>NETCONF</manageEvent:name>
            </manageEvent:stream>
         </manageEvent:streams>
      </manageEvent:netconf>
   </nc:data>
</nc:rpc-reply>

In order to refine the previous filter to select nodes from just one module, the use the XML prefix in the node identifier. The example below selects only the <name> nodes from the interfaces module.

Example yangcli-pro command:

xget //if:name

Example Client Request:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="44">
  <nc:get>
    <nc:filter type="xpath" xmlns:if="http://netconfcentral.org/ns/interfaces"
      select="//if:name"/>
  </nc:get>
</nc:rpc>

Example Reply:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
   message-id="44">
   <nc:data>
      <if:interfaces xmlns:if="http://netconfcentral.org/ns/interfaces">
         <if:interface>
            <if:name>lo</if:name>
         </if:interface>
         <if:interface>
            <if:name>eth0</if:name>
         </if:interface>
         <if:interface>
            <if:name>virbr0</if:name>
         </if:interface>
         <if:interface>
            <if:name>pan0</if:name>
         </if:interface>
      </if:interfaces>
   </nc:data>
</nc:rpc-reply>

Using XPath Predicate Expressions

Any valid node-set expression can be used in an XPath query.

• The XPath result for the entire expression is a node-set

• Predicates are used to remove instances from the node-set that do not match

• Each predicate is a boolean expression. If 'true' the the test node remains in the node-set. If 'false' that node is removed from the node-set.

• The node just preceding the first predicate is the context node for all the predicates.

  /foo/bar[name='test1'][type='type1']/leaf1
  

• In this example the node bar is the context node for the 2 predicates that follow.

• In this example, all instances of bar are checked by the server. This is called the starting node-set.

  • If an entry has a leaf called name with a value of test1 then it remains in the node-set.

  • The node-set that remains is checked again. If an entry has a leaf named type that has a value type1 then it remains in the node-set

• For all nodes remaining in the node-set, if the bar entry has a child named leaf1 then this becomes the node in the node-set to replace its parent. Otherwise the parent is removed from the result node-set.

• The server returns the resulting leaf1 nodes and all its ancestor list, list key leafs, and containers.

Example: Retrieve only the interfaces with a 'speed' greater than zero

Example yangcli-pro request:

xget /interfaces-state/interface[speed>0]

Example Client Request:

• Note that the '>' sign must be sent as a character entity because it is a special character in XML.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="xpath" select="/interfaces-state/interface[speed&gt;0]"/>
 </get>
</rpc>
</rpc>

Example Server Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="5"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-12T21:22:59Z" ncx:etag="158"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
   <interface>
    <name>eno1</name>
    <type
     xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
    <oper-status>up</oper-status>
    <phys-address>3c:7c:3f:1d:83:aa</phys-address>
    <speed>1000000000</speed>
    <statistics>
     <in-octets>13648545351</in-octets>
     <in-unicast-pkts>9525114</in-unicast-pkts>
     <in-multicast-pkts>11786695</in-multicast-pkts>
     <in-discards>0</in-discards>
     <in-errors>0</in-errors>
     <out-octets>2887923796</out-octets>
     <out-unicast-pkts>3720106</out-unicast-pkts>
     <out-discards>0</out-discards>
     <out-errors>0</out-errors>
    </statistics>
   </interface>
  </interfaces-state>
 </data>
</rpc-reply>

Using XPath Functions

The XPath 1.0 function library is fully supported. There are restrictions for certain functions.

• Refer to RFC 8407 Section 4.6.2 for details on YANG XPath usage.

• Function calls can only appear in predicates or arguments to other function calls.

Example: Retrieve some inbound interface counters

• Request only the statistics where the name starts with the string in

Example yangcli-pro request:

xget /interfaces-state/interface/statistics/*[starts-with(local-name(.),'in')]

Example Client Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="4"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="xpath"
   select="/interfaces-state/interface/statistics/*[starts-with(local-name(.),'in')]"/>
 </get>
</rpc>

Example Server Reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-12T21:22:59Z" ncx:etag="158"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
   <interface>
    <name>lo</name>
    <statistics>
     <in-octets>13231227</in-octets>
     <in-unicast-pkts>105087</in-unicast-pkts>
     <in-multicast-pkts>0</in-multicast-pkts>
     <in-discards>0</in-discards>
     <in-errors>0</in-errors>
    </statistics>
   </interface>
   <interface>
    <name>eno1</name>
    <statistics>
     <in-octets>13632758426</in-octets>
     <in-unicast-pkts>9507673</in-unicast-pkts>
     <in-multicast-pkts>11735283</in-multicast-pkts>
     <in-discards>0</in-discards>
     <in-errors>0</in-errors>
    </statistics>
   </interface>
   <interface>
    <name>virbr0</name>
    <statistics>
     <in-octets>0</in-octets>
     <in-unicast-pkts>0</in-unicast-pkts>
     <in-multicast-pkts>0</in-multicast-pkts>
     <in-discards>0</in-discards>
     <in-errors>0</in-errors>
    </statistics>
   </interface>
  </interfaces-state>
 </data>
</rpc-reply>

Using Time Filters

The module yuma-time-filter.yang defines a timestamp mechanism to help reduce polling overhead for a client.

• Timestamps are specified in 'date-and-time' format (from the ietf-yang-types.yang module).

• The timestamp parameter 'if-modified-since' is added to the <get> and <get-config> operations.

• The timestamp monitoring node 'last-modified' is added to the /netconf-state/datastores/datastore list.

• The XML attribute 'last-modified' is added to the <rpc-reply> element for replies to <get> and <get-config> operations.

• The per-datastore last modified timestamp is for the entire datastore contents. If the 'if-modified-since' parameter is present in the <get> or <get-config> request, then the server will check the corresponding 'last-modified' timestamp.

  • If the 'last-modified' timestamp is more recent than the 'if-modified-since' value, then the <get> or <get-config> operation is processed as normal.

  • If the 'last-modified' timestamp is not more recent than the 'if-modified-since' value, then the <get> or <get-config> operation is not processed. Instead, an empty <data> element is returned. The 'last-modified' XML attribute in the <rpc-reply> will indicate the last modification timestamp for the datastore.

Example Request:

<?xml version="1.0" encoding="UTF-8"?>
 <get-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <source>
      <running/>
    </source>
    <if-modified-since
    xmlns="http://netconfcentral.org/ns/yuma-time-filter">
      2011-08-21T21:51:46Z</if-modified-since>
  </get-config>
</rpc>

An empty reply is sent because datastore not modified since specified time:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4"
   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
   last-modified="2011-08-21T17:51:46Z"
   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data></data>
</rpc-reply>

Retrieving Default Values

Normally, the server does not return default values in retrieval operations. The Default Node Handling section explains how the server treats default nodes.

Note

• A YANG default is the value returned if no data node actually exists.

• The definition of 'data node exists' varies and depends on the --default-style CLI parameter setting.

The server can be instructed to return default nodes using the with-defaults' parameter defined in :rfc:`6243.

With-defaults Examples

The following examples show the differences between the different default modes, using the default nodes from the /nacm subtree.

Plain Request

• Server returns only non-default data nodes

The yangcli-pro command:

sget-config source=running /nacm

The client request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="4"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
  <source>
   <running/>
  </source>
 </get-config>
</rpc>

The server response:

• no data is returned since no NACM config has been set

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-11T21:14:00Z" ncx:etag="156"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data></data>
</rpc-reply>

With-defaults=trim

• Server returns only non-default data nodes.

• A data node is considered to be the default, even if the client set the node to its default vale.

• This mode returns the same data as a 'plain' request.

The yangcli-pro command:

sget-config source=running /nacm with-defaults=trim

The client request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
  <source>
   <running/>
  </source>
  <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">trim</with-defaults>
 </get-config>
</rpc>

The server response:

• no data is returned since no NACM config has been set

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="5"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-11T21:14:00Z" ncx:etag="156"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data></data>
</rpc-reply>

With-defaults=explicit

• Server returns only non-default data nodes.

• A data node is considered to be the default only if no client has set the node.

• A data node is returned even if it has a client-set value the same as the YANG default value.

• This mode normally returns the same data as a 'plain' request. For this example, the leaf /nacm/write-default is set to the YANG default value deny. Now this leaf and the parent container will exist as data nodes.

The yangcli-pro command:

sget-config source=running /nacm with-defaults=explicit

The client request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="12"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
  <source>
   <running/>
  </source>
  <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">explicit</with-defaults>
 </get-config>
</rpc>

The server response:

• the /nacm/write-default leaf is returned.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="12"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-11T21:28:23Z" ncx:etag="158"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
   <write-default>deny</write-default>
  </nacm>
 </data>
</rpc-reply>

With-defaults=report-all

• Server returns all real data nodes and default data nodes.

The yangcli-pro command:

sget-config source=running /nacm with-defaults=report-all

The client request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="13"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
  <source>
   <running/>
  </source>
  <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all</with-defaults>
 </get-config>
</rpc>

The server response:

• All default leafs within the /nacm container are returned.

• The default NP-container /nacm/groups is also returned

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="13"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-11T21:28:23Z" ncx:etag="158"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
   <enable-nacm>true</enable-nacm>
   <read-default>permit</read-default>
   <write-default>deny</write-default>
   <exec-default>permit</exec-default>
   <enable-external-groups>true</enable-external-groups>
   <groups/>
  </nacm>
 </data>
</rpc-reply>

With-defaults=report-all-tagged

• Server returns all real data nodes and default data nodes.

• An XML attribute is also returned in each node that the server considers to be a default node.

The yangcli-pro command:

sget-config source=running /nacm with-defaults=report-all-tagged

The client request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="14"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get-config>
  <filter type="subtree">
   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/>
  </filter>
  <source>
   <running/>
  </source>
  <with-defaults
    xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all-tagged</with-defaults>
 </get-config>
</rpc>

The server response:

• All default leafs within the /nacm container are returned.

• The default NP-container /nacm/groups is also returned

• All default nodes are tagged with the wda:default="true" attribute

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="16"
 xmlns:wda="urn:ietf:params:xml:ns:netconf:default:1.0"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2025-11-11T21:28:23Z" ncx:etag="158"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
   <enable-nacm wda:default="true">true</enable-nacm>
   <read-default wda:default="true">permit</read-default>
   <write-default wda:default="true">deny</write-default>
   <exec-default wda:default="true">permit</exec-default>
   <enable-external-groups wda:default="true">true</enable-external-groups>
   <groups/>
  </nacm>
 </data>
</rpc-reply>