Confirmed Commit

This capability indicates that the device is capable to confirm configurations. In other words, the <commit> message delivered in this instance does not directly commit the configuration and depends on the next <commit> message to trigger the configuration commitment.

confirmed-commit:1.0

The <commit> operation can carry the <confirmed> and <confirm-timeout> parameters.

<confirmed>: submits the configuration data in the <candidate/> configuration database and converts it into the running configuration data on a device (configuration data in the <running/> configuration database).
<confirm-timeout>: specifies a timeout period for confirming the <commit> operation, in seconds. The default value is 600s. After the <commit> operation is performed, if the confirmation operation is not performed within the timeout period, the configuration in the <running/> configuration database is rolled back to the status before the <commit> operation is performed and the modified data in the <candidate/> configuration database is abandoned.

This capability is valid only when the candidate configuration capability is supported. It is mainly used in service trial running and verification scenarios.

Submit the current configuration and set the timeout period for confirming the <commit> operation to 120s:

RPC request:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <commit>
    <confirmed/>
    <confirm-timeout>120</confirm-timeout>
  </commit>
</rpc>

RPC reply:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

confirmed-commit:1.1

The <commit> operation can carry the <persist> and <persist-id> parameters.

If a <confirmed-commit> message carries the <persist> parameter, the trial run operation created using <confirmed-commit> is still effective after the associated session is terminated. The device allows a message to carry the <persist-id> parameter to update an existing trial-run operation.

Carry the <persist> parameter in a message for the <commit> operation:

RPC request:
```
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
  <commit>
    <confirmed/>
    <persist>123</persist>
  </commit>
</rpc>
```
RPC reply:
```
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
  <ok/>
</rpc-reply>
```
Carry the <persist-id> parameter in a message for the <commit> operation:

RPC request:
```
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <commit>
    <confirmed/>
    <persist-id>123</persist-id>
  </commit>
</rpc>
```
RPC reply:
```
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <ok/>
</rpc-reply>
```
The <cancel-commit> operation is supported. The <persist-id> parameter can be carried to eliminate or terminate the trial operation that is being executed, which is created using <confirmed-commit> with the <persist> parameter.

RPC request:
```
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <cancel-commit>
    <persist-id>IQ,d4668</persist-id>
  </cancel-commit>
</rpc>
```
RPC reply:
```
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <ok/>
</rpc-reply>
```