List keys not returned by <get> with subtree filter

NETCONF
1

Hello,

The Conf-D NETCONF server is not returning list and sub-list keys for a request that contains a subtree filter. Please see the example below. The response does not return the ‘name’ field, which is the key for ‘my-list’.

Is there something I can configure in Conf-D to enable returning list keys for requests?

This is the only form of a NETCONF get that behaves this way and is inconsistent with the other five get variations. All other variations of NETCONF get operations return list keys.

NETCONF Get Operations that return list keys:

  • with subtree filter
  • with subtree filter
  • with xpath filter
  • with xpath filter
  • with xpath filter

NETCONF Get Operations that do not return list keys:

  • with subtree filter

get Request:

<get>
  <filter type="subtree">
    <my-test-module:my-list xmlns:my-test-module="urn:my:yang:my-test-module">
      <my-test-module:my-entry>
        <my-test-module:str-data/>
      </my-test-module:my-entry>
    </my-test-module:my-list>
  </filter>
</get>

get Response:

<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <my-list xmlns="urn:my:yang:my-test-module">
    <my-entry>
      <str-data>some data (1)</str-data>
    </my-entry>
    <my-entry>
      <str-data>some data (2)</str-data>
    </my-entry>
    <my-entry>
      <str-data>some data (3)</str-data>
    </my-entry>
  </my-list>
</data>

get-data Request:

<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
          xmlns:ncds="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <ncds:datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">operational</ncds:datastore>
  <subtree-filter>
    <my-test-module:my-list xmlns:my-test-module="urn:my:yang:my-test-module">
      <my-test-module:my-entry>
        <my-test-module:str-data/>
      </my-test-module:my-entry>
    </my-test-module:my-list>
  </subtree-filter>
</get-data>

get-data Response:

<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <my-list xmlns="urn:my:yang:my-test-module">
    <my-entry>
      <name>TEST00000001</name>
      <str-data>some data (1)</str-data>
    </my-entry>
    <my-entry>
      <name>TEST00000002</name>
      <str-data>some data (2)</str-data>
    </my-entry>
    <my-entry>
      <name>TEST00000003</name>
      <str-data>some data (3)</str-data>
    </my-entry>
  </my-list>
</data>

Module:

module my-test-module {
    yang-version 1.1;
    namespace "urn:my:yang:my-test-module";
    prefix "my-test-module";
    organization "My Test YANG Module.";
    contact
        "My Test YANG Module.
         ";
    description
        "My Test YANG Module.";
    revision 2022-08-26 {
        reference "My Test YANG Module.";
    }

    container my-list {
        description "An example of a list.";
        list my-entry {
            key name;
            description "An example of a list entry.";
            leaf name {
                type string;
                description "Name identifying a list entry.";
            }
            leaf str-data {
                type string;
                description "String data for this list entry.";
            }
            leaf int-data {
                type int32;
                description "Integer data for this list entry.";
            }
        }
    }
}
2

Yes, for a reason unknown to me the ConfD authors decided not to return keys with get/subtree requests, and no, it does not appear you can configure that. Note that the NETCONF RFC does not require a NETCONF server to do that, it MAY return keys; but I agree the inconsistency might be confusing.

3

Yes, I understand the RFC makes this optional. However, what is the use case for this behavior? It seems to make the usage if cumbersome for the applications use. Consider the use case below:

Use Case: with content match filter str-data == “some data (2)”

<get>
  <filter type="subtree">
    <my-test-module:my-list xmlns:my-test-module="urn:my:yang:my-test-module">
      <my-test-module:my-entry>
        <my-test-module:str-data>some data (2)<my-test-module:str-data>
      </my-test-module:my-entry>
    </my-test-module:my-list>
  </filter>
</get>

<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <my-list xmlns="urn:my:yang:my-test-module">
    <my-entry>
      <str-data>some data (2)</str-data>
    </my-entry>
  </my-list>
</data>

The response output is not particularly helpful here since you don’t know which list entry the subtree filter matches. To work-around this issue, we can include a content selection with the subtree filter.

<get>
  <filter type="subtree">
    <my-test-module:my-list xmlns:my-test-module="urn:my:yang:my-test-module">
      <my-test-module:my-entry>
        <my-test-module:name/>
        <my-test-module:str-data>some data (2)<my-test-module:str-data>
      </my-test-module:my-entry>
    </my-test-module:my-list>
  </filter>
</get>

<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <my-list xmlns="urn:my:yang:my-test-module">
    <my-entry>
      <name>TEST00000001</name>
    </my-entry>
    <my-entry>
      <name>TEST00000002</name>
      <str-data>some data (2)</str-data>
    </my-entry>
    <my-entry>
      <name>TEST00000003</name>
    </my-entry>
  </my-list>
</data>

The response output is now cluttered with a bunch of entries that do not match the original intent of the subtree filter - to find list entries that match str-data == “some data (2)”. My example, with three list entries may not be a big deal, but consider larger lists (e.g., 100K entries, etc.).

There’s no way to craft a request and get a clean response for my use case, which seems like it would be more common than the use case for the current behavior of . I could be mistaken here with my understanding of whether or not Conf-D’s behavior is a common/desired behavior.

4

This indeed looks like a bug, I’ll report it. But it appears to be there for quite some time, so most likely this use-case is rarely seen and for any just a bit more complex filtering XPath filters are used. Maybe you can use that too instead? For what you are doing it would be /my-list/my-entry[str-data = "some data (2)"]/name; a lot less code than the subtree filter.

Possibly not every subtree filter can be (easily) reformulated as an equivalent XPath filter, but in most cases it can and in many cases XPath filters are actually more flexible.