Re: New Version Notification for draft-resnick-variance-00.txt

John C Klensin <john-ietf@jck.com> Sat, 28 March 2020 20:15 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 2017F3A0DB4 for <ietf@ietfa.amsl.com>; Sat, 28 Mar 2020 13:15:43 -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 gi0M9Kd9FH1k for <ietf@ietfa.amsl.com>; Sat, 28 Mar 2020 13:15:41 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 CC6473A0CE0 for <ietf@ietf.org>; Sat, 28 Mar 2020 13:15:40 -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 1jIHrl-000Eg2-Vu; Sat, 28 Mar 2020 16:15:37 -0400
Date: Sat, 28 Mar 2020 16:15:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
cc: IETF discussion list <ietf@ietf.org>
Subject: Re: New Version Notification for draft-resnick-variance-00.txt
Message-ID: <BC8D550D8EAE709FCA831F67@PSB>
In-Reply-To: <CAC4RtVA1j4vSCvgWstnajveAqgWYvu19UDSNKBagk3XjfDM=2A@mail.gmail.com>
References: <158533925458.17797.13806166303625482245@ietfa.amsl.com> <AE66200A-E718-4BF6-BA87-EE427A0BF971@episteme.net> <0e9e0a5f-5022-9a06-b8be-46d922f31aa7@nostrum.com> <4f79a660-2268-dad0-e796-dc1fabfcf73d@network-heretics.com> <A2B6BC2A-5983-48D9-BF0E-F782BBA54004@episteme.net> <0b518909-d421-afe7-b473-3d7ea3b04648@network-heretics.com> <CAC4RtVA1j4vSCvgWstnajveAqgWYvu19UDSNKBagk3XjfDM=2A@mail.gmail.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/Obe5F1seHBBqocfg3rpXrDkq1uI>
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: Sat, 28 Mar 2020 20:15:44 -0000


--On Saturday, March 28, 2020 10:20 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

> (Not picking Keith's comment, in particular: it was just
> convenient to use for the reply here.)
> 
> For those of you who think the IESG should not (or is not
> allowed to) exercise judgment here and make a one-time
> exception for this exceptional situation:
> 
> Please advise how you think we can get the NomCom eligibility
> question sorted out IN TIME to seat a 2020-21 NomCom, when we
> normally need to ask for volunteers within the next 6 weeks.

Barry,

I think I've suggested a variation on what follows off-list,
but, in response to your request:

(1) Write an I-D and get it posted (tomorrow would be good,
today better).  Focus it exclusively on the Nomcom eligibility
issue that has been under discussion on this list for weeks,
with more messages than I can easily count.  The shorter and
more narrowly-focused the draft is, the better (I think some
variation on Pete's draft is a good idea for multiple reasons,
but  this is not the time and doing it in haste would be
unwise.).  Obviously, you shouldn't ask me to write it :-)

Speaking as someone whose personal preferences are probably in
the rough, I don't particularly care which mechanism you choose
as long as the draft makes it clear that this is a one-time
thing to seat this (2020-2021) nomcom, that it cannot be used as
a precedent for the 2021-2022 nomcom or anything else, and that
it clearly and explicitly leaves 107 as a legitimate "First
Meeting" at which the new IAB and IESG were seated.  Beyond
that, I just don't believe that the number and profile of people
in the eligible pool are going to be significantly affected.  I
also believe that the number and profile of people from the
eligible poor who actually volunteer will be affected even less.
Those are anecdotal impressiona -- if any one has or can get
data one way or the other, let's see it, but let's not block on
waiting for it as having it show up in steps 3 or 4 below would
be ok.

(2) Provide in the I-D that it becomes effective the moment the
IESG approves it.  If there are appeals, we sort them out in
parallel with collecting Nomcom volunteers and seating them.  If
an appeal changes the rules in a way that affects someone, we
treat that as we treat any other situation in which a selected
volunteer is unable to serve.

(3) Give that I-D a week to season, nits to be picked, old
issues to be rehashed, etc.  If clear consensus emerges that
whatever mechanism that was selected for the -00 draft was the
wrong one, change the document (and make any other changes
suggested by the discussion) and get -01 posted.

(4) Issue a Last Call.   On the theory that we need four week
last calls only so the community has ample time to think about
an issue that has not been thoroughly vetted and refined in a WG
and noting that there is nothing substantive in the I-D (other
than "immediate effect on IESG approval") that has not been
kicked around (and around and around) on the IETF list for weeks
already, make a one-time exception and announce the Last Call
for two weeks, to be extended if discussions indicate that is
really needed.   That shortened time is a much smaller exception
that making an IESG decision about nomcom eligibility without a
document; it is consistent with the spirit of the 2026
provisions, and it should be a lot less controversial.

(5) The IESG agrees, internally and in advance, that the
document will be processed as soon as the Last Call ends, that
any AD who starts nitpicking (not that anyone would) will be
taken to the nearest bikeshed.   So either the IESG signs off,
with or without minor substantive adjustments, on whatever
emerges from the Last Call, or we need either a bigger bikesheed
or a distributed virtual one to accommodate all of us.

(6) At that point, three weeks and some days into your six, we
have an approved BCP and documented rough community consensus
for the rules for this Nomcom.  The RFC Editor gets to the
document in a timely fashion, but how quickly they do it does
not affect the process.


_Variation_

Skip Step 3, issue a four-week Last Call as soon as the I-D gets
posted, treat the comments that would have appeared during that
week as LC comments with the expectation of posting -01 halfway
through the LC period.   That avoids making any exceptions and
costs an extra week, but that is still less than the six week
window you suggest we have.

We could process Pete's document the same way, but the
"discussed for weeks" option wouldn't apply, so we'd need four
weeks to get it approved and _then_ a minimum of four weeks to
approve the variance, so, on your six week calendar, that just
doesn't work (as you have already noted).

Or we could dither around for three or four weeks and _then_ use
the shortness of time to justify the IESG making an executive
decision.  I hope (and expect) that we can all pull together on
this and skip that option.

best,
   john





(6)



(2) Twenty-four hours after the draft is posted