How to avoid the keys ordering constraints for multiple keys list

NETCONF
1

Now I am working on a list nodes with two keys: key “node-type node-id”, then use xml file to create a new entry of nodes, in which the leafs appear in different order: node-id precedes by node-type. But the result fails with the following error message:
< error-message xml:lang=“en”>expected tag: ‘node-type’, got tag: 'node-id’node-type< /bad-element>

It works when I change the order of leafs according to the order in the key statement. In a reality scenario, I have a yang with the key of five leafs and it’s inconvenient to always keep order in mind. So is it possible to let confd ignore keys ordering in xml in such case?

The Yang File:
container ranges-multi {

list nodes {
  config true;

  key "node-type node-id";

  leaf node-type {
    type enumeration {
      enum ethernet;
      enum wireless;
      enum optical;
      enum coaxial;
    }
  }   

  leaf node-id {
    type uint32;
  }   

  leaf payload {
    type string;
    description "Dummy payload leaf to show callback invocations";
  }   
}

}

The XML file:

< edit-config>
    < target>
      < running/>
    < /target>
    < config>
      < ranges-multi xmlns="https://tail-f.com/example/ranges-multi">
        < nodes>
          < node-id>4< /node-id>
          < node-type>wireless< /node-type>
          < payload>test< /payload>
        < /nodes>
      < /ranges-multi>
    < /config>
  < / edit-config>

The Error Message:

netconf> rpc ./xml/test_mkey1.xml
<? xml version='1.0' encoding='UTF-8'?>
< rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
< error-type>application</error-type>
< error-tag>missing-element</error-tag>
< error-severity>error</error-severity>
< error-path xmlns:ranges-multi="https://tail-f.com/example/ranges-multi" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    /nc:rpc/nc:edit-config/nc:config/ranges-multi:ranges-multi/ranges-multi:nodes
  </error-path><error-message xml:lang="en">expected tag: 'node-type', got tag: 'node-id'</error-message>< error-info><bad-element>node-type</bad-element>
< /error-info>
< /rpc-error>
2

No, ConfD obeys these two RFC requirements and it cannot be changed, I’m afraid. If it really is so tedious to keep the key order in mind, perhaps it might not be too difficult to write a script that would fix the edit-config XML for you (for a single list; doing that generically would probably be a bit more complex).

3

Thanks mvf for clarification.
The order is not a trouble for developers and I will explain this to whom complained about this.
BTW, I just check the RFC 7950, looks like the doc. doesn’t mention that the multiple-key requires ordering on them except uniqueness.

Snippet about key from <RFC 7950>:

The combined values of all the leafs specified in the key are used to
uniquely identify a list entry. All key leafs MUST be given values
when a list entry is created. Thus, any default values in the key
leafs or their types are ignored.

4

These are the RFC parts that I had in mind:

The list’s key nodes are encoded as subelements to the list’s identifier element, in the same order as they are defined within the “key” statement.

and

If all keys are not specified for a list entry, a “missing-element” error is returned.

So when ConfD does not see the expected key leaf node, it cannot but assume that it is not specified and responds with “missing-element” error response.

5

I understand now, Thanks mvf.