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.