Network Working Group J. Klensin
Request for Comments: 3933 S. Dawkins
BCP: 93 November 2004
Category: Best Current Practice
Network Working Group J. Klensin
Request for Comments: 3933 S. Dawkins
BCP: 93 November 2004
Category: Best Current Practice
A Model for IETF Process Experiments
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).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight.
IETF在过去十年中以两种方式之一设计了流程变更：IESG发布，有时基于非正式协议，社区参与和意识有限，以及正式使用用于协议规范的相同机制。第一种机械装置通常被证明太轻，第二种太重。
This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted.
本文件规定了对IETF过程进行更改的系统的中间方法，该方法在很大程度上依赖于“提出并执行实验，评估实验，然后根据运行经验建立永久性程序”模型，而不是之前尝试的模型。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background and Specification . . . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative Reference. . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background and Specification . . . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative Reference. . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted.
本文件规定了对IETF过程进行更改的系统的中间方法，该方法在很大程度上依赖于“提出并执行实验，评估实验，然后根据运行经验建立永久性程序”模型，而不是之前尝试的模型。
Since the 1992 changes documented in [RFC1396], the IETF has used two mechanisms for process changes.
自[RFC1396]中记录的1992年变更以来，IETF使用了两种过程变更机制。
1. IESG has adopted a number of procedural changes on its own initiative and documented them informally, utilizing the wide discretion implicitly granted to them by [RFC2026]. This provided a lightweight mechanism for change, but the lightness came with a cost: There was sometimes too little alignment with the larger IETF community.
1. IESG主动采取了一些程序变更，并非正式地记录了这些变更，利用了[RFC2026]隐含授予的广泛自由裁量权。这为改变提供了一个轻量级机制，但轻量级带来了成本：有时与更大的IETF社区的一致性太少。
2. The IETF has also used the [RFC2026] protocol standards development process to identify a community of interest, hold one or more BoFs, charter a working group, discuss proposed changes within the community, develop IETF-wide consensus on the changes, and publish (usually) Best Current Practice specifications. This provided full community involvement but also came with a cost in flexibility. The IETF does not change its formal processes often (the IPR clarifications in [RFC3667, RFC3668] are the first documented changes to [RFC2026] since 1996), and the community is understandably reluctant to permanently alter or extend formally adopted processes with untried new procedures.
2. IETF还利用[RFC2026]协议标准制定过程确定利益共同体，召开一个或多个BOF会议，成立工作组，在共同体内讨论提议的变更，就变更达成IETF范围内的共识，并发布（通常）当前最佳实践规范。这提供了充分的社区参与，但也带来了灵活性方面的成本。IETF不会经常更改其正式流程（RFC3667、RFC3668中的知识产权澄清是自1996年以来对[RFC2026]的第一次有文件记录的更改），可以理解，社区不愿意永久更改或扩展未经试验的新程序正式采用的流程。
There is a middle ground between BCP process updates and informal agreements. This document specifies regularizing and formalizing the informal IESG mechanisms listed in 1 above as a means of moving forward with procedural changes that might prove valuable.
BCP流程更新和非正式协议之间有一个中间地带。本文件规定了上述1中所列非正式IESG机制的规范化和正式化，作为推进可能证明有价值的程序变更的一种手段。
The mechanisms outlined here add to the IESG's range of tools for dealing with process issues on an ongoing basis. They supplement the existing tools rather than attempting to replace them with a single "magic bullet". The choice of using the procedure outlined in this document or other mechanisms available to the IESG and the community -- present or future -- remains in the IESG's hands. If the IESG does not exercise this discretion wisely, this document provides no additional remedies.
这里概述的机制增加了IESG的一系列工具，用于持续处理流程问题。它们是对现有工具的补充，而不是试图用一个“魔弹”来取代它们。使用本文件中概述的程序或IESG和社区（现在或将来）可用的其他机制的选择权仍在IESG手中。如果IESG不明智地行使这一自由裁量权，本文件不提供额外的补救措施。
Some have interpreted the current procedures as giving the IESG all of the capabilities outlined here. If this were true, this document only encourages the IESG to use this type of mechanism more frequently in preference to less streamlined ones, and to more explicitly document its actions and decisions.
一些人将当前程序解释为赋予IESG此处概述的所有功能。如果这是真的，本文件只鼓励IESG更频繁地使用此类机制，而不是简化的机制，并更明确地记录其行动和决定。
This specification permits and encourages the IESG to adopt and institute "process experiments" by using the following procedure:
本规范允许并鼓励IESG通过使用以下程序采用并开展“工艺试验”：
1. An I-D is written describing the proposed new or altered procedure. A statement of the problem expected to be resolved is desirable but not required (the intent is to keep the firm requirements for such an experiment as lightweight as possible). Similarly, specific experimental or evaluative criteria, although highly desirable, are not required -- for some of the process changes we anticipate, having the IESG reach a conclusion at the end of the sunset period that the community generally believes things to be better (or worse) will be both adequate and sufficient. The I-D must state an explicit "sunset" timeout typically, not to exceed one year after adoption.
1. I-D用于描述拟定的新程序或变更程序。对预期要解决的问题的陈述是可取的，但不是必需的（其目的是使此类试验的严格要求尽可能轻）。类似地，虽然非常可取，但不需要具体的实验或评估标准——对于我们预期的一些过程变化，让IESG在日落期结束时得出结论，即社区普遍认为情况会更好（或更糟）就足够了。I-D必须明确说明“日落”超时时间，通常不超过采用后一年。
2. If the IESG believes the proposal is plausible and plausibly useful, a four-week IETF Last Call is initiated. The IESG can institute whatever procedures it wishes to make this determination and to avoid denial of service attacks from large numbers of spurious or unimportant proposals. In particular, they might institute a procedure requiring a number of endorsements, or endorsements of a particular type, before the IESG considers the proposal. The IESG is, however, expected to understand that procedures or review processes that act as a mechanism for significant delays do not fall within the intent of this specification.
2. 如果IESG认为该建议合理且有用，则发起为期四周的IETF最后一次呼叫。IESG可以制定任何程序来做出这一决定，并避免来自大量虚假或不重要提议的拒绝服务攻击。特别是，在IESG考虑该提案之前，他们可能会制定一个程序，要求进行多次背书或特定类型的背书。然而，IESG应理解，作为重大延误机制的程序或审查过程不属于本规范的意图。
3. At the conclusion of the Last Call, the IESG reevaluates the plausibility and appropriateness of the proposal. If they conclude that the proposed experiment is appropriate, a second I-D is generated (either by the IESG or by the original authors with IESG advice) that cleans up any definitional issues exposed in the Last Call and that explicitly identifies and responds to issues raised during the Last Call.
3. 在最后一次通话结束时，IESG重新评估提案的合理性和适当性。如果他们认为建议的实验是合适的，则会生成第二个ID（由IESG或由原始作者提供IESG建议），该ID会清理上次通话中暴露的任何定义问题，并明确识别和响应上次通话中提出的问题。
4. The document and experiment are then announced, the experiment is begun, and the document is forwarded for publication as an Experimental RFC.
4. 然后宣布文档和实验，开始实验，并将文档作为实验RFC转发发布。
The IESG is explicitly authorized to use this mechanism (based on Experimental RFCs) to gain experience with proposed changes to BCP specifications. There is no requirement to approve a BCP specification for the experiment until the experiment is found to have value.
IESG被明确授权使用该机制（基于实验性RFC），以获得BCP规范拟议变更的经验。在发现实验有价值之前，无需批准实验的BCP规范。
The IESG could, of course, reach a "bad idea" conclusion at any stage in this process and abandon the experiment. It might recommend publication of the experimental document, with a discussion of why it was a bad idea, but is not required to do so. The list above is deliberately vague about where the I-Ds come from: a WG, design team, individual contribution, editing group, or other mechanism could be used in the first and/or third steps, but no specific mechanisms are required, and the IESG is explicitly permitted to generate such proposals internally.
当然，IESG可以在这个过程的任何阶段得出“坏主意”的结论，并放弃实验。它可能会建议出版实验性文件，并讨论为什么这是一个坏主意，但并不要求这样做。上面的列表故意含糊其辞地说明了I-D的来源：第一步和/或第三步可以使用工作组、设计团队、个人贡献、编辑组或其他机制，但不需要特定机制，并且明确允许IESG在内部生成此类提案。
In each case, the IESG's decision to go forward (or not) with a procedural experiment, or the steps leading up to one, is expected to reflect their judgment of the existence of rough consensus in the community. That judgment may be appealed using the usual procedures, but the IESG and the community are reminded that an experimental attempt to try something for a fixed period is typically a better engineering approach than extended philosophical discussion without any experience to back it up.
在每一种情况下，IESG决定进行（或不进行）程序性实验，或进行程序性实验的步骤，预计将反映出他们对社区存在粗略共识的判断。可以使用通常的程序对该判决提出上诉，但IESG和社区被提醒，在固定时间内尝试某种东西的实验性尝试通常是一种比没有任何经验支持的扩展哲学讨论更好的工程方法。
Nothing above is to be construed as requiring an IETF-wide attempt for any given process experiment. A proposal for such an experiment may specify selected areas, selected working groups, working groups meeting some specific criteria (e.g., those created after a particular time or of a specified age), or be specific in other ways.
以上任何内容均不得解释为要求在IETF范围内尝试任何给定的工艺试验。此类实验的提案可以指定选定的领域、选定的工作组、满足某些特定标准的工作组（例如，在特定时间或特定年龄后创建的工作组），或者以其他方式指定。
At or before the end of the "sunset" timeout, the IESG would either revise (or cause to be revised) the document into a BCP RFC or the procedure would expire and, presumably, not be tried again unless something changed radically. A document describing why the experiment had succeeded or failed would be desirable but could not, realistically, be a requirement. If the procedure went to BCP, the BCP would reflect what we would call "operational experience" in the real world.
在“日落”超时结束时或之前，IESG会将文件修改（或导致修改）为BCP RFC，或者该程序将过期，除非发生根本性变化，否则可能不会再次尝试。一份描述实验成功或失败原因的文件是可取的，但现实情况下，这不是一项要求。如果程序转到BCP，BCP将反映我们在现实世界中所谓的“操作经验”。
We note that, if the procedures the IESG has adopted (and the procedural exceptions it has made) over the last decade are legitimate, then the IESG has the authority to institute the changes specified here by bootstrapping this process.
我们注意到，如果IESG在过去十年中所采用的程序（以及它所制定的程序性例外）是合法的，那么IESG有权通过引导这一过程来实施此处规定的变更。
This document specifies a mechanism for evolving IETF procedures. It does not raise or consider any protocol-specific security issues. In considering experimental changes to procedures, the IESG should, of course, exercise due caution that such changes not reduce the quality of security review and consideration for protocols or, at least, that the process experiment proposals contain early detection and correction mechanisms should quality deterioration occur.
本文件规定了发展IETF程序的机制。它不提出或考虑任何协议特定的安全问题。当然，在考虑对程序进行实验性更改时，IESG应谨慎行事，确保此类更改不会降低协议的安全审查和考虑的质量，或者至少在出现质量恶化时，过程实验建议包含早期检测和纠正机制。
The first revision of this document benefited significantly from suggestions and comments from Avri Doria, Margaret Wasserman, and Harald Alvestrand, and from discussions with the General Area Directorate and at its open meeting during IETF 59. After mailing list discussion, considerable explanatory material was removed to a separate document for the current version.
本文件的第一次修订得益于来自Avri Doria、Margaret Wasserman和Harald Alvestrand的建议和评论，以及与总区域理事会的讨论和IETF 59期间的公开会议。在讨论邮件列表之后，相当多的解释性材料被删除到当前版本的单独文件中。
The first version of this document was posted as an Internet Draft on February 7, 2004.
本文件的第一个版本于2004年2月7日作为互联网草稿发布。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC1396] Crocker, S., "The Process for Organization of Internet Standards Working Group (POISED)", RFC 1396, January 1993.
[RFC1396]Crocker，S.，“互联网标准工作组的组织过程（平衡）”，RFC 1396，1993年1月。
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004.
[RFC3667]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3667，2004年2月。
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004.
[RFC3668]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3668，2004年2月。
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥市322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Spencer Dawkins 1547 Rivercrest Blvd. Allen, TX 75002 USA
斯宾塞·道金斯河冠大道1547号。美国德克萨斯州艾伦75002
Phone: +1 469 330 3616
EMail: spencer@mcsr-labs.org
Phone: +1 469 330 3616
EMail: spencer@mcsr-labs.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。