Re: IETF 107 Vancouver In-Person Meeting Cancelled

John C Klensin <john-ietf@jck.com> Wed, 11 March 2020 04:50 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5163A1190; Tue, 10 Mar 2020 21:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 rgfomUCSw2M9; Tue, 10 Mar 2020 21:50:14 -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 AF0083A118D; Tue, 10 Mar 2020 21:50: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 1jBtJr-000KMA-FD; Wed, 11 Mar 2020 00:50:11 -0400
Date: Wed, 11 Mar 2020 00:50:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
cc: Bob Hinden <bob.hinden@gmail.com>, IESG <iesg@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: IETF 107 Vancouver In-Person Meeting Cancelled
Message-ID: <E4C7E11A9B8F26117A1529A8@PSB>
In-Reply-To: <B18A6A93-1DB9-43BF-99DE-17F6EB751869@cable.comcast.com>
References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <0E1D4A15-3CAB-4D9D-A3E9-8815983A052D@gmail.com> <B18A6A93-1DB9-43BF-99DE-17F6EB751869@cable.comcast.com>
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/ietf/gBqdgEu9zRw68qhBfq-38snzt6M>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 04:50:17 -0000


--On Wednesday, March 11, 2020 00:22 +0000 "Livingood, Jason"
<Jason_Livingood@comcast.com> wrote:

> On 3/10/20, 5:55 PM, "ietf on behalf of Bob Hinden"
> <ietf-bounces@ietf.org on behalf of bob.hinden@gmail.com>
> wrote:
> 
>>  Kudos to the IESG and IRTF chair for making this difficult
>>  decision.
> 
> +1
> I know the community appreciates that this decision was taken
> rationally, after assessing data from all the working groups
> and research groups, and via a consensus-based process in the
> IESG and IRTF.  This is, as always, the sort of process &
> approach that sets this community apart from other SDOs. :-)

Jason, 

I beg to differ and we will sooner or later have another
situation in which the difference is important (there have been
at least a few in the past). 

What sets this community apart from other SDOs is that we make
most decisions by consensus-based processes in the community and
with full community involvement.  The role of the IESG has
traditionally (since Kobe and POISED at least) to interpret and
verify (i.e., "call" or "declare") community consensus.  RFC
2028 Section 3.5 talks about the IESG as "administering" the
standards process, not deciding, based on its collective wisdom,
what is to be a standard.   As a more recent example see
language such as "we strive to make our decisions by the consent
of all participants" in RFC 7282.  Any number of other standards
bodies select leadership bodies (by one means or another) who
then make decisions _for_ those standards bodies.  They may do
that by unanimous consent (a very strong version of consensus),
by voting, by discussion and agreement within that leadership
body that is indistinguishable from our definition of rough
consensus, or by the sorts of compromises that RFC 7282 abhors.
But they make the decisions and they are the final authority.    

In the IETF, it is the community itself that forms the consensus
and is the final authority, and it is that which makes us
different.

In that sense, the way this decision was made --by consensus
_within_ the IESG and with the IRTF Chair -- is not what we
traditionally do and what sets us apart; it is an aberration.
It is, however, an aberration that exhibits something else that
distinguishes us from those other SDOs.  While it is not, to my
recollection, explicit in any of our procedural documents, we
often put Doing The Right Thing ahead of nitpicking adherence to
the details of procedures.   In this case, I believe that, in
gathering information the way it did, discussing issues
internally and with the IRTF Chair, and then reaching internal
consensus and making a decision, the IESG Did The Right Thing
whether one agrees with their conclusion or not (I do agree, but
that is not important in this context).   Most of the
alternatives with far more early community involvement would
have been catastrophic (or at least would have had us still
debating whether or not to hold a meeting in March 2020 during
May of 2020).

But, if we were to end up confusing the IESG making decisions
that way with an IETF consensus process, we not only would not
be different enough from those other SDOs for the difference to
matter, but we would be in serious trouble indeed.

best,
   john