<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
    

<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-non-wg-presentations-01" category="exp">
  <front>
    <title abbrev="non-wg-presso">Giving Non-Working Group Presentations in IETF Meetings</title>
    <author initials="Y." surname="Nir" fullname="Yoav Nir">
      <organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
      <address>
        <postal>
          <street>5 Hasolelim st.</street>
          <city>Tel Aviv</city>
          <code>67897</code>
          <country>Israel</country>
        </postal>
        <email>ynir@checkpoint.com</email>
      </address>
    </author>
    <date year="2010"/>
    <area>General Area</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t> 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.</t>
    </abstract>
  </front>
  <middle>
    <!-- ====================================================================== -->
    <section anchor="introduction" title="Introduction">
      <t> 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.</t>
      <t> 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.</t>
      <t> The current state of affairs has several drawbacks:<list style="symbols">
        <t> 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.</t>
        <t> 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.</t>
        <t> 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.</t>
        <t> 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.</t>
        </list></t>
      <t> 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.</t>
      <section anchor="mustshouldmay" title="Conventions Used in This Document">
        <t>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 <xref target="RFC2119"/>.</t>
      </section>
    </section>
    <section anchor="newtrack" title="The 'Berlin' Track">
      <t> 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 <xref target="presreq"/>. The requirements for the meeting
        room are specified in <xref target="roomreq"/>.</t>
      <section anchor="scheduling" title="Scheduling">
        <t> 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.</t>
        <t> 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 <xref target="presreq"/>. With the approval of an AD, the participant may
          request two adjacent slots, if his presentation requires a full hour.</t>
        <t> 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.</t>
        <t> Requests can be made as long as slots are available. Having reserved a slot, the 
          presentor still needs to comply with the requirements in <xref target="presreq"/>. If
          the chaperone feels that the requirements are not met, she can remove the presentation
          from the schedule, freeing up the slot.</t>
      </section>
      <section anchor="roomreq" title="Room Requirements">
        <t> 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.</t>
        <t> 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.</t>
      </section>
    </section>
    <section anchor="presreq" title="Requirements for the Presentation">
      <t> General Requirements. These requirements should serve as guidance to the chaperones and 
        ADs when they consider if a certain presentation is appropriate:<list style="symbols">
        <t> 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."</t>
        <t> 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.</t>
        <t> 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.</t>
        <t> 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.</t></list></t>
      <t> Presentations are scheduled for 30 minutes. With a nod from an AD, the presentations MAY
        be extended to 60 minutes.</t>
      <t> 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.</t>
      <t> 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.</t>
      <t> 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.</t>
      <t> 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.</t>
      <t> 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.</t>
      <t> To summarize, this is an approximation of how a presentation should go: <list
        style="symbols">
        <t> Chaperone presents the subject (0.5 minutes)</t>
        <t> Presentation, including the problem and what can be done (15 minutes)</t>
        <t> Questions and Answers (10 minutes)</t>
        <t> Polling the room, how many are interested in this (1 minute) </t>
        <t> Show a slide with the mailing list address, and invite people to sign up (0.5 minutes)</t>
        <t> Ask who would like to meet for a bar BoF (0.5 minutes, find 4-6 people) </t>
        <t> Find a good time for the bar BoF (2 minutes) </t>
        <t> With 1 minute to spare, the next presentor walks up to the front of the room</t>
        </list></t>
    </section>
    <section anchor="chaperone" title="Chaperone Requirements">
      <t> 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.</t>
      <t> 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.</t>
    </section>
    <section anchor="examples" title="Examples">
      <t> 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.</t>
      <t><list style="symbols">
        <t> Title: A multi-homed variant of FTP</t>
        <t> Time: Monday, 10:30 (30 minutes)</t>
        <t> Presentor: J. Doe</t>
        <t> Draft: http://www.ietf.org/id/draft-doe-ftp-mh-01.txt </t>
        <t> Slides: http://www.example.com/slides/mhftp.pdf</t>
        <t> Mailing List: http://www.example.com/ml/mhftp.html</t>
        <t> 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.</t></list></t>
      <t> 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.</t>
      <t><list style="symbols">
        <t> Title: SNA Primer for TCP/IP Folks</t>
        <t> Time: Tuesday, 10:00 (60 minutes)</t>
        <t> Presentor: J. Smith</t>
        <t> Slides: http://www.example.com/slides/sna.pdf</t>
        <t> 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.</t></list></t>
      <t> 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.</t>
      <t><list style="symbols">
        <t> Title: The Writing is on the Wall: World Peace through Facebook Interaction</t>
        <t> Time: Canceled by chaperone</t>
        <t> Presentor: J. Jones</t>
        <t> Slides: http://www.example.com/slides/pax_facebook.pdf</t>
        <t> 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.</t></list></t>
      <t> 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.</t>
      <t><list style="symbols">
        <t> Title: Using the Camelia cipher in GDOI</t>
        <t> Time: Canceled by chaperone</t>
        <t> Presentor: J. Kwan</t>
        <t> Draft: http://www.ietf.org/id/draft-kwan-camelia-gdoi-00.txt </t>
        <t> Slides: http://www.example.com/slides/camelia-gdoi.png</t>
        <t> Abstract: This draft adds the camelia cipher as a possible encryption algorithm for 
          GDOI keys, both KEKs and TEKs.</t></list></t>
      <t> 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.</t>      
    </section>
    <!-- ====================================================================== -->
    <section anchor="security" title="Security Considerations">
      <t> There are no security considerations for this draft. </t>
    </section>
    <section anchor="delta" title="Changes from Previous Versions">
      <t> Changes from version -00: <list style="symbols">
        <t> Added chaperone considerations.</t>
        <t> Expanded the introduction.</t></list></t>
    </section>
  </middle>
  <!-- ====================================================================== -->
  <back>
    <references title="Normative References"> 
      <reference anchor='RFC2119'>
        <front>
          <title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials='S.' surname='Bradner' fullname='Scott Bradner'>
            <organization>Harvard University</organization>
            <address>
              <postal>
                <street>1350 Mass. Ave.</street>
                <street>Cambridge</street>
                <street>MA 02138</street>
              </postal>
              <phone>- +1 617 495 3864</phone>
              <email>sob@harvard.edu</email>
            </address>
          </author>
          <date year='1997' month='March' />
          <area>General</area>
          <keyword>keyword</keyword>
        </front>
        <seriesInfo name='BCP' value='14' />
        <seriesInfo name='RFC' value='2119' />
        <format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
        <format type='HTML' octets='16553' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
        <format type='XML' octets='5703' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
      </reference>
    </references>
    <!-- ====================================================================== -->
  </back>
</rfc>
