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:45 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 B991012EC12 for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 06:45:15 -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 zNCrrTdPHRaa for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 06:45:15 -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 DD9E4126CC7 for <vmeet@ietf.org>; Fri, 14 Jul 2017 06:45:14 -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 1dW0u7-0005S3-Iy; Fri, 14 Jul 2017 09:45:11 -0400
Date: Fri, 14 Jul 2017 09:45:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: Toerless Eckert <tte@cs.fau.de>
cc: Joly MacFie <joly@punkcast.com>, vmeet <vmeet@ietf.org>
Message-ID: <0229C55E09BE2314261E3D4D@PSB>
In-Reply-To: <20170714110530.GQ31925@faui40p.informatik.uni-erlangen.de>
References: <CAG4d1rdcexVq9tzyUe9YkhxXxovtnXHri6QJYnr=CtTes7d-KA@mail.gmail.com> <CAG4d1rc1pYWeLmNQ5yw60K1A7HqmxbttDBFwhxca0dnmj4ED3Q@mail.gmail.c om> <35554605-FED2-432F-8A24-1EE9E8398183@isoc.org> <CAM9VJk1BPkK2L=bT40mdiRbVYczEWUVNQG3fyzoVBmFzDRsvfQ@mail.gmail.com> <20170714110530.GQ31925@faui40p.informatik.uni-erlangen.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/2h58AX_PRTmTqd0mbgqcXx1gzKo>
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:45:16 -0000

Toerless,

Hi.  I don't have a convenient URL.  Maybe someone else can
provide one.  But the issues you ask about below, vis-a-vis
remote participation with a local user as request manager, come
down to fundamental IETF procedural and fairness issues.  As
only one example, in WGs with controversial subject matter,
Chairs often have difficulty managing in-room microphone queues
in a way that is generally accepted as fair and balanced.   When
those queues are long, having someone pick a request up from
Jabber and run to the microphone has never worked especially
well; I imagine opinions differ as to whether it has worked well
enough.  We've now got remote queue (and queue management more
generally) facilities in Meetecho that should work better than
the Jabber relay approach.   IMnvHO, we still don't have
agreement, skills, and experience with how to make that work
well -- things that are more a matter of training and practices
than the tools themselves.   In the unlikely event that a WG
Chair should behave in a way that favors one point of view or
one participants or group of participants over others, the
actions occur in plain sight and those Chairs are accountable to
the IESG.

Now, contrast that with the sort of informal arrangements you
posit.  The WG Chair isn't managing the queue, the hub manager
is.  If there are two people in the hub who want to speak, the
WG Chair is going to see only the request "from the hub".  The
hub manager is not directly accountable to the IESG or the
community.  It is not clear that whatever mechanisms we have for
ensuring fairness and good behavior apply to hubs or other
remote, non-individual, setups.  We have no plan about
registration of participants at hubs that are visible to the
Secretariat and part of the permanent IETF record. 

I think that, given time (and I hope keeping our priorities
clearly in mind -- see earlier notes), it should be possible to
sort all of those issues out although we should view the ICANN
experience as cautionary.  But doing something ad hoc, with ad
hoc local management arrangements, poses a risk to the IETF's
ability to have confidence in its consensus model... at least
unless the principle that we make no decisions at meetings, only
on mailing lists and only based on discussions that are visible
on/from those mailing lists is very strictly observed.  My
observation is that, at least unless there is a specific
complaint, and increasing number of WGs have been treating the
principle in a more and more relaxed way.

    best,
      john


--On Friday, July 14, 2017 13:05 +0200 Toerless Eckert
<tte@cs.fau.de> wrote:

> Eg: For the use-cases discussed on this thread such as
> developing world hubs whee i guess the issue is not only
> ability not to travel but also inability to have individual
> remote participant HW/network connection, i can't quute see how
> the first instance of a remote hub should need to be anything
> different than a single remote participant hardware
> ("notebook") in a room, connected to projector and noise
> cancelling speakerphone and a user acting as the remote hub
> admin in front of it managing requests for comments from other
> participants in the room. Aka: nothing that looks different to
> the WG chair than an individual remote participant called
> "Room Foobar in Faraway Town".