idnits 2.17.1 draft-meyer-agendas-and-minutes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '...red WG interactions, the Chair(s) MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 240 has weird spacing: '...slation chair...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2005) is 6701 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Meyer 2 Internet-Draft University of Oregon/Cisco Systems 3 Expires: June 23, 2006 O. Kolkman 4 NLnet Labs 5 December 20, 2005 7 On the Formatting and Content of IETF Working Group Agendas and Minutes 8 draft-meyer-agendas-and-minutes-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 23, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 RFC 2418 outlines the procedures for IETF Session operation. 42 However, it contains little information about post-IETF meeting 43 working group chair responsibilities. In particular, it provides 44 little guidance with respect to either form or submission deadlines 45 for the artifacts of the meeting, namely, session minutes and 46 presentation materials. This document addresses the form and content 47 of Working Group agendas and minutes. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Agendas . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Agenda Content and Formatting Considerations . . . . . . . 3 54 2.1.1. The Header . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1.2. The Body . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. The Purpose of Session Minutes . . . . . . . . . . . . . . 7 58 3.2. Minutes Content Considerations . . . . . . . . . . . . . . 8 59 3.3. Minutes Formatting Considerations . . . . . . . . . . . . 8 60 3.3.1. The Header . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3.2. The Body . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3.3. Length of Submitted Minutes . . . . . . . . . . . . . 9 63 3.4. The Body . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. Length of Submitted Minutes . . . . . . . . . . . . . . . 10 65 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5. Submission Procedure and Deadlines . . . . . . . . . . . . . . 12 67 6. Minutes Errata -- Correcting Mistakes . . . . . . . . . . . . 13 68 7. Format: General Layout Guidelines . . . . . . . . . . . . . . 14 69 8. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. Submission Procedure and Deadlines . . . . . . . . . . . . . . 15 71 10. Presentation Errata -- Correcting Mistakes . . . . . . . . . . 15 72 11. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 73 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 78 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Appendix A. Templates . . . . . . . . . . . . . . . . . . . . . . 17 80 A.1. Agenda Template . . . . . . . . . . . . . . . . . . . . . 17 81 A.2. Minutes Template . . . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 83 Intellectual Property and Copyright Statements . . . . . . . . . . 22 85 1. Introduction 87 Section 3.1 of RFC 2418 [RFC2418] outlines the procedures for IETF 88 Working Group operation. However, it contains little information 89 about post-IETF meeting working group chair responsibilities. In 90 particular, it gives little guidance with respect to either form or 91 submission deadlines for the artifacts of the session, namely, 92 working group minutes and presentation slides. The remainder of this 93 document focus on the format, submission procedure, and deadlines for 94 both session (e.g., Working Group) minutes and presentation 95 materials. 97 2. Agendas 99 RFC 2418 section 3.1 defines a clear role for the agenda as part of 100 the session planning. It states: 102 For coordinated, structured WG interactions, the Chair(s) MUST 103 publish a draft agenda well in advance of the actual session. The 104 agenda should contain at least: 106 - The items for discussion; 107 - The estimated time necessary per item; and 108 - A clear indication of what documents the participants will need 109 to read before the session in order to be well prepared. 111 This mandate serves a number of needs. It allows working group 112 chairs to carefully optimize the meeting time. Presenters know well 113 in advance how to tailor their presentations to the allocated time 114 and participants know what material to read in order to come 115 prepared. In addition, a good agenda can act as a checklist for the 116 for the chairs during the meeting. 118 2.1. Agenda Content and Formatting Considerations 120 There are a couple of considerations that can help one to produce an 121 agenda that serves everybody's needs. One will always have to try to 122 make trade-offs between the size of the formatted document and the 123 amount of detail to add. This document suggests some content and 124 some hints to present this content in a uniform way. 126 According to [MEETINGTOOL], agendas can be submitted in HTML and TXT 127 encoding. Since a clearly formatted agenda can be used as a template 128 for the construction of the minutes one should clearly structure the 129 source text. 131 2.1.1. The Header 133 To unambiguously identify the agenda the header should at least 134 contain the name of the working group and its acronym and the IETF 135 meeting to which this meeting relates. 137 By adding some standard information to your header the agenda can be 138 used as a 'one-stop-shop' for all information regarding the meeting. 139 Consider adding the location and time of the meeting, pointers to the 140 jabber room, pointers to audio- or web-cast and a pointer to the 141 working groups web pages. Versioning the agenda is also a 142 recommended practice. Finally, don't forget to add the contact 143 information of the chairs. 145 Try to separate the header from the rest of the agenda with a 146 "graphical" element such as a line of "="-signs when the agenda is 147 encoded in TXT or the when the agenda is encoded in HTML. 149 Figure 1 provides an example Agenda Section Header. 151 Formatting of IETF Workflow Documents Group (FIWD) AGENDA 153 Meeting : IETF202, Monday 34 November 2032. 154 Location: Fargo Hilton, Coens room, 12:30-14:00. 155 Chairs : Brian De Palma , 156 Fernando Meirell 157 Jabber : FIWD@jabber.ietf.org 158 URL : http://tools.ietf.org/wg/FIWD/ 159 Agenda : version 1.4 (draft) 160 ============================================================== 162 Figure 1: Agenda Section Header 164 2.1.2. The Body 166 The body of the agenda presents the structure of the meeting. In our 167 experience the meeting can usually be split in 'topics'. The 168 meeting-administrivia is one 'topic', the administrivia concerning 169 the working group documents is another 'topic'. By trying to 170 structure the agenda by 'topic' a chair brings structure to the 171 meeting. Stated from a meeting-centric point of view: The structure 172 of a meeting should be represented in the agenda. 174 For each topic there will be a number of sub-topics. All subtopics 175 have a title, and in the most common case, somebody to speak for 176 them. If there is reading material such as an internet-draft a 177 reference should be supplied. For each subtopic you should indicate 178 how much time is allocated. 180 Note that it often happens that people want to be in the room for a 181 particular topic. By also indicating the total time allocated to a 182 topic one can allow participants to selectively join rooms. 184 Try to format topics and subtopics so that they can be clearly 185 distinguished. Indentation and or 'section numbers' are handy 186 formatting tools. Introducing a topic with one or two lines may help 187 to identify what the intended goal of the discussion is. 189 We suggest that you always include "Meeting Administrivia" as a 190 topic. By explicitly sub-topics like "Previous Minutes", "Scribe" 191 and "Blue Sheets" a chair can be sure those topics are addressed. 193 When using HTML to encode the agenda we suggest you put in links to 194 the document and use a short notation. When using text, consider 195 that you have to trade off writing out complete URLs (in order to 196 facilitate cutting and pasting) versus the conciseness of using only 197 draft names. Figure 2 provides an example Agenda Body. 199 -------------------- Example Agenda Body -------------------- 200 A. Meeting Administrivia chairs (total: 5 min) 201 - Mailing list and URL 202 - Minutes Scribe 203 - Jabber Scribe 204 - Blue Sheets 205 - Agenda Bashing 206 - Previous Minutes 207 - Action Items 209 B. Stalled Work chairs (total:10 min) 210 Documents that have not seen anything happen. Status update 211 and proposed way forward. 212 - draft-ietf-fiwd-handwritten-minutes-12.txt 213 - draft-ietf-fiwd-agenda-over-sms-02.txt 214 - discussion 216 C. Page Numbers (total: 30 min) 217 Several proposals on page numbering have been put forward. 218 We will have to make a choice based on requirements. 219 (draft-ietf-fiwd-pnum-requirements-5.txt) 221 - Page numbers at the center Gilliam (10 min) 222 draft-ietf-fiwd-pnum-centr-02.txt 223 - Page numbers at the right Coppola (10 min) 224 draft-ietf-fiwd-pnum-right-06.txt 225 - Page number strawman and chairs (10 min) 226 discussion 228 D. Possible Work Items (total: 15 min) 230 D.1 XML based agendas and minutes. Coens (10 min) 231 Work on development of a DTD for minutes 232 and agendas. 234 - draft-coens-fiwd-pnum-xml-workflow-docs-02.txt 235 - Discussion (5 min) 237 D.2 (...) 239 G. Working Group Administrivia (total: 10 min) 240 G.1 Conclusion WGLC minutes translation chairs (3 min) 241 - draft-ietf-fiwd-translation-05.txt 242 Chair summarizes WGLC. 244 --------------------------------------------------------------------- 246 Figure 2: Example Agenda Body 248 3. Minutes 250 Section 3.1 of RFC 2418 mandates that "All working group sessions 251 (including those held outside of the IETF meetings) shall be reported 252 by making minutes available". And while there a brief discussion of 253 the desired content (note that this is not required content), 254 including the session agenda, an account of the discussion including 255 any decisions made, and the list of attendees, it gives little other 256 guidance. Further, while the IETF secretariat maintains 257 "instructions" web pages [MINUTES], they provide only vague 258 guidelines, and note that the format and content of the minutes is to 259 be "is defined by the chair and minute-taker". As a result, IETF 260 session minutes are of widely varying content and quality. In the 261 following sections we outline a standard format for IETF session 262 minutes, and a process for their submission. 264 3.1. The Purpose of Session Minutes 266 RFC 2418 states that "It is also good practice to note important 267 decisions/consensus reached by email in the minutes of the next 268 'live' session, and to summarize briefly the decision-making history 269 in the final documents the WG produces." Note that decisions reached 270 during a face-to-face meeting about topics or issues which have not 271 been discussed on the mailing list, or are significantly different 272 from previously arrived mailing list consensus must be reviewed on 273 the mailing list. This suggests the importance of the working 274 group's minutes: while the working group minutes just reporting and 275 critical record-keeping, there are times when a working group's 276 minutes play an important role in signaling the subsequent 277 confirmation process (post working group meeting) on the mailing 278 list. 280 The suggestion here is that the purpose of the minutes is to 281 summarize and document the history and activity (and in particular, 282 any decision making activity) of the live meeting, both for those who 283 could not attend, and for archival purposes. Thus timely submission 284 of minutes, along with standardized format and quality, are essential 285 to the operation of the IETF process. 287 The guiding principle behind the minutes, then, is that they must 288 convey enough information to a non-attending reader to be able to 289 review the meeting activity and understand the meeting outcome. In 290 general, the minutes must be of sufficient detail and accuracy such 291 that if an event cannot be understood to have happened from the 292 minutes, then the event in question "did not happen" at the meeting. 294 3.2. Minutes Content Considerations 296 In general, session minutes serve two main functions. First, they 297 provide a record of the issues discussed during the meeting, and 298 those participating in the discussions for those who weren't in 299 attendance. Second, they provide a record that can be used to review 300 decisions that were made (such as those items on which the WG has 301 reached consensus, etc). As such, standardized format, as well as 302 quality and completeness, are essential to the operation of the IETF 303 process. In particular, as noted in [MINUTES], "Minutes should 304 provide a thorough summary of the issues discussed during the working 305 group/BOF sessions". 307 Note that it is important to record each draft which is discussed at 308 the meeting, including its revision number, since the discussion 309 needs to be placed in context. This includes drafts that have not 310 yet been accepted as working group documents, and late revisions of 311 working group documents. This is important as working group minutes 312 are frequently used as a resource answering questions relating to 313 prior art, as well questions about the state of the technical 314 development of a protocol. We recommend that a list of all drafts 315 mentioned during the discussion is added just before each topic is 316 summarized 318 The main body of the Minutes section must be a prose description of 319 the issues discussed at the meeting and any apparent conclusions 320 reached in the room. Other material may be included as supporting 321 documentation from the meeting -- for example, transcript-style notes 322 ("A said," then "B said," then "C said"), or a detailed list of 323 changes to a document. These should be included as attachments to, 324 and not replacements for, the Minutes. 326 Action items are a good way to document commitments of participants. 327 We recommend action items to be explicitly mentioned at the end of 328 each topic or at the end of the minutes. 330 Finally, the minutes may include any other additional information 331 that the working group chair deems appropriate as as appendices or 332 attachments. 334 3.3. Minutes Formatting Considerations 336 3.3.1. The Header 338 In order to unambiguously identify the minutes they should, just like 339 agendas, have a clear and unambiguous header. The content should at 340 least contain the name of the working group, the IETF number, the 341 date and time of the meeting and the name of the scribes. A version 342 number is recommended. Figure 3 provides an example Agenda Header. 344 Formatting of IETF Workflow Documents Group (FIWD) Minutes 346 Meeting : IETF202, Monday 34 Noctember 2032. 347 Location: Fargo Hilton, Coens room, 12:30-14:00. 348 Chairs : Brian De Palma , 349 Fernando Meirell 350 Minutes : Martin Scorsese 351 Version 2 352 ============================================================== 354 Figure 3: Example Minutes Header 356 3.3.2. The Body 358 The Agenda Body should occur just below the agenda header. To 359 improve readability, we suggest that details are skipped and only the 360 main topics are listed. We suggest that the sub-topic structure is 361 maintained in the minutes. 363 Try to format the text in such a way that topics and subtopics are 364 clearly grouped. Start each (sub)topic with adding the names of 365 document that have been discussed. A properly formatted agenda can 366 easily be used as a template. Working group chairs could suggest 367 minute takers to construct such a template from the agenda before the 368 meeting. 370 Enumeration room consensus or actions for each topic is helpful. 372 Figure 4 contains an example of the formatting of a the body of a set 373 of minutes for our imaginary working group. We try to present an 374 example for a style that captures the gist of the meeting and a 375 formatting that represents the structure of the meeting. 377 3.3.3. Length of Submitted Minutes 379 Minutes should provide a thorough summary of the issues discussed 380 during the working group/BOF sessions, and should BE limited to a 381 maximum of six pages of text. 383 3.4. The Body 385 The Agenda Body should occur just below the agenda header. To 386 improve readability, we suggest that details are skipped and only the 387 main topics are listed. We suggest that the sub-topic structure is 388 maintained in the minutes. 390 Try to format the text in such a way that topics and subtopics are 391 clearly grouped. Start each (sub)topic with adding the names of 392 document that have been discussed. A properly formatted agenda can 393 easily be used as a template. Working group chairs could suggest 394 minute takers to construct such a template from the agenda before the 395 meeting. 397 Enumeration room consensus or actions for each topic is helpful. 399 Figure 4 contains an example of the formatting of a the body of a set 400 of minutes for our imaginary working group. We try to present an 401 example for a style that captures the gist of the meeting and a 402 formatting that represents the structure of the meeting. 404 3.5. Length of Submitted Minutes 406 Minutes should provide a thorough summary of the issues discussed 407 during the working group/BOF sessions, and should BE limited to a 408 maximum of six pages of text. 410 -------------------- Example Minutes Body ------------------- 412 ======================================================= 413 AGENDA 414 A. Meeting Administrivia 415 B. Stalled Work 416 C. Page Numbers 417 D. Possible Work Items 418 D.1 XML based agendas and minutes. 419 D.2 (...) 420 G. Working Group Administrivia 421 G.1 Conclusion WGLC minute translation 423 ======================================================= 425 MEETING Report 426 A. Meeting Administrivia 428 Martin Scorsese volunteered as scribe. 429 Luc Besson volunteered as jabber scribe. 431 Minutes of the IETF201 where posted and finalized within 2 432 weeks after IETF201. The minute takes is acknowledged. The 433 room unanimously approved the minutes. 435 There was one action item from IETF201, this is dealt with in 436 item B of this meeting. 438 B. Stalled Work 439 Documents that have not seen anything happen. Status update 440 and proposed way forward. 441 - draft-ietf-fiwd-handwritten-minutes-12.txt 442 - draft-ietf-fiwd-agenda-over-sms-02.txt 444 The chairs explained that the document editors for these 445 draft have changed their jobs and have requested to be 446 resigned as editors. Volunteers have been called for on the 447 list but nobody stepped forward. The chairs suggest that this 448 work is dropped from the charter. 450 Quint Tarantino notes that this work has seen little activity 451 except from the editors he wonders how this work ever made it 452 on the charter. The discussion drifted into how handwriting 453 can effectively be scanned. It was concluded by requesting 454 the chairs to remove this work from the charter. 456 Action on chairs: Have these drafts removed from the charter. 458 C. Page Numbers 460 * draft-ietf-fiwd-pnum-requirements-5.txt) 461 * draft-ietf-fiwd-pnum-centr-02.txt 462 * draft-ietf-fiwd-pnum-right-06.txt 463 * draft-verhoeven-two-pnums-per-page-02.txt 465 Several proposals on page numbering have been put forward. 466 We will have to make a choice based on requirements. 467 (draft-ietf-fiwd-pnum-requirements-5.txt) 469 - Page numbers at the center 470 draft-ietf-fiwd-pnum-centr-02.txt 472 Gilliam presented his slides (see proceedings). 474 During his presentation he stressed that that printing page 475 numbers in the center of the page eases double sided 476 printing. 478 - Page numbers at the right 479 draft-ietf-fiwd-pnum-right-06.txt 481 Coppola explained that during Gilliam presentation that 482 there are economic and environmental considerations in 483 addition to the aesthetic principles on which the 484 'pnum-right' draft is based. The room hummed in consensus 485 when the chairs suggested to document the economical issues 486 in the 'pnum-centr' draft and the original requirements 487 draft and then move to last call. 489 - Page number strawman and discussion 491 The strawman was not discussed. See above. 493 During the meeting Steve Spielberg noted that his company had 494 IPR on printing page numbers on both the left and the right 495 hand side of the paper in order to ease double sided 496 printing. This bears relevance to a personal submission to 497 this group; draft-verhoeven-two-pnums-per-page-02.txt The 498 chair asked him to file the IPR claim via the IPR pages on 499 the IETF website. 501 Action on Gilliam: update pnum-centr to document the 502 economical and environmental considerations 503 of two-side printing 505 D. Possible Work Items 506 (...) 507 -------------------------------------------------------------------- 509 Figure 4: Example Minutes Body 511 4. Encoding 513 [MEETINGTOOL] allows HTML encoded minutes. We suggest that txt 514 encoding is used except for those cases in which the working group 515 chair wants to emphasize flow or other formatting. 517 In summary, the minutes for the IETF proceedings must be submitted in 518 ASCII form, and formatted either in either plain text format or in 519 HTML. That is, non-ASCII binary formats such as JPEG [JPEG] or 520 executable code such as Java [JAVA] must not be included in submitted 521 minutes. 523 5. Submission Procedure and Deadlines 525 There are at least three places in IETF literature where the 526 disposition of session minutes are discussed: 528 Section 3.1 of RFC 2418 states that "The minutes shall be 529 submitted in printable ASCII text for publication in the IETF 530 Proceedings, and for posting in the IETF Directories and are to be 531 sent to: minutes@ietf.org". 533 The IETF Secretariat "minutes page" [MINUTES], which states that 534 "Minutes for the IETF proceedings must be submitted in ASCII form 535 by the end of two weeks following the meeting". 537 The IETF Secretariat "proceedings page" [PROCEEDINGS], which 538 states that "The deadline for submission of minutes and 539 presentation slides for inclusion in the IETF meeting proceedings 540 is four weeks from the Friday of the meeting week." 542 While RFC 2418 is silent on deadlines, and there is a discrepancy 543 between the minutes page and the proceedings page. To resolve this 544 ambiguity, the proceedings page takes precedent and the final form of 545 meeting minutes must be submitted in ASCII form by the forth Friday 546 following the meeting week. For example, in the case of the 59th 547 IETF Meeting (March 01, 2004 - March 05, 2004), minutes are required 548 to be received by the IETF Secretariat (minutes@ietf.org) by April 549 02, 2004 (i.e., the forth Friday following the meeting week). 551 Finally, note that draft minutes must not be submitted to 552 minutes@ietf.org, and only final versions of session minutes will be 553 accepted. 555 6. Minutes Errata -- Correcting Mistakes 557 Corrections to minutes will be accepted until the Friday six weeks 558 from the Friday of the meeting week. Such corrections should be sent 559 to minutes@ietf.org. In general, the rule can be stated as follows: 561 The Working Group Chair can make changes to submitted minutes 562 or presentation materials for six weeks from the Friday of 563 meeting week; However, the chair must have submitted some form 564 of the materials to the IETF Secretariat by the forth Friday 565 following the meeting week. 567 IETF secretariat also maintains a "slides" web page [SLIDES] which 568 outlines acceptable encodings (outlined below), and layout guidelines 569 for session presentation materials. However, these guidelines are 570 (possibly necessarily) vague, and provide no procedures for working 571 group chairs to ensure consistent cross-working group presentation 572 quality. As a result, IETF session presentation materials are of 573 widely varying content and quality. In the following sections we 574 outline a standard format for IETF session materials, and a process 575 for their submission. 577 In general, in order to have presentation materials included in the 578 meeting proceedings, an on-line copy set of the slides in an approved 579 format, must be submitted within two weeks following the meeting (see 580 discussion of formats and deadlines below). Presentation slides 581 covering information reported in the minutes need not be submitted. 583 7. Format: General Layout Guidelines 585 [SLIDES] outlines the general layout guidelines for presentation 586 materials to be included in IETF proceedings. In particular: 588 Paper size: 215.9x279.4mm (Letter), all other sizes will be 589 modified to fit. 591 Avoid unnecessary detail in slides, they will be difficult to read 592 in the reduced hard copy version 594 Avoid using color schemes which wash out information when printed 595 in black-and-white 597 Landscape layout will be printed 6 horizontal frames per page - 598 use at least an 16-point font 600 Portrait layout will be printed 4 vertical frames per page - use 601 at least an 14-point font 603 8. Encoding 605 [SLIDES] lays out the accepted presentation formats. In particular, 606 the presentation materials must be provided one following encodings 607 in order to be accepted for publication in the meeting proceedings: 609 File Name Encoding 610 ============================================= 611 * .txt Plain Text (Win/*nix/Dos/Mac/Be) 612 * .doc Microsoft Word Document 613 * .pdf Adobe Portable Document Format 614 * .ps Adobe PostScript 615 * .ppt Microsoft PowerPoint 616 * .html HTML 618 Many presenters are currently use MagicPoint [MGP] as a presentation 619 tool, MagicPoint format documents must be converted to one of the 620 above formats for submission to proceedings@ietf.org. 622 9. Submission Procedure and Deadlines 624 While submission of minutes is mandatory, submission of slides is 625 optional. Again, there is a discrepancy between the IETF secretariat 626 "slides" page [SLIDES] and the proceedings page [PROCEEDINGS]. To 627 resolve this ambiguity, the proceedings page takes precedent and the 628 final form of meeting presentation set must be submitted in an 629 approved form by the forth Friday following the meeting week. For 630 example, in the case of the 59th IETF Meeting (March 01, 2004 - March 631 05, 2004), presentation materials are required to be received by the 632 IETF Secretariat (proceedings@ietf.org) by April 02, 2004 (i.e., the 633 forth Friday following the meeting week). 635 Presenters must provide presentation materials in one of the 636 acceptable formats described above to the working group chair by the 637 first Friday following the meeting. This gives the chair or chairs 638 time to organize their submission to proceedings@ietf.org. If a 639 presenter fails to to provide the working group chair with 640 presentation materials in a timely fashion or in standard format, the 641 materials may not appear in the meeting proceedings. 643 Once the working group chair has received presentation materials, the 644 chair must fill out the form on [PROCSUB], and submit it with the 645 presentation materials. Hard copies must not be submitted, as they 646 will not be used. Finally, slides should not be submitted for the 647 proceedings if they contain information included in the minutes. 649 Note: The materials must be in electronic form, but the form is pdf 650 (not amenable to editing, etc). 652 10. Presentation Errata -- Correcting Mistakes 654 Corrections to minutes will be accepted until the Friday six weeks 655 from the Friday of the meeting week. Such corrections should be sent 656 to proceedings@ietf.org. In general, the rule can be stated as 657 follows: 659 The Working Group Chair can make changes to submitted minutes 660 or presentation materials for six weeks from the Friday of 661 meeting week; However, the chair must have submitted some form 662 of the materials to the IETF Secretariat by the forth Friday 663 following the meeting week. 665 11. Recommendations 667 As outlined in Section 1.1 above, minutes serve to "note important 668 decisions/consensus reached by email in the minutes of the next 669 \'live\' session, and to summarize briefly the decision-making 670 history in the final documents the WG produces." However, the highly 671 variable format, quality and content of the minutes makes this goal 672 difficult if not impossible to achieve. 674 Since the purpose of the minutes is to summarize and document the 675 history and activity (and in particular, any decision making 676 activity) of the live meeting, both for those who could not attend, 677 and for archival purposes, they are of critical importance. One 678 relatively straight forward way to address this problem is described 679 in the next section. 681 Finally, it is worth noting that the IETF already has this mechanism 682 in place. However, it is only used for those sessions that are also 683 have video recording. 685 12. Acknowledgments 687 Rebecca Bunch, Leslie Daigle and Allison Mankin made several helpful 688 and clarifying comments on earlier versions of this document. [IMDB] 689 is acknowledged for the inspiring pool of names in the examples. 691 13. Security Considerations 693 This document specifies neither a protocol nor an operational 694 practice, and as such, it creates no new security considerations. 696 14. IANA Considerations 698 This document creates a no new requirements on IANA namespaces 699 [RFC2434]. 701 15. References 703 15.1. Normative References 705 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 706 Procedures", BCP 25, RFC 2418, September 1998. 708 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 709 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 710 October 1998. 712 15.2. Informative References 714 [MEETINGTOOL] 715 "The IETF Meeting Materials Management Tool", Web Page: 716 http://www.ietf.org/instructions/ 717 meeting_materials_tool.html, 2005. 719 [MINUTES] "Minutes for the IETF Proceedings", Web 720 Page: http://www.ietf.org/instructions/minutes.html, 2005. 722 [PROCEEDINGS] 723 "Submitting Input to IETF Meeting Proceedings", Web 724 Page: http://www.ietf.org/instructions/proceedings.html, 725 2005. 727 [PROCSUB] "Proceedings Submission Form", Web 728 Page: http://www.ietf.org/instructions/proxform.pdf, 2005. 730 [SLIDES] "Presentation Slides for the IETF Proceedings", Web 731 Page: http://www.ietf.org/instructions/slides.html, 2005. 733 [JAVA] "The JAVA Programming Language", Web 734 Page: http://java.sun.com, 2005. 736 [JPEG] "The JPEG Image Format", Web Page: http://www.jpeg.org, 737 2005. 739 [MGP] "MagicPoint", Web Page: http://member.wide.ad.jp/wg/mgp, 740 2005. 742 [IMDB] "The Internet Movie Database", Web 743 Page: http://www.imdb.com/, 1990-2005. 745 Appendix A. Templates 747 A.1. Agenda Template 749 [ED note: In the final document we would want to have this on a 750 separate page] 752 () AGENDA 754 Meeting : IETF 755 Location: , 756 Chairs : 757 758 Jabber : 759 URL : 760 Agenda : version: 761 ========================================================= 763 AGENDA 765 o Meeting Administriva 767 - Mailing list: 768 - Scribe(s) 769 - Blue Sheets 770 - Agenda Bashing 771 - Previous minutes 772 - Action Items 774 o Review and status of work items 776 Active Drafts 777 ------------- 778 779 780 781 ... 782 784 Potential New Work 785 ------------------ 786 + Work Item1 787 788 789 790 792 + Work Item2 793 794 795 796 798 Other 799 ----- 800 802 A.2. Minutes Template 804 [ED note: In the final document we would want to have this on a 805 separate page] It is probably easiest to use the published agenda to 806 derive the actual minutes template 808 () MINUTES 810 Meeting : IETF 811 Location: , 812 Chairs : 813 814 Minutes : 815 version: 816 ========================================================= 817 AGENDA 818 A. Meeting Administrivia 819 B. 820 C. 821 D. 822 D.1 823 D.2 824 ========================================================== 826 Meeting Report 827 A. Meeting Administrivia 829 volunteered as minutes scribe. 830 volunteered as jabber scribe. 832 < status previous minutes > 834 B. < topic title > 835 * < draft-foo-discussed-draft-1 > 836 * < draft-foo-discussed-draft-2 > 837 * < draft-foo-discussed-draft-3 > 839 < Meeting prose > 841 < Action Items > 843 C. < topic title > 844 * < draft-foo-discussed-draft-1 > 845 * < draft-foo-discussed-draft-2 > 846 * < draft-foo-discussed-draft-3 > 848 < Meeting prose > 849 < Action Items > 851 Authors' Addresses 853 David Meyer 854 University of Oregon/Cisco Systems 855 1225 Kincaid St. 856 Eugene OR 97403 857 USA 859 Email: dmm@1-4-5.net 860 URI: http://www.1-4-5.net/~dmm 862 Olaf M. Kolkman 863 NLnet Labs 864 Kruislaan 419 865 Amsterdam 1098 VA 866 The Netherlands 868 Email: olaf@nlnetlabs.nl 869 URI: http://www.nlnetlabs.nl 871 Intellectual Property Statement 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Disclaimer of Validity 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 900 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 901 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 902 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Copyright Statement 907 Copyright (C) The Internet Society (2005). This document is subject 908 to the rights, licenses and restrictions contained in BCP 78, and 909 except as set forth therein, the authors retain all their rights. 911 Acknowledgment 913 Funding for the RFC Editor function is currently provided by the 914 Internet Society.