[Gendispatch] some thoughts about ietf communication

Eliot Lear <lear@lear.ch> Thu, 29 July 2021 09:45 UTC

Return-Path: <lear@lear.ch>
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 DC6CF3A1B81 for <gendispatch@ietfa.amsl.com>; Thu, 29 Jul 2021 02:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 5AEYTuj6fgBC for <gendispatch@ietfa.amsl.com>; Thu, 29 Jul 2021 02:45:53 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BF63A1B7D for <gendispatch@ietf.org>; Thu, 29 Jul 2021 02:45:53 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1002::343] ([IPv6:2001:420:c0c0:1002:0:0:0:343]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 16T9jf0R087192 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 29 Jul 2021 11:45:42 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1627551942; bh=dmbfakpohu0l89OUv8VBqRYQu/Rl4w7QL//7xBnZEVo=; h=To:From:Subject:Date:From; b=q5HoI7u+E3sSBw2XrZSiEEO2mJUx9M05JsqsvpC6Fo08oIXcYGkRaFn0ounmm+L1X BGWZSFdDi3szAElbyFiJ2TYj7MZpxAeZUoBeY6qsPDPBJGNEf9rQXa7KZbvYudC/En 4Gg1OuRLbeYnPhK51iz2wPBtImaYTeea7qL0wf0o=
To: gendispatch@ietf.org, Pete Resnick <resnick@episteme.net>
From: Eliot Lear <lear@lear.ch>
Message-ID: <ee2a840d-1837-1e06-647e-1251295c94bb@lear.ch>
Date: Thu, 29 Jul 2021 11:45:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="hb2UXeuA7CXGzdoFUOoyQNS8J3f09P4Ma"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/GDFplqlS15aMMidqpHsaSfT0xhM>
Subject: [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 09:45:59 -0000

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