de active only when required. This is made possible using the <candidate> capability, which provides a temporary data store. A <commit> operation makes the candidate store permanent by copying the <candidate> to the <running> data store. The <candidate> data store needs to be locked while the store before modified, this is because <candidate> is not private by default. If the client that locked the candidate datastore for changing the configuration finally decides not to commit the change and then <discard-changes> can be used to ensure that the running configuration is not altered. For test-based scenarios, where the operator wants to change the configuration and test if it is working properly and in the case of issues wants to revert back to the previous configuration, then the confirmed- commit capability in NETCONF can be used. This capability extends the usual <commit> operation. A deep dive into NETCONF reveals many features that will make it the configuration management protocol of choice offering capabilities that were not available previously. Before we close the overview on SOAP let us also look into some of the trans- port mappings offered by NETCONF. Some of the transport mappings are: SSH: A secure transport binding is offered to NETCONF with SSH. Functions like server authentication and confidentiality of the content can be provided with this transport mapping. The client-side user can also be authenticated to the server. SSH also offers the capability of multiplexing the encrypted tunnel or the transport layer into several logical channels. SSH mapping is usually a mandatory feature in most NETCONF implementations. XML-Based Protocols BEEP: The feature of connection-oriented asynchronous interactions can be achieved with BEEP. It supports multiple logical channels similar to SSH, with the capability to both frame as well as fragment. BEEP is an optional transport with NETCONF. SOAP with HTTP[s]: This combination of SOAP with HTPP as already discussed is one of the most popular transport mappings in