INTERNET-DRAFT D. Meyer
draft-meyer-wg-post-meeting-01.txt
Category Best Current Practice
Expires: July 2004 January 2004
IETF Session Minutes and Presentation Materials --
Post Meeting WG Chair Duties and Responsibilities
<draft-meyer-wg-post-meeting-01.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 (2004). All Rights Reserved.
D. Meyer [Page 1]
INTERNET-DRAFT Expires: July 2004 January 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: July 2004 January 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 . . . . . . . . . . . . . . . . . . . . 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: July 2004 January 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.
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: July 2004 January 2004
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: July 2004 January 2004
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] or
executable code such as Java [JAVA] MUST NOT be included in submitted
minutes.
D. Meyer Section 1.4. [Page 6]
INTERNET-DRAFT Expires: July 2004 January 2004
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: July 2004 January 2004
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: July 2004 January 2004
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.
Note: The materials must be in electronic form, but the form is pdf
(not amenable to editing, etc).
D. Meyer Section 2.3. [Page 9]
INTERNET-DRAFT Expires: July 2004 January 2004
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: July 2004 January 2004
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: July 2004 January 2004
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: July 2004 January 2004
8. References
8.1. Normative References
[JAVA] http://java.sun.com
[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: July 2004 January 2004
9. Author's Addresses
D. Meyer
Email: dmm@1-4-5.net
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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]