ts." To claim that the equipment does not meet the claimed class of performance is meaningless if the input signals were somehow im- paired or degraded during the test. But the fact that the tests are standardized is a very good thing because it allows engineers to make comparisons between vendors and equipment. This is an important feature of being able to select the right network equipment for the job (see the preceding section on writing an RFP). Most of what is called "timing testing," both in this book and in the timing community, does not generally include functionality testing. Yes, it is a given that the network equipment should be able to function correctly according to the IEEE 1588 specification and the specific profiles. Some oper- ators might like to confirm specific cases that concern them, such as the correct functioning of the leap-second logic, for example. Some years ago, the IEEE did have a program called the IEEE Conformity Assessment Program (ICAP) that validated individual PTP implementations against 1588-2008 and whatever profile claimed to support. Testing companies offered a service whereby they could test an implementation of PTP against the standards, using a very detailed test plan. ICAP turned out not to be commer- cially sustainable for the telecom profiles (only G.8265.1 was completed). The program is still act- ive for the power profile, and you can even download a conformance test suite for it. But the testing discussed here involves testing the timing signals and clock performance rather than specific behavior or even protocol compliance. Yes, if an interoperability issue arises, then packet traces and field validation are important tools to resolve those problems. But the topic here is mostly about performance, and therefore the testing requires dedicated equipment that can generate and measure time and frequency signals. There are two fundamentally different approaches to testing: Standalone testing of a single network element against the performance recommendations, what the I