Re: [vmeet] interest in a side-meeting to talk about remote hubs, local communities, etc?

John C Klensin <john-ietf@jck.com> Fri, 14 July 2017 13:21 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: vmeet@ietfa.amsl.com
Delivered-To: vmeet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D86131B77 for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 06:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 eQJVBZoD4kwP for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 06:21:30 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A957131A64 for <vmeet@ietf.org>; Fri, 14 Jul 2017 06:21:30 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1dW0X8-0005QH-FA; Fri, 14 Jul 2017 09:21:26 -0400
Date: Fri, 14 Jul 2017 09:21:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: joly@punkcast.com, Nalini J Elkins <nalini.elkins@insidethestack.com>
cc: Alia Atlas <akatlas@gmail.com>, vmeet <vmeet@ietf.org>
Message-ID: <445D45EBBDF27F2FDD587338@PSB>
In-Reply-To: <CAM9VJk26_rwyK3DQhDM2UNJdj3v8=0X9WeWy4fg5weCFkO4ZMw@mail.gmail.com>
References: <CAG4d1rdcexVq9tzyUe9YkhxXxovtnXHri6QJYnr=CtTes7d-KA@mail.gmail.com> <7C01F627C8359CEDBAC06663@PSB> <1218340531.4451377.1499975473084@mail.yahoo.com> <47EEF3CDA3FF3D28A436E23F@PSB> <344501606.4498898.1499978169216@mail.yahoo.com> <CAM9VJk26_rwyK3DQhDM2UNJdj3v8=0X9WeWy4fg5weCFkO4ZMw@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/vmeet/M_xxhYsTBS6TtcgjhsxQcCbRFkA>
Subject: Re: [vmeet] interest in a side-meeting to talk about remote hubs, local communities, etc?
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 14 Jul 2017 13:21:32 -0000

Joly,

Sorry... I was responding a bit in the context of some prior
discussions (some not on the vmeet list) as well as to Alia's
note and your response.  Clarification below.

--On Thursday, July 13, 2017 19:51 -0400 Joly MacFie
<joly@punkcast.com> wrote:

> Individuals attending hubs can still register as remote
> participants and interact via jabber etc, surely?

Sure.  THey can even individually set up as participants with
Meetecho which (bandwidth and other facilities permitting),
should allow a better experience.  There are still some issues,
but most of them are easily overcome but, e.g., use of headsets.
However, at that point, they are participating as individuals
who happen to be sitting in the same facility.  They are not
participating in the hub with the hub participating in the
meeting (there are other ways to frame that, but I trust you see
what I'm getting at).

>  The problem
> I was highlighting at ICANN was the effort to set up
> audio/video interactive hubs. Similarly ICANN still enables
> interaction via Adobe Connect, and there is nothing to stop
> communal viewing.

Yes, but that is exactly the distinction between what we've
started to call "remote participation hubs" and "remote viewing
hubs".

> At both ICANN meetings, and the IGF, there is no better way to
> keep up with what happens in other rooms, either live, or
> catching up during breaks, than text transcriptions.  In the
> past, while these are projected in the room, or emebedded in
> remote participation platforms, one has to dig to find the
> correct standalone streamtext urls. however there is
> improvement. One thing I have agitated for,
> ​  is for immediate posting of the rough transcripts. The
> tendency is for these to disappear, and sat on for correction,
> until the iron is well cold.

Yes, but two observations.   First, no matter how well, or
poorly, IETF Jabber scripts do, they don't approximate the level
of detail and quality of ICANN (or UN, IGF included) real-time
transcriptions.   Second, I've noticed (and am confident that
others have too) that the quality of the ICANN and IGF
transcriptions tend to deteriorate very quickly when the
discussion turns to technical details, inevitably with
terminology and context that are not familiar to the
transcribers.  Perhaps fortunately, ICANN and IGF don't have
that problem very often.  However IETF discussions that do not
involve technical details and require fairly deep understanding
of the materials being discussed are, as has been discussed on
the iETF list many times, very often useless presentations or
otherwise a waste of very limited WG time.

That suggests a different way to look at my position on this.
I'm very much in favor of anything that helps bring new people
into the IETF or that increases understanding of the IETF and
its work and products in broader communities, especially, but
not limited to, those people who cannot regularly attend
meetings, don't have technical English as a first language or
even a good working language, etc.   However, I think we need to
keep a focus on the primary objective of getting IETF work done
and dine with as broad a selection of educated and competent
participant perspectives as possible.  That means it is really,
really, important to have real time remote participation by
those who are really going to contribute work well.  I don't see
any incompatibility between that and remote viewing hubs,
observers, audio feeds in other than real time, etc., and think
those things are all desirable.  But I also don't want to see
efforts to get remote participation hub arrangements together to
get in the way of, or get priority over, the kinds of individual
remote participation about which we seem to be getting better
and better.

best,
   john