o help get a result from your next timing RFP that might better re- flect your needs and budget: Try to limit the list of features to what you reasonably need. Perhaps there are some "nice to have" features that might solve a problem that could perhaps arise in the future in a small subset of cases. That is completely understood, but it would be better not to have those features as a mandatory requirement for each class of equipment. Try to differentiate the features based on the type of machine being proposed and the location of the equipment in the network. There are networking, routing, and redundancy features that are standard for very large core routers that are uncalled for in a cell site router. The same is true for timing features, SO it might help to tailor the RFP questions somewhat for the role and position of the network clock. There are standards defining almost every aspect of the timing solutions: from network topolo- gies to clock behavior and performance. It saves a lot of work to specify, for example, "must meet Class B noise generation for a Telecom Boundary Clock (T-BC) according to G.8273.2" rather than to try to define clock performance in your own words. Be sure to include optional components of standards if they are important to your solution. Similarly, be more specific and avoid outlining features in an overly broad manner, such as "must support 1588," which is SO vague and nonspecific that it is almost meaningless. It is an easy requirement to comply with, but it will not help you select a better device for a network timing solution. If you do not understand timing that well, then seek input from knowledgeable people who can help you design a better list of specifications for your next procurement. RFPs commonly have requirements like "must support Class C oscillator," which is impossible to comply with-since there is no such thing. The people answering the RFP questions will politely try to answer the question, but it will not help a selection process because it is basically a flawed q