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.