summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3935.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3935.txt')
-rw-r--r--doc/rfc/rfc3935.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3935.txt b/doc/rfc/rfc3935.txt
new file mode 100644
index 0000000..74837e2
--- /dev/null
+++ b/doc/rfc/rfc3935.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+