GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp95

Network Working Group H. Alvestrand Request for Comments: 3935 Cisco Systems BCP: 95 October 2004 Category: Best Current Practice

                  A Mission Statement for the IETF

Status of this Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This memo gives a mission statement for the IETF, tries to define the
 terms used in the statement sufficiently to make the mission
 statement understandable and useful, argues why the IETF needs a
 mission statement, and tries to capture some of the debate that led
 to this point.

1. Mission Statement

 The goal of the IETF is to make the Internet work better.
 The mission of the IETF is to produce high quality, relevant
 technical and engineering documents that influence the way people
 design, use, and manage the Internet in such a way as to make the
 Internet work better.  These documents include protocol standards,
 best current practices, and informational documents of various kinds.
 The IETF will pursue this mission in adherence to the following
 cardinal principles:
 Open process - any interested person can participate in the work,
    know what is being decided, and make his or her voice heard on the
    issue.  Part of this principle is our commitment to making our
    documents, our WG mailing lists, our attendance lists, and our
    meeting minutes publicly available on the Internet.
 Technical competence - the issues on which the IETF produces its
    documents are issues where the IETF has the competence needed to
    speak to them, and that the IETF is willing to listen to

Alvestrand Best Current Practice [Page 1] RFC 3935 IETF Mission Statement October 2004

    technically competent input from any source.  Technical competence
    also means that we expect IETF output to be designed to sound
    network engineering principles - this is also often referred to as
    "engineering quality".
 Volunteer Core - our participants and our leadership are people who
    come to the IETF because they want to do work that furthers the
    IETF's mission of "making the Internet work better".
 Rough consensus and running code - We make standards based on the
    combined engineering judgement of our participants and our real-
    world experience in implementing and deploying our specifications.
 Protocol ownership - when the IETF takes ownership of a protocol or
    function, it accepts the responsibility for all aspects of the
    protocol, even though some aspects may rarely or never be seen on
    the Internet.  Conversely, when the IETF is not responsible for a
    protocol or function, it does not attempt to exert control over
    it, even though it may at times touch or affect the Internet.

2. Definition of Terms

 Mission: What an organization sets out to do.  This is in contrast to
    its goal (which is what it hopes to achieve by fulfilling its
    mission), and to its activities (which is what specific actions it
    takes to achieve its mission).
 The Internet: A large, heterogeneous collection of interconnected
    systems that can be used for communication of many different types
    between any interested parties connected to it.  The term includes
    both the "core Internet" (ISP networks) and "edge Internet"
    (corporate and private networks, often connected via firewalls,
    NAT boxes, application layer gateways and similar devices).  The
    Internet is a truly global network, reaching into just about every
    country in the world.
    The IETF community wants the Internet to succeed because we
    believe that the existence of the Internet, and its influence on
    economics, communication, and education, will help us to build a
    better human society.
 Standard: As used here, the term describes a specification of a
    protocol, system behaviour or procedure that has a unique
    identifier, and where the IETF has agreed that "if you want to do
    this thing, this is the description of how to do it".  It does not
    imply any attempt by the IETF to mandate its use, or any attempt
    to police its usage - only that "if you say that you are doing
    this according to this standard, do it this way".  The benefit of

Alvestrand Best Current Practice [Page 2] RFC 3935 IETF Mission Statement October 2004

    a standard to the Internet is in interoperability - that multiple
    products implementing a standard are able to work together in
    order to deliver valuable functions to the Internet's users.
 Participants: Individuals who participate in the process are the
    fundamental unit of the IETF organization and the IETF's work.
    The IETF has found that the process works best when focused around
    people, rather than around organizations, companies, governments
    or interest groups.  That is not to say that these other entities
    are uninteresting - but they are not what constitutes the IETF.
 Quality: In this context, the ability to express ideas with enough
    clarity that they can be understood in the same way by all people
    building systems to conform to them, and the ability (and
    willingness) to describe the properties of the system well enough
    to understand important consequences of its design, and to ensure
    that those consequences are beneficial to the Internet as a whole.
    It also means that the specifications are designed with adherence
    to sound network engineering principles, so that use for its
    intended purpose is likely to be effective and not harmful to the
    Internet as a whole.
 Relevant: In this context, useful to some group of people who have to
    make decisions that affect the Internet, including, but not
    limited to, hardware and software implementors, network builders,
    network operators, and users of the Internet.  Note that it does
    not mean "correct" or "positive" - a report of an experiment that
    failed, or a specification that clearly says why you should not
    use it in a given situation, can be highly relevant - for deciding
    what NOT to do.  A part of being relevant is being timely - very
    often, documents delivered a year after core decisions have been
    taken are far less useful than documents that are available to the
    decision-makers at decision time.

3. The Need for a Mission Statement

 The IETF has to make decisions.  And in some cases, people acting on
 behalf of the IETF have to make decisions without consulting the
 entire IETF first.
 There are many reasons for this, including the near-impossibility of
 getting an informed consensus opinion on a complex subject out of a
 community of several thousand people in a short time.
 Having a defined mission is one of the steps we can take in order to
 evaluate alternatives: Does this help or hinder the mission, or is it
 orthogonal to it? If there are limited resources, are there things
 that they could be invested in that help the mission better?

Alvestrand Best Current Practice [Page 3] RFC 3935 IETF Mission Statement October 2004

 (Another step is to choose leaders that we trust to exercise their
 good judgement and do the right thing.  But we're already trying to
 do that.)

4. Issues with Scoping the IETF's Mission

4.1. The Scope of the Internet

 A very difficult issue in discussing the IETF's mission has been the
 scope of the term "for the Internet".  The Internet is used for many
 things, many of which the IETF community has neither interest nor
 competence in making standards for.
 The Internet isn't value-neutral, and neither is the IETF.  We want
 the Internet to be useful for communities that share our commitment
 to openness and fairness.  We embrace technical concepts such as
 decentralized control, edge-user empowerment and sharing of
 resources, because those concepts resonate with the core values of
 the IETF community.  These concepts have little to do with the
 technology that's possible, and much to do with the technology that
 we choose to create.
 At the same time, it is clear that many of the IETF-defined
 technologies are useful not only for the Internet, but also for
 networks that have no direct relation to the Internet itself.
 In attempting to resolve the question of the IETF's scope, perhaps
 the fairest balance is struck by this formulation: "protocols and
 practices for which secure and scalable implementations are expected
 to have wide deployment and interoperation on the Internet, or to
 form part of the infrastructure of the Internet."
 In addition to this constraint, we are also constrained by the
 principle of competence: Where we do not have, and cannot gather, the
 competence needed to make technically sound standards, we should not
 attempt to take the leadership.

4.2. The Balance Between Research, Invention and Adoption

 The IETF has traditionally been a community for experimentation with
 things that are not fully understood, standardization of protocols
 for which some understanding has been reached, and publication of
 (and refinement of) protocols originally specified outside the IETF
 process.

Alvestrand Best Current Practice [Page 4] RFC 3935 IETF Mission Statement October 2004

 All of these activities have in common that they produce documents -
 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
 confused about what documents are in which category.
 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
 potential benefit to the Internet - an experiment that yields
 information about the fact that an approach is not viable might be of
 greater benefit to the Internet than publishing a standard that is
 technically competent, but only useful in a few special cases.
 For research of an essentially unbounded nature, with unknown
 probability of success, it may be more relevant to charter a research
 group than a standards group.  For activities with a bounded scope -
 such as specifying several alternative protocols to the point where
 experiments can identify the better one for standardization - the
 IETF's working group mechanism may be an appropriate tool.

4.3. The Balance Between Mission and Procedures

 The mission is intended to state what the IETF is trying to achieve.
 There are many methods that can be chosen to achieve these outcomes -
 for instance, the appeals procedure is defined so that we can detect
 cases where our fundamental principles of technical competence and
 open process has been violated; it is not itself a fundamental value.
 Similarly, the question of what body in the IETF declares that a
 document is ready for publication is entirely outside the mission
 statement; we can imagine changing that without in any way impacting
 what the IETF mission is - even though it may significantly impact
 the ability to achieve that mission.

4.4. The Reach of the Internet

 The Internet is a global phenomenon.  The people interested in its
 evolution are from every culture under the sun and from all walks of
 life.  The IETF puts its emphasis on technical competence, rough
 consensus and individual participation, and needs to be open to
 competent input from any source.  The IETF uses the English language
 for its work is because of its utility for working in a global
 context.

Alvestrand Best Current Practice [Page 5] RFC 3935 IETF Mission Statement October 2004

4.5. Protocol Ownership

 A problem akin to the problem of deciding on the area of the IETF's
 competence arises when a protocol that is clearly in the IETF's scope
 is used both on and off the Internet - the premier example is of
 course the Internet Protocol itself.
 Sometimes the IETF defines standards that ultimately see the most use
 outside the global Internet.  The IETF, having defined the standard,
 will continue to provide the necessary administration of that
 protocol.
 Sometimes the IETF leverages standards that are defined and
 maintained by other organizations; we continue to work with those
 organizations on their standards and do not attempt to take them
 over.

5. Security Considerations

 Considering security is one of the core principles of sound network
 engineering for the Internet.  Apart from that, it's not relevant to
 this memo.

6. Acknowledgements

 This document is a result of many hours of debate, countless reviews,
 and limitless emails.  As such, any acknowledgements section is bound
 to be incomplete.
 Among the many who provided input were the current members of the
 IESG (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David
 Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott
 Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent
 IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as
 multiple IAB members, and many members from the community, including
 James Polk, John Klensin, Pekka Savola, Paul Hoffman, Eliot Lear,
 Jonne Soininen, Fred Baker, Dean Anderson, John Leslie, Susan Harris,
 and many others.  Special thanks go to Leslie Daigle, the IAB chair.

Author's Address

 Harald Tveit Alvestrand
 Cisco Systems
 Weidemanns vei 27
 Trondheim  7043
 NO
 EMail: harald@alvestrand.no

Alvestrand Best Current Practice [Page 6] RFC 3935 IETF Mission Statement October 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 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
 made any independent effort to identify any such rights.  Information
 on the IETF's procedures with respect to rights in IETF Documents can
 be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Alvestrand Best Current Practice [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp95.txt · Last modified: 2004/10/21 00:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki