rfc3160.txt

RFC 的详细文档！

   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.






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


   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
   ftp://ftp.ietf.org/ietf-mail-archive/.  If you don't find the list
   you're looking for, send a message to the list's "-request" address
   (not to the list itself!).

3.5 Interim Working Group Meetings

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

4. BOFs

   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.



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


   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.

6. RFCs and Internet Drafts

   If you're a new IETF participant and are looking for a particular RFC
   or Internet Draft, go to the RFC Editor's Web pages, http://www.rfc-
   editor.org/rfc.html.  That site also has links to other RFC
   collections, many with search capabilities.  If you know the number
   of the RFC you're looking for, go to the IETF RFC pages,
   http://www.ietf.org/rfc.html.  For Internet Drafts, the best resource
   is the IETF web site, http://www.ietf.org/ID.html, where you can
   search by title and keyword.

6.1 Getting a Standard Published

   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.




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


   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

   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:

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





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


6.2 Letting Go Gracefully

   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

   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:

      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.



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


   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.

   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

   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 docu