Expected behaviour for sending the same edit-config if there is a deny rule

NETCONF
1

What is the expected behaviour of confd if there is a NACM rule for deny update action, and the same edit-config is sent twice? Currently confd rejects the second edit-config.

Example:

container test-container {
    list test-list {
        key parameter-1;
        leaf parameter-1 {
            type string;
        }
        leaf parameter-2 {
            type string;
        }
    }
}

      <rule>
        <name>update-deny</name>
        <module-name>test-module</module-name>
        <path>/test-container/test-list/*</path>
        <access-operations>update delete</access-operations>
        <action>deny</action>
      </rule>

<rpc message-id="rpc-1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>merge</default-operation>
    <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <test-container xmlns="http://test.com">
            <test-list>
                <parameter-1>key-1</parameter-1>
                <parameter-2>parameter-2</parameter-2>
            </test-list>
        </test-container>
    </config>
  </edit-config>
</rpc>

Based on the netconf-acm rfc, my assumption is that the same configration can be sent multiple times, as there is no configuration change.
Snippet from nacm rfc https://tools.ietf.org/html/rfc6536#section-3.2.3:

A “merge” or “replace” operation may include data nodes
that do not alter portions of the existing datastore. For example, a
container or list node may be present for naming purposes but does
not actually alter the corresponding datastore node. These unaltered
data nodes are ignored by the server and do not require any access
rights by the client.

2

ConfD seems to interpret that part of the RFC differently than your assumption. I.e. leaf data nodes that are edited with the same value but have a deny rule on updating them will be denied.
So in your example above, attempting to update the leaf parameter-2 will cause your NACM “update-deny” rule to trigger and the transaction will be rejected.