olly unsuited for management of most WAN-based timing solutions, including those for mobile. On the other hand, there are proprietary, vendor-specific MIBs that are available for management of PTP clocks. CISCO-PTP-MIB is one such example, which captures many of the elements of PTP configuration and performance monitoring. Although widely adopted, SNMP has some deficiencies that make it an unsuitable tool for configur- ation management. One of the main reasons is that SNMP handles a mix of configuration and non- configuration data. This mix makes it difficult to implement even basic network automation func- tions such as configuration backup and restore because it is not clear what elements of a MIB are for configuration. An additional problem is that, architecturally, SNMP is a device view rather than a network and ser- vices view. And operators no longer wish to manage devices but want to configure and manage net- works and/or services. As an example, if an interface were to start seeing errors, SNMP would alert the network management system (NMS) that interface GE 10/1 on Router "Fred" is showing a very high error count. But SNMP does not tell the operator that this link, servicing ACME Incorporated, has an extremely high service level, and the operator is contractually committed to inform the cus- tomer of its degraded state within a defined time limit. Such gaps, along with several shortcomings of other management protocols (such as CORBA, SOAP, and others) gave rise to the development of NETCONF and YANG. 12.4.1 NETCONF and YANG In 2006, the IETF published the Network Configuration (NETCONF) specification in RFC 4741 (now updated by RFC 6241) to provide mechanisms to install, manipulate, and delete the configura- tion of network devices. NETCONF uses an eXtensible Markup Language (XML)-based data en- coding for the configuration data as well as the protocol messages. NETCONF has been adopted by major network equipment providers and has already gained strong industry support. Also, vendors of other (non-netw