Octet

Say this first

Running is the live config. Candidate (the :candidate capability) is a scratch copy: you edit it, check it, then commit copies it to running in one step, or discard-changes throws it away. A confirmed commit applies the change but rolls it back automatically unless a second commit arrives within the timeout (600 seconds by default). Inside edit-config, the operation attribute decides merge, replace, create, delete or remove for each node.

Go deeper

Datastores

Datastore	Capability	Notes
running	always	Live config. Writable directly only with `:writable-running`
candidate	`:candidate`	Edit, `validate`, then `commit` or `discard-changes`
startup	`:startup`	Config loaded at boot, where the platform separates it

edit-config operations

Operation	Behavior
`merge` (default)	Merge the sent data into the target
`replace`	Replace the target node with the sent data
`create`	Create; error `data-exists` if it is already there
`delete`	Delete; error `data-missing` if it is not there
`remove`	Delete if present, no error if absent

default-operation (merge, replace or none) sets the behavior for nodes without an attribute. error-option is stop-on-error (default), continue-on-error or rollback-on-error (needs the :rollback-on-error capability).

Deleting one interface description

Output

<rpc message-id="105" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><candidate/></target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>GigabitEthernet2</name>
          <description nc:operation="remove"/>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

Confirmed commit

<commit><confirmed/><confirm-timeout>120</confirm-timeout></commit> applies the candidate and starts a timer. If your session drops or nobody sends a plain <commit/> before the timer ends, the device reverts. That is the safety net for changes that might cut your own access. Junos users know the same idea as commit confirmed.

Platform notes

IOS-XE needs netconf-yang feature candidate-datastore to offer a candidate. Junos maps NETCONF candidate to its normal candidate configuration.

They will ask next

Why lock the datastore?
lock stops other NETCONF sessions (and on many platforms CLI users) from changing the datastore while you work, so your commit does not include someone else's half-finished edit. Another session that tries to lock it gets lock-denied, and its edits are refused until you release it. Always unlock or close the session.
Merge or replace for a full interface config push?
Replace makes the node match exactly what you sent, which removes anything you left out. That is what you want for intended-state management, and dangerous if your data is incomplete. Merge is safer but leaves stale config behind.

Traps

Thinking delete and remove are the same. delete errors when the node is missing; remove does not.
Editing running directly on a platform that has a candidate, and losing the all-or-nothing behavior.

How did you do?