[vmeet] Supporting interim meetings (was Re: Duties of WG Chairs)

Dave CROCKER <dhc@dcrocker.net> Mon, 11 May 2009 23:59 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8C9D23A67DB for <vmeet@core3.amsl.com>; Mon, 11 May 2009 16:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Bc7fjh29Oaf7 for <vmeet@core3.amsl.com>; Mon, 11 May 2009 16:59:38 -0700 (PDT)
Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id D22D83A6AD2 for <vmeet@ietf.org>; Mon, 11 May 2009 16:59:37 -0700 (PDT)
Received: from [] (adsl-68-122-32-149.dsl.pltn13.pacbell.net []) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4C011ds018604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <vmeet@ietf.org>; Mon, 11 May 2009 17:01:07 -0700
Message-ID: <4A08BC3C.9070302@dcrocker.net>
Date: Mon, 11 May 2009 17:01:00 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
CC: vmeet@ietf.org
References: <20090507175356.GG32848@verdi>
In-Reply-To: <20090507175356.GG32848@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com []); Mon, 11 May 2009 17:01:07 -0700 (PDT)
Subject: [vmeet] Supporting interim meetings (was Re: Duties of WG Chairs)
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2009 23:59:39 -0000

John Leslie wrote:
 >    As part of the discussion, one AD mentioned that Virtual Interim
 > Meetings are being seriously considered. (I have noted three announcement
 > of Virtual Interim meetings recently.)
 >    Can we do anything to help?

Excellent timing for the query.

I am starting to suspect that the answer is yes.

I've been thinking about the experiences, so far, in looking at tools, and I'm 
suspecting that the two, immediate, areas of potential benefit are the IETF 
management meetings (IESG, IAB, IAOC) and interim meetings.

A distinction that came up in a private discussion was between 'special' events 
-- less frequent, and amongst a group where participants have less experience 
with each other -- versus regular ones.

The management meetings are quite regular in timing and participation.  That has 
an effect on group dynamics and probably makes it tolerable to have /less/ basic 
functionality, such as sharing slides, but probably makes telephone bridging 
/more/ important, to deal with participants who are in transit.  (The more 
regular the meetings, the more likely someone is in transit, with no useful 
Internet connectivity.)

By contrast, an interim meeting could require good Internet access for 
participants and, therefore, limit voice to VOIP.  But content display and 
meeting management tools probably become more important.

By contrast a plenary or, worse, an entire week-long series of sessions is 
vastly more complicated and demanding.  I think we can see the hints of 
capability emerging but could not reasonably expect to have major impact on main 
IETF meetings quickly.  We can probably improve the current functionality for 
remote participants, but we aren't likely to make a serious dent in the actual 
/need/ for full-week, face-to-face meetings.

Based on this view -- and folks are encouraged to comment -- I think that a good 
near-term goal is to try to find a tool to enable easy, virtual interim meetings.

We should try to converge on the statement of functions and scaling that we 
think are essential for an interim meeting.

 From the ealier discussions, one of the milestones was stated as:

 > MG-C:  Individual virtual session, small scale (30?)

Henning offered these items in response:

 > - Ability to render PowerPoint and PDF MUST, OpenOffice SHOULD.
 > - For audio, allow VoIP and PSTN dial-in (800# is MAY).
 > - Ability to mute remote participants (e.g., to deal with someone's
 >   music-on-hold system)
 > - Audio recording


 From the earlier postings, here's what I think we are wanting, to support a 
virtual, interim meeting.

I'll note that we need to be careful about an existence proof for a function, 
versus what is comfortable for its regular use.  In particular because we are a 
technical group, we can deal with all sorts of silliness that the rest of the 
world can't, won't, and should not have to.  However I believe that for regular 
use, we need to pretend that we aren't geeks and instead demand features and 
ease of use that makes sense for regular folk.



0.  Scale

     I think we could get away with a relatively modest initial requirement. 
Say, 30 people?  That will limit applicability for the larger and more active 
working groups.

     I guess the real question is what participation numbers there have been for 
interim meetings over the last couple of years?  We might still settle on a 
small initial number, but we should try to know beforehand.

1.  Meeting management -

     a)  Ability to queue up participants, as if at a microphone

         For meetings of a group that can easily be 20-40 people, with 
relatively little history of group collaboration, the job of meeting management 
is vastly easier when there is some functional help for coordinating who wants 
to speak next.

     b)  Ability to shift who is presenting

         This is the equivalent of having different folk come up to the front of 
the room and plug in their laptop.  I suspect that a failure to support this 
mode of participation would seriously hamper the convenience -- and possibly 
effectiveness -- of meetings.

2.  VOIP for voice

     As noted above, a telephone bridge does not have to be a requirement, for 
meetings that are infrequent.

3.  Shared slide presentation

     Shipping powerpoint files around is tolerable only for special cases, I 
believe.  Since we are talking about broad-based, regular use, we should make 
presenting slides as comfortable as it is in a room.  A major benefit of 
integrated slide presentation and control is that there is then no need to worry 
about people's knowing what slide is showing.

4.  Shared white board

     My gut says that this really is an extremely useful feature for many 
meetings.  And since it's available in a number of products, it seems to make 
sense that we require it.


5.  IM

     Existing IETF jabber can suffice, IMO.  IM integrated into the conferencing 
tool would be nice, but only if it is on a par with the jabber service we are 
used to.

6.  Telephone bridge (in, out)

     mumble.  This adds quite a bit of expense.  I could argue /against/ 
supporting it at all(!)

7.  ???



   Dave Crocker
   Brandenburg InternetWorking