[YANGTOOLS-1037] Mis-ordered keyed list children in NETCONF requests Created: 05/Nov/19  Updated: 26/Dec/19  Resolved: 05/Nov/19

Status: Resolved
Project: yangtools
Component/s: data-impl
Affects Version/s: 2.0.20, 3.0.6, 2.1.13, 4.0.2, 2.0.23
Fix Version/s: 4.0.3, 3.0.7, 2.1.14

Type: Bug Priority: High
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by NETCONF-581 restconf to netconf translation doesn... Resolved

 Description   

When yang model has a list with multiple keys, ODL is not maintaining the order of the attributes while sending the request down to the netconf device. It appears from RFC 6020 that order needs to be strictly followed.

"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."

Mainly my vendor device does not complain while creating the list with out of order but during deletion complains with error.

Yang model example:

container acl-config {
    list acl-config-list {
    key "tenant-id access-control-list-id";
    leaf tenant-id {
        type leafref {
        path "/tenant:tenant-config/tenant:tenant-list/tenant:tenant-id";
        }
    description
        "Unique identifier of the Tenant";
    }

    leaf access-control-list-id {
        type custom-id;
        mandatory true;
        description
            "Unique ACL identifier";
    }
}

ODL while encoding during delete operation sends the request as below:

<edit-config>
  <target>
    <running/>
  </target>
  <default-operation>none</default-operation>
  <error-option>rollback-on-error</error-option>
  <config>
    <acl-config xmlns="http://example.com/acl">
      <acl-config-list>
        <access-control-list-id>acl7</access-control-list-id>
        <tenant-id>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</tenant-id>
        <acl-dst-config xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="delete"/>
      </acl-config-list>
    </acl-config>
  </config>
</edit-config>

I expected tenant-id to be encoded first rather than access-control-list-id as per key order defined in yang. Device throwing below error during delete operation:

<rpc-error>
  <error-type>protocol</error-type>
  <error-tag>missing-element</error-tag>
  <error-severity>error</error-severity>
  <error-message xml:lang="en">Invalid position of the key "tenant-id" in a list "acl-config-list".</error-message>
  <error-info>
    <bad-element>/access_control_list:acl-config/acl-config-list[access-control-list-id='acl7']/tenant-id</bad-element>
  </error-info>
</rpc-error>

 



 Comments   
Comment by Robert Varga [ 05/Nov/19 ]

As it turns out, NETCONF is using ImmutableNodes.fromInstanceId() (and hence InstanceIdToCompositeNodes) to create a NormalizedNode document representing the NETCONF filter structure, which is then passed to the XML codec for emission (via an ordered NormalizedNodeWriter).

Both InstanceIdToCompositeNodes and NormalizedNodeWriter rely on NodeIdentifierWithPredicates.entrySet()'s iteration order for child emission, assuming the order matches the key definition order in schema. While this assumption used to be  true (most of the time), it was never documented and in general has not been true for 3+ years now. In order to write the entries in their proper format, the transformation code needs access to the corresponding ListSchemaNode – something InstanceIdToCompositeNodes has, while NormalizedNodeWriter does not.

Generated at Wed Feb 07 20:55:00 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.