controls, and overall system design are all very critical. Then, the combined performance of each device in the network directly maps into the final performance at the end of the chain. For this reason, engineers writing an RFP should be mindful of the fact that many timing features, and certainly those that improve the performance, costs money. This is especially true when these timing features require specialized hardware (at non-trivial cost) to meet that requirement. A good example is holdover performance (see the sections on holdover in "Chapter 9. PTP Deployment Considerations", and Chapter 11). Vendors could build a PTP-aware network element that could stay aligned to 1 us of holdover for several weeks, but it would be SO expensive that nobody would buy it (yes, that level of holdover is frequently requested in RFP requirements). So, the first piece of advice is to seriously think about the features that your solution requires and do not make a requirement mandatory unless it really is a deal breaker. For example, there are arguably better (and certainly cheaper) ways to deliver resiliency and redundancy in a timing design than to ask for atomic clock-level performance in thousands of low-end network elements. On the other hand, vendors also understand that operators also define RFPs for brownfield deploy- ments; hence, sometimes the requirements need to be defined in very fine detail to ensure that the requirements align or are compatible with the envisioned deployment scenarios. That is totally un- derstandable, but just appreciate that timing characteristics are frequently hardware dependent, and poorly defined RFPs end up targeting more expensive equipment than might be required. The second piece of advice is to allow the vendors some degree of flexibility in designing a solution and allow them to propose innovative solutions to the problem. A better approach might be define the desired outcome rather than be too specific and lock the vendor into a traditional solution. In summary, here are some tips t