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

Toerless Eckert <tte@cs.fau.de> Fri, 14 July 2017 14:32 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 33561131B9E for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 07:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 i-9olDVp6TLu for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 07:32:07 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817AB131B99 for <vmeet@ietf.org>; Fri, 14 Jul 2017 07:32:07 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id ED2A658C4AE; Fri, 14 Jul 2017 16:32:02 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C86C7B0C16D; Fri, 14 Jul 2017 16:32:02 +0200 (CEST)
Date: Fri, 14 Jul 2017 16:32:02 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: John C Klensin <john-ietf@jck.com>
Cc: vmeet <vmeet@ietf.org>
Message-ID: <20170714143202.GR31925@faui40p.informatik.uni-erlangen.de>
References: <CAG4d1rdcexVq9tzyUe9YkhxXxovtnXHri6QJYnr=CtTes7d-KA@mail.gmail.com> <CAG4d1rc1pYWeLmNQ5yw60K1A7HqmxbttDBFwhxca0dnmj4ED3Q@mail.gmail.com> <35554605-FED2-432F-8A24-1EE9E8398183@isoc.org> <CAM9VJk1BPkK2L=bT40mdiRbVYczEWUVNQG3fyzoVBmFzDRsvfQ@mail.gmail.com> <20170714110530.GQ31925@faui40p.informatik.uni-erlangen.de> <0229C55E09BE2314261E3D4D@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0229C55E09BE2314261E3D4D@PSB>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/vmeet/cXZYzedoOtLpfIF8TgZ6xXibIeg>
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 14:32:10 -0000

Thanks John for the detailled explanation.

Some thoughts:

It sounds as if you worry about the best solution to deal with 
bad behavior, eg: biased chairs, pontification, flash mobs,
irreconcileable business conflicts and so on.  Which is
good to worry about. And yes, i've seen or heard about all this too.

I just think we should not conclude that we can
not have any remote hubs unless all these issues can be solved
by tools. IMHO it would be better to also look into a scheme where
the tools may just be good enough for good weather phases of
meetings with remote (group) participation and then improve our
BCP for intelligently solving conflicts with human intervention
when it starts to rain.

We already take things to the list whenever we fail to come to
conclusions in a meeting. We're far less innovative to explore
other options AFAIK. How about trying to resolve
heated local/remote discussions by moving it to jabber during the
meeting even for the local folks. How about allocating time based
on contribution credit score (please write your opinions into a draft etc..),
How about pushing conflicting parties into an interim where they'd be on
equal footing, etc. pp.

Cheers
    Toerless

On Fri, Jul 14, 2017 at 09:45:04AM -0400, John C Klensin wrote:
> 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".
> 
> 
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet

-- 
---
tte@cs.fau.de