Network Working Group S. Bradner
Request for Comments: 2418 Editor
Obsoletes: 1603 Harvard University
BCP: 25 September 1998
Category: Best Current Practice
Network Working Group S. Bradner
Request for Comments: 2418 Editor
Obsoletes: 1603 Harvard University
BCP: 25 September 1998
Category: Best Current Practice
IETF Working Group Guidelines and Procedures
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors.
互联网工程任务组（IETF）负责制定和审查作为互联网标准的规范。IETF活动分为工作组（WG）。本文件描述了IETF工作组的组建和运作指南和程序。它还描述了IETF参与者工作组和互联网工程指导小组（IESG）之间的正式关系，以及IETF参与者的基本职责，包括工作组主席、工作组参与者和IETF区域主管。
Table of Contents
目录
Abstract ......................................................... 1
1. Introduction .................................................. 2
1.1. IETF approach to standardization .......................... 4
1.2. Roles within a Working Group .............................. 4
2. Working group formation ....................................... 4
2.1. Criteria for formation .................................... 4
2.2. Charter ................................................... 6
2.3. Charter review & approval ................................. 8
2.4. Birds of a feather (BOF) .................................. 9
3. Working Group Operation ....................................... 10
3.1. Session planning .......................................... 11
3.2. Session venue ............................................. 11
3.3. Session management ........................................ 13
3.4. Contention and appeals .................................... 15
Abstract ......................................................... 1
1. Introduction .................................................. 2
1.1. IETF approach to standardization .......................... 4
1.2. Roles within a Working Group .............................. 4
2. Working group formation ....................................... 4
2.1. Criteria for formation .................................... 4
2.2. Charter ................................................... 6
2.3. Charter review & approval ................................. 8
2.4. Birds of a feather (BOF) .................................. 9
3. Working Group Operation ....................................... 10
3.1. Session planning .......................................... 11
3.2. Session venue ............................................. 11
3.3. Session management ........................................ 13
3.4. Contention and appeals .................................... 15
4. Working Group Termination ..................................... 15
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
6.1. WG Chair .................................................. 16
6.2. WG Secretary .............................................. 18
6.3. Document Editor ........................................... 18
6.4. WG Facilitator ............................................ 18
6.5. Design teams .............................................. 19
6.6. Working Group Consultant .................................. 19
6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
7.1. Session documents ......................................... 19
7.2. Internet-Drafts (I-D) ..................................... 19
7.3. Request For Comments (RFC) ................................ 20
7.4. Working Group Last-Call ................................... 20
7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix: Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26
4. Working Group Termination ..................................... 15
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
6.1. WG Chair .................................................. 16
6.2. WG Secretary .............................................. 18
6.3. Document Editor ........................................... 18
6.4. WG Facilitator ............................................ 18
6.5. Design teams .............................................. 19
6.6. Working Group Consultant .................................. 19
6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
7.1. Session documents ......................................... 19
7.2. Internet-Drafts (I-D) ..................................... 19
7.3. Request For Comments (RFC) ................................ 20
7.4. Working Group Last-Call ................................... 20
7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix: Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26
The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated interconnected networks, which are not connected to the global Internet but use the Internet Standards. Internet Standards are developed in the Internet Engineering Task Force (IETF). This document defines guidelines and procedures for IETF working groups. The Internet Standards Process of the IETF is defined in [1]. The organizations involved in the IETF Standards Process are described in [2] as are the roles of specific individuals.
互联网是一种松散组织的自主互联网络国际协作，通过自愿遵守互联网标准定义的开放协议和程序，支持主机对主机的通信。还有许多孤立的互联网络，它们没有连接到全球互联网，而是使用互联网标准。互联网标准由互联网工程任务组（IETF）制定。本文件定义了IETF工作组的指南和程序。IETF的互联网标准过程定义见[1]。[2]中描述了参与IETF标准过程的组织以及特定个人的角色。
The IETF is a large, open community of network designers, operators, vendors, users, and researchers concerned with the Internet and the technology used on it. The primary activities of the IETF are performed by committees known as working groups. There are currently more than 100 working groups. (See the IETF web page for an up-to-date list of IETF Working Groups - http://www.ietf.org.) Working groups tend to have a narrow focus and a lifetime bounded by the completion of a specific set of tasks, although there are exceptions.
IETF是一个大型开放社区，由网络设计师、运营商、供应商、用户和研究人员组成，他们关注互联网及其所用技术。IETF的主要活动由称为工作组的委员会执行。目前有100多个工作组。（有关IETF工作组的最新列表，请参见IETF网页-http://www.ietf.org.)工作组往往关注的范围很窄，其一生都以完成一组特定的任务为界限，尽管也有例外。
For management purposes, the IETF working groups are collected together into areas, with each area having a separate focus. For example, the security area deals with the development of security-related technology. Each IETF area is managed by one or two Area Directors (ADs). There are currently 8 areas in the IETF but the number changes from time to time. (See the IETF web page for a list of the current areas, the Area Directors for each area, and a list of which working groups are assigned to each area.)
出于管理目的，IETF工作组被集中到各个区域，每个区域都有一个单独的重点。例如，安全领域涉及安全相关技术的发展。每个IETF区域由一个或两个区域主管（ADs）管理。IETF中目前有8个领域，但数量不时变化。（参见IETF网页，了解当前区域列表、每个区域的区域主管以及分配给每个区域的工作组列表。）
In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.
在许多地区，地区主任成立了一个咨询小组或董事会。这些成员包括IETF的经验丰富的成员和该地区代表的技术社区。每个小组的具体名称和角色细节因地区而异，但主要目的是这些小组协助地区总监，例如，审查该地区制定的规范。
The IETF area directors are selected by a nominating committee, which also selects an overall chair for the IETF. The nominations process is described in [3].
IETF区域主任由提名委员会选出，提名委员会还将为IETF选出一名总主席。提名过程如[3]所述。
The area directors sitting as a body, along with the IETF Chair, comprise the Internet Engineering Steering Group (IESG). The IETF Executive Director is an ex-officio participant of the IESG, as are the IAB Chair and a designated Internet Architecture Board (IAB) liaison. The IESG approves IETF Standards and approves the publication of other IETF documents. (See [1].)
区域总监与IETF主席共同组成互联网工程指导小组（IESG）。IETF执行董事是IESG的当然参与者，IAB主席和指定的互联网架构委员会（IAB）联络人也是IESG的当然参与者。IESG批准IETF标准，并批准其他IETF文件的发布。（见[1]。）
A small IETF Secretariat provides staff and administrative support for the operation of the IETF.
一个小型IETF秘书处为IETF的运行提供人员和行政支持。
There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations.
IETF没有正式成员资格。所有人都可以参加。这种参与可以通过在线贡献、参加面对面会议或两者兼而有之。互联网社区中有时间和兴趣的任何人都应参加IETF会议及其在线工作组讨论。参与是由个人技术贡献者，而不是由组织的正式代表。
This document defines procedures and guidelines for the formation and operation of working groups in the IETF. It defines the relations of working groups to other bodies within the IETF. The duties of working group Chairs and Area Directors with respect to the operation of the working group are also defined. When used in this document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [6]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this
本文件规定了IETF工作组的组建和运作程序和指南。它定义了工作组与IETF内其他机构的关系。还规定了工作组主席和区域主任在工作组运作方面的职责。本文件中使用的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中的说明进行解释。RFC 2119定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。这篇文章使用了相同的关键词
document to help smooth WG operation and reduce the chance for confusion about the processes.
文件有助于工作组顺利运作，减少对流程的混淆。
Familiarity with The Internet Standards Process [1] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.
熟悉互联网标准流程[1]对于全面理解本文件所述的理念、程序和指南至关重要。
The document, "Organizations Involved in the IETF Standards Process" [2] describes the roles of a number of individuals within a working group, including the working group chair and the document editor. These descriptions are expanded later in this document.
文件“参与IETF标准过程的组织”[2]描述了工作组中许多个人的角色，包括工作组主席和文件编辑。这些描述将在本文档后面部分展开。
IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended to be standards or recommendations. A working group may be established at the initiative of an Area Director or it may be initiated by an individual or group of individuals. Anyone interested in creating an IETF working group MUST obtain the advice and consent of the IETF Area Director(s) in whose area the working group would fall and MUST proceed through the formal steps detailed in this section.
IETF工作组（WG）是制定IETF规范和指南的主要机制，其中许多旨在成为标准或建议。工作组可以由区域主任发起成立，也可以由个人或个人团体发起成立。任何有兴趣创建IETF工作组的人必须获得IETF区域主管的建议和同意，工作组将归属于该区域，并且必须按照本节详细说明的正式步骤进行。
Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group is terminated. A working group may also be terminated for other reasons (see section 4). Alternatively, with the concurrence of the IESG, Area Director, the WG Chair, and the WG participants, the objectives or assignment of the working group may be extended by modifying the working group's charter through a rechartering process (see section 5).
创建工作组通常是为了解决特定的问题或产生一个或多个特定的可交付成果（指南、标准规范等）。工作组通常被认为是短命的。在完成其目标并实现其目标后，工作组终止。工作组也可因其他原因终止（见第4节）。或者，在IESG、区域总监、工作组主席和工作组参与者的同意下，工作组的目标或任务可以通过重新编制流程修改工作组章程来延长（见第5节）。
When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:
在确定是否成立一个工作组时，区域主任和IESG将考虑几个问题：
- Are the issues that the working group plans to address clear and relevant to the Internet community?
- 工作组计划解决的问题是否明确且与互联网社区相关？
- Are the goals specific and reasonably achievable, and achievable within a reasonable time frame?
- 目标是否具体且合理可实现，并且在合理的时间范围内可实现？
- What are the risks and urgency of the work, to determine the level of effort required?
- 为了确定所需的工作水平，工作的风险和紧迫性是什么？
- Do the working group's activities overlap with those of another working group? If so, it may still be appropriate to create the working group, but this question must be considered carefully by the Area Directors as subdividing efforts often dilutes the available technical expertise.
- 该工作组的活动是否与另一工作组的活动重叠？如果是这样，成立工作组可能仍然合适，但该问题必须由区域主任仔细考虑，因为细分工作往往会稀释现有的技术专长。
- Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Working groups require considerable effort, including management of the working group process, editing of working group documents, and contributing to the document text. IETF experience suggests that these roles typically cannot all be handled by one person; a minimum of four or five active participants in the management positions are typically required in addition to a minimum of one or two dozen people that will attend the working group meetings and contribute on the mailing list. NOTE: The interest must be broad enough that a working group would not be seen as merely the activity of a single vendor.
- IETF内部是否对工作组的主题有足够的兴趣，有足够的人愿意付出努力来产生预期的结果（例如，协议规范）？工作组需要付出相当大的努力，包括管理工作组流程、编辑工作组文件以及为文件文本做出贡献。IETF的经验表明，这些角色通常不能全部由一个人处理；除了参加工作组会议并在邮寄名单上做出贡献的至少一到二十人之外，通常还需要至少四到五名管理职位的积极参与者。注：利益必须足够广泛，使工作组不被视为仅仅是一个供应商的活动。
- Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group?
- IETF中是否有足够的专家参与工作组的主题，这些人是否有兴趣参与工作组的工作？
- Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means.
- 对于计划的工作，是否存在感兴趣的消费者（最终用户）群体？消费者的兴趣可以通过最终用户在IETF过程中的参与以及不太直接的方式来衡量。
- Does the IETF have a reasonable role to play in the determination of the technology? There are many Internet-related technologies that may be interesting to IETF members but in some cases the IETF may not be in a position to effect the course of the technology in the "real world". This can happen, for example, if the technology is being developed by another standards body or an industry consortium.
- IETF在确定技术时是否有合理的作用？IETF成员可能对许多与互联网相关的技术感兴趣，但在某些情况下，IETF可能无法影响“现实世界”中的技术进程。例如，如果该技术由另一个标准机构或行业联盟开发，则可能发生这种情况。
- Are all known intellectual property rights relevant to the proposed working group's efforts issues understood?
- 是否了解与拟议工作组工作相关的所有已知知识产权问题？
- Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants may be limited?
- 提议的工作计划是一项开放的IETF工作，还是试图在IETF参与者的输入效果可能有限的情况下“祝福”非IETF技术？
- Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere.
- 是否充分了解与拟议工作组将开展的主题相关的任何现有工作？这包括IETF和其他地方的工作。
- Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place?
- 工作组的目标是否与其他标准机构的已知工作重叠，如果重叠，是否有足够的联系？
Considering the above criteria, the Area Director(s), using his or her best judgement, will decide whether to pursue the formation of the group through the chartering process.
考虑到上述标准，区域总监将运用其最佳判断，决定是否通过租船流程组建集团。
The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks. A charter:
工作组的组建需要一份章程，该章程主要由潜在的工作组主席和相关的区域总监协商，尽管最终批准是由IESG根据互联网架构委员会（IAB）的建议做出的。章程是工作组和IETF之间签订的执行一系列任务的合同。宪章：
1. Lists relevant administrative information for the working group; 2. Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals; and 3. Enumerates a set of milestones together with time frames for their completion.
1. 列出工作组的相关管理信息；2.指定工作组的方向或目标，并说明为实现目标将采取的方法；三,。列举一组里程碑及其完成时间框架。
When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that an Area Director MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described below, to gage the level of support for a working group before submitting the charter to the IESG and IAB for approval.
当未来的主席、区域主任和IETF秘书处对章程的形式和内容感到满意时，章程就成为成立工作组的基础。请注意，在将章程提交给IESG和IAB批准之前，区域总监可能需要召开如下所述的探索性羽毛鸟（BOF）会议，以评估对工作组的支持程度。
Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group (see section 5). Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering specific "products".
章程可以定期重新谈判，以反映工作组的现状、组织或目标（见第5节）。因此，章程是IETF和工作组之间的合同，工作组承诺满足明确的里程碑和交付特定的“产品”。
Specifically, each charter consists of the following sections:
具体而言，每个章程由以下章节组成：
Working group name A working group name should be reasonably descriptive or identifiable. Additionally, the group shall define an acronym (maximum 8 printable ASCII characters) to reference the group in the IETF directories, mailing lists, and general documents.
工作组名称工作组名称应具有合理的描述性或可识别性。此外，集团应定义首字母缩略词（最多8个可打印ASCII字符），以在IETF目录、邮件列表和一般文件中引用集团。
Chair(s) The working group may have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Generally, a working group is limited to two chairs.
主席工作组可有一名或多名主席履行工作组的行政职能。应包括主席的电子邮件地址。一般来说，一个工作组限于两名主席。
Area and Area Director(s) The name of the IETF area with which the working group is affiliated and the name and electronic mail address of the associated Area Director(s).
区域和区域主管工作组所属IETF区域的名称以及相关区域主管的姓名和电子邮件地址。
Responsible Area Director The Area Director who acts as the primary IESG contact for the working group.
负责区域主管作为工作组主要IESG联系人的区域主管。
Mailing list An IETF working group MUST have a general Internet mailing list. Most of the work of an IETF working group will be conducted on the mailing list. The working group charter MUST include:
邮件列表IETF工作组必须有一个通用的Internet邮件列表。IETF工作组的大部分工作将在邮件列表上进行。工作组章程必须包括：
1. The address to which a participant sends a subscription request and the procedures to follow when subscribing,
1. 参与者发送订阅请求的地址以及订阅时应遵循的程序，
2. The address to which a participant sends submissions and special procedures, if any, and
2. 参与者提交意见和特殊程序（如有）的地址，以及
3. The location of the mailing list archive. A message archive MUST be maintained in a public place which can be accessed via FTP or via the web.
3. 邮件列表存档的位置。邮件存档必须保存在公共场所，可通过FTP或web访问。
As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address "wg_acronym-archive@lists.ietf.org" (where "wg_acronym" is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat.
作为对社区的服务，IETF秘书处为工作组邮件列表管理邮件列表档案。为了利用这项服务，工作组邮件列表必须包括地址“wg_”的首字母缩写-archive@lists.ietf.org“（其中“wg_首字母缩略词”是工作组的首字母缩略词），以便将所有邮件列表信息的副本记录在秘书处的档案中。这些档案位于ftp://ftp.ietf.org/ietf-mail-archive. 为了稳健性，工作组应在秘书处保存的档案之外另外保存一份档案。
Description of working group The focus and intent of the group shall be set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph can be used as an overview of the working group's
工作组说明应简要说明工作组的重点和意图。通过单独阅读本节，个人应该能够确定该小组是否与他们自己的工作相关。第一段必须简要概述工作组计划的问题领域、基础、目标和方法。本段可作为工作组报告的概述
effort.
气力
To facilitate evaluation of the intended work and to provide on-going guidance to the working group, the charter must describe the problem being solved and should discuss objectives and expected impact with respect to:
为了促进对预期工作的评估并向工作组提供持续指导，章程必须描述正在解决的问题，并应讨论以下方面的目标和预期影响：
- Architecture - Operations - Security - Network management - Scaling - Transition (where applicable)
- 架构-操作-安全-网络管理-扩展-转换（如适用）
Goals and milestones The working group charter MUST establish a timetable for specific work items. While this may be renegotiated over time, the list of milestones and dates facilitates the Area Director's tracking of working group progress and status, and it is indispensable to potential participants identifying the critical moments for input. Milestones shall consist of deliverables that can be qualified as showing specific achievement; e.g., "Internet-Draft finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. This milestone list is expected to be updated periodically (see section 5).
目标和里程碑工作组章程必须为具体工作项目制定时间表。虽然这可能会随着时间的推移而重新协商，但里程碑和日期清单有助于区域主任跟踪工作组的进展和状态，对于潜在参与者确定关键时刻以供投入是必不可少的。里程碑应包括可证明具体成就的可交付成果；e、 例如，“网络草稿完成”可以，但“通过电子邮件讨论”不行。每3-6个月指定一次里程碑是很有帮助的，这样可以很容易地衡量进度。该里程碑列表预计将定期更新（见第5节）。
An example of a WG charter is included as Appendix A.
附录a中包含了工作组章程的一个示例。
Proposed working groups often comprise technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design. To facilitate working group efforts, an Area Director may assign a Consultant from among the ranks of senior IETF participants. (Consultants are described in section 6.) At the discretion of the Area Director, approval of a new WG may be withheld in the absence of sufficient consultant resources.
提议的工作组通常由技术能力强的参与者组成，他们不熟悉互联网体系结构或IETF过程的历史。不幸的是，这可能导致工作组就糟糕的设计达成良好的共识。为促进工作组的工作，区域主任可从IETF高级参与者中指派一名顾问。（第6节对顾问进行了说明。）在缺乏足够顾问资源的情况下，区域总监可自行决定拒绝批准新工作组。
Once the Area Director (and the Area Directorate, as the Area Director deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the IESG. After a review period of at least a week the proposed charter is posted to the IETF-announce mailing list as a public notice that the formation of the working group is being considered. At the same time the proposed charter is also posted to the "new-work" mailing
一旦区域总监（以及区域总监认为合适的区域董事会）批准了工作组章程，该章程将提交给IAB审查和IESG批准。在至少一周的审查期后，提议的章程被张贴到IETF公告邮寄名单上，作为正在考虑成立工作组的公告。同时，拟议的章程也张贴在“新工作”邮件上
list. This mailing list has been created to let qualified representatives from other standards organizations know about pending IETF working groups. After another review period lasting at least a week the IESG MAY approve the charter as-is, it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group
列表创建此邮件列表是为了让其他标准组织的合格代表了解待定的IETF工作组。在另一个至少持续一周的审查期后，IESG可按原样批准章程，也可要求修改章程，或拒绝批准工作组的章程
If the IESG approves the formation of the working group it remands the approved charter to the IETF Secretariat who records and enters the information into the IETF tracking database. The working group is announced to the IETF-announce a by the IETF Secretariat.
如果IESG批准成立工作组，则将批准的章程发回IETF秘书处，由其记录信息并将其输入IETF跟踪数据库。工作组由IETF秘书处向IETF发布公告。
Often it is not clear whether an issue merits the formation of a working group. To facilitate exploration of the issues the IETF offers the possibility of a Birds of a Feather (BOF) session, as well as the early formation of an email list for preliminary discussion. In addition, a BOF may serve as a forum for a single presentation or discussion, without any intent to form a working group.
通常不清楚某个问题是否值得成立一个工作组。为了促进对这些问题的探索，IETF提供了一个羽毛鸟（BOF）会议的可能性，以及早期形成初步讨论的电子邮件列表。此外，BOF可以作为一个论坛进行单一的介绍或讨论，而不打算成立一个工作组。
A BOF is a session at an IETF meeting which permits "market research" and technical "brainstorming". Any individual may request permission to hold a BOF on a subject. The request MUST be filed with a relevant Area Director who must approve a BOF before it can be scheduled. The person who requests the BOF may be asked to serve as Chair of the BOF.
BOF是IETF会议上的一次会议，允许“市场研究”和技术“头脑风暴”。任何个人均可申请就某一主题举办BOF。必须向相关区域主管提交申请，该主管必须在安排BOF之前批准BOF。申请BOF的人员可能被要求担任BOF主席。
The Chair of the BOF is also responsible for providing a report on the outcome of the BOF. If the Area Director approves, the BOF is then scheduled by submitting a request to agenda@ietf.org with copies to the Area Director(s). A BOF description and agenda are required before a BOF can be scheduled.
BOF主席还负责提供一份关于BOF结果的报告。如果区域总监批准，则BOF将通过向agenda@ietf.org向区域主管提交副本。在安排BOF之前，需要BOF说明和议程。
Available time for BOFs is limited, and BOFs are held at the discretion of the ADs for an area. The AD(s) may require additional assurances before authorizing a BOF. For example,
BOF的可用时间是有限的，并且BOF由ADs决定是否为某一区域举行。在授权BOF之前，AD可能需要额外的保证。例如
- The Area Director MAY require the establishment of an open email list prior to authorizing a BOF. This permits initial exchanges and sharing of framework, vocabulary and approaches, in order to make the time spent in the BOF more productive.
- 在授权BOF之前，区域总监可要求建立公开电子邮件列表。这允许初步交流和分享框架、词汇和方法，以使在BOF中花费的时间更有成效。
- The Area Director MAY require that a BOF be held, prior to establishing a working group (see section 2.2).
- 在成立工作组之前，区域总监可要求召开BOF（见第2.2节）。
- The Area Director MAY require that there be a draft of the WG charter prior to holding a BOF.
- 在举行BOF之前，区域总监可能要求有工作组章程草案。
- The Area Director MAY require that a BOF not be held until an Internet-Draft describing the proposed technology has been published so it can be used as a basis for discussion in the BOF.
- 区域总监可要求在互联网上发布描述拟议技术的草案之前，不得举行BOF，以便将其用作BOF讨论的基础。
In general, a BOF on a particular topic is held only once (ONE slot at one IETF Plenary meeting). Under unusual circumstances Area Directors may, at their discretion, allow a BOF to meet for a second time. BOFs are not permitted to meet three times. Note that all other things being equal, WGs will be given priority for meeting space over BOFs. Also, occasionally BOFs may be held for other purposes than to discuss formation of a working group.
一般来说，一个特定主题的BOF只举行一次（一次IETF全体会议的一个时段）。在特殊情况下，区域董事可自行决定允许BOF举行第二次会议。BOF不得召开三次会议。请注意，在所有其他条件相同的情况下，工作组的会议空间优先于工作组。此外，除讨论成立工作组外，偶尔也会召开BOF会议。
Usually the outcome of a BOF will be one of the following:
通常，BOF的结果如下所示：
- There was enough interest and focus in the subject to warrant the formation of a WG;
- 对该主题有足够的兴趣和关注，足以保证成立工作组；
- While there was a reasonable level of interest expressed in the BOF some other criteria for working group formation was not met (see section 2.1).
- 虽然在BOF中表达了合理程度的兴趣，但未满足工作组组建的其他一些标准（见第2.1节）。
- The discussion came to a fruitful conclusion, with results to be written down and published, however there is no need to establish a WG; or
- 讨论得出了富有成果的结论，结果有待记录和公布，但没有必要设立工作组；或
- There was not enough interest in the subject to warrant the formation of a WG.
- 对该主题的兴趣不足，无法保证成立工作组。
The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus". WG participants should specifically note the requirements for disclosure of conflicts of interest in [2].
IETF有公开、公平参与和全面考虑技术替代方案的基本要求。在这些限制条件下，工作组是自主的，每个工作组决定其自身运作的大部分细节，如会议参与、达成闭幕等。运作的核心规则是通过工作组“粗略共识”达成接受或同意。工作组参与者应特别注意在[2]中披露利益冲突的要求。
A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair(s) to manage the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group's goals and objectives.
随着时间的推移，会出现一些程序性问题，工作组主席的职责是管理工作组的进程，同时牢记工作组的总体目标是在实现工作组的目标和目的方面取得进展，达成大致共识。
There are few hard and fast rules on organizing or conducting working group activities, but a set of guidelines and practices has evolved over time that have proven successful. These are listed here, with
关于组织或开展工作组活动，几乎没有硬性规定，但随着时间的推移，一套指导方针和实践已被证明是成功的。这些都列在这里，带有
actual choices typically determined by the working group participants and the Chair(s).
实际选择通常由工作组参与者和主席决定。
For coordinated, structured WG interactions, the Chair(s) MUST publish a draft agenda well in advance of the actual session. The agenda should contain at least:
对于协调的、结构化的工作组互动，主席必须在实际会议之前公布议程草案。议程应至少包括：
- The items for discussion; - The estimated time necessary per item; and - A clear indication of what documents the participants will need to read before the session in order to be well prepared.
- 供讨论的项目每个项目所需的估计时间；以及-明确指出与会者在会议前需要阅读哪些文件才能做好准备。
Publication of the working group agenda shall include sending a copy of the agenda to the working group mailing list and to agenda@ietf.org.
工作组议程的公布应包括向工作组邮寄名单和agenda@ietf.org.
All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. IETF Plenary meetings are the primary venue for these face-to-face working group sessions, and it is common (though not required) that active "interim" face-to-face meetings, telephone conferences, or video conferences may also be held. Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings.
工作组的所有行动应在公开论坛上进行，并鼓励广泛参与。工作组将通过电子邮件分发名单开展大部分业务，但可能会定期开会讨论和审查任务状态和进度，解决具体问题并指导未来的活动。IETF全体会议是这些面对面工作组会议的主要场所，通常（尽管不是必需的）也可以举行积极的“临时”面对面会议、电话会议或视频会议。临时会议须遵守适用于其他工作组会议的关于事先通知、报告、公开参与和程序的相同规则。
All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@ietf.org
所有工作组会议（包括IETF会议以外的会议）均应通过提供会议记录的方式进行报告。这些会议记录应包括会议议程、讨论记录（包括做出的任何决定）以及与会者名单。工作组主席负责确保编写和分发会议纪要，尽管实际任务可能由工作组主席指定的人员执行。会议记录应以可打印的ASCII文本提交，以便在IETF会议记录中发布，并张贴在IETF目录中，并发送至：minutes@ietf.org
Each working group will determine the balance of email and face-to-face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group
每个工作组将确定电子邮件和面对面会议的平衡，以实现其里程碑。电子邮件允许最广泛的参与；面对面的会议往往能够更好地集中精力，因此能够更有效地在工作组核心成员之间达成共识
participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list.
参与者。在确定余额时，工作组必须确保其流程不会将仅通过电子邮件发送的参与者的贡献排除在外。在面对面会议期间就邮件列表上未讨论的主题或问题达成的决定，或与之前达成的邮件列表共识有显著差异的主题或问题达成的决定，必须在邮件列表上进行审查。
IETF Meetings If a WG needs a session at an IETF meeting, the Chair must apply for time-slots as soon as the first announcement of that IETF meeting is made by the IETF Secretariat to the WG-chairs list. Session time is a scarce resource at IETF meetings, so placing requests early will facilitate schedule coordination for WGs requiring the same set of experts.
IETF会议如果工作组需要在IETF会议上举行会议，主席必须在IETF秘书处向工作组主席名单首次宣布IETF会议后立即申请时间段。在IETF会议上，会议时间是一种稀缺资源，因此尽早提出请求将有助于协调需要同一组专家的工作组的日程安排。
The application for a WG session at an IETF meeting MUST be made to the IETF Secretariat at the address agenda@ietf.org. Some Area Directors may want to coordinate WG sessions in their area and request that time slots be coordinated through them. If this is the case it will be noted in the IETF meeting announcement. A WG scheduling request MUST contain:
在IETF会议上召开工作组会议的申请必须提交给IETF秘书处，地址为agenda@ietf.org. 一些区域主管可能希望协调其区域内的工作组会议，并要求通过他们协调时间段。如果是这种情况，将在IETF会议公告中注明。工作组计划请求必须包含：
- The working group name and full title; - The amount of time requested; - The rough outline of the WG agenda that is expected to be covered; - The estimated number of people that will attend the WG session; - Related WGs that should not be scheduled for the same time slot(s); and - Optionally a request can be added for the WG session to be transmitted over the Internet in audio and video.
- 工作组名称和全称；-请求的时间量；-预期将涵盖的工作组议程的大致轮廓；-预计将出席工作组会议的人数；-不应安排在同一时间段的相关工作组；和-可选地，可以添加一个请求，以便在互联网上以音频和视频的形式传输工作组会话。
NOTE: While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress. When acceptable to the WG, the Chair may call for restricted participation (but not restricted attendance!) at IETF working group sessions for the purpose of achieving progress. The Working Group Chair then has the authority to refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material, or who, in the opinion of the Chair is disrupting the WG process. The Chair should consult with the Area Director(s) if the individual persists in disruptive behavior.
注：虽然公开讨论和贡献对工作组的成功至关重要，但主席负责确保取得进展。在工作组接受的情况下，主席可要求限制参与IETF工作组会议（但不限于出席！），以取得进展。然后，工作组主席有权拒绝向未做好准备或以其他方式涵盖不适当材料，或主席认为正在干扰工作组进程的任何个人发言。如果该个人坚持破坏性行为，主席应咨询区域主管。
On-line It can be quite useful to conduct email exchanges in the same manner as a face-to-face session, with published schedule and agenda, as well as on-going summarization and consensus polling.
在网上，以与面对面的会议相同的方式进行电子邮件交流是非常有用的，可以公布时间表和议程，以及持续的总结和共识投票。
Many working group participants hold that mailing list discussion is the best place to consider and resolve issues and make decisions. The choice of operational style is made by the working group itself. It is important to note, however, that Internet email discussion is possible for a much wider base of interested persons than is attendance at IETF meetings, due to the time and expense required to attend.
许多工作组的参与者认为邮件列表讨论是考虑和解决问题和做出决定的最佳场所。业务方式的选择由工作组自己决定。然而，需要注意的是，由于参加IETF会议所需的时间和费用，与参加IETF会议相比，互联网电子邮件讨论可能会有更广泛的利益相关者。
As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair should attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair must involve the Area Director in the issue. As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG.
与面对面会议一样，偶尔一个或多个个人可能会参与邮件列表上的行为，从而干扰工作组的进度。在这些情况下，主席应通过直接与冒犯者沟通，而不是在公开邮件列表上，试图阻止这种行为。如果该行为持续存在，则主席必须让区域主管参与该问题。作为最后手段，在发出明确警告后，经IESG批准，区域总监可要求邮件列表维护者阻止违规个人向邮件列表投递邮件。（如果邮件列表软件允许这种类型的操作。）即使这样做，也不能阻止个人接收发送到列表的邮件。可以考虑其他邮件列表控制方法，但必须得到广告部和IESG的批准。
Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached.
工作组通过“粗略的共识”过程作出决定。IETF共识并不要求所有参与者都同意，尽管这当然是首选。一般而言，应以工作组的主导意见为准。（然而，必须注意的是，“支配地位”不是根据数量或持续性来确定的，而是更普遍意义上的一致性。）协商一致可以通过举手、哼唱或工作组同意的任何其他方式来确定（当然是通过大致协商一致）。请注意，51%的工作组不符合“粗略共识”的条件，99%的工作组优于粗略共识。由主席决定是否达成了大致的共识。
It can be particularly challenging to gauge the level of consensus on a mailing list. There are two different cases where a working group may be trying to understand the level of consensus via a mailing list discussion. But in both cases the volume of messages on a topic is not, by itself, a good indicator of consensus since one or two individuals may be generating much of the traffic.
衡量邮件列表上的共识程度可能特别具有挑战性。在两种不同的情况下，工作组可能试图通过邮件列表讨论来了解共识的程度。但在这两种情况下，一个主题的消息量本身并不是一个很好的共识指标，因为一个或两个个体可能会产生大量的流量。
In the case where a consensus which has been reached during a face-to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people
如果在面对面会议期间达成的共识在邮件列表上得到验证，则必须考虑出席会议并表示同意的人员。如果一次会议有100人，而只有几个人
on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this.
在邮件列表中，如果不同意会议的一致意见，则应将一致意见视为已得到验证。请注意，邮件列表阅读器的验证过程应该有足够的时间来理解并考虑列表中可能出现的任何异议。正常的两周最后通话时间应足以满足此要求。
The other case is where the discussion has been held entirely over the mailing list. The determination of the level of consensus may be harder to do in this case since most people subscribed to mailing lists do not actively participate in discussions on the list. It is left to the discretion of the working group chair how to evaluate the level of consensus. The most common method used is for the working group chair to state what he or she believes to be the consensus view and. at the same time, requests comments from the list about the stated conclusion.
另一种情况是，讨论完全围绕邮件列表进行。在这种情况下，确定共识水平可能更难，因为大多数订阅邮件列表的人并不积极参与列表上的讨论。如何评估协商一致的程度由工作组主席自行决定。最常用的方法是工作组主席陈述他或她认为是协商一致意见的观点和建议。同时，要求名单对所述结论提出意见。
The challenge to managing working group sessions is to balance the need for open and fair consideration of the issues against the need to make forward progress. The working group, as a whole, has the final responsibility for striking this balance. The Chair has the responsibility for overseeing the process but may delegate direct process management to a formally-designated Facilitator.
管理工作组会议的挑战是平衡公开和公平审议问题的需要与取得进展的需要。整个工作组对实现这一平衡负有最终责任。主席负责监督过程，但可将直接过程管理委托给正式指定的主持人。
It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. It is also good practice to note important decisions/consensus reached by email in the minutes of the next 'live' session, and to summarize briefly the decision-making history in the final documents the WG produces.
偶尔，重温主题、重新评估备选方案或提高团队对相关决策的理解是合适的。但是，如果主席确保在讨论结束后对讨论中的主要论点（以及结果）进行总结和存档，就可以避免对问题进行不必要的重复讨论。在下一次“现场”会议的会议记录中记录通过电子邮件达成的重要决定/共识，并在工作组编制的最终文件中简要总结决策历史也是一种良好做法。
To facilitate making forward progress, a Working Group Chair may wish to decide to reject or defer the input from a member, based upon the following criteria:
为促进取得进展，工作组主席不妨根据以下标准决定拒绝或推迟成员的意见：
Old The input pertains to a topic that already has been resolved and is redundant with information previously available;
旧输入与已解决的主题相关，并且与以前可用的信息冗余；
Minor The input is new and pertains to a topic that has already been resolved, but it is felt to be of minor import to the existing decision;
次要输入是新的，与已解决的主题相关，但对现有决策具有次要意义；
Timing The input pertains to a topic that the working group has not yet opened for discussion; or
时间安排与工作组尚未开放供讨论的专题有关；或
Scope The input is outside of the scope of the working group charter.
范围投入超出了工作组章程的范围。
Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion.
IETF过程中的各个阶段都可能发生争议。该进程的设计应尽可能使各方达成妥协，并达成真正的共识；然而，有时即使是最通情达理、知识渊博的人也无法达成一致。为了实现公开和公平的目标，这些冲突必须通过公开审查和讨论的过程来解决。
Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions and conducting appeals are documented in The Internet Standards Process [1].
互联网标准流程中记录了请求审查工作组、主席、区域主任或IESG行动和进行上诉的正式程序[1]。
Working groups are typically chartered to accomplish a specific task or tasks. After the tasks are complete, the group will be disbanded. However, if a WG produces a Proposed or Draft Standard, the WG will frequently become dormant rather than disband (i.e., the WG will no longer conduct formal activities, but the mailing list will remain available to review the work as it moves to Draft Standard and Standard status.)
工作组通常被授权完成一项或多项特定任务。任务完成后，该小组将解散。但是，如果工作组提出了一个建议或标准草案，工作组将经常处于休眠状态，而不是解散（即工作组将不再进行正式活动，但在工作组进入标准草案和标准状态时，邮件列表将保持可用以审查工作。）
If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, or if the assumptions which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either:
如果在某一点上，工作组显然无法完成《宪章》中概述的工作，或者如果该工作所依据的假设在讨论中或根据经验进行了修改，则区域主任在与工作组协商后可以：
1. Recharter to refocus its tasks, 2. Choose new Chair(s), or 3. Disband.
1. 重新调整其任务重点，2。选择新椅子或3把。解散
If the working group disagrees with the Area Director's choice, it may appeal to the IESG (see section 3.4).
如果工作组不同意区域主任的选择，可向IESG提出上诉（见第3.4节）。
Updated milestones are renegotiated with the Area Director and the IESG, as needed, and then are submitted to the IESG Secretariat: iesg-secretary@ietf.org.
根据需要，与区域总监和IESG重新协商更新的里程碑，然后提交给IESG秘书处：IESG-secretary@ietf.org.
Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded.
重新租船（修订里程碑除外）工作组遵循与初始租船相同的程序（见第2节）。修订后的章程必须提交IESG和IAB批准。与初始章程一样，IESG可以按原样批准新章程，可以要求对新章程进行修改（包括让工作组继续使用旧章程），也可以拒绝批准重新编制的工作组。在后一种情况下，工作组解散。
Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles. The Area Director must agree to the specific people performing the WG Chair, and Working Group Consultant roles, and they serve at the discretion of the Area Director.
工作组需要相当多的照顾和喂养。除了普遍参与外，成功的工作组还得益于参与者填补特定职能角色的努力。区域总监必须同意担任工作组主席和工作组顾问角色的具体人员，他们的服务由区域总监决定。
The Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The Chair must ensure that a number of tasks are performed, either directly or by others assigned to the tasks.
工作组主席关注通过公平和公开的程序取得进展，并在工作组业务的开展方面拥有广泛的自由裁量权。主席必须确保直接或由分配给任务的其他人执行多项任务。
The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention.
主席有责任和权力代表工作组根据IETF的规则，就工作组流程和人员配置的所有事项作出决定。广告有权也有责任应主席的要求或在情况需要时协助作出这些决定。
The Chair's responsibility encompasses at least the following:
主席的职责至少包括以下内容：
Ensure WG process and content management
确保工作组流程和内容管理
The Chair has ultimate responsibility for ensuring that a working group achieves forward progress and meets its milestones. The Chair is also responsible to ensure that the working group operates in an open and fair manner. For some working groups, this can be accomplished by having the Chair perform all management-related activities. In other working groups -- particularly those with large or divisive participation -- it is helpful to allocate process and/or secretarial functions to other participants. Process management pertains strictly to the style of working group interaction and not to its content. It ensures fairness and detects redundancy. The secretarial function encompasses document editing. It is quite common for a working
主席对确保工作组取得进展并达到其里程碑负有最终责任。主席还负责确保工作组以公开和公平的方式运作。对于某些工作组，这可以通过让主席执行所有与管理相关的活动来实现。在其他工作组中——特别是那些参与人数众多或存在分歧的工作组——将流程和/或秘书职能分配给其他参与者是有帮助的。过程管理严格属于工作组互动的风格，而不是其内容。它确保公平性并检测冗余。秘书职能包括文件编辑。这对于一个工人来说是很常见的
group to assign the task of specification Editor to one or two participants. Sometimes, they also are part of the design team, described below.
组将规范编辑器的任务分配给一个或两个参与者。有时，他们也是设计团队的一部分，如下所述。
Moderate the WG email list
调整工作组电子邮件列表
The Chair should attempt to ensure that the discussions on this list are relevant and that they converge to consensus agreements. The Chair should make sure that discussions on the list are summarized and that the outcome is well documented (to avoid repetition). The Chair also may choose to schedule organized on-line "sessions" with agenda and deliverables. These can be structured as true meetings, conducted over the course of several days (to allow participation across the Internet).
主席应努力确保该清单上的讨论具有相关性，并使之趋于协商一致。主席应确保对清单上的讨论进行总结，并将结果记录在案（以避免重复）。主席还可以选择安排有组织的在线“会议”，包括议程和可交付成果。这些会议可以被组织成真正的会议，在几天的时间内进行（允许通过互联网参与）。
Organize, prepare and chair face-to-face and on-line formal sessions.
组织、准备和主持面对面和在线正式会议。
Plan WG Sessions
计划工作组会议
The Chair must plan and announce all WG sessions well in advance (see section 3.1).
主席必须提前计划并宣布所有工作组会议（见第3.1节）。
Communicate results of sessions
交流会议结果
The Chair and/or Secretary must ensure that minutes of a session are taken and that an attendance list is circulated (see section 3.1).
主席和/或秘书必须确保记录会议记录并分发出席名单（见第3.1节）。
Immediately after a session, the WG Chair MUST provide the Area Director with a very short report (approximately one paragraph, via email) on the session.
会议结束后，工作组主席必须立即向区域主任提供一份非常简短的会议报告（大约一段，通过电子邮件）。
Distribute the workload
分配工作量
Of course, each WG will have participants who may not be able (or want) to do any work at all. Most of the time the bulk of the work is done by a few dedicated participants. It is the task of the Chair to motivate enough experts to allow for a fair distribution of the workload.
当然，每个工作组都会有一些参与者，他们可能根本无法（或不想）做任何工作。大多数情况下，大部分工作都是由几个专注的参与者完成的。主席的任务是调动足够的专家，以便公平分配工作量。
Document development
文件开发
Working groups produce documents and documents need authors. The Chair must make sure that authors of WG documents incorporate changes as agreed to by the WG (see section 6.3).
工作组制作文档，文档需要作者。主席必须确保工作组文件的作者纳入工作组同意的变更（见第6.3节）。
Document publication
文件出版
The Chair and/or Document Editor will work with the RFC Editor to ensure document conformance with RFC publication requirements [5] and to coordinate any editorial changes suggested by the RFC Editor. A particular concern is that all participants are working from the same version of a document at the same time.
主席和/或文件编辑将与RFC编辑合作，确保文件符合RFC出版要求[5]，并协调RFC编辑建议的任何编辑变更。特别令人担忧的是，所有参与者都在同一时间使用同一版本的文档。
Document implementations
文档实现
Under the procedures described in [1], the Chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations.
根据[1]中所述的程序，主席负责记录符合规范草案或互联网标准状态的具体实施，以及关于这些实施互操作性测试的文件。
Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Secretary's job is to record WG decisions, rather than to perform basic specification.
记录会议记录和编辑工作组文件通常由指定的参与者或一组参与者执行。在这个角色中，秘书的工作是记录工作组的决定，而不是执行基本规范。
Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group generally designates a person or persons to serve as the Editor for a particular document. The Document Editor is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group.
大多数IETF工作组将工作重点放在一个或一组文档上，这些文档记录了工作组的工作结果。工作组通常指定一人或多人担任特定文件的编辑。文件编辑负责确保文件内容准确反映工作组作出的决定。
As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed.
作为一种普遍做法，工作组主席和文件编辑职位由不同的人担任，以帮助确保产生的文件准确反映工作组的共识，并遵守所有程序。
When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves.
当会议容易分散注意力或产生分歧时，将“流程管理”任务分配给一名参与者通常是有帮助的。他们的工作是监督参与者互动的性质，而不是内容。也就是说，他们关注讨论的风格和议程安排，而不是自己做出直接的技术贡献。
It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole.
工作组的一个小组拟订一项解决某一特定问题的建议通常是有益的，而且可能是不可避免的。这样的子组称为设计团队。为了使设计团队保持小型化和敏捷化，可以接受非公开成员和私人会议。设计团队的范围可以从人们在走廊里的非正式聊天，到工作组主席或广告指定的一组正式的专家志愿者来解决一个有争议的问题。设计团队的输出始终受到工作组整体的批准、拒绝或修改。
At the discretion of the Area Director, a Consultant may be assigned to a working group. Consultants have specific technical background appropriate to the WG and experience in Internet architecture and IETF process.
根据区域总监的决定，可向工作组指派一名顾问。顾问具有适合工作组的特定技术背景以及互联网架构和IETF流程方面的经验。
Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF.
区域总监负责确保其区域内的工作组产生一致、协调、架构一致和及时的输出，作为对IETF总体结果的贡献。
All relevant documents to be discussed at a session should be published and available as Internet-Drafts at least two weeks before a session starts. Any document which does not meet this publication deadline can only be discussed in a working group session with the specific approval of the working group chair(s). Since it is important that working group members have adequate time to review all documents, granting such an exception should only be done under unusual conditions. The final session agenda should be posted to the working group mailing list at least two weeks before the session and sent at that time to agenda@ietf.org for publication on the IETF web site.
会议上讨论的所有相关文件应在会议开始前至少两周以互联网草稿的形式发布和提供。任何不符合本出版物截止日期的文件只能在工作组会议上讨论，并获得工作组主席的特别批准。由于工作组成员有足够的时间审查所有文件是很重要的，因此只有在非常情况下才应批准这种例外情况。最后一次会议议程应至少在会议前两周张贴到工作组邮寄名单上，并在当时发送给agenda@ietf.org在IETF网站上发布。
The Internet-Drafts directory is provided to working groups as a resource for posting and disseminating in-process copies of working group documents. This repository is replicated at various locations around the Internet. It is encouraged that draft documents be posted
因特网草稿目录作为张贴和分发工作组文件过程中副本的资源提供给工作组。此存储库在Internet上的不同位置复制。鼓励张贴文件草稿
as soon as they become reasonably stable.
只要它们变得相当稳定。
It is stressed here that Internet-Drafts are working documents and have no official standards status whatsoever. They may, eventually, turn into a standards-track document or they may sink from sight. Internet-Drafts are submitted to: internet-drafts@ietf.org
这里强调的是，互联网草案是工作文件，没有任何官方标准地位。它们最终可能会变成一份标准跟踪文件，或者从人们的视线中消失。Internet草稿提交至：Internet-drafts@ietf.org
The format of an Internet-Draft must be the same as for an RFC [2]. Further, an I-D must contain:
互联网草稿的格式必须与RFC的格式相同[2]。此外，I-D必须包含：
- Beginning, standard, boilerplate text which is provided by the Secretariat on their web site and in the ftp directory; - The I-D filename; and - The expiration date for the I-D.
- 由秘书处在其网站和ftp目录中提供的开头、标准、样板文本I-D文件名；和-身份证的有效期。
Complete specification of requirements for an Internet-Draft are found in the file "1id-guidelines.txt" in the Internet-Drafts directory at an Internet Repository site. The organization of the Internet-Drafts directory is found in the file "1id-organization" in the Internet-Drafts directory at an Internet Repository site. This file also contains the rules for naming Internet-Drafts. (See [1] for more information about Internet-Drafts.)
Internet草稿要求的完整规范可在Internet存储库站点的Internet草稿目录中的文件“1id guidelines.txt”中找到。Internet草稿目录的组织位于Internet存储库站点的Internet草稿目录中的文件“1id组织”中。此文件还包含命名Internet草稿的规则。（有关Internet草稿的更多信息，请参见[1]）
The work of an IETF working group often results in publication of one or more documents, as part of the Request For Comments (RFCs) [1] series. This series is the archival publication record for the Internet community. A document can be written by an individual in a working group, by a group as a whole with a designated Editor, or by others not involved with the IETF.
IETF工作组的工作通常导致发布一个或多个文件，作为征求意见书（RFCs）[1]系列的一部分。本系列是互联网社区的档案出版物记录。文档可以由工作组中的个人编写，也可以由指定编辑的整个工作组编写，也可以由与IETF无关的其他人编写。
NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards [4].
注：RFC系列只是一种发布机制，发布并不决定文档的IETF状态。状态通过IESG代表IETF分配的单独、明确的状态标签确定。换句话说，提醒读者，所有互联网标准均以RFC形式发布，但并非所有RFC都指定了标准[4]。
When a WG decides that a document is ready for publication it may be submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for publication is done by the WG Chair issuing a working group Last-Call. The decision to issue a working group Last-Call is at the discretion of the WG Chair working with the Area Director. A working group Last-Call serves the same purpose within a working group that
当工作组决定文件已准备好发布时，可将其提交给IESG审议。在大多数情况下，工作组主席发出工作组最后一次通知，确定工作组认为文件已准备好发布。工作组主席与区域主任共同决定是否发出工作组最后一次通知。工作组最后一次呼叫在工作组内的作用与
an IESG Last-Call does in the broader IETF community (see [1]).
IESG最后一次调用在更广泛的IETF社区中进行（见[1]）。
Once that a WG has determined at least rough consensus exists within the WG for the advancement of a document the following must be done:
一旦工作组确定工作组内部至少存在推进文件的大致共识，则必须完成以下工作：
- The version of the relevant document exactly as agreed to by the WG MUST be in the Internet-Drafts directory.
- 工作组完全同意的相关文件版本必须在互联网草稿目录中。
- The relevant document MUST be formatted according to section 7.3.
- 相关文件的格式必须符合第7.3节的规定。
- The WG Chair MUST send email to the relevant Area Director. A copy of the request MUST be also sent to the IESG Secretariat. The mail MUST contain the reference to the document's ID filename, and the action requested. The copy of the message to the IESG Secretariat is to ensure that the request gets recorded by the Secretariat so that they can monitor the progress of the document through the process.
- 工作组主席必须向相关区域主管发送电子邮件。还必须向IESG秘书处发送请求副本。邮件必须包含对文档ID文件名的引用以及请求的操作。发送给IESG秘书处的信息副本是为了确保秘书处记录请求，以便他们能够通过该过程监控文件的进度。
Unless returned by the IESG to the WG for further development, progressing of the document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Editor.
除非IESG返回工作组进行进一步开发，否则文件的进度由IESG负责。IESG批准后，RFC编辑、工作组主席和文件编辑共同负责最终处置。
The IESG reviews all documents submitted for publication as RFCs. Usually minimal IESG review is necessary in the case of a submission from a WG intended as an Informational or Experimental RFC. More extensive review is undertaken in the case of standards-track documents.
IESG审查所有提交作为RFC发布的文件。通常，在工作组提交信息或实验RFC的情况下，最低限度的IESG审查是必要的。对标准跟踪文件进行更广泛的审查。
Prior to the IESG beginning their deliberations on standards-track documents, IETF Secretariat will issue a "Last-Call" to the IETF mailing list (see [1]). This Last Call will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF within a period of two weeks. It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review.
在IESG开始审议标准跟踪文件之前，IETF秘书处将向IETF邮件列表发出“最后一次呼叫”（见[1]）。这最后一次通话将宣布IESG考虑文件的意图，并将在两周内征求IETF的最终意见。重要的是要注意，最后一次通话是为了与互联网社区进行简短的最后检查，以确保没有遗漏或误解任何重要问题。最后一次呼吁不应作为更全面、更深入的审查。
The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions:
IESG审查考虑了对最后一次电话的回应，并将得出以下可能的结论之一：
1. The document is accepted as is for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor.
1. 该文件按要求的状态被接受。IETF秘书处将向IETF邮件列表和RFC编辑公布这一事实。
2. The document is accepted as-is but not for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor (see [1] for more details).
2. 文档按原样接受，但不符合请求的状态。IETF秘书处将向IETF邮件列表和RFC编辑公布这一事实（更多详细信息，请参见[1]）。
3. Changes regarding content are suggested to the author(s)/WG. Suggestions from the IESG must be clear and direct, so as to facilitate working group and author correction of the specification. If the author(s)/WG can explain to the satisfaction of the IESG why the changes are not necessary, the document will be accepted for publication as under point 1, above. If the changes are made the revised document may be resubmitted for IESG review.
3. 建议作者/工作组更改内容。IESG的建议必须清晰直接，以便于工作组和作者修改规范。如果作者/工作组能够向IESG解释为什么不需要进行更改，并使IESG满意，则该文件将按照上述第1点的规定予以出版。如果进行了更改，修订后的文件可重新提交给IESG审查。
4. Changes are suggested by the IESG and a change in status is recommended. The process described above for 3 and 2 are followed in that order.
4. IESG建议进行更改，并建议更改状态。按照上述步骤3和步骤2的顺序进行操作。
5. The document is rejected. Any document rejection will be accompanied by specific and thorough arguments from the IESG. Although the IETF and working group process is structured such that this alternative is not likely to arise for documents coming from a working group, the IESG has the right and responsibility to reject documents that the IESG feels are fatally flawed in some way.
5. 该文件被拒绝。任何文件拒绝都将伴随IESG的具体和彻底的论证。尽管IETF和工作组流程的结构使得来自工作组的文件不太可能出现这种替代方案，但IESG有权和责任拒绝IESG认为在某些方面存在致命缺陷的文件。
If any individual or group of individuals feels that the review treatment has been unfair, there is the opportunity to make a procedural complaint. The mechanism for this type of complaints is described in [1].
如果任何个人或个人团体认为审查待遇不公平，则有机会提出程序性投诉。[1]中描述了此类投诉的机制。
Documents describing IETF processes, such as this one, do not have an impact on the security of the network infrastructure or of Internet applications.
描述IETF过程的文档（如本文档）不会对网络基础设施或互联网应用程序的安全性产生影响。
It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs in a Security Considerations section. Note that merely noting a significant security hole is no longer sufficient. IETF developed technologies should not add insecurity to the environment in which they are run.
应该注意的是，所有IETF工作组都需要检查和理解他们开发的任何技术的安全含义。此分析必须包含在安全注意事项部分的任何结果RFC中。请注意，仅仅注意一个重要的安全漏洞已不再足够。IETF开发的技术不应增加运行环境的不安全性。
This revision of this document relies heavily on the previous version (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has been reviewed by the Poisson Working Group.
本文件的本次修订严重依赖于Erik Huizer和Dave Crocker编辑的前一版本（RFC 1603）。Poisson工作组已对其进行了审查。
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，编辑，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Hovey, R., and S. Bradner, "The Organizations involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[2] Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 2282, February 1998.
[3] Gavin，J.，“IAB和IESG的选择、确认和召回过程：提名和召回委员会的运作”，BCP 10，RFC 2282，1998年2月。
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", RFC 1796, April 1995.
[4] Huitema，C.，J.Postel，S.Crocker，“并非所有RFC都是标准”，RFC 1796，1995年4月。
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[5] Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Scott Bradner Harvard University 1350 Mass Ave. Cambridge MA 02138 USA
美国马萨诸塞州剑桥市马萨诸塞大道1350号斯科特·布拉德纳哈佛大学02138
Phone +1 617 495 3864 EMail: sob@harvard.edu
电话+1 617 495 3864电子邮件：sob@harvard.edu
Appendix: Sample Working Group Charter
附录：工作组章程样本
Working Group Name: IP Telephony (iptel)
工作组名称：IP电话（iptel）
IETF Area: Transport Area
IETF区域：运输区域
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/siptel
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/siptel
Description of Working Group:
工作组说明：
Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services.
在Internet电话成为广泛部署的服务之前，必须部署许多协议。这些协议包括信令和交换能力，但也包括一些用于提供相关服务的“外围”协议。
The primary purpose of this working group is to develop two such supportive protocols and a frameword document. They are:
该工作组的主要目的是制定两个此类支持性协议和一份frameword文件。他们是：
1. Call Processing Syntax. When a call is setup between two endpoints, the signaling will generally pass through several servers (such as an H.323 gatekeeper) which are responsible for forwarding, redirecting, or proxying the signaling messages. For example, a user may make a call to j.doe@bigcompany.com. The signaling message to initiate the call will arrive at some server at bigcompany. This server can inform the caller that the callee is busy, forward the call initiation request to another server closer to the user, or drop the call completely (among other possibilities). It is very desirable to allow the callee to provide input to this process, guiding the server in its decision on how to act. This can enable a wide variety of advanced personal mobility and call agent services.
1. 调用处理语法。当在两个端点之间建立呼叫时，信令通常将通过多个服务器（如H.323网守），这些服务器负责转发、重定向或代理信令消息。例如，用户可以呼叫j。doe@bigcompany.com. 发起呼叫的信令消息将到达bigcompany的某个服务器。此服务器可以通知呼叫者被呼叫者正忙，将呼叫发起请求转发到离用户更近的另一台服务器，或者完全放弃呼叫（以及其他可能性）。非常希望允许被调用方向这个过程提供输入，指导服务器决定如何操作。这可以实现多种高级个人移动和呼叫代理服务。
Such preferences can be expressed in a call processing syntax, which can be authored by the user (or generated automatically by some tool), and then uploaded to the server. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC.
这些首选项可以用调用处理语法表示，该语法可以由用户编写（或由某些工具自动生成），然后上传到服务器。该小组将开发该语法，并指定安全传输和扩展该语法的方法。结果将是一个单一的标准轨道RFC。
2. In addition, the group will write a service model document, which describes the services that are enabled by the call processing syntax, and discusses how the syntax can be used. This document will result in a single RFC.
2. 此外，该小组还将编写一份服务模型文档，描述通过调用处理语法启用的服务，并讨论如何使用该语法。本文件将生成一份RFC。
3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone number. Since gateways outside of the hosts' administrative domain might be used, a protocol is required to allow gateways in remote domains to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities in other domains which must make a selection of a gateway. The protocol must allow for scalable, bandwidth efficient, and very secure transmission of these attributes. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC as appropriate.
3. 网关属性分发协议。在IP主机和PSTN用户之间进行呼叫时，必须使用电话网关。除目的地电话号码外，此类网关的选择可以基于许多标准，包括客户表示的偏好、服务提供商偏好和网关的可用性。由于可能会使用主机管理域之外的网关，因此需要一个协议来允许远程域中的网关将其属性（如PSTN连接、支持的编解码器等）分发给其他域中的实体，这些实体必须选择网关。该协议必须允许这些属性的可扩展、带宽高效和非常安全的传输。该小组将为此目的调查和设计协议，生成互联网草案，并酌情将其提交给RFC。
Goals and Milestones:
目标和里程碑：
May 98 Issue first Internet-Draft on service framework Jul 98 Submit framework ID to IESG for publication as an RFC. Aug 98 Issue first Internet-Draft on Call Processing Syntax Oct 98 Submit Call processing syntax to IESG for consideration as a Proposed Standard. Dec 98 Achieve consensus on basics of gateway attribute distribution protocol Jan 99 Submit Gateway Attribute Distribution protocol to IESG for consideration as a RFC (info, exp, stds track TB
1998年5月发布关于服务框架的第一份互联网草案1998年7月将框架ID提交给IESG，作为RFC发布。1998年8月发布关于呼叫处理语法的第一份互联网草案1998年10月将呼叫处理语法提交给IESG，作为建议的标准进行考虑。1998年12月就网关属性分发协议的基础达成共识1999年1月将网关属性分发协议提交给IESG，作为RFC（信息、经验、STD跟踪TB）考虑
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。