Network Working Group                                          S. Harris
Request for Comments: 3160                                 Merit Network
FYI: 17                                                      August 2001
Obsoletes: 1718
Category: Informational
Network Working Group                                          S. Harris
Request for Comments: 3160                                 Merit Network
FYI: 17                                                      August 2001
Obsoletes: 1718
Category: Informational

The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force


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 (2001). All Rights Reserved.




This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process.


Table of Contents


   Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .   3
   1. What Is the IETF?  . . . . . . . . . . . . . . . . . . . . .   4
      1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . .   5
      1.2 The Hierarchy  . . . . . . . . . . . . . . . . . . . . .   5
          1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . .   5
          1.2.2 IESG . . . .  . . . . . . . . . . . . . .  . . . .   6
          1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . .   7
          1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . .   8
          1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . .   8
          1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . .   9
      1.3  IETF Mailing Lists. . . . . . . . . . . . . . . . . . .   9
   2.  IETF Meetings   . . . . . . . . . . . . . . . . . . . . . .  10
       2.1 Registration  . . . . . . . . . . . . . . . . . . . . .  11
       2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . .  12
       2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . .  12
       2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . .  13
       2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . .  13
       2.6 Meals and Other Delights. . . . . . . . . . . . . . . .  14
       2.7 Social Event. . . . . . . . . . . . . . . . . . . . . .  14
   Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .   3
   1. What Is the IETF?  . . . . . . . . . . . . . . . . . . . . .   4
      1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . .   5
      1.2 The Hierarchy  . . . . . . . . . . . . . . . . . . . . .   5
          1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . .   5
          1.2.2 IESG . . . .  . . . . . . . . . . . . . .  . . . .   6
          1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . .   7
          1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . .   8
          1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . .   8
          1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . .   9
      1.3  IETF Mailing Lists. . . . . . . . . . . . . . . . . . .   9
   2.  IETF Meetings   . . . . . . . . . . . . . . . . . . . . . .  10
       2.1 Registration  . . . . . . . . . . . . . . . . . . . . .  11
       2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . .  12
       2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . .  12
       2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . .  13
       2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . .  13
       2.6 Meals and Other Delights. . . . . . . . . . . . . . . .  14
       2.7 Social Event. . . . . . . . . . . . . . . . . . . . . .  14
       2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . .  14
       2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . .  15
           2.9.1  IS Managers. . . . . . . . . . . . . . . . . . .  15
           2.9.2  Network Operators and ISPs . . . . . . . . . . .  15
           2.9.3  Networking Hardware and Software Vendors . . . .  15
           2.9.4  Academics  . . . . . . . . . . . . . . . . . . .  16
           2.9.5  Computer Trade Press . . . . . . . . . . . . . .  16
       2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . .  16
       2.11 Other General Things . . . . . . . . . . . . . . . . .  17
   3.  Working Groups. . . . . . . . . . . . . . . . . . . . . . .  18
       3.1 Working Group Chairs  . . . . . . . . . . . . . . . . . .18
       3.2 Getting Things Done in a Working Group. . . . . . . . .  19
       3.3 Preparing for Working Group Meetings    . . . . . . . .  19
       3.4 Working Group Mailing Lists   . . . . . . . . . . . . .  20
       3.5 Interim Working Group Meetings  . . . . . . . . . . . .  21
   4.  BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   5.  New to the IETF?  STOP HERE! (Temporarily). . . . . . . . .  22
   6.  RFCs and Internet Drafts  . . . . . . . . . . . . . . . . .  22
       6.1 Getting a Standard Published  . . . . . . . . . . . . .  22
       6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . .  24
       6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . .  24
           6.3.1 Recommended Reading for Writers . . . . . . . . .  25
           6.3.2 Filenames and Other Matters . . . . . . . . . . .  26
       6.4 Standards-Track RFCs  . . . . . . . . . . . . . . . . .  26
           6.4.1 Telling It Like It Is -- Using MUST and
                 SHOULD and MAY. . . . . . . . . . . . . . . . . .  27
           6.4.2 Normative References in Standards . . . . . . . .  28
           6.4.3 IANA Considerations . . . . . . . . . . . . . . .  29
           6.4.4 Security Considerations . . . . . . . . . . . . .  29
           6.4.5 Patents in IETF Standards . . . . . . . . . . . .  30
       6.5 Informational and Experimental RFCs . . . . . . . . . .  31
   7. How to Contribute to the IETF -- What You Can Do . . . . . .  31
       7.1  What Your Company Can Do . . . . . . . . . . . . . . .  32
   8. IETF and the Outside World . . . . . . . . . . . . . . . . .  33
       8.1 IETF and Other Standards Groups . . . . . . . . . . . .  33
       8.2 Press Coverage of the IETF. . . . . . . . . . . . . . .  33
   9. References . . . . . . . . . . . . . . . . . . . . . . . . .  35
       9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . .  35
       9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . .  35
       9.3 Useful Documents and Files. . . . . . . . . . . . . . .  35
       9.4 Acronyms and Abbreviations Used in the Tao  . . . . . .  36
       9.5 Documents Cited in the Tao  . . . . . . . . . . . . . .  36
   Security Considerations . . . . . . . . . . . . . . . . . . . .  37
   Editor's Address  . . . . . . . . . . . . . . . . . . . . . . .  37
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .  38
       2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . .  14
       2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . .  15
           2.9.1  IS Managers. . . . . . . . . . . . . . . . . . .  15
           2.9.2  Network Operators and ISPs . . . . . . . . . . .  15
           2.9.3  Networking Hardware and Software Vendors . . . .  15
           2.9.4  Academics  . . . . . . . . . . . . . . . . . . .  16
           2.9.5  Computer Trade Press . . . . . . . . . . . . . .  16
       2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . .  16
       2.11 Other General Things . . . . . . . . . . . . . . . . .  17
   3.  Working Groups. . . . . . . . . . . . . . . . . . . . . . .  18
       3.1 Working Group Chairs  . . . . . . . . . . . . . . . . . .18
       3.2 Getting Things Done in a Working Group. . . . . . . . .  19
       3.3 Preparing for Working Group Meetings    . . . . . . . .  19
       3.4 Working Group Mailing Lists   . . . . . . . . . . . . .  20
       3.5 Interim Working Group Meetings  . . . . . . . . . . . .  21
   4.  BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   5.  New to the IETF?  STOP HERE! (Temporarily). . . . . . . . .  22
   6.  RFCs and Internet Drafts  . . . . . . . . . . . . . . . . .  22
       6.1 Getting a Standard Published  . . . . . . . . . . . . .  22
       6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . .  24
       6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . .  24
           6.3.1 Recommended Reading for Writers . . . . . . . . .  25
           6.3.2 Filenames and Other Matters . . . . . . . . . . .  26
       6.4 Standards-Track RFCs  . . . . . . . . . . . . . . . . .  26
           6.4.1 Telling It Like It Is -- Using MUST and
                 SHOULD and MAY. . . . . . . . . . . . . . . . . .  27
           6.4.2 Normative References in Standards . . . . . . . .  28
           6.4.3 IANA Considerations . . . . . . . . . . . . . . .  29
           6.4.4 Security Considerations . . . . . . . . . . . . .  29
           6.4.5 Patents in IETF Standards . . . . . . . . . . . .  30
       6.5 Informational and Experimental RFCs . . . . . . . . . .  31
   7. How to Contribute to the IETF -- What You Can Do . . . . . .  31
       7.1  What Your Company Can Do . . . . . . . . . . . . . . .  32
   8. IETF and the Outside World . . . . . . . . . . . . . . . . .  33
       8.1 IETF and Other Standards Groups . . . . . . . . . . . .  33
       8.2 Press Coverage of the IETF. . . . . . . . . . . . . . .  33
   9. References . . . . . . . . . . . . . . . . . . . . . . . . .  35
       9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . .  35
       9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . .  35
       9.3 Useful Documents and Files. . . . . . . . . . . . . . .  35
       9.4 Acronyms and Abbreviations Used in the Tao  . . . . . .  36
       9.5 Documents Cited in the Tao  . . . . . . . . . . . . . .  36
   Security Considerations . . . . . . . . . . . . . . . . . . . .  37
   Editor's Address  . . . . . . . . . . . . . . . . . . . . . . .  37
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .  38



Over the last several 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 e-mail messages.


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.


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 FYI provides the mundane bits of information that newcomers will need in order to become active participants.


Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and FYIs. (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;" and FYIs provide topical and technical overviews that are introductory or appeal to a broad audience. See Section 6 for more information.)


The acronyms and abbreviations used in this document are usually expanded in place, and are explained fully in Section 9.




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 draft are also much appreciated. Paul Hoffman wrote significant portions of this revision and provided encouragement, expertise, and much-needed guidance. Other contributors include Scott Bradner, Michael Patton, Donald E. Eastlake III, the IETF Secretariat, and members of the User Services Working Group.

该文件的原始版本于1994年出版,由加里·马尔金撰写。他对IETF的知识、见解和无与伦比的写作风格为后来的修订定下了标准,他对当前草案的贡献也备受赞赏。保罗·霍夫曼(Paul Hoffman)撰写了本次修订的重要部分,并提供了鼓励、专业知识和急需的指导。其他贡献者包括Scott Bradner、Michael Patton、Donald E.Eastlake III、IETF秘书处和用户服务工作组成员。

1. What Is the IETF?
1. 什么是IETF?

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.


Its mission includes:


- Identifying, and proposing solutions to, pressing operational and technical problems in the Internet;

- 识别互联网上紧迫的运营和技术问题,并提出解决方案;

- Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet;

- 指定协议的开发或使用以及解决互联网技术问题的近期架构;

- Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet;

- 向互联网工程指导小组(IESG)提出关于互联网协议和协议使用标准化的建议;

- Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community; and

- 促进互联网研究工作队(IRTF)向更广泛的互联网社区进行技术转让;和

- Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, and network managers.

- 为供应商、用户、研究人员、机构承包商和网络经理之间在互联网社区内交流信息提供论坛。

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.


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 1.3). This is where the best information about current IETF activities and focus can be found.


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 BCP 11, "The Organizations Involved in the IETF Standards Process." If you participate in the IETF and only read one BCP, this is the one you should read.

当然,如果没有某种结构,任何组织都不可能像IETF那样成功。在IETF的案例中,该结构由其他组织提供,如BCP 11“参与IETF标准过程的组织”中所述。如果您参与IETF并且只阅读一个BCP,则这是您应该阅读的BCP。

1.1 Humble Beginnings
1.1 卑微的开端

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 over 100 attendees.


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.


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.


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. One in five 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 US.


1.2 The Hierarchy
1.2 等级制度
1.2.1 ISOC (Internet Society)
1.2.1 互联网协会

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's oversight of the IETF is remarkably hands-off, so many IETF participants don't even know about it. 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-funded) heroes of the Internet.


1.2.2 IESG (Internet Engineering Steering Group)
1.2.2 IESG(互联网工程指导小组)

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. The IESG ratifies or corrects the output from the IETF's Working Groups, gets WGs started and finished, and makes sure that non-WG drafts that are about to become RFCs are correct.


The IESG consists of the Area Directors ("ADs"), who are selected by the Nominations Committee (which is usually called "Nomcom") and are appointed for two years. The process for choosing the members of the IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees."

IESG由区域总监(“ADs”)组成,由提名委员会(通常称为“Nomcom”)选出,任期两年。选择IESG成员的流程详见BCP 10,“IAB和IESG选择、确认和召回流程:提名和召回委员会的运作”

The current areas and abbreviations are:


- Applications (APP) Protocols seen by user programs, such as e-mail and the Web - General (GEN) Catch-all for WGs that don't fit in other areas (which is very few) - Internet (INT) Different ways of moving IP packets and DNS information - Operations and Operational aspects, network monitoring, Management (OPS) and configuration - Routing (RTG) Getting packets to their destinations - Security (SEC) Authentication and privacy - Transport (TSV) Special services for special packets - User Services (USV) Support for end users and user support organizations

- 用户程序看到的应用程序(APP)协议,如电子邮件和Web-一般(GEN)适用于不适合其他领域的WG(非常少)-互联网(INT)移动IP数据包和DNS信息的不同方式-操作和操作方面,网络监控、管理(OPS)和配置-路由(RTG)将数据包送到目的地-安全(SEC)认证和隐私-特殊数据包的传输(TSV)特殊服务-终端用户和用户支持组织的用户服务(USV)支持

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 an Area Director 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.


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 discusses each Internet Draft that is proposed to become an RFC. At least two IESG members must express concerns before a draft can be blocked from moving forward. These checks 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.


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 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 review that the WG review gets from the ADs.


The IETF is run by rough consensus, and it is the IESG that decides if a WG has come up with a result that has a real 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.


1.2.3 IAB (Internet Architecture Board)
1.2.3 IAB(互联网架构委员会)

The IAB is responsible for keeping an eye on the "big picture" of the Internet, and 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 brings these topics to the attention of people they think should know about them.


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.


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.


The IAB also:


- Approves Nomcom's IESG nominations - Acts as the appeals board for appeals against IESG actions - Appoints and oversees the RFC Editor - Approves the appointment of the IANA - Acts as an advisory body to the ISOC - Oversees IETF liaisons with other standards bodies

- 批准Nomcom的IESG提名-担任针对IESG行动的上诉委员会-任命并监督RFC编辑-批准IANA的任命-担任ISOC的咨询机构-监督IETF与其他标准机构的联络

Like the IESG, the IAB members are selected for multi-year positions by the Nomcom, and are approved by the Board of Trustees of the ISOC.


1.2.4 IANA (Internet Assigned Numbers Authority)
1.2.4 IANA(互联网分配号码管理局)

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.


Five years ago, no one would have expected to ever 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 which 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.


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年他不合时宜地去世。

1.2.5 RFC Editor
1.2.5 RFC编辑

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 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提供一个最终存储库(请参见 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 ISOC and can be contacted by e-mail at


1.2.6 IETF Secretariat
1.2.6 IETF秘书处

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 for helping the IESG do its work. The IETF Secretariat is financially supported by the fees of the face-to-face meetings.


1.3 IETF Mailing Lists
1.3 IETF邮件列表

Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, "". This is where all of the meeting information, Internet Draft and RFC announcements, and IESG Protocol Actions and Last Calls are posted. People who would like to "get technical" may also join the IETF discussion list, "". This is where discussions of cosmic significance are held (Working Groups have their own mailing lists for discussions related to their work).

计划参加IETF会议的任何人都应加入IETF公告邮件列表“IETF”". 这是所有会议信息、互联网草案和RFC公告、IESG协议操作和最后通话的发布地点。希望“掌握技术”的人也可以加入IETF讨论列表". 这是举行具有宇宙意义的讨论的地方(工作组有自己的邮件列表,用于与工作相关的讨论)。

Subscriptions to these and other IETF mailing lists are handled by a program called Majordomo. Majordomo tends to be somewhat finicky about the format of subscription messages, and interacts poorly with email programs that make all email messages into HTML files. Majordomo will treat you well, however, if you format your messages just the way it likes. To join the IETF announcement list, for example, send email to:



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:


and enter the word 'subscribe' as explained above. If you decide to withdraw from either list, use the word 'unsubscribe.' Your messages to Majordomo should have nothing other than the commands 'subscribe' or 'unsubscribe' in them.


Both lists are archived on the IETF web site:


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 e-mail addresses or leaving a list, send your request only to the "-request" address, not to the main list. This means you!!


The IETF discussion list is unmoderated. This means that anyone 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 "IETF Discussion List Charter," RFC 3005. It is a good idea to read the whole RFC (it's short!) before posting to the IETF discussion list.

IETF讨论列表未降额。这意味着任何人都可以就影响互联网的问题发表意见。然而,正如“IETF讨论列表章程”RFC 3005所述,它不是公司或个人招揽或宣传的场所。在发布到IETF讨论列表之前,最好先阅读整个RFC(很短!)。

Only the Secretariat can send messages to the announcement list.


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.


2. IETF Meetings
2. 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 dweebfests 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, although ISOC kicks in additional funds for things like the multicast simulcast of some Working Group sessions.


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.


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 or two. The past few meetings have had about 2,500 attendees. There have been over 50 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages,


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 half the people in a WG meeting reading e-mail or perusing the web during presentations they find uninteresting.


2.1 Registration
2.1 登记

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 e-mail to the IETF-announce mailing list, and information is posted on the IETF web site,, that same day.


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 breaks.


Credit card payments on the web are encrypted and secure, or, if you prefer, you can use PGP to send your payment information to the Registrar (


Registration is open throughout the week of the meeting. However, the Secretariat highly recommends that attendees arrive for early registration, beginning at noon on Sunday and continuing throughout the 5:00 Sunday evening reception. The reception is a popular event where you can get a 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 or IETF mailing lists are ever offered for sale.


2.2 Newcomers' Orientation
2.2 新来者的定位

Newcomers are encouraged to attend the Newcomers' Orientation, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF Secretariat, and is intended to provide useful introductory information. The orientation is typically about 30 minutes long and 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.


Immediately following the Newcomers' Orientation 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. The Standards Process Orientation also lasts about 30 minutes.


There is ample time at the end for questions. The Secretariat also provides handouts that include an overview of the IETF, a list of important files available online, and hard copies of the slides of the "IETF Structure and Internet Standards Process" presentation. These very useful slides are also available online at under "Additional Information".


The orientation is held on Sunday afternoon before the 5:00 p.m. reception (check the agenda for exact time and location). Be advised that attending the orientation does NOT mean you can go to the reception early!


2.3 Dress Code
2.3 着装要求

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!).


2.4 Seeing Spots Before Your Eyes
2.4 看到眼前的斑点

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 following meanings:


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.


2.5 Terminal Room
2.5 候机室

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 who donate their equipment, services and time are to be heartily congratulated and thanked.


While 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. The terminal room provides workstations, one or two printers, and ports for laptops.


2.6 Meals and Other Delights
2.6 用餐和其他乐趣

Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners." While it is true that some people eat very well at the IETF, they find the food on their own; lunches and 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.

马歇尔·罗斯(Marshall Rose)曾说过,IETF是一个“许多美味午餐和晚餐”的去处。虽然确实有些人在IETF吃得很好,但他们自己找到了食物;注册费不包括午餐和晚餐。秘书处确实在周日晚上的招待会上提供开胃菜(并非取代晚餐)、每天早上的欧式早餐,以及(最重要的是)下午休息时的饼干、布朗尼和其他美味佳肴。

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.


2.7 Social Event
2.7 社会事件

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 the 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.


Newcomers to the IETF are encouraged to attend the social event. Everyone is 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.


2.8 Agenda
2.8 议程

The agenda for the IETF meetings is a very fluid thing. It is sent, updated, to the IETF announcement list three times prior to the meeting, and is also available on the web. The agenda for the 50th IETF, for example, is at 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).

IETF会议的议程是一个非常不稳定的事情。在会议之前,它会三次发送、更新到IETF公告列表中,也可以在web上获得。例如,第50届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.


2.9 Where Do I Fit In?
2.9 我适合哪里?

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.


2.9.1 IS Managers
2.9.1 信息系统经理

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.


This is not to say that no one from 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.


2.9.2 Network Operators and ISPs
2.9.2 网络运营商和ISP

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 might find attending the IETF meeting valuable. The closer you are to the bleeding edge of networking, particularly in the areas of routing and switching, the more likely it is that you will be able to learn and contribute at an IETF meeting.


2.9.3 Networking Hardware and Software Vendors
2.9.3 网络硬件和软件供应商

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.


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.


2.9.4 Academics
2.9.4 学者

IETF meetings are often excellent places for computer science folk 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.


2.9.5 Computer Trade Press
2.9.5 计算机贸易出版社

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 8.2.


2.10 Proceedings
2.10 诉讼

IETF proceedings are compiled in the two months following each meeting, and are available on the web, on CD, and in print. 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.


The proceedings usually start with an informative (and highly entertaining) message from Steve Coya, the Executive Director of the IETF. Each volume of 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执行董事史蒂夫·科亚(Steve Coya)的信息(高度娱乐性)开始。每卷包含最终(事后)议程、IETF概述、区域和工作组报告以及协议和技术演示的幻灯片。如果材料没有及时提交秘书处出版,工作组的报告和介绍有时是不完整的。

An attendee list is also included, and contains names, affiliations, work and fax phone numbers, and e-mail addresses as provided on the registration form. For information about obtaining copies of the proceedings, see the Web listing at


2.11 Other General Things
2.11 其他一般事项

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!


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).


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.


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, 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.


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, etc.). Please check with the Secretariat before placing materials on the desk; the Secretariat has the right to remove material that they feel is not appropriate.


3.0 Working Groups
3.0 工作组

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 a very good reason.) BCP 25, "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions.

IETF的绝大多数工作是在许多“工作组”中完成的;在撰写本文时,大约有115个不同的工作组。(术语“工作组”通常被视为大写,但可能不是出于一个很好的理由。)BCP 25,“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. Some IETF WG mailing lists only let subscribers to the mailing list post to the mailing list, while others let anyone post. Each Working Group has one or two chairs.


More importantly, 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.


3.1 Working Group Chairs
3.1 工作组主席

The role of the WG chairs is described in both BCP 11 and BCP 25. Basically, their job is to keep the discussion moving forward towards the milestones in the WG charter -- usually publication of one or more RFCs. They are not meant to be taskmasters, but are responsible for assuring positive forward motion and preventing random wandering.

工作组主席的作用在BCP 11和BCP 25中均有描述。基本上,他们的工作是保持讨论朝着工作组章程中的里程碑前进——通常是发布一个或多个RFC。他们不是监工,而是负责确保正向运动和防止随机游荡。

As you can imagine, some Working Group chairs are much better at their jobs than others. 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 called "degenerative Working Group syndrome."


One important role of the chair is to decide which Internet Drafts get published as "official" Working Group drafts, and which don't. In practice, there is actually not much procedural difference between WG drafts and independent drafts; 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 new chairs' training lunch the first day of the IETF meeting. If you're interested in what they hear there, take a look at the slides at


3.2 Getting Things Done in a Working Group
3.2 在工作组中完成工作

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.


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. The lack of 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?)


3.3 Preparing for Working Group Meetings
3.3 筹备工作组会议

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 beforehand. 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.


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, where 'xx' is the meeting number), but many WG chairs are lax (if not totally negligent) about turning them in.


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.


If you're giving a presentation at a face-to-face meeting, you should probably come with a few slides prepared. Projectors for laptop-based presentations are available in all the meeting rooms. And here's a tip for your slides: don't put your company's logo on every one, even though it's common practice outside the IETF. The IETF frowns on this kind of corporate advertising, and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism.


3.4 Working Group Mailing Lists
3.4 工作组邮寄名单

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 everybody follow the discussions on the mailing lists of the Working Groups that they 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).


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.


Most IETF discussion lists use Majordomo and have a "-request" address which handles the administrative details of joining and leaving the list. (See Section 1.3 for more information on Majordomo.) It is generally frowned upon when such administrivia appears on the discussion mailing list.


Most IETF discussion lists are archived. That is, all of the messages sent to the list are automatically stored on a host for anonymous FTP access. Many such archives are listed online at 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!).

大多数IETF讨论列表都已存档。也就是说,发送到列表的所有消息都自动存储在主机上,以便进行匿名FTP访问。许多这样的档案都在网上列出 如果找不到要查找的列表,请将消息发送到列表的“-request”地址(而不是列表本身!)。

3.5 Interim Working Group Meetings
3.5 临时工作组会议

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 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, and the group needs to take attendance.


4. BOFs
4. 转炉

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.


A 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 they think. 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 meetings have a very different tone than 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, while others start from scratch.


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.


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.


5.  ** New to the IETF? STOP HERE! (Temporarily) **
   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.
5.  ** New to the IETF? STOP HERE! (Temporarily) **
   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.
6. RFCs and Internet Drafts
6. RFC和互联网草案

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, 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, For Internet Drafts, the best resource is the IETF web site,, where you can search by title and keyword.

如果您是新的IETF参与者,并且正在寻找特定的RFC或Internet草稿,请访问RFC编辑器的网页, 该网站还提供了指向其他RFC收藏的链接,其中许多具有搜索功能。如果您知道要查找的RFC的编号,请转到IETF RFC页面, 对于Internet草稿,最好的资源是IETF网站,,您可以在其中按标题和关键字进行搜索。

6.1 Getting a Standard Published
6.1 发布标准

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.


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:


1. Publish the document as an Internet Draft 2. Receive comments on the draft 3. Edit your draft based on the comments 4. Repeat steps 1 through 3 a few times 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. 6. Make any changes deemed necessary by the IESG (this might include giving up on becoming a standard) 7. Wait for the document to be published by the RFC Editor

1. 将文档发布为Internet草稿2。接受对草案3的评论。根据评论4编辑您的草稿。重复步骤1至3几次5。请区域主管将草案提交给IESG(如果是个人提交)。如果草案是正式工作组产品,工作组主席要求广告将其提交给IESG。6.做出IESG认为必要的任何更改(这可能包括放弃成为标准)7。等待RFC编辑器发布文档

A much more complete explanation of these steps is contained in BCP 9, "The Internet Standards Process." Anyone who writes a draft that they hope will become an IETF standard must read BCP 9 so that they can follow the path of their document through the process. BCP 9 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标准的人都必须阅读BCP 9,以便他们能够沿着文件的路径通过过程。BCP 9非常详细地讨论了一个经常被误解的话题,即使是经验丰富的IETF参与者也是如此:不同类型的RFC会经历不同的过程,并有不同的排名。有六种RFC:

- Proposed standards - Draft standards - Internet standards (sometimes called "full standards") - Experimental protocols - Informational documents - Historic standards

- 拟定标准-标准草案-互联网标准(有时称为“完整标准”)-实验协议-信息文件-历史标准

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 RFC 1796, "Not All RFCs are Standards."


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 which are introductory or appeal to a broad audience. Frequently, FYIs are created by groups within the IETF User Services Area. 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子系列是为了记录概述和主题而创建的,这些概述和主题是介绍性的,或对广大读者有吸引力。通常,FYI由IETF用户服务区域内的组创建。当前最佳实践文件描述了各种技术在互联网上的应用。创建STD RFC子系列是为了识别实际上指定了互联网标准的RFC。有些STD实际上是一套以上的RFC,“标准”名称适用于整套文件。

6.2 Letting Go Gracefully
6.2 优雅地放手

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.


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.


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 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.


6.3 Internet Drafts
6.3 互联网草稿

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 BCP 9 says:

第一件事。RFC存储库中的每个文档都以互联网草稿的形式开始使用。互联网上的草稿是暂时性的文件——它们是供读者评论的,因此作者可以仔细考虑这些评论,并决定将哪些评论纳入草稿中。为了提醒人们他们的潜力,互联网草稿在六个月后会自动从在线目录中删除。它们绝对不是标准,甚至不是规范。正如BCP 9所说:

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 they brag about having published an Internet Draft; it takes no significant effort.


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. RFC 2223, "Instructions to RFC Authors," describes the nroff formatting used by the RFC Editor.

I-D的格式应与RFC大致相同。与许多人的信念相反,I-D不需要看起来完全像RFC,但是如果您可以在创建I-D时使用RFC编辑器使用的相同格式设置过程,那么当您的草稿作为RFC发布时,它将简化RFC编辑器的工作。RFC 2223,“RFC作者须知”描述了RFC编辑器使用的nroff格式。

An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the chair before being accepted as a WG item.


6.3.1 Recommended Reading for Writers
6.3.1 作家推荐阅读

Before you create the first draft of your Internet Draft, you should read four documents:


- More important than just explaining formatting, RFC 2223 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.

- 更重要的是,RFC2223不仅解释了格式,还解释了互联网草稿在成为RFC之前需要包含哪些内容。本文档描述了文档中需要包含的所有部分和注意事项,最好从一开始就将它们放在文档中,这样读者在您将它们放入更高版本时不会感到惊讶。

- BCP 22, "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.

- BCP 22,“互联网标准编写者指南”提供了一些技巧,可以帮助您编写一个实现互操作性的标准。例如,它解释了如何选择正确数量的协议选项,如何响应超出规范的行为,以及如何显示状态图。

- The online "Guidelines to Authors of Internet Drafts,", 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.

- 在线“互联网草稿作者指南,”,具有有关提交互联网草稿过程的最新信息,以及必须包含在每个互联网草稿中的最新样板信息。

- 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 "Considerations for Internet Drafts,", a list of common "nits" 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.

- 当您认为您已经完成了草稿流程,并准备好要求草稿成为RFC时,您应该明确阅读“互联网草稿的注意事项”,这是一个常见的“NIT”列表,已知这些NIT会阻止IESG中的文档。事实上,您可能应该在完成之前阅读该文档,这样您就不必在最后一刻进行大量更改。

6.3.2 Filenames and Other Matters
6.3.2 文件名和其他事项

When you're ready to turn in your Internet Draft, send it to the Internet Drafts editor at There is a real person at the other end of this mail address -- their 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, the draft editor supplies the 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草稿时,请将其发送到Internet上的Internet草稿编辑器 在这个邮件地址的另一端有一个真实的人——他们的工作是确保你已经包含了互联网草稿发布所需的最低项目。提交草稿的第一个版本时,草稿编辑器将提供草稿的文件名。如果草案是正式工作组产品,名称将以“草案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, the author sometimes follows 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 editor (and, if it is an official WG draft, the WG chair) to come up with the filename.


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 the first version, such as when a personal effort is pulled into a Working Group.


6.4 Standards-Track RFCs
6.4 标准跟踪RFC

The procedure for creating and advancing a standard is described in BCP 9. 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.

BCP 9中描述了创建和推进标准的程序。互联网草案经过充分讨论后,人们大致一致认为它所说的将是一个有用的标准,然后提交给IESG审议。如果草案是工作组的正式草案,工作组主席在完成工作组最后一次会议后将其发送给相应的区域主任。如果草稿是个人提交的,草稿的作者或编辑将其提交给相应的区域主管。BCP 9还描述了那些认为工作组主席、广告或IESG在考虑创建或推进标准时做出错误决定的人的上诉程序。

After it 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 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.


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.


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 while 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." This doesn't happen often, and 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 before making a Draft Standard an Internet Standard.


6.4.1 Telling It Like It Is -- Using MUST and SHOULD and MAY
6.4.1 用“必须”和“应该”以及“可能”来表达

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 1123, "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 BCP 14, "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 lists a few synonyms for the words defined.

早在1989年,RFC1123《对互联网主机的要求——应用程序和支持》就有一个简短的词汇列表,这些词汇似乎很有用,即“必须”、“应该”和“可能”。这些定义在BCP 14“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.


BCP 14 is a short document, and 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标准的人都应该阅读。虽然“必须”和“不得”的定义相当明确,“应该”和“不应该”的定义在许多工作组中引起了大量讨论。在审查互联网草案时,经常会提出这样一个问题:“这句话中应该包含“必须”还是“应该?”这确实是一个很好的问题,因为规范不应该包含免费的“必须”,也不应该包含互操作性所需的“应该”。这就涉及到标准中过度规定和不充分规定要求的问题的关键。

6.4.2 Normative References in Standards
6.4.2 标准中的规范性引用

One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folk) 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 is one that is helpful to an implementor but is not needed. As we noted above, a "MUST" specification would certainly be normative, so any reference needed to implement the "MUST" would be normative. A "SHOULD" or "MAY" specification is not necessarily


normative, but it could be normative based on what is being required. There is definitely room for debate here!


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.


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.


6.4.3 IANA Considerations
6.4.3 IANA考虑

More and more IETF standards require the registration of various protocol parameters, such as named options in the protocol. As we noted in Section 1.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.


Anyone writing an Internet standard that may need an IANA registry needs to read BCP 26, "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注册中心的互联网标准的人都需要阅读BCP 26《RFC中IANA注意事项编写指南》,其中描述了RFC作者应如何正确要求IANA启动或接管注册中心。IANA还维护早在BCP 26产生之前就开始的注册。

6.4.4 Security Considerations
6.4.4 安全考虑

One thing that's required in every RFC 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.


6.4.5 Patents in IETF Standards
6.4.5 IETF标准中的专利

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."


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. You can read about the official rules in BCP 9, but you should assume that the application of those rules is flexible and depends on the type of patent, the patent holder, and the availability of alternate technologies that are not encumbered by patents.

IETF在标准中处理专利的方法是一个备受争议的话题。您可以阅读BCP 9中的官方规则,但是您应该假设这些规则的应用是灵活的,并且取决于专利类型、专利持有人以及不受专利限制的替代技术的可用性。

Patent holders who freely allow their patents to be used by people implementing IETF standards often get a great deal of good will 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).


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, send a note to the IETF Secretariat ( about the patent or other intellectual property rights. The note will be published on the IETF IPR web page ( Intellectual property rights aren't

如果你正在写一份互联网草稿,并且你知道一项专利适用于你正在写的技术,不要在文档中列出该专利。相反,向IETF秘书处(IETF)发送一份说明关于专利或其他知识产权。该说明将发布在IETF IPR网页上( 知识产权并非如此

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 a RFC could be incomplete and mislead the reader. BCP 9 provides specific text that should be added to RFCs where the author knows of IPR issues.

在RFC中提到,因为RFC在发布后不会更改,但知识产权知识可以随时更改。因此,RFC中的IPR列表可能不完整,并误导读者。BCP 9提供了作者知道知识产权问题时应添加到RFC中的特定文本。

6.5 Informational and Experimental RFCs
6.5 信息和实验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, Historical, 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.)


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.


Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them. That is, a specification might solve a problem, but if it is not clear 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, 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.


7. How to Contribute to the IETF -- What You Can Do
7. 如何为IETF做出贡献——你能做什么

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.


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.


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.


7.1 What Your Company Can Do
7.1 你的公司能做什么

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.


Open Up -- If your company controls a patent that is used in an IETF standard, convince them 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.


Join -- Become a member of ISOC. More importantly, 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.


8. IETF and the Outside World
8. IETF与外部世界
8.1 IETF and Other Standards Groups
8.1 IETF和其他标准组

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 who ignored the Internet for a long time and now want to get a piece of the action.


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, and 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.


At the time of this writing, the IESG has some liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-IEC/JTC1 (The Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). The list of IETF liaisons,, shows that there are many different liaisons to ISO-IEC/JTC1 subcommittees.


8.2 Press Coverage of the IETF
8.2 IETF的新闻报道

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.


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 reporter would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The official press contact for the IETF is the IETF Secretariat.


The fact that those reporters who've gotten it wrong once 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!). Further, if you think that you'll get a hot story from attending an IETF meeting, you are likely to be disappointed.


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.


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.


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, a magazine or newspaper that runs 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.


9. References
9. 工具书类
9.1 Tao
9.1 道

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.


9.2 Useful E-mail Addresses
9.2 有用的电子邮件地址 Requests for agenda slots at IETF meetings General questions about the IETF Questions about registration, meeting locations, and fees Requests to join/leave IETF lists Questions for the Secretariat Web questions/comments Internet Draft submissions and queries Where to send Working Group minutes IETF Proceedings Coordinator Internet Assigned Numbers Authority RFC Editor

agenda@ietf.org请求在IETF会议上安排议程-info@ietf.org关于IETF IETF的一般问题-registrar@ietf.org关于注册、会议地点的问题,和费用-request@ietf.org加入/离开IETF列表的请求IETF-secretariat@ietf.org向秘书处提出的问题-web@ietf.org网上问题/评论-drafts@ietf.org互联网草案提交和查询minutes@ietf.org向何处发送工作组会议记录proceedings@ietf.orgIETF程序协调员 互联网分配号码管理局-ed@rfc-org RFC编辑器

9.3 Useful Documents and Files
9.3 有用的文件和档案

The IETF web site,, is the best source for information about meetings, Working Groups, Internet Drafts, RFCs, IETF e-mail 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:


Check the IESG web pages,, to find up-to-date information about drafts processed, RFCs published, and documents in Last Call, as well as the monthly IETF status reports.


9.4 Acronyms and Abbreviations Used in the Tao
9.4 Tao中使用的首字母缩略词和缩写词
   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
   IANA     Internet Assigned Numbers Authority
   ICANN    Internet Corporation for Assigned Names and Numbers,
   I-D      Internet Draft
   IESG     Internet Engineering Steering Group,
   IETF     Internet Engineering Task Force,
   INET     Internet Society Conference,
   IRTF     Internet Research Task Force,
   ISO      International Organization for Standardization,
            Joint Technical Committee of the International
            Organization for Standardization and International
            Electrotechnical Commission,
   ISOC     Internet Society,
   ITU      International Telecommunication Union,
   RFC      Request For Comments
   STD      Standard (RFC)
   W3C      World Wide Web Consortium,
   WG       Working Group
   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
   IANA     Internet Assigned Numbers Authority
   ICANN    Internet Corporation for Assigned Names and Numbers,
   I-D      Internet Draft
   IESG     Internet Engineering Steering Group,
   IETF     Internet Engineering Task Force,
   INET     Internet Society Conference,
   IRTF     Internet Research Task Force,
   ISO      International Organization for Standardization,
            Joint Technical Committee of the International
            Organization for Standardization and International
            Electrotechnical Commission,
   ISOC     Internet Society,
   ITU      International Telecommunication Union,
   RFC      Request For Comments
   STD      Standard (RFC)
   W3C      World Wide Web Consortium,
   WG       Working Group
9.5 Documents Cited in the Tao
9.5 《道》中引用的文献

BCP 9 "The Internet Standards Process" BCP 10 "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees" BCP 11 "The Organizations Involved in the IETF Standards Process" BCP 14 "Key words for use in RFCs to Indicate Requirement Levels" BCP 22 "Guide for Internet Standards Writers" BCP 25 "IETF Working Group Guidelines and Procedures" BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" RFC 1123 "Requirements for Internet Hosts -- Application and Support" RFC 1796 "Not All RFCs are Standards" RFC 2223 "Instructions to RFC Authors"

BCP 9“互联网标准流程”BCP 10“IAB和IESG选择、确认和召回流程:提名和召回委员会的运作“BCP 11”参与IETF标准流程的组织“BCP 14”RFC中用于指示需求水平的关键词“BCP 22”互联网标准编写者指南“BCP 25”“IETF工作组指南和程序”BCP 26“编写互联网主机RFC“RFC 1123”要求中IANA注意事项部分的指南——应用和支持“RFC 1796”并非所有RFC都是标准“RFC 2223”RFC作者说明

   "Considerations for Internet Drafts,"
   "Considerations for Internet Drafts,"
   "Guidelines to Authors of Internet-Drafts,"
   "Guidelines to Authors of Internet-Drafts,"

Security Considerations


Section 6.4.5 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.


Editor's Address


Susan Harris Merit Network, Inc. 4251 Plymouth Road, Suite 2000 Ann Arbor, MI 48105

Susan Harris Merit Network,Inc.美国密歇根州安娜堡普利茅斯路4251号2000室,邮编:48105


Full Copyright Statement


Copyright (C) The Internet Society (2001). All Rights Reserved.


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






Funding for the RFC Editor function is currently provided by the Internet Society.