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).
AbstractThis 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.
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.
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.
(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.)
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.
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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.