Re: NomCom eligibility & IETF 107

Robert Elz <kre@munnari.OZ.AU> Tue, 31 March 2020 19:38 UTC

Return-Path: <kre@munnari.OZ.AU>
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 0D2B93A2A85 for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 12:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.297
X-Spam-Level:
X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 SMRns85HttW2 for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 12:38:39 -0700 (PDT)
Received: from munnari.OZ.AU (munnari.coe.psu.ac.th [IPv6:2001:3c8:9009:181::2]) (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 8AB503A2A83 for <ietf@ietf.org>; Tue, 31 Mar 2020 12:38:39 -0700 (PDT)
Received: from jinx.noi.kre.to (localhost [IPv6:::1]) by munnari.OZ.AU with ESMTP id 02VJbmPi016491; Wed, 1 Apr 2020 02:37:49 +0700 (ICT)
Received: from jinx.noi.kre.to (localhost [127.0.0.1]) by jinx.noi.kre.to (8.15.2/8.14.2) with ESMTP id 02VJbVC6010301; Wed, 1 Apr 2020 02:37:32 +0700 (+07)
From: Robert Elz <kre@munnari.OZ.AU>
To: Alissa Cooper <alissa@cooperw.in>
cc: Pete Resnick <resnick@episteme.net>, Barry Leiba <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: NomCom eligibility & IETF 107
In-Reply-To: <0C31D020-46FA-424E-8FFD-64BBE8F952E9@cooperw.in>
References: <0C31D020-46FA-424E-8FFD-64BBE8F952E9@cooperw.in> <CALaySJ+kFVXrVAkYLaO6MaPqDA29MzXhVFcxG0c6hZcBs-LqnQ@mail.gmail.com> <CAC4RtVAhfFLYwzqw6Qch3BpuMvqjZPzFJ5o1iTOwR+yqH8j-Aw@mail.gmail.com> <CAC4RtVCzMPGuunYZBCSh90ddY2kKJ_Hqnot0s1jmhNQ7qT0xkg@mail.gmail.com> <89730DD8-0451-4658-A0CD-83A85E2055FE@episteme.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 01 Apr 2020 02:37:31 +0700
Message-ID: <23579.1585683451@jinx.noi.kre.to>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a0Oxe6c12ndqkwZpUjWJC3NiO5g>
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: Tue, 31 Mar 2020 19:38:45 -0000

    Date:        Tue, 31 Mar 2020 13:56:19 -0400
    From:        Alissa Cooper <alissa@cooperw.in>
    Message-ID:  <0C31D020-46FA-424E-8FFD-64BBE8F952E9@cooperw.in>

First, you can all ignore my opinion if you like, I haven't been part of
the IETF process for many years, and don't usually even read any of the
(voluminous) IETF related e-mail I still get sent.   But I noticed all of
this tonight (I have only read a very few of the most recent messages, and
have no idea what proposals have been made).

Second, assuming it isn't already in the nomcomm process doc (I thought
it was, but perhaps not) the first thing that should be done, right now,
is to last call a 2 line (plus 27 pages, or whatever it is up to these days,
of boilerplate) BCP RFC-to-be (I-D initially) which simply says:

	In case a new nomcom is not seated, for any reason, the previous
	nomcom shall continue to serve.

That gets over any "Danger Will Robinson" type nonsense about "we absolutely
have to reach consensus or the whole process falls apart".

The previous nomcom might not be thrilled at this - but it is unlikely
(even this year) to ever be put into practice, but the process needs this
one vulnerability covered (assuming it isn't already).

Beyond that:

  | I think what you suggest is a recipe for either delegitimizing the IETF
  | or causing it to enter a state of dysfunction. It assumes there will be
  | consensus at the end of four weeks.

Anything that is to make forward process has to assume rough consensus
for a change exists.   If we ever get to the state where the IESG starts
saying (for any reason) "we have no consensus on what to do, but we believe
we must do something, so we have decided to do ..." then all is truly lost.

Personally, I'd like that to happen - I believe that the current IESG
process (and workload) is all broken, and needs a revolution to fix it,
and that kind of thing could provoke exactly the needed revolution.

That would be very similar to the IAB's Kobe decision (mid 90's) which
resulted in the revolution which installed (approximately) the current
process.   The same would happen to the IESG I believe (and a good thing
that would be - it would return the IESG back to the job of managing the
IETF's work, and get it out of the standards (including BCP) approval
business).

Overall, I believe that the process Pete set out (along with the BCP I
suggested above) is the best way for all of you to make progress for
this year.

kre