One document matched: draft-nir-non-wg-presentations-00.xml
<?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-00" category="info">
<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.</t>
<t> The traditional bar BoF has three major weaknesses:<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> Not all subjects benefit from the open, free-form discussion that is characteristic of
a bar BoF. For example, presenting the results of an experiment, or the results of
measurements taken over inter-domain traffic, is best done in presentation style with
slides and a microphone, rather than over a meal of a drink.</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="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> First version </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>
| PAFTECH AB 2003-2026 | 2026-04-24 14:45:58 |