 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 the Web service development. There are many Web service standards associated with SOAP with HTTP that could be reused when NETCONF is intended to be used with SOAP over HTTP. This leads to quicker integration with components that are developed to align with Web standards. However the transport map- ping of NETCONF with SOAP does not map NETCONF operations to SOAP operations. So NETCONF should not be considered as a replacement for SOAP. 18.8 Conclusion This chapter gives the reader an understanding of XML-based protocols. Rather than jumping into detai