rfc1391.txt

RFC 的详细文档！

   still fresh in their minds.


Social Event

   Another of the most important things organized and managed by the
   local hosts is the IETF social event.  The social event has become
   something of a tradition at the IETF meetings.  It has been
   immortalized by Marshal Rose with his reference to "many fine lunches
   and dinners" [ROSE], and by Claudio and Julia Topolcic with their
   rendition of "Nerds in Paradise" on a pink T-shirt.

   Newcomers to the IETF are encouraged to attend the social event.
   Everyone is encouraged to wear their name tags.  The social event is
   designed to give people a chance to meet on a social, rather than
   technical, level.

   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.


Agenda

   The Agenda for the IETF meetings is a very fluid thing.  It is sent,
   in various forms, to the IETF announcement list three times prior to
   the meeting.  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 printers.

   The Secretariat will announce Agenda changes during the morning
   plenary sessions.  Changes will also be posted on the bulletin board



Internet Engineering Task Force                                 [Page 7]

RFC 1391                    The Tao of IETF                 January 1993


   near the IETF Registration Table (not the hotel registration desk).

   Assignments for breakout rooms (that's where the Working Groups and
   BOFs meet) and a map showing the room locations make up the At-A-
   Glance sheet (included in the Registration Packets).  Room
   assignments are as flexible as the Agenda.  Some Working Groups meet
   multiple times during a meeting and every attempt is made to have a
   Working Group meet in the same room each session.  Room assignment
   changes are not necessarily permanent for the week.  Always check the
   At-A-Glance first, then the bulletin board.  When in doubt, check
   with a member of the Secretariat at the Registration Table.


Other General Things

   The opening Plenary on Monday morning is the most heavily attended
   session.  It is where important introductory remarks are made, so
   people are encouraged to attend.

   The guy wearing the suit is probably Vint Cerf, the President of the
   Internet Society and an IAB member.  If you see a guy doing a strip
   tease out of a suit, it's definitely Vint (but don't come just to see
   him do it again; he's only done it once in the Internet's 20 year
   history).

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

   "Bar BOFs" are unofficial get-togethers, usually in the late evening,
   during which a lot of work gets done over drinks.

   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 always safe to question an
   opinion and offer alternatives, but don't expect an IETFer to follow
   an order.

   The IETF, and the plenary sessions in particular, are not places for
   vendors to try to sell their wares.  People can certainly answer



Internet Engineering Task Force                                 [Page 8]

RFC 1391                    The Tao of IETF                 January 1993


   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.


Registration Bullets

   Registration is such an important topic, that it's in this RFC twice!
   This is the "very important registration bullets" section.

   o  To attend an IETF meeting: you have to register and you have to
      pay the registration fee.

   o  All you need to do to be registered is to send in a completed
      Registration Form.

   o  You may register by mail, email or fax.  Email and fax
      registration forms will be accepted until 1:00 P.M. ET on the
      Friday before the meeting.

   o  You may preregister and pay, preregister and pay later,
      preregister and pay on-site, or register and pay on-site.

   o  To get the lower registration fee, you must register by the early
      registration deadline (about one month before the meeting).  You
      can still pay later or on-site.

   o  If you don't register by the early registration deadline, a late
      fee is added.

   o  Everyone pays the same fees.  There are no education or group
      discounts.  There are no discounts for attending only part of the
      week.

   o  Register only ONE person per registration form.  Substitutions are
      NOT allowed.

   o  You may register then pay later, but you may not pay then register
      later.  Payment MUST be accompanied by a completed registration
      form.

   o  Purchase orders are NOT accepted.  DD Form 1556 IS accepted.

   o  Refunds are subject to a $20 service charge.  Late fees will not
      be refunded.

   o  The registration fee covers a copy of the meeting's Proceedings,



Internet Engineering Task Force                                 [Page 9]

RFC 1391                    The Tao of IETF                 January 1993


      Sunday evening reception (cash bar), a daily continental
      breakfast, and two daily coffee breaks.


Mailing Lists and Archives

   As previously mentioned, 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 which 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 which 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 cannot attend the
   IETF meetings.

   All IETF discussion lists have a "-request" address which handles the
   administrative details of joining and leaving the list.  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.  To find out where a particular list is
   archived, send a message to the list's "-request" address, NOT to the
   list itself.


Important Email Addresses

   There are some important IETF email addresses with which everyone
   should be familiar.  They are all located at "cnri.reston.va.us"
   (e.g., "[e-mail]").  To personalize things, the
   names of the Secretariat staff who handle the lists are given.

   o  ietf-info        general queries about the IETF-
                       Greg Vaudreuil, Megan Davies and Cynthia Clark

   o  ietf-rsvp        queries about meeting locations and fees,
                       emailed Registration Forms-
                       Debra Legare



Internet Engineering Task Force                                [Page 10]

RFC 1391                    The Tao of IETF                 January 1993


   o  proceedings      queries about previous Proceedings availability,
                       orders for copies of the Proceedings-
                       Debra Legare

   o  ietf-announce-request
                       requests to join/leave IETF announcement list-
                       Cynthia Clark

   o  ietf-request     requests to join/leave IETF discussion list-
                       Cynthia Clark

   o  internet-drafts  Internet-Draft submissions-
                       Cynthia Clark

   o  iesg-secretary   Greg Vaudreuil


IETF Proceedings

   The IETF Proceedings are compiled in the two months following each
   IETF meeting.  The Proceedings usually start with a message from
   Phill Gross, the Chair of the IETF.  Each contains the final
   (hindsight) Agenda, an IETF overview, a report from the IESG, Area
   and Working Group reports, network status briefings, slides from the
   protocol and technical presentations, and the attendees list.  The
   attendees list includes an attendee's name, affiliation, work phone
   number, work fax number, and email address, as provided on the
   Registration Form.

   A copy of the Proceedings will be sent to everyone who registered for
   the IETF.  The cost is included in the registration fee.  The
   Proceedings are sent to the mailing addresses provided on the
   Registration Forms.

   For those who could not attend a meeting but would like a copy of the
   Proceedings send a check for $35 (made payable to CNRI) to:

      Corporation for National Research Initiatives
      Attn: Accounting Department - IETF Proceedings
      1895 Preston White Drive, Suite 100
      Reston, VA   22091

   Please indicate which meeting Proceedings you would like to receive
   by specifying the meeting date (e.g., July 1992) or meeting number
   and location (e.g., 24th meeting in Boston).  Availability of
   previous meeting Proceedings is limited, so check BEFORE sending
   payment.




Internet Engineering Task Force                                [Page 11]

RFC 1391                    The Tao of IETF                 January 1993


Be Prepared

   This topic cannot be stressed enough.  As the IETF grows, it becomes
   more and more important for attendees to arrive prepared for the
   Working Groups meetings they plan to attend.  This doesn't apply only
   to newcomers; everybody should come prepared.

   Being prepared means having read the documents which the Working
   Group or BOF Chair has distributed.  It means having followed the
   discussions on the Working Group's mailing list or having reviewed
   the archives.  For the Working Group/BOF Chairs, it means getting all
   of the documents out early enough (i.e., several weeks) to give
   everybody time to read them.  It also means announcing an agenda and
   sticking with it.

   At the Chair's discretion, some time may be devoted to bringing new
   Working Group attendees up to speed.  In fact, long lived Working
   Groups have occasionally held entire sessions which were introductory
   in nature.  As a rule, however, a Working Group is not the place to
   go for training.  Observers are always welcome, but they must realize
   that the work effort cannot be delayed for education.  Anyone wishing
   to attend a Working Group for the first time might seek out the Chair
   prior to the meeting and ask for some introduction.

   Another thing, for everybody, to consider is that Working Groups go
   through phases.  In the initial phase (say, the first two meetings),
   all ideas are welcome.  The idea is to gather all the possible
   solutions together for consideration.  In the development phase, a
   solution is chosen and developed.  Trying to reopen issues which were
   decided more than a couple of meetings back is considered bad form.
   The final phase (the last two meetings) is where the "spit and
   polish" are applied to the architected solution.  This is not the
   time to suggest architectural changes or open design issues already
   resolved.  It's a bad idea to wait until the last minute to speak out
   if a problem is discovered.  This is especially true for people whose
   excuse is that they hadn't read the documents until the day before a
   comments period ended.

   Time at the IETF meetings is a precious thing.  Working Groups are
   encouraged to meet between IETF meetings, either in person or by
   video or telephone conference.  Doing as much work as possible over
   the mailing lists would also reduce the amount of work which must be
   done at the meeting.

RFCs and Internet-Drafts

   Originally, RFCs were just what the name implies; they were requests
   for comments.  The early RFCs were messages between the ARPANET



Internet Engineering Task Force                                [Page 12]

RFC 1391                    The Tao of IETF                 January 1993


   architects about how to resolve certain problems.  Over the years,
   RFCs became more formal.  It reached the point that they were being
   cited as standards, even when they weren't.

   Internet Experiment Notes (IEN) were created to become a new informal
   document series about the early experimental work on TCP and IP.  It
   was thought that having "Notes" as part of the name would prevent
   them from being cited as standards.  As the work matured, the
   documentation was done as RFCs.

   RFCs continue to be the important documents about the Internet; there
   are now two special sub-series within the RFCs: FYIs and STDs.  The
   For Your Information RFC sub-series was created to document overviews
   and things which are introductory.  Frequently, FYIs are created by
   the IETF User Services Area.  The STD RFC sub-series is new.  It was
   created to identify those RFCs which do specify full Internet
   Standards.  RFCs of every type have an RFC number by which they are
   indexed and by which they can be retrieved.  FYIs and STDs have FYI
   numbers and STD numbers, respectively, in addition to RFC numbers.
   This makes it easier for a new Internet user, for example, to find
   all of the helpful, informational documents, by looking in the FYI
   index.  In addition, FYI and STD numbers never change across a
   document revision, while the RFC number does.

   Internet-Drafts (I-D) are working documents of the IETF.  Any group
   (e.g., Working Group, BOF) or individual may submit a document for
   distribution as an I-D.  An I-D is valid for six months.  Recent
   guidelines require that an expiration date appear on every page of an
   I-D.  An I-D may be updated, replaced or obsoleted at any time.  It
   is not appropriate to use I-Ds as reference material or to cite them,
   other than as a "working draft" or "work in progress".

   For additional information, read the following documents: