< draft-alvestrand-ietf-mission-01.txt   draft-alvestrand-ietf-mission-02.txt >
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: October 28, 2004 April 29, 2004 Expires: October 28, 2004 April 29, 2004
A Mission Statement for the IETF A Mission Statement for the IETF
draft-alvestrand-ietf-mission-01 draft-alvestrand-ietf-mission-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3667. RFC 3667.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 46 skipping to change at page 2, line 5
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo gives a mission statement for the IETF, tries to define the This memo gives a mission statement for the IETF, tries to define the
terms used in the statement sufficiently to make the mission terms used in the statement sufficiently to make the mission
statement understandable and useful, argues why the IETF needs a statement understandable and useful, argues why the IETF needs a
mission statement, and tries to capture some of the debate that led mission statement, and tries to capture some of the debate that led
to this point. to this point.
The appendix giving the debate is intended to be deleted when the RFC
is published; it is only given here as a reference and a thank-you
note.
1. Mission statement 1. Mission statement
The goal of the IETF is to make the Internet work better. The goal of the IETF is to make the Internet work better.
The mission of the IETF is to produce high quality, relevant The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people technical and engineering documents that influence the way people
design, use and manage the Internet in such a way as to make the design, use and manage the Internet in such a way as to make the
Internet work better. Internet work better.
These documents include protocol standards, best current practices These documents include protocol standards, best current practices
and informational documents of various kinds. and informational documents of various kinds.
The IETF will pursue this mission in adherence to the following The IETF will pursue this mission in adherence to the following
cardinal principles: cardinal principles:
Open process - that any interested participant can in fact Open process - any interested participant can participate in the
participate in the work, know what is being decided, and make his work, know what is being decided, and make his or her voice heard
or her voice heard on the issue. Part of this principle is our on the issue. Part of this principle is our commitment to making
commitment to making our documents, our WG mailing lists, our our documents, our WG mailing lists, our attendance lists and our
attendance lists and our meeting minutes publicly available on the meeting minutes publicly available on the Internet.
Net.
Technical competence - that the issues on which the IETF produces its Technical competence - the issues on which the IETF produces its
documents are issues where the IETF has the competence needed to documents are issues where the IETF has the competence needed to
speak to them, and that the IETF is willing to listen to speak to them, and that the IETF is willing to listen to
technically competent input from any source. technically competent input from any source.
Technical competence also means that we expect IETF output to be Technical competence also means that we expect IETF output to be
designed to sound network engineering principles - this is also designed to sound network engineering principles - this is also
often referred to as "engineering quality". often referred to as "engineering quality".
Volunteer Core - that our participants and our leadership are people Volunteer Core - our participants and our leadership are people who
who come to the IETF because they want to work for the IETF's come to the IETF because they want to do work that furthers the
purposes. IETF's mission of "making the Internet work better".
Rough consensus and running code - We make standards based on the Rough consensus and running code - We make standards based on the
combined engineering judgement of our participants and our combined engineering judgement of our participants and our
real-world experience in implementing and deploying our real-world experience in implementing and deploying our
specifications. specifications.
Protocol ownership - that when the IETF takes ownership of a protocol Protocol ownership - when the IETF takes ownership of a protocol or
or function, it accepts the responsibility for all aspects of the function, it accepts the responsibility for all aspects of the
protocol, even though some aspects may rarely or never be seen on protocol, even though some aspects may rarely or never be seen on
the Internet. Conversely, that when the IETF is not responsible the Internet. Conversely, when the IETF is not responsible for a
for a protocol or function, it does not attempt to exert control protocol or function, it does not attempt to exert control over
over it, even though it may at times touch or affect the Internet. it, even though it may at times touch or affect the Internet.
2. Definition of terms 2. Definition of terms
Misson: What an organization sets out to do. This is in contrast to Misson: What an organization sets out to do. This is in contrast to
its goal (which is what it hopes to achieve by fulfilling its its goal (which is what it hopes to achieve by fulfilling its
mission), and to its activities (which is what specific actions it mission), and to its activities (which is what specific actions it
takes to achieve its mission). takes to achieve its mission).
The Internet: A large, heterogenous collection of interconnected The Internet: A large, heterogenous collection of interconnected
systems that can be used for communication of many different types systems that can be used for communication of many different types
skipping to change at page 6, line 27 skipping to change at page 6, line 27
decentralized control, edge-user empowerment and sharing of decentralized control, edge-user empowerment and sharing of
resources, because those concepts resonate with the core values of resources, because those concepts resonate with the core values of
the IETF community. These concepts have little to do with the the IETF community. These concepts have little to do with the
technology that's possible, and much to do with the technology that technology that's possible, and much to do with the technology that
we choose to create. we choose to create.
At the same time, it is clear that many of the IETF-defined At the same time, it is clear that many of the IETF-defined
technologies are useful not only for the Internet, but also for technologies are useful not only for the Internet, but also for
networks that have no direct relation to the Internet itself. networks that have no direct relation to the Internet itself.
In attempting to resolve this question, perhaps the fairest balance In attempting to resolve the question of the IETF's scope, perhaps
is struck by this formulation: "protocols and practices for which the fairest balance is struck by this formulation: "protocols and
secure and scalable implementations are expected to have wide practices for which secure and scalable implementations are expected
deployment and interoperation on the Internet, or to form part of the to have wide deployment and interoperation on the Internet, or to
infrastructure of the Internet." form part of the infrastructure of the Internet."
In addition to this constraint, we are also constrained by the In addition to this constraint, we are also constrained by the
principle of competence: Where we do not have, and cannot gather, the principle of competence: Where we do not have, and cannot gather, the
competence needed to make technically sound standards, we should not competence needed to make technically sound standards, we should not
attempt to take the leadership. attempt to take the leadership.
4.2 The balance between research, invention and adoption 4.2 The balance between research, invention and adoption
The IETF has traditionally been a community for both experimentation The IETF has traditionally been a community for experimentation with
with things that are not fully understood, standardization of things that are not fully understood, standardization of protocols
protocols for which some understanding has been reached, and for which some understanding has been reached, and publication of
publication of (and refinement of) protocols originally specified (and refinement of) protocols originally specified outside the IETF
outside the IETF process. process.
All of these activities have in common that they produce documents - All of these activities have in common that they produce documents -
but the documents should be judged by very different criteria when but the documents should be judged by very different criteria when
the time to publish comes around, and it's not uncommon to see people the time to publish comes around, and it's not uncommon to see people
confused about what documents are in which category. confused about what documents are in which category.
In deciding whether or not these activities should be done within the In deciding whether or not these activities should be done within the
IETF, one should not chiefly look at the type of activity, but the IETF, one should not chiefly look at the type of activity, but the
potential benefit to the Internet - an experiment that yields potential benefit to the Internet - an experiment that yields
information about the fact that an approach is not viable might be as information about the fact that an approach is not viable might be of
worthy of publication as a standard that is technically competent, greater benefit to the Internet than publishing a standard that is
but only useful in a few special cases. technically competent, but only useful in a few special cases.
For research of an essentially unbounded nature, with unknown For research of an essentially unbounded nature, with unknown
probability of success, it may be more relevant to charter a research probability of success, it may be more relevant to charter a research
group than a standards group. For activities with a bounded scope - group than a standards group. For activities with a bounded scope -
such as specifying several alternative protocols to the point where such as specifying several alternative protocols to the point where
experiments can identify the better one for standardization - the experiments can identify the better one for standardization - the
IETF's working group mechanism may be an appropriate tool. IETF's working group mechanism may be an appropriate tool.
4.3 The balance between mission and procedures 4.3 The balance between mission and procedures
skipping to change at page 10, line 11 skipping to change at page 10, line 11
Considering security is one of the core principles of sound network Considering security is one of the core principles of sound network
engineering for the Internet. Apart from that, it's not relevant to engineering for the Internet. Apart from that, it's not relevant to
this memo. this memo.
6. Acknowledgements 6. Acknowledgements
This document is a result of many hours of debate, countless reviews This document is a result of many hours of debate, countless reviews
and limitless emails. As such, any acknowledgements section is bound and limitless emails. As such, any acknowledgements section is bound
to be incomplete. to be incomplete.
Among the people who worked on it was the IESG at the time of this Among the many who provided input were the current members of the
writing (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David IESG (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David
Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott
Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent
IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as
multiple IAB members. Special thanks go to made of Leslie Daigle, IAB multiple IAB members, and many members from the community, including
chair. James Polk, John Klensin, Pekka Savola, Paul Hoffman, Eliot Lear,
Jonne Soininen, Fred Baker, Dean Anderson, John Leslie, Susan Harris
From the community we also need to mention James Polk, John Klensin, and many others. Special thanks go to Leslie Daigle, the IAB chair.
Pekka Savola, Paul Hoffman, Eliot Lear, Jonne Soininen, Fred Baker,
Dean Anderson and many others.
NOTE IN DRAFT: Given how incomplete this section necessarily is,
should it just say "None mentioned, none forgotten"?
Author's Address Author's Address
Harald Tveit Alvestrand Harald Tveit Alvestrand
Cisco Systems Cisco Systems
Weidemanns vei 27 Weidemanns vei 27
Trondheim 7043 Trondheim 7043
NO NO
EMail: harald@alvestrand.no EMail: harald@alvestrand.no
Appendix A. From the debate: Other mission statements proposed Appendix A. Change log
This appendix is intended to be removed when (if) this document is
published as an RFC. It is intended to aid the memory of those
engaging in discussion about it, and avoid repetition of previous
discussion and proposals of alternatives. These other mission
statements have formed a critical part of the process leading to the
current proposal, and thanks should be extended to their formulators.
A.1 The Tao of IETF
RFC 3160, the Tao of IETF (latest version) says (section 1):
The Internet Engineering Task Force is a loosely self-organized group
of people who contribute to the engineering and evolution of Internet
technologies. It is the principal body engaged in the development of
new Internet standard specifications. The IETF is unusual in that it
exists as a collection of happenings, but is not a corporation and
has no board of directors, no members, and no dues.
Its mission includes:
Identifying, and proposing solutions to, pressing operational and
technical problems in the Internet;
Specifying the development or usage of protocols and the near-term
architecture to solve such technical problems for the Internet;
Making recommendations to the Internet Engineering Steering Group
(IESG) regarding the standardization of protocols and protocol
usage in the Internet;
Facilitating technology transfer from the Internet Research Task
Force (IRTF) to the wider Internet community; and
Providing a forum for the exchange of information within the
Internet community between vendors, users, researchers, agency
contractors, and network managers.
The IETF meeting is not a conference, although there are technical
presentations. The IETF is not a traditional standards organization,
although many specifications are produced that become standards. The
IETF is made up of volunteers, many of whom meet three times a year
to fulfill the IETF mission.
There is no membership in the IETF. Anyone may register for and
attend any meeting. The closest thing there is to being an IETF
member is being on the IETF or Working Group mailing lists (see
Section 1.3). This is where the best information about current IETF
activities and focus can be found.
Of course, no organization can be as successful as the IETF is
without having some sort of structure. In the IETF's case, that
structure is provided by other organizations, as described in BCP 11,
"The Organizations Involved in the IETF Standards Process." If you
participate in the IETF and only read one BCP, this is the one you
should read.
Commentary: This is a long section. It also is quite unclear in the
scope of the term "IETF". And it does not provide any hint of which
goals are primary and which are secondary. But it does describe quite
accurately many aspects of the current IETF.
A.2 Harald Alvestrand from the London IESG
The purpose of the IETF is to create high quality, relevant standards
for the Internet
Commentary: This was formulated at an IESG meeting held in
conjunction with the IETF meeting. There is more text explaining more
background - see http://www.alvestrand.no/ietf/iesg/purpose.php
A.3 Ted Hardie to the IESG
The IETF is a community of active participants dedicated to producing
timely, high quality engineering work that describes protocols and
practices for which secure and scalable implementations are expected
to have wide deployment and interoperation on or to form part of the
infrastructure of the Internet.
Commentary: This came out of a meeting of a small group that was
convened by the IETF Chair in September 2003 to do a brainstorm on
what we could do to "make the IETF work better".
A.4 IESG sponsored proposal, November 2003
The IETF's mission has historically been embedded in a shared
understanding that making engineering choices based on the long term
interest of the Internet as a whole produces better long-term results
for each participant than making choices based on short term
considerations, because the value of those advantages is ultimately
derived from the health of the whole. The long term interest of the
Internet includes the premise that "the Internet is for everyone".
Two years ago, the IESG felt that making the mission of the IETF more
explicit was needed. The following terse statement has since been
promulgated, first by IESG members and then by others:
"The purpose of the IETF is to create high quality, relevant, and
timely standards for the Internet."
Note that this clearly positions the IETF primarily as a standards
development organization. There are other activities in the IETF;
but if the IETF does not do its core mission, all else will quickly
fade. This is intended to be an ordered list of characteristics.
Timely standards of low quality or that are irrelevant will not serve
the Internet's or the IETF's needs.
This leaves open the very interesting and difficult questions of how
to measure quality, relevance, and timeliness. The IETF has
identified interoperability, security, and scalability as essential,
but without attaching measurements to those characteristics.
It is important that this is "For the Internet," and does not
include everything that happens to use IP. IP is being used in a
myriad of real-world applications, such as controlling street lights,
but the IETF does not standardize those applications.
Commentary: This was part of an "IETF social contract" proposed by
the IESG to the IETF list on October 14, 2003. It engendered quite a
bit of discussion, with perhaps the most heated part being the
definition of "For the Internet".
A.5 Fred Baker
The Internet Engineering Task Force provides a forum for the
discussion and development of white papers and specifications for the
engineering issues of the Internet.
This discussion builds on hard lessons learned in research and
operational environments, and necessarily includes speakers from
those communities. Vendors offer wisdom on what can be built and made
to work in their products, and may bring customer or market issues
whose owners cannot or will not bring themselves.
The intended goal is well characterized as 'community memory' -
written observations and wisdom as well as protocols and operational
procedures defined - to enable the datagram internet to scalably
deliver relevant services in transit and edge networks."
This was sent to the IETF list as part of a discussion on the IETF
mission on Jan 29, 2004.
A.6 Dean Anderson
IETF is a technical protocol standards organization. Its principal
goals are:
To create open, technical standards that will be useful to and
adopted by the world internet communtity and the public at large.
To identify current and emerging protocol requirements, and share
best practices.
To facliitate the participation of all affected and interested
parties and develop consensus.
To solicit the input of a diverse group of interests and
participants in the formation of protocol standards.
To provide a fair and open process whereby any party that believes
it has been treated unfairly has the right to appeal.
To work with suppliers, consortia, and other standards bodies to
develop consensus and facilitate interoperability.
Comment: Sent to the IETF list on February 4, 2004. Had some
discussion on the "appeal" point - whether "party" was persons or
companies, and whether appeals belonged in a mission statement.
Appendix B. Change log
This appendix is intended to be removed when this document is This appendix is intended to be removed when this document is
published as an RFC. It gives a list of the important changes since published as an RFC. It gives a list of the important changes since
version -00, and the reason for them. version -00, and the reason for them.
B.1 Changes since -00 A.1 Changes from -00 to -01
The goal of the IETF was changed to "... make the Internet work The goal of the IETF was changed to "... make the Internet work
better" (add "better"). There's a reasonable chance that we can tell better" (add "better"). There's a reasonable chance that we can tell
the difference between the Internet working "better" and "worse" - the difference between the Internet working "better" and "worse" -
and we shouldn't limit ourselves to a goal of "just barely working". and we shouldn't limit ourselves to a goal of "just barely working".
The operating principle of protocol ownership was added, and a The operating principle of protocol ownership was added, and a
discussion about it was added as section 4.5. discussion about it was added as section 4.5.
Modified the "reach of the Internet" to make it clear that both sides Modified the "reach of the Internet" to make it clear that both sides
skipping to change at page 16, line 5 skipping to change at page 11, line 33
Section about the global Internet added as section 4.4 Section about the global Internet added as section 4.4
Modified definition of "participant" to make it obvious that Modified definition of "participant" to make it obvious that
participants are people participants are people
Added acknowledgements section Added acknowledgements section
Added this appendix Added this appendix
A.2 Changes from -01 to -02
Tightened up the text on various points
Reworded point on "volunteer core"
The appendix giving other proposed mission statements was removed
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79. be found in BCP 78 and BCP 79.
 End of changes. 15 change blocks. 
216 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/