Network Working Group                                             Y. Nir
Internet-Draft                                               Check Point
Intended status: Experimental                           October 24, 2010
Expires: April 27, 2011


        Giving Non-Working Group Presentations in IETF Meetings
                   draft-nir-non-wg-presentations-01

Abstract

   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.

Status of this Memo

   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 Notice

   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



Nir                      Expires April 27, 2011                 [Page 1]


Internet-Draft                non-wg-presso                 October 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions Used in This Document . . . . . . . . . . . . . 4
   2.  The 'Berlin' Track  . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Scheduling  . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Room Requirements . . . . . . . . . . . . . . . . . . . . . 5
   3.  Requirements for the Presentation . . . . . . . . . . . . . . . 5
   4.  Chaperone Requirements  . . . . . . . . . . . . . . . . . . . . 6
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  Changes from Previous Versions  . . . . . . . . . . . . . . . . 8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9


































Nir                      Expires April 27, 2011                 [Page 2]


Internet-Draft                non-wg-presso                 October 2010


1.  Introduction

   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:
   o  It is often difficult, especially for those who are not IETF
      regulars, to find these "birds of feather" among the 1200+
      participants in a particular meeting.
   o  Hundreds of drafts are published every day.  It is often futile to
      expect that even those who might be interested in the subject will
      have read a draft on the subject, and be knowledgeable enough to
      have a meaningful discussion on the topic without a prior
      presentation.
   o  Presenting new topics over lunchtime or at 10 PM tends to cause
      people to skip lunch, dinner, or sleep.  It also means that
      several people will skip the session, simply because they have
      other plans, such as meetings, eating, or sleeping.  This is
      especially true for IESG members and working group chairs, who may
      be an important part of the presentor's target audience.
   o  The lack of "the right people" at the meeting is particularly
      problematic for IETF newbies, who need guidance as to where to
      take their idea next.

   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



Nir                      Expires April 27, 2011                 [Page 3]


Internet-Draft                non-wg-presso                 October 2010


   avenue will be called the 'Berlin' track, after a room in IETF78 that
   seems to me to be about the right size.

1.1.  Conventions Used in This Document

   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].


2.  The 'Berlin' Track

   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.  The requirements for the meeting room are specified in
   Section 2.2.

2.1.  Scheduling

   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.  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.  If the chaperone feels that the requirements are not met,



Nir                      Expires April 27, 2011                 [Page 4]


Internet-Draft                non-wg-presso                 October 2010


   she can remove the presentation from the schedule, freeing up the
   slot.

2.2.  Room Requirements

   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.


3.  Requirements for the Presentation

   General Requirements.  These requirements should serve as guidance to
   the chaperones and ADs when they consider if a certain presentation
   is appropriate:
   o  The presentations MUST be related to the issues the IETF works
      with.  "Why we all need to be driving hybrid cars" is not
      appropriate, as is "Getting a universally-standard power-plug
      shape, so that we don't have to carry stupid adapters to every
      IETF meeting."
   o  Economics or social impacts or the Internet are appropriate
      subjects, but social commentary and politics in general are not.
      "Re-elect Obama in 2012 because he gets the Internet" has plenty
      of venues to present, none of which is the IETF.
   o  Subjects need to have enough substance to warrant a half-hour time
      slot and hopefully some follow-up discussion.  For this reason,
      adding yet another ciphersuite involving some government's
      favorite algorithm to TLS is not appropriate.
   o  Subjects SHOULD NOT have a natural home in another working group.
      A new TLS ciphersuite SHOULD be presented at the TLS working group
      meeting, not at the Berlin track.  If, however, the working group
      chairs have passed on allowing this presentation, or if the
      working group does not have a scheduled meeting in this IETF
      gathering,then it is appropriate to present it at the Berlin
      track.

   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.




Nir                      Expires April 27, 2011                 [Page 5]


Internet-Draft                non-wg-presso                 October 2010


   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:
   o  Chaperone presents the subject (0.5 minutes)
   o  Presentation, including the problem and what can be done (15
      minutes)
   o  Questions and Answers (10 minutes)
   o  Polling the room, how many are interested in this (1 minute)
   o  Show a slide with the mailing list address, and invite people to
      sign up (0.5 minutes)
   o  Ask who would like to meet for a bar BoF (0.5 minutes, find 4-6
      people)
   o  Find a good time for the bar BoF (2 minutes)
   o  With 1 minute to spare, the next presentor walks up to the front
      of the room


4.  Chaperone Requirements

   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



Nir                      Expires April 27, 2011                 [Page 6]


Internet-Draft                non-wg-presso                 October 2010


   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.


5.  Examples

   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.

   o  Title: A multi-homed variant of FTP
   o  Time: Monday, 10:30 (30 minutes)
   o  Presentor: J. Doe
   o  Draft: http://www.ietf.org/id/draft-doe-ftp-mh-01.txt
   o  Slides: http://www.example.com/slides/mhftp.pdf
   o  Mailing List: http://www.example.com/ml/mhftp.html
   o  Abstract: Today many computers have multiple connections to the
      Internet, such as wireless LAN and 3G. We leverage this to allow
      multiple connections to be used simultaneously, so that file
      trasfers get the cumulative bandwidth.

   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.

   o  Title: SNA Primer for TCP/IP Folks
   o  Time: Tuesday, 10:00 (60 minutes)
   o  Presentor: J. Smith
   o  Slides: http://www.example.com/slides/sna.pdf
   o  Abstract: SNA is a network architecture quite different from
      TCP/IP.  In this session we will learn the fundamentals of SNA,
      and compare the two architectures.

   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.





Nir                      Expires April 27, 2011                 [Page 7]


Internet-Draft                non-wg-presso                 October 2010


   o  Title: The Writing is on the Wall: World Peace through Facebook
      Interaction
   o  Time: Canceled by chaperone
   o  Presentor: J. Jones
   o  Slides: http://www.example.com/slides/pax_facebook.pdf
   o  Abstract: Today, when everyone has a facebook profile, and can
      'friend' anyone in the world, universal peace is finally at hand.
      What diplomats in the United Nations have never been able to
      achieve in closed session meetings, will very soon be done in a
      bottom- up fasion.  In this presentation, we will explain how.

   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.

   o  Title: Using the Camelia cipher in GDOI
   o  Time: Canceled by chaperone
   o  Presentor: J. Kwan
   o  Draft: http://www.ietf.org/id/draft-kwan-camelia-gdoi-00.txt
   o  Slides: http://www.example.com/slides/camelia-gdoi.png
   o  Abstract: This draft adds the camelia cipher as a possible
      encryption algorithm for GDOI keys, both KEKs and TEKs.

   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.


6.  Security Considerations

   There are no security considerations for this draft.


7.  Changes from Previous Versions

   Changes from version -00:
   o  Added chaperone considerations.
   o  Expanded the introduction.





Nir                      Expires April 27, 2011                 [Page 8]


Internet-Draft                non-wg-presso                 October 2010


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Author's Address

   Yoav Nir
   Check Point Software Technologies Ltd.
   5 Hasolelim st.
   Tel Aviv  67897
   Israel

   Email: ynir@checkpoint.com




































Nir                      Expires April 27, 2011                 [Page 9]