idnits 2.17.1 draft-nir-non-wg-presentations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Experimental October 24, 2010 5 Expires: April 27, 2011 7 Giving Non-Working Group Presentations in IETF Meetings 8 draft-nir-non-wg-presentations-01 10 Abstract 12 This document proposes a new avenue for IETF meetings participants to 13 present ideas, results, or other information to the IETF community. 14 The proposal does not replace the work done in IETF working groups, 15 or the presentations given in area gatherings and the plenary 16 sessions. Instead, it allows a different track for delivering 17 information, gathering comments, and rallying support. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 27, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . . 4 55 2. The 'Berlin' Track . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Room Requirements . . . . . . . . . . . . . . . . . . . . . 5 58 3. Requirements for the Presentation . . . . . . . . . . . . . . . 5 59 4. Chaperone Requirements . . . . . . . . . . . . . . . . . . . . 6 60 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 62 7. Changes from Previous Versions . . . . . . . . . . . . . . . . 8 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 For the past few years, we have witnessed an unusual proliferation of 69 so called "bar BoFs". The traditional definition of a Bar BoF has 70 been an informal gathering of people interested in a particular 71 subject, discussing what, if anything, should be done in the IETF 72 about this subject. Typically these would occur spontaneously in 73 restaurants, social events, and as the name suggests - bars. These 74 new Bar BoFs are different. The are scheduled in advance, usually 75 with presentations, and they take place in the regular meeting venue 76 rooms, only at inconvenient times. They are listed, along with the 77 agenda in pages linked from the main meeting page on the IETF 78 website. 80 These bar BoFs have become the main avenue by which new work is 81 brought to the IETF. The IETF mailing list has seen some postings 82 claiming that this is because IETF newbies, who don't know the proper 83 processes schedule bar BoFs just because they don't know any better, 84 but even long-time IETFer Sam Hartman used such a bar BoF to bring 85 the federated authentication idea in IETF 77. For this reason, it is 86 now almost expected that area directors will attend. Also, because 87 of the use of the regular meeting rooms, these Bar BoFs tend to take 88 place over lunch or dinner time, some beginning as late as 10 PM. 89 This creates a lot of stress for potential attendees, and the 90 subjects suffer as well. 92 The current state of affairs has several drawbacks: 93 o It is often difficult, especially for those who are not IETF 94 regulars, to find these "birds of feather" among the 1200+ 95 participants in a particular meeting. 96 o Hundreds of drafts are published every day. It is often futile to 97 expect that even those who might be interested in the subject will 98 have read a draft on the subject, and be knowledgeable enough to 99 have a meaningful discussion on the topic without a prior 100 presentation. 101 o Presenting new topics over lunchtime or at 10 PM tends to cause 102 people to skip lunch, dinner, or sleep. It also means that 103 several people will skip the session, simply because they have 104 other plans, such as meetings, eating, or sleeping. This is 105 especially true for IESG members and working group chairs, who may 106 be an important part of the presentor's target audience. 107 o The lack of "the right people" at the meeting is particularly 108 problematic for IETF newbies, who need guidance as to where to 109 take their idea next. 111 This document suggests an alternative avenue for presenting new ideas 112 or gathered data. Such things can still be presented in working 113 groups or in gatherings. For this version of the docuemnt, this new 114 avenue will be called the 'Berlin' track, after a room in IETF78 that 115 seems to me to be about the right size. 117 1.1. Conventions Used in This Document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. The 'Berlin' Track 125 The new track will be held in one of the regular conference rooms. 126 Any meeting participant may give a 30 minute presentation on any 127 technical issue, and the precise requirements are specified in 128 Section 3. The requirements for the meeting room are specified in 129 Section 2.2. 131 2.1. Scheduling 133 Four weeks prior to the meeting, the secreteriat will publish the 134 schedule for the meeting, including rooms and times for the 'Berlin' 135 track. While a 'Berlin' track session is as long as a regular 136 session (for example, 2.5 hours), Each such session is divided into 137 30-minute slots. The secreteriat is encouraged to schedule these 138 sessions in the early days of an IETF meeting, such as Monday or 139 Tuesday, so that follow-up discussions can take place in the rest of 140 the week. 142 A separate schedule will be published for each of the 'Berlin'-track 143 sessions, consisting of 30-minute slots. Any participant can request 144 a slot, provided that he meets the criteria in Section 3. With the 145 approval of an AD, the participant may request two adjacent slots, if 146 his presentation requires a full hour. 148 For each of the 'Berlin'-track sessions, the General Area AD will 149 appoint a chaperone, who will perform a similar function as a WG 150 chair in a regular session. The chaperone will introduce the 151 presenters, make sure that presentations end on time, and advise the 152 presentors and the audience about IETF procedure. To be able to do 153 this, it is RECOMMENDED that the chaperone will be a current of 154 former WG chair or IESG member, who has sufficient experience with 155 the IETF to be able to advise the presentors about the appropriate 156 next steps. 158 Requests can be made as long as slots are available. Having reserved 159 a slot, the presentor still needs to comply with the requirements in 160 Section 3. If the chaperone feels that the requirements are not met, 161 she can remove the presentation from the schedule, freeing up the 162 slot. 164 2.2. Room Requirements 166 The Berlin track meetings may attract varying sizes of an audience. 167 Therefore, the room MUST be able to hold 50 people, and SHOULD be 168 able to hold 70. 170 Like all meeting rooms, there MUST be a projector, and the chaperone 171 should have a computer attached, to show presentations in PDF or PPT 172 formats. 174 3. Requirements for the Presentation 176 General Requirements. These requirements should serve as guidance to 177 the chaperones and ADs when they consider if a certain presentation 178 is appropriate: 179 o The presentations MUST be related to the issues the IETF works 180 with. "Why we all need to be driving hybrid cars" is not 181 appropriate, as is "Getting a universally-standard power-plug 182 shape, so that we don't have to carry stupid adapters to every 183 IETF meeting." 184 o Economics or social impacts or the Internet are appropriate 185 subjects, but social commentary and politics in general are not. 186 "Re-elect Obama in 2012 because he gets the Internet" has plenty 187 of venues to present, none of which is the IETF. 188 o Subjects need to have enough substance to warrant a half-hour time 189 slot and hopefully some follow-up discussion. For this reason, 190 adding yet another ciphersuite involving some government's 191 favorite algorithm to TLS is not appropriate. 192 o Subjects SHOULD NOT have a natural home in another working group. 193 A new TLS ciphersuite SHOULD be presented at the TLS working group 194 meeting, not at the Berlin track. If, however, the working group 195 chairs have passed on allowing this presentation, or if the 196 working group does not have a scheduled meeting in this IETF 197 gathering,then it is appropriate to present it at the Berlin 198 track. 200 Presentations are scheduled for 30 minutes. With a nod from an AD, 201 the presentations MAY be extended to 60 minutes. 203 A draft MUST exist for each presentation, providing further details 204 about the problem, the proposed solution, or the information conveyed 205 in the presentation. An AD can waive this requirement. It is also 206 RECOMMENDED that a mailing list be set up for the issue. 208 The presentor requesting a session MUST be attending the IETF 209 session, at least on a one-day pass. An AD may waive this 210 requirement, if they believe the presentation to be particularly 211 interesting to the IETF, but the requirement SHOULD NOT be waived for 212 presentations proposing work items or work groups. 214 The slides for the presentation MUST be sent to the chaperone, who 215 will upload them to the IETF website, similar to the slides for 216 working group presentations. 218 About half the time should be spent on presentation, with the 219 remainder left for questions and answers, and for finding a number of 220 people who would like to participate in a future working group. It 221 is up to the presentor to decide the proper mix, but the present-and- 222 run style is considered bad form in the IETF, which is founded on 223 open discussion. 225 It is highly recommended to use this presentation as an opportunity 226 to get a list of people who are interested in the subject and get 227 them to sign up for the mailing list. It is also RECOMMENDED to find 228 a small group of people, who may have good ideas on the subject, and 229 schedule a proper bar BoF or hallway meeting with them. They can 230 later be the beginning of a working group. 232 To summarize, this is an approximation of how a presentation should 233 go: 234 o Chaperone presents the subject (0.5 minutes) 235 o Presentation, including the problem and what can be done (15 236 minutes) 237 o Questions and Answers (10 minutes) 238 o Polling the room, how many are interested in this (1 minute) 239 o Show a slide with the mailing list address, and invite people to 240 sign up (0.5 minutes) 241 o Ask who would like to meet for a bar BoF (0.5 minutes, find 4-6 242 people) 243 o Find a good time for the bar BoF (2 minutes) 244 o With 1 minute to spare, the next presentor walks up to the front 245 of the room 247 4. Chaperone Requirements 249 The chaperone is appointed to one or more sessions, lasting between 1 250 hour and 2.5 hours, and including up to 5 presentations. The 251 chaperone's job is similar to the WG chair's job at a meeting, with 252 some changes. 254 As soon as registration for the time slots begins, the chaperone MUST 255 go over the proposed presentations, and remove those that are not 256 appropriate according to the guidelines set by this document or 257 subsequent updates and IESG policies. If a presentation seems 258 related to a particular working group, the chaperone should send 259 email to that working group's chairs, informing them of this 260 presentation. In any case, the chaperone has to decide what is or is 261 not acceptable, subject only to an appeal to the IESG. 263 5. Examples 265 This section is not meant to be normative. It holds listings for 266 some hypothetical presentations, with a short explanation about why 267 they are the way they are. 269 o Title: A multi-homed variant of FTP 270 o Time: Monday, 10:30 (30 minutes) 271 o Presentor: J. Doe 272 o Draft: http://www.ietf.org/id/draft-doe-ftp-mh-01.txt 273 o Slides: http://www.example.com/slides/mhftp.pdf 274 o Mailing List: http://www.example.com/ml/mhftp.html 275 o Abstract: Today many computers have multiple connections to the 276 Internet, such as wireless LAN and 3G. We leverage this to allow 277 multiple connections to be used simultaneously, so that file 278 trasfers get the cumulative bandwidth. 280 This is classic IETF presentation. It can probably be presented in a 281 few slides, it is technical in nature, and there are both a draft and 282 a mailing list. The presentor will undoubtedly be grilled during the 283 Q&A session, but might be able to find 4-5 people who will think this 284 is worthy enough to join him in the hotel lobby later to talk about 285 this. No AD involvement is required. 287 o Title: SNA Primer for TCP/IP Folks 288 o Time: Tuesday, 10:00 (60 minutes) 289 o Presentor: J. Smith 290 o Slides: http://www.example.com/slides/sna.pdf 291 o Abstract: SNA is a network architecture quite different from 292 TCP/IP. In this session we will learn the fundamentals of SNA, 293 and compare the two architectures. 295 SNA is a big subject. Without getting into the messy subject of 296 whether it is open or proprietary, the IETF is not the standards body 297 that deals with it. That is why some AD has waived the requirements 298 for draft and mailing list, and allowed the presentation to take a 299 full hour. 301 o Title: The Writing is on the Wall: World Peace through Facebook 302 Interaction 303 o Time: Canceled by chaperone 304 o Presentor: J. Jones 305 o Slides: http://www.example.com/slides/pax_facebook.pdf 306 o Abstract: Today, when everyone has a facebook profile, and can 307 'friend' anyone in the world, universal peace is finally at hand. 308 What diplomats in the United Nations have never been able to 309 achieve in closed session meetings, will very soon be done in a 310 bottom- up fasion. In this presentation, we will explain how. 312 Whatever the merits of this idea, it is not technical, and it is not 313 really about the Internet. While 'J. Jones' deserves a soap box just 314 as much as anybody else, an IETF meeting is not the right venue for 315 this. 317 o Title: Using the Camelia cipher in GDOI 318 o Time: Canceled by chaperone 319 o Presentor: J. Kwan 320 o Draft: http://www.ietf.org/id/draft-kwan-camelia-gdoi-00.txt 321 o Slides: http://www.example.com/slides/camelia-gdoi.png 322 o Abstract: This draft adds the camelia cipher as a possible 323 encryption algorithm for GDOI keys, both KEKs and TEKs. 325 This draft certainly has merit, but there are two reasons why it 326 should not be in the 'Berlin' track. First, it is very narrow in 327 scope - it's just like adding ciphersuites to TLS, and does not have 328 enough substance for a presentation, and even less for discussion. 329 In fact, it is very likely that the only reason for submitting this 330 draft, was to get an IANA number assignment when it's published. The 331 other reason that this is not appropriate, is that this subject has a 332 natural home in the MSEC working group. It can be a 5-minute 333 presentation there. Given all of this, it does not make sense to 334 waste a 30-minute slot of the 'Berlin' track on this presentation. 336 6. Security Considerations 338 There are no security considerations for this draft. 340 7. Changes from Previous Versions 342 Changes from version -00: 343 o Added chaperone considerations. 344 o Expanded the introduction. 346 8. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 Author's Address 353 Yoav Nir 354 Check Point Software Technologies Ltd. 355 5 Hasolelim st. 356 Tel Aviv 67897 357 Israel 359 Email: ynir@checkpoint.com