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 17:03 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 ADF161270A0 for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 10:03:12 -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 75nFUBFueh4O for <vmeet@ietfa.amsl.com>; Fri, 14 Jul 2017 10:03:11 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 E3323126C22 for <vmeet@ietf.org>; Fri, 14 Jul 2017 10:03:10 -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 1dW3zh-0005jv-9V; Fri, 14 Jul 2017 13:03:09 -0400
Date: Fri, 14 Jul 2017 13:03:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Toerless Eckert <tte@cs.fau.de>
cc: vmeet <vmeet@ietf.org>
Message-ID: <1062F9C3AC2A2D62A30B0C2B@PSB>
In-Reply-To: <20170714143202.GR31925@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> <0229C55E09BE2314261E3D4D@PSB> <20170714143202.GR31925@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/7NFTrUrPuPPYe__kwfpMr5eig3Q>
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 17:03:13 -0000


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

> 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.

Again, I'm not suggesting avoiding remote participation hubs
forever, only that we put it off until a number of other issues
are resolved and running smoothly.  I would feel differently if
we had not other options for remote participation but we do have
those options (and there are part of what need debugging and
experience).

As to "good enough", etc., I think doing some of these things
without the right procedures involved are very dangerous to/for
the IETF (and we have been repeatedly told that one of the
assumptions that such actions would challenge are already
high-risk).  Again, if we had no alternative, I'd be arguing
much more for trying to figure out how to push those boundaries,
but we do have alternatives.

> 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.

But, again, I can give example after example where "taking
things to the list" has become perfunctory and more or less
ignored in IESG review and decision making.  I wish it weren't
that way, but can understand lots of reasons for our apparent
evolution in that direction.   I also know that we have
mechanisms for working around those things, starting with
informal conversations with one of more ADs (I had my last one
of those last month -- they are an important protection and
remedy, especially for marginal situations) rather than really
abusive ones), and there is always the appeals process.  But
using those mechanisms effectively often requires a good deal of
skill and experience with the IETF and IETF processes --
precisely the skills and experience that I don't think we can
assume that typical participants in remote hubs who have never
regularly attended IETF meetings will have.

As to your other suggestions, this is probably the wrong list
and forum, but one observation about "use jabber instead"
suggestions.  Remembering that English is not only my first
language but that I type much more quickly than the IETF average
(something many people think is, in my case, a disease), there
have been many occasions in which there has been a heated
discussion in a WG or plenary, with long microphone queues,
where a comment I might type into Jabber in response to a remark
that is made in the meeting is seriously OBR because the
discussion has moved on long before I was able to finish typing
something coherent.  Delayed audio doesn't help, nor does the
time it takes for someone to get to the microphone, but the
problem would exist even if both of those were instantaneous.
How much worse would it be for someone with either different
skills in English or slower typing.    I'm not saying "no", just
that maybe we need to either look for other solutions or
training WG chairs to be much better as making sure the Jabber
queues are drained (and people have had time to type) before
allowing threads to be switched.  I think that would require
much longer meeting times and don't know if the community is
willing to pay that price.

Again, I'm just suggesting that taking this one step at a time
would better serve everyone involved.

  best,
   john