the Inter- net, they must also meet stringent requirements for scalability. No matter what the scenario that originally provoked a new protocol might look like, the resulting protocol should be usable in large networks with several mil- lions nodes. Robustness is another feature every protocol should exhibit. The IETF approach to protocol robustness is well captured in one sentence: be strict when sending and tolerant when receiving. An implementation should always strive to follow correct protocol syntax and send well-formed mes- sages. However, messages received by one implementation from another should not be scrutinized for grammatical errors or syntax problems. The guideline is that any message that can be understood should be processed, and adherence to that guideline enables correct implementations to inter- work properly with faulty ones. For instance, suppose a protocol specification states that a certain mes- sage containing a timestamp has to be sent every 500 ms. A merely correct implementation would send the message every 500 ms, but a good imple- mentation would work just as well if it receives messages every 400 ms instead. Obviously, this guideline is not endlessly flexible; it's meant to be applicable as long as the faulty input doesn't affect the correct operation of the system. Figure 2-11 is a familiar illustration of how someone adopting this guide- line approach manages to communicate with someone who does not follow strict English grammar rules. In order to make sense of all these design rules, we need to consider briefly how the process of new protocol design in the Internet has evolved into the procedures used by today's IETF. The following contains a brief his tory of the Internet for this purpose. Packet Switching, IP, and the IETF Figure 2-11 Be strict when O brother, where sending and tolerant art thou? when receiving. I am right here. Bob receives a faulty (although still understandable) input, but he answers properly. History of the Internet Protocol Development Process The Internet