返回首页

RFC 4677 - The Tao of IETF - A Novices Guide to the Internet

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup P.Hoffman RequestforComments:4677VPNConsortium FYI:17 S.Harris Obsoletes:3160 UniversityofMichigan Category:Informational September2006 TheTaoofIETF:ANovice’sGuideto theInternetEngineeringTaskForce StatusofThisMemo Thismemoprovid
  Network Working Group                                              P. Hoffman
Request for Comments: 4677                                VPN Consortium
FYI: 17                                                                              S. Harris
Obsoletes: 3160                                            University of Michigan
Category: Informational                                          September 2006

                 The Tao of IETF: A Novice’s Guide to
                  the Internet Engineering Task Force

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the inner workings of IETF meetings and
   Working Groups, discusses organizations related to the IETF, and
   introduces the standards process.  It is not a formal IETF process
   document but instead an informational overview.

Table of Contents

   1. Introduction ....................................................4
   2. Acknowledgements ................................................5
   3. What Is the IETF? ...............................................5
      3.1. Humble Beginnings ..........................................6
      3.2. The Hierarchy ..............................................7
           3.2.1. ISOC (Internet Society) .............................7
           3.2.2. IESG (Internet Engineering Steering Group) ..........8
           3.2.3. IAB (Internet Architecture Board) ..................10
           3.2.4. IANA (Internet Assigned Numbers Authority) .........11
           3.2.5. RFC Editor .........................................11
           3.2.6. IETF Secretariat ...................................12
      3.3. IETF Mailing Lists ........................................12
   4. IETF Meetings ..................................................13
      4.1. Registration ..............................................14
      4.2. Take the Plunge and Stay All Week! ........................15
      4.3. Newcomer Training .........................................16
      4.4. Dress Code ................................................16
      4.5. Seeing Spots Before Your Eyes .............................16
      4.6. Terminal Room .............................................17
      4.7. Meals and Other Delights ..................................17
      4.8. Social Event ..............................................18
      4.9. Agenda ....................................................18
      4.10. EDU to the Rescue ........................................19
      4.11. Where Do I Fit In? .......................................19
           4.11.1. IS Managers .......................................19
           4.11.2. Network Operators and ISPs ........................19
           4.11.3. Networking Hardware and Software Vendors ..........20
           4.11.4. Academics .........................................20
           4.11.5. Computer Trade Press ..............................20
      4.12. Proceedings ..............................................21
      4.13. Other General Things .....................................21
   5. Working Groups .................................................22
      5.1. Working Group Chairs ......................................23
      5.2. Getting Things Done in a Working Group ....................24
      5.3. Preparing for Working Group Meetings ......................25
      5.4. Working Group Mailing Lists ...............................26
      5.5. Interim Working Group Meetings ............................27
   6. BOFs ...........................................................27
   7. New to the IETF and Coming to a Meeting? STOP HERE!
      (Temporarily) ..................................................28
   8. RFCs and Internet Drafts .......................................29
      8.1. Getting an RFC Published ..................................29
      8.2. Letting Go Gracefully .....................................30
      8.3. Internet Drafts ...........................................31
           8.3.1. Recommended Reading for Writers ....................32
           8.3.2. Filenames and Other Matters ........................33

      8.4. Standards-Track RFCs ......................................34
           8.4.1. Telling It Like It Is -- Using MUST and SHOULD
                  and MAY ............................................35
           8.4.2. Normative References in Standards ..................36
           8.4.3. IANA Considerations ................................37
           8.4.4. Security Considerations ............................37
           8.4.5. Patents in IETF Standards ..........................37
      8.5. Informational and Experimental RFCs .......................38
   9. How to Contribute to the IETF ..................................39
      9.1. What You Can Do ...........................................39
      9.2. What Your Company Can Do ..................................40
   10. IETF and the Outside World ....................................40
      10.1. IETF and Other Standards Groups ..........................40
      10.2. Press Coverage of the IETF ...............................41
   11. Security Considerations .......................................42
   Appendix A. Related Information ...................................43
      A.1. Why "the Tao"? ............................................43
      A.2. Useful Email Addresses ....................................43
      A.3. Useful Documents and Files ................................44
      A.4. Acronyms and Abbreviations Used in the Tao ................44
   Appendix B. IETF Guiding Principles ...............................45
      B.1. General ...................................................45
      B.2. Management and Leadership .................................45
      B.3. Process ...................................................46
      B.4. Working Groups ............................................46
      B.5. Documents .................................................47
   Informative References ............................................48

1.  Introduction

   Since its early years, attendance at Internet Engineering Task Force
   (IETF) face-to-face meetings has grown phenomenally.  Many of the
   attendees are new to the IETF at each meeting, and many of those go
   on to become regular attendees.  When the meetings were smaller, it
   was relatively easy for a newcomer to get into the swing of things.
   Today, however, a newcomer meets many more new people, some
   previously known only as the authors of documents or thought-
   provoking email messages.

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

   The IETF is always in a state of change.  Although the principles in
   this document are expected to remain largely the same over time,
   practical details may well have changed by the time you read it; for
   example, a web-based tool may have replaced an email address for
   requesting some sort of action.

   Many types of IETF documentation are mentioned in the Tao, from BCPs
   to RFCs and FYIs and STDs.  BCPs make recommendations for Best
   Current Practices in the Internet; RFCs are the IETF’s main technical
   documentation series, politely known as "Requests for Comments"; FYIs
   provide topical and technical overviews that are introductory or
   appeal to a broad audience; and STDs are RFCs identified as
   "standards".  See Section 8 for more information.

   The acronyms and abbreviations used in this document are usually
   expanded in place and are explained fully in Appendix A.

   This document is intended to obsolete FYI 17, RFC 3160.  See Section
   3.2.5 for information on what it means for one RFC to obsolete
   another.

2.  Acknowledgements

   The original version of this document, published in 1994, was written
   by Gary Malkin.  His knowledge of the IETF, insights, and unmatched
   writing style set the standard for this later revision, and his
   contributions to the current document are also much appreciated.
   Paul Hoffman wrote significant portions of this revision and provided
   encouragement, expertise, and much-needed guidance.  Other
   contributors include Brian Carpenter, Scott Bradner, Michael Patton,
   Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault,
   the IETF Secretariat, members of the User Services Working Group, and
   members of the PESCI design team.

3.  What Is the 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; see [BCP95], "A
   Mission Statement for the IETF", for more detail.

   Its mission includes the following:

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

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

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

   o  Facilitating technology transfer from the Internet Research Task
      Force (IRTF) to the wider Internet community

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

   In many ways, the IETF runs on the beliefs of its members.  One of
   the "founding beliefs" is embodied in an early quote about the IETF
   from David Clark: "We reject kings, presidents and voting.  We
   believe in rough consensus and running code".  Another early quote
   that has become a commonly-held belief in the IETF comes from Jon
   Postel: "Be conservative in what you send and liberal in what you
   accept".

   The IETF is really about its members.  Because of the unrestrictive
   membership policies, IETF members come from all over the world and
   from many different parts of the Internet industry.  See Section 4.11
   for information about the ways that many people fit into the IETF.

   One more thing that is important for newcomers: the IETF in no way
   "runs the Internet", despite what some people mistakenly might say.
   The IETF makes standards that are often adopted by Internet users,
   but it does not control, or even patrol, the Internet.  If your
   interest in the IETF is because you want to be part of the overseers,
   you may be badly disappointed by the IETF.

3.1.  Humble Beginnings

   The first IETF meeting was held in January 1986 at Linkabit in San
   Diego, with 21 attendees.  The 4th IETF, held at SRI in Menlo Park in
   October 1986, was the first that non-government vendors attended.
   The concept of Working Groups was introduced at the 5th IETF meeting
   at the NASA Ames Research Center in California in February 1987.  The
   7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the
   first meeting with more than 100 attendees.

   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.  About one in three IETF meetings are now
   held in Europe or Asia, and the number of non-US attendees continues
   to be high -- about 50%, even at meetings held in the United States.

3.2.  The Hierarchy

3.2.1.  ISOC (Internet Society)

   The Internet Society is an international, non-profit, membership
   organization that fosters the expansion of the Internet.  One of the
   ways that ISOC does this is through financial and legal support of
   the other "I" groups described here, particularly the IETF.  ISOC
   provides insurance coverage for many of the people in the IETF
   process and acts as a public relations channel for the times that one
   of the "I" groups wants to say something to the press.  The ISOC is
   one of the major unsung (and under-supported) heroes of the Internet.

   Starting in spring 2005, the ISOC also became home base for the
   IETF’s directly employed administrative staff.  This is described in
   more detail in [BCP101], "Structure of the IETF Administrative
   Support Activity (IASA)".  The staff initially includes only an
   Administrative Director (IAD) who works full-time overseeing IETF
   meeting planning, operational aspects of support services (the
   secretariat, IANA (the Internet Assigned Numbers Authority), and the
   RFC Editor, which are described later in this section), and the
   budget.  He or she (currently it’s a he) leads the IETF
   Administrative Support Activity (IASA), which takes care of tasks
   such as collecting meeting fees and paying invoices, and also
   supports the tools for the work of IETF working groups, the IESG, the
   IAB, and the IRTF (more about these later in this section).

   As well as staff, the IASA comprises volunteers and ex officio
   members from the ISOC and IETF leadership.  The IASA and the IAD are
   directed by the IETF Administrative Oversight Committee (IAOC), which
   is selected by the IETF community.  Here’s how all this looks:

                          Internet Society
                                 |
                                IAOC
                                 |
                                IASA
                                 |
                                IAD

   Neither the IAD nor the IAOC have any influence over IETF standards
   development, which we turn to now.

3.2.2.  IESG (Internet Engineering Steering Group)

   The IESG is responsible for technical management of IETF activities
   and the Internet standards process.  It administers the process
   according to the rules and procedures that have been ratified by the
   ISOC Trustees.  However, the IESG doesn’t do much direct leadership,
   such as the kind you will find in many other standards organizations.
   As its name suggests, its role is to set directions rather than to
   give orders.  The IESG ratifies or corrects the output from the
   IETF’s Working Groups (WGs), gets WGs started and finished, and makes
   sure that non-WG drafts that are about to become RFCs are correct.

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

   The current areas and abbreviations are shown below.

   Area                    Description
   -----------------------------------------------------------------
   Applications (APP)      Protocols seen by user programs, such as
                           email and the web

   General (GEN)           Catch-all for WGs that don’t fit in other
                           areas (which is very few)

   Internet (INT)          Different ways of moving IP packets and
                           DNS information

   Operations and          Operational aspects, network monitoring,
   Management (OPS)        and configuration

   Real-time               Delay-sensitive interpersonal
   Applications and        communications
   Infrastructure (RAI)

   Routing (RTG)           Getting packets to their destinations

   Security (SEC)          Authentication and privacy

   Transport (TSV)         Special services for special packets

   Because the IESG has a great deal of influence on whether Internet
   Drafts become RFCs, many people look at the ADs as somewhat godlike
   creatures.  IETF participants sometimes reverently ask Area Directors
   for their opinion on a particular subject.  However, most ADs are
   nearly indistinguishable from mere mortals and rarely speak from
   mountaintops.  In fact, when asked for specific technical comments,
   the ADs may often defer to members at large whom they feel have more
   knowledge than they do in that area.

   The ADs for a particular area are expected to know more about the
   combined work of the WGs in that area than anyone else.  On the other
   hand, the entire IESG reviews each Internet Draft that is proposed to
   become an RFC.  Any AD may record a "DISCUSS" ballot position against
   a draft if he or she has serious concerns.  If these concerns cannot
   be resolved by discussion, an override procedure is defined such that
   at least two IESG members must express concerns before a draft can be
   blocked from moving forward.  These procedures help ensure that an
   AD’s "pet project" doesn’t make it onto the standards track if it
   will have a negative effect on the rest of the IETF protocols and
   that an AD’s "pet peeve" cannot indefinitely block something.

   This is not to say that the IESG never wields power.  When the IESG
   sees a Working Group veering from its charter, or when a WG asks the
   IESG to make the WG’s badly designed protocol a standard, the IESG
   will act.  In fact, because of its high workload, the IESG usually
   moves in a reactive fashion.  It eventually approves most WG requests
   for Internet Drafts to become RFCs, and usually only steps in when
   something has gone very wrong.  Another way to think about this is
   that the ADs are selected to think, not to just run the process.  The
   quality of the IETF standards comes both from the review they get in
   the Working Groups and the scrutiny that the WG review gets from the
   ADs.

   The IETF is run by rough consensus, and it is the IESG that judges
   whether a WG has come up with a result that has community consensus.
   (See Section 5.2 for more information on WG consensus.)  Because of
   this, one of the main reasons that the IESG might block something
   that was produced in a WG is that the result did not really gain
   consensus in the IETF as a whole, that is, among all of the Working
   Groups in all areas.  For instance, the result of one WG might clash
   with a technology developed in a different Working Group.  An
   important job of the IESG is to watch over the output of all the WGs
   to help prevent IETF protocols that are at odds with each other.
   This is why ADs are supposed to review the drafts coming out of areas
   other than their own.

3.2.3.  IAB (Internet Architecture Board)

   The IAB is responsible for keeping an eye on the "big picture" of the
   Internet, and it focuses on long-range planning and coordination
   among the various areas of IETF activity.  The IAB stays informed
   about important long-term issues in the Internet, and it brings these
   topics to the attention of people it thinks should know about them.
   The IAB web site is at http://www.iab.org/.

   IAB 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:

   o  Approves NomCom’s IESG nominations

   o  Acts as the appeals board for appeals against IESG actions

   o  Appoints and oversees the RFC Editor

   o  Approves the appointment of the IANA

   o  Acts as an advisory body to ISOC

   o  Oversees IETF liaisons with other standards bodies

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

3.2.4.  IANA (Internet Assigned Numbers Authority)

   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.

   Ten years ago, no one would have expected to see the IANA mentioned
   on the front page of a newspaper.  IANA’s role had always been very
   low key.  The fact that IANA was also the keeper of the root of the
   domain name system forced it to become a much more public entity, one
   that was badly maligned by a variety of people who never looked at
   what its role was.  Nowadays, the IETF is generally no longer
   involved in the IANA’s domain name and IP address assignment
   functions, which are overseen by ICANN.

   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.

3.2.5.  RFC Editor

   The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容