s, but it needs to map that goal into configurations on a multitude of network elements. This gets more difficult when the networks are multi-vendor, and each vendor has its own manage- ment interface for configuration, monitoring, and control. The same issue arises with provisioning a path for a timing signal, which to the network is just an- other service. In theory, the operator would like an end-to-end configuration and visibility across all PTP network elements-from the GM through BCs to the remote application. To allow the network to be operated well and with high efficiency, there must also be a robust set of PTP performance metrics and monitoring tools. IEEE 1588-2008 specifies a management node (a device that configures and monitors clocks) for configuration and performance management of PTP clocks. The management node can read and write parameters in the other PTP nodes via PTP management messages. The management node it- self does not take part in the synchronization or BMCA and is only used for the management of PTP clocks. Refer to section "PTP Clocks" in "Chapter 7. Precision Time Protocol", for some more details on management nodes. Note, however, that management nodes and the PTP management messages are not supported in any of the telecom profiles. The goal is to provide a mechanism where one or more nodes can perform actions such as GET and SET on a range of parameters (known in 1588-2008 as datasets) on other PTP nodes via manage- ment messages. The target PTP node will reply to each GET or SET with either an OK or not OK status to indicate the result of the operation. Refer to Chapter 15 of 1588-2008 for details on man- agement nodes and management messages. 1588-2008 did not always specify datasets for optional features. IEEE 1588-2019 improves on the optional features from 1588-2008 and adds several new ones (for details, see clauses 16 and 17 of 1588-2019). Additionally, 1588-2019 specifies datasets for all these optional features as well as the standard features. If a feature can be managed