Internet Engineering Task Force (IETF)
[Note: this page is maintained by OBJS and not IETF. It is meant
to provide a quick overview of the IETF (mission, scope, and organization)
and how these relate to OMG. IETF is the organization most involved
in creating Internet standards and OMG is the organization most
involved in object technology standards. At issue is, how can
these communities interoperate as OO and Internet technologies
begin to merge.]
Table of Contents
IETF Mission
How IETF Operates (in comparison to OMG)
Areas and Working Groups
Internet Protocols
IETF provides a forum for working groups to coordinate technical
development and selection of the Internet protocol suite (collection
of de facto standards). Begun in 1986 as a forum for technical
coordination by U.S. DoD contractors working on ARPANET and related
DoD networks, IETF is now a large open international community
of network designers, operators, vendors, and researchers concerned
with the architecture, evolution, and smooth operation of the
global Internet. IETF meets three times a year. Most of the work
is done off-line.
Relevant WWW home pages are:
Internet files may be obtained from several sites including ds.internic.net via
anonymous ftp. Send email to ietf-info@cnri.reston.va.us
with general inquiries about IETF. Send email ietf-announce-request@cnri.reston.va.us
to get on the moderated email exploder to learn about announcements
(meeting logistics, agendas, RFC announcements, and Internet-Draft
announcements) or ietf-request@cnri.reston.va.us
to get on the main IETF discussion exploder. Discussions is very
active. Prepare to be swamped. The -request lists are human-moderated.
IETF and OMG share similarities and differences:
- most work is done at member organizations and not at meetings.
IETF meetings mostly review deltas on drafts and issues related.
So if one attends IETF meetings, it is important to read relevant
documents, comment over email on issues, designs, etc. before
the meeting. Meetings mainly provide authors a gauge on how many
people care about a topic and believe the work is heading in the
right direction. This is similar to OMG.
- IETF is somewhat larger in current scope than OMG with many
more active working groups (see below). OMG has perhaps a half
to a fifth as many specifications it is producing or has produced.
Both organizations have many concurrent sessions, more than one
person can attend.
- IETF does not "bless" other groups' documents. It
is a working organization and so expects revision control over
documents it produces. It might reference outside standards but
it only works on documents if it has revision control. An OMG
document for which OMG retains revision control can be published
in IETF as an Informational RFC as a way to inform IETF about
OMG documents and get a community critique. But this is only worth
doing if OMG wants a community review of its specifications from
the IETF community and is willing to consider consequent proposed
revisions.
- IETF and OMG are open in different ways. IETF membership is
anyone interested in understanding or working on IETF work items.
OMG membership is organizations who pay membership dues. IETF
accepts specifications from any source, requires implementation
experience and multiple interoperable implementations before standards
are accepted. OMG requires specification providers to be full
members (or sponsored by full members) and requires commercialization
within a year. In OMG, specification revisions are the responsibility
of submitting companies who take inputs from others. In both cases,
any company can implement published specifications.
- IETF Working Groups are targeted on one or a few specifications,
have a charter, milestones, and disappear when their work is completed.
The mantra is "rough consensus and running code". There
is no voting; decisions are made by demonstrations and discussions
by email and at meetings. And in the marketplace, by use.
- IETF documents fall into several categories:
- Internet Drafts -- working documents, no status of
any kind, deleted after 6 months.
- Requests for Comment (RFCs) -- archival documents of
several kinds
- Standards Track -- there is a "survival of the
fittest" view of RFCs. No mandate from IETF makes an IETF
standard something the Internet community must adopt. Instead,
if RFCs don't make it in the marketplace, they are eventually
superseded. At a given time, there may be several competing specifications.
Nevertheless, IETF has a standards hierarchy.
- Proposed Standard -- complete specs of credible utility.
After 6 months and before 2 years, then elevated, deprecated,
or recycled. [Many OMG adopted specs are at this level according
to this definition.]
- Draft Standard -- requires multiple independent interoperable
implementations, e.g., the spec is not underspecified if multiple
vendors can implement it. Based on limited operational experience,
this spec and its implementations work well. After 4 months and
before 2 years, then elevated, deprecated, or recycled. [e.g.,
OMG CORBA but not yet most CORBAservices or CORBAfacilities meet
this criterion.]
- Standard -- demonstrated operational stability. Can
stay forever or be deprecated to Historic.
- Informational
- Experimental
- Historic
- Best Current Practice
- IETF scope versus OMG scope. Many but not all IETF specifications
are "on the wire" interchange format specifications
and not API specifications. There is a strong feeling among several
key people that interoperability-in-the-large is achieved by wire
protocols, not APIs. The claim, based on experience, is that one
wire format accommodates multiple APIs. At the application level,
SGML-based HTML extensions appear to be an example of how typed
information is exchanged.
- Unlike OMG with its OMA architecture, there does not appear
to be any one overarching Internet architecture. More, it seems
a patchwork of standards. This may be a naive view.
The work of IETF is divided into areas, each of which is
further divided into working groups (WGs) and birds
of a feather (BOFs). During a 5-day long meeting three times
a year, working groups meet, usually for 2-4 hours each, to review
progress and proposals on highlights of work items that they are
responsible for. Perhaps 500-700 people attended the IETF meeting
in Dallas in December 1995. Several sessions were broadcast over
MBONE.
To provide a sense of the IETF landscape, we provide a list of
current (as of December 1995) IETF areas and the working groups
within those areas (listed below). Some possible OMG - IETF liaisons
are (very tentatively) listed in [...].
- General Interest -- GEN
- Process for Organization of Internet Standards -- poised'95
- Internet Architecture Board -- iab
- IETF Role in DNS Evolution -- dnsevolv-bof
- Applications -- APP -- John Klensin (MCI) and Harald Alvestrand
(UNINETT)
- HyperText Markup Language -- html
- HyperText Transfer Protocol -- html
- [OMG Internet SIG gateways between OIDs and URLs]
- MIME Content Type for SGML Documents -- mimesgml
- MIME - X.400 Gateway -- mixer
- Detailed Revision and Update of Message Standards -- drums
- Integrated Directory Services -- ids
- Common Indexing Protocol -- find
- Accessing, Searching, and Indexing of Directories -- asid
- [OMG OSTF Object Indexing Service]
- Mail and Directory Management -- madman
- Receipt Notification of Internet Mail -- receipt
- Uniform Resource Names BOF -- urn-bof
- Uniform Resource Characteristics BOF -- urc-bof
- Voluntary Access Control BOF -- vac-bof
- Security -- SEC -- Jeff Schiller (MIT)
- Security Area Advistory Group -- saag
- [OMG OSTF Security Services & OMG Security SIG & OMG
ORBTF Encryption Protocol RFP and Secure Interoperability RFP]
- Web Transaction Security -- wts
- [OMG OSTF Transactions & Security Services]
- Public Key Infrastructure (X.509) -- pkix
- Common Authentication Technology -- cat
- Authentication Firewall Protection -- aft
- [OMG needs work in this area]
- IP Security Protocol -- ipsec
- Domain Name System Security -- dnssec
- Internet Secure Payments Protocol BOF -- issp-bof
- [proposed Internet Electronic Commerce SIG & OMG Finance
SIG & OMG Internet SIG]
- One time Password Authentication -- otp
- Network Management -- MGT -- Deidre Kostick (AT&T)
- Network Management Open Area Meeting -- nmarea
- SNMP Agent Extensibility -- agentx
- Application MIB BOF -- applmib-bof
- AToM MIB -- atommib
- IEEE 802.3 Hub MIB
- Interfaces MIB -- ifmib
- RAID MIB BOF -- raidmib-bof
- Entity MIB -- entmib
- ISDN MIB -- isdnmib
- DS1/DS3 MIB -- trunkmib
- Uninterruptable Power Supply -- upsmib
- Operational Requirements -- OPS -- Michael O'Dell (UUNET Technologies)
and Scott Bradner (Harvard)
- Guide for Internet Standards Writers -- stdguide
- Guidelines & Recommendations for Security Incident Processing
-- grip
- Remote Authentication Dial in User Service -- radius-bof
- Procedures for Internet/Enterprise Renumbering -- pier-bof
- Benchmarking Methodology -- bmwg
- CIDR Deployment -- cidrd
- Routing Policy Service -- rps
- Real-time Traffic Flow Measurement -- rtf-bof
- RWHOIS Operational Development -- rwhois
- Mbone Engineering -- mboneng-bof
- Internet -- INT -- Frank Kastenholz (FTP SW) and Susan Thomson
(Bellcore)
- MessageWay -- msgway
- Dynamic Host Configuration -- dhc
- DNS IXFR, Notification, and Dynamic Update -- dnsind
- IP over Asyncronous Transfer Mode -- ipatm
- Service Location Protocol -- svrloc
- Internet Stream Protocol V2 -- st2
- [ORBTF Streams and Multiple Interfaces RFP]
- Point-to-Point Protocol Extensions -- pppext
- IP: Next Generation -- IPNG -- Scott Bradner (Harvard) and
Allison Mankin (ISI)
- IP Next Generation Working Group -- ipngwg
- New Generation Transition -- ngtrans
- Address Autoconfiguration -- addrconf
- Transport -- TSV -- Allison Mankin (ISI)
- Transport Area Directorate Open Meeting -- tsvdir
- RFC 1006 bis/ISO TP over IP v6 -- rfc1006
- Multiway Multimedia Session Control -- mmusic
- Resource Reservation Setup Control -- rsvp
- Integrated Services -- intserv
- TCP Short Term Problems -- tcpfix-bof
- Routing -- RTG -- Joel Halpern (Newbridge Networking)
- Open Shortest Path First IGP -- ospf
- New Internet Routing and Addressing Architecture -- nimrod
- Interdomain Multicast Routing -- idmr
- Routing Information Protocol -- rip
- Routing over Large Clouds -- rolc
- Source Demand Routing -- sdr
- IP Routing for Mobile/Wireless Hosts -- mobileip
- [do we need a wireless CORBA SIG?]
- Mobile Mesh Networks BOF -- mmnet-bof
- User Services -- USV -- Joyce Reynolds (ISI)
- User Services Working Group -- uswg
- Site Security Handbook -- ssh
- Internet School Networking -- isn
- Internet School Networking 2 -- isn2-bof
- Internet User Glossary - usrglos
- Humanities and Arts - harts
IETF protocols are accessible from the descriptions of the Area
and Working Groups (above) or via the Internet Drafts index
or RFC index .
This research is sponsored by the Defense Advanced
Research Projects Agency and managed by the U.S. Army Research
Laboratory under contract DAAL01-95-C-0112. The views and conclusions
contained in this document are those of the authors and should
not be interpreted as necessarily representing the official policies,
either expressed or implied of the Defense Advanced Research Projects
Agency, U.S. Army Research Laboratory, or the United States Government.
© Copyright 1996 Object Services and Consulting,
Inc. Permission is granted to copy this document provided this
copyright statement is retained in all copies. Disclaimer:
OBJS does not warrant the accuracy or completeness of the information
on this page.
This page was written by Craig Thompson. Send
questions and comments about it to thompson@objs.com.
Last updated: 04/22/96 7:15 PM
Back to Internet Tool Survey -- Back
to OBJS