uestion. On the other hand, hiring a consultant with 500 cookie-cutter questions in a "one size fits all" boilerplate does not help dis- cern the best product for each role. Clearly understand the difference between clock requirements and network requirements. Ask- ing for requirements such as "cell site router must support 5G" or "aggregation device must support G.8271.1" is not that useful because they are solution or network requirements. The clock could "support" those standards and solutions but still be a dreadful PTP and SyncE clock. There is a similar issue with standards for timing that specify architecture and concept. Some of them are very high level and you do not learn anything by asking the question. In fact, some standards are SO conceptual that it is almost impossible to be noncompliant. The answers to those questions do not help you procure a better product. Do not ask the same questions repeatedly using slightly different terminology. One of the au- thors recently worked on a (very extensive) RFP that asked one question, in slightly different form, about a dozen times. When evaluating a vendor response, lack of support for this one (somewhat minor) feature would destroy the compliance score for that vendor's product. This can happen as well when the RFP is poorly divided into technologies. For example, the SyncE questions are in the timing section and repeated in the Ethernet or some other sections. This leads to possible inconsistency because the timing specialist did not see the timing ques- tion in the section on layer 2 (L2) Ethernet, and the L2 engineer did not understand the timing question properly. Do not expect support for the version of the ITU-T specification published last week to be in the router that will be delivered at the end of next month. If you need compliance to a new spe- cification, then the better approach is to allow "Roadmap" as an answer with a committed deliv- ery date, and do not require the answer to be "Mandatory, must comply." If you are going to ask about particu