P is not just a network-layer protocol. IP is a completely new way of developing technology. Perhaps the best-known rule of thumb is to try to mirror the behavior of IP by implementing intelligent end systems and a relatively dumb network. This practice encourages the design of end-to-end protocols at layers above IP, where they can deliver better end-to-end functions. The terminal usually has the best knowledge in the system to provide the service that the user wishes to have. The network does not make unnec- essary assumptions about what the user wants, but it provides transmis- sion at a fairly predictable level. Another reason for using upper-layer end-to-end protocols is end-to-end security-security that doesn't depend on any (vulnerable or fallible) mechanism provided by the network. For appli- cations that are secured this way, the information flowing between end systems is encrypted and/or signed by the end systems themselves. In the case of encrypted messages, the network cannot access the contents trans- mitted. In the case of digital signatures, nothing outside the end terminals can modify the messages. In both situations, end-to-end protocols are the only means to provide end-to-end security without impinging on the func- tionality required for each application. Chapter 2 General Design Issues The IETF proffers a set of guidelines for protocol design in RFC 1958 [RFC 1958]. The express purpose of these guidelines is to improve the technical quality of the protocols documented in Request For Comments (RFCs) and to save time in the standardization process. If a protocol is properly designed from the beginning, the community does not need to give as much feedback to the authors and it can advance in the standards more efficiently. The IETF Toolkit The design process followed by the IETF is usually referred to as a bottom-up approach in order to distinguish it from approaches that start by defining an architecture and then design more granular protocols between the nodes. The bottom-up approach provides p