The <unlock> operation releases a configuration lock previously obtained with the <lock> operation. A client cannot unlock a configuration database that it did not lock.
If the <unlock> operation is successful, the server sends an <rpc-reply> element containing an <ok> element. Otherwise, the server sends an <rpc-reply> element containing an <rpc-error> element.
Unlock the <running/> configuration database:
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
If the NMDA data set is supported, the data set format in the target configuration database is different, as shown in the following:
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<target>
<datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">ds:running</datastore>
</target>
</unlock>
</rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>