One document matched: draft-meyer-wg-post-meeting-03.txt
Differences from draft-meyer-wg-post-meeting-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:16:15 |