<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY RFC2418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-jaeggli-interim-observations-04" ipr="trust200902">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Abbreviated Title">Observations on the experience and nature of Large Interim Meetings</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Joel Jaeggli" initials="J.P.J" surname="Jaeggli">
      <organization>Zynga</organization>

      <address>
        <postal>
          <street>675 east Middlefield rd</street>

          <!-- Reorder these if your country does things differently -->

          <city>Mountain View</city>

          <region>CA</region>

          <code>94043</code>

          <country>US</country>
        </postal>

        <phone>+15415134095</phone>

        <email>jjaeggli@zynga.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Jari Arkko"  initials="J.A." surname="Arkko">
      <organization>Ericsson</organization>
      <address>
	<postal>
	  <street></street>
	  <city>Jorvas</city>
	  <code>02420</code>
	  <country>Finland</country>
	</postal>
	<email>jari.arkko@piuha.net</email>
      </address>
    </author>

    <date month="January" year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>interim meeting experiences</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Planning, particpipation and conclusions from the experience of participating in the IETF LIM activity on september 29th 2012.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The genesis of this draft was the experience of planning and participating in the so called IETF Large Interim Meeting (LIM) held adjacent to the fall RIPE meeting on the 29th of September 2012. Three working groups met, OPSEC, V6OPS and SIDR. It is intended that the draft cover planning, the operation of the meeting, and an attempt at some conclusions based on the experience.</t>

<t>The fact that the draft represents the vantage point of a limited number of persons  and a singular event at this time necessarily limits the utility and aplicability of the draft and undoubtedly as result, some key elements of the planning and motivation will be missed. The Large Interim Meeting is the product of efforts over a number of years by multiple parties including the ISOC Board, IETF management (Chair, IESG, IAB, IAOC, IAD) working group chairs and probably others. To the extent that this draft can be made better through the input of others, The authors would invite contribution, criticism and future dialog on how we meet outside the scheduled IETF meetings.</t>

<t>The Sept 29th LIM was the most recent attempt that we are aware of an interim meeting scheduled by IETF management for the purposes of accumulating interim meetings in a common location. The IETF's traditional model for interim meetings has been that virtual or physical interim meetins are scheduled by working-group participants in conjunction with chairs and coordinating ADs <xref target="IESGinterim"></xref>. It is not the first attempt at such meeting. It's status therefore an experiment is worth bearing mind in understanding the rest of the text.</t>

  <section title="date and location">
  <t>The LIM was scheduled to coincide with the end of RIPE 65 and Occurred on Saturday Sept 29th 2012. Ripe 65 was held at the Hotel Okura Amseterdam from September 24th-28th. It is our understanding that coordination with the RIPE program committee occured only After IETF 84 (an IAB member member also happens to serve on the RIPE program committee)</t>
  </section>
</section>

<section title="Planning"> 
    <t>It is, our understanding that discussion of the possibility of a LIM style meeting within this time window occurred in early 2011 if not before. The v6ops chairs were asked at various times to consider particpation in such a meeting in other potential locations. The discussion related to this interim meeting commenced in June. The stated rational for targeting v6ops involvement in a large interim was the volume of work that we process during and between meetings. For reasons that we will try and explore the expectation of a volume of work to be processed was not borne out by the agenda and meeting itself.</t>

<t>A previous proposal for a LIM style meeting to have met in Malta in 2009 attracted a sponsor (Google) but was ultimatetly cancled on the basis of expected participation (60 particpants) and remaining time constraints. The Malta LIM was to have included the RAI area plus SOFTWIRE and BEHAVE.</t>

  <section title="Discussion leading up to LIM">
    <t>Some questions existed in the planning phase as to the nature of the logisitical support provided by the secretatit for the meeting as well as, remote participation, and the actual timinng of the meeting. Unlike a traditional interim the responsibility for satisfying these details was for better or worse in the hands of the secretariat, which meant a reduced workload for the chairs but it also left some details undecided until they could be announced, a hotel contract for the meeting rooms wasn't completed until after the 4 week window required for announcing and interim meeting had passed</t>
  </section>

  <section title="Plannning for meeting and announcement">
    <t>A show of hands, as well as subsequent mailing list followup were done to gauge v6ops interest in participation in an interim meeting. Roughly 50 participants, mostly active ones indicated significant interest in an interim collocated with RIPE 65 which we deemed sufficient to proceed. Superficially, only a fraction of the v6ops attendees are represented by the segment of the group indicating interest. When the numbers are mapped against active participants and draft authors, interested participants in the interim likely represent a bigger proportion of that group.</t> 

<t>Two of the three scheduled meetings were given 4 hour windows, the third SIDR (which routinely has interim meetings) had effectivetly the entire day.</t>
  </section>

    <section title="Draft Deadlines"> 
    <t>Immediately after IETF 84, the working group chairs of v6ops proposed an interim draft deadline 2 weeks out from the interim meeting ( Saturday the 15th of Sept). This was to be the basis for the acceptance of revised or new drafts onto the agenda. The goal of the deadline was to be able to identify drafts which had changed and which had issues to be addressed prior to any additional action.</t>
  </section>

</section>

<section title="Meeting">
  <t>Two OPS area working groups met, OPSEC and V6OPS, Effectively one after the other albiet seperated by lunch. The SIDR working group met in parallel.</t>
  <section title="Running">
    <t>Both OPS-area meetings came in substantially below their allotted time. V6OPS was allocated four hours and completed in two. SIDR broke for lunch, returned, and finished early, however it used a substantially higher percentage of the allocated time. Possibly because it was a Saturday remote participation was limited but not non-existant</t>

<t>The observation of one participant in v6ops (Jari Arkko) was that they came prepared to discuss topics, for which the document  authors were not present. Looking at what we were able to schedule for the agenda, appart from the discussion of the state of drafts in various states of processing and the attention that they required, the scheduled presentations (3) were associated with drafts for which the authors were requesting feedback.</t> 

  </section>
  <section title="Remote Participation">
    <t>>Remote participation was supported by volunteers from meetecho using their own application. Hotel okura wired network was provided for the slide-sharing computer and wireless infrastrucuture was used to support the meeting and in-room participation in the meetecho chat. An outage of the hotel wireless network was observed during the OPSEC meeting with the result that local participation in the meetecho session would have been interupted for about 10 minutes, had there been any to speak of. Philip Mathews reports having attended the v6ops meeting remotely.</t>
  </section>
  <section title="Participants">
    <t>Interim Meeting registration ended up being about 40 participants, 2 days prior to the meeting that number was 23, provisions had been made for around 100 attendees.</t>
  </section>

</section>

<section title="Observations and Conclusions">
  <t>Despite misgivings with V6OPS as patient zero for the large interim meeting concept, once committed we endeavored to make the meeting work for the participants that took the time out of their weekend to attend, or as was my case, traveled specifically for the Interim meeting. As an experiment we think a lot of things are worth doing once and hope that some lessons can be derived from the experience that have value for future interims.</t>

  <section title="Incentives for participation">
    <t>An observation that we would make about the  V6OPS interim submission deadline (and what we believe to be relative failure) is that it appears that authors who are not planning to attend a meeting, are less inclined to revise a document in support of a meeting they are not attending. The corollary, is that authors planning on a attending a meeting will rev their documents, or possibly that a revised document is justification to attend (This applies to  IETF meetings in general).</t>

<t>While this may be a tautology, Interim meetings probably are more successful when they appear necessary. SIDR clearly is a close knit group of people (even when they disagree) working hard on a design problem. The required time is due to the necessity of going over every issue to be addressed within a constrained temporal space. While the SIDR interim(s) may not be valid as the measurement of consensus they promote a common understanding of the problems and solution space among the key participants that ultimately will be the basis of any broader consensus.</t>

  </section>
    <section title="Organization in conjunction with other events">
    <t>The particular conjunction  of the LIM and RIPE was proposed several months prior to coordination with the RIPE program committee. Given that the RIPE meeting traditionally ends on Friday with Lunch it is possible that tighter coordination with the RIPE organization could have coupled the event more directly  (e.g. to friday afternoon). There is an implicit assumption on the part of the authors that tighter coordination with an operator meeting means ceding control over the program to a certain extent to fit within that framework.</t> 

<t> The RIPE meeting is a week long like an IETF meeting, and if the goal of a conjoint interim is evangelism, cross pollination or outreach, (is it?) then fitting more directly into the program  would probably be salubrious for both groups. As it stands, the bulk of the attendees in OPSEC and V6OPS were present to attend RIPE as well, or attended RIPE and stayed for the interim.</t>

<t>A specific suggestion provided by several RIPE participants was to leverage the post-RIPE friday afternoon as opposed to the following day in order to reduce the commitment required by RIPE participants who would otherwise have to remain an extra day and therefore travel on saturday. A common experience with many *NOG meetings and indeed with the IETF is ancillary meetings packing in either before or after a core meeting thereby increasing the overall cost (time,money,commitment) associated with the overall activity.</t>

  </section>
  <section title="Implications for working groups/design teams of varying sizes">
    <t>V6ops attendance at an IETF meeting is typically in excess of 200 attendees. An interim meeting that attracts 25 of those and limited remote participation is necessarily exclusionary by default if not deliberately. If useful work that advances drafts, gets done, is that exclusion a bad thing? The resulting meeting input would not  be useful for measuring meaningful consensus. V6OPS got a new draft out of discussion that occurred during the interim meeting.</t>

<t>The history of interim meetings has illustrative examples of working groups or design teams, with numerus interim meetings (IP storage/NFSv4, Lemonade, 6lowpan, Behave SIDR etc) that demonstrate the utility of frequent physical or virtual interims. It is possible that there are properties (demands on immediacy, collaboration with other SDOs etc) that make some working groups or design teams more effective at utilizing interims than others.</t> 
  </section>

  <section title="Mobilizing ADs">
    <t>Area Director's and IAB members were rather well represented at the LIM,  While the attendance of both of the Ops and Mangement Directors was appreciated we are not sure that it's a good use of their time. In particular if the frequency of these events were fixed as some rate in the future, this represents an additional workload for which huge benefits do not appear likely to ensue. In the case of of colocation with a RIPE meeting, some of these participants were attending already. Jari Arkko observed, "I would probably not have made the trip just for RIPE this time (although I usually do travel to them), nor would I have attended just for the LIM itself."</t>
  </section>

  <section title="Outreach">
    <t>Some entities related to the IETF clearly have outreach and advocacy as part of the mission, Internet Society, IETF chair, Liaisons, edu-team and so forth. It is not clear to us, that beyond the scope of chartered working group documents that end up as part of the RFC series, that working group activities including meetings are well suited for use as an outreach mechanism. The IETF meeting as a whole, which is certainly an opportunity for advancing the work of the respective working groups is also an opportunity for cross pollination, for the collegial building of consensus that advances joint efforts, and to the extent that mini-IETF's do not appear to support those opportunities relative to the three times annually meeting, the utility of LIMs as outreach tools lacks some degree of legitimacy.</t>
  </section>

  <section title="Conclusions">
    <t>It's not easy to draw strong conclusions from a single experiment. Perhaps we have and extensive control group in the form of working groups that did not avail themselves of the virtual interim. Some thoughts follow.</t>

   <t>Mobilizing IETF secretariat and meeting support resources in support of interim meetings that ultimately are lightly attended does not, on the face of it seem like it works on a cost recovery basis. Smaller single working-group interims have experienced substantial difficulties arranging technology support and remote participation for interim meetings in some locations so in that respect some central planning and coordination does pay off.</t> 

<t>The requirements for an interim meeting are typically modest, aggregating them makes them less so.</t> 

<t>Expectations for the level of availability that an IETF network provides are expensive to deliver in the case of a smaller more ephemeral meeting.</t> 

<t>In cases where interim meetings leverage resources that have higher availability/performance expectations such as the corporate offices of some of the participants, the results may be substantially better than what we can expect to be delivered by a hotel network contractor.</t>

<t>Interim meetings are typically organized around short term goals, the longer term planning needs associated with participants budgeting for travel and making time commitments are incompatible with the short term nature of current interim planning. Immediacy appears to trump other considerations for working groups and desgin teams that meet in signular interims.</t>

<t>The experience of OPSEC and V6OPS was not I think a huge success, it is likely that some of the rational discussed in the "incentives for participation" section plays a role in the ability of OPS working groups to invite work to be revised on the basis of interim deadlines. By all accounts the SIDR working group had a successful productive meeting. It is also likely in our understanding that SIDR would have met in the absence of the LIM with similar results.</t>
  </section>

</section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Ron Bonica, Fred Baker, Randy Bush, Spencer Dawkins Philip Matthews and Simon Pietro Romano for offering constructive input or feedback on this draft.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo Makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>No security consequences are envisioned as a proeduct of this draft.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

<!--
    <references title="Normative References">
  
    </references>
-->
    <references title="Informative References">
      <reference anchor="IESGinterim" target="http://www.ietf.org/iesg/statement/interim-meetings.html">
	<front>
	<title>IESG Guidance on Interim Meetings, Conference Calls and Jabber Sessions</title>
	<author><organization>IESG</organization></author>
	<date year="2008"/>
	</front>
      </reference>
      &RFC2418;
   </references>  

  </back>
</rfc>
