rfc1603.txt

RFC 的详细文档！

     The Chair and/or Secretary must ensure that minutes of a
     session are taken and that an attendance list is circulated.
     See the section on Session Documents for detailed
     procedures.

     Immediately after a session, the WG Chair must immediately
     provide the Area Director with a very short report
     (approximately one paragraph, via email) on the session.
     This is used in an Area Report as presented in the
     Proceedings of each IETF meeting.

   Distribute the work

     Of course each WG will have participants who may not be able
     (or want) to do any work at all. Most of the time the bulk
     of the work is done by a few dedicated participants. It is
     the task of the Chair to motivate enough experts to allow
     for a fair distribution of the workload.

   Document development

     Working groups produce documents and documents need authors.
     The Chair will make sure that authors of WG documents
     incorporate changes as discussed by the WG.  See the section
     on Session Documents for details procedures.





Huizer & Crocker                                               [Page 18]

RFC 1603             IETF Working Group Guidelines            March 1994


   Document publication

     The Chair and/or Secretary will work with the RFC Editor to
     ensure document conformance with RFC publication
     requirements and to coordinate any editorial changes
     suggested by the RFC Editor.  A particular concern is that
     all participants are working from the same version of a
     document at the same time.

5.2. WG Editor/Secretary

   Taking minutes and editing working group documents often is performed
   by a specifically-designated participant or set of participants.  In
   this role, the Editor's job is to record WG decisions, rather than to
   perform basic specification.

5.3. WG Facilitator

   When meetings tend to become distracted or divisive, it often is
   helpful to assign the task of "process management" to one
   participant.  Their job is to oversee the nature, rather than the
   content, of participant interactions.  That is, they attend to the
   style of the discussion and to the schedule of the agenda, rather
   than making direct technical contributions themselves.

5.4. Design teams

   The majority of the detailed specification effort within a working
   group may be done by self-selecting sub-groups, called design teams,
   with the (implicit or explicit) approval of the working group.  The
   team may hold closed sessions for conducting portions of the
   specification effort. In some cases design teams are necessary to
   make forward progress when preparing a document.  All work conducted
   by a design team must be available for review by all working group
   participants and the design team must be responsive to the direction
   of the working group's consensus.

5.5. Area Consultant

   At the discretion of the AD, a Consultant may be assigned to a
   working group.  Consultants are senior participants in the IETF
   community.  They have technical background appropriate to the WG and
   experience in Internet architecture and IETF process.








Huizer & Crocker                                               [Page 19]

RFC 1603             IETF Working Group Guidelines            March 1994


5.6. Area Director

   Area Directors are responsible for ensuring that working groups in
   their area produce coherent, coordinated, architecturally consistent
   and timely output as a contribution to the overall results of the
   IETF. This very general description encompasses at the very least
   these detailed tasks related to working groups:

   Area planning

     The Area Director determines activities appropriate to the
     area.  This may include initiating working groups directly,
     rather than waiting for proposals from IETF participants.

   Coordination of WGs

     The Area Director coordinates the work done by the various
     WGs within (and sometimes even outside) the relevant area.

   IETF Meeting Schedule

     The Director tries to coordinate sessions in such a way that
     experts can attend the relevant sessions with a minimum of
     overlap and gaps between sessions. (See section on WG
     sessions for details.)

   Reporting

     The Area Director reports to the IETF on progress in the
     area.

   Reviewing

     The Area Director may appoint independent reviewers prior to
     document approval. The Area Director tracks the progress of
     documents from the area through the IESG review process, and
     report back on this to the WG Chair(s).

   Progress tracking

     The Area Director tracks and manages the progress of the
     various WGs with the aid of a regular status report on
     documents and milestones that is generated by the IESG
     Secretary. The Area Director forwards this report to the WG
     chairs.  This in turn helps the chairs to manage their WGs.






Huizer & Crocker                                               [Page 20]

RFC 1603             IETF Working Group Guidelines            March 1994


5.7. Area Directorate

   An area directorate consists of senior members of the technical
   community and are appointed by the Area Director who then tasks them
   with technical oversight and review of specific area activities.  An
   Area Director chairs the directorate.  At the request of the AD,
   directorate members conduct specification reviews and may be assigned
   as Area Consultants, to provide architectural assistance.

6.  WORKING GROUP DOCUMENTS

6.1. Session documents

   All relevant documents for a session (including the final agenda)
   should be published and available at least two weeks before a session
   starts.

   It is strongly suggested that the WG Chair make sure that an
   anonymous FTP directory be available for the upcoming session.  All
   relevant documents (including the final agenda and the minutes of the
   last session) should be placed in this directory.  This has the
   advantage that all participants can FTP all files in this directory
   and thus make sure they have all relevant documents. Also, it will be
   helpful to provide electronic mail-based retrieval for those
   documents.

6.2. IETF meeting document archive

   In preparing for an IETF meeting it is helpful to have ready access
   to all documents that are being reviewed. While documents usually are
   placed in the internet-drafts Internet Repository or in the
   respective working group archives or just published in some mail-
   lists, there are just too many things to browse or read through.
   Also, many documents are modified immediately before a meeting.

   The InterNIC Directory and Database Services provides a current-
   ietf-docs archive to enable people to get all documents that are
   relevant for the up-coming IETF meeting.  This document database will
   be removed two weeks after the IETF meeting.

   The completeness of this archive depends on the authors and working
   group chairs submitting the documents.  Each WG Chair is requested to
   submit the agenda to this archive.

   Structure of the archive:

   On ds.internic.net documents will be stored under the appropriate
   working group name under the appropriate area name in the directory:



Huizer & Crocker                                               [Page 21]

RFC 1603             IETF Working Group Guidelines            March 1994


          /pub/current-ietf-docs

   Each area will also have a directory called bof where a document to
   be discussed in a BOF meeting will be placed.  At the area level a
   directory called plenary will be created to hold documents or
   presentation material related to a plenary session.  Any filename
   conflicts will be resolved by the InterNIC's administrator and the
   submitter will be informed via electronic mail.  Example:

          /pub/current-ietf-docs/app/osids
          /pub/current-ietf-docs/int/sip

   Access via anonymous FTP:

   Anonymous FTP to ds.internic.net and change directory to

          /pub/current-ietf-docs/

   and browse and get the document of interest.

   Access via gopher:

   Connect to gopher.internic.net  and select the menu item:

          4.  InterNIC Directory and Database Services (AT&T)/

   and then the menu item:

          3.  Documents to be reviewed at the *** IETF

   One may use the public-access gopher client by:

          telnet gopher.internic.net

   Submission of documents via anonymous FTP:

   FTP to ds.internic.net and login as anonymous.  Change directory to:

          /incoming/current-ietf-docs

   Put the document using the following filename convention,

          <area>.<wgname>.<filename>
   e.g.:

          plenary.mondayVGs.ps
          app.osids.agenda
          app.osids.internic-talk-VGs.ps



Huizer & Crocker                                               [Page 22]

RFC 1603             IETF Working Group Guidelines            March 1994


   Note that the names of areas and working groups are their official
   short-form acronyms,

   Submission of documents via electronic mail:

   Send mail to

          [e-mail]

   with the following subject line:

          IETF - <area>.<wgname>.<filename>

   e.g.:

          IETF - app.osids.agenda

   NOTE:  Instead of sending a fresh copy of an already available
   document, you may ask the InterNIC's administrators to create a link
   to an existing internet-draft/RFC/ID

   NOTE:  If you do not remember your area or working group acronym get
   the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous
   FTP.

6.3. Internet-Drafts (I-D)

   The Internet-Drafts directory is provided to working groups as a
   resource for posting and disseminating early copies of working group
   documents. This repository is replicated at various locations around
   the Internet. It is encouraged that draft documents be posted as soon
   as they become reasonably stable.

   It is stressed here that Internet-Drafts are working documents and
   have no official standards status whatsoever. They may, eventually,
   turn into a standards-track document or they may sink from sight.
   Internet-Drafts are submitted to:

          [e-mail]

   The format of an Internet-Draft must be the same as for an RFC [2].
   Further, an I-D must contain:

   -    Beginning, standard, boilerplate text which is provided by
        the Secretariat;

   -    The I-D filename; and




Huizer & Crocker                                               [Page 23]

RFC 1603             IETF Working Group Guidelines            March 1994


   -    The expiration date for the I-D.

   Complete specification of requirements for an Internet-Draft are
   found in the file:

          1id-guidelines.txt

   in the internet-drafts directory at an Internet Repository site.

6.4. Request For Comments (RFC)