rfc3160.txt

RFC 的详细文档！

Harris                       Informational                      [Page 5]

RFC 3160                    The Tao of IETF                  August 2001


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

   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

   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



Harris                       Informational                      [Page 6]

RFC 3160                    The Tao of IETF                  August 2001


   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)

   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.





Harris                       Informational                      [Page 7]

RFC 3160                    The Tao of IETF                  August 2001


   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

   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)

   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.

1.2.5 RFC Editor

   The RFC Editor edits, formats, and publishes Internet Drafts as RFCs,
   working in conjunction with the IESG.  An important secondary role is
   to provide one definitive repository for all RFCs (see
   http://www.rfc-editor.org).  Once an RFC is published, it is never
   revised.  If the standard it describes changes, the standard will be
   re-published in another RFC that "obsoletes" the first.



Harris                       Informational                      [Page 8]

RFC 3160                    The Tao of IETF                  August 2001


   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 [e-mail].

1.2.6 IETF Secretariat

   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

   Anyone who plans to attend an IETF meeting should join the IETF
   announcement mailing list, "[e-mail]".  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,
   "[e-mail]".  This is where discussions of cosmic significance
   are held (Working Groups have their own mailing lists for discussions
   related to their work).

   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:

      [e-mail]

   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:

      [e-mail]






Harris                       Informational                      [Page 9]

RFC 3160                    The Tao of IETF                  August 2001


   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:

      http://www.ietf.org/maillist.html

   Do not, ever, under any circumstances, for any reason, send a request
   to join a list to the list itself!  The thousands of people on the
   list don't need, or want, to know when a new person joins.
   Similarly, when changing 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.

   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

   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