INTERNET-DRAFT D. Meyer draft-meyer-wg-post-meeting-03.txt Category Best Current Practice Expires: September 2004 March 2004 IETF Session Minutes and Presentation Materials -- Post Meeting WG Chair Duties and Responsibilities <draft-meyer-wg-post-meeting-03.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. This document is an individual submission. Comments are solicited and should be addressed to the author(s). Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. D. Meyer [Page 1]
INTERNET-DRAFT Expires: September 2004 March 2004 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: September 2004 March 2004 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 . . . . . . . . . . . . . . . . . . . . 6 1.3.2. Length of Submitted Minutes. . . . . . . . . . . . . . . 6 1.4. Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Submission Procedure and Deadlines. . . . . . . . . . . . . 8 1.6. Minutes Errata -- Correcting Mistakes . . . . . . . . . . . 8 2. Presentation Materials . . . . . . . . . . . . . . . . . . . . 9 2.1. Format: General Layout Guidelines . . . . . . . . . . . . . 9 2.2. Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Submission Procedure and Deadlines. . . . . . . . . . . . . 10 2.4. Presentation Errata -- Correcting Mistakes. . . . . . . . . 11 3. Recommendations. . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Audio-only recordings . . . . . . . . . . . . . . . . . . . 11 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References. . . . . . . . . . . . . . . . . . . 14 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 15 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 D. Meyer [Page 3]
INTERNET-DRAFT Expires: September 2004 March 2004 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. 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]. 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, D. Meyer Section 1.2. [Page 4]
INTERNET-DRAFT Expires: September 2004 March 2004 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. The guiding principle behind the minutes, then, is that they must convey to a non-attending reader enough information to review the meeting activity and understand the meeting outcome. In general, the minutes must be of sufficient detail and accuracy such that if an event cannot be understood to have happened from the minutes, then the event in question "did not happen" at the meeting. 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 D. Meyer Section 1.3. [Page 5]
INTERNET-DRAFT Expires: September 2004 March 2004 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 group/BOF sessions". The main body of the <Minutes> section must be a prose description of the issues discussed at the meeting and any apparent conclusions reached in the room. Other material may be included as supporting documentation from the meeting -- for example, transcript-style notes ("A said," then "B said," then "C said"), or a detailed list of changes to a document. These should be included as attachments to, and not replacements for, the <Minutes>. Finally, the minutes may include any other additional information that the working group chair deems appropriate as as appendices or attachments. 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 D. Meyer Section 1.4. [Page 6]
INTERNET-DRAFT Expires: September 2004 March 2004 ASCII form, and formatted either in either plain text format or in HTML. That is, non-ASCII binary formats such as JPEG [JPEG] or executable code such as Java [JAVA] must not be included in submitted minutes. D. Meyer Section 1.4. [Page 7]
INTERNET-DRAFT Expires: September 2004 March 2004 1.5. Submission Procedure and Deadlines There are at least three 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". o The IETF Secretariat "proceedings page" [PROCEEDINGS], which states that "The deadline for submission of minutes and presentation slides for inclusion in the IETF meeting proceedings is four weeks from the Friday of the meeting week." While RFC 2418 is silent on deadlines, and there is a discrepancy between the minutes page and the proceedings page. To resolve this ambiguity, the proceedings page takes precedent and the final form of meeting minutes must be submitted in ASCII form by the forth Friday following the meeting week. For example, in the case of the 59th IETF Meeting (March 01, 2004 - March 05, 2004), minutes are required to be received by the IETF Secretariat (minutes@ietf.org) by April 02, 2004 (i.e., the forth Friday following the meeting week). Finally, note that draft minutes must not be submitted to minutes@ietf.org, and only final versions of session minutes will be accepted. 1.6. Minutes Errata -- Correcting Mistakes Corrections to minutes will be accepted until the Friday six weeks from the Friday of the meeting week. Such corrections should be sent to minutes@ietf.org. In general, the rule can be stated as follows: The Working Group Chair can make changes to submitted minutes or presentation materials for six weeks from the Friday of meeting week; However, the chair must have submitted some form of the materials to the IETF Secretariat by the forth Friday following the meeting week. D. Meyer Section 1.6. [Page 8]
INTERNET-DRAFT Expires: September 2004 March 2004 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 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 ============================================= D. Meyer Section 2.2. [Page 9]
INTERNET-DRAFT Expires: September 2004 March 2004 * .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 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. Again, there is a discrepancy between the IETF secretariat "slides" page[SLIDES] and the proceedings page [PROCEEDINGS]. To resolve this ambiguity, the proceedings page takes precedent and the final form of meeting presentation set must be submitted in an approved form by the forth Friday following the meeting week. For example, in the case of the 59th IETF Meeting (March 01, 2004 - March 05, 2004), presentation materials are required to be received by the IETF Secretariat (proceedings@ietf.org) by April 02, 2004 (i.e., the forth 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. Note: The materials must be in electronic form, but the form is pdf (not amenable to editing, etc). D. Meyer Section 2.3. [Page 10]
INTERNET-DRAFT Expires: September 2004 March 2004 2.4. Presentation Errata -- Correcting Mistakes Corrections to minutes will be accepted until the Friday six weeks from the Friday of the meeting week. Such corrections should be sent to proceedings@ietf.org. In general, the rule can be stated as follows: The Working Group Chair can make changes to submitted minutes or presentation materials for six weeks from the Friday of meeting week; However, the chair must have submitted some form of the materials to the IETF Secretariat by the forth Friday following the meeting week. 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 accuracy and completeness of the IETF minutes mechanism is to have, in addition to the minutes described above, 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 D. Meyer Section 3.1. [Page 11]
INTERNET-DRAFT Expires: September 2004 March 2004 in place. However, it is only used for those sessions that are also have video recording. 4. Acknowledgments Leslie Daigle and Rebecca Bunch made several helpful and clarifying comments on earlier versions of this document. D. Meyer Section 4. [Page 12]
INTERNET-DRAFT Expires: September 2004 March 2004 5. Security Considerations This document specifies neither a protocol nor an operational practice, and as such, it creates no new security considerations. 6. IANA Considerations This document creates a no new requirements on IANA namespaces [RFC2434]. D. Meyer Section 6. [Page 13]
INTERNET-DRAFT Expires: September 2004 March 2004 7. References 7.1. Normative References [JAVA] http://java.sun.com [JPEG] http://www.jpeg.org [MGP] MagicPoint, http://www.mew.org/MagicPoint [PROCEEDINGS] http://www.ietf.org/instructions/proceedings.html [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 7.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 7.2. [Page 14]
INTERNET-DRAFT Expires: September 2004 March 2004 8. Author's Addresses D. Meyer Email: dmm@1-4-5.net 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. 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. 10. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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 might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information D. Meyer Section 10. [Page 15]
INTERNET-DRAFT Expires: September 2004 March 2004 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 11. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. D. Meyer Section 11. [Page 16]