| < 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/ | ||||