RE: Future adjustment of nomcom company limits (Was: Re: Nomcom 2019-2020: Result of random selection process)

Scott Mansfield <scott.mansfield@ericsson.com> Mon, 08 July 2019 18:49 UTC

Return-Path: <scott.mansfield@ericsson.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 9FB2912073A for <ietf@ietfa.amsl.com>; Mon, 8 Jul 2019 11:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 5ACXVqM0TH9V for <ietf@ietfa.amsl.com>; Mon, 8 Jul 2019 11:49:54 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740088.outbound.protection.outlook.com [40.107.74.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE67120702 for <ietf@ietf.org>; Mon, 8 Jul 2019 11:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bPIVH337eGZf/P10ZO7lMDhF1oew3DZUCkjs1Ra1knM=; b=V91wg04txI0UTWAnoKt1Aq8pyhqz/E99XDWPZLJYUJ+kqiz2ceyGjtcITsNAmNtCKlpJ/tgr88+9g2hoABf5JEldJ8jHITcMtykV6BjHkvdMs50PA3JBDFkIQ4ETXqgKeGGKhwjHn29b9oPnLeAa1BCVNDTsWGNA0mup1fY0pqE=
Received: from DM6PR15MB2379.namprd15.prod.outlook.com (20.176.69.16) by DM6PR15MB3708.namprd15.prod.outlook.com (10.141.166.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 18:49:12 +0000
Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::d8bb:1afb:5b32:2d6c]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::d8bb:1afb:5b32:2d6c%2]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 18:49:12 +0000
From: Scott Mansfield <scott.mansfield@ericsson.com>
To: Donald Eastlake <d3e3e3@gmail.com>
CC: Jari Arkko <jari.arkko@piuha.net>, Russ Housley <housley@vigilsec.com>, Bob Hinden <bob.hinden@gmail.com>, IETF <ietf@ietf.org>
Subject: RE: Future adjustment of nomcom company limits (Was: Re: Nomcom 2019-2020: Result of random selection process)
Thread-Topic: Future adjustment of nomcom company limits (Was: Re: Nomcom 2019-2020: Result of random selection process)
Thread-Index: AQHVNZydOi1PoGZaM0iFwg2uX1LunabAz3CQgAAqQwCAABP10A==
Date: Mon, 08 Jul 2019 18:49:12 +0000
Message-ID: <DM6PR15MB2379C3A88FF93297AD93B12A8BF60@DM6PR15MB2379.namprd15.prod.outlook.com>
References: <156251219263.14655.10883596601010032213.idtracker@ietfa.amsl.com> <F4669B2A-EEFA-4CAE-96D4-143434C3C6A3@vigilsec.com> <4fff1493-4bbc-283b-74c8-e43b5c0c7168@pi.nu> <CAJc3aaNTM-EZX_QfB5buuVhbzhsb0noQGw2QqnUcAf2Aev_Pew@mail.gmail.com> <16bd1276f58.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5C4BC50C-0153-460B-AA19-1EB7BD2CBA3B@cisco.com> <13C7C389-3587-4A44-8DE7-286606F92B57@gmail.com> <E1E7DBEB-1D8A-499D-9357-2FAAB1EB25E6@vigilsec.com> <3C4BF5C9-B3FD-4317-8F0A-2DCF6D0671E5@piuha.net> <DM6PR15MB23797B8E472CE41FF43E85078BF60@DM6PR15MB2379.namprd15.prod.outlook.com> <CAF4+nEFZxZDDj7oV6p4YXDxa-F=PeBuYynUixpt3aP=32Sz4_g@mail.gmail.com>
In-Reply-To: <CAF4+nEFZxZDDj7oV6p4YXDxa-F=PeBuYynUixpt3aP=32Sz4_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=scott.mansfield@ericsson.com;
x-originating-ip: [107.77.225.137]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13bd127e-3fdb-4a91-e1dd-08d703d4f840
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR15MB3708;
x-ms-traffictypediagnostic: DM6PR15MB3708:
x-microsoft-antispam-prvs: <DM6PR15MB370889E1CBB87A5F9EE8272C8BF60@DM6PR15MB3708.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00922518D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(30594003)(13464003)(189003)(51444003)(199004)(5660300002)(76116006)(73956011)(52536014)(8676002)(66446008)(99936001)(81166006)(186003)(14454004)(1411001)(6246003)(86362001)(66946007)(66616009)(476003)(81156014)(478600001)(64756008)(66476007)(66556008)(26005)(76176011)(55016002)(4326008)(6436002)(71200400001)(2906002)(44832011)(8936002)(25786009)(71190400001)(9686003)(66066001)(6506007)(7696005)(486006)(53546011)(6116002)(33656002)(99286004)(3846002)(229853002)(68736007)(54906003)(305945005)(316002)(446003)(53936002)(102836004)(7736002)(256004)(14444005)(74316002)(11346002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB3708; H:DM6PR15MB2379.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GonXk258xhDZNCbtBcUl0Tj0kAnPttEMyXTctIZ70uoHx4B+hBr7px4QhQtSZ8J5cWOiLDxyc2DPUDWxaShYKCdC9hJGYsHylGUTdEfzFKOox8b4Z4p7ntr48jxl7jcIuG2IIjfV/4p2H8UAjczUrxRj3czlE2MI5TukubCdI7x4HqMtrMn/AXObAh2fRUHnWtALLSqDjimzSRGY39hZrR8qj7miHGfap4wuDhHypZ4EL2mh3XNBK5u6JOHgNRC/wx+GWk8o8m5MHtawflnyRSeDns+E17s4CMC2wfFYQ+aq3fQqKGhWYigvrdr26a3bkXT84/bExLoEk/DDLCOjqex3jCUCOkZJulHGfhPm+OYXGsgKQT7DpEOBfaHNGrkpncUnwzHHaFHmCz8QvhhtyQBnPQ1LGeOvMIRWtgOfcM4=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00B3_01D5359C.4D4140B0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13bd127e-3fdb-4a91-e1dd-08d703d4f840
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 18:49:12.7397 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: scott.mansfield@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3708
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/AXRJjNIElExQE8n5eCWef_NCf08>
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: Mon, 08 Jul 2019 18:50:06 -0000

Peace.

Victor has made his decision and sent it to the list.  I accept it and thank the community for being passionate about process.

Regards,
-scott.

-----Original Message-----
From: Donald Eastlake <d3e3e3@gmail.com> 
Sent: Monday, July 8, 2019 1:28 PM
To: Scott Mansfield <scott.mansfield@ericsson.com>
Cc: Jari Arkko <jari.arkko@piuha.net>; Russ Housley <housley@vigilsec.com>; Bob Hinden <bob.hinden@gmail.com>; IETF <ietf@ietf.org>
Subject: Re: Future adjustment of nomcom company limits (Was: Re: Nomcom 2019-2020: Result of random selection process)

Hi Scott,

On Mon, Jul 8, 2019 at 11:12 AM Scott Mansfield <scott.mansfield@ericsson.com> wrote:
>
> I think (as the instigator of this issue) that..
>
> First off:  Need two terms clearly defined:
>
> Voting Volunteers
> Non-Voting Volunteers

I do not think that is correct wording. There are the volunteers to become voting members. There is no guarantee that anyone else is a "volunteer". Everyone else is appointed. Volunteers have all stepped forward. While it is possible that in some cases someone has expressed interest in doing the extra work of the non-voting appointed positions, I think that in most cases they get pointed at and they don't step back fast enough. It's very different.

I just looked up all occurrences of volunteer in RFC 7437 and there are only two uses: those who volunteer for voting membership in the nomcom and those who volunteer for positions for which the nomcom is finding candidates. I cannot find any case in RFC 7437 where a non-voting member of the nomcom is referred to as a volunteer.

> Voting Volunteers are already defined in 4.11.
> Non-Voting Volunteers are not precisely defined as a category/term but would include: NomCom Chair, Past Chair, Advisors, and Liaisons.
>
> The Nominating Committee is Voting Volunteers + Non-Voting Volunteers.
>
> So.  For the affiliation question.
>
> Current (the community seems to favor) that 4.17 is talking only about Voting Volunteers not the whole Nominating Committee.  So, section 4.17 should say that if that is what is desired.

Anything can be made clearer but I think 4.17 of RFC 7437 does say that. Any ambiguity in the first sentence of the 2nd paragraph of 4.17 is fixed by the algorithmic specification in the rest of the
paragraph:

      The Chair reviews the primary
   affiliation of each volunteer selected by the method in turn.  If the
   primary affiliation for a volunteer is the same as two previously
   selected volunteers, that volunteer is removed from consideration and
   the method is repeated to identify the next eligible volunteer.

That's the normative specification. "method" has been specified in the previous section as the method of selecting from among those volunteering to be voters. The word volunteer is not used anywhere in RC 7437 to refer to the appointed members of the nomcom. Informative text in an Oral Tradition appendix does not override this. Later in RFC 7437 it says

   A change in the primary affiliation of a voting volunteer during the
   term of the nominating committee is not a cause to request the recall
   of that volunteer, even if the change would result in more than two
   voting volunteers with the same affiliation.

which I think further clarifies that the limit is intended to apply only to voting members of the nomcom.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA  d3e3e3@gmail.com


> Using that interpretation, there currently is no hard number on affiliation affecting the Non-Voting Volunteers.  All that the current RFC has is Appendix B #5 (Oral Tradition) that "The number of nominating committee members with the same primary affiliation is limited in order to avoid the appearance of improper bias in choosing the leadership of the IETF."  So if that sentence is only talking about Voting members, then it should say that clearly.  Otherwise it is up to interpretation because some feel (well maybe just me) that when talking about "nominating committee members" we mean all nominating committee members not just voting members.
>
> So.  Just a bit of tweaking to clearly indicate what the community wants is in order.  Keep in mind that (I believe) we are arguing about this because we care about a fair playing field and all want the best results for the community.
>
> Regards,
> -scott.
>
> -----Original Message-----
> From: ietf <ietf-bounces@ietf.org> On Behalf Of Jari Arkko
> Sent: Monday, July 8, 2019 10:50 AM
> To: Russ Housley <housley@vigilsec.com>; Bob Hinden 
> <bob.hinden@gmail.com>
> Cc: IETF <ietf@ietf.org>
> Subject: Future adjustment of nomcom company limits (Was: Re: Nomcom 
> 2019-2020: Result of random selection process)
>
> Changing the subject line for everyone’s benefit, if we are discussing 
> RFC revisions :-)
>
> Bob, Russ:
>
> >> If RFC7437 is revised to include this, then that effort should consider the liaisons affiliations as well, not just the current and past chairs.
> >
> > Are the liaisons known from all bodies before the voting members are selected.  I know that they have not in the past.
>
> Russ’ point is one of those considerations to take into account if we make a change.
>
> But in addition, I think there’s a strategic question of how far one wants the needle to go. What’s the right answer? I have not been in Nomcom, but I think there’s a difference in the roles of liaisons, voting members, and chairs. Is the right answer to consider just the voting members, voting members + chair, voting members + chair + ex chair, or all of that + liaisons? It is not clear to _me_ what the right answer is, but it might be worth discussing that through before worrying too much about the mechanics and ordering of events.
>
> Jari
>