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>
</rpc>
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>
I expected ODL to follow strict order of key nodes during XML encoding and as per RFC 6020 statement. This is not happening and device is rejecting the request purely based on out of order issue. Is this a bug in ODL yangtools XML encoding issue or really the device should handle the request in any order ?
It looks like this question is being answered here