<unlock>

Because there is a single lock per datastore, regardless of the scope of that lock, the following restrictions apply to the <unlock> operation.

• The <running> datastore lock is unlocked by using the <unlock> command only on the <running> datastore. An error results and the lock stays if a different datastore is specified with the <unlock> operation.

• The <candidate> datastore lock is unlocked by using the <unlock> command only on the <candidate> datastore. An error results and the lock stays if a different datastore is specified with the <unlock> operation.

Performing an <unlock> operation on the <candidate> datastore discards all pending (not committed) <candidate> datastore changes.

To unlock a BOF datastore, the ‟bof” <configuration-region> must be specified within the <unlock> <target>. For example:

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

To unlock an LI datastore, the ‟li” <configuration-region> must be specified within the <unlock> <target>. For example:

<unlock>
  <target>
    <configuration-region>li</configuration-region>
    <candidate/>
  </target>
</unlock>

Alternatively, the <target> can be specified in the format of ‟configuration-region”-”datastore”. For example:

<unlock>
  <target>
    <li-candidate/>
  </target>
</unlock>

When both the <configuration-region> and the ‟configuration-region”-”datastore” format are used, SR OS applies the last tag used in the XML request. For example:

<unlock> 
  <target> 
    <configuration-region>configure</configuration-region> 
    <li-candidate/> 
  </target> 
</unlock> 

In the preceding example, the <unlock> is used to unlock the ‟li” <candidate> datastore.

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