Network Working Group P. Hoffman
Request for Comments: 4677 VPN Consortium
FYI: 17 S. Harris
Obsoletes: 3160 University of Michigan
Category: Informational September 2006
Network Working Group P. Hoffman
Request for Comments: 4677 VPN Consortium
FYI: 17 S. Harris
Obsoletes: 3160 University of Michigan
Category: Informational September 2006
The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force
IETF之道：互联网工程任务组新手指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview.
本文件描述了IETF会议和工作组的内部工作，讨论了与IETF相关的组织，并介绍了标准流程。它不是一份正式的IETF过程文件，而是一份信息概述。
Table of Contents
目录
1. Introduction ....................................................4
2. Acknowledgements ................................................5
3. What Is the IETF? ...............................................5
3.1. Humble Beginnings ..........................................6
3.2. The Hierarchy ..............................................7
3.2.1. ISOC (Internet Society) .............................7
3.2.2. IESG (Internet Engineering Steering Group) ..........8
3.2.3. IAB (Internet Architecture Board) ..................10
3.2.4. IANA (Internet Assigned Numbers Authority) .........11
3.2.5. RFC Editor .........................................11
3.2.6. IETF Secretariat ...................................12
3.3. IETF Mailing Lists ........................................12
4. IETF Meetings ..................................................13
4.1. Registration ..............................................14
4.2. Take the Plunge and Stay All Week! ........................15
4.3. Newcomer Training .........................................16
4.4. Dress Code ................................................16
4.5. Seeing Spots Before Your Eyes .............................16
4.6. Terminal Room .............................................17
4.7. Meals and Other Delights ..................................17
4.8. Social Event ..............................................18
4.9. Agenda ....................................................18
4.10. EDU to the Rescue ........................................19
4.11. Where Do I Fit In? .......................................19
4.11.1. IS Managers .......................................19
4.11.2. Network Operators and ISPs ........................19
4.11.3. Networking Hardware and Software Vendors ..........20
4.11.4. Academics .........................................20
4.11.5. Computer Trade Press ..............................20
4.12. Proceedings ..............................................21
4.13. Other General Things .....................................21
5. Working Groups .................................................22
5.1. Working Group Chairs ......................................23
5.2. Getting Things Done in a Working Group ....................24
5.3. Preparing for Working Group Meetings ......................25
5.4. Working Group Mailing Lists ...............................26
5.5. Interim Working Group Meetings ............................27
6. BOFs ...........................................................27
7. New to the IETF and Coming to a Meeting? STOP HERE!
(Temporarily) ..................................................28
8. RFCs and Internet Drafts .......................................29
8.1. Getting an RFC Published ..................................29
8.2. Letting Go Gracefully .....................................30
8.3. Internet Drafts ...........................................31
8.3.1. Recommended Reading for Writers ....................32
8.3.2. Filenames and Other Matters ........................33
1. Introduction ....................................................4
2. Acknowledgements ................................................5
3. What Is the IETF? ...............................................5
3.1. Humble Beginnings ..........................................6
3.2. The Hierarchy ..............................................7
3.2.1. ISOC (Internet Society) .............................7
3.2.2. IESG (Internet Engineering Steering Group) ..........8
3.2.3. IAB (Internet Architecture Board) ..................10
3.2.4. IANA (Internet Assigned Numbers Authority) .........11
3.2.5. RFC Editor .........................................11
3.2.6. IETF Secretariat ...................................12
3.3. IETF Mailing Lists ........................................12
4. IETF Meetings ..................................................13
4.1. Registration ..............................................14
4.2. Take the Plunge and Stay All Week! ........................15
4.3. Newcomer Training .........................................16
4.4. Dress Code ................................................16
4.5. Seeing Spots Before Your Eyes .............................16
4.6. Terminal Room .............................................17
4.7. Meals and Other Delights ..................................17
4.8. Social Event ..............................................18
4.9. Agenda ....................................................18
4.10. EDU to the Rescue ........................................19
4.11. Where Do I Fit In? .......................................19
4.11.1. IS Managers .......................................19
4.11.2. Network Operators and ISPs ........................19
4.11.3. Networking Hardware and Software Vendors ..........20
4.11.4. Academics .........................................20
4.11.5. Computer Trade Press ..............................20
4.12. Proceedings ..............................................21
4.13. Other General Things .....................................21
5. Working Groups .................................................22
5.1. Working Group Chairs ......................................23
5.2. Getting Things Done in a Working Group ....................24
5.3. Preparing for Working Group Meetings ......................25
5.4. Working Group Mailing Lists ...............................26
5.5. Interim Working Group Meetings ............................27
6. BOFs ...........................................................27
7. New to the IETF and Coming to a Meeting? STOP HERE!
(Temporarily) ..................................................28
8. RFCs and Internet Drafts .......................................29
8.1. Getting an RFC Published ..................................29
8.2. Letting Go Gracefully .....................................30
8.3. Internet Drafts ...........................................31
8.3.1. Recommended Reading for Writers ....................32
8.3.2. Filenames and Other Matters ........................33
8.4. Standards-Track RFCs ......................................34
8.4.1. Telling It Like It Is -- Using MUST and SHOULD
and MAY ............................................35
8.4.2. Normative References in Standards ..................36
8.4.3. IANA Considerations ................................37
8.4.4. Security Considerations ............................37
8.4.5. Patents in IETF Standards ..........................37
8.5. Informational and Experimental RFCs .......................38
9. How to Contribute to the IETF ..................................39
9.1. What You Can Do ...........................................39
9.2. What Your Company Can Do ..................................40
10. IETF and the Outside World ....................................40
10.1. IETF and Other Standards Groups ..........................40
10.2. Press Coverage of the IETF ...............................41
11. Security Considerations .......................................42
Appendix A. Related Information ...................................43
A.1. Why "the Tao"? ............................................43
A.2. Useful Email Addresses ....................................43
A.3. Useful Documents and Files ................................44
A.4. Acronyms and Abbreviations Used in the Tao ................44
Appendix B. IETF Guiding Principles ...............................45
B.1. General ...................................................45
B.2. Management and Leadership .................................45
B.3. Process ...................................................46
B.4. Working Groups ............................................46
B.5. Documents .................................................47
Informative References ............................................48
8.4. Standards-Track RFCs ......................................34
8.4.1. Telling It Like It Is -- Using MUST and SHOULD
and MAY ............................................35
8.4.2. Normative References in Standards ..................36
8.4.3. IANA Considerations ................................37
8.4.4. Security Considerations ............................37
8.4.5. Patents in IETF Standards ..........................37
8.5. Informational and Experimental RFCs .......................38
9. How to Contribute to the IETF ..................................39
9.1. What You Can Do ...........................................39
9.2. What Your Company Can Do ..................................40
10. IETF and the Outside World ....................................40
10.1. IETF and Other Standards Groups ..........................40
10.2. Press Coverage of the IETF ...............................41
11. Security Considerations .......................................42
Appendix A. Related Information ...................................43
A.1. Why "the Tao"? ............................................43
A.2. Useful Email Addresses ....................................43
A.3. Useful Documents and Files ................................44
A.4. Acronyms and Abbreviations Used in the Tao ................44
Appendix B. IETF Guiding Principles ...............................45
B.1. General ...................................................45
B.2. Management and Leadership .................................45
B.3. Process ...................................................46
B.4. Working Groups ............................................46
B.5. Documents .................................................47
Informative References ............................................48
Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages.
自成立初期以来，参加互联网工程任务组（IETF）面对面的会议的人数显著增加。在每次会议上，许多与会者都是IETF的新手，其中许多人后来成为定期与会者。当会议规模较小时，新来者相对容易参与到事情的发展中来。然而，今天，一个新来者会遇到更多的新朋友，有些人以前只知道是文档或发人深省的电子邮件的作者。
This document describes many aspects of the IETF, with the goal of explaining to newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting and the Working Group discussions more productive for everyone.
本文档描述了IETF的许多方面，目的是向新来者解释IETF是如何工作的。这将给他们一种温暖、模糊的感觉，使他们能够使会议和工作组的讨论对每个人都更有成效。
Of course, it's true that many IETF participants don't go to the face-to-face meetings at all. Instead, they're active on the mailing list of various IETF Working Groups. Since the inner workings of Working Groups can be hard for newcomers to understand, this document provides the mundane bits of information that newcomers will need in order to become active participants.
当然，许多IETF参与者根本不参加面对面的会议，这是事实。相反，他们活跃在各个IETF工作组的邮件列表中。由于工作组的内部工作对新手来说可能很难理解，本文件提供了新手成为积极参与者所需的平凡信息。
The IETF is always in a state of change. Although the principles in this document are expected to remain largely the same over time, practical details may well have changed by the time you read it; for example, a web-based tool may have replaced an email address for requesting some sort of action.
IETF始终处于变化状态。尽管本文件中的原则预计随着时间的推移基本保持不变，但在您阅读本文件时，实际细节可能已经发生了变化；例如，一个基于web的工具可能已经取代了请求某种操作的电子邮件地址。
Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and FYIs and STDs. BCPs make recommendations for Best Current Practices in the Internet; RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments"; FYIs provide topical and technical overviews that are introductory or appeal to a broad audience; and STDs are RFCs identified as "standards". See Section 8 for more information.
Tao中提到了许多类型的IETF文档，从BCP到RFC、FYI和STD。BCP为互联网的最佳实践提出建议；RFC是IETF的主要技术文档系列，礼貌地称为“征求意见”；FYI提供专题和技术概述，这些概述是介绍性的或对广大受众有吸引力的；性传播疾病是被确定为“标准”的RFC。更多信息请参见第8节。
The acronyms and abbreviations used in this document are usually expanded in place and are explained fully in Appendix A.
本文件中使用的首字母缩略词和缩写词通常会适当扩展，并在附录A中进行详细解释。
This document is intended to obsolete FYI 17, RFC 3160. See Section 3.2.5 for information on what it means for one RFC to obsolete another.
本文件旨在淘汰FYI 17，RFC 3160。参见第3.2.5节，了解一个RFC淘汰另一个RFC意味着什么。
The original version of this document, published in 1994, was written by Gary Malkin. His knowledge of the IETF, insights, and unmatched writing style set the standard for this later revision, and his contributions to the current document are also much appreciated. Paul Hoffman wrote significant portions of this revision and provided encouragement, expertise, and much-needed guidance. Other contributors include Brian Carpenter, Scott Bradner, Michael Patton, Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault, the IETF Secretariat, members of the User Services Working Group, and members of the PESCI design team.
该文件的原始版本于1994年出版，由加里·马尔金撰写。他对IETF的知识、见解和无与伦比的写作风格为后来的修订定下了标准，他对当前文件的贡献也备受赞赏。保罗·霍夫曼（Paul Hoffman）撰写了本次修订的重要部分，并提供了鼓励、专业知识和急需的指导。其他贡献者包括Brian Carpenter、Scott Bradner、Michael Patton、Donald E.Eastlake III、Tony Hansen、Pekka Savola、Lisa Dusseault、IETF秘书处、用户服务工作组成员和PESCI设计团队成员。
The Internet Engineering Task Force is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. It is the principal body engaged in the development of new Internet standard specifications. The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues; see [BCP95], "A Mission Statement for the IETF", for more detail.
互联网工程任务组是一个松散的自组织团队，为互联网技术的工程和发展做出贡献。它是负责制定新的互联网标准规范的主要机构。IETF的不同寻常之处在于它是一个事件集合，但不是一个公司，没有董事会，没有成员，也没有会费；有关更多详细信息，请参见[BCP95]，“IETF任务声明”。
Its mission includes the following:
其任务包括：
o Identifying, and proposing solutions to, pressing operational and technical problems in the Internet
o 识别互联网上紧迫的运营和技术问题并提出解决方案
o Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet
o 指定协议的开发或使用以及解决互联网技术问题的近期架构
o Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet
o 向互联网工程指导小组（IESG）提出关于互联网协议和协议使用标准化的建议
o Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community
o 促进互联网研究工作队（IRTF）向更广泛的互联网社区进行技术转让
o Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, and network managers
o 为供应商、用户、研究人员、机构承包商和网络经理之间在互联网社区内交流信息提供论坛
The IETF meeting is not a conference, although there are technical presentations. The IETF is not a traditional standards organization, although many specifications are produced that become standards. The IETF is made up of volunteers, many of whom meet three times a year to fulfill the IETF mission.
IETF会议不是一个会议，尽管有技术演示。IETF不是一个传统的标准组织，尽管许多规范已经成为标准。IETF由志愿者组成，其中许多人每年开会三次以完成IETF任务。
There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists (see Section 3.3). This is where the best information about current IETF activities and focus can be found.
IETF没有成员资格。任何人都可以注册并参加任何会议。最接近IETF成员的是IETF或工作组邮件列表（见第3.3节）。在这里可以找到有关当前IETF活动和重点的最佳信息。
Of course, no organization can be as successful as the IETF is without having some sort of structure. In the IETF's case, that structure is provided by other organizations, as described in [BCP11], "The Organizations Involved in the IETF Standards Process". If you participate in the IETF and read only one BCP, this is the one you should read.
当然，如果没有某种结构，任何组织都不可能像IETF那样成功。就IETF而言，该结构由其他组织提供，如[BCP11]“参与IETF标准过程的组织”所述。如果您参加IETF并只读取一个BCP，则这是您应该阅读的BCP。
In many ways, the IETF runs on the beliefs of its members. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: "Be conservative in what you send and liberal in what you accept".
在许多方面，IETF依靠其成员的信念运行。其中一个“创始信念”体现在大卫·克拉克（David Clark）对IETF的早期引用中：“我们拒绝国王、总统和投票。我们相信粗略的共识和运行代码”。另一句在IETF中已成为普遍信仰的早期引语来自Jon Postel：“发送的内容要保守，接受的内容要自由”。
The IETF is really about its members. Because of the unrestrictive membership policies, IETF members come from all over the world and from many different parts of the Internet industry. See Section 4.11 for information about the ways that many people fit into the IETF.
IETF真正关心的是它的成员。由于不受限制的成员政策，IETF成员来自世界各地以及互联网行业的许多不同部分。有关许多人融入IETF的方式的信息，请参见第4.11节。
One more thing that is important for newcomers: the IETF in no way "runs the Internet", despite what some people mistakenly might say. The IETF makes standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF.
对于新手来说，还有一件事很重要：IETF绝不“管理互联网”，尽管有些人可能会错误地说。IETF制定了互联网用户经常采用的标准，但它并不控制甚至巡逻互联网。如果你对IETF感兴趣是因为你想成为监督者的一部分，你可能会对IETF感到非常失望。
The first IETF meeting was held in January 1986 at Linkabit in San Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986, was the first that non-government vendors attended. The concept of Working Groups was introduced at the 5th IETF meeting at the NASA Ames Research Center in California in February 1987. The 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the first meeting with more than 100 attendees.
第一次IETF会议于1986年1月在圣地亚哥的林卡比特举行，有21名与会者。第四届IETF于1986年10月在门罗公园SRI举行，是第一次非政府供应商参加。工作组的概念于1987年2月在加利福尼亚州NASA艾姆斯研究中心举行的第五届IETF会议上提出。第七届IETF于1987年7月在弗吉尼亚州麦克莱恩的米特举行，是第一次有100多人参加的会议。
The 14th IETF meeting was held at Stanford University in July 1989. It marked a major change in the structure of the IETF universe. The IAB (then Internet Activities Board, now Internet Architecture Board), which until that time oversaw many "task forces", changed its structure to leave only two: the IETF and the IRTF. The IRTF is tasked to consider long-term research problems in the Internet. The IETF also changed at that time.
第14届IETF会议于1989年7月在斯坦福大学举行。它标志着IETF宇宙结构的重大变化。IAB（当时的互联网活动委员会，现在的互联网架构委员会）在此之前监督了许多“工作队”，改变了结构，只剩下两个：IETF和IRTF。IRTF的任务是考虑互联网上的长期研究问题。当时IETF也发生了变化。
After the Internet Society (ISOC) was formed in January 1992, the IAB proposed to ISOC that the IAB's activities should take place under the auspices of the Internet Society. During INET92 in Kobe, Japan, the ISOC Trustees approved a new charter for the IAB to reflect the proposed relationship.
互联网协会（ISOC）于1992年1月成立后，IAB向ISOC建议，IAB的活动应在互联网协会的赞助下进行。在日本神户INET92期间，ISOC受托人批准了IAB的新章程，以反映拟议的关系。
The IETF met in Amsterdam, The Netherlands, in July 1993. This was the first IETF meeting held in Europe, and the US/non-US attendee split was nearly 50/50. About one in three IETF meetings are now held in Europe or Asia, and the number of non-US attendees continues to be high -- about 50%, even at meetings held in the United States.
IETF于1993年7月在荷兰阿姆斯特丹举行会议。这是第一次在欧洲举行的IETF会议，美国/非美国与会者的比例接近50/50。目前，约三分之一的IETF会议在欧洲或亚洲举行，非美国与会者的数量仍然很高——约为50%，即使在美国举行的会议上也是如此。
The Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet. One of the ways that ISOC does this is through financial and legal support of the other "I" groups described here, particularly the IETF. ISOC provides insurance coverage for many of the people in the IETF process and acts as a public relations channel for the times that one of the "I" groups wants to say something to the press. The ISOC is one of the major unsung (and under-supported) heroes of the Internet.
互联网协会是一个促进互联网发展的国际性非营利会员组织。ISOC做到这一点的方法之一是通过本文所述的其他“I”团体，特别是IETF的财政和法律支持。ISOC为IETF过程中的许多人提供保险，并作为一个公共关系渠道，为一个“I”团体想向媒体发表意见的时候提供服务。ISOC是互联网上主要的无名英雄之一。
Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a he) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section).
从2005年春季开始，ISOC也成为IETF直接雇用的管理人员的基地。这在[BCP101]“IETF管理支持活动（IASA）的结构”中有更详细的描述。工作人员最初仅包括一名全职监督IETF会议规划、支持服务运营方面（秘书处、IANA（互联网分配号码管理局）和RFC编辑（本节后面将介绍）以及预算的行政总监（IAD）。他或她（目前是He）领导IETF行政支持活动（IASA），负责收取会议费用和支付发票等任务，还支持IETF工作组、IESG、IAB和IRTF的工作工具（本节后面将详细介绍这些工具）。
As well as staff, the IASA comprises volunteers and ex officio members from the ISOC and IETF leadership. The IASA and the IAD are directed by the IETF Administrative Oversight Committee (IAOC), which is selected by the IETF community. Here's how all this looks:
除了工作人员外，IASA还包括来自ISOC和IETF领导层的志愿者和当然成员。IASA和IAD由IETF管理监督委员会（IAOC）指导，该委员会由IETF社区选出。这一切看起来是这样的：
Internet Society
|
IAOC
|
IASA
|
IAD
Internet Society
|
IAOC
|
IASA
|
IAD
Neither the IAD nor the IAOC have any influence over IETF standards development, which we turn to now.
IAD和IAOC都不会对IETF标准的制定产生任何影响，我们现在来谈谈IETF标准的制定。
The IESG is responsible for technical management of IETF activities and the Internet standards process. It administers the process according to the rules and procedures that have been ratified by the ISOC Trustees. However, the IESG doesn't do much direct leadership, such as the kind you will find in many other standards organizations. As its name suggests, its role is to set directions rather than to give orders. The IESG ratifies or corrects the output from the IETF's Working Groups (WGs), gets WGs started and finished, and makes sure that non-WG drafts that are about to become RFCs are correct.
IESG负责IETF活动和互联网标准流程的技术管理。它根据ISOC受托人批准的规则和程序管理流程。然而，IESG并没有做太多的直接领导工作，就像你在许多其他标准组织中看到的那样。顾名思义，它的作用是确定方向，而不是下达命令。IESG批准或更正IETF工作组（WG）的输出，启动和完成工作组，并确保即将成为RFC的非工作组草案是正确的。
The IESG consists of the Area Directors (ADs), who are selected by the Nominations Committee (which is usually called "the NomCom") and are appointed for two years. The process for choosing the members of the IESG is detailed in [BCP10], "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees".
IESG由地区总监（ADs）组成，由提名委员会（通常称为“NomCom”）选出，任期两年。选择委员会和召回过程中的“IAB、IAB和召回”是指“IAB、IAB和IESG的具体操作”。
The current areas and abbreviations are shown below.
当前区域和缩写如下所示。
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs, such as
email and the web
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs, such as
email and the web
General (GEN) Catch-all for WGs that don't fit in other areas (which is very few)
一般（GEN）不适用于其他领域的工作组的总括（非常少）
Internet (INT) Different ways of moving IP packets and DNS information
Internet（INT）移动IP数据包和DNS信息的不同方式
Operations and Operational aspects, network monitoring, Management (OPS) and configuration
操作和操作方面、网络监控、管理（OPS）和配置
Real-time Delay-sensitive interpersonal Applications and communications Infrastructure (RAI)
实时延迟敏感人际应用程序和通信基础设施（RAI）
Routing (RTG) Getting packets to their destinations
将数据包发送到目的地的路由（RTG）
Security (SEC) Authentication and privacy
安全（SEC）认证和隐私
Transport (TSV) Special services for special packets
特殊包的运输（TSV）特殊服务
Because the IESG has a great deal of influence on whether Internet Drafts become RFCs, many people look at the ADs as somewhat godlike creatures. IETF participants sometimes reverently ask Area Directors for their opinion on a particular subject. However, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops. In fact, when asked for specific technical comments, the ADs may often defer to members at large whom they feel have more knowledge than they do in that area.
由于IESG对互联网草稿是否成为RFC有很大的影响，许多人认为这些广告有点像上帝。IETF参与者有时会虔诚地询问区域主管对特定主题的意见。然而，大多数广告几乎无法与凡人区分开来，也很少从山顶说起。事实上，当被问及具体的技术意见时，广告往往会听从那些他们认为在该领域比他们有更多知识的广大会员的意见。
The ADs for a particular area are expected to know more about the combined work of the WGs in that area than anyone else. On the other hand, the entire IESG reviews each Internet Draft that is proposed to become an RFC. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols and that an AD's "pet peeve" cannot indefinitely block something.
某一特定领域的广告预计比其他任何人都更了解工作组在该领域的联合工作。另一方面，整个IESG审查每个拟成为RFC的互联网草案。如果他或她有严重的顾虑，任何广告都可以记录反对草案的“讨论”投票立场。如果这些问题无法通过讨论解决，则应定义一个覆盖程序，以便至少两名IESG成员在阻止草案向前推进之前表达问题。这些程序有助于确保如果广告的“宠物项目”会对IETF协议的其余部分产生负面影响，并且广告的“宠物愤怒”不能无限期地阻止某些内容，则广告的“宠物项目”不会进入标准轨道。
This is not to say that the IESG never wields power. When the IESG sees a Working Group veering from its charter, or when a WG asks the IESG to make the WG's badly designed protocol a standard, the IESG will act. In fact, because of its high workload, the IESG usually moves in a reactive fashion. It eventually approves most WG requests for Internet Drafts to become RFCs, and usually only steps in when something has gone very wrong. Another way to think about this is that the ADs are selected to think, not to just run the process. The quality of the IETF standards comes both from the review they get in the Working Groups and the scrutiny that the WG review gets from the ADs.
这并不是说IESG从未掌权。当IESG看到一个工作组偏离其章程，或当工作组要求IESG将工作组设计糟糕的协议作为标准时，IESG将采取行动。事实上，由于其高工作量，IESG通常以反应式方式移动。它最终批准了大多数工作组关于互联网草案成为RFC的请求，通常只有在出现严重问题时才介入。考虑这一点的另一种方式是，选择广告是为了思考，而不仅仅是为了运行流程。IETF标准的质量既来自于工作组的审查，也来自于工作组审查来自ADs的审查。
The IETF is run by rough consensus, and it is the IESG that judges whether a WG has come up with a result that has community consensus. (See Section 5.2 for more information on WG consensus.) Because of this, one of the main reasons that the IESG might block something that was produced in a WG is that the result did not really gain consensus in the IETF as a whole, that is, among all of the Working Groups in all areas. For instance, the result of one WG might clash with a technology developed in a different Working Group. An important job of the IESG is to watch over the output of all the WGs to help prevent IETF protocols that are at odds with each other. This is why ADs are supposed to review the drafts coming out of areas other than their own.
IETF由大致一致的意见运行，IESG判断工作组是否得出了具有社区一致意见的结果。（有关工作组共识的更多信息，请参见第5.2节。）因此，IESG可能会阻止工作组中产生的内容的主要原因之一是，结果并未在整个IETF中，即在所有领域的所有工作组中，真正获得共识。例如，一个工作组的结果可能与另一个工作组开发的技术发生冲突。IESG的一项重要工作是监视所有工作组的输出，以帮助防止IETF协议相互冲突。这就是为什么广告应该审查来自不同领域的草稿。
The IAB is responsible for keeping an eye on the "big picture" of the Internet, and it focuses on long-range planning and coordination among the various areas of IETF activity. The IAB stays informed about important long-term issues in the Internet, and it brings these topics to the attention of people it thinks should know about them. The IAB web site is at http://www.iab.org/.
IAB负责关注互联网的“大局”，并专注于IETF活动各个领域之间的长期规划和协调。IAB会随时了解互联网上的重要长期问题，并将这些话题提请其认为应该了解的人注意。IAB网站位于http://www.iab.org/.
IAB members pay special attention to emerging activities in the IETF. When a new IETF Working Group is proposed, the IAB reviews its charter for architectural consistency and integrity. Even before the group is chartered, the IAB members are more than willing to discuss new ideas with the people proposing them.
IAB成员特别关注IETF中出现的活动。当提出新的IETF工作组时，IAB将审查其架构一致性和完整性章程。甚至在集团特许成立之前，IAB成员就非常愿意与提出新想法的人讨论新想法。
The IAB also sponsors and organizes the Internet Research Task Force and convenes invitational workshops that provide in-depth reviews of specific Internet architectural issues. Typically, the workshop reports make recommendations to the IETF community and to the IESG.
IAB还赞助和组织互联网研究工作组，并召开邀请研讨会，深入审查具体的互联网架构问题。通常，研讨会报告向IETF社区和IESG提出建议。
The IAB also:
The IAB also:translate error, please retry
o Approves NomCom's IESG nominations
o 批准NomCom的IESG提名
o Acts as the appeals board for appeals against IESG actions
o 担任针对IESG行动的上诉委员会
o Appoints and oversees the RFC Editor
o 任命并监督RFC编辑
o Approves the appointment of the IANA
o 批准IANA的任命
o Acts as an advisory body to ISOC
o 担任ISOC的咨询机构
o Oversees IETF liaisons with other standards bodies
o 监督IETF与其他标准机构的联络
Like the IESG, the IAB members are selected for multi-year positions by the NomCom and are approved by the ISOC Board of Trustees.
与IESG一样，IAB成员由NomCom选择担任多年职位，并由ISOC董事会批准。
The core registrar for the IETF's activities is the IANA. Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out. Typical examples of the kinds of registries needed are for TCP port numbers and MIME types. The IAB has designated the IANA organization to perform these tasks, and the IANA's activities are financially supported by ICANN, the Internet Corporation for Assigned Names and Numbers.
IETF活动的核心注册机构是IANA。许多互联网协议要求有人跟踪协议发布后添加的协议项。TCP端口号和MIME类型是所需注册表类型的典型示例。IAB已指定IANA组织执行这些任务，IANA的活动由ICANN（互联网名称和号码分配公司）提供财政支持。
Ten years ago, no one would have expected to see the IANA mentioned on the front page of a newspaper. IANA's role had always been very low key. The fact that IANA was also the keeper of the root of the domain name system forced it to become a much more public entity, one that was badly maligned by a variety of people who never looked at what its role was. Nowadays, the IETF is generally no longer involved in the IANA's domain name and IP address assignment functions, which are overseen by ICANN.
十年前，没有人会想到报纸头版会提到IANA。伊安娜的角色一直都很低调。IANA同时也是域名系统根源的守护者，这一事实迫使它成为了一个更加公开的实体，一个受到了各种各样的人的严重诽谤的实体，这些人从未考虑过它的角色是什么。如今，IETF一般不再参与IANA的域名和IP地址分配功能，这些功能由ICANN监管。
Even though being a registrar may not sound interesting, many IETF participants will testify to how important IANA has been for the Internet. Having a stable, long-term repository run by careful and conservative operators makes it much easier for people to experiment without worrying about messing things up. IANA's founder, Jon Postel, was heavily relied upon to keep things in order while the Internet kept growing by leaps and bounds, and he did a fine job of it until his untimely death in 1998.
尽管作为一名注册官听起来可能并不有趣，但许多IETF参与者将证明IANA对互联网的重要性。拥有一个由谨慎保守的运营商运行的稳定、长期的存储库，让人们更容易进行实验，而不用担心把事情搞砸。IANA的创始人乔恩·波斯特尔（Jon Postel）在互联网飞速发展的同时，一直依靠他来维持秩序，他在这方面做得很好，直到1998年他不合时宜地去世。
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, working in conjunction with the IESG. An important secondary role is to provide one definitive repository for all RFCs (see http://www.rfc-editor.org). Once an RFC is published, it is never revised. If the standard it describes changes, the standard will be re-published in another RFC that "obsoletes" the first.
RFC编辑器与IESG合作，以RFC的形式编辑、格式化和发布互联网草稿。一个重要的次要角色是为所有RFC提供一个最终存储库（请参见http://www.rfc-editor.org). RFC一旦发布，就永远不会修改。如果所描述的标准发生变化，该标准将在另一个“淘汰”第一个RFC中重新发布。
One of the most popular misconceptions in the IETF community is that the role of the RFC Editor is performed by IANA. In fact, the RFC Editor is a separate job, although both the RFC Editor and IANA involved the same people for many years. The IAB approves the organization that will act as RFC Editor and the RFC Editor's general policy. The RFC Editor is funded by IASA and can be contacted by email at mailto:rfc-editor@rfc-editor.org.
IETF社区中最常见的误解之一是RFC编辑器的角色由IANA执行。事实上，RFC编辑器是一项独立的工作，尽管RFC编辑器和IANA多年来都涉及同一个人。IAB批准担任RFC编辑的组织和RFC编辑的一般政策。RFC编辑器由IASA资助，可通过电子邮件联系mailto:RFC-editor@rfc-editor.org。
There are, in fact, a few people who are paid to maintain the IETF. The IETF Secretariat provides day-to-day logistical support, which mainly means coordinating face-to-face meetings and running the IETF-specific mailing lists (not the WG mailing lists). The Secretariat is also responsible for keeping the official Internet Drafts directory up to date and orderly, maintaining the IETF web site, and helping the IESG do its work. It provides various tools for use by the community and the IESG. The IETF Secretariat is under contract to IASA, which in turn is financially supported by the fees of the face-to-face meetings.
事实上，有一些人是为维护IETF而付费的。IETF秘书处提供日常后勤支持，这主要意味着协调面对面会议和运行IETF特定邮件列表（而非工作组邮件列表）。秘书处还负责使官方互联网草稿目录保持最新和有序，维护IETF网站，并帮助IESG开展工作。它提供各种工具供社区和IESG使用。IETF秘书处与IASA签订了合同，IASA又通过面对面会议的费用获得财政支持。
Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, mailto:ietf-announce@ietf.org. This is where all of the meeting information, RFC announcements, and IESG Protocol Actions and Last Calls are posted. People who would like to "get technical" may also join the IETF general discussion list, ietf@ietf.org. This is where discussions of cosmic significance are held (Working Groups have their own mailing lists for discussions related to their work). Another mailing list, mailto:i-d-announce@ietf.org, announces each new version of every Internet Draft as it is published.
计划参加IETF会议的任何人都应加入IETF公告邮件列表，邮件收件人：IETF-announce@ietf.org. 这是发布所有会议信息、RFC公告、IESG协议操作和最后通话的地方。希望“掌握技术”的人也可以加入IETF一般性讨论列表，ietf@ietf.org. 这是举行具有宇宙意义的讨论的地方（工作组有自己的邮件列表，用于与工作相关的讨论）。另一个邮件列表，mailto:i-d-announce@ietf.org，公布每一份互联网草稿的新版本。
Subscriptions to these and other IETF-run mailing lists are handled by a program called "mailman". Mailman can be somewhat finicky about the format of subscription messages, and sometimes interacts poorly with email programs that make all email messages into HTML files. Mailman will treat you well, however, if you format your messages just the way it likes.
对这些和其他IETF运行的邮件列表的订阅由一个名为“mailman”的程序处理。邮递员可能对订阅邮件的格式有点挑剔，有时与将所有电子邮件都转换为HTML文件的电子邮件程序的交互很差。然而，如果你按照邮件喜欢的格式发送邮件，邮递员会对你很好。
To join the IETF announcement list, for example, send email to mailto:ietf-announce-request@ietf.org. Enter the word 'subscribe' (without the quotes) in the Subject line of the message and in the message body. To join the IETF discussion list, send email to <mailto:ietf-request@ietf.org> and enter the word 'subscribe' as explained above. If you decide to withdraw from either list, use the word 'unsubscribe'. Your messages to mailman should have nothing other than the commands 'subscribe' or 'unsubscribe' in them. Both lists are archived on the IETF web site, http://www.ietf.org/maillist.html.
例如，要加入IETF公告列表，请发送电子邮件至mailto:IETF announce-request@ietf.org. 在邮件的主题行和邮件正文中输入单词“subscribe”（不带引号）。要加入IETF讨论列表，请发送电子邮件至<mailto:IETF-request@ietf.org>并输入“订阅”一词，如上所述。如果您决定退出任一列表，请使用“取消订阅”一词。您发送给邮递员的邮件中应该只有“订阅”或“取消订阅”命令。两份清单都存档在IETF网站上，http://www.ietf.org/maillist.html.
Do not, ever, under any circumstances, for any reason, send a request to join a list to the list itself! The thousands of people on the list don't need, or want, to know when a new person joins. Similarly, when changing email addresses or leaving a list, send your request only to the "-request" address, not to the main list. This means you!!
在任何情况下，无论出于何种原因，都不要向列表本身发送加入列表的请求！名单上成千上万的人不需要或不想知道一个新人何时加入。同样，在更改电子邮件地址或留下列表时，只将请求发送到“-request”地址，而不是主列表。这意味着你！！
The IETF discussion list is unmoderated. This means that all can express their opinions about issues affecting the Internet. However, it is not a place for companies or individuals to solicit or advertise, as noted in [BCP45], "IETF Discussion List Charter". It is a good idea to read the whole RFC (it's short!) before posting to the IETF discussion list. Actually, the list does have two "sergeants at arms" who keep an eye open for inappropriate postings, and there is a process for banning persistent offenders from the list, but fortunately this is extremely rare.
IETF讨论列表未降额。这意味着所有人都可以就影响互联网的问题发表意见。然而，正如[BCP45]“IETF讨论列表章程”中所述，它不是公司或个人招揽或宣传的场所。在发布到IETF讨论列表之前，最好先阅读整个RFC（很短！）。事实上，名单上确实有两名“武装中士”，他们密切注意不适当的张贴，并且有一个程序禁止名单上的持续犯罪者，但幸运的是，这是极为罕见的。
Only the Secretariat and certain IETF office holders can approve messages sent to the announcement list, although those messages can come from a variety of people.
只有秘书处和某些IETF官员可以批准发送到公告列表的消息，尽管这些消息可能来自不同的人。
Even though the IETF mailing lists "represent" the IETF membership at large, it is important to note that attending an IETF meeting does not mean you'll be automatically added to either mailing list.
尽管IETF邮件列表“代表”了IETF的全体成员，但重要的是要注意，参加IETF会议并不意味着您将自动添加到任一邮件列表中。
The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face-to-face meetings are nothing like these. The meetings, held three times a year, are week-long "gatherings of the tribes" whose primary goal is to reinvigorate the WGs to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the WGs and the areas. The cost of the meetings is paid by the people attending and by the corporate host for each meeting (if any), although IASA kicks in additional funds for things such as the audio broadcast of some Working Group sessions.
计算机行业充斥着会议、研讨会、展览和各种各样的会议。IETF面对面会议与此完全不同。这些会议每年举行三次，为期一周的“部落聚会”，其主要目标是重振工作组以完成其任务，其次要目标是促进工作组与各地区之间的合理混合。会议费用由出席人员和每次会议的公司主持人（如有）支付，尽管IASA为一些工作组会议的音频广播等事项提供了额外资金。
For many people, IETF meetings are a breath of fresh air when compared to the standard computer industry conferences. There is no exposition hall, few tutorials, and no big-name industry pundits. Instead, there is lots of work, as well as a fair amount of time for socializing. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers.
对于许多人来说，与标准的计算机行业会议相比，IETF会议是一股新鲜空气。这里没有展览厅，很少有教程，也没有知名的行业专家。相反，这里有很多工作，也有相当多的社交时间。销售和营销人员对IETF会议不感兴趣，但工程师和开发人员对IETF会议感兴趣。
Most IETF meetings are held in North America, because that's where most of the participants are from; however, meetings are held on other continents about once every year. The past few meetings have
大多数IETF会议在北美举行，因为大部分参与者都来自北美；然而，会议每年大约在其他大陆举行一次。过去几次会议已经结束
had about 1,300 attendees. There have been more than 65 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.
大约有1300名与会者。到目前为止，已经有超过65次IETF会议，IETF网页上提供了即将召开的会议列表，http://www.ietf.org/meetings/0mtg-sites.txt.
Newcomers to IETF face-to-face meetings are often in a bit of shock. They expect them to be like other standards bodies, or like computer conferences. Fortunately, the shock wears off after a day or two, and many new attendees get quite animated about how much fun they are having. One particularly jarring feature of recent IETF meetings is the use of wireless Internet connections throughout the meeting space. It is common to see people in a WG meeting apparently reading email or perusing the web during presentations they find uninteresting. Remember, however, that they may also be consulting the drafts under discussion, looking up relevant material online, or following another meeting using instant messaging.
IETF面对面会议的新手通常会感到有点震惊。他们希望他们像其他标准机构一样，或者像计算机会议一样。幸运的是，一两天后，这种震惊就消失了，许多新与会者对他们的乐趣感到非常兴奋。最近IETF会议的一个特别令人不安的特点是在整个会议空间使用无线互联网连接。在工作组会议上，很常见的情况是，人们在他们觉得无趣的演讲过程中阅读电子邮件或浏览网页。但是，请记住，他们也可能在查阅讨论中的草稿、在线查找相关材料，或者在使用即时消息的另一次会议之后。
To attend an IETF meeting, you have to register and you have to pay the registration fee. The meeting site and advance registration are announced about two months ahead of the meeting -- earlier if possible. An announcement goes out via email to the IETF-announce mailing list, and information is posted on the IETF web site, http://www.ietf.org, that same day.
要参加IETF会议，您必须注册并支付注册费。会议地点和预先登记将在会议召开前两个月左右公布——如果可能的话，提前公布。公告通过电子邮件发送至IETF公告邮件列表，信息发布在IETF网站上，http://www.ietf.org，当天。
To pre-register, you must submit your registration on the web. You may pre-register and pre-pay, pre-register and return to the web site later to pay with a credit card, pre-register and pay on-site at the meeting, or register and pay on-site. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening reception (cash bar), daily continental breakfasts, and afternoon coffee and snack breaks.
要预注册，您必须在web上提交注册。您可以预先注册并预付，预先注册并稍后返回网站以使用信用卡支付，在会议上预先注册并在现场支付，或在现场注册并支付。为了获得更低的注册费，您必须在提前的注册截止日期（会议前一周左右）之前支付。注册费包括一周的所有会议、周日晚上的招待会（现金吧）、每天的欧式早餐以及下午的咖啡和点心时间。
Credit card payments on the web are encrypted and secure, or, if you prefer, you can use Pretty Good Privacy (PGP) to send your payment information to the Registrar (mailto:ietf-registrar@ietf.org).
网上的信用卡支付是加密和安全的，或者，如果您愿意，您可以使用相当好的隐私（PGP）将您的支付信息发送给注册机构（mailto:ietf）-registrar@ietf.org).
Registration is open throughout the week of the meeting. However, the Secretariat highly recommends that attendees arrive for early registration, usually beginning at noon on Sunday and continuing throughout the Sunday evening reception. The reception is a popular event where you can get a small bite to eat and socialize with other early arrivals.
整个会议的一周都开放注册。然而，秘书处强烈建议与会者提前登记，通常从周日中午开始，一直持续到周日晚上的招待会。招待会是一个很受欢迎的活动，在那里你可以吃点东西，并与其他提前到达的人进行社交活动。
Registered attendees (and there aren't any other kind) receive a registration packet. It contains much useful information, including a general orientation sheet, the most recent agenda, and a name tag.
注册的与会者（没有其他类型的人）收到一个注册包。它包含了很多有用的信息，包括一张总体介绍表、最近的议程和一个姓名标签。
Attendees who pre-paid will also find their receipt in their packet. It's worth noting that neither attendee names and addresses nor IETF mailing lists are ever offered for sale.
预付费的与会者也会在他们的包裹中找到收据。值得注意的是，与会者姓名和地址以及IETF邮件列表均未出售。
In your registration packet is a sheet titled "Note Well". You should indeed read it carefully because it lays out the rules for IETF intellectual property rights.
在您的注册资料袋中有一张题为“注意事项”。您确实应该仔细阅读，因为它列出了IETF知识产权的规则。
If you need to leave messages for other attendees, you can do so at the cork boards that are often near the registration desk. These cork boards will also have last-minute meeting changes and room changes.
如果你需要给其他与会者留言，你可以在登记台附近的软木板上留言。这些软木板还将在最后一分钟更改会议和房间。
You can also turn in lost-and-found items to the registration desk. At the end of the meeting, anything left over from the lost and found will usually be turned over to the hotel or brought back to the Secretariat's office.
您还可以将失物招领物品交到登记台。在会议结束时，失物招领处遗留下来的任何东西通常会被移交给旅馆或带回秘书处办公室。
Incidentally, the IETF registration desk is often a convenient place to arrange to meet people. If someone says "meet me at registration", they almost always mean the IETF registration desk, not the hotel registration desk.
顺便说一句，IETF登记台通常是安排会见人员的方便场所。如果有人说“在登记处见我”，他们几乎总是指IETF登记处，而不是酒店登记处。
IETF meetings last from Monday morning through Friday lunchtime. Associated meetings often take place on the preceding or following weekends. It is best to plan to be present the whole week, to benefit from cross-fertilization between Working Groups and from corridor discussions. As noted below, the agenda is fluid, and there have been many instances of participants missing important sessions due to last-minute scheduling changes after their travel plans were fixed. Being present the whole week is the only way to avoid this annoyance.
IETF会议从周一上午持续到周五午餐时间。相关会议通常在周末前后举行。最好计划整个星期都出席，从工作组之间的相互交流和走廊讨论中获益。如下文所述，议程是不固定的，许多与会者在旅行计划确定后由于最后一分钟的日程安排变化而错过了重要会议。整整一周都在场是避免这种烦恼的唯一方法。
If you cannot find meetings all week to interest you, you can still make the most of the IETF meeting by working between sessions. Most IETF attendees carry laptop computers, and it is common to see many of them in the terminal room or in the hallways working during meeting sessions. There is often good wireless Internet coverage in many places of the meeting venue (restaurants, coffee shops, and so on), so catching up on email when not in meetings is a fairly common task for IETFers.
如果你找不到一整周让你感兴趣的会议，你仍然可以通过在会议之间工作来充分利用IETF会议。大多数IETF与会者都携带笔记本电脑，在会议期间，通常会看到他们中的许多人在终端室或走廊工作。在会议地点的许多地方（餐馆、咖啡馆等），通常都有良好的无线互联网覆盖，因此，在不开会的情况下回复电子邮件是IETFER的一项相当常见的任务。
Newcomers are encouraged to attend the Newcomer Training, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what's in the attendee packets, what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers.
鼓励新员工参加新员工培训，该培训专为首次参加培训的员工设计。该培训由IETF EDU团队组织和实施，旨在提供有用的介绍信息。本课程涵盖了与会者信息包中的内容、姓名标签上的所有点的含义、IETF的结构以及新IETF的许多其他重要和启发性主题。
Immediately following the Newcomers' Training is the IETF Standards Process Orientation. This session demystifies much of the standards process by explaining what stages a document has to pass through on its way to becoming a standard, and what has to be done to advance to the next stage.
紧接着新员工培训的是IETF标准过程指导。本课程通过解释文档在成为标准的过程中必须经过哪些阶段，以及必须采取哪些措施才能进入下一个阶段，从而揭开标准过程的神秘面纱。
There is usually ample time at the end for questions. The Secretariat provides hard copies of the slides of the "IETF Structure and Internet Standards Process" presentation -- these very useful slides are also available online at www.ietf.org under "Educational Materials".
通常在结尾有足够的时间提问。秘书处提供了“IETF结构和互联网标准过程”演示文稿的硬拷贝——这些非常有用的幻灯片也可在www.IETF.org的“教育材料”下在线获取。
The orientation is normally held on Sunday afternoon, along with tutorials of interest to newcomers and old-timers alike. Check the agenda for exact times and locations.
介绍会通常在周日下午举行，同时还有新老同学都感兴趣的教程。查看日程，了解确切的时间和地点。
Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. Seriously though, many newcomers are often embarrassed when they show up Monday morning in suits, to discover that everybody else is wearing T-shirts, jeans (shorts, if weather permits) and sandals. There are those in the IETF who refuse to wear anything other than suits. Fortunately, they are well known (for other reasons) so they are forgiven this particular idiosyncrasy. The general rule is "dress for the weather" (unless you plan to work so hard that you won't go outside, in which case, "dress for comfort" is the rule!).
由于与会者必须佩戴姓名标签，他们还必须穿衬衫或衬衫。强烈建议穿裤子或裙子。不过，说真的，许多新来者在周一早上穿着西装出现时，发现其他人都穿着T恤、牛仔裤（如果天气允许，可以穿短裤）和凉鞋，常常感到尴尬。IETF中有些人拒绝穿西装以外的任何衣服。幸运的是，他们是众所周知的（出于其他原因），所以他们被原谅了这种特殊的特质。一般的规则是“穿着适合天气”（除非你计划努力工作而不出门，在这种情况下，“穿着舒适”是规则！）。
Some of the people at the IETF will have a little colored dot on their name tag. A few people have more than one. These dots identify people who are silly enough to volunteer to do a lot of extra work. The colors have the meanings shown here.
IETF的一些人的姓名标签上会有一个小点。少数人有不止一个。这些点表示那些愚蠢到自愿做大量额外工作的人。颜色具有此处所示的含义。
Color Meaning
--------------------------------------
Blue Working Group/BOF chair
Green Host group
Red IAB member
Yellow IESG member
Orange Nominating Committee member
Color Meaning
--------------------------------------
Blue Working Group/BOF chair
Green Host group
Red IAB member
Yellow IESG member
Orange Nominating Committee member
(Members of the press wear orange-tinted badges.)
（媒体成员佩戴橙色徽章。）
Local hosts are the people who can answer questions about the terminal room, restaurants, and points of interest in the area.
当地主持人是可以回答有关航站楼、餐厅和该地区景点的问题的人。
It is important that newcomers to the IETF not be afraid to strike up conversations with people who wear these dots. If the IAB and IESG members and Working Group and BOF chairs didn't want to talk to anybody, they wouldn't be wearing the dots in the first place.
IETF的新来者不要害怕与佩戴这些圆点的人交谈，这一点很重要。如果IAB和IESG成员、工作组和BOF主席不想与任何人交谈，他们一开始就不会戴上圆点。
One of the most important (depending on your point of view) things the host does is provide Internet access for the meeting attendees. In general, wired and wireless connectivity is excellent. This is entirely due to the Olympian efforts of the local hosts and their ability to beg, borrow, and steal. The people and companies that donate their equipment, services, and time are to be heartily congratulated and thanked.
主持人所做的最重要的事情之一（取决于您的观点）是为与会者提供互联网接入。一般来说，有线和无线连接都非常好。这完全是由于当地东道主在奥运会上的努力以及他们乞讨、借贷和偷窃的能力。向捐赠设备、服务和时间的人们和公司表示衷心的祝贺和感谢。
Although preparation far in advance of the meeting is encouraged, there may be some unavoidable "last minute" things that can be accomplished in the terminal room. It may also be useful to people who need to make trip reports or status reports while things are still fresh in their minds.
尽管鼓励在会议召开之前进行充分准备，但可能会有一些不可避免的“最后一分钟”的事情可以在候机室完成。它也可能对那些需要在头脑中还记忆犹新的时候做旅行报告或状态报告的人有用。
You need to be wearing your badge in order to get into the terminal room. The terminal room provides lots of power strips, lots of Ethernet ports for laptops, wireless (for the people who don't need Ethernet but want power), usually a printer for public use, and sometimes workstations. What it doesn't provide are terminals; the name is historical. The help desk in the terminal room is a good place to ask questions about network failures, although they might point you off to different networking staff.
你需要佩戴徽章才能进入候机室。终端室提供大量的电源板、笔记本电脑的以太网端口、无线（为不需要以太网但需要电源的人提供）、通常是供公用的打印机，有时还提供工作站。它不提供的是终端；这个名字是历史性的。候机室的服务台是询问网络故障的好地方，尽管它们可能会将您引向不同的网络工作人员。
Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners". Although it is true that some people eat very well at the IETF, they find the food on their own; lunches and
马歇尔·罗斯（Marshall Rose）曾经说过，IETF是一个“许多美味午餐和晚餐”的去处。虽然确实有些人在IETF吃得很好，但他们是自己找到食物的；午餐和
dinners are not included in the registration fee. The Secretariat does provide appetizers at the Sunday evening reception (not meant to be a replacement for dinner), continental breakfast every morning, and (best of all) cookies, brownies, and other yummies during afternoon breaks.
注册费不包括晚餐。秘书处确实在周日晚上的招待会上提供开胃菜（并非取代晚餐）、每天早上的欧式早餐，以及（最重要的是）下午休息时的饼干、布朗尼和其他美味佳肴。
If you prefer to get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site.
如果你想离开酒店吃饭，当地的主人通常会提供一份在会议地点附近的用餐地点清单。
Another of the most important things organized and managed by the host is the IETF social event. Sometimes, the social event is a computer- or high-tech-related event. At one Boston IETF, for example, the social was dinner at the Computer Museum. Other times, the social might be a dinner cruise or a trip to an art gallery. Note, however, that not all IETF meetings have social events.
由主持人组织和管理的另一项最重要的活动是IETF社交活动。有时，社交活动是与计算机或高科技相关的活动。例如，在波士顿的一次IETF上，社交聚会在计算机博物馆举行。其他时候，社交活动可能是一次晚宴巡游或是一次艺术画廊之旅。然而，请注意，并非所有IETF会议都有社交活动。
Newcomers to the IETF are encouraged to attend the social event. All are encouraged to wear their name tags and leave their laptops behind. The social event is designed to give people a chance to meet on a social, rather than technical, level.
IETF的新成员被鼓励参加社交活动。所有人都被鼓励戴上自己的名牌，把笔记本电脑扔在身后。社交活动旨在让人们有机会在社交而非技术层面上见面。
The agenda for the IETF meetings is a very fluid thing. It is typically sent to the IETF announcement list a few times prior to the meeting, and it is also available on the web. The final agenda is included in the registration packets. Of course, "final" in the IETF doesn't mean the same thing as it does elsewhere in the world. The final agenda is simply the version that went to the printer. The Secretariat will post agenda changes on the bulletin board near the IETF registration desk (not the hotel registration desk). These late changes are not capricious: they are made "just in time" as session chairs and speakers become aware of unanticipated clashes. The IETF is too dynamic for agendas to be tied down weeks in advance.
IETF会议的议程是一个非常不稳定的事情。它通常在会议前几次发送到IETF公告列表，也可以在web上获得。最终议程包含在注册包中。当然，IETF中的“最终”并不像世界上其他地方那样意味着同样的事情。最后的议程只是送到打印机的版本。秘书处将在IETF登记处（而非酒店登记处）附近的公告板上张贴议程变更。这些晚些时候的变化并不是反复无常的：它们是在会议主席和发言者意识到意外冲突时“及时”做出的。IETF过于动态，无法提前几周将议程固定下来。
Assignments for breakout rooms (where the Working Groups and BOFs meet) and a map showing the room locations are also shown on the agenda. Room assignments can change as the agenda changes. Some Working Groups meet multiple times during a meeting, and every attempt is made to have a Working Group meet in the same room for each session.
会议议程上还显示了分组会议室的分配（工作组和BOF开会的地方）和显示会议室位置的地图。房间分配可以随着日程的变化而变化。一些工作组在一次会议期间举行多次会议，每次会议都试图让一个工作组在同一个房间开会。
If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team. These informal classes are designed for newcomers and seasoned IETFers alike. In addition to the Newcomer Training, the EDU team offers workshops for document editors and Working Group chairs, plus an in-depth security tutorial that's indispensable for both novices and longtime IETF attendees. EDU sessions are generally held on Sunday afternoons. You'll find more about the EDU team at http://edu.ietf.org/.
如果IETF的某些方面仍然让你感到困惑（即使在你读完Tao之后），你会想去参加教育（EDU）团队提供的现场培训。这些非正式课程是为新手和经验丰富的新手设计的。除了新手培训外，EDU团队还为文档编辑和工作组主席提供研讨会，以及对新手和IETF长期参与者都必不可少的深入安全教程。EDU课程通常在周日下午举行。您将在以下网址找到更多关于EDU团队的信息：http://edu.ietf.org/.
The IETF is different things to different people. There are many people who have been very active in the IETF who have never attended an IETF meeting. You should not feel obligated to come to an IETF meeting just to get a feel for the IETF. The following guidelines (based on stereotypes of people in various industries) might help you decide whether you actually want to come and, if so, what might be the best use of your time at your first meeting.
IETF对不同的人来说是不同的。许多人在IETF中非常活跃，他们从未参加过IETF会议。你不应该觉得有义务参加IETF会议只是为了感受IETF。下面的指导原则（基于不同行业的人的刻板印象）可能会帮助你决定是否真的想来，如果真的想来，在第一次会议上什么是最好的时间利用方式。
As discussed throughout this document, an IETF meeting is nothing like any trade show you have attended. IETF meetings are singularly bad places to go if your intention is to find out what will be hot in the Internet industry next year. You can safely assume that going to Working Group meetings will confuse you more than it will help you understand what is happening, or will be happening, in the industry.
正如本文件中所讨论的，IETF会议与您参加过的任何贸易展览会完全不同。如果你想了解明年互联网行业的热点，那么IETF会议是一个非常糟糕的去处。你可以放心地认为，参加工作组会议会让你更加困惑，而不是帮助你了解行业正在发生或将要发生的事情。
This is not to say that no one from the industry should go to IETF meetings. As an IS manager, you might want to consider sending specific people who are responsible for technologies that are under development in the IETF. As these people read the current Internet Drafts and the traffic on the relevant Working Group lists, they will get a sense of whether or not their presence would be worthwhile for your company or for the Working Groups.
这并不是说业内人士不应该参加IETF会议。作为一名IS经理，您可能需要考虑发送负责IETF中正在开发的技术的特定人员。当这些人阅读当前的互联网草稿和相关工作组列表上的流量时，他们会意识到他们的存在是否值得为您的公司或工作组服务。
Running a network is hard enough without having to grapple with new protocols or new versions of the protocols with which you are already dealing. If you work for the type of network that is always using the very latest hardware and software, and you are following the relevant Working Groups in your copious free time, you could certainly find participating in the IETF valuable. A fair amount of IETF work also covers many other parts of operations of ISPs and
运行一个网络已经够困难的了，而不需要处理新的协议或协议的新版本。如果您的网络类型始终使用最新的硬件和软件，并且在充裕的空闲时间内跟随相关的工作组，那么您肯定会发现参加IETF很有价值。相当数量的IETF工作还包括ISP和网络运营的许多其他部分
large enterprises, and the input of operators is quite valuable to keep this work vibrant and relevant. Many of the best operations documents from the IETF come from real-world operators, not vendors and academics.
大型企业和运营商的投入对于保持这项工作的活力和相关性非常有价值。IETF中的许多最佳操作文档来自现实世界的运营商，而不是供应商和学者。
The image of the IETF being mostly ivory tower academics may have been true in the past, but the jobs of typical attendees are now in industry. In most areas of the IETF, employees of vendors are the ones writing the protocols and leading the Working Groups, so it's completely appropriate for vendors to attend. If you create Internet hardware or software, and no one from your company has ever attended an IETF meeting, it behooves you to come to a meeting if for no other reason than to tell the others how relevant the meeting was or was not to your business.
IETF大多是象牙塔学者的形象在过去可能是真实的，但典型与会者的工作现在已经进入了行业。在IETF的大多数领域，供应商的员工是编写协议和领导工作组的人，因此供应商完全适合参加。如果您创建了Internet硬件或软件，并且您的公司没有人参加过IETF会议，那么您应该参加会议，如果没有其他原因，只是为了告诉其他人会议与您的业务有多相关。
This is not to say that companies should close up shop during IETF meeting weeks so everyone can go to the meeting. Marketing folks, even technical marketing folks, are usually safe in staying away from the IETF as long as some of the technical people from the company are at the meeting. Similarly, it isn't required, or likely useful, for everyone from a technical department to go, particularly if they are not all reading the Internet Drafts and following the Working Group mailing lists. Many companies have just a few designated meeting attendees who are chosen for their ability to do complete and useful trip reports. In addition, many companies have internal coordination efforts and a standards strategy. If a company depends on the Internet for some or all of its business, the strategy should probably cover the IETF.
这并不是说公司应该在IETF会议周内关闭店铺，以便每个人都可以参加会议。营销人员，甚至技术营销人员，只要公司的一些技术人员出席会议，通常都可以安全地远离IETF。同样，对于技术部门的每个人来说，这不是必需的，也可能不是有用的，特别是如果他们不是都在阅读互联网草稿并遵循工作组邮件列表的话。许多公司只有少数指定的会议参与者，他们被选中是因为他们有能力完成完整而有用的旅行报告。此外，许多公司都有内部协调工作和标准战略。如果一家公司的部分或全部业务依赖于互联网，则该战略可能涵盖IETF。
IETF meetings are often excellent places for computer science folks to find out what is happening in the way of soon-to-be-deployed protocols. Professors and grad students (and sometimes overachieving undergrads) who are doing research in networking or communications can get a wealth of information by following Working Groups in their specific fields of interest. Wandering into different Working Group meetings can have the same effect as going to symposia and seminars in your department. Researchers are also, of course, likely to be interested in IRTF activities.
IETF会议通常是计算机科学人员了解即将部署的协议的最佳场所。从事网络或通信研究的教授和研究生（有时是成绩优异的本科生）可以通过跟踪他们感兴趣的特定领域的工作组获得大量信息。在不同的工作组会议上闲逛会产生与在你的部门参加专题讨论会和研讨会相同的效果。当然，研究人员也可能对IRTF活动感兴趣。
If you're a member of the press and are considering attending IETF, we've prepared a special section of the Tao just for you -- please see Section 10.2.
如果您是媒体的一员，并且正在考虑参加IETF，我们为您准备了一个专门的Tao章节——请参阅第10.2节。
IETF proceedings are compiled in the two months following each meeting and are available on the web and on CD. Be sure to look through a copy -- the proceedings are filled with information about IETF that you're not likely to find anywhere else. For example, you'll find snapshots of most WG charters at the time of the meeting, giving you a better understanding of the evolution of any given effort.
IETF会议记录在每次会议后的两个月内进行汇编，可在web和CD上查阅。一定要翻阅一份副本——会议记录中充满了关于IETF的信息，而这些信息在其他任何地方都找不到。例如，您将在会议期间找到大多数工作组章程的快照，从而更好地了解任何给定工作的发展。
The proceedings sometimes start with an informative (and highly entertaining) message. Each volume contains the final (hindsight) agenda, an IETF overview, area and Working Group reports, and slides from the protocol and technical presentations. The Working Group reports and presentations are sometimes incomplete, if the materials haven't been turned in to the Secretariat in time for publication.
会议过程有时以信息丰富（且极具娱乐性）的信息开始。每卷都包含最终（事后）议程、IETF概述、区域和工作组报告，以及协议和技术演示的幻灯片。如果材料没有及时提交秘书处出版，工作组的报告和介绍有时是不完整的。
An attendee list is also included, which contains names and affiliations as provided on the registration form. For information about obtaining copies of the proceedings, see the web listing at http://www.ietf.org/proceedings/directory.html.
还包括与会者名单，其中包含登记表上提供的姓名和联系。有关获取会议记录副本的信息，请参阅http://www.ietf.org/proceedings/directory.html.
The IETF Secretariat, and IETFers in general, are very approachable. Never be afraid to approach someone and introduce yourself. Also, don't be afraid to ask questions, especially when it comes to jargon and acronyms.
IETF秘书处和IETFER总体上都非常平易近人。永远不要害怕接近某人并介绍自己。另外，不要害怕问问题，特别是当涉及到行话和首字母缩略词时。
Hallway conversations are very important. A lot of very good work gets done by people who talk together between meetings and over lunches and dinners. Every minute of the IETF can be considered work time (much to some people's dismay).
走廊上的对话非常重要。很多非常好的工作都是由在会议之间、午餐和晚餐时一起交谈的人完成的。IETF的每一分钟都可以被视为工作时间（让一些人感到沮丧）。
A "bar BOF" is an unofficial get-together, usually in the late evening, during which a lot of work gets done over drinks. Bar BOFs spring up in many different places around an IETF meeting, such as restaurants, coffee shops, and (if we are so lucky) pools.
“酒吧聚会”是一种非正式的聚会，通常在深夜举行，其间许多工作都是在喝酒的时候完成的。IETF会议期间，酒吧BOF在许多不同的地方涌现，如餐厅、咖啡馆和（如果我们运气好的话）游泳池。
It's unwise to get between a hungry IETFer (and there isn't any other kind) and coffee break brownies and cookies, no matter how interesting a hallway conversation is.
不管走廊上的谈话有多有趣，在饥饿的便笺簿（而且没有其他种类的便笺簿）和咖啡休息时间的巧克力饼和饼干之间徘徊是不明智的。
IETFers are fiercely independent. It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders.
他们是非常独立的。质疑意见和提供替代方案是安全的，但不要指望听命于人。
The IETF meetings, and the plenary session in particular, are not places for vendors to try to sell their wares. People can certainly answer questions about their company and its products, but bear in mind that the IETF is not a trade show. This does not preclude people from recouping costs for IETF-related T-shirts, buttons, and pocket protectors.
IETF会议，特别是全体会议，不是供应商试图销售其产品的场所。人们当然可以回答有关他们公司及其产品的问题，但请记住，IETF不是一个贸易展览会。这并不妨碍人们收回与IETF相关的T恤、纽扣和口袋保护器的费用。
There is always a "materials distribution table" near the registration desk. This desk is used to make appropriate information available to the attendees (e.g., copies of something discussed in a Working Group session, descriptions of online IETF-related information). Please check with the Secretariat before placing materials on the desk; the Secretariat has the right to remove material that he or she feels is not appropriate.
登记台附近总是有一张“材料分配表”。该办公桌用于向与会者提供适当的信息（例如，工作组会议中讨论的内容的副本、在线IETF相关信息的描述）。在将材料放在桌子上之前，请与秘书处核对；秘书处有权删除他或她认为不适当的材料。
If you rely on your laptop during the meeting, it is a good idea to bring an extra battery. It is not always easy to find a spare outlet in some meeting rooms, and using the wireless access can draw down your battery faster than you might expect. If you are sitting near a power-strip in a meeting room, expect to be asked to plug and unplug for others around you. Many people bring an extension cord with spare outlets, which is a good way to make friends with your neighbor in a meeting. If you need an outlet adapter, you should try to buy it in advance because the one you need is usually easier to find in your home country.
如果你在会议期间依靠笔记本电脑，最好多带一块电池。在某些会议室中，要找到备用电源插座并不总是那么容易，使用无线接入可以比预期更快地消耗电池电量。如果你坐在会议室的电源板附近，你可能会被要求为你周围的其他人拔插电源。许多人都会带一根带备用插座的延长线，这是在会议中与邻居交朋友的好方法。如果你需要一个插座适配器，你应该试着提前购买，因为你需要的插座适配器通常在你的祖国更容易找到。
The vast majority of the IETF's work is done in many Working Groups; at the time of this writing, there are about 115 different WGs. (The term "Working Group" is often seen capitalized, but probably not for any good reason.) [BCP25], "IETF Working Group Guidelines and Procedures", is an excellent resource for anyone participating in WG discussions.
IETF的绝大多数工作是在许多工作组中完成的；在撰写本文时，大约有115个不同的工作组。（术语“工作组”通常被视为大写，但可能不是出于任何好的理由。）[BCP25]“IETF工作组指南和程序”对于任何参与工作组讨论的人来说都是极好的资源。
A WG is really just a mailing list with a bit of adult supervision. You "join" the WG by subscribing to the mailing list; all mailing lists are open to anyone. Anyone can post to a WG mailing list, although most lists require non-subscribers to have their postings moderated. Each Working Group has one or two chairs.
一个工作组实际上只是一个带有成人监督的邮件列表。您通过订阅邮件列表“加入”工作组；所有邮件列表对任何人开放。任何人都可以发布到工作组邮件列表，尽管大多数列表要求非订阅者对其发布进行审核。每个工作组有一个或两个主席。
More important, each WG has a charter that the WG is supposed to follow. The charter states the scope of discussion for the Working Group, as well as its goals. The WG's mailing list and face-to-face meetings are supposed to focus on just what is in the charter and not to wander off on other "interesting" topics. Of course, looking a bit outside the scope of the WG is occasionally useful, but the large majority of the discussion should be on the topics listed in the
更重要的是，每个工作组都有一个工作组应该遵循的章程。《宪章》规定了工作组的讨论范围及其目标。工作组的邮件列表和面对面的会议应该只关注章程中的内容，而不是偏离其他“有趣”的话题。当然，稍微超出工作组的范围有时是有用的，但是绝大多数的讨论应该是关于工作组中列出的主题
charter. In fact, some WG charters actually specify what the WG will not do, particularly if there were some attractive but nebulous topics brought up during the drafting of the charter. The list of all WG charters makes interesting reading for folks who want to know what the different Working Groups are supposed to be doing.
宪章事实上，一些工作组章程实际上规定了工作组不会做的事情，特别是如果在起草章程期间提出了一些有吸引力但模糊的主题。所有工作组章程的列表对于那些想知道不同工作组应该做什么的人来说是一本有趣的读物。
The role of the WG chairs is described in both [BCP11] and [BCP25]. The IETF EDU team also offers special training for WG chairs on Sunday afternoons preceding IETF.
工作组主席的角色在[BCP11]和[BCP25]中均有描述。IETF EDU团队还在IETF之前的周日下午为工作组主席提供特殊培训。
As volunteer cat-herders, a chair's first job is to determine the WG consensus goals and milestones, keeping the charter up to date. Next, often with the help of WG secretaries or document editors, the chair must manage WG discussion, both on the list and by scheduling meetings when appropriate. Sometimes discussions get stuck on contentious points and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over. Sometimes chairs also manage interactions with non-WG participants or the IESG, especially when a WG document approaches publication. Chairs have responsibility for the technical and non-technical quality of WG output. As you can imagine given the mix of secretarial, interpersonal, and technical demands, some Working Group chairs are much better at their jobs than others.
作为志愿养猫人，主席的第一项工作是确定工作组的共识目标和里程碑，使章程保持最新。其次，通常在工作组秘书或文件编辑的帮助下，主席必须管理工作组的讨论，包括在清单上以及在适当时安排会议。有时讨论会陷入争议点，主席可能需要引导人们进行富有成效的互动，然后宣布何时达成初步共识，讨论结束。有时，主席还负责管理与非工作组参与者或IESG的互动，特别是当工作组文件接近发布时。主席负责工作组产出的技术和非技术质量。你可以想象，考虑到秘书、人际关系和技术需求的混合，一些工作组主席的工作要比其他人好得多。
When a WG has fulfilled its charter, it is supposed to cease operations. (Most WG mailing lists continue on after a WG is closed, still discussing the same topics as the Working Group did.) In the IETF, it is a mark of success that the WG closes up because it fulfilled its charter. This is one of the aspects of the IETF that newcomers who have experience with other standards bodies have a hard time understanding. However, some WG chairs never manage to get their WG to finish, or keep adding new tasks to the charter so that the Working Group drags on for many years. The output of these aging WGs is often not nearly as useful as the earlier products, and the messy results are sometimes attributed to what's called "degenerative Working Group syndrome".
工作组履行其章程后，应停止运营。（大多数工作组邮件列表在工作组关闭后仍在继续，仍在讨论与工作组相同的主题。）在IETF中，工作组关闭是成功的标志，因为它履行了章程。这是IETF的一个方面，具有其他标准机构经验的新手很难理解。然而，一些工作组主席从来没有设法让他们的工作组完成，或者不断地在章程中增加新的任务，以至于工作组拖了很多年。这些老化WGs的输出通常不如早期产品有用，而混乱的结果有时被归因于所谓的“退化工作组综合症”。
There is an official distinction between WG drafts and independent drafts, but in practice, sometimes there is not much procedural difference. For example, many WG mailing lists also discuss independent drafts (at the discretion of the WG chair). Procedures for Internet Drafts are covered in much more detail later in this document.
工作组草案和独立草案之间有正式区别，但在实践中，有时程序上没有太大区别。例如，许多工作组邮件列表也讨论独立草案（由工作组主席决定）。本文件后面将更详细地介绍互联网草稿的程序。
WG chairs are strongly advised to go to the WG leadership training that usually happens on the Sunday preceding the IETF meeting. There is also usually a WG chairs lunch mid-week during the meeting where chair-specific topics are presented and discussed. If you're interested in what they hear there, take a look at the slides at http://edu.ietf.org/.
强烈建议工作组主席参加工作组领导培训，培训通常在IETF会议前的周日进行。在会议期间，工作组主席通常会在周中举行午餐会，介绍和讨论主席的特定主题。如果你对他们听到的内容感兴趣，请看http://edu.ietf.org/.
One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere.
让许多新手困惑的一个事实是，面对面工作组会议在IETF中的重要性远远低于在大多数其他组织中的重要性。在面对面会议上做出的任何决定也必须在工作组邮件列表上取得一致意见。有许多在工作组会议上做出的重要决定后来在邮件列表上被推翻的例子，通常是因为无法出席会议的人指出了做出决定的逻辑中的一个严重缺陷。最后，工作组会议不是“起草会议”，就像在其他一些标准机构中一样：在IETF中，起草是在其他地方进行的。
Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" -- if you agree with a proposal, you hum when prompted by the chair; if you disagree, you keep your silence. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.
令许多人困惑的工作组的另一个方面是没有正式投票。关于有争议的议题的一般规则是，工作组必须达成“大致共识”，这意味着绝大多数关心的人必须同意。确定大致共识的确切方法因工作组而异。有时，共识是由“哼唱”决定的——如果你同意一项提案，你在主席的提示下哼唱；如果你不同意，你就保持沉默。新来的人觉得这很奇怪，但它很管用。工作组何时达成大致共识由主席决定。
The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that anyone can join, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.
由于缺乏正式投票，一些提案出现了很长时间的延迟，但在激烈辩论后见证了大致共识的大多数IETF参与者认为，延迟往往会导致更好的协议。（如果你仔细想想，你怎么能在一个任何人都可以加入的团体中进行“投票”，而当无法统计参与者时？）粗略的共识已经在许多方面得到了定义；一个简单的说法是，这意味着必须对强烈反对意见进行辩论，直到大多数人确信这些反对意见是错误的。
Some Working Groups have complex documents or a complex set of documents (or even both). Shaking all the bugs out of one or more complex documents is a daunting task. In order to help relieve this problem, some Working Groups use "issue trackers", which are online lists of the open issues with the documents, the status of the issue, proposed fixes, and so on. Using an issue tracker not only helps the WG not to forget to do something important, it helps when someone asks a question later about why something was done in a particular fashion.
一些工作组有复杂的文档或一组复杂的文档（甚至两者都有）。从一个或多个复杂文档中消除所有bug是一项艰巨的任务。为了帮助缓解这一问题，一些工作组使用了“问题追踪器”，即在线列出文件中的未决问题、问题状态、建议的修复方案等。使用问题跟踪器不仅有助于工作组不要忘记做一些重要的事情，而且在以后有人问到为什么某些事情会以特定的方式进行时也会有所帮助。
Another method that some Working Groups adopt is to have a Working Group "secretary" to handle the juggling of the documents and the changes. The secretary can run the issue tracker if there is one, or can simply be in charge of watching that all of the decisions that are made on the mailing list are reflected in newer versions of the documents.
一些工作组采用的另一种方法是由一个工作组“秘书”来处理文件和修改的杂耍。如果有问题跟踪器，秘书可以运行问题跟踪器，也可以只负责观察邮件列表上做出的所有决定是否反映在新版本的文件中。
One thing you might find helpful, and possibly even entertaining, during Working Group sessions is to follow the running commentary on the Jabber room associated with that Working Group. The running commentary is often used as the basis for the minutes of the meeting, but it can also include jokes, sighs, and other extraneous chatter. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at http://www.jabber.org. The Jabber chatrooms have the name of the Working Group followed by "@jabber.ietf.org". Those rooms are, in fact, available year-round, not just during IETF meetings, and some are used by active Working Group participants during protocol development.
在工作组会议期间，你可能会发现有一件事很有帮助，甚至可能很有趣，那就是关注与该工作组相关的聊天室的评论。连续评论通常被用作会议记录的基础，但也可以包括笑话、叹息和其他无关的闲聊。Jabber是一种免费的流式XML技术，主要用于即时消息传递。您可以在网站上找到许多平台的Jabber客户端指针http://www.jabber.org. Jabber聊天室的名称为工作组名称，后跟“@Jabber.ietf.org”。事实上，这些房间全年都可用，不仅在IETF会议期间可用，而且在协议制定期间，一些房间被活跃的工作组参与者使用。
The most important thing that everyone (newcomers and seasoned experts) should do before coming to a face-to-face meeting is to read the Internet Drafts and RFCs ahead of time. WG meetings are explicitly not for education: they are for developing the group's documents. Even if you do not plan to say anything in the meeting, you should read the group's documents before attending so you can understand what is being said.
每个人（新来者和经验丰富的专家）在参加面对面会议之前应该做的最重要的事情是提前阅读互联网草稿和RFC。工作组会议明确不是为了教育：它们是为了制定工作组的文件。即使你不打算在会议上说什么，你也应该在参加会议之前阅读小组的文件，这样你才能理解他们在说什么。
It's up to the WG chair to set the meeting agenda, usually a few weeks in advance. If you want something discussed at the meeting, be sure to let the chair know about it. The agendas for all the WG meetings are available in advance (see http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the meeting number), but many WG chairs are lax (if not totally negligent) about turning them in.
由工作组主席制定会议议程，通常提前几周。如果你想在会议上讨论一些事情，一定要让主席知道。所有工作组会议的议程均提前提供（见http://www.ietf.org/meetings/wg_agenda_xx.html，其中“xx”是会议编号），但许多工作组主席在提交会议时很松懈（如果不是完全疏忽的话）。
The Secretariat only schedules WG meetings a few weeks in advance, and the schedule often changes as little as a week before the first day. If you are only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the Working Group's meeting changes schedule. Be sure to keep track of the current agenda so you can schedule flights and hotels. But, when it comes down to it, you probably shouldn't be coming for just one WG meeting. It's likely that your knowledge could be valuable in a few WGs, assuming that you've read the drafts and RFCs for those groups.
秘书处只提前几周安排工作组会议，而日程往往在第一天的前一周变化很小。如果你只来参加一次工作组会议，那么你可能很难在通知如此之少的情况下预订航班，特别是如果工作组的会议改变了日程安排。确保跟踪当前议程，以便安排航班和酒店。但是，归根结底，你可能不应该只参加一次工作组会议。假设您已经阅读了这些小组的草稿和RFC，那么您的知识可能在一些工作组中很有价值。
If you are on the agenda at a face-to-face meeting, you should probably come with a few slides prepared. But don't come with a tutorial; people are supposed to read the drafts in advance. Projectors for laptop-based presentations are available in all the meeting rooms.
如果你在面对面会议的议程上，你可能应该准备一些幻灯片。但是不要带着教程来；人们应该提前阅读草稿。所有会议室都提供用于笔记本电脑演示的投影仪。
And here's a tip for your slides in WG or plenary presentations: don't put your company's logo on every one, even though that is a common practice outside the IETF. The IETF frowns on this kind of corporate advertising (except for the meeting sponsor in the plenary presentation), and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism. Slides are often plain black and white for legibility, with color used only when it really adds clarity. Again, the content is the most important part of the slides, not how it's presented.
这里有一个在工作组或全体会议上演示幻灯片的提示：不要在每一张幻灯片上都贴上你公司的徽标，即使这是IETF之外的常见做法。IETF不赞成这种公司广告（除了全体会议上的会议赞助商），大多数演讲人甚至不在开幕幻灯片上贴上他们的标志。IETF关注的是技术内容，而不是公司宣传。为了便于阅读，幻灯片通常是纯黑白的，只有在真正增加清晰度时才使用颜色。同样，内容是幻灯片中最重要的部分，而不是如何呈现。
As we mentioned earlier, the IETF announcement and discussion mailing lists are the central mailing lists for IETF activities. However, there are many other mailing lists related to IETF work. For example, every Working Group has its own discussion list. In addition, there are some long-term technical debates that have been moved off of the IETF list onto lists created specifically for those topics. It is highly recommended that you follow the discussions on the mailing lists of the Working Groups that you wish to attend. The more work that is done on the mailing lists, the less work that will need to be done at the meeting, leaving time for cross pollination (i.e., attending Working Groups outside one's primary area of interest in order to broaden one's perspective).
如前所述，IETF公告和讨论邮件列表是IETF活动的中心邮件列表。然而，还有许多其他与IETF工作相关的邮件列表。例如，每个工作组都有自己的讨论列表。此外，还有一些长期的技术争论已经从IETF列表中转移到专门为这些主题创建的列表中。强烈建议您关注您希望参加的工作组邮件列表上的讨论。邮件列表上完成的工作越多，会议上需要完成的工作就越少，留出时间进行异花授粉（即，参加自己主要兴趣领域以外的工作组，以拓宽自己的视野）。
The mailing lists also provide a forum for those who wish to follow, or contribute to, the Working Groups' efforts, but can't attend the IETF meetings. That's why IETF procedures require all decisions to be confirmed "on the list" and you will often hear a WG chair say, "Let's take it to the list" to close a discussion.
邮件列表还为那些希望关注工作组的工作或为工作组的工作做出贡献但不能参加IETF会议的人提供了一个论坛。这就是为什么IETF程序要求所有决定都要“在清单上”得到确认的原因，你经常会听到工作组主席在结束讨论时说，“让我们把它放到清单上”。
Many IETF discussion lists use either mailman or another list manager, Majordomo. They usually have a "-request" address that handles the administrative details of joining and leaving the list. (See Section 3.3 for more information on mailman.) It is generally frowned upon when such administrivia appears on the discussion mailing list.
许多IETF讨论列表使用邮递员或其他列表管理器Majordomo。他们通常有一个“-request”地址，处理加入和离开列表的管理细节。（有关邮递员的更多信息，请参见第3.3节。）当此类管理员出现在讨论邮件列表上时，通常不赞成。
Most IETF discussion lists are archived. That is, all of the messages sent to the list are automatically stored on a host for anonymous HTTP or FTP access. Many such archives are listed online at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based archive. If you don't find the list you're looking for, send a message to the list's "-request" address (not to the list itself!). The Working Group charter listings at http://www.ietf.org/html.charters/wg-dir.html are a useful source; note that the page has links to old, concluded WGs.
大多数IETF讨论列表都已存档。也就是说，发送到列表的所有消息都自动存储在主机上，以便进行匿名HTTP或FTP访问。许多这样的档案都在网上列出ftp://ftp.ietf.org/ietf-mail-archive/ 或者它们位于基于web的存档中。如果找不到要查找的列表，请将消息发送到列表的“-request”地址（而不是列表本身！）。工作组在http://www.ietf.org/html.charters/wg-dir.html 是一个有用的来源；请注意，该页面有指向旧的、已结束的WGs的链接。
Some WG lists apply size limits on messages, particularly to avoid large documents or presentations landing in everyone's mailbox. It is well worth remembering that participants do not all have broadband connections (and even those with broadband connections sometimes get their mail on slow connections when they travel), so shorter messages are greatly appreciated. Documents can be posted as Internet Drafts; presentation material can be posted to a web site controlled by the sender or sent personally to people who ask for it. Some WGs set up special sites to hold these large documents so that senders can post there first, then just send to the list the URL of the document.
一些工作组列表对邮件大小进行了限制，特别是为了避免大型文档或演示文稿出现在每个人的邮箱中。值得记住的是，参与者并非都有宽带连接（甚至那些有宽带连接的人有时在旅行时也会通过慢速连接收到邮件），因此短消息非常受欢迎。文件可以作为互联网草稿发布；演示材料可以发布到由发件人控制的网站，也可以亲自发送给索取者。一些工作组建立了专门的站点来保存这些大型文档，以便发件人可以先在那里发布，然后只向列表发送文档的URL。
Working Groups sometimes hold interim meetings between IETFs. Interim meetings aren't a substitute for IETF meetings, however -- a group can't decide to skip a meeting in a location they're not fond of and meet in Cancun (or even someplace mundane) three weeks later, for example. Interim meetings require AD approval and need to be announced at least one month in advance. Location and timing need to allow fair access for all participants. Like regular IETF meetings, someone needs to take notes and send them to mailto:proceedings@ietf.org, and the group needs to take attendance. Decisions tentatively made during an interim WG meeting still must be ratified on the mailing list.
工作组有时在IETF之间举行临时会议。然而，临时会议并不能代替IETF会议——例如，一个团队不能决定跳过在他们不喜欢的地点举行的会议，三周后在坎昆（甚至是普通的地方）开会。临时会议需要广告批准，并且需要至少提前一个月宣布。地点和时间需要允许所有参与者公平进入。与常规IETF会议一样，需要有人做笔记并发送至mailto：proceedings@ietf.org，小组需要参加。临时工作组会议期间临时作出的决定仍必须在邮件列表上批准。
In order to form a Working Group, you need a charter and someone who is able to be chair. In order to get those things, you need to get people interested so that they can help focus the charter and convince an Area Director that the project is worthwhile. A face-
为了组建一个工作组，你需要一个章程和一个能够担任主席的人。为了得到这些东西，你需要让人们感兴趣，以便他们能够帮助关注宪章，并说服区域主管该项目是值得的。一张脸-
to-face meeting is useful for this. In fact, very few WGs get started by an Area Director; most start after a face-to-face BOF because attendees have expressed interest in the topic.
面对面会议对此很有用。事实上，很少有工作组是由区域主管启动的；大多数在面对面BOF之后开始，因为与会者对该主题表示了兴趣。
A Birds of a Feather (BOF) meeting has to be approved by the Area Director in the relevant area before it can be scheduled. If you think you really need a new WG, approach an AD informally with your proposal and see what he or she thinks. The next step is to request a meeting slot at the next face-to-face meeting. Of course, you don't need to wait for that meeting to get some work done, such as setting up a mailing list and starting to discuss a charter.
在安排会议之前，相关区域的区域总监必须批准“羽毛鸟”（BOF）会议。如果你认为你真的需要一个新的工作组，用你的建议非正式地接触一个广告，看看他或她是怎么想的。下一步是在下次面对面会议上申请会议时间。当然，你不需要等待会议完成一些工作，比如建立邮件列表和开始讨论章程。
BOF meetings have a very different tone than do WG meetings. The purpose of a BOF is to make sure that a good charter with good milestones can be created and that there are enough people willing to do the work needed in order to create standards. Some BOFs have Internet Drafts already in process, whereas others start from scratch.
BOF会议的基调与WG会议截然不同。BOF的目的是确保能够创建具有良好里程碑的良好章程，并且有足够多的人愿意完成创建标准所需的工作。一些BOF已经在互联网上起草了草案，而其他BOF则从零开始。
An advantage of having a draft before the BOF is to help focus the discussion. On the other hand, having a draft might tend to limit what the other folks in the BOF want to do in the charter. It's important to remember that most BOFs are held in order to get support for an eventual Working Group, not to get support for a particular document.
在BOF之前有草案的一个优点是有助于集中讨论。另一方面，起草一份草案可能会限制BOF中其他人在章程中想要做的事情。重要的是要记住，大多数BOF的召开是为了获得最终工作组的支持，而不是为了获得特定文件的支持。
Many BOFs don't turn into WGs for a variety of reasons. A common problem is that not enough people can agree on a focus for the work. Another typical reason is that the work wouldn't end up being a standard -- if, for example, the document authors don't really want to relinquish change control to a WG. (We'll discuss change control later in this document.) Only two meetings of a BOF can be scheduled on a particular subject; either a WG has to form or the topic should be dropped.
由于各种原因，许多BOF不能转变为WG。一个常见的问题是，没有足够的人能够就工作重点达成一致。另一个典型的原因是，如果文档作者真的不想将更改控制权交给工作组，那么该工作最终不会成为标准。（我们将在本文件后面讨论变更控制。）一个BOF只能就一个特定主题安排两次会议；要么工作组必须成立，要么主题应该被删除。
If you're new to the IETF and this is the only reference you plan to read before coming to the meeting, stop here -- at least temporarily. Then, on your flight home, read the rest of the Tao. By that time you'll be ready to get actively involved in the Working Groups that interested you at the meeting, and the Tao will get you started on your way.
如果您是IETF新手，并且在参加会议之前，这是您计划阅读的唯一参考资料，请在这里停下来——至少暂时停下来。然后，在回家的飞机上，读道的其余部分。到那时，你将准备好积极参与会议上你感兴趣的工作组，而道将让你开始你的道路。
If you're planning to participate in the IETF remotely, through reading email lists and the proceedings, read on!
如果您计划通过阅读电子邮件列表和会议记录远程参与IETF，请继续阅读！
If you're a new IETF participant and are looking for a particular RFC or Internet Draft, go to the RFC Editor's web pages, http://www.rfc-editor.org/rfc.html. That site also has links to other RFC collections, many with search capabilities. If you know the number of the RFC you're looking for, go to the IETF RFC pages, http://www.ietf.org/rfc.html. For Internet Drafts, the best resource is the IETF web site, http://www.ietf.org/ID.html, where you can search by title and keyword.
如果您是新的IETF参与者，并且正在寻找特定的RFC或Internet草稿，请访问RFC编辑器的网页，http://www.rfc-editor.org/rfc.html. 该网站还提供了指向其他RFC收藏的链接，其中许多具有搜索功能。如果您知道要查找的RFC的编号，请转到IETF RFC页面，http://www.ietf.org/rfc.html. 对于Internet草稿，最好的资源是IETF网站，http://www.ietf.org/ID.html，您可以在其中按标题和关键字进行搜索。
One of the most common questions seasoned IETFers hear from newcomers is, "How do I get an IETF standard published?" A much better question is, "Should I write an IETF standard?" since the answer is not always "yes." If you do decide to try to write a document that becomes an IETF standard, be warned that the overall process may be arduous, even if the individual steps are fairly straightforward. Lots of people get through the process unscathed, though, and there's plenty of written guidance that helps authors emerge with their ego more or less intact.
经验丰富的IETF人员从新来者那里听到的一个最常见的问题是，“我如何发布IETF标准？”一个更好的问题是，“我应该编写IETF标准吗？”因为答案并不总是“是”。如果您决定尝试编写一份成为IETF标准的文档，请注意，整个过程可能很艰巨，即使每个步骤都相当简单。然而，很多人都安然无恙地完成了这个过程，而且有很多书面指导帮助作者或多或少地保持自我。
Every IETF standard is published as an RFC (a "Request for Comments," but everyone just calls them RFCs), and every RFC starts out as an Internet Draft (often called an "I-D"). The basic steps for getting something published as an IETF standard are as follows:
每一个IETF标准都以RFC（征求意见）的形式发布（但每个人都称之为RFC），每一个RFC都以互联网草案（通常称为“I-D”）的形式发布。作为IETF标准发布的基本步骤如下：
1. Publish the document as an Internet Draft.
1. 将文档发布为Internet草稿。
2. Receive comments on the draft.
2. 接受对草案的评论。
3. Edit your draft based on the comments.
3. 根据评论编辑草稿。
4. Repeat steps 1 through 3 a few times.
4. 重复步骤1至3几次。
5. Ask an Area Director to take the draft to the IESG (if it's an individual submission). If the draft is an official Working Group product, the WG chair asks the AD to take it to the IESG.
5. 请区域主管将草案提交给IESG（如果是个人提交）。如果草案是正式工作组产品，工作组主席要求广告将其提交给IESG。
6. Make any changes deemed necessary by the IESG (this might include giving up on becoming a standard).
6. 做出IESG认为必要的任何更改（这可能包括放弃成为标准）。
7. Wait for the document to be published by the RFC Editor.
7. 等待RFC编辑器发布文档。
A much more complete explanation of these steps is contained in [BCP9], "The Internet Standards Process". Those who write drafts that they hope will become IETF standards must read BCP 9 so that
[BCP9]“互联网标准流程”中包含了对这些步骤更完整的解释。那些编写希望成为IETF标准的草案的人必须阅读BCP 9，以便
they can follow the path of their document through the process. BCP 9 (and various other documents that update it) goes into great detail on a topic that is very often misunderstood, even by seasoned IETF participants: different types of RFCs go through different processes and have different rankings. There are six kinds of RFCs:
他们可以在整个过程中遵循文档的路径。BCP 9（以及更新它的各种其他文件）对一个经常被误解的主题进行了非常详细的阐述，即使是经验丰富的IETF参与者也是如此：不同类型的RFC经历不同的过程，并有不同的排名。有六种RFC：
o Proposed standards
o 拟议标准
o Draft standards
o 标准草案
o Internet standards (sometimes called "full standards")
o 互联网标准（有时称为“完整标准”）
o Informational documents
o 信息性文件
o Experimental protocols
o 实验协议
o Historic documents
o 历史文献
Only the first three (proposed, draft, and full) are standards within the IETF. A good summary of this can be found in the aptly titled [RFC1796], "Not All RFCs Are Standards".
只有前三个（建议、草案和完整）是IETF中的标准。在标题恰当的[RFC1796]“并非所有RFC都是标准”中可以找到这方面的一个很好的总结。
There are also three sub-series of RFCs, known as FYIs, BCPs, and STDs. The For Your Information RFC sub-series was created to document overviews and topics that are introductory or that appeal to a broad audience; however, that series has not been added to in a long time. Best Current Practice documents describe the application of various technologies in the Internet. The STD RFC sub-series was created to identify RFCs that do in fact specify Internet standards. Some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents.
RFC还有三个子系列，即FYIs、BCP和STD。“为您的信息”RFC子系列是为了记录概述和主题而创建的，这些概述和主题是介绍性的，或者是吸引广大读者的；然而，这个系列已经很久没有被加入了。当前最佳实践文件描述了各种技术在互联网上的应用。创建STD RFC子系列是为了识别实际上指定了互联网标准的RFC。有些STD实际上是一套以上的RFC，“标准”名称适用于整套文件。
The biggest reason some people do not want their documents put on the IETF standards track is that they must give up change control of the protocol. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed.
一些人不希望他们的文档进入IETF标准轨道的最大原因是他们必须放弃对协议的更改控制。也就是说，一旦您提议您的协议成为IETF标准，您就必须完全放弃对该协议的控制。如果达成一致，协议的部分内容可以完全更改，整个部分可以删除，可以添加新内容，名称可以更改。
Some authors find it very hard to give up control of their pet protocol. If you are one of those people, don't even think about trying to get your protocol to become an IETF standard. On the other hand, if your goal is the best standard possible with the widest implementation, then you might find the IETF process to your liking.
一些作者发现很难放弃对pet协议的控制。如果你是这些人中的一员，甚至不要考虑让你的协议成为IETF标准。另一方面，如果您的目标是实现最广泛的最佳标准，那么您可能会发现IETF过程符合您的喜好。
Incidentally, the change control on Internet standards doesn't end when the protocol is put on the standards track. The protocol itself can be changed later for a number of reasons, the most common of which is that implementors discover a problem as they implement the standard. These later changes are also under the control of the IETF, not the editors of the standards document.
顺便说一句，当协议进入标准轨道时，互联网标准的变更控制并没有结束。协议本身可以在以后更改，原因有很多，其中最常见的是实现者在实现标准时发现问题。这些后续变更也由IETF控制，而不是由标准文件的编辑控制。
IETF standards exist so that people will use them to write Internet programs that interoperate. They don't exist to document the (possibly wonderful) ideas of their authors, nor do they exist so that a company can say, "We have an IETF standard". If a standards-track RFC only has one implementation (whereas two are required for it to advance on the standards track), it was probably a mistake to put it on the standards track in the first place.
IETF标准的存在使得人们可以使用它们来编写互操作的互联网程序。它们的存在不是为了记录作者的想法（可能很精彩），也不是为了让公司说“我们有一个IETF标准”。如果一个标准轨道RFC只有一个实现（而在标准轨道上前进需要两个实现），那么首先将其放在标准轨道上可能是一个错误。
First things first. Every document that ends up in the RFC repository starts life as an Internet Draft. Internet Drafts are tentative documents -- they're meant for readers to comment on, so authors can mull over those comments and decide which ones to incorporate in the draft. In order to remind folks of their tentativeness, Internet Drafts are automatically removed from the online directories after six months. They are most definitely not standards or even specifications. As [BCP9] says:
第一件事。RFC存储库中的每个文档都以互联网草稿的形式开始使用。互联网上的草稿是暂时性的文件——它们是供读者评论的，因此作者可以仔细考虑这些评论，并决定将哪些评论纳入草稿中。为了提醒人们他们的潜力，互联网草稿在六个月后会自动从在线目录中删除。它们绝对不是标准，甚至不是规范。正如[BCP9]所说：
"An Internet Draft is NOT a means of 'publishing' a specification;
specifications are published through the RFC mechanism.... Internet
Drafts have no formal status, and are subject to change or removal at
any time. Under no circumstances should an Internet Draft be
referenced by any paper, report, or Request-for-Proposal, nor should
a vendor claim compliance with an Internet Draft".
"An Internet Draft is NOT a means of 'publishing' a specification;
specifications are published through the RFC mechanism.... Internet
Drafts have no formal status, and are subject to change or removal at
any time. Under no circumstances should an Internet Draft be
referenced by any paper, report, or Request-for-Proposal, nor should
a vendor claim compliance with an Internet Draft".
You can always tell a person who doesn't understand the IETF (or is intentionally trying to fool people) when he or she brags about having published an Internet Draft; it takes no significant effort.
你可以告诉一个不懂IETF（或有意愚弄他人）的人，当他或她吹嘘自己已经在互联网上发表了一份草稿；这不需要很大的努力。
When you submit an Internet Draft, you give some publication rights to the IETF. This is so that your Internet Draft is freely available to everyone who wants to read and comment on it. The rights you do and don't give to the IETF are described in [BCP78], "IETF Rights in Contributions".
当您提交互联网草稿时，您将授予IETF一些出版权。这样，你的网络草稿就可以免费提供给每个想阅读和评论它的人。您给予和不给予IETF的权利在[BCP78]，“贡献中的IETF权利”中进行了描述。
There is a very useful checking tool at http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool before you turn in an Internet Draft will help prevent the draft from being rejected due to errors in form and formatting.
现在有一个非常有用的检查工具http://tools.ietf.org/tools/idnits/idnits.pyht. 在您提交Internet草稿之前使用此工具将有助于防止草稿因格式和格式错误而被拒绝。
An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the nroff formatting used by the RFC Editor. There is also a tool called "xml2rfc", available from http://xml.resource.org/, that takes XML-formatted text and turns it into a valid Internet Draft.
I-D的格式应与RFC大致相同。与许多人的信念相反，I-D不需要看起来完全像RFC，但是如果您可以在创建I-D时使用RFC编辑器使用的相同格式设置过程，那么当您的草稿作为RFC发布时，它将简化RFC编辑器的工作。[RFC2223]，“RFC作者须知”，描述了RFC编辑器使用的nroff格式。还有一个名为“xml2rfc”的工具，可从http://xml.resource.org/，将XML格式的文本转换为有效的Internet草稿。
An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say.
互联网草案可以是工作组草案，也可以是个人提交的文件。工作组草案通常在作为工作组项目被接受之前由工作组进行审查，尽管主席拥有最终发言权。
If you're interested in checking the status of a particular draft, or can't remember its exact name, or want to find out which drafts a WG is working on, two handy tools are available. The "Internet Drafts Database Interface", at https://datatracker.ietf.org/public/idindex.cgi, lets you search for a draft by author, Working Group, date, or filename. The "I-D Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is especially useful for authors who want to track the progress of their draft as it makes its way through the publication process.
如果您对检查特定草案的状态感兴趣，或者记不起其确切名称，或者想知道工作组正在处理哪些草案，那么有两个方便的工具可用。“互联网草稿数据库接口”，网址：https://datatracker.ietf.org/public/idindex.cgi，用于按作者、工作组、日期或文件名搜索草稿。“I-D跟踪器”，位于https://datatracker.ietf.org/public/pidtracker.cgi，对于希望跟踪其草稿在出版过程中的进度的作者特别有用。
There are some informal rules for Internet Draft naming that have evolved over the years. Internet Drafts that revise existing RFCs often have draft names with "bis" in them, meaning "again" or "twice"; for example, a draft might be called "draft-someone-rfc2345bis-00.txt".
互联网草案命名有一些非正式规则，这些规则多年来一直在演变。修改现有RFC的互联网草案通常有带有“bis”的草案名称，意思是“再次”或“两次”；例如，草案可能被称为“draft-someone-rfc2345bis-00.txt”。
Before you create the first draft of your Internet Draft, you should read four documents:
在创建Internet草稿的第一稿之前，您应该阅读四个文档：
o More important than just explaining formatting, [RFC2223] also explains what needs to be in an Internet Draft before it can become an RFC. This document describes all the sections and notices that will need to be in your document, and it's good to have them there from the beginning so that readers aren't surprised when you put them in later versions.
o 比仅仅解释格式更重要的是，[RFC2223]还解释了互联网草稿在成为RFC之前需要包含哪些内容。本文档描述了文档中需要包含的所有部分和注意事项，最好从一开始就将它们放在文档中，这样读者在您将它们放入更高版本时不会感到惊讶。
o [BCP22], "Guide for Internet Standards Writers", provides tips that will help you write a standard that leads to interoperability. For instance, it explains how to choose the right number of protocol options, how to respond to out-of-spec behavior, and how to show state diagrams.
o [BCP22]，“互联网标准编写者指南”，提供了一些技巧，可以帮助您编写一个实现互操作性的标准。例如，它解释了如何选择正确数量的协议选项，如何响应超出规范的行为，以及如何显示状态图。
o The online "Guidelines to Authors of Internet Drafts", http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date information about the process for turning in Internet Drafts, as well as the most current boilerplate information that has to be included in each Internet Draft.
o 在线“互联网草稿作者指南”，http://www.ietf.org/ietf/1id-guidelines.txt，具有有关提交互联网草稿过程的最新信息，以及必须包含在每个互联网草稿中的最新样板信息。
o When you think you are finished with the draft process and are ready to request that the draft become an RFC, you should definitely read "Checklist for Internet Drafts (I-Ds) Submitted for RFC Publication", http://www.ietf.org/ID-Checklist.html, a list of common issues that have been known to stop documents in the IESG. In fact, you should probably read that document well before you are finished, so that you don't have to make a bunch of last-minute changes.
o 当您认为您已完成草稿流程并准备好请求将草稿变成RFC时，您应该明确阅读“提交RFC发布的互联网草稿（I-D）清单”，http://www.ietf.org/ID-Checklist.html，这是一个常见问题列表，已知这些问题会阻止IESG中的文档。事实上，您可能应该在完成之前阅读该文档，这样您就不必在最后一刻进行大量更改。
Also, you should visit the IETF Tools web pages, http://tools.ietf.org, where you'll find pointers to other tools that will automate some of your work for the IETF.
此外，您还应访问IETF工具网页，http://tools.ietf.org，您将在其中找到指向其他工具的指针，这些工具将自动化IETF的一些工作。
When you're ready to turn in your Internet Draft, send it to the Internet Drafts administrator at mailto:internet-drafts@ietf.org. There is a real person at the other end of this mail address, whose job is to make sure you've included the minimum items you need for the Internet Draft to be published. When you submit the first version of the draft, you also tell the draft administrator your proposed filename for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt".
当您准备好提交Internet草稿时，请将其发送给位于mailto:Internet的Internet草稿管理员-drafts@ietf.org. 在这个邮件地址的另一端有一个真实的人，他的工作是确保你已经包含了互联网草稿发布所需的最低项目。当您提交草稿的第一个版本时，您还可以告诉草稿管理员您建议的草稿文件名。如果草案是正式工作组产品，名称将以“草案ietf-”开头，然后是工作组名称，然后是一两个描述性单词，最后是“00.txt”。
For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". You are welcome to suggest names; however, it is up to the Internet Drafts administrator (and, if it is an official WG draft, the WG chair) to come up with the filename. If you follow the naming guidelines given at http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good that your suggested filename will be fine.
例如，S/MIME工作组中关于创建密钥的草案可能命名为“draft-ietf-smime-keying-00.txt”。如果不是工作组的产品，名称将以“草稿-”开头，其中一位作者的姓氏后接一两个描述性单词，然后是“00.txt”。例如，一个名叫史密斯的人写的草稿可能被命名为“draft-Smith-keying-00.txt”。如果草稿是单独提交的，但与特定工作组有关，则作者有时会在其姓名后面加上工作组的名称，如“draft-smith-smime-keying-00.txt”。欢迎你推荐名字；但是，由Internet草稿管理员（如果是正式的工作组草稿，则由工作组主席）提出文件名。如果您遵循中给出的命名指导原则http://www.ietf.org/ietf/1id-guidelines.txt，很有可能您建议的文件名会很好。
After the first edition of a draft, the number in the filename is incremented; for instance, the second edition of the S/MIME draft named above would be "draft-ietf-smime-keying-01.txt". Note that there are cases where the filename changes after one or more versions, such as when a personal effort is pulled into a Working Group; when a draft has its filename changed, the number reverts to -00. Be sure to let the Internet Drafts administrator know the previous name of the draft when such a name change occurs so that the databases can be kept accurate.
初版草稿之后，文件名中的数字将递增；例如，上述S/MIME草案的第二版将是“draft-ietf-smime-keying-01.txt”。请注意，在某些情况下，文件名在一个或多个版本后发生更改，例如当个人工作被拉入工作组时；当草稿的文件名发生更改时，数字将恢复为-00。当名称发生更改时，请确保让Internet草稿管理员知道草稿的以前名称，以便数据库保持准确。
The procedure for creating and advancing a standard is described in [BCP9]. After an Internet Draft has been sufficiently discussed and there is rough consensus that what it says would be a useful standard, it is presented to the IESG for consideration. If the draft is an official WG draft, the WG chair sends it to the appropriate Area Director after it has gone through Working Group last call. If the draft is an individual submission, the draft's author or editor submits it to the appropriate Area Director. BCP 9 also describes the appeals process for people who feel that a Working Group chair, an AD, or the IESG has made the wrong decision in considering the creation or advancement of a standard.
[BCP9]中描述了创建和推进标准的过程。互联网草案经过充分讨论后，人们大致一致认为它所说的将是一个有用的标准，然后提交给IESG审议。如果草案是工作组的正式草案，工作组主席在完成工作组最后一次会议后将其发送给相应的区域主任。如果草稿是个人提交的，草稿的作者或编辑将其提交给相应的区域主管。BCP 9还描述了那些认为工作组主席、广告或IESG在考虑创建或推进标准时做出错误决定的人的上诉程序。
After the I-D is submitted to the IESG, the IESG announces an IETF-wide last call. This helps get the attention of people who weren't following the progress of the draft, and it can sometimes cause further changes to the draft. It is also a time when people in the WG who feel that they weren't heard can make their comments to everyone. The IETF last call is two weeks for drafts coming from WGs and four weeks for individual submissions.
在I-D提交给IESG后，IESG宣布IETF范围内的最后一次呼叫。这有助于引起那些没有关注草案进展情况的人的注意，有时还会导致草案的进一步修改。这也是一个工作组中感觉自己没有被听到的人可以向每个人发表评论的时候。IETF的最后一次呼叫是两周，针对来自WGs的草案，以及四周的个人提交。
If the IESG approves the draft to become an Internet standard, they ask the RFC Editor to publish it as a Proposed standard. After it has been a Proposed standard for at least six months, the RFC's author (or the appropriate WG chair) can ask for it to become a Draft standard. Before that happens, however, someone needs to convince the appropriate Area Director that there are at least two independent, interoperable implementations of each part of the standard. This is a good test of the usefulness of the standard as a whole, as well as an excellent way to check if the standard was really readable.
如果IESG批准草案成为互联网标准，他们会要求RFC编辑将其作为建议标准发布。在其成为拟议标准至少六个月后，RFC的作者（或相应的工作组主席）可以要求其成为标准草案。然而，在此之前，需要有人说服相应的区域主管，标准的每个部分至少有两个独立的、可互操作的实现。这是对整个标准有用性的一个很好的测试，也是检查标准是否真正可读的一个很好的方法。
A few things typically happen at this point. First, it's common to find that some of the specifications in the standard need to be reworded because one implementor thought they meant one thing whereas another implementor thought they meant something else. Another common occurrence is that none of the implementations actually tried
此时通常会发生一些事情。首先，通常会发现标准中的一些规范需要重新编写，因为一个实现者认为它们意味着一件事，而另一个实现者认为它们意味着另一件事。另一个常见的情况是，没有一个实现实际尝试过
to implement a few of the features of the standard; these features get removed not just because no one tested them but also because they weren't needed.
实施标准的一些特征；这些特性被删除不仅仅是因为没有人测试它们，还因为它们不需要。
Don't be surprised if a particular standard doesn't progress from Proposed to Draft. In fact, most of the standards in common use are Proposed standards and never move forward. This may be because no one took the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed standard, or it may be that everyone found more important things to do.
如果一个特定的标准没有从提出到起草，不要感到惊讶。事实上，大多数常用的标准都是提议的标准，从未向前推进过。这可能是因为没有人花时间试图让他们起草，或者标准中的一些规范性引用仍在拟定标准中，或者可能是每个人都发现了更重要的事情要做。
A few years after a document has been a Draft standard, it can become an Internet standard, also known as "full standard" (it can happen in as little as four months, but this is rare). This doesn't happen often, and it is usually reserved for protocols that are absolutely required for the Internet to function. The IESG goes over the document with a fine-tooth comb and looks for evidence of widespread deployment before making a Draft standard an Internet standard.
文档成为标准草案几年后，它就可以成为互联网标准，也称为“完整标准”（可能在短短四个月内完成，但这种情况很少见）。这种情况并不经常发生，它通常是为互联网运行所必需的协议保留的。IESG对该文件进行了仔细的梳理，并在将标准草案作为互联网标准之前寻找广泛部署的证据。
Writing specifications that get implemented the way you want is a bit of an art. You can keep the specification very short, with just a list of requirements, but that tends to cause implementors to take too much leeway. If you instead make the specification very wordy with lots of suggestions, implementors tend to miss the requirements (and often disagree with your suggestions anyway). An optimal specification is somewhere in between.
编写以您想要的方式实现的规范是一门艺术。您可以将规范保持得非常简短，只列出一系列需求，但这往往会导致实现者留有太多的余地。如果您将规范变得非常冗长，并提出了大量建议，那么实现者往往会错过需求（并且通常不同意您的建议）。最佳规格介于两者之间。
One way to make it more likely that developers will create interoperable implementations of standards is to be clear about what's being mandated in a specification. Early RFCs used all kinds of expressions to explain what was needed, so implementors didn't always know which parts were suggestions and which were requirements. As a result, standards writers in the IETF generally agreed to limit their wording to a few specific words with a few specific meanings.
使开发人员更有可能创建可互操作的标准实现的一种方法是明确规范中规定的内容。早期的RFC使用各种表达式来解释需要什么，所以实现者并不总是知道哪些部分是建议，哪些是需求。因此，IETF中的标准编写者普遍同意将其措辞限制为几个具有特定含义的特定单词。
[STD3], "Requirements for Internet Hosts -- Application and Support", written way back in 1989, had a short list of words that had appeared to be useful, namely, "must", "should", and "may". These definitions were updated and further refined in [BCP14], "Key words for use in RFCs to Indicate Requirement Levels", which is widely referenced in current Internet standards. BCP 14 also specifically defines "must not" and "should not", and it lists a few synonyms for the words defined.
[STD3]，“对互联网主机的要求——应用和支持”，写于1989年，有一个简短的词汇列表，似乎很有用，即“必须”、“应该”和“可能”。这些定义在[BCP14]“RFC中用于表示需求水平的关键词”中进行了更新和进一步完善，该词在当前的互联网标准中被广泛引用。BCP 14还明确定义了“不得”和“不应”，并列出了所定义单词的几个同义词。
In a standard, in order to make it clear that you're using the definitions from BCP 14, you should do two things. First, refer to BCP 14 (although most people refer to it as RFC 2119, because that's what BCP 14 tells you to do), so that the reader knows how you're defining your words. Second, you should point out which instances of the words you are using come from BCP 14. The accepted practice for this is to capitalize the words. That is why you see "MUST" and "SHOULD" capitalized in IETF standards.
在一个标准中，为了明确您使用的是BCP14中的定义，您应该做两件事。首先，参考BCP14（尽管大多数人将其称为RFC2119，因为这是BCP14告诉您要做的），以便读者知道您如何定义您的单词。其次，你应该指出你正在使用的单词的实例来自BCP14。公认的做法是将单词大写。这就是为什么在IETF标准中“必须”和“应该”大写的原因。
BCP 14 is a short document, and it should be read by everyone who is reading or writing IETF standards. Although the definitions of "must" and "must not" are fairly clear, the definitions of "should" and "should not" cause a great deal of discussion in many WGs. When reviewing an Internet Draft, the question is often raised, "Should that sentence have a MUST or a SHOULD in it?" This is, indeed, a very good question, because specifications shouldn't have gratuitous MUSTs, but also should not have SHOULDs where a MUST is needed for interoperability. This goes to the crux of the question of over-specifying and under-specifying requirements in standards.
BCP 14是一个简短的文档，每个阅读或编写IETF标准的人都应该阅读它。虽然“必须”和“不得”的定义相当明确，“应该”和“不应该”的定义在许多工作组中引起了大量讨论。在审查互联网草案时，经常会提出这样一个问题：“这句话中应该包含“必须”还是“应该？”这确实是一个很好的问题，因为规范不应该包含免费的“必须”，也不应该包含互操作性所需的“应该”。这就涉及到标准中过度规定和不充分规定要求的问题的关键。
One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folks) is the rule about how to make "normative references" to non-IETF documents or to other RFCs in a standard. A normative reference is a reference to a document that must be followed in order to implement the standard. A non-normative reference (sometimes called an "informative reference") is one that is helpful to an implementor but is not needed.
编写IETF标准的一个方面让许多新手（以及许多长期从事IETF的人）感到困惑，那就是关于如何对非IETF文档或标准中的其他RFC进行“规范性引用”的规则。规范性引用是指为实施本标准而必须遵循的文件。非规范性引用（有时称为“信息性引用”）是对实施者有用但不需要的引用。
An IETF standard may make a normative reference to any other standards-track RFC that is at the same standards level or higher, or to any "open standard" that has been developed outside the IETF. The "same level or higher" rule means that before a standard can move from Proposed to Draft, all of the RFCs for which there is a normative reference must also be at Draft or Internet standard. This rule gives implementors assurance that everything in a Draft standard or Internet standard is quite stable, even the things referenced outside the standard. This can also delay the publication of the Draft or Internet standard by many months (sometimes even years) while the other documents catch up.
IETF标准可对处于相同或更高标准级别的任何其他标准或IETF之外开发的任何“开放标准”进行规范性引用。“同一级别或更高级别”规则意味着，在一个标准可以从提议的标准转变为草案标准之前，有规范性参考的所有RFC也必须是草案标准或互联网标准。该规则为实现者提供了保证，即标准草案或互联网标准中的所有内容都是相当稳定的，即使是标准之外引用的内容也是如此。这也会使草案或互联网标准的发布延迟数月（有时甚至数年），而其他文件则会赶上。
There is no hard-and-fast rule about what is an "open standard", but generally this means a stable standard that anyone can get a copy of (although they might have to pay for it) and that was made by a generally recognized standards group. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, as with a designation of the date of
关于什么是“开放标准”没有硬性规定，但一般来说，这意味着一个稳定的标准，任何人都可以获得一份（尽管他们可能需要支付费用），这是由一个公认的标准团体制定的。如果外部标准发生变化，您必须在您的规范中引用该标准的特定实例，如指定日期
the standard. Some external standards bodies don't make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, a draft author should ask the WG chair or appropriate Area Director if a particular external standard can be used in an IETF standard.
标准。一些外部标准机构不提供旧标准，这是未来需要使用的IETF标准的一个问题。当有疑问时，草案作者应询问工作组主席或适当的区域主任，是否可以在IETF标准中使用特定的外部标准。
More and more IETF standards require the registration of various protocol parameters, such as named options in the protocol. As we noted in Section 3.2.4, the main registry for all IETF standards has long been IANA. Because of the large and diverse kinds of registries that standards require, IANA needs to have specific information about how to register parameters, what not to register, who (if anyone) will decide what is to be registered, and so on.
越来越多的IETF标准要求注册各种协议参数，例如协议中的命名选项。正如我们在第3.2.4节中指出的，所有IETF标准的主要注册中心一直是IANA。由于标准要求的注册种类繁多，IANA需要有关于如何注册参数、不注册什么、由谁（如果有人）决定注册什么等的具体信息。
Anyone writing an Internet standard that may need a new IANA registry or new values in a current IANA registry needs to read [BCP26], "Guidelines for Writing an IANA Considerations Section in RFCs", which describes how RFC authors should properly ask for IANA to start or take over a registry. IANA also maintains registries that were started long before BCP 26 was produced.
任何编写可能需要新的IANA注册表或当前IANA注册表中的新值的互联网标准的人都需要阅读[BCP26]，“RFC中编写IANA注意事项部分的指南”，其中描述了RFC作者应如何正确要求IANA启动或接管注册表。IANA还维护早在BCP 26产生之前就开始的注册。
One thing that's required in every RFC and Internet Draft is a "Security Considerations" section. This section should describe any known vulnerabilities of the protocol, possible threats, and mechanisms or strategies to address them. Don't gloss over this section -- in particular, don't say, "Here's our protocol, if you want security, just use IPsec". This won't do at all, because it doesn't answer the question of how IPsec interacts with your protocol, and vice versa. Be sure to check with your Working Group chair if you're not sure how to handle this section in your draft. See [BCP72], "Guidelines for Writing RFC Text on Security Considerations", for more information on writing good security considerations sections.
每个RFC和Internet草案都需要一个“安全注意事项”部分。本节应描述协议的任何已知漏洞、可能的威胁以及解决这些漏洞的机制或策略。不要掩饰这一部分——尤其不要说，“这是我们的协议，如果您想要安全性，只需使用IPsec”。这根本不行，因为它不能回答IPsec如何与您的协议交互的问题，反之亦然。如果您不确定如何在草稿中处理此部分，请务必咨询您的工作组主席。有关编写良好安全注意事项部分的更多信息，请参见[BCP72]，“关于安全注意事项的RFC文本编写指南”。
The problems of intellectual property have cropped up more and more often in the past few years, particularly with respect to patents. The goal of the IETF is to have its standards widely used and validated in the marketplace. If creating a product that uses a standard requires getting a license for a patent, people are less likely to implement the standard. Not surprisingly, then, the general rule has been "use good non-patented technology where possible".
在过去几年中，知识产权问题越来越频繁地出现，特别是在专利方面。IETF的目标是在市场上广泛使用和验证其标准。如果创建使用标准的产品需要获得专利许可证，那么人们就不太可能实施标准。因此，毫不奇怪，一般规则是“尽可能使用良好的非专利技术”。
Of course, this isn't always possible. Sometimes patents appear after a standard has been established. Sometimes there's a patent on something that is so valuable that there isn't a non-patented equivalent. Sometimes the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed.
当然，这并不总是可能的。有时，专利会在标准制定后出现。有时，有些东西的专利价值如此之高，以至于没有非专利的等价物。有时，专利持有人慷慨大方，承诺向标准的所有实施者授予专利免版税许可证，从而使其几乎与不存在专利时一样易于实施。
The IETF's methods for dealing with patents in standards are a subject of much debate. The official rules for all intellectual property rights (IRP) in IETF documents (not just patents) are covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF Technology". Everyone who participates in IETF Working Groups will probably find these documents interesting because they lay out the rules that everyone agrees to follow.
IETF在标准中处理专利的方法是一个备受争议的话题。[BCP78]和[BCP79]“IETF技术中的知识产权”涵盖了IETF文件中所有知识产权（不仅仅是专利）的官方规则。参加IETF工作组的每个人都可能会发现这些文档很有趣，因为它们列出了每个人都同意遵守的规则。
Patent holders who freely allow their patents to be used by people implementing IETF standards often get a great deal of goodwill from the folks in the IETF. Such generosity is more common than you might think. For example, RFC 1822 is a license from IBM for one of its security patents, and the security community has responded very favorably to IBM for this (whereas a number of other companies have made themselves pariahs for their intractability on their security patents).
自由允许自己的专利被执行IETF标准的人使用的专利持有者通常会从IETF的人那里得到很多善意。这种慷慨比你想象的还要普遍。例如，RFC1822是IBM对其一项安全专利的许可证，而安全社区对此给予了IBM非常积极的回应（而其他一些公司因其安全专利的难处理性而受到排斥）。
If you are writing an Internet Draft and you know of a patent that applies to the technology you're writing about, don't list the patent in the document. Instead, consult the IETF IPR Disclosure Page linked off the main IETF web site to determine how to proceed. Intellectual property rights aren't mentioned in RFCs because RFCs never change after they are published, but knowledge of IPR can change at any time. Therefore, an IPR list in an RFC could be incomplete and mislead the reader. [BCP9] provides specific text that should be added to RFCs where the author knows of IPR issues.
如果你正在写一份互联网草稿，并且你知道一项专利适用于你正在写的技术，不要在文档中列出该专利。相反，请参考IETF主网站链接的IETF知识产权披露页面，以确定如何继续。RFC中未提及知识产权，因为RFC在发布后不会改变，但知识产权知识可以随时改变。因此，RFC中的IPR列表可能不完整并误导读者。[BCP9]提供了作者知道知识产权问题时应添加到RFC中的特定文本。
As we noted earlier, not all RFCs are standards. In fact, plenty of important RFCs are not on the standards track at all. Currently, there are two designations for RFCs that are not meant to be standards: Informational, like the Tao, and Experimental. (There is actually a third designation, Historic, but that is reserved for documents that were on the standards track and have been removed due to lack of current use, or that more recent thinking indicates the technology is actually harmful to the Internet.)
正如我们前面提到的，并不是所有的RFC都是标准的。事实上，许多重要的RFC根本不在标准轨道上。目前，RFC有两个名称并不意味着是标准：信息性的，如Tao，和实验性的。（实际上还有第三个名称，历史性的，但它是为那些在标准轨道上的文件保留的，并且由于缺乏当前使用而被删除，或者最近的想法表明该技术实际上对互联网有害。）
The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as "standards" even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed.
IETF中经常讨论信息RFC的作用。许多人喜欢拥有它们，特别是那些在IETF之外创建但被IETF文档引用的规范。它们对于作为IETF工作组所做工作的先驱的规范也很有用。另一方面，有些人将信息RFC称为“标准”，即使RFC不是标准，通常是为了愚弄容易上当的公众，让他们知道他们正在销售或支持的东西。当这种情况发生时，关于信息RFC的争论又重新开始了。
Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular (or proves that it works well), it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards-track material, but for which there are still unanswered questions.
实验性RFC适用于可能感兴趣的规范，但目前尚不清楚是否会对实现这些规范感兴趣，或者一旦部署它们是否会起作用。也就是说，一个规范可能解决一个问题，但是如果不清楚许多人是否认为这个问题很重要，或者认为他们会用规范来解决这个问题，那么这个规范可能会被标记为实验性RFC。如果以后规范变得流行（或证明它工作良好），则可以作为标准跟踪RFC重新发布。实验性RFC也被用来让人们用一种看起来可能是标准轨道材料的技术进行实验，但对于这项技术，仍然有一些尚未解答的问题。
The IESG has created guidelines on how it chooses between Informational and Experimental status: http://www.ietf.org/u/ietfchair/info-exp.html. If you are creating a document that you think might become an Experimental RFC, knowing the current thinking will help you justify your proposed choice.
IESG制定了关于如何在信息状态和实验状态之间进行选择的指南：http://www.ietf.org/u/ietfchair/info-exp.html. 如果您正在创建一个您认为可能会成为实验性RFC的文档，了解当前的想法将有助于您证明所建议的选择是正确的。
*Read* -- Review the Internet Drafts in your area of expertise and comment on them in the Working Groups. Participate in the discussion in a friendly, helpful fashion, with the goal being the best Internet standards possible. Listen much more than you speak. If you disagree, debate the technical issues: never attack the people.
*阅读*——审查你专业领域的互联网草案，并在工作组中对其进行评论。以友好、有益的方式参与讨论，目标是尽可能达到最佳的互联网标准。多听多说。如果你不同意，就讨论技术问题：永远不要攻击人民。
*Implement* -- Write programs that use the current Internet standards. The standards aren't worth much unless they are available to Internet users. Implement even the "minor" standards, since they will become less minor if they appear in more software. Report any problems you find with the standards to the appropriate Working Group so that the standard can be clarified in later revisions. One of the oft-quoted tenets of the IETF is "running code wins", so you can help support the standards you want to become more widespread by creating more running code.
*实施*——编写使用当前互联网标准的程序。除非互联网用户可以使用这些标准，否则这些标准没有多大价值。甚至实现“次要”标准，因为如果它们出现在更多的软件中，它们将变得不那么次要。向相应的工作组报告您发现的与标准有关的任何问题，以便在以后的修订中澄清标准。IETF的一个经常被引用的原则是“运行代码赢”，因此您可以通过创建更多运行代码来帮助支持您想要变得更广泛的标准。
*Write* -- Edit or co-author Internet Drafts in your area of expertise. Do this for the benefit of the Internet community, not to get your name (or, even worse, your company's name) on a document. Draft authors are subject to all kinds of technical (and sometimes personal) criticism; receive it with equanimity and use it to improve your draft in order to produce the best and most interoperable standard.
*撰写*——编辑或共同撰写您专业领域的互联网草稿。这样做是为了互联网社区的利益，而不是为了让你的名字（或者更糟糕的是，你公司的名字）出现在文档上。各种各样的作者有时都会受到技术性的批评；平静地接受它，并使用它来改进您的草稿，以产生最佳和最可互操作的标准。
*Share* -- Avoid proprietary standards. If you are an implementor, exhibit a strong preference for IETF standards. If the IETF standards aren't as good as the proprietary standards, work to make the IETF standards better. If you're a purchaser, avoid products that use proprietary standards that compete with the open standards of the IETF and tell the companies you buy from that you are doing so.
*共享*——避免专有标准。如果您是一名实施者，请表现出对IETF标准的强烈偏好。如果IETF标准不如专有标准好，那么努力使IETF标准更好。如果您是买家，请避免使用与IETF开放标准竞争的专有标准的产品，并告诉您购买的公司您正在这样做。
*Open Up* -- If your company controls a patent that is used in an IETF standard, convince the company to make the patent available at no cost to everyone who is implementing the standard. In the past few years, patents have caused a lot of serious problems for Internet standards because they prevent some companies from being able to freely implement the standards. Fortunately, many companies have generously offered unlimited licenses for particular patents in order to help the IETF standards flourish. These companies are usually rewarded with positive publicity for the fact that they are not as greedy or short-sighted as other patent-holders.
*开放*——如果您的公司控制IETF标准中使用的专利，请说服该公司免费向实施该标准的所有人提供该专利。在过去几年中，专利给互联网标准带来了许多严重问题，因为它们妨碍了一些公司自由实施这些标准。幸运的是，许多公司慷慨地为特定专利提供了无限许可证，以帮助IETF标准蓬勃发展。这些公司通常会得到积极的宣传，因为它们不像其他专利持有者那样贪婪或短视。
*Join* -- Become a member of ISOC. More important, urge any company that has benefited from the Internet to become a corporate member of ISOC, since this has the greatest financial benefit for the group. It will, of course, also benefit the Internet as a whole.
*加入*——成为ISOC的成员。更重要的是，敦促任何受益于互联网的公司成为ISOC的公司成员，因为这对集团的财务效益最大。当然，这也将使整个互联网受益。
As much as many IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum. There are many (perhaps too many) other standards organizations whose decisions affect the Internet. There are also a fair number of standards bodies that ignored the Internet for a long time and now want to get a piece of the action.
尽管许多IETF参与者不这么认为，IETF并不存在于标准真空中。有许多（也许太多）其他标准组织的决策会影响互联网。还有相当多的标准机构长期忽视互联网，现在想从中分得一杯羹。
In general, the IETF tries to have cordial relationships with other significant standards bodies. This isn't always easy, since many other bodies have very different structures than the IETF does, and
一般来说，IETF试图与其他重要的标准机构建立友好关系。这并不总是容易的，因为许多其他机构的结构与IETF非常不同，而且
the IETF is mostly run by volunteers who would probably prefer to write standards rather than meet with representatives from other bodies. Even so, some other standards bodies make a great effort to interact well with the IETF despite the obvious cultural differences.
IETF主要由志愿者管理，他们可能更愿意编写标准，而不是与其他机构的代表会面。即便如此，尽管存在明显的文化差异，但其他一些标准机构仍在努力与IETF良好互动。
At the time of this writing, the IETF has some liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). As stated in the IAB Charter [BCP39], "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications". In practice, the IETF prefers liaisons to take place directly at Working Group level, with formal relationships and liaison documents in a backup role.
在撰写本文时，IETF与大型标准机构有一些联系，包括ITU（国际电信联盟）、W3C、Unicode联盟和ISO/IEC JTC1（国际标准化组织和国际电工委员会联合技术委员会）。正如IAB章程[BCP39]中所述，“联络应尽可能非正式，并且在提高IETF规范的质量方面必须具有明显的价值”。实际上，IETF倾向于直接在工作组级别进行联络，正式关系和联络文件起备份作用。
Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Detail-oriented readers will learn much about the formal methods for dealing with other standards bodies in [BCP102], "IAB Processes for Management of IETF Liaison Relationships", and [BCP103], "Procedures for Handling Liaison Statements to and from the IETF". The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons, www.ietf.org/liaisonActivities.html. The list shows that there are many different liaisons to ISO/IEC JTC1 subcommittees.
其中一些联络任务属于IESG，而另一些则属于IAB。注重细节的读者将在[BCP102]、“IETF联络关系管理的IAB流程”和[BCP103]、“处理与IETF之间的联络声明的程序”中了解与其他标准机构打交道的正式方法。检查IETF是否有任何正式联络的最佳地点是IETF联络人列表，www.IETF.org/contractionactivities.html。清单显示，ISO/IEC JTC1小组委员会有许多不同的联络人。
Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's natural for the computer press (and even the trade press) to want to cover its actions. In recent years, a small number of magazines have assigned reporters and editors to cover the IETF in depth over a long period of time. These reporters have ample scars from articles that they got wrong, incorrect statements about the status of Internet Drafts, quotes from people who are unrelated to the IETF work, and so on.
鉴于IETF是帮助推动互联网发展的最知名机构之一，计算机媒体（甚至贸易媒体）自然希望报道其行动。近年来，少数杂志指派记者和编辑长期深入报道IETF。这些记者从错误的文章、关于互联网草稿状态的错误陈述、与IETF工作无关的人的引用中留下了大量的伤疤，等等。
Major press errors fall into two categories: saying that the IETF is considering something when in fact there is just an Internet Draft in a Working Group, and saying that the IETF approved something when all that happened was that an Informational RFC was published. In both cases, the press is not fully to blame for the problem, since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Of course, a bit of research by the reporters would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The default press contact for the IETF is the IAD, who can be reached at mailto:iad@ietf.org.
主要的新闻错误分为两类：一类是说IETF正在考虑某件事，而事实上工作组中只有一份互联网草案；另一类是说IETF批准了某件事，而事实上只是发布了一份信息RFC。在这两种情况下，媒体并不是问题的全部责任，因为他们通常会被一家公司提醒，该公司试图为他们制定或至少支持的协议获得宣传。当然，记者们的一点调查可能会让他们接触到一些可以解决问题的人，比如工作组主席或区域主管。IETF的默认新闻联系人是IAD，可以通过mailto联系到IAD：iad@ietf.org.
The fact that those reporters who've gotten it wrong once still come back to IETF meetings shows that it is possible to get it right eventually. However, IETF meetings are definitely not for reporters who are naive about the IETF process (although if you are a reporter the fact that you are reading this document is a very good sign!). Furthermore, if you think that you'll get a hot story from attending an IETF meeting, you are likely to be disappointed.
事实上，那些曾经犯过错误的记者仍然会回到IETF会议上，这表明最终纠正错误是可能的。然而，IETF会议绝对不是为那些对IETF过程不了解的记者而召开的（尽管如果你是记者，那么你正在阅读本文件是一个非常好的迹象！）。此外，如果你认为参加IETF会议会引起轰动，你可能会失望。
Considering all this, it's not surprising that some IETFers would prefer to have the press stay as far away from meetings as possible. Having a bit of press publicity for protocols that are almost near completion and will become significant in the industry in the next year can be a good thing. However, it is the rare reporter who can resist over-hyping a nascent protocol as the next savior for the Internet. Such stories do much more harm than good, both for the readers of the article and for the IETF.
考虑到所有这些，一些电子记者希望媒体尽可能远离会议也就不足为奇了。对即将完成的协议进行一点新闻宣传，并将在明年在业界发挥重要作用，这可能是一件好事。然而，很少有记者能够抵制将一个新生的协议过度炒作为互联网的下一个救世主。对于本文读者和IETF来说，这样的故事弊大于利。
The main reason why a reporter might want to attend an IETF meeting is not to cover hot technologies (since that can be done in the comfort of your office by reading the mailing lists) but to meet people face-to-face. Unfortunately, the most interesting people are the ones who are also the busiest during the IETF meeting, and some folks have a tendency to run away when they see a press badge. However, IETF meetings are excellent places to meet and speak with document authors and Working Group chairs; this can be quite valuable for reporters who are covering the progress of protocols.
记者可能想参加IETF会议的主要原因不是为了报道热门技术（因为这可以通过阅读邮件列表在舒适的办公室内完成），而是为了与人们面对面地见面。不幸的是，最有趣的人是那些在IETF会议期间最忙的人，一些人在看到记者徽章时有逃跑的倾向。然而，IETF会议是与文件作者和工作组主席会面和交谈的绝佳场所；这对于报道协议进展的记者来说是非常有价值的。
Reporters who want to find out about "what the IETF is doing" on a particular topic would be well-advised to talk to more than one person who is active on that topic in the IETF, and should probably try to talk to the WG chair in any case. It's impossible to determine what will happen with a draft by looking at the draft or talking to the draft's author. Fortunately, all WGs have archives that a reporter can look through for recent indications about what the progress of a draft is; unfortunately, few reporters have the time or inclination to do this kind of research. Because the IETF doesn't have a press liaison, magazines or newspapers that run a story with errors won't hear directly from the IETF and therefore often won't know what they did wrong, so they might easily do it again later.
想要了解某一特定主题的“IETF正在做什么”的记者最好与多个在IETF中活跃于该主题的人交谈，并且在任何情况下都应该尝试与工作组主席交谈。通过查看草稿或与草稿作者交谈来确定草稿会发生什么是不可能的。幸运的是，所有的工作组都有档案，记者可以通过这些档案查找关于草案进展情况的最新迹象；不幸的是，很少有记者有时间或倾向于做这种研究。由于IETF没有新闻联络人，因此刊登有错误报道的杂志或报纸不会直接从IETF那里得到消息，因此通常不知道他们做错了什么，因此他们可能很容易在以后再这样做。
Section 8.4.4 explains why each RFC is required to have a Security Considerations section and gives some idea of what it should and should not contain. Other than that information, this document does not touch on Internet security.
第8.4.4节解释了为什么要求每个RFC都有一个安全注意事项部分，并给出了它应该和不应该包含的内容的一些想法。除此之外，本文件不涉及互联网安全。
Pronounced "dow", Tao is the basic principle behind the teachings of Lao-tse, a Chinese master. Its familiar symbol is the black-and-white yin-yang circle. Taoism conceives the universe as a single organism, and human beings as interdependent parts of a cosmic whole. Tao is sometimes translated "the way", but according to Taoist philosophy the true meaning of the word cannot be expressed in words.
道的发音为“道”，是中国大师老子教导背后的基本原则。它熟悉的符号是黑白的阴阳圆。道教认为宇宙是一个单一的有机体，人类是宇宙整体中相互依存的部分。道有时被翻译成“道”，但根据道家哲学，道的真正含义无法用语言表达。
Some useful email addresses are listed here. These addresses may change from time to time, and it's a good idea to check the IETF web pages for the correct address before sending your mail.
这里列出了一些有用的电子邮件地址。这些地址可能会不时更改，在发送邮件之前，最好检查IETF网页中的正确地址。
Address Description
-----------------------------------------------------------------
agenda@ietf.org Requests for agenda slots at IETF
meetings
Address Description
-----------------------------------------------------------------
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-action@ietf.org Requests for things to be done when you don't know exactly where to send the request
ietf-action@ietf.org当您不知道将请求发送到何处时，请求要完成的事情
ietf-info@ietf.org General questions about the IETF
ietf-info@ietf.org关于IETF的一般问题
ietf-registrar@ietf.org Questions about registration, meeting locations, and fees
ietf-registrar@ietf.org有关注册、会议地点和费用的问题
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-request@ietf.org加入/离开IETF列表的请求
ietf-secretary@ietf.org Questions for the Secretariat
ietf-secretary@ietf.org秘书处的问题
ietf-web@ietf.org Questions or comments about the IETF web site
ietf-web@ietf.org关于IETF网站的问题或评论
internet-drafts@ietf.org Internet Draft submissions and queries
互联网-drafts@ietf.org互联网草案提交和查询
proceedings@ietf.org Where to send Working Group minutes and slides for the IETF Proceedings
proceedings@ietf.org向何处发送IETF会议记录和幻灯片
iana@iana.org Internet Assigned Numbers Authority
iana@iana.org互联网分配号码管理局
rfc-editor@rfc-editor.org RFC Editor
rfc-editor@rfc-org RFC编辑器
statements@ietf.org Incoming liaison statements from other organizations
statements@ietf.org从其他组织收到的联络声明
Online upload pages are planned for the future to facilitate submission of Internet Drafts, Proceedings, and Liaison statements.
未来计划在线上传页面，以便于提交互联网草案、会议记录和联络声明。
The IETF web site, http://www.ietf.org, is the best source for information about meetings, Working Groups, Internet Drafts, RFCs, IETF email addresses, and much more. Click on "Additional Information" to find a variety of helpful links. Internet Drafts and other documents are also available in the "ietf" directory on anonymous FTP sites worldwide. For a listing of these sites, see http://www.ietf.org/shadow.html.
IETF网站，http://www.ietf.org，是有关会议、工作组、Internet草稿、RFC、IETF电子邮件地址等信息的最佳来源。点击“附加信息”查找各种有用的链接。Internet草稿和其他文档也可在全球匿名FTP站点的“ietf”目录中找到。有关这些网站的列表，请参阅http://www.ietf.org/shadow.html.
Check the IESG web pages, http://www.ietf.org/iesg.html, to find up-to-date information about drafts processed, RFCs published, and documents in Last Call, as well as the monthly IETF status reports.
查看IESG网页，http://www.ietf.org/iesg.html，以查找有关已处理的草稿、已发布的RFC和上次通话中的文档以及每月IETF状态报告的最新信息。
Some of the acronyms and abbreviations from this document are listed below.
本文件中的一些首字母缩略词和缩写如下所示。
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
Numbers, http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force,
http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
Numbers, http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force,
http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1 Joint Technical Committee of the International
Organization for Standardization and
International Electrotechnical Commission,
http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union,
http://www.itu.int
RFC Request for Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1 Joint Technical Committee of the International
Organization for Standardization and
International Electrotechnical Commission,
http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union,
http://www.itu.int
RFC Request for Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
If you've gotten this far in the Tao, you've learned a lot about how the IETF works. What you'll find in this appendix summarizes much of what you've read and adds a few new points to ponder. Be sure to read through all the principles; taken as a whole, they'll give you a new slant on what makes the IETF work.
如果你已经在道中走了这么远，你已经学到了很多关于IETF如何工作的知识。本附录中的内容总结了您所阅读的大部分内容，并添加了一些新的思考点。一定要通读所有的原则；作为一个整体，他们会让你对IETF的工作有一个新的认识。
P1. The IETF works by an open process and by rough consensus. This applies to all aspects of the operation of the IETF, including creation of IETF documents and decisions on the processes that are used. But the IETF also observes experiments and running code with interest, and this should also apply to the operational processes of the organization.
P1。IETF以开放的过程和大致的共识工作。这适用于IETF运行的所有方面，包括创建IETF文件和对所用过程的决策。但是IETF也饶有兴趣地观察实验和运行代码，这也应该适用于组织的操作过程。
P2. The IETF works in areas where it has, or can find, technical competence.
P2。IETF在其拥有或能够找到技术能力的领域工作。
P3. The IETF depends on a volunteer core of active participants.
P3。IETF依靠积极参与者的志愿者核心。
P4. Membership of the IETF or of its WGs is not fee-based or organizationally defined, but is based upon self-identification and active participation by individuals.
P4。IETF或其工作组的成员资格不是基于费用或组织定义的，而是基于个人的自我认同和积极参与。
P5. The IETF recognizes leadership positions and grants power of decision to the leaders, but decisions are subject to appeal.
P5。IETF承认领导职位，并授予领导决策权，但决策可上诉。
P6. Delegation of power and responsibility are essential to the effective working of the IETF. As many individuals as possible will be encouraged to take on leadership of IETF tasks.
P6。权力和责任的授权对于IETF的有效工作至关重要。将鼓励尽可能多的个人担任IETF任务的领导。
P7. Dissent, complaint, and appeal are a consequence of the IETF's nature and should be regarded as normal events, but ultimately it is a fact of life that certain decisions cannot be effectively appealed.
P7。异议、投诉和上诉是IETF性质的结果，应视为正常事件，但最终，某些决定无法有效上诉是生活的事实。
P8. Leadership positions are for fixed terms (although we have no formal limitation on the number of terms that may be served).
第8页。领导职位的任期是固定的（尽管我们没有正式的任期限制）。
P9. It is important to develop future leaders within the active community.
第9页。在活跃的社区中培养未来的领导者很重要。
P10. A community process is used to select the leadership.
第10页。社区流程用于选择领导层。
P11. Leaders are empowered to make the judgment that rough consensus has been demonstrated. Without formal membership, there are no formal rules for consensus.
P11。领导人有权作出判断，大致的共识已经得到证明。没有正式成员资格，就没有达成共识的正式规则。
P12. Although the IETF needs clear and publicly documented process rules for the normal cases, there should be enough flexibility to allow unusual cases to be handled according to common sense. We apply personal judgment and only codify when we're certain. (But we do codify who can make personal judgments.)
第12页。尽管IETF需要针对正常情况制定明确且公开记录的过程规则，但应具有足够的灵活性，以允许根据常识处理异常情况。我们运用个人判断，只有在确定的情况下才进行编纂。（但我们确实将谁能做出个人判断编成法典。）
P13. Technical development work should be carried out by tightly chartered and focused Working Groups.
第13页。技术开发工作应由特许的、重点突出的工作组进行。
P14. Parts of the process that have proved impractical should be removed or made optional.
第14页。已被证明不切实际的工艺部分应移除或成为可选。
P15. Working Groups (WGs) should be primarily responsible for the quality of their output, and therefore for obtaining early review; WG chairs as WG leaders, backed up by the IETF leadership, should act as a quality backstop.
P15。工作组应主要负责其产出的质量，因此应尽早获得审查；作为工作组领导的工作组主席，在IETF领导的支持下，应该成为质量的后盾。
P16. WGs should be primarily responsible for assessing the negative impact of their work on the Internet as a whole, and therefore for obtaining cross-area review; the IETF leadership should act as a cross-area backstop.
第16页。工作组应主要负责评估其工作对整个互联网的负面影响，从而获得跨领域审查；IETF领导层应充当跨区域的后盾。
P17. Early review of documents is more effective in dealing with major problems than late review.
第17页。在处理重大问题时，提前审查文件比晚审查更有效。
P18. Area Directors (ADs) are responsible for guiding the formation and chartering of WGs, for giving them direction as necessary, and for terminating them.
第18页。区域总监（ADs）负责指导工作组的组建和租赁，必要时给予指导，并终止工作组。
P19. WG chairs are responsible for ensuring that WGs execute their charters, meet their milestones, and produce deliverables that are ready for publication.
第19页。工作组主席负责确保工作组执行其章程，达到其里程碑，并产生可供发布的交付成果。
P20. ADs are responsible for arranging backstop review and final document approval.
P20。ADs负责安排后台审查和最终文件批准。
P21. IETF documents often start as personal drafts, may become WG drafts, and are approved for permanent publication by a leadership body independent of the WG or individuals that produced them.
第21页。IETF文件通常以个人草稿开始，可能成为工作组草稿，并由独立于工作组的领导机构或产生这些文件的个人批准永久出版。
P22. IETF documents belong to the community, not to their authors. But authorship is recognized and valued, as are lesser contributions than full authorship.
P22。IETF文档属于社区，而不是其作者。但是，作者身份是被认可和重视的，与正式作者身份相比，作者身份的贡献更小。
P23. Technical quality and correctness are the primary criteria for reaching consensus about documents.
第23页。技术质量和正确性是就文件达成共识的主要标准。
P24. IETF specifications may be published as Informational, Experimental, Standards Track, or Best Current Practice.
P24。IETF规范可以作为信息性、实验性、标准跟踪或当前最佳实践发布。
P25. IETF Standards Track specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) But, on legal advice, the IETF does not take responsibility for interoperability tests and does not certify interoperability.
第25页。在证明可互操作的独立实现之前，IETF标准跟踪规范不被认为是令人满意的标准。（这是“运行代码”口号的体现。）但是，根据法律建议，IETF不负责互操作性测试，也不认证互操作性。
P26. IETF processes are currently published as Best Current Practice documents.
第26页。IETF过程目前作为最佳实践文件发布。
P27. Useful information that is neither a specification nor a process may be published as Informational.
P27。既不是规范也不是过程的有用信息可以作为信息发布。
P28. Obsolete or deprecated specifications and processes may be downgraded to Historic.
P28。过时或弃用的规范和流程可能降级为历史规范和流程。
P29. The standards track should distinguish specifications that have been demonstrated to interoperate.
P29。标准跟踪应区分已证明可互操作的规范。
P30. Standards Track and Best Current Practice documents must be subject to IETF wide rough consensus (Last Call process). WG rough consensus is normally sufficient for other documents.
第30页。标准跟踪和最佳现行实践文件必须符合IETF范围内的粗略共识（最后一次呼叫过程）。对于其他文件，工作组的粗略共识通常足够了。
P31. Substantive changes made after a document leaves a WG must be referred back to the WG.
第31页。文件离开工作组后所做的实质性更改必须提交给工作组。
P32. The IETF determines requirements for publication and archiving of its documents.
第32页。IETF确定其文件的发布和归档要求。
Informative References
资料性引用
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[BCP10]Galvin，J.，“IAB和IESG的选择、确认和召回过程：提名和召回委员会的运作”，BCP 10，RFC 3777，2004年6月。
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[BCP11]Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP22]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[BCP25]Bradner，S.，“IETF工作组指南和程序”，BCP 25，RFC 2418，1998年9月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[BCP39] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[BCP39]互联网架构委员会和B.Carpenter，“互联网架构委员会（IAB）章程”，BCP 39，RFC 2850，2000年5月。
[BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
[BCP45]Harris，S.，“IETF讨论列表章程”，BCP 45，RFC 3005，2000年11月。
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[BCP72]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[BCP78]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[BCP79]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
[BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[BCP95]Alvestrand，H.，“IETF的使命声明”，BCP 95，RFC 3935，2004年10月。
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[BCP101]Austein，R.和B.Wijnen，“IETF行政支持活动（IASA）的结构”，BCP 101，RFC 4071，2005年4月。
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[BCP102]Daigle，L.和互联网架构委员会，“IETF联络关系管理的IAB流程”，BCP 102，RFC 4052，2005年4月。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103]Trowbridge，S.，Bradner，S.，和F.Baker，“处理进出IETF的联络声明的程序”，BCP 103，RFC 4053，2005年4月。
[RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
[RFC1796]Huitema，C.，Postel，J.，和S.Crocker，“并非所有RFC都是标准”，RFC 1796，1995年4月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[STD3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[STD3]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
Authors' Addresses
作者地址
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·霍夫曼私人有限公司，邮编95060
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Susan Harris 1722 Chandler Road Ann Arbor, MI 48104 US
美国密歇根州安阿伯市钱德勒路1722号，邮编：48104
EMail: srh@umich.edu
EMail: srh@umich.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。