RFC 1925 - The Twelve Networking Truths
[ RFC Index | Usenet FAQs | Web FAQs | Documents | Cities | Patents | Abstracts | Copyrights | Forum ]
Network Working Group R. Callon, Editor Request for Comments: 1925 IOOF Category: Informational 1 April 1996 The Twelve Networking Truths Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. Acknowledgements The truths described in this memo result from extensive study over an extended period of time by many people, some of whom did not intend to contribute to this work. The editor merely has collected these truths, and would like to thank the networking community for originally illuminating these truths. 1. Introduction This Request for Comments (RFC) provides information about the fundamental truths underlying all networking. These truths apply to networking in general, and are not limited to TCP/IP, the Internet, or any other subset of the networking community. 2. The Fundamental Truths (1) It Has To Work. (2) No matter how hard you push and no matter what the priority, you can't increase the speed of light. (2a) (corollary). No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker. (3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (4) Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. (5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection. (7) It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three). (8) It is more complicated than you think. (9) For all resources, whatever it is, you need more. (9a) (corollary) Every networking problem always takes longer to solve than it seems like it should. (10) One size never fits all. (11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. (11a) (corollary). See rule 6a. (12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. Security Considerations This RFC raises no security issues. However, security protocols are subject to the fundamental networking truths. References The references have been deleted in order to protect the guilty and avoid enriching the lawyers. Author's Address Ross Callon Internet Order of Old Farts c/o Bay Networks 3 Federal Street Billerica, MA 01821 Phone: 508-436-3936 EMail: rcallon@baynetworks.com User Contributions: 1 Brian Rawlings ⚠ Networking Truth N+1:There exists an N+1 layer to any multi-layer protocol. While often referred to as "The 8th layer in the 7-layer protocol", this is too limiting for a Networking Truth of this magnitude.This layer has a general description of "The Financial and Political Layer". No information can successfully traverse the other protocol layers until requirements of the N+1th layer are satisfied.It is suggested that this Networking Truth be included in the cannonical listing, since it is not adequately represented by any of the other Truths. 2 Gideon12 ⚠ You spelled agglutinate incorrectly. Please see RFC1925, Fundamental Truth #7 for more information. 3 Bakoor ⚠ 13. From the "Application" point of view, you should start troubleshooting from down to up, and from the Layer 1 point of view, you should start troubleshhoting from up to down. 4 Alexander ⚠ Sep 4, 2024 @ 9:21 pm It's strange looking upon these old RFCs for my networking class, it's like a fly trapped in amber; a series of endearing snapshots of the internet's development, frozen in time. Honestly a lot of this stuff would be worthy of some sort of fun internet historian style documentary. Personally I'd get right to work on it myself if I had the time. Comment about this RFC, ask questions, or add new information about this topic:
|