Re: [Gendispatch] some thoughts about ietf communication

Bob Hinden <bob.hinden@gmail.com> Thu, 29 July 2021 16:02 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA603A0926 for <gendispatch@ietfa.amsl.com>; Thu, 29 Jul 2021 09:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hDv24QDdLv54 for <gendispatch@ietfa.amsl.com>; Thu, 29 Jul 2021 09:02:11 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FFC3A0924 for <gendispatch@ietf.org>; Thu, 29 Jul 2021 09:02:10 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id n21so4040789wmq.5 for <gendispatch@ietf.org>; Thu, 29 Jul 2021 09:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+1N1iHcUgvEiQ/6LDcoOd7k0TdsaPZbCUtBLH2wSiSI=; b=Ld34gOt8DDMto5AUqrIR/NguQ6WoGHl2+8u43lrxWmF7f49DIKUdBZ1O/b667E6ZBT TJZtSJVsRSLsbkR81eyk+nv2IxFlsX4WT3UkMYM3Mo6qUGjxd6EdN5bN/cborljrtKv/ YPYlQsFy5IONBx+18JaRBNQABRHr4UiSmNEomOpc9gaoUx8LYk5jGttd8+UCWtGFfCAs X41y4XwUtDU1oEzUfIQBpINFIaLHjth3uYe2+7R6PswAPfoo0CEot8kBOvj0F9+kUhD7 pC36yG7aJ2HtGSV6hsMSrB8P2qZh8HCB0nsQsDb/xlNI2HiziC0aemO29EHXl/XWIUWC e3nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+1N1iHcUgvEiQ/6LDcoOd7k0TdsaPZbCUtBLH2wSiSI=; b=b32XcQnY6GU0CMbmU4W4G7GnWTY7Bq6wjYofQTvuMpSpoKl+iRXYz85KoxsVaC5lmC X9xX2B8DDUHf6sKOFNrin7ct+74/hm4do0gGnNj4fKmlItLobjs3NjtyV/r+mmXudCDD iifirWynYmsE4CoO6HCLRy3lWxmD4M7aUlIrrgg2Wje0vKhnks3cOy7fklbydWDpMafw ZxrKdUjN0M/QU06ZNQF8BHos5QGveu9SbKvWJjJJdMcQHI9Imq3qV0GKU6Dyh3j0Vxfr 6tZ+acNkADCIarHVmY28xxoR9xzcta+yUTBV9/1plNG90HzNahoCqrSBSe2OMh8yZwT1 fS0g==
X-Gm-Message-State: AOAM5330VDL3anhvVyMUWmYapKoKiR7c1IV4vlQ3ctN5F2L8yJBe55s5 ju3JhQB42c00BS06LmzBEMw=
X-Google-Smtp-Source: ABdhPJxtlKdB3TRsaGA1yuLqm/wy+7e1dQfEkOL0tKACQpV1YV4fl0Eo4V2f4DZSdNtM38a63EDc4Q==
X-Received: by 2002:a7b:c5c7:: with SMTP id n7mr5657380wmk.5.1627574526019; Thu, 29 Jul 2021 09:02:06 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:659:904e:d830:2ae7:6ebd? ([2601:647:5a00:659:904e:d830:2ae7:6ebd]) by smtp.gmail.com with ESMTPSA id x18sm3949106wrw.19.2021.07.29.09.02.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 09:02:05 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <FEE60FE3-3FFF-4C18-BFE7-831AF2647D67@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0D2CC4A7-ACE5-4852-8FA9-759AD48686FB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Thu, 29 Jul 2021 09:02:02 -0700
In-Reply-To: <eaf283db-ce73-dc6e-3ba1-64b830f0f726@joelhalpern.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Eliot Lear <lear@lear.ch>, gendispatch@ietf.org
To: "Joel M. Halpern" <jmh@joelhalpern.com>
References: <ee2a840d-1837-1e06-647e-1251295c94bb@lear.ch> <eaf283db-ce73-dc6e-3ba1-64b830f0f726@joelhalpern.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/uII-A8541ZWoWtshzF0GN1gK6RE>
Subject: Re: [Gendispatch] some thoughts about ietf communication
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 16:02:16 -0000

Joel,

> On Jul 29, 2021, at 8:14 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
> I may be misreading this, but it seems that it misses one important purpose for the plenary.
> 
> Sometimes, the community has concerns that need to be expressed, whether the leadership thinks the issue is important or not.  That is why, even though it is usually vacuous, I consider the open mic portion of the plenary to be important.

I agree.  One very important purpose of the plenary is for the community to speak to our leadership and for them to listen.

Bob


> 
> Also, sometimes it is important to air and compare perspectives on an issue (particularly in the4 above category) even if we do not know what a reasonable result could be, and can not arrive at a reasonable outcome during that time.
> 
> I do not see how that would fit with what you have below.
> 
> Yours,
> Joel
> 
> On 7/29/2021 5:45 AM, Eliot Lear wrote:
>> Hi,
>> As one of the people who think that the plenary function of the IETF needs a more serious rethink, I thought I would put this out to the gendispatch list and see what people think.  At the end of the day, I am aiming for an experiment, and might write this or something else up in a draft with others, if others are interested in this or some alternative to this (cough, Pete).  If nobody else is interested, or lots of people think that trying something new for plenary communication is A Bad Idea, this discussion will be the last you hear from me on it.  But what is written below is meant as a starting point, not an endpoint.
>> FWIW, and with apologies to Joel and others, I've a copy of the below in Github at https://github.com/elear/ietf-plen/tree/main. Mostly so that all the below can be modified, substituted, etc, and later turned into a draft if there is interest.
>> The Principles
>>  * Plenary communication is expensive and burdensome, and should be
>>    reserved for important issues that are cross-cutting.
>>  * Plenary communication is necessary when there is an important
>>    question for the community to consider.
>>  * Discussion of such issues must be well organized and facilitated;
>>    and the plenary discussion should be of finite duration.
>>  * There should be some outcome.  The outcome may be a mailing list, a
>>    BOF, dispatch to a dispatch group, an IAB program, or feedback from
>>    a body such as the IESG or IAB.  The outcome shouldn't be an
>>    immediate policy change, but if there is interest, some means to
>>    focus the discussion that might later use our existing processes to
>>    effect that change.
>>  * Plenary discussions may not happen on a regular basis, because there
>>    may not be anything important to discuss.
>>  * The community should decide what's important.  This is a bit of a
>>    chicken and egg issue, though.  Sometimes, an issue must get tossed
>>    around before its importance is understood by others.  What's
>>    important is that just because Eliot thinks an issue is important
>>    and cross cutting doesn't mean that it is to others.
>> How does this differ from *dispatch?
>> There are two major differences:
>> 1. The matter must be of cross-cutting importance.
>> 2. The input to the process may not be a draft to be dispatched, but
>>    simply an important question.
>> Possible Examples
>>  * How should the IESG/LLC organize its COVID response? (past)
>>  * Is there anything the IETF should be doing to address particular
>>    threats or changes to the Internet model? (potential future)
>>  * What should be done about the RFC Editor process? (past)
>>  * What sort of working group working methods should be acceptable?
>>    (potential future?)
>>  * Should our work take into account HR considerations (past and future?)
>> The astute will note that this isn't much different from what you might expect at an in person plenary.
>> Modalities
>>  * EMail may not be the best way to hold plenary discussions.  I think
>>    we've all seen bad interactions in email,  and we seem to do better
>>    in person, and I think we largely enjoy each other's company, quite
>>    frankly, even if that involves meetecho.  perhaps a "discussion"
>>    might really be a set of meetings, the way Heather did consultations
>>    toward the end of her tenor.
>>  * We need a way for the community to upvote issues to the point that a
>>    plenary discussion can occur.  Perhaps Github could provide us this
>>    opportunity.
>>  * IMHO a facilitator should drive the discussion (not lead it), and
>>    help interested parties develop their views *prior* to a plenary
>>    discussion.
>>  * A good way to identify those interested parties would be *short*
>>    position papers.  Again, not email.
>> Comments?
>> Eliot
> 
> --
> Gendispatch mailing list
> Gendispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/gendispatch