Hi,
The RFC doesn’t cover the internal workings at all of an application, here consisting of ConfD’s Core/CDB and your application, and the APIs that the internal application, here the ConfD CDB API.
If we can understand better why you need a southbound API that is NETCONF compliant it would be easier to help. Are you developing some sort of manager?
Regarding default value, that is expected behaviour. If we construct a yang model out of your “container when” example adding a couple of leafs to it:
leaf type {
type string;
}
container A-type {
when "../type = 'A'";
leaf testA1 {
type string;
}
leaf testA2 {
type string;
default "testA2-defval";
}
}
container B-type {
when "../type = 'B'";
leaf testB1 {
type string;
}
leaf testB2 {
type string;
default "testG2-defval";
}
}
Then we add a subscriber that use the cdb_get_modifications_iter() to print the modifications In MOP_VALUE_SET the get_modifications_iter() function returns changes in reverse
Quick demo:
After playing around with the leafs we for example can get something like this in our libconfd trace + subscriber application printouts:
*** Config updated
TRACE CDB_SUB_ITERATE 6
/root/NodeB/RFHead{1} modified
TRACE CDB_GET_MODIFICATIONS --> CONFD_OK
get_modifications_iter:
type B
A-type begin
testA1 deleted
testA2 testA2-defval
A-type end
TRACE CDB_SYNC_SUB CDB_DONE_PRIORITY --> CONFD_OK
TRACE CDB_SUBSCRIPTION_EVENT --> 6
In the above trace we can see how we changed the “type” leaf to “B” from “A”. The “when” statement in the container “A-type” got triggered so we first got a “deleted” on leaf “testA1” since it did not have a default value, then we see that leaf “testA2” also was deleted but since it had a default value it got its default value set.