Re: Remote participation fees

John Leslie <> Sat, 14 February 2015 23:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 32ABC1A064C for <>; Sat, 14 Feb 2015 15:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fubDfvkh5Dp4 for <>; Sat, 14 Feb 2015 15:34:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 027621A0016 for <>; Sat, 14 Feb 2015 15:34:02 -0800 (PST)
Received: by (Postfix, from userid 104) id C63CFC94BD; Sat, 14 Feb 2015 18:33:48 -0500 (EST)
Date: Sat, 14 Feb 2015 18:33:48 -0500
From: John Leslie <>
To: John C Klensin <>
Subject: Re: Remote participation fees
Message-ID: <20150214233348.GV14296@verdi>
References: <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Feb 2015 23:34:06 -0000

   (I do generally try to avoid high Narten scores, but...)
John C Klensin <> wrote:
>... but there is an issue that more and fancier protocols and/or
> hardware doesn't solve, which is that running these things well
> and at high quality tends to need serious operational commitments,
> which means more staff.

   There will be costs, but they _could_ be quite minimal:

> One can reduce the staff requirement somewhat with _really_ fancy
> and expensive technology, but the tradeoff may not be wonderful.
> I'm not talking about the complex technical stuff here, I'm talking
> about things closer to "camera gives good view of carpet" and
> "if that speaker is going to pace the floor while talking,
> either the camera needs to follow or someone needs to apply a
> short leash"

   These don't require on-site staff to notice, so probably these
could be _entirely_ covered by volunteers. Doing something about it
probably would require on-site staff -- but that's needed to make
the sound+picture useful to archive the session anyway...

> to say nothing of the perennial microphone announcement, "MY NAME
> IS <mumble>".

   That's really no worse for remote participants.

> Similarly, very high quality remote participation with lots of
> participants at lots of different locations tends to either put
> a premium on participant training and/or typing speed and/or a
> requirement for trained moderators who can control both in-room
> and remote conversation flow.  Again, not really technical
> issues, but not so easy to resolve, at least without cultural
> changes.

   Actually, there are many conferencing systems which already
have solutions to these problems. It's just a learning-curve
issue -- and so far we've avoided learning them.

>... Again, be careful what you wish for, lest trying to optimize
> for people attending face to face meetings while not requiring so
> much travel, bring a situation in which almost all of the people
> at a meeting in Region X are from Region X, almost all of those
> at a meeting in Region Y are from Region Y, etc.  That loss of
> diversity in individual f2f meetings, even if it improved
> statistical diversity over a year or two, would not, IMO, be a
> desirable outcome.


John Leslie <>