The following text is copyright 2011 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.
The Internet Engineering Task Force (IETF): Unfinished Business
By Scott Bradner
As I write this, the IETF has been around for 25 years and a few hours. (http://www.networkworld.com/news/2011/011411-ietf.html) The first meeting (http://www.ietf.org/proceedings/01.pdf) of the IETF started at 9 AM on Thursday, 16 January, 1986 in San Diego, California with 21 people in attendance. A far cry from the most recent meeting (http://www.ietf.org/proceedings/79/) in Beijing, China, which attracted 1207 attendees. The Internet we have today, and that most enterprises heavily depend on, is largely a result of IETF technologies, and more importantly, the IETF philosophy of the proper role of the network. The network that sprang from this philosophy is now under sustained attack and the future role of the IETF will depend on how well the IETF responds to this attack.
I first started paying attention to the IETF in 1988 or 89 by monitoring various IETF mailing lists -- the first meeting I attended in person was the Tallahassee, Florida meeting in early 1990. (My boss was not willing to spring for the previous meeting in Hawaii - so it goes.) I go back a ways with the IETF but there are others that go back further -- 20% (4) of the attendees of the first IETF meeting are still active in the IETF.
If there is a key document that was the origin of the IETF's design philosophy it is the 1984 Saltzer, Reed & Clark paper "End to End Arguments in System Design." A dozen years after this paper was published the IETF published an expanded description of its design philosophy in RFC 1958 " Architectural Principles of the Internet". (You can find pointers to these, and many other relevant documents at http://www.sobco.com/e.132/reading/02-arch.html.) The IETF has interpreted the End-to-End paper to basically say that the network should not be application aware, unless told otherwise by an application, the network should treat all Internet traffic the same. The IETF has defined various ways that an application can ask for special treatment by the network (such as Diffserv defined in RFC 2474 (http://www.ietf.org/rfc/rfc2474.txt)) but generally networks are ways to get bunches of bits (packets) from one place to another.
In brief, this design philosophy has led the IETF to create technologies that can be deployed without having to get permission from network operators or having to modify the networks. This is not to say that IETF protocols have not been impacted by the proliferation of firewalls and network address translators (NATs) - see RFC 2775 (http://www.ietf.org/rfc/rfc2775.txt) But this design philosophy has also led to an environment where network operators do not get added value from high-value traffic. This is the heart of the network neutrality discussions being played out so loudly in the wake of the recent FCC proposal.
The IETF has developed many technologies that make the Internet function, make the networks that make up the Internet more secure and make the Internet work over ever faster and ever changing transport technologies. But the IETF has developed far more technologies that run over the Internet to provide end to end functions for you and me to use.