Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7221 Juniper Networks
Category: Informational D. Crocker, Ed.
ISSN: 2070-1721 Brandenburg InternetWorking
April 2014
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7221 Juniper Networks
Category: Informational D. Crocker, Ed.
ISSN: 2070-1721 Brandenburg InternetWorking
April 2014
Handling of Internet-Drafts by IETF Working Groups
IETF工作组处理互联网草案
Abstract
摘要
The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.
IETF工作组的生产性输出是工作组章程规定的文件。当一个工作组准备编写一份特定的文件时，最常见的机制是以“通过”一份现有文件为起点。工作组通过并进一步发展的文件是基于不同成熟度的初始投入。工作组初稿可能是已经广泛使用的文件，也可能是完全由工作组创建的空白页，也可能代表两者之间的任何成熟程度。本文档讨论了工作组通常如何处理其发布目标的正式文档。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7221.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7221.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. What Is a WG Draft? ........................................3
1.2. Working Group Authority and Consensus ......................4
1.3. Questions Considered in This Document ......................5
2. Adoption Sequence ...............................................6
2.1. Common Steps ...............................................6
2.2. Criteria for Adoption ......................................6
3. Authors/Editors .................................................8
4. Document History and Stability ..................................8
5. Some Issues for Consideration ..................................10
5.1. Individual I-Ds under WG Care .............................10
5.2. WG Drafts Can Become Individual Drafts ....................11
5.3. Competing Drafts ..........................................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. Informative References .........................................13
1. Introduction ....................................................2
1.1. What Is a WG Draft? ........................................3
1.2. Working Group Authority and Consensus ......................4
1.3. Questions Considered in This Document ......................5
2. Adoption Sequence ...............................................6
2.1. Common Steps ...............................................6
2.2. Criteria for Adoption ......................................6
3. Authors/Editors .................................................8
4. Document History and Stability ..................................8
5. Some Issues for Consideration ..................................10
5.1. Individual I-Ds under WG Care .............................10
5.2. WG Drafts Can Become Individual Drafts ....................11
5.3. Competing Drafts ..........................................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. Informative References .........................................13
The productive output of an IETF working group (WG) is documents, as mandated by the working group's charter. Working groups develop these documents based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. The discussion applies only to the IETF and does not cover IRTF groups, where practices vary widely.
IETF工作组（WG）的生产性输出是工作组章程规定的文件。工作组根据不同成熟度的初始输入编制这些文件。工作组初稿可能是已经广泛使用的文件，也可能是完全由工作组创建的空白页，也可能代表两者之间的任何成熟程度。本文档讨论了工作组通常如何处理其发布目标的正式文档。讨论仅适用于IETF，不包括实践差异很大的IRTF组。
Within the general constraints of formal IETF process and the specific constraints of a working group's charter, there can be considerable freedom in the adoption and development of drafts. As with most IETF activities, the ultimate arbiter of such choices is working group agreement, within the constraints of its charter. As with most working group management, this agreement might be explicit or implicit, depending upon the efficiencies that the group deems appropriate.
在正式IETF流程的一般约束和工作组章程的具体约束范围内，草案的通过和制定具有相当大的自由度。与大多数IETF活动一样，在其章程的约束下，此类选择的最终仲裁者是工作组协议。与大多数工作组管理层一样，该协议可能是明确的，也可能是隐含的，这取决于工作组认为适当的效率。
NOTE: This document is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible.
注：本文件为非规范性文件。它的意思是作为一般做法的指南，而不是作为什么是允许的正式定义。
Working group drafts are documents that are subject to IETF working group revision control, with advancement for publication as an RFC requiring rough consensus in the working group and then in the broader IETF. Creation or adoption of a draft by a working group -- as well as substantive changes to the document -- need to represent working group rough consensus.
工作组草案是受IETF工作组修订控制的文件，作为RFC出版需要工作组和更广泛的IETF达成初步共识。工作组起草或通过草案以及对文件进行实质性修改需要代表工作组的大致共识。
Documents under development in the IETF community are distributed as Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this mechanism for producing their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. The common convention for identifying an I-D formally under the ownership of a working group is by the inclusion of "ietf" in the second field of the I-D filename and the working group name in the third field, per Section 7 of [ID-Guidelines]. That is:
IETF社区正在开发的文档作为互联网草稿（I-D）[RFC2026][ID信息]分发。根据[RFC2418]第7.2节和[Tao]第6.3节，工作组使用该机制产生其官方输出。根据[ID指南]第7节，识别正式归工作组所有的I-D的通用惯例是在I-D文件名的第二个字段中包含“ietf”，在第三个字段中包含工作组名称。即:
draft-ietf-<wgname>-...
ietf草案-<wgname>-。。。
In contrast, individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author/editor's last name, in the style of:
相比之下，个别划界案是在一个工作组之外制定和执行的草案，尽管如下文所述，一个工作组可能会选择稍后通过该草案。任何人都可以随时自由创建个人提交。此类文件通常通过使用作者/编辑的姓氏来区分，其风格如下：
draft-<lastname>-...
草稿-<lastname>-。。。
(Also see Section 5.1 for an elaboration on this naming.)
（有关此命名的详细信息，请参见第5.1节。）
Responsibility for direct revision of a working group I-D is assigned to its editors and authors. See Section 3 for discussion about their selection and role.
直接修订工作组I-D的责任分配给其编辑和作者。有关其选择和作用的讨论，请参见第3节。
A premise of the IETF is that, within a working group, it is the working group itself that has final authority over the content of its documents, within the constraints of the working group's charter. No individual has special authority for the content. The Chairs assign document authors/editors and can formulate design teams, but the content of working group documents is always, ultimately, subject to working group approval. Approval is described in terms of the IETF's "rough consensus" construct, which is the prime example of the IETF's preference for pragmatics over niceties. Unanimous agreement is always desirable, but more approximate (rough) agreement will suffice, as long as it is clear and strong.
IETF的一个前提是，在工作组内，在工作组章程的约束范围内，工作组本身对其文件的内容拥有最终权限。没有任何个人对该内容拥有特殊权限。主席指定文件作者/编辑，并可以组建设计团队，但工作组文件的内容最终始终取决于工作组的批准。批准是根据IETF的“粗略共识”结构来描述的，这是IETF偏好语用而非细节的主要例子。一致同意总是可取的，但更近似（粗略）的同意就足够了，只要它清晰有力。
Other than for selection of document authors/editors, as discussed in Section 3, working group decision-making about document management is subject to normal IETF rough consensus rules. Useful descriptions of this process for a working group are in Section 3.3 of [RFC2418] and Section 4.2 of [Tao]. Discussion of the nature of rough consensus can be found in [Consensus].
如第3节所述，除选择文件作者/编辑外，工作组关于文件管理的决策应遵守IETF的一般共识规则。[RFC2418]第3.3节和[Tao]第4.2节对工作组的这一过程进行了有用的描述。关于粗略共识性质的讨论见[共识]。
In terms of the IETF's formal rough consensus processes, the working group explicitly develops, modifies, reviews, and approves document content, according to overt rough consensus. For difficult topics and/or difficult working group dynamics, this laborious process really is essential. Its diligence validates progress at each step along the way. However, working groups often handle simpler matters more simply, such as allowing a Chair to assert the likely agreement and then merely call for objections. Ultimately, the mode of working group decision-making is determined by the comfort and engagement of the working group with the way the decisions are being made.
就IETF的正式粗略共识过程而言，工作组根据公开的粗略共识明确制定、修改、审查和批准文件内容。对于困难的主题和/或困难的工作组动态，这一艰苦的过程确实至关重要。它的勤奋验证了前进的每一步。然而，工作组往往更简单地处理一些简单的问题，例如允许主席声明可能达成的协议，然后仅仅要求提出反对意见。最终，工作组的决策模式取决于工作组对决策方式的舒适度和参与度。
At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the Chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode. Of course, the benefit in the mode is efficiency, but its risk is failure to retain or verify actual consensus among the working group participants. When a working group is operating in the mode of active, direct author/ editor content development, an easy validation method is simply to have Chairs query the working group when a new document version appears, asking for comments and concerns.
有时，文档作者/编辑似乎对内容拥有相当大的权限，但这（仅仅）是为了提高效率。也就是说，只要工作组对这种模式感到满意，主席可以允许作者和编辑继续进行默示（默认）工作组协议。当然，这种模式的好处在于效率，但其风险在于无法保持或核实工作组参与者之间的实际共识。当工作组在主动、直接作者/编辑内容开发模式下运行时，一种简单的验证方法就是让主席在出现新文档版本时查询工作组，征求意见和关注点。
In general, when it is not completely obvious what the opinion of the working group is, Working Group Chairs can poll the working group to find out. As with any other consensus question, the form in which it is asked can make a difference. In particular, a general 'yes/no' question often is not as helpful as asking supporters and detractors of a draft -- or of the decision under consideration -- to provide their reasons, not merely their preferences. In effect, this treats the matter of consensus as an ongoing discussion. Ideally, the discussion can produce changes in the document or in participant views, or both.
一般来说，当工作组的意见不完全明确时，工作组主席可以对工作组进行民意调查。与任何其他协商一致的问题一样，提出问题的形式可能会有所不同。特别是，一般性的“是/否”问题通常不如要求草案的支持者和批评者——或正在审议的决定的支持者和批评者——提供他们的理由，而不仅仅是他们的偏好。实际上，这将协商一致的问题视为正在进行的讨论。理想情况下，讨论可以在文档或参与者视图中产生更改，或两者都产生更改。
The purpose of this document is to discuss the criteria and sequence typically followed when adopting and developing a formal IETF working group document. Therefore, this document considers the following questions that are particularly relevant to Working Group Chairs who are charged with running the process:
本文件旨在讨论采用和制定正式IETF工作组文件时通常遵循的标准和顺序。因此，本文件考虑了与负责运行流程的工作组主席特别相关的以下问题：
* How do Working Group Chairs decide which drafts to adopt and when?
* 工作组主席如何决定何时通过哪些草案？
* Is it necessary to poll the working group explicitly, and what does a working group poll look like?
* 是否有必要明确投票给工作组？工作组投票是什么样的？
* How do Working Group Chairs make the decision?
* 工作组主席如何作出决定？
* What are the process steps the working group will choose to use, for an I-D to become a WG I-D?
* 工作组将选择使用哪些流程步骤，使I-D成为工作组I-D？
* Are there any special cases?
* 有什么特殊情况吗？
* Can a document be created as a WG I-D from scratch?
* 文档是否可以从头创建为工作组ID？
* How can competing drafts be handled?
* 如何处理竞争性草案？
* Can an individual I-D be under the care of a WG?
* 个人身份证是否可以由工作组保管？
* Can a WG I-D become an individual I-D?
* 工作组身份证明是否可以成为个人身份证明？
When there is interest in adopting a document as a new working group document, the Chairs often:
当有兴趣通过一份文件作为新的工作组文件时，主席们往往：
1. Remind current draft owners that they are transferring change control for the document to the IETF. (This is a particularly significant point for a document covered by proprietary interests, because it typically entails a negotiation between the current owners and the IETF, including a formal agreement.)
1. 提醒当前草稿所有者，他们正在将文档的更改控制转移到IETF。（这对于专有权益所涵盖的文档来说尤其重要，因为它通常需要当前所有者和IETF之间的协商，包括正式协议。）
2. Check for known IPR that needs to be disclosed, using some technique like those described in [RFC6702].
2. 使用[RFC6702]中描述的技术检查需要披露的已知知识产权。
3. Obtain working group rough consensus.
3. 获得工作组的大致共识。
4. Choose document editors.
4. 选择文档编辑器。
5. Instruct authors to post the WG I-D.
5. 指导作者发布工作组ID。
6. Approve posting [Approval].
6. 批准发布[批准]。
7. Ensure that the non-working group version of the draft is marked as being replaced by this working group version.
7. 确保草案的非工作组版本标记为被此工作组版本替换。
8. Encourage everyone to enjoy the ensuing working group discussion...
8. 鼓励大家享受接下来的工作组讨论。。。
No formal specification for working group 'adoption' of a draft exists; the current document is meant to provide a description of common activities for this, but again note that it is not normative.
不存在工作组“通过”草案的正式规范；本文件旨在对这方面的常见活动进行说明，但请再次注意，本文件并非规范性文件。
There are some basic considerations when deciding to adopt a draft:
在决定通过草案时，有一些基本考虑：
* Is there a charter milestone that explicitly calls for such a document?
* 是否有明确要求此类文件的宪章里程碑？
* Is the topic of the I-D within scope for the working group?
* I-D的主题是否在工作组的范围内？
* Is the purpose of the draft sufficiently clear?
* 草案的目的是否足够明确？
* Does the document provide an acceptable platform for continued effort by the working group?
* 该文件是否为工作组的持续努力提供了一个可接受的平台？
* What are the process or technical objections to adoption of the draft?
* 通过草案的过程或技术异议是什么？
* Is the draft likely to be completed in a timely manner?
* 草案是否可能及时完成？
* Does the intended status of the document seem reasonable to the working group?
* 工作组认为该文件的预期状态合理吗？
* If not already in scope, is a simple modification to the charter feasible and warranted?
* 如果还不在范围之内，那么对《宪章》进行简单的修改是否可行？
* Does the draft carry known intellectual property rights issues?
* 草案是否包含已知的知识产权问题？
* Is there strong working group support for working on the draft?
* 工作组是否大力支持起草该草案？
Adoption has some basic pragmatics:
收养有一些基本的语用学：
Rough consensus: Working group agreement to adopt is not required to be unanimous [RFC2418].
大致共识：不要求工作组一致同意通过[RFC2418]。
Initial, not final: The writing quality is not required to be "ready for publication", although writing quality can be a problem and does need explicit attention; although not mandatory, it is good practice to check whether a new working group draft passes [IDNITS].
初始，而非最终：写作质量不需要“准备出版”，尽管写作质量可能是一个问题，需要明确关注；虽然不是强制性的，但检查新工作组草案是否通过[IDNITS]是一种良好的做法。
Adoption, not approval: The document is not required to already contain a complete and/or sufficient solution, although of course this can be helpful. Equally, adoption by a working group does not guarantee publication of the document as an RFC.
采用，而不是批准：文档不需要已经包含完整和/或充分的解决方案，尽管这当然会有所帮助。同样，工作组的通过并不保证该文件作为RFC出版。
Group, not Chairs: Concerning the draft, the position of the Working Group Chairs has no special authority, except to assess working group consensus.
工作组，而不是主席：关于草案，工作组主席的立场没有特别权力，只是评估工作组的共识。
REMINDER: Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter. Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content. So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly.
提醒：一旦工作组通过草案，该文件归工作组所有，可在IETF流程和工作组章程的范围内，根据工作组的决定进行更改。如果没有明确的协议，通过一份文件并不自动意味着工作组已同意其所有内容。因此，工作组（或其章程）可能明确规定保留、删除或修改部分或全部草案内容、技术细节等的依据。然而，在没有这些限制的情况下，值得让通过过程包括一个子过程，即收集工作组对现有草案的关注，并明确指出这些关注。
Document authors/editors are chosen by the Working Group Chairs. Document editors are described in Section 6.3 of [RFC2418]. Authors and editors are described in [RFC-Auth-Ed].
文件作者/编辑由工作组主席选择。[RFC2418]第6.3节介绍了文档编辑器。作者和编辑在[RFC Auth Ed]中进行了描述。
NOTE: In this document, the terms 'author' and 'editor' are meant interchangeably. Within the IETF, the distinction between an 'author' and an 'editor' is, at best, subjective. A simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas authors tend to create the detail, subject to working group approval. That is, one role is more active with the content, and the other is more passive. It is a responsibility of the Working Group Chairs to ensure that document authors make modifications in accord with working group rough consensus. Authors/editors are solely chosen by the Chairs -- although the views of the working group should be considered -- and are subject to replacement for a variety of reasons, as the Chairs see fit.
注：在本文件中，术语“作者”和“编辑”的含义是可互换的。在IETF中，“作者”和“编辑”之间的区别充其量是主观的。一个过于简单的经验法则是，编辑倾向于采用合并工作组细节的机制，而作者倾向于创建细节，但需经工作组批准。也就是说，一个角色对内容更主动，另一个角色更被动。工作组主席有责任确保文件作者根据工作组的初步共识进行修改。作者/编辑完全由主席选择——尽管应考虑工作组的意见——并可根据主席认为合适的各种原因更换。
For existing documents that are being adopted by a working group, there is a special challenge in the selection of document editors. Because the document has already had editors, the question "Are the same people appropriate for continuing the task?" is asked. Sometimes the answer is yes, but this is not automatic. The process within an IETF working group can be quite different from the process that created previous versions. This well might make it appropriate to select one or more new editors, either as additions to the editor team or as primary pen-holders (effectively reclassifying the previous team as coauthors).
对于一个工作组正在通过的现有文件，在选择文件编辑方面有一个特殊的挑战。因为文档已经有了编辑，所以会问“相同的人适合继续执行任务吗？”。有时答案是肯定的，但这不是自动的。IETF工作组内的过程可能与创建以前版本的过程大不相同。这可能会使选择一个或多个新编辑变得合适，可以作为编辑团队的补充，也可以作为主要的笔杆（有效地将以前的团队重新归类为合著者）。
If the original editors are to continue in their role, the Chairs might want to ensure that the editors understand IETF working group process; it is likely to be quite different from the process that developed earlier versions of the document. If additional or new editors are assigned, the transition can be discussed, including its reasons; this is best done as soon as possible.
如果最初的编辑要继续履行其职责，主席可能希望确保编辑了解IETF工作组流程；这可能与开发文档早期版本的过程有很大不同。如果指派了额外的或新的编辑，可以讨论过渡，包括其原因；这最好尽快完成。
Working group charters sometimes specify an initial set of existing documents to use as a basis of the working group's activities. That 'basis' can vary considerably, from simple input to working group discussion, all the way to an advanced draft adopted by the working group and subject only to minimal changes. The role of a document should be explicitly stated in the charter.
工作组章程有时规定了作为工作组活动基础的一套初始现有文件。这种“基础”可能有很大的不同，从简单的投入到工作组的讨论，一直到工作组通过的一份高级草案，而且只需稍作修改。文件的作用应在宪章中明确规定。
Within the scope of its charter, a working group is free to create new documents. It is not required that all drafts start as the effort of an individual. Of course, the criteria for brand new documents are likely to be the same as for those imported into the working group, with the additional and obvious requirement that the Working Group Chairs will need to appoint authors/editors before any work can progress. Note that, from time to time, a working group will form a design team to produce the first version of a working group draft. Design teams are discussed in Section 6.5 of [RFC2418].
在其章程范围内，工作组可以自由创建新文件。不要求所有草稿都由个人完成。当然，全新文件的标准可能与导入工作组的标准相同，还有一个明显的附加要求，即工作组主席需要在任何工作进展之前任命作者/编辑。请注意，工作组将不时组建设计团队，以编制工作组草案的第一个版本。[RFC2418]第6.5节讨论了设计团队。
Work that is brought to the IETF has different levels of completeness and maturity, and different timings for having achieved those levels. When the IETF charters a group and includes existing material, the charter can cast the role of that material in very different ways. It can treat it as:
提交给IETF的工作具有不同的完整性和成熟度级别，以及达到这些级别的不同时间。当IETF包租一个小组并包含现有材料时，包租可以用非常不同的方式来塑造该材料的角色。它可以将其视为：
* no more than a set of ideas, to be used or ignored;
* 不超过一套想法，可以使用或忽略；
* a basic design, with all of the actual details still fluid;
* 基本设计，所有实际细节仍然流畅；
* a rough draft, subject to extensive revision;
* 粗略的草案，需要进行广泛的修订；
* a solid specification that merely needs review, refinement, and maybe enhancement;
* 一个可靠的规范，只需要审查、完善，甚至可能需要改进；
* a deployed technology that is best served by trying to protect its installed base, but with some tolerance for changes that affect interoperability;
* 一种已部署的技术，最好是通过保护其安装基础，但对影响互操作性的更改有一定的容忍度；
* a deployed technology for which protecting the installed base is essential, including retention of core interoperability.
* 对已部署的技术而言，保护已安装的基础至关重要，包括保留核心互操作性。
These suggest a wide range of possible constraints on working group effort. Technology is brought to the IETF at different points of maturity along its life cycle, and the nature of the technology can have widely varying utility in developing an Internet standard.
这表明工作组的努力可能受到各种各样的限制。在IETF的生命周期中，技术在不同的成熟点被引入IETF，并且该技术的性质在开发互联网标准时具有广泛的不同用途。
When technology is brand new, with at most some prototypes done as proofs of concept, then significant changes to the specification will not necessarily add much to the development and deployment costs. However, when the technology is already part of a mature and extensive operational deployment, any changes that are incompatible are likely to be problematic for that market and can hinder adoption of the changes overall. For example, immediately after the development investment is made -- and especially when there has been considerable initial deployment but there is still room for quite a bit more -- the installed and potential base might not take kindly to disruptive standards work that undermines their recent investment.
当技术是全新的，最多做一些原型作为概念证明时，那么对规范的重大更改不一定会增加很多开发和部署成本。然而，当该技术已经是成熟且广泛的操作部署的一部分时，任何不兼容的更改都可能对该市场产生问题，并且可能会阻碍整体更改的采用。例如，在进行开发投资之后——特别是在已经进行了大量的初始部署但仍有相当多的空间的情况下——已安装的和潜在的基础可能不会接受破坏性的标准工作，这会破坏他们最近的投资。
Conversely, even a deployed technology with a solid base might be inappropriate to deploy at Internet scale, and while a document specifying such a technology might serve as a good starting point on which to base a new specification, undermining of the deployed base might be completely appropriate.
相反，即使是具有坚实基础的已部署技术也可能不适合在互联网规模上部署，虽然指定此类技术的文档可以作为新规范的良好起点，但破坏已部署的基础可能是完全合适的。
In reflecting upon the basis for adopting an existing draft and the way it will be used by the working group, it is important to consider the document's place in its life cycle, the needs of any installed base, and the applicability of the draft's technology, when deciding on the constraints to impose on document development. It will all depend on the constraints of the charter and the analysis of the working group.
在考虑采用现有草案和工作组使用的方式的基础上，重要的是考虑文件在其生命周期中的位置、任何已安装的基础的需要以及草案技术的适用性，在决定施加在文件开发上的约束时。这一切将取决于《宪章》的限制和工作组的分析。
Sometimes, a working group facilitates a draft but does not own it or formally adopt it. These are "individual" drafts [Individual].
有时，工作组为草案提供便利，但并不拥有或正式通过草案。这些是“个人”草案[个人]。
As noted in Section 1.1 and reinforced in [ID-Guidelines], the convention for identifying an I-D formally under the ownership of a working group is by following the naming convention:
如第1.1节所述，并在[ID指南]中得到加强，识别工作组正式拥有的I-D的公约遵循命名公约：
draft-ietf-<wgname>-...
ietf草案-<wgname>-。。。
By contrast, documents that are still under the control of their authors are known as "individual" I-Ds. When these documents are intended for consideration by a specific working group, the convention is that the document uses the naming convention as follows, where the second element is the last name of one of the principal authors.
相比之下，仍由作者控制的文档称为“个人”ID。当这些文件拟由某一特定工作组审议时，惯例是该文件使用如下命名惯例，其中第二个要素是主要作者之一的姓氏。
draft-<lastname>-<wgname>...
草稿-<lastname>-<wgname>。。。
Having the working group name following the personal name allows tools to associate these drafts with the working group, even though the filename identifies them as the work of individuals.
将工作组名称置于个人名称之后，允许工具将这些草稿与工作组关联，即使文件名将其标识为个人作品。
The working group can choose to apply any of its normal, internal working group process management mechanisms to an individual I-D. However, matters of ownership, working group final approval, and the like are all subject to negotiation amongst the document authors, working group, and Area Directors.
工作组可以选择将其任何正常的内部工作组流程管理机制应用于个人身份证。但是，所有权、工作组最终批准等事项均需经过文件作者、工作组和区域主管之间的协商。
This is a rare situation, and Working Group Chairs can be assured that the Area Directors will want to understand why the document could not be adopted and owned by the working group.
这是一种罕见的情况，可以向工作组主席保证，区域主任会想了解为什么该文件不能被工作组采纳和拥有。
A working group is not obligated to retain documents it has adopted. Sometimes working group efforts conclude that a draft is no longer appropriate for working group effort. If a working group drops a draft, then anyone is permitted to pursue it as an Individual or Independent Submission, subject to the document's existing copyright constraints.
工作组没有义务保留其通过的文件。有时，工作组的努力得出结论，草案不再适合工作组的努力。如果一个工作组放弃了一份草案，那么任何人都可以将其作为个人或独立提交的文件进行提交，但必须遵守该文件现有的版权限制。
Engineering for interesting topics often produces competing, interesting proposals. The reasons can be technical aesthetics, engineering trade-offs, architectural differences, company economics, and the like. Although it is far more comfortable to entertain only one proposal, a working group is free to pursue more than one. Often this is necessary until a clear preference develops. Sometimes, multiple versions are formally published, absent consensus among the alternatives.
针对有趣主题的工程设计通常会产生相互竞争、有趣的建议。原因可能是技术美学、工程权衡、架构差异、公司经济等等。虽然只考虑一项提案要舒服得多，但一个工作组可以自由地提出不止一项提案。通常这是必要的，直到形成明确的偏好。有时，正式发布多个版本，但备选方案之间缺乏共识。
It is appealing to ask authors of competing proposals to find a way to merge their work. Where it makes sense to do this, it can produce a single, strong specification. The detailed discussions to merge are often better held in a design team than amidst the dynamics of an open working group mailing list. The working group has ultimate authority over any decisions, but it is not required that it be involved in all the discussions.
要求竞争提案的作者找到一种合并他们作品的方法是很有吸引力的。在这样做有意义的地方，它可以产生一个单一的、强大的规范。合并的详细讨论通常最好在设计团队中进行，而不是在开放工作组邮件列表的动态中进行。工作组对任何决定拥有最终权力，但不要求它参与所有讨论。
On the other hand, some differences cannot be resolved, and attempting a merge can produce a weaker result. An example of this problem of conflicting design goals is discussed in [Heli-Sub], noting:
另一方面，一些差异无法解决，尝试合并可能会产生较弱的结果。[Heli Sub]中讨论了设计目标冲突问题的一个例子，注意：
"Helicopters are great, and so are submarines. The problem is that if you try to build one vehicle to perform two fundamentally different jobs, you're going to get a vehicle that does neither job well."
“直升机很棒，潜艇也很棒。问题是，如果你试图制造一辆车来完成两项根本不同的工作，你会得到一辆两项工作都不好的车。”
Various management efforts can facilitate the handling of competing proposals. Some examples include:
各种管理工作可促进处理竞争性提案。一些例子包括：
* Developing a requirements document that is independent of specific proposals; this can highlight features that are deemed essential and distinguish them from features that are of secondary importance, and can facilitate a discussion about features without reference to specific proposals.
* 制定独立于具体提案的需求文件；这可以突出显示被认为是必要的特征，并将其与次要特征区分开来，并且可以在不参考具体提案的情况下促进对特征的讨论。
* Developing a comparison table of the proposals; this can aid understanding of their differences.
* 编制提案对照表；这有助于理解他们之间的差异。
* Discussing the relative importance and effects of having one proposal, versus multiple; this can focus people's efforts at compromise and encourage a willingness to choose a single proposal.
* 讨论一个提案相对于多个提案的相对重要性和影响；这可以将人们的努力集中在妥协上，并鼓励人们愿意选择一个方案。
The problem of competing drafts can be particularly painful when it arises in either of two circumstances:
当出现以下两种情况之一时，竞争性草案的问题可能特别令人痛苦：
* If a second proposal appears as a new draft, just as the Chairs were ready to poll the working group on adoption of the draft containing the first proposal, then the authors of the first proposal could feel affronted. It does not follow that the second draft was written to be difficult or derail the first: it might even include better ideas. So it is best not to disregard it. However, automatically asking the authors to merge their work will not necessarily produce a more solid solution and will not guarantee faster progress. This situation will be a judgement call in each case, and it might help to ask the working group for their opinion: shall the working group adopt one document as a starting point and fold in the ideas from the second under the control of consensus, or shall the working group wait until the authors of both documents have reached agreement?
* 如果第二项提案以新草案的形式出现，正如主席们准备就通过载有第一项提案的草案向工作组投票一样，那么第一项提案的作者可能会感到受到冒犯。这并不是说第二稿写得很难，也不是说第一稿脱轨：它甚至可能包含更好的想法。因此，最好不要忽视它。然而，自动要求作者合并他们的工作并不一定会产生更坚实的解决方案，也不能保证更快的进展。在每一种情况下，这种情况都将是一种判断，请工作组发表意见可能会有所帮助：工作组是以一份文件为起点，在协商一致的基础上采纳第二份文件的观点，还是等到两份文件的作者达成一致意见后再作决定？
* If the working group has already adopted an I-D on a specific topic, the posting of a new individual I-D on the same topic could be seen as an attack on the working group processes or decisions. However, posting an I-D is often a good way to put new ideas into concrete form, for public consideration and discussion. The Working Group Chairs will want to encourage the working group to consider the new proposal. Shall it be adopted and entirely replace the current working group draft? Shall the new ideas be incorporated into the work of the working group through the normal editorial process? Shall the working group adopt a second competing solution? Or shall the new draft be rejected and not adopted by the working group?
* 如果工作组已经就某一特定主题采用了个人识别码，那么就同一主题发布新的个人识别码可能被视为对工作组流程或决定的攻击。然而，发布ID通常是将新想法转化为具体形式的好方法，供公众考虑和讨论。工作组主席希望鼓励工作组考虑这项新建议。是否应予以通过并完全取代目前的工作组草案？这些新想法是否应通过正常的编辑程序纳入工作组的工作？工作组是否应通过第二个相互竞争的解决方案？或者，新的草案是否应被否决而不被工作组通过？
Beyond the credibility of the IETF, this document raises no security concerns.
除了IETF的可信度之外，本文件不涉及安全问题。
This document was developed from an IETF tutorial given by A. Farrel at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson contributed useful comments.
本文件是根据A.Farrel在IETF工作组主席午餐[Farrel主席]上提供的IETF教程编写的。安德森发表了有益的评论。
[Approval] IETF, "IETF Internet-Draft Initial Version Approval Tracker", (IETF Datatracker), <https://datatracker.ietf.org/ cgi-bin/wg/wg_init_rev_approval.cgi>.
[批准]IETF，“IETF互联网初稿批准跟踪程序”（IETF数据跟踪程序）<https://datatracker.ietf.org/ cgi bin/wg/wg_init_rev_approval.cgi>。
[Consensus] Resnick, P., "On Consensus and Humming in the IETF", Work in Progress, April 2014.
[共识]Resnick，P.“关于IETF中的共识和哼唱”，进展中的工作，2014年4月。
[Farrel-Chairs] Farrel, A., "What is a Working Group ID (and when to adopt one)", (IETF 78 WG chairs lunch Material), July 2010, <http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.
[Farrel主席]Farrel，A.，“什么是工作组ID（以及何时采用）”，（IETF 78工作组主席午餐材料），2010年7月<http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.
[Heli-Sub] Rose, M., "On Helicopters and Submarines", ACM Queue - Instant Messaging, Vol. 1, Issue 8, Page 10, <http://dl.acm.org/ft_gateway.cfm?id=966726>.
[Heli Sub]Rose，M.，“直升机和潜艇上”，ACM队列-即时消息，第1卷，第8期，第10页<http://dl.acm.org/ft_gateway.cfm?id=966726>.
[ID-Guidelines] Housley, R., Ed., "Guidelines to Authors of Internet-Drafts", December 2010, <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[ID指南]Housley，R.，Ed.“互联网草稿作者指南”，2010年12月<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", May 2009, <https://www.ietf.org/id-info/checklist.html>.
[ID信息]Wijnen，B.，Ed.，“为RFC出版物提交的互联网草案（ID）清单”，2009年5月<https://www.ietf.org/id-info/checklist.html>.
[IDNITS] IETF, "IDNITS Tool", 2013, <https://tools.ietf.org/tools/idnits/>.
[IDNITS]IETF，“IDNITS工具”，2013年<https://tools.ietf.org/tools/idnits/>.
[Individual] IESG, "Guidance on Area Director Sponsoring of Documents", March 2007, <http://www.ietf.org/iesg/statement/ ad-sponsoring-docs.html>.
[个人]IESG，“关于区域主任赞助文件的指导”，2007年3月<http://www.ietf.org/iesg/statement/ 广告赞助文档.html>。
[RFC-Auth-Ed] RFC Editor, "RFC Editorial Guidelines and Procedures -- Author Overload", 2014, <http://www.rfc-editor.org/policy.html#policy.authlist>.
[RFC授权]RFC编辑，“RFC编辑指南和程序——作者过载”，2014年<http://www.rfc-editor.org/policy.html#policy.authlist>.
[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月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418]Bradner，S.，“IETF工作组指南和程序”，BCP 25，RFC 2418，1998年9月。
[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, August 2012.
[RFC6702]Polk，T.和P.Saint Andre，“促进遵守知识产权（IPR）披露规则”，RFC 67022012年8月。
[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", 2012, <http://www.ietf.org/tao.html>.
[Tao]Hoffman，P.，Ed.“IETF之道-互联网工程任务组新手指南”，2012年<http://www.ietf.org/tao.html>.
Authors' Addresses
作者地址
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
戴夫·克罗克（编辑）美国加利福尼亚州桑尼维尔云杉大道675号勃兰登堡互联网络，邮编94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net