rored from a PTP master port or wire-tapped by the probes. The passive probe then uses its own slave-based timestamps (t2 and t3) to carry out the analysis. When the passive probes are installed, the fiber distance from network element (or from the wire-tapping point) is measured, which allows the probes to calibrate their measurements. Note that these probes can only use t1 and t4 timestamps from the PTP master for measure- ments and should never use the value of t3 in the Delay_Req message from the slave. The t2 timestamp never gets transmitted (from slave to master), SO it cannot be captured from any PTP messages. Meanwhile, the t3 timestamp, which is returned to the PTP master from the PTP slave (in the Delay_Req message), does not need to be accurate; it is only an approximation. In fact, a slave can even set the timestamp in the Delay_Req to be zero. So, you need to make sure that the passive probes do not rely on t3 timestamps for any measurement because any results will al- most certainly be wrong. Because these probes are placed in live production networks, they become part of the network itself. And just like any other network devices, the operator needs to be able to manage these devices re- motely and automatically. Like many other devices in the network, these devices come with their own individual management characteristics, which may present a challenge to integrate with the ex- listing management infrastructure. Probes are normally sold by different vendors than the vendors who sell network devices, SO the probe management approach might not align cleanly with that of network devices. For example, a network device might support streaming telemetry and automation, whereas these probes might not support streaming telemetry at all. Or even if they do support it, the format of the telemetry data might be different or proprietary, which becomes an additional burden on operations staff. On the other hand, the specialized management of these devices could be more relevant for timing staff than a general-