| TOC |
|
This document proposes a new avenue for IETF meetings participants to present ideas, results, or other information to the IETF community. The proposal does not replace the work done in IETF working groups, or the presentations given in area gatherings and the plenary sessions. Instead, it allows a different track for delivering information, gathering comments, and rallying support.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on April 27, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
1.1.
Conventions Used in This Document
2.
The 'Berlin' Track
2.1.
Scheduling
2.2.
Room Requirements
3.
Requirements for the Presentation
4.
Chaperone Requirements
5.
Examples
6.
Security Considerations
7.
Changes from Previous Versions
8.
Normative References
§
Author's Address
| TOC |
For the past few years, we have witnessed an unusual proliferation of so called "bar BoFs". The traditional definition of a Bar BoF has been an informal gathering of people interested in a particular subject, discussing what, if anything, should be done in the IETF about this subject. Typically these would occur spontaneously in restaurants, social events, and as the name suggests - bars. These new Bar BoFs are different. The are scheduled in advance, usually with presentations, and they take place in the regular meeting venue rooms, only at inconvenient times. They are listed, along with the agenda in pages linked from the main meeting page on the IETF website.
These bar BoFs have become the main avenue by which new work is brought to the IETF. The IETF mailing list has seen some postings claiming that this is because IETF newbies, who don't know the proper processes schedule bar BoFs just because they don't know any better, but even long-time IETFer Sam Hartman used such a bar BoF to bring the federated authentication idea in IETF 77. For this reason, it is now almost expected that area directors will attend. Also, because of the use of the regular meeting rooms, these Bar BoFs tend to take place over lunch or dinner time, some beginning as late as 10 PM. This creates a lot of stress for potential attendees, and the subjects suffer as well.
The current state of affairs has several drawbacks:
This document suggests an alternative avenue for presenting new ideas or gathered data. Such things can still be presented in working groups or in gatherings. For this version of the docuemnt, this new avenue will be called the 'Berlin' track, after a room in IETF78 that seems to me to be about the right size.
| TOC |
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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
The new track will be held in one of the regular conference rooms. Any meeting participant may give a 30 minute presentation on any technical issue, and the precise requirements are specified in Section 3 (Requirements for the Presentation). The requirements for the meeting room are specified in Section 2.2 (Room Requirements).
| TOC |
Four weeks prior to the meeting, the secreteriat will publish the schedule for the meeting, including rooms and times for the 'Berlin' track. While a 'Berlin' track session is as long as a regular session (for example, 2.5 hours), Each such session is divided into 30-minute slots. The secreteriat is encouraged to schedule these sessions in the early days of an IETF meeting, such as Monday or Tuesday, so that follow-up discussions can take place in the rest of the week.
A separate schedule will be published for each of the 'Berlin'-track sessions, consisting of 30-minute slots. Any participant can request a slot, provided that he meets the criteria in Section 3 (Requirements for the Presentation). With the approval of an AD, the participant may request two adjacent slots, if his presentation requires a full hour.
For each of the 'Berlin'-track sessions, the General Area AD will appoint a chaperone, who will perform a similar function as a WG chair in a regular session. The chaperone will introduce the presenters, make sure that presentations end on time, and advise the presentors and the audience about IETF procedure. To be able to do this, it is RECOMMENDED that the chaperone will be a current of former WG chair or IESG member, who has sufficient experience with the IETF to be able to advise the presentors about the appropriate next steps.
Requests can be made as long as slots are available. Having reserved a slot, the presentor still needs to comply with the requirements in Section 3 (Requirements for the Presentation). If the chaperone feels that the requirements are not met, she can remove the presentation from the schedule, freeing up the slot.
| TOC |
The Berlin track meetings may attract varying sizes of an audience. Therefore, the room MUST be able to hold 50 people, and SHOULD be able to hold 70.
Like all meeting rooms, there MUST be a projector, and the chaperone should have a computer attached, to show presentations in PDF or PPT formats.
| TOC |
General Requirements. These requirements should serve as guidance to the chaperones and ADs when they consider if a certain presentation is appropriate:
Presentations are scheduled for 30 minutes. With a nod from an AD, the presentations MAY be extended to 60 minutes.
A draft MUST exist for each presentation, providing further details about the problem, the proposed solution, or the information conveyed in the presentation. An AD can waive this requirement. It is also RECOMMENDED that a mailing list be set up for the issue.
The presentor requesting a session MUST be attending the IETF session, at least on a one-day pass. An AD may waive this requirement, if they believe the presentation to be particularly interesting to the IETF, but the requirement SHOULD NOT be waived for presentations proposing work items or work groups.
The slides for the presentation MUST be sent to the chaperone, who will upload them to the IETF website, similar to the slides for working group presentations.
About half the time should be spent on presentation, with the remainder left for questions and answers, and for finding a number of people who would like to participate in a future working group. It is up to the presentor to decide the proper mix, but the present-and-run style is considered bad form in the IETF, which is founded on open discussion.
It is highly recommended to use this presentation as an opportunity to get a list of people who are interested in the subject and get them to sign up for the mailing list. It is also RECOMMENDED to find a small group of people, who may have good ideas on the subject, and schedule a proper bar BoF or hallway meeting with them. They can later be the beginning of a working group.
To summarize, this is an approximation of how a presentation should go:
| TOC |
The chaperone is appointed to one or more sessions, lasting between 1 hour and 2.5 hours, and including up to 5 presentations. The chaperone's job is similar to the WG chair's job at a meeting, with some changes.
As soon as registration for the time slots begins, the chaperone MUST go over the proposed presentations, and remove those that are not appropriate according to the guidelines set by this document or subsequent updates and IESG policies. If a presentation seems related to a particular working group, the chaperone should send email to that working group's chairs, informing them of this presentation. In any case, the chaperone has to decide what is or is not acceptable, subject only to an appeal to the IESG.
| TOC |
This section is not meant to be normative. It holds listings for some hypothetical presentations, with a short explanation about why they are the way they are.
This is classic IETF presentation. It can probably be presented in a few slides, it is technical in nature, and there are both a draft and a mailing list. The presentor will undoubtedly be grilled during the Q&A session, but might be able to find 4-5 people who will think this is worthy enough to join him in the hotel lobby later to talk about this. No AD involvement is required.
SNA is a big subject. Without getting into the messy subject of whether it is open or proprietary, the IETF is not the standards body that deals with it. That is why some AD has waived the requirements for draft and mailing list, and allowed the presentation to take a full hour.
Whatever the merits of this idea, it is not technical, and it is not really about the Internet. While 'J. Jones' deserves a soap box just as much as anybody else, an IETF meeting is not the right venue for this.
This draft certainly has merit, but there are two reasons why it should not be in the 'Berlin' track. First, it is very narrow in scope - it's just like adding ciphersuites to TLS, and does not have enough substance for a presentation, and even less for discussion. In fact, it is very likely that the only reason for submitting this draft, was to get an IANA number assignment when it's published. The other reason that this is not appropriate, is that this subject has a natural home in the MSEC working group. It can be a 5-minute presentation there. Given all of this, it does not make sense to waste a 30-minute slot of the 'Berlin' track on this presentation.
| TOC |
There are no security considerations for this draft.
| TOC |
Changes from version -00:
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
| Yoav Nir | |
| Check Point Software Technologies Ltd. | |
| 5 Hasolelim st. | |
| Tel Aviv 67897 | |
| Israel | |
| Email: | ynir@checkpoint.com |