About candidate and running space

[okmine123]

Dear Maintainer,

I don't know it is bug or just it is the spec should like that.
When the netopeer-server start, does it should make the candidate and running space all the nodes same in the initial time?

After netopeer-server start run first time. I found the 'interfaces' yang model that the get-config candidate is vacant. But running space is listed all the interfaces.

If my first command is 'commit', the callbacks would think it is commiting a vacant node and with 'op' the 'REM' operation. Then all the nodes in the 'running' space would removed.
I asking this question to make me understanding the candidate space clearly. 'commit' operation try to make 'candidate' space totally same with with 'running' space.
If so, I need to send command 'discard-changes' first when the first time connect the server to make the 'candidate' space and 'running' space totally same, then edit-config any of the interfaces in candidate. then 'commit' in the end. If I mix operate the edit-config candidate and edit-config running. There is problem. I have to add 'discard-changes' follow after the 'edit-config running' to make 'candidate' adn 'running' all the same. Then start to 'edit-config candidate'.
An example steps to explain what do I say:
discard-changes //copy 'running' to 'candidate'
edit-config candidate
commit //copy 'candidate' to 'running'
edit-config running
edit-config running
discard-changes //copy 'running' to 'candidate'
edit-config candidate
commit
......

So my question is my understanding is right or not? If yes, so the netopeer-server should has a bug in the initial time not make 'candidate' and 'running' same, is it correct?
Expect reply.

Thanks!

[okmine123]

Sorry, seems it is only happened in my porting to buildroot. Not happened in the centos x86 server. I guess my porting to the buildroot has lead something wrong not to make the 'candidate' and 'running' equal.