<commit>

The following are the characteristics of the <commit> command.

• It represents the equivalent of the CLI command commit.

• When a <commit> operation fails and more than one error exists, SR OS returns multiple errors.

• When SR OS is not able to commit all the changes in the <candidate> datastore, SR OS keeps the <running> datastore unchanged.

• When a NETCONF session is disconnected (using the CLI command, Ctrl-c, or <kill-session>) in the middle of a <commit> operation, SR OS keeps the <running> datastore unchanged.

• The persistency of changes made using a <commit> operation is operator-controlled. A copy of the <running> datastore to the <startup> datastore can be automatically performed after each successful <commit> operation. This behavior can be enabled or disabled through a CLI command.

• If changes exist in the <candidate> datastore (before they are committed to the <running> datastore), this impacts:

  • a CLI user trying to make immediate changes, because SR OS may block some CLI immediate configurations

  • an SNMP set request, because SR OS may block the request and return an error

To commit BOF configurations, the ‟bof” <configuration-region> must be specified within the <commit> RPC. For example:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit> 
      <configuration-region>bof</configuration-region>
</commit>
</rpc>
]]>]]>

To commit LI configurations, the ‟li” <configuration-region> must be specified within the <commit> RPC. For example:

<commit>
  <configuration-region>li</configuration-region>
</commit>

The <commit> RPC can only be used with LI configuration changes if all of the following conditions are true.

• The NETCONF user is a LI user.

• The NETCONF session has an exclusive lock on the LI configuration region and <candidate> datastore.

• The specified <configuration-region> is ‟li”.

• The YANG modules used are the Nokia SR OS YANG modules.

If any of the preceding conditions are false, SR OS returns an error.

The :confirmed-commit capability cannot be used with LI configuration changes.

The :confirmed-commit capability is advertised in the SR OS NETCONF server <hello> as:

<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>

The :confirmed-commit capability includes the following characteristics.

• The capability is not advertised if the operator disables the <candidate> datastore capability using the available SR OS CLI command.

• Table: Parameters for a <commit> operation lists the supported parameters for a <commit> operation.

  Table: Parameters for a <commit> operation

  Parameter	Description
  <comment>	Optional. Specifies a comment in the commit history.
  <confirmed>	Indicates a confirmed <commit> operation.
  <confirm-timeout>	Specifies the timeout period for confirmed commit (in seconds). If unspecified, the confirmed commit timeout defaults to 600 seconds (10 minutes).
  <persist>	Configures the confirmed commit changes to survive a session termination. It sets a token on the ongoing confirmed commit. If <persist> is not in the confirmed commit operation, any follow-up commit and the confirming commit must be issued on the same session that issued the confirmed commit. If <persist> is in the confirmed commit operation, a follow-up commit and the confirming commit can be on any session. However, they must include a <persist-id> element with a value equal to the value of the <persist> element in the confirmed commit. The <persist> element cannot be changed through a follow-up confirmed commit.
  <persist-id>	Issues a follow-up confirmed commit or the confirming commit from any session, using the same token from the <persist> element of the confirmed commit. The <persist-id> element cannot be changed through a follow-up confirmed commit.

• If <persist> is specified in the confirmed commit, the configuration changes are rolled back only if the timeout expires before a confirming commit is received. The confirming commit must include a <persist-id> tag with a value equal to the value of the <persist> tag contained in the confirmed commit.

• If the NETCONF session that initiated the confirmed commit is closed while waiting for the confirming commit (for example, disconnected), SR OS restores the configuration to its state before the confirmed commit was issued. This is valid only if <persist> was not defined in the confirmed commit.If a follow-up confirmed commit is issued before the timer expires, the timer is reset to the new value.

• The confirming commit and the follow-up confirmed commit cannot introduce additional changes to the configuration. The <cancel-commit> operation is supported. It can cancel an ongoing confirmed commit (that is, cancel the timer and rollback the changes introduced with the confirmed commit).

• Without the <persist> parameter, the <cancel-commit> operation must be issued in the same session that issued the confirmed commit.

• If the configuration changes involve changing the configuration-mode to classic, a confirmed commit should not be used to commit those configuration changes, as SR OS would switch to classic mode before sending the second commit.

See Table: Protocol operations and level of support in Nokia SR OS NETCONF servers for more information.