idnits 2.17.1 draft-alvestrand-ietf-mission-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 376), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 29, 2004) is 7294 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Alvestrand 2 Internet-Draft Cisco Systems 3 Expires: October 28, 2004 April 29, 2004 5 A Mission Statement for the IETF 6 draft-alvestrand-ietf-mission-02 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3667. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 28, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This memo gives a mission statement for the IETF, tries to define the 39 terms used in the statement sufficiently to make the mission 40 statement understandable and useful, argues why the IETF needs a 41 mission statement, and tries to capture some of the debate that led 42 to this point. 44 1. Mission statement 46 The goal of the IETF is to make the Internet work better. 48 The mission of the IETF is to produce high quality, relevant 49 technical and engineering documents that influence the way people 50 design, use and manage the Internet in such a way as to make the 51 Internet work better. 52 These documents include protocol standards, best current practices 53 and informational documents of various kinds. 55 The IETF will pursue this mission in adherence to the following 56 cardinal principles: 58 Open process - any interested participant can participate in the 59 work, know what is being decided, and make his or her voice heard 60 on the issue. Part of this principle is our commitment to making 61 our documents, our WG mailing lists, our attendance lists and our 62 meeting minutes publicly available on the Internet. 64 Technical competence - the issues on which the IETF produces its 65 documents are issues where the IETF has the competence needed to 66 speak to them, and that the IETF is willing to listen to 67 technically competent input from any source. 68 Technical competence also means that we expect IETF output to be 69 designed to sound network engineering principles - this is also 70 often referred to as "engineering quality". 72 Volunteer Core - our participants and our leadership are people who 73 come to the IETF because they want to do work that furthers the 74 IETF's mission of "making the Internet work better". 76 Rough consensus and running code - We make standards based on the 77 combined engineering judgement of our participants and our 78 real-world experience in implementing and deploying our 79 specifications. 81 Protocol ownership - when the IETF takes ownership of a protocol or 82 function, it accepts the responsibility for all aspects of the 83 protocol, even though some aspects may rarely or never be seen on 84 the Internet. Conversely, when the IETF is not responsible for a 85 protocol or function, it does not attempt to exert control over 86 it, even though it may at times touch or affect the Internet. 88 2. Definition of terms 90 Misson: What an organization sets out to do. This is in contrast to 91 its goal (which is what it hopes to achieve by fulfilling its 92 mission), and to its activities (which is what specific actions it 93 takes to achieve its mission). 95 The Internet: A large, heterogenous collection of interconnected 96 systems that can be used for communication of many different types 97 between any interested parties connected to it. The term includes 98 both the "core Internet" (ISP networks) and "edge Internet" 99 (corporate and private networks, often connected via firewalls, 100 NAT boxes, application layer gateways and similar devices). The 101 Internet is a truly global network, reaching into just about every 102 country in the world. 103 The IETF community wants the Internet to succeed because we 104 believe that the existence of the Internet, and its influence on 105 economics, communication and education, will help us to build a 106 better human society. 108 Standard: As used here, the term describes a specification of a 109 protocol, system behaviour or procedure that has a unique 110 identifier, and where the IETF has agreed that "if you want to do 111 this thing, this is the description of how to do it". It does not 112 imply any attempt by the IETF to mandate its use, or any attempt 113 to police its usage - only that "if you say that you are doing 114 this according to this standard, do it this way". 115 The benefit of a standard to the Internet is in interoperability - 116 that multiple products implementing a standard are able to work 117 together in order to deliver valuable functions to the Internet's 118 users. 120 Participants: Individuals who participate in the process are the 121 fundamental unit of the IETF organization and the IETF's work. The 122 IETF has found that the process works best when focused around 123 people, rather than around organizations, companies, governments 124 or interest groups. That is not to say that these other entities 125 are uninteresting - but they are not what constitutes the IETF. 127 Quality: In this context, the ability to express ideas with enough 128 clarity that they can be understood in the same way by all people 129 building systems to conform to them, and the ability (and 130 willingness) to describe the properties of the system well enough 131 to understand important consequences of its design, and to ensure 132 that those consequences are beneficial to the Internet as a whole. 133 It also means that the specifications are designed with adherence 134 to sound network engineering principles, so that use for its 135 intended purpose is likely to be effective and not harmful to the 136 Internet as a whole. 138 Relevant: In this context, useful to some group of people who have to 139 make decisions that affect the Internet, including, but not 140 limited to, hardware and software implementors, network builders, 141 network operators and users of the Internet. Note that it does not 142 mean "correct" or "positive" - a report of an experiment that 143 failed, or a specification that clearly says why you should not 144 use it in a given situation, can be highly relevant - for deciding 145 what NOT to do. 146 A part of being relevant is being timely - very often, documents 147 delivered a year after core decisions have been taken are far less 148 useful than documents that are available to the decision-makers at 149 decision time. 151 3. The need for a mission statement 153 The IETF has to make decisions. And in some cases, people acting on 154 behalf of the IETF have to make decisions without consulting the 155 entire IETF first. 157 There are many reasons for this, including the near-impossibility of 158 getting an informed consensus opinion on a complex subject out of a 159 community of several thousand people in a short time. 161 Having a defined mission is one of the steps we can take in order to 162 evaluate alternatives: Does this help or hinder the mission, or is it 163 orthogonal to it? If there are limited resources, are there things 164 that they could be invested in that help the mission better? (Another 165 step is to choose leaders that we trust to exercise their good 166 judgment and do the right thing. But we're already trying to do 167 that.) 169 4. Issues with scoping the IETF's mission 171 4.1 The scope of the Internet 173 A very difficult issue in discussing the IETF's mission has been the 174 scope of the term "for the Internet". The Internet is used for many 175 things, many of which the IETF community has neither interest nor 176 competence in making standards for. 178 The Internet isn't value-neutral, and neither is the IETF. We want 179 the Internet to be useful for communities that share our commitment 180 to openness and fairness. We embrace technical concepts such as 181 decentralized control, edge-user empowerment and sharing of 182 resources, because those concepts resonate with the core values of 183 the IETF community. These concepts have little to do with the 184 technology that's possible, and much to do with the technology that 185 we choose to create. 187 At the same time, it is clear that many of the IETF-defined 188 technologies are useful not only for the Internet, but also for 189 networks that have no direct relation to the Internet itself. 191 In attempting to resolve the question of the IETF's scope, perhaps 192 the fairest balance is struck by this formulation: "protocols and 193 practices for which secure and scalable implementations are expected 194 to have wide deployment and interoperation on the Internet, or to 195 form part of the infrastructure of the Internet." 197 In addition to this constraint, we are also constrained by the 198 principle of competence: Where we do not have, and cannot gather, the 199 competence needed to make technically sound standards, we should not 200 attempt to take the leadership. 202 4.2 The balance between research, invention and adoption 204 The IETF has traditionally been a community for experimentation with 205 things that are not fully understood, standardization of protocols 206 for which some understanding has been reached, and publication of 207 (and refinement of) protocols originally specified outside the IETF 208 process. 210 All of these activities have in common that they produce documents - 211 but the documents should be judged by very different criteria when 212 the time to publish comes around, and it's not uncommon to see people 213 confused about what documents are in which category. 215 In deciding whether or not these activities should be done within the 216 IETF, one should not chiefly look at the type of activity, but the 217 potential benefit to the Internet - an experiment that yields 218 information about the fact that an approach is not viable might be of 219 greater benefit to the Internet than publishing a standard that is 220 technically competent, but only useful in a few special cases. 222 For research of an essentially unbounded nature, with unknown 223 probability of success, it may be more relevant to charter a research 224 group than a standards group. For activities with a bounded scope - 225 such as specifying several alternative protocols to the point where 226 experiments can identify the better one for standardization - the 227 IETF's working group mechanism may be an appropriate tool. 229 4.3 The balance between mission and procedures 231 The mission is intended to state what the IETF is trying to achieve. 232 There are many methods that can be chosen to achieve these outcomes - 233 for instance, the appeals procedure is defined so that we can detect 234 cases where our fundamental principles of technical competence and 235 open process has been violated; it is not itself a fundamental value. 237 Similarly, the question of what body in the IETF declares that a 238 document is ready for publication is entirely outside the mission 239 statement; we can imagine changing that without in any way impacting 240 what the IETF mission is - even though it may significantly impact 241 the ability to achieve that mission. 243 4.4 The reach of the Internet 245 The Internet is a global phenomenon. The people interested in its 246 evolution includes people from every culture under the sun and from 247 all walks of life. The IETF puts its emphasis on technical 248 competence, rough consensus and individual participation, and needs 249 to be open to competent input from any source. The IETF uses the 250 English language for its work is because of its utility for working 251 in a global context. 253 4.5 Protocol ownership 255 A problem akin to the problem of deciding on the area of the IETF's 256 competence arises when a protocol that is clearly in the IETF's scope 257 is used both on and off the Internet - the premier example is of 258 course the Internet Protocol itself. 260 Sometimes the IETF defines standards that are ultimately used mostly 261 for non-global IP-routing Internet. The IETF, having defined the 262 standard, will continue to provide the necessary administration of 263 that protocol. 265 Sometimes the IETF leverages standards that are defined and 266 maintained by other organizations; we continue to work with those 267 organizations on their standards and do not attempt to take them 268 over. 270 5. Security considerations 272 Considering security is one of the core principles of sound network 273 engineering for the Internet. Apart from that, it's not relevant to 274 this memo. 276 6. Acknowledgements 278 This document is a result of many hours of debate, countless reviews 279 and limitless emails. As such, any acknowledgements section is bound 280 to be incomplete. 282 Among the many who provided input were the current members of the 283 IESG (Alex Zinin, Allison Mankin, Bert Wijnen, Bill Fenner, David 284 Kessens, Jon Peterson, Margaret Wasserman, Russ Housley, Scott 285 Hollenbeck, Steve Bellovin, Ted Hardie, Thomas Narten) and recent 286 IESG members (Ned Freed, Randy Bush, Erik Nordmark), as well as 287 multiple IAB members, and many members from the community, including 288 James Polk, John Klensin, Pekka Savola, Paul Hoffman, Eliot Lear, 289 Jonne Soininen, Fred Baker, Dean Anderson, John Leslie, Susan Harris 290 and many others. Special thanks go to Leslie Daigle, the IAB chair. 292 Author's Address 294 Harald Tveit Alvestrand 295 Cisco Systems 296 Weidemanns vei 27 297 Trondheim 7043 298 NO 300 EMail: harald@alvestrand.no 302 Appendix A. Change log 304 This appendix is intended to be removed when this document is 305 published as an RFC. It gives a list of the important changes since 306 version -00, and the reason for them. 308 A.1 Changes from -00 to -01 310 The goal of the IETF was changed to "... make the Internet work 311 better" (add "better"). There's a reasonable chance that we can tell 312 the difference between the Internet working "better" and "worse" - 313 and we shouldn't limit ourselves to a goal of "just barely working". 315 The operating principle of protocol ownership was added, and a 316 discussion about it was added as section 4.5. 318 Modified the "reach of the Internet" to make it clear that both sides 319 of a firewall are considered to be part of the Internet 321 Section about the global Internet added as section 4.4 323 Modified definition of "participant" to make it obvious that 324 participants are people 326 Added acknowledgements section 328 Added this appendix 330 A.2 Changes from -01 to -02 332 Tightened up the text on various points 334 Reworded point on "volunteer core" 336 The appendix giving other proposed mission statements was removed 338 Intellectual Property Statement 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the IETF's procedures with respect to rights in IETF Documents can 347 be found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at 360 ietf-ipr@ietf.org. 362 Disclaimer of Validity 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 367 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 368 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Copyright Statement 374 Copyright (C) The Internet Society (2004). This document is subject 375 to the rights, licenses and restrictions contained in BCP 78, and 376 except as set forth therein, the authors retain all their rights. 378 Acknowledgment 380 Funding for the RFC Editor function is currently provided by the 381 Internet Society.