Those people involved in the birth of the Internet never talk about the Internet as having been 'invented', as it was not. It was engineered by many people. It incorporates many, now standard, protocols for communicating in many different but specific ways, suitable for a wide range of different applications. The creation of the Internet was not only a breakthrough on the technological front, it was also a tremendous breakthrough sociologically. It all started with a handful of people meeting in a single room to talk about how to connect their computer networks, and grew to become an international ad hoc effort with the least amount of formal and official structure possible. In short, it was a meeting of technicians, not a meeting of politicians.
The fact that no formal organization is responsible for the design and development of the Internet does not mean that the Internet is in a perpetual state of chaos and near collapse. On the contrary, the Internet functions with extreme reliability, made possible by the ad hoc organization of the IETF, the Internet Engineering Task Force. And what makes this even more unique is that the IETF does not exist. There is no legal entity called IETF. The IETF solely works by the existence of two processes and a mantra.
The mantra that describes the goals of the IETF is concrete and precise: Consensus and running code. The two processes that make this possible are the mailing lists that are organized in 'working groups', and the quarterly gatherings of people at IETF conferences around the world, which give everyone and anyone, even those not backed by a large organization, a chance to attend a few meetings per year. Anyone can join a working group mailing list and become part of this process. There are no fees involved. The conferences are usually sponsored by vendors of networking equipment, and cost about $1500 to attend. These fees are to recover the rent of the conference facilities and administrative costs.
People attend and speak at the IETF as individuals, and not on behalf of their employer. In fact, many IETF regulars have switched jobs repeatedly without letting it impact their work within the IETF.
The procedure followed by the IETF is relatively simple. When some people identify a need for a new protocol to solve some technical issue, they can form a working group. They pick a chairman, and set up one or more mailing lists. They create a charter that formulates the problem and then discussion on the mailing lists and at IETF conferences proceeds until the working group reaches a consensus on the design. This process generally sees the working group publish several draft documents. At some point, a working implementation will be written by someone, some group, or vendor with a specific interest in the new protocol. Once the working group is confident enough that no flaws can be found in the protocol, and when those claims are backed by at least two independently written functioning (interoperating) implementations of the drafted protocol, it will be submitted to the Internet Engineering Steering Group (IESG). This group consists of individual experts who have proven their knowledge and skills over a prolonged time at the IETF. They are expected to be very knowledgeable, and capable of confirming the working group's claims. For certain essential core protocols, the process might also involve the Internet Architecture Board, another group of IETF veterans.
Once this group gives its approval to the new protocol, the draft protocol needs to be assigned a unique identifier. Historically, though now somewhat badly, named, this official registration is called a Request For Comments, or RFC. Furthermore, there are usually options or parameters of the new protocol that need some kind of central registration as well. These will receive their unique registrations in one of the IANA registers. For example, the list of ports used by certain protocols such as HTTP or SMTP is such a register.
This process of finalizing is done by the RFC Editor. The first RFC Editor was Jon Postel, but nowadays the RFC Editor is actually a small group of varying people. The RFC Editor will stamp the new protocol with its final official RFC registration number. Vendors who have not yet implemented the draft protocol can now go and implement the final RFC-specified implementation. Sometimes, vendors get together in bake off events. There, they will test their implementation with those of other vendors, to see if they interoperate correctly. Once they do, the new protocol is ready to be included in their new equipment or software.
This is exactly the same procedure that the IPsec protocols went through, before becoming RFCs. Due to the complexity of IPsec, there are over 20 RFCs describing the various parts of the protocols. An overview of those can be found in Appendix D.
At some point, even in the old days of the first RFC Editor, Jon Postel, it became clear that the IETF had to take a stance on security, cryptography, and whether or not its protocols should have backdoors or key escrow built in. Some people noticed that the RFCs had skipped one particular RFC number, the number 1984. In August 1996, the IETF released RFC 1984, expressing the view of the IETF on cryptography and key escrow. The IETF strongly opposed any backdoors or key escrow feature in its protocols. Any attempt to make a protocol weaker just to assist a government in online surveillance was considered extremely dangerous. This was not a political opinion, but purely motivated by technological reasoning. The IETF would not hamper its protocol design. An excerpt from RFC 1984:
The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy.
Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology. Ready access to such technology is therefore a key factor in the future growth of the Internet as a motor for international commerce and communication.
The IAB and IESG are therefore disturbed to note that various governments have actual or proposed policies on access to cryptographic technology that either:
(a) impose restrictions by implementing export controls; and/or
(b) restrict commercial and private users to weak and inadequate mechanismssuch as short cryptographic keys; and/or
(c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or
(d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations.
We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies, as discussed below.
The IAB and IESG would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries.
RFC 1984 has been complemented by RFC 2804, Policy on Wiretapping, where the IETF announced its stance that wiretapping had no place in the protocol standards, and should be achieved using alternative means. This position was not based on a consensus of political opinion, but was based purely on technical arguments.