Re: NomCom eligibility & IETF 107

Spencer Dawkins at IETF <> Thu, 26 March 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57DE93A0CEC for <>; Thu, 26 Mar 2020 05:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCP26xy6rnEp for <>; Thu, 26 Mar 2020 05:59:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C8183A0CF7 for <>; Thu, 26 Mar 2020 05:59:04 -0700 (PDT)
Received: by with SMTP id t17so6260077ljc.12 for <>; Thu, 26 Mar 2020 05:59:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=URydxhEkCFxSjCZGOILB+sHWpCDoqMkOTuYgbzk2Ix0=; b=d55ysMVdaUX+FXwWQgJW1g5qvAiaSk+SIfTOmAxPB8pg7zIOXNokERCyV58tZZmGKr cTya7xRkniF4xmTMxxdz02iJklvcZb9YBUNCtAhwoAlsL2njaha4Gwrv5n2tLkUYypRo dQ9a6Fg1sxl7g+//r3+SITeHCwjGuaeydVu6ENHg6JsSLV492UBBRhR31vtHEfPrznm4 5G97aeir5iNG+pMzxCZWtkpklaXC+8HrAAvC9Ok5/xibidSLAsBHxpftEA31hEjLgpZ1 YoddtBXlgaVW+ttU6CpaTvgygM2bLKjggAo45IwJ9BzCeU92qTbyq1dbmuzdyJnFHuwD 5G6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=URydxhEkCFxSjCZGOILB+sHWpCDoqMkOTuYgbzk2Ix0=; b=TnHRyFmwVUaDhd4g1mT4G8kA6k62S+D4osgJPv7bLHoLlbxLzO+ETNMxuk2u4xKc62 vtTzhuf2ODw/bE2uf6qB5lIpXf8mMS0O/ROyhfg3a+wNXUrX1cScJQoA7RnLJIeKGN3w vHfzyas2/VMbuzlXL++EXE/Mi7fwHk2jXNtXg8W19lRTnckLpvnv2XaIovVIMVkq4m67 CiUxsOg/b7Rrz5H1K1k7V2FrgCoCpnoAw6AE23msEsnmG1jtpQ4hIZ2j0VPXk3XnKPn7 Iu2ja3f/YHcbDBvX8o8O4/MMxrcC3JiTrHRR/2QIvzJhr8tQIS8AkVnD463H10HBNqbS az5g==
X-Gm-Message-State: ANhLgQ3GiCxrzgE6hL871lQ8UdFDJvHl/096eiwLUKf4lWXqRAkMc06h lAETpfk5EzZsU+PxtL93Kq+G5sHuXFbFWTvdrMI=
X-Google-Smtp-Source: ADFU+vvoq3gL8pLVJBiueS8P3B1+Ezz3mbdDz57+PhgxS5Bu9RT+KUKHkneMSTU97QVb/Ot/TxIhK2ohsTd4TOG5ZlI=
X-Received: by 2002:a05:651c:445:: with SMTP id g5mr5010429ljg.125.1585227542197; Thu, 26 Mar 2020 05:59:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <33F93A5405A4C1CA6134F4C8@PSB>
In-Reply-To: <33F93A5405A4C1CA6134F4C8@PSB>
From: Spencer Dawkins at IETF <>
Date: Thu, 26 Mar 2020 07:58:36 -0500
Message-ID: <>
Subject: Re: NomCom eligibility & IETF 107
To: John C Klensin <>
Cc: Brian E Carpenter <>, "Salz, Rich" <>, Barry Leiba <>, IETF discussion list <>
Content-Type: multipart/alternative; boundary="0000000000008a7a3505a1c18c50"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2020 12:59:08 -0000

Top-posting to agree with Brian and John, that we should formally notify
the ISOC Board of Trustees on whatever the IESG thinks the community has
consensus on.

The last thing on earth that we need is a process appeal (that goes through
the IESG, IAB, and ISOC, because it's a process appeal) in the middle of
trying to seat a Nomcom and review positions. Of course, that can still
happen, but a crisp "we discussed this" would lessen the drama if it does.

And I don't actually care what we decide for this year's Nomcom, because
next year's Nomcom eligibility rules may need to be different, anyway.



On Wed, Mar 25, 2020 at 11:56 PM John C Klensin <> wrote:

> FWIW, I agree with Brian about the clarity of BCP 10 and this
> not being a situation in which we can say "Do the Right Thing",
> wave our hands a bit, and move on.
> I have one additional concern that I think needs to be part of
> this discussion.   Whether one believes that IETF 108 will
> occur, on schedule, f2f and with "normal" levels of attendance
> in Madrid (and similarly for IETF 109 in Bangkok), I hope we can
> agree that the likelihood of either meeting being virtual and/or
> low attendance is above zero.   In addition to making it clear
> who is eligible to volunteer for the nomcom, we need to figure
> out what guidance we should give people as to whether or not
> they should volunteer.   During the plenary discussions and on
> the mailing list earlier, I think I heard the current nomcom
> chair say things than I interpret as a belief that running a
> nomcom entirely virtually would be fairly easy.  I think I've
> heard others, including some previous nomcom chairs and members,
> suggest that it would be difficult and might create some
> complicated biases.  So, assume I were an IETF participant who
> would be eligible under any of the formulas now being considered
> (for the record, I'm not under any of them).  Assume, too, that
> I work for a company whose travel policies are subject to
> change, that have changed in the last month or three, and whose
> policies three or seven months from now are not reliably
> predictable.  Whether it is plausible or ethical for me to
> volunteer for the nomcom depends, not only on whether I'm
> eligible but on whether I have a reasonable expectation that, if
> either everyone is virtual or I'm remote from IETF 108 and/or
> 109 the nomcom chair and other nomcom members will be willing
> and able to accommodate that and work efficiently.
> I think the issues that go into that reasonable expectation had
> best be resolved on the same schedule as the eligibility issue.
> They might even influence Andrew and his appointment of a Nomcom
> chair because, like it or not, a Chair who is experienced and
> comfortable operating a process similar to the Nomcom with
> either a mix of f2f and several remote participants or everyone
> remote would considerably increase the chances for a process
> that runs smoothly and a volunteer pool that reflects the
> collection of effective IETF participants as much as reasonably
> possible.
> thanks,
>     john
> --On Thursday, March 26, 2020 16:10 +1300 Brian E Carpenter
> <> wrote:
> > On 26-Mar-20 12:54, Salz, Rich wrote:
> >> Err on the side of including people. Discount 107 for
> >> everyone.  BUT include it for those who signed bluesheets on
> >> more than one day.
> >
> > I think that actually amounts to varying the rule to 3/6, i.e.
> > 102-107 would all be considered.
> >
> > I certainly consider this worth discussing, although I don't
> > see why you say "bluesheets on more than one day" rather than
> > "more than one bluesheet." With such a reduced agenda, it
> > could easily happen that a person only considered one day of
> > interest. (Especially with many people having to deal with the
> > domestic chaos of a lockdown. I heard dogs and I heard kids
> > during today's sessions.)
> >
> > However, I'm concerned about the implications of potentially
> > contravening BCP10. It's a process BCP and we build a chain of
> > authority for those by having the ISOC Board take note of
> > them. And BCP10 is unambiguous in stating: (a) That various
> > things happen related to the First IETF each year. (b) That
> > eligibility requires 3/5 attendance at the moment of NomCom
> > selection, which normally means that the 5th of the 5
> > qualifying meetings is the First IETF of the year.
> >
> > Because of (a), it seems to me that the IESG needs to formally
> > assert that this week *is* the First IETF of 2020, and ask the
> > ISOC Board to take note.
> >
> > If you then want to make virtual attendance this week qualify,
> > the IESG would also need to assert the ad hoc definition of
> > attendance, and also ask the ISOC Board to take note.
> >
> > If you wanted to include 102 in the qualifying meetings, the
> > same applies, IMHO.
> >
> > I'm not sure which approach is best, but I am sure about it
> > needing a formal statement from the IESG which the ISOC Board
> > is informed about.
> >
> > (And before anyone asks, I do mean the ISOC Board. IETF LLC is
> > not in this particular loop, since it concerns the IETF
> > process, not its administration.)
> >
> > Regards
> >     Brian
> >