Re: Remote participation fees

Nico Williams <nico@cryptonector.com> Wed, 25 February 2015 18:24 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990C21A1AA2 for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 10:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.855
X-Spam-Level: ****
X-Spam-Status: No, score=4.855 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FSL_HELO_FAKE=3.199, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQGOYOQSwfvR for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 10:24:14 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7C1A1A29 for <ietf@ietf.org>; Wed, 25 Feb 2015 10:24:14 -0800 (PST)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 00FBF27BC065; Wed, 25 Feb 2015 10:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=RldXafIvvc4zQYGMfi2EqRC7Z7U=; b=fSoPZpis/jh Xk3TK1d6aOQLlDFxT6lq19vaHuMP8W/xLjmWlWaSXfH3UdWLFhjLcdCkuPHnxKkV 9VCBS+dsHPV6M+04fl9OX418TxQJaRtaa+CbU5UtMh30R+qCUjLZFt5UqG5+UD7O rM3jXQSH/idXxociD/g2mpofV4ENmsuU=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 77F8327BC064; Wed, 25 Feb 2015 10:24:12 -0800 (PST)
Date: Wed, 25 Feb 2015 12:24:08 -0600
From: Nico Williams <nico@cryptonector.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: Remote participation fees
Message-ID: <20150225182407.GA8631@gmail.com>
References: <54DE9844.1010807@gmail.com> <61FBB27B-4EF3-40A0-8981-00EB89698295@isoc.org.ec> <B90F5E29-06C5-41D1-9F31-1BE42382995F@gmail.com> <CABmDk8=YPZ1W2tTOqP23U2PFVLoDh-3+wwmcA8mpta-Y05op2A@mail.gmail.com> <54DFBAF6.30409@cs.tcd.ie> <22998.1424015163@sandelman.ca> <DB3PR06MB219529AF019E530B47FBE!67BF210@DB3PR06MB219.eurprd06.prod.outlook.com> <5146CB6A-789D-4382-ACE8-9715B6C2AB92@ecs.soton.ac.uk> <EMEW3|bf7ae4bd312fe25b80a066e21ee84d67r1ODjZ03tjc|ecs.soton.ac.uk|5146CB6A-789D-4382-ACE8-9715B6C2AB92@ecs.soton.ac.uk> <41798353-AA92-4476-A0BB-ECD2FEF96BF2@nominum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <41798353-AA92-4476-A0BB-ECD2FEF96BF2@nominum.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UKZ0YqU0UHatiwvBrmFfe_k21Vs>
Cc: Tim Chown <tjc@ecs.soton.ac.uk>, ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2015 18:24:15 -0000

On Wed, Feb 25, 2015 at 09:05:33AM -0500, Ted Lemon wrote:
> On Feb 25, 2015, at 8:45 AM, Tim Chown <tjc@ecs.soton.ac.uk>; wrote:
> > Perhaps charging is introduced for higher quality access (cases b,
> > c), while casual ‘best effort’ remote participation is kept open and
> > free (case a).
> 
> If I were setting it up, I'd give everyone the same access whether
> they can afford to pay or not, and incentivize paying by listing
> people who pay differently in the proceedings.   If you're an amateur
> participant who isn't being paid to attend, you shouldn't have to pay,
> period.
> 
> If you are being paid to attend, then we should just say that your
> company is expected to pay the remote attendee fee.  If they don't, it
> should be a bit embarrassing for them (not for you!).   In practice I
> would expect that people who are being paid to attend would just pay
> the remote attendee fee, because they support the IETF, and there's no
> reason for them not to.

Yes, the honor system will do.

Improvements that could be made for remote participation:

 - Virtual mic queuing that's better than the current "get someone in
   the room *and* the jabber room to represent you".

   I'm not sure how important this is.  In practice the current solution
   works well enough for the WGs I participate in.  But it does rely on
   volunteers, and it does put them out somewhat.  It's also not
   guaranteed to work every time, in every WG.  We've been limping along
   without a solution here, so it's not urgent, but it's worth thinking
   about.

   One thing that has worked well is to have two projected displays: one
   for slideware, and one for the jabber room, which the chairs and/or
   others in the room can use to help manage access to the mic.  Perhaps
   two jabber rooms would help (one for chatting, one for requesting mic
   access).  Perhaps a bot would help (maybe even with text-to-speech
   functionality, though a lot of jargon and acronyms would probably
   stump TTS).

 - Follow-along slide viewing.

   Again, we've been limping along with this one, with the aid of a
   volunteer indicating slide changes on the jabber room.  This works
   well enough and with low enough a burden on volunteers that a
   solution may not be needed.

 - Lower-latency audio.

   One of the first things I do when I join a WG remotely is: attempt a
   guestimate of audio latency using the jabber room.  If latency is
   much more than a second then the jabber room can get very
   distracting, but the jabber room is often a great aid to following
   along.

   For webex-style remote participation, where we get to have our voices
   carried into the room, latency is utterly critical.

   For me this is the top priority.  Low-latency audio feeds or bust.

   I will happily pay a very large fraction of the full participation
   fee if the IETF can deliver this one feature, honor system or not.

 - Remote MIC, a la webex.

   I'd like more of this.

I can think of other features that might help, particularly help in
participating in hallway conversations (which surely are out of scope),
but the above is a start.  For example: always leave the room MICs on
(with a warning sign?) so that people can have post-meeting
conversations that should be heard by remote participants (this is
already the case, usually, and it is risky, from a privacy point of
view).  Participation in hallway conversations (and bar BoFs) are a key
justification for on-site attendance, and it should continue being so.

Nico
--