INTERNET-DRAFT                                      D. Meyer
draft-meyer-wg-post-meeting-00.txt
Category                               Best Current Practice
Expires: June 2004                             December 2003


           IETF Session Minutes and Presentation Materials --
           Post Meeting WG Chair Duties and Responsibilities
                  <draft-meyer-wg-post-meeting-00.txt>



Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].


   This document is an individual submission. Comments are solicited and
   should be addressed to the author(s).

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.







D. Meyer                                                        [Page 1]

INTERNET-DRAFT             Expires: June 2004              December 2003


                                Abstract


   RFC 2418 outlines the procedures for IETF Session operation. However,
   it contains little information about post-IETF meeting working group
   chair responsibilities. In particular, it gives little guidance with
   respect to either form or submission deadlines for the artifacts of
   the meeting, namely, session minutes and presentation materials. This
   document addresses those issues.










































D. Meyer                                                        [Page 2]

INTERNET-DRAFT             Expires: June 2004              December 2003


                           Table of Contents


   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
    1.1. Minutes . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    1.2. The Purpose of Session Minutes. . . . . . . . . . . . . . .   4
    1.3. Format. . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.1. <Minutes> Format . . . . . . . . . . . . . . . . . . . .   5
     1.3.2. Length of Submitted Minutes. . . . . . . . . . . . . . .   6
    1.4. Encoding. . . . . . . . . . . . . . . . . . . . . . . . . .   6
    1.5. Submission Procedure and Deadlines. . . . . . . . . . . . .   7
    1.6. Correcting Errata . . . . . . . . . . . . . . . . . . . . .   7
   2. Presentation Materials . . . . . . . . . . . . . . . . . . . .   7
    2.1. Format: General Layout Guidelines . . . . . . . . . . . . .   8
    2.2. Encoding. . . . . . . . . . . . . . . . . . . . . . . . . .   8
    2.3. Submission Procedure and Deadlines. . . . . . . . . . . . .   9
    2.4. Correcting Errata . . . . . . . . . . . . . . . . . . . . .  10
   3. Recommendations. . . . . . . . . . . . . . . . . . . . . . . .  10
    3.1. Audio-only recordings . . . . . . . . . . . . . . . . . . .  10
   4. Intellectual Property. . . . . . . . . . . . . . . . . . . . .  10
   5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  11
   6. Security Considerations. . . . . . . . . . . . . . . . . . . .  12
   7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  12
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  13
    8.1. Normative References. . . . . . . . . . . . . . . . . . . .  13
    8.2. Informative References. . . . . . . . . . . . . . . . . . .  13
   9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . .  14
   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  14























D. Meyer                                                        [Page 3]

INTERNET-DRAFT             Expires: June 2004              December 2003


1.  Introduction


   Section 3.1 of RFC 2418 [RFC2418] outlines the procedures for IETF
   Working Group operation. However, it contains little information
   about post-IETF meeting working group chair responsibilities. In
   particular, it gives little guidance with respect to either form or
   submission deadlines for the artifacts of the session, namely,
   working group minutes and presentation slides. The remainder of this
   document focus on the format, submission procedure, and deadlines for
   both session (e.g., Working Group) minutes and presentation
   materials.



1.1.  Minutes


   Section 3.1 of RFC 2418 mandates that "All working group sessions
   (including those held outside of the IETF meetings) shall be reported
   by making minutes available". And while there a brief discussion of
   the desired content (note that this is not required content),
   including the session agenda, an account of the discussion including
   any decisions made, and the list of attendees, it gives little other
   guidance. Further, while the IETF secretariat maintains
   "instructions" web pages [MINUTES], they provide only vague
   guidelines, and note that the format and content of the minutes is to
   be "is defined by the chair and minute-taker". As a result, IETF
   session minutes are of widely varying content and quality. In the
   following sections we outline a standard format for IETF session
   minutes, and a process for their submission.



1.2.  The Purpose of Session Minutes


   RFC 2418 states that "It is also good practice to note important
   decisions/consensus reached by email in the minutes of the next
   'live' session, and to summarize briefly the decision-making history
   in the final documents the WG produces."

   The suggestion here is that the purpose of the minutes is to
   summarize and document the history and activity (and in particular,
   any decision making activity) of the live meeting, both for those who
   could not attend, and for archival purposes.  Thus timely submission
   of minutes, along with standardized format and quality, are essential
   to the operation of the IETF process.



D. Meyer                                          Section 1.2.  [Page 4]

INTERNET-DRAFT             Expires: June 2004              December 2003


1.3.  Format


   Minutes SHOULD be submitted in the following format:

   <Working Group Name> (<gw abbreviation>) Minutes -- IETF<number>

   <Date>                <Time>
   =============================

   CHAIRS: <chair name> <chair email address>
           <co-chair1 name> <co-chair1 email address>
           ...

   Minutes recorded by <name> <email address>

   Agenda
   <agenda>

   Document Status
   <document status>
   #############################

   <Minutes>


   The following table expands on the above template:

    <Working Group Name>           Full working group name
    <gw abbreviation>              Working group abbreviation
    <number>                       Number of this IETF (e.g. 58)
    <Date>                         Date of the meeting, in MM DD, YYYY format
    <Time>                         Time of the meeting, in 24 hour time



1.3.1.  <Minutes> Format


   In general, session minutes serve two main functions. First, they
   provide a record of the issues discussed during the meeting, and
   those participating in the discussions for those who weren't in
   attendance. Second, they provide a record that can be used to review
   decisions that were made (such as those items on which the WG has
   reached consensus, etc). As such, standardized format, as well as
   quality and completeness, are essential to the operation of the IETF
   process. In particular, as noted in [MINUTES], "Minutes should
   provide a thorough summary of the issues discussed during the working



D. Meyer                                        Section 1.3.1.  [Page 5]

INTERNET-DRAFT             Expires: June 2004              December 2003


   group/BOF sessions".

   In addition, the general format of the <Minutes> section SHOULD NOT
   follow a "A said," then "B said," then "C said, format, as this
   format will likely of less interest to the general operation of the
   group. Finally, minutes SHOULD NOT contain a detailed list of changes
   to a document, as this is information is, in most cases, readily
   available elsewhere.



1.3.2.  Length of Submitted Minutes


   Minutes should provide a thorough summary of the issues discussed
   during the working group/BOF sessions, and SHOULD BE limited to a
   maximum of six pages of text.



1.4.  Encoding


   While [MINUTES] states that "Minutes for the IETF proceedings must be
   submitted in ASCII form", the trend is towards allowing HTML format
   minutes for those cases in which the working group chair wants to
   emphasize flow or other formatting. To that end, those working group
   chairs concerned about preserving the formatting of minutes MAY
   submit minutes in HTML format.

   In summary, the minutes for the IETF proceedings MUST be submitted in
   ASCII form, and formatted either in either plain text format or in
   HTML. That is, non-ASCII binary formats such as JPEG [JPEG] MUST NOT
   be included in submitted minutes.

















D. Meyer                                          Section 1.4.  [Page 6]

INTERNET-DRAFT             Expires: June 2004              December 2003


1.5.  Submission Procedure and Deadlines


   There are two places in IETF literature where the disposition of
   session minutes are discussed:

    o Section 3.1 of RFC 2418 states that "The minutes shall be
      submitted in printable ASCII text for publication in the
      IETF Proceedings, and for posting in the IETF Directories
      and are to be sent to: minutes@ietf.org".

    o The IETF Secretariat "minutes page" [MINUTES], which states
      that "Minutes for the IETF proceedings must be submitted in
      ASCII form by the end of two weeks following the meeting".

   RFC 2418 is, however, silent on deadlines, while the minutes page is
   ambiguous with respect to when the minutes must be received.  That
   is, "two weeks following the meeting" could mean 14 days from the
   Monday of meeting week, or 14 days from the Friday of the meeting
   week.

   To resolve this ambiguity, the final form of meeting minutes MUST BE
   submitted in ASCII form by the second Friday following the meeting
   week. For example, in the case of the 58th IETF Meeting (November
   9-14, 2003), the minutes would have to be received by the IETF
   Secretariat (minutes@ietf.org) by November 28, 2003 (the second
   Friday following the meeting week).

   Finally, draft minutes MUST NOT be submitted to minutes@ietf.org, and
   only final versions of session minutes SHALL be accepted.



1.6.  Correcting Errata


   deadline....format...minutes@ietf.org



2.  Presentation Materials


   IETF secretariat also maintains a "slides" web page[SLIDES] which
   outlines acceptable encodings (outlined below), and layout guidelines
   for session presentation materials. However, these guidelines are
   (possibly necessarily) vague, and provide no procedures for working
   group chairs to ensure consistent cross-working group presentation



D. Meyer                                            Section 2.  [Page 7]

INTERNET-DRAFT             Expires: June 2004              December 2003


   quality. As a result, IETF session presentation materials are of
   widely varying content and quality. In the following sections we
   outline a standard format for IETF session materials, and a process
   for their submission.

   In general, in order to have presentation materials included in the
   meeting proceedings, an on-line copy set of the slides in an approved
   format, MUST be submitted within two weeks following the meeting (see
   discussion of formats and deadlines below). Presentation slides
   covering information reported in the minutes need not be submitted.



2.1.  Format: General Layout Guidelines


   [SLIDES] outlines the general layout guidelines for presentation
   materials to be included in IETF proceedings. In particular:

    o Paper size: Letter (all other sizes will be modified to fit)
    o Avoid unnecessary detail in slides, they will be difficult to
      read in the reduced hardcopy version
    o Avoid using color schemes which wash out information when
      printed in black-and-white
    o Landscape layout will be printed 6 horizontal frames per page
      - use at least an 16-point font
    o Portrait layout will be printed 4 vertical frames per page -
      use at least an 14-point font



2.2.  Encoding


   [SLIDES] lays out the accepted presentation formats. In particular,
   the presentation materials MUST be provided one following encodings
   in order to be accepted for publication in the meeting proceedings:

      File Name                    Encoding
      =============================================
      * .txt       Plain Text (Win/*nix/Dos/Mac/Be)
      * .doc       Microsoft Word Document
      * .pdf       Adobe Portable Document Format
      * .ps        Adobe PostScript
      * .ppt       Microsoft PowerPoint
      * .html      HTML

   Many presenters are currently use MagicPoint [MGP] as a presentation



D. Meyer                                          Section 2.2.  [Page 8]

INTERNET-DRAFT             Expires: June 2004              December 2003


   tool, MagicPoint format documents MUST be converted to one of the
   above formats for submission to proceedings@ietf.org.



2.3.  Submission Procedure and Deadlines


   While submission of minutes is mandatory, submission of slides is
   optional. The IETF secretariat "slides" web page[SLIDES] contains an
   submission deadline ambiguity which is analogous to the minutes page,
   namely:

    To have your presentation included in the meeting proceedings,
    you are required to submit an on-line copy set of your slides
    within two weeks following the meeting.

   That is, "two weeks following the meeting" could mean 14 days from
   the Monday of meeting week, or 14 days from the Friday of the meeting
   week.

   To resolve this ambiguity, in order to have a presentation included
   in the meeting proceedings, an on-line copy set of the slides MUST BE
   submitted by the second Friday following the meeting week. For
   example, in the case of the 58th IETF Meeting (November 9-14, 2003),
   the slide sets would have to be received by the IETF Secretariat
   (proceedings@ietf.org) by November 28, 2003 (the second Friday
   following the meeting week).

   Presenters MUST provide presentation materials in one of the
   acceptable formats described above to the working group chair by the
   first Friday following the meeting. This gives the chair or chairs
   time to organize their submission to proceedings@ietf.org. If a
   presenter fails to to provide the working group chair with
   presentation materials in a timely fashion or in standard format, the
   materials MAY not appear in the meeting proceedings.

   Once the working group chair has received presentation materials, the
   chair MUST fill out the form on [PROCSUB], and submit it with the
   presentation materials. Hard copies MUST NOT be submitted, as they
   will not be used. Finally, slides SHOULD NOT be submitted for the
   proceedings if they contain information included in the minutes.









D. Meyer                                          Section 2.3.  [Page 9]

INTERNET-DRAFT             Expires: June 2004              December 2003


2.4.  Correcting Errata


   deadline...format...proceedings@ietf.org



3.  Recommendations


   As outlined in Section 1.1 above, minutes serve to "note important
   decisions/consensus reached by email in the minutes of the next
   'live' session, and to summarize briefly the decision-making history
   in the final documents the WG produces."  However, the highly
   variable format, quality and content of the minutes makes this goal
   difficult if not impossible to achieve.

   Since the  purpose of the minutes is to summarize and document the
   history and activity (and in particular, any decision making
   activity) of the live meeting, both for those who could not attend,
   and for archival purposes, they are of critical importance. One
   relatively straight forward way to address this problem is described
   in the next section.



3.1.  Audio-only recordings


   One relatively straight forward way to improve the veracity and
   accuracy of the IETF minutes mechanism is to have audio-only
   recordings of all sessions available. Such recordings would not only
   serve to improve the precision of them minutes (alleviating the
   "collective bad memory" problem), but the would also serve the
   documentary of meeting minutes.

   Finally, it is worth noting that the IETF already has this mechanism
   in place. However, it is only used for those sessions that are also
   have video recording.


4.  Intellectual Property


   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights



D. Meyer                                           Section 4.  [Page 10]

INTERNET-DRAFT             Expires: June 2004              December 2003


   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11 [RFC2028].
   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.



5.  Acknowledgments


   TBD





























D. Meyer                                           Section 5.  [Page 11]

INTERNET-DRAFT             Expires: June 2004              December 2003


6.  Security Considerations


   This document specifies neither a protocol nor an operational
   practice, and as such, it creates no new security considerations.



7.  IANA Considerations


   This document creates a no new requirements on IANA namespaces
   [RFC2434].






































D. Meyer                                           Section 7.  [Page 12]

INTERNET-DRAFT             Expires: June 2004              December 2003


8.  References

8.1.  Normative References


   [JPEG]          http://www.jpeg.org/

   [MGP]           MagicPoint, http://www.mew.org/MagicPoint

   [MINUTES]       IETF Secretariat, "Minutes for the IETF
                   Proceedings", http://www.ietf.org/instructions/minutes.html

   [PROCSUB]       "Proceedings Submission Form",
                   http://www.ietf.org/instructions/proxform.pdf

   [RFC2418]       Bradner, S., " IETF Working Group Guidelines and
                   Procedures", RFC 2418, September 1998

   [SLIDES]        IETF Secretariat, " Presentation Slides for the
                   IETF Proceedings", http://www.ietf.org/instructions/slides.html


8.2.  Informative References



   [RFC2119]       Bradner, S., "Key words for use in RFCs to
                   Indicate Requirement Levels", RFC 2119, March,
                   1997.

   [RFC2026]       Bradner, S., "The Internet Standards Process --
                   Revision 3", RFC 2026/BCP 9, October, 1996.

   [RFC2028]       Hovey, R. and S. Bradner, "The Organizations
                   Involved in the IETF Standards Process", RFC
                   2028/BCP 11, October, 1996.

   [RFC2434]       Narten, T., and H. Alvestrand, "Guidelines for
                   Writing an IANA Considerations Section in RFCs",
                   RFC 2434/BCP 26, October 1998.











D. Meyer                                         Section 8.2.  [Page 13]

INTERNET-DRAFT             Expires: June 2004              December 2003


9.  Author's Addresses


   D. Meyer
   Email: dmm@1-4-5.net


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















D. Meyer                                          Section 10.  [Page 14]