Re: [vmeet] Supporting interim meetings

Thomas Narten <narten@us.ibm.com> Sun, 17 May 2009 19:52 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F0528B23E for <vmeet@core3.amsl.com>; Sun, 17 May 2009 12:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.569
X-Spam-Level:
X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKkvh580mxhq for <vmeet@core3.amsl.com>; Sun, 17 May 2009 12:52:47 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 4150328C232 for <vmeet@ietf.org>; Sun, 17 May 2009 12:52:47 -0700 (PDT)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4HJpXZ4031104 for <vmeet@ietf.org>; Sun, 17 May 2009 13:51:33 -0600
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4HJsF5S240524 for <vmeet@ietf.org>; Sun, 17 May 2009 13:54:15 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4HJsFRF021156 for <vmeet@ietf.org>; Sun, 17 May 2009 13:54:15 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-76-131-135.mts.ibm.com [9.76.131.135]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4HJsDOf021020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 13:54:14 -0600
Received: from cichlid.raleigh.ibm.com (cichlid [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n4HJsCUY013356; Sun, 17 May 2009 15:54:12 -0400
Message-Id: <200905171954.n4HJsCUY013356@cichlid.raleigh.ibm.com>
To: John Leslie <john@jlc.net>
In-reply-to: <20090513025653.GD14375@verdi>
References: <20090507175356.GG32848@verdi> <4A08BC3C.9070302@dcrocker.net> <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com> <20090513025653.GD14375@verdi>
Comments: In-reply-to John Leslie <john@jlc.net> message dated "Tue, 12 May 2009 22:56:53 -0400."
Date: Sun, 17 May 2009 15:54:12 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: dcrocker@bbiw.net, vmeet@ietf.org
Subject: Re: [vmeet] Supporting interim meetings
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Sun, 17 May 2009 19:52:54 -0000

John Leslie <john@jlc.net> writes:

> Thomas Narten <narten@us.ibm.com> wrote:
> > Dave CROCKER <dhc@dcrocker.net> writes:
> > 
> >> ... 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.
> > 
> > Actually, I don't agree with this (necessarily). The absolute
> > requirements to participate in an interim meeting are more
> > modest. Think about the critical things:
> > 
> >  - audio bridge (could be VoIP, or POTS, that is a detail)
> >  - access to charts
> >  - IM capability as a side channel

>    We have been running virtual meetings with that much for some time
> now, any many folks are used to it. By human nature, if we provide a
> tool that folks aren't used to, they'll gravitate back to _that_ model
> they're used to.

Actually, I wasn't just reporting what we have today. I was thinking
of my participation in remote meetings and the parts I considered
necessary to participate.

>    2) Advance availability of charts is egregiously poorly enforced.
> Where it is enforced it leads to charts which only exist in the
> presenter's imagination. Preparation of slides is the best exercise
> for most presenters to organize their thoughts -- and, alas, the
> last minute is when it, almost by definition, happens.

Absolutely. I am assuming that advance preparation would be
enforced. For something scheduled out in advance (like a WG meeting),
the idea that charts are being editted in real time minutes before the
actualy presentation is flawwed. This is poor work habits of the
presentor, not the nature of how one prepares for meetings.

...

>    But last-minute changes, even changes _during_ the presentation
> are the nature of the beast. I agree with Dave.

Not for the kinds of meetings we are talking about. We are talking
about WG meetings that are scheduled weeks out in advance. Things
shouldn't be in serious flux moments before the call... There may be
exceptions, but in general charts can be done a few days out in
advance of a meeting.

>    Playing back an audio recording is not the normal case. We should
> design for the normal case.

Actually, I've done this fairly often. It has advantages to following
a meeting in real-time (one can pause, rewind, etc.) in cases where
one is not expecting to actually contribute/speak during the meeting.

Thomas