From nobody Sun Nov 12 09:25:11 2017 Return-Path: X-Original-To: ietf-nomcom@ietfa.amsl.com Delivered-To: ietf-nomcom@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CD6126B7F for ; Sun, 12 Nov 2017 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eh_La2cTavUD; Sun, 12 Nov 2017 09:25:09 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4DF12008A; Sun, 12 Nov 2017 09:25:09 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eDw0C-0002Zu-1j; Sun, 12 Nov 2017 12:25:00 -0500 Date: Sun, 12 Nov 2017 12:24:55 -0500 From: John C Klensin To: Stephen Farrell , "Salz, Rich" , Peter Yee cc: 'NomComDiscussion' , 'NomCom Chair 2017' Message-ID: <439F201200F4BC596F7A0343@JcK-HP5.jck.com> In-Reply-To: <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> 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 Archived-At: Subject: Re: [ietf-nomcom] Experiment in "full transparency" X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 17:25:11 -0000 Sorry for the slow response to this, but I've been preoccupied with other issues and more specific comments... --On Saturday, October 28, 2017 3:36 PM +0100 Stephen Farrell wrote: >... > The reason for this mail though is that I figure the utility of > the liaisons increases as the voting members are less > experienced IETFers. Highly experienced voting members could > likely get by with fewer liaisons, but if we're more likely to > have less experienced voting members the non-voting folks seem > to me to be a thing to be very careful about ditching, even if > 6/16 seems like a lot. I think this is true. At the same time, having liaisons present who explain "how things work" in the relevant bodies creates an inherent bias toward keeping them working that way, possibly as well as reinforcing some tendencies toward returning incumbents (if only in the interest of stability and continuity). Those are not necessarily bad things, but the Nomcom also has considerable responsibility for determining the strategic direction of the IETF (IAB included) by the choices it makes. That makes possible discussions along the lines of lines of "is that group doing what we want as a body (or even set of ADs) or is it time to seat a new group that will set new directions" important. Liaisons who represent, and are expected to advocate for, the incumbent body and its definition of what it should be doing are an impediment to such discussions even while they may provide useful insights. I have similar concerns about liaisons participating in interviews. Depending on dynamics within the leadership bodies (not just the one a particular liaison comes from) those liaisons may bring strong biases for or against an incumbent to the interview or reports to the rest of the Nomcom about the interview as well as insights into how an incumbent is or is not effective and how they play well with others. These are a tricky balances, both specifically and relative to the points you make, and I think the Nomcom should be sensitive them, and should have considerable flexibility about how liaisons are involved, what information they have access to, etc. best, john From nobody Sun Nov 12 14:26:53 2017 Return-Path: X-Original-To: ietf-nomcom@ietfa.amsl.com Delivered-To: ietf-nomcom@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803641267BB for ; Sun, 12 Nov 2017 14:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 cTEM6HUhclzO; Sun, 12 Nov 2017 14:26:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9722B1241FC; Sun, 12 Nov 2017 14:26:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBAE9BE49; Sun, 12 Nov 2017 22:26:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjIeyHqVHHtj; Sun, 12 Nov 2017 22:26:47 +0000 (GMT) Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0DDEABE2F; Sun, 12 Nov 2017 22:26:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510525607; bh=pSO2HNBlLQlKRAz0vbB8opgVnZsVKbcW1igKzSogBq4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tpvz/WGJuUje/J/y1nZpRtBF0IS5ioGYSIh/ro4k+5BgccrAfocwn3iS2ddKvm4mn uOJ5/EITN4AlRHtmv6spuo7fI9nBmySRofdnYPZ9LfXKycx+yambOZplQN7pTfhzx/ RjyI8Q52L3cgQ8TEYtTZdUXQjnSP29R3805RpsuY= To: John C Klensin , "Salz, Rich" , Peter Yee Cc: 'NomComDiscussion' , 'NomCom Chair 2017' References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4cdaa53e-b1cd-bfd4-304d-d3afdc3373bb@cs.tcd.ie> Date: Sun, 12 Nov 2017 22:26:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <439F201200F4BC596F7A0343@JcK-HP5.jck.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SqbKAmv9MRJ6l5i3dl3vlGiGnipbC0SNm" Archived-At: Subject: Re: [ietf-nomcom] Experiment in "full transparency" X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 22:26:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SqbKAmv9MRJ6l5i3dl3vlGiGnipbC0SNm Content-Type: multipart/mixed; boundary="QO4MwO6QQ13v0D79ujmL8CB1CaJWpRPva"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , "Salz, Rich" , Peter Yee Cc: 'NomComDiscussion' , 'NomCom Chair 2017' Message-ID: <4cdaa53e-b1cd-bfd4-304d-d3afdc3373bb@cs.tcd.ie> Subject: Re: [ietf-nomcom] Experiment in "full transparency" References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> In-Reply-To: <439F201200F4BC596F7A0343@JcK-HP5.jck.com> --QO4MwO6QQ13v0D79ujmL8CB1CaJWpRPva Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 12/11/17 17:24, John C Klensin wrote: > These are a tricky balances, both specifically and relative to > the points you make, and I think the Nomcom should be sensitive > them,=20 I pretty much agree about the existence of the pros and cons of non-voting nomcom members you and I mentioned. (I don't agree that liaisons are there to "advocate" though, but they could do that when asked for information of course so it's a fair point to consider.) > and should have considerable flexibility about how > liaisons are involved, what information they have access to, etc. I agree in theory with your last above, but I suspect it's not practical to have the nomcom voting members, likely as one of their early decisions, figure out what liaisons can and cannot see. Maybe some ex-nomcom chair might have ideas as to how that could be done and of the pros/cons of having differential access to nomcom data. (As of when I was on nomcom the tooling allowed anyone with access to that year's private key to see all of the comments etc and IIRC only the chair had additional buttons to press so more fine-grained access control would be a chunk of work to figure out.) I do fully agree though that nomcom voting members ought to be able to decide how they use liaisons, but I think that's already the case, other than the above access control issue. S. --QO4MwO6QQ13v0D79ujmL8CB1CaJWpRPva-- --SqbKAmv9MRJ6l5i3dl3vlGiGnipbC0SNm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCMqiAAoJEC88hzaAX42iQXYIAKhsktXpJvqzf9oZZqLt/dxG 7ghXk6uxl2E3c8u1L+V5mFE/b5rGRxvNSlGMsTxuVjNlbyEA+p28fdDc/bdiBmgL AXPLbakpPc/t2Y69v742kqjSzSmobuGsAnj3LgSNTk6AUVAILeHfk9lGP4wlejuY 3KuSA3tuszckJzCOeAFxObiZHv+TvgQeinBCIRupv4OFBxoKD9j7nFafwItEp3Oz ErcwxefpFNxAzkKASkTBK3Pg4vSPYEESwN8nsTjv5sXeIyZymLbBuXN2rRUmv+jX lhkWbgxxUep3Jmqg3VgrP7oAxVZAQ+31iscXillSyVH3BtXpnI7pP37H8gXtviU= =iHfe -----END PGP SIGNATURE----- --SqbKAmv9MRJ6l5i3dl3vlGiGnipbC0SNm-- From nobody Sun Nov 12 15:18:15 2017 Return-Path: X-Original-To: ietf-nomcom@ietfa.amsl.com Delivered-To: ietf-nomcom@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E1C12421A for ; Sun, 12 Nov 2017 15:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=eVBpohBp; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=XOMWhXCi 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 kGig8g0oK7SW for ; Sun, 12 Nov 2017 15:18:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20E1200CF for ; Sun, 12 Nov 2017 15:18:13 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.225.23.97]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id vACNHqMv009360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2017 15:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1510528684; x=1510615084; bh=4yjvuqHUT597mHwjrsrwtPkF+Cc5t3kUJfWwVC5ZerE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eVBpohBplQ9X7GrB+bbfmX1dkN9d/uKx8W4L6pxzTAUAOUk6PVUHAJlXNQyIHklvs FsLh7nH9kIfigc+XjFJpPwxyH8a7sI1DK5+Hs41QXgXnK05YTi0s5E8LxPOrxEcKNs wEfui+oT4gFzHdq1T+jcluBMyQ1C5lTQrfy4El5s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1510528684; x=1510615084; i=@elandsys.com; bh=4yjvuqHUT597mHwjrsrwtPkF+Cc5t3kUJfWwVC5ZerE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XOMWhXCi5Xg23SSZKFvrAOi6JLhXDjx1or7qJ6fpGvCziW4nf3bgBZHMcp1Qb1rlm ESH3ovHbGQIrykGzETfC2Dli3EbfCdCQVrSdyaSGsHt4+Hv1vqUcFSzOhbR0lVyOv7 xJFP9u24eFh9/YjzGC2fXf/wXVm79IQ7m8YdniVQ= Message-Id: <6.2.5.6.2.20171112150153.12178b90@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 12 Nov 2017 15:17:39 -0800 To: John C Klensin , ietf-nomcom@ietf.org From: S Moonesamy In-Reply-To: <439F201200F4BC596F7A0343@JcK-HP5.jck.com> References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [ietf-nomcom] Experiment in "full transparency" X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:18:14 -0000 Hi John, At 09:24 AM 12-11-2017, John C Klensin wrote: >I think this is true. At the same time, having liaisons present >who explain "how things work" in the relevant bodies creates an >inherent bias toward keeping them working that way, possibly as >well as reinforcing some tendencies toward returning incumbents >(if only in the interest of stability and continuity). It seems that it is not clear whether the non-member of NomCom serves as a liaison or an advisor. Is it up to the liaison to tell NomCom: "don't pay too much attention to what is written; this is how things actually work" and implying that it should be kept like that? >I have similar concerns about liaisons participating in >interviews. Depending on dynamics within the leadership bodies >(not just the one a particular liaison comes from) those >liaisons may bring strong biases for or against an incumbent to >the interview or reports to the rest of the Nomcom about the >interview as well as insights into how an incumbent is or is not >effective and how they play well with others. Is there a rationale for a liaison to participate in a NomCom interview? I don't have a strong opinion about whether where it causes a bias for or against an incumbent as it is up to NomCom members to make the decision(s). Regards, S. Moonesamy From nobody Sun Nov 12 15:31:28 2017 Return-Path: X-Original-To: ietf-nomcom@ietfa.amsl.com Delivered-To: ietf-nomcom@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAED1241F5 for ; Sun, 12 Nov 2017 15:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ebcLD5LJCML0 for ; Sun, 12 Nov 2017 15:31:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF5C1205F0 for ; Sun, 12 Nov 2017 15:31:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DACA4BE47; Sun, 12 Nov 2017 23:31:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkDUf2Y026WD; Sun, 12 Nov 2017 23:31:21 +0000 (GMT) Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 47D5ABDD8; Sun, 12 Nov 2017 23:31:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510529481; bh=mZUQ41BjPcpCnlraCxRupvStuDrB9DMweF3nIrwBiY8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XmTIROD8YfyAt7lqbpdwwJ/Cz2kOhk08V6DVPnR+6FsAIgm29EckGbPKbVx1sByl3 c7btvRDW+3EtZUsFlvnDWxpkyVB3aSCmRvh5pTeZqZlVBR4821ghL8g5j+xXv9+Xp1 x61kqKCUJZTSJQuwEoLt6Bt7cYXJCyaT2h+YcO+Q= To: S Moonesamy , John C Klensin , ietf-nomcom@ietf.org References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> <6.2.5.6.2.20171112150153.12178b90@elandnews.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 12 Nov 2017 23:31:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20171112150153.12178b90@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hISX9NBgkTKxuoO0GCnuRp9khErIufgSg" Archived-At: Subject: Re: [ietf-nomcom] Experiment in "full transparency" X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:31:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hISX9NBgkTKxuoO0GCnuRp9khErIufgSg Content-Type: multipart/mixed; boundary="XoIjpaNFLpPPGIC32f57vO2Gd7x1IT7Ut"; protected-headers="v1" From: Stephen Farrell To: S Moonesamy , John C Klensin , ietf-nomcom@ietf.org Cc: "Salz, Rich" Message-ID: Subject: Re: [ietf-nomcom] Experiment in "full transparency" References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> <6.2.5.6.2.20171112150153.12178b90@elandnews.com> In-Reply-To: <6.2.5.6.2.20171112150153.12178b90@elandnews.com> --XoIjpaNFLpPPGIC32f57vO2Gd7x1IT7Ut Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable FWIW, my take on your questions... On 12/11/17 23:17, S Moonesamy wrote: > Hi John, > At 09:24 AM 12-11-2017, John C Klensin wrote: >> I think this is true.=C2=A0 At the same time, having liaisons present >> who explain "how things work" in the relevant bodies creates an >> inherent bias toward keeping them working that way, possibly as >> well as reinforcing some tendencies toward returning incumbents >> (if only in the interest of stability and continuity). >=20 > It seems that it is not clear whether the non-member of NomCom serves a= s > a liaison or an advisor.=C2=A0 Is it up to the liaison to tell NomCom: = "don't > pay too much attention to what is written; this is how things actually > work" and implying that it should be kept like that? >=20 I think both liaison and advisor is right and yes I'd like that liaisons do make the kind of statement you quote above. I'd not like that liaisons try to direct what nomcom does and yes it could be a fine line to tread. >> I have similar concerns about liaisons participating in >> interviews.=C2=A0 Depending on dynamics within the leadership bodies >> (not just the one a particular liaison comes from) those >> liaisons may bring strong biases for or against an incumbent to >> the interview or reports to the rest of the Nomcom about the >> interview as well as insights into how an incumbent is or is not >> effective and how they play well with others. >=20 > Is there a rationale for a liaison to participate in a NomCom > interview?=C2=A0 I don't have a strong opinion about whether where it c= auses > a bias for or against an incumbent as it is up to NomCom members to mak= e > the decision(s). IIRC, it helped with logistics - 10 voting members trying to interview O(50) folks during the November IETF when they all have other stuff to do is hard to schedule, so having 5 or 6 more folks who can help in interviews, e.g. taking notes or ensuring that questions aren't forgotten/skipped seems to me to be useful. When I was the IESG's liaison I avoided any of the interviews for AD roles, and only sat in on one or maybe two of the other interviews, I think other liaisons helped out more. S. >=20 > Regards, > S. Moonesamy >=20 --XoIjpaNFLpPPGIC32f57vO2Gd7x1IT7Ut-- --hISX9NBgkTKxuoO0GCnuRp9khErIufgSg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCNnEAAoJEC88hzaAX42i6TcH/3byODB0WtwdiKU0aFe3RMfZ xD8B6/84JIFONr5/Y92UUH8aHepUoucfLj2b9p1CA1XOYduQXh/seyeFNuz5l55c zl5tBn8c5pLQ3B53EJOHAUbUXFe25USyRFR0ICRkuNmU71RBvZ8CMVfNHJWyrn9B R4q/ZAG+Y0DZWUgJMw2UV6QiSXNrahLHb6Awz1cFp6pFT0juddmxlYfFXeoXn2Mb 3hPTwlvnRZQuSNtm33AEYYSNPuYF35cA/oNfUTm65rd79WlSLvKR+XOEiD3OasiR 1AJKCDlyXETeNaUQOCc3ubykwAdwsa+Iy6Bo2wOKY9feZoiKm71gqo4Ywzvs2vw= =pKtb -----END PGP SIGNATURE----- --hISX9NBgkTKxuoO0GCnuRp9khErIufgSg-- From nobody Sun Nov 12 21:22:33 2017 Return-Path: X-Original-To: ietf-nomcom@ietfa.amsl.com Delivered-To: ietf-nomcom@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FF7127337 for ; Sun, 12 Nov 2017 21:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JwoTyc2ywIAZ for ; Sun, 12 Nov 2017 21:22:29 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CB2124D6C for ; Sun, 12 Nov 2017 21:22:29 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id q1so12523601ywh.5 for ; Sun, 12 Nov 2017 21:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yb73kCvw+qbrGVn39lVITzaaKt58oPiPGzov7bT0oXs=; b=AYRjsd0KY11yzJZf0eKyRVBMXtDWb41wSVUMCoKA2OspG9HpkJTWNdZO49C3hJTAmJ IVnmucUfryPLhVC0se9uIoo2jnyydbkrzEcJHczj2XvBU2ZB9wr8FXXe5yY2yJcyDt06 0R5zt003yBU9OfbWPggCXSy2OsYZLP7ZmdWrvL05BDvT8iuUXdXg6iC3bpY09bscqx82 MHxg3iJPn9uv8BhKWcqc1aDM0U1S5lzoMRUKcNRopdt2p3kKjdyMJxPjwNKFammD3zWW oCB3nKwnXBfTTJGfoc9Vc9ScVgOaGEC7tndxcxIfkeq5JcBtks1VjfFFoOLpDz8gmc5I /rng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yb73kCvw+qbrGVn39lVITzaaKt58oPiPGzov7bT0oXs=; b=XQzdtrJTC4jKYVDNNDcVcHRqUwMjtCxSsMKXjlj0QIJ+zqq4u5ZEfk9cFxhE5Uz9X1 qm5mVsIQucssN7CRL7QzD2dRqxhH6238AANWY+IUiCxeuzp3w8TtKw/j84/3uK6wBqh7 oU7fjn5vNCD6D+uNvgWEd6D0NS1ugz1ILgg6ymN/CicCabjh6xEJeQQ0lyOAIYrbRFPb qRu6JZTdSbFF69CQzGR6JsrjzFWv003PNuexMNP8jWXsy4NYN7mYhEkITiFYmAWNAE1X Qam3hRc+tgjM1Qc4mG4Pqss76S3Tcod0ksNGTaP2RupE/U6iyyExR4eueWtDgVeGosgP o/MA== X-Gm-Message-State: AJaThX5gnzRdEfp/DaOq6pkUMe/tPHz59sGcOmv11IVYFb7CiVivGTRw YoBjDl16gl8MfWuUulUPfQUUj77iKXHtHr4eOnc= X-Google-Smtp-Source: AGs4zMYfAYAftvQ2zB3tpf1pbi+pZwt9Fy6DS0sYnr8rKk9SDdabauPKnQFlzIQGaBdbR4ZmoBL+3TADBNeoHpDhNJQ= X-Received: by 10.37.252.17 with SMTP id v17mr1789961ybd.518.1510550548687; Sun, 12 Nov 2017 21:22:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.173.82 with HTTP; Sun, 12 Nov 2017 21:22:28 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com> <70A26384995DDC19DC8E2CAC@PSB> <09f301d34fb0$fe5925d0$fb0b7170$@akayla.com> <5c51ab08-13f7-0579-6d1e-4e73575c10e4@cs.tcd.ie> <439F201200F4BC596F7A0343@JcK-HP5.jck.com> <6.2.5.6.2.20171112150153.12178b90@elandnews.com> From: Spencer Dawkins at IETF Date: Mon, 13 Nov 2017 13:22:28 +0800 Message-ID: To: Stephen Farrell Cc: S Moonesamy , John C Klensin , NomCom-Discussion Content-Type: multipart/alternative; boundary="f403045da75cdeb190055dd67452" Archived-At: Subject: Re: [ietf-nomcom] Experiment in "full transparency" X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:22:32 -0000 --f403045da75cdeb190055dd67452 Content-Type: text/plain; charset="UTF-8" Just to top-post, I am reading this thread with interest. I talked with the IESG on Sunday morning about other Nomcom updates, and where we're headed, is toward a few more small updates - for instance, we've had a concern raised that having voting members drop out after the Nomcom is selected means that everyone knows who is "next" on the list of volunteers, and that's exploitable if you have any influence on a person selected as a voting member and like the "next" volunteer more. Some of the updates seem simple, but others are more complex - it turns out that IAB-IESG-IAOC moves are really a matrix, and one of the moves is in the BCP, but others are not. I'm reading the most recent round of 10,000-meter "are we doing the right thing?" discussion with interest. Where we ended up yesterday, was thinking that IASA 2.0 is potentially going to change what we ask Nomcom to review, so maybe we should wait to see what the future workload looks like. On the other hand, that's what were thinking, and it's not like no one ever grabs one or more ADs and says "are you NUTS?", and most of the names I've seen in these threads aren't shy about doing that. All this to say, thank you for your attention, and we'll be back. Spencer On Mon, Nov 13, 2017 at 7:31 AM, Stephen Farrell wrote: > > FWIW, my take on your questions... > > On 12/11/17 23:17, S Moonesamy wrote: > > Hi John, > > At 09:24 AM 12-11-2017, John C Klensin wrote: > >> I think this is true. At the same time, having liaisons present > >> who explain "how things work" in the relevant bodies creates an > >> inherent bias toward keeping them working that way, possibly as > >> well as reinforcing some tendencies toward returning incumbents > >> (if only in the interest of stability and continuity). > > > > It seems that it is not clear whether the non-member of NomCom serves as > > a liaison or an advisor. Is it up to the liaison to tell NomCom: "don't > > pay too much attention to what is written; this is how things actually > > work" and implying that it should be kept like that? > > > > I think both liaison and advisor is right and yes I'd like that > liaisons do make the kind of statement you quote above. I'd not > like that liaisons try to direct what nomcom does and yes it > could be a fine line to tread. > > >> I have similar concerns about liaisons participating in > >> interviews. Depending on dynamics within the leadership bodies > >> (not just the one a particular liaison comes from) those > >> liaisons may bring strong biases for or against an incumbent to > >> the interview or reports to the rest of the Nomcom about the > >> interview as well as insights into how an incumbent is or is not > >> effective and how they play well with others. > > > > Is there a rationale for a liaison to participate in a NomCom > > interview? I don't have a strong opinion about whether where it causes > > a bias for or against an incumbent as it is up to NomCom members to make > > the decision(s). > > IIRC, it helped with logistics - 10 voting members trying to > interview O(50) folks during the November IETF when they all > have other stuff to do is hard to schedule, so having 5 or > 6 more folks who can help in interviews, e.g. taking notes or > ensuring that questions aren't forgotten/skipped seems to me > to be useful. When I was the IESG's liaison I avoided any of > the interviews for AD roles, and only sat in on one or maybe > two of the other interviews, I think other liaisons helped > out more. > > S. > > > > > Regards, > > S. Moonesamy > > > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > --f403045da75cdeb190055dd67452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to top-post, I am reading this thread with interest.= =C2=A0

I talked with the IESG on Sunday morning about ot= her Nomcom updates, and where we're headed, is toward a few more small = updates - for instance, we've had a concern raised that having voting m= embers drop out after the Nomcom is selected means that everyone knows who = is "next" on the list of volunteers, and that's exploitable i= f you have any influence on a person selected as a voting member and like t= he "next" volunteer more.

Some of the up= dates seem simple, but others are more complex - it turns out that IAB-IESG= -IAOC moves are really a matrix, and one of the moves is in the BCP, but ot= hers are not.=C2=A0

I'm reading the most recen= t round of 10,000-meter "are we doing the right thing?" discussio= n with interest. Where we ended up yesterday, was thinking that IASA 2.0 is= potentially going to change what we ask Nomcom to review, so maybe we shou= ld wait to see what the future workload looks like. On the other hand, that= 's what were thinking, and it's not like no one ever grabs one or m= ore ADs and says "are you NUTS?", and most of the names I've = seen in these threads aren't shy about doing that.

=
All this to say, thank you for your attention, and we'll be back.<= /div>

Spencer

On Mon, Nov 13, 2017 at 7:31 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

FWIW, my take on your questions...

On 12/11/17 23:17, S Moonesamy wrote:
> Hi John,
> At 09:24 AM 12-11-2017, John C Klensin wrote:
>> I think this is true.=C2=A0 At the same time, having liaisons pres= ent
>> who explain "how things work" in the relevant bodies cre= ates an
>> inherent bias toward keeping them working that way, possibly as >> well as reinforcing some tendencies toward returning incumbents >> (if only in the interest of stability and continuity).
>
> It seems that it is not clear whether the non-member of NomCom serves = as
> a liaison or an advisor.=C2=A0 Is it up to the liaison to tell NomCom:= "don't
> pay too much attention to what is written; this is how things actually=
> work" and implying that it should be kept like that?
>

I think both liaison and advisor is right and yes I'd like that<= br> liaisons do make the kind of statement you quote above. I'd not
like that liaisons try to direct what nomcom does and yes it
could be a fine line to tread.

>> I have similar concerns about liaisons participating in
>> interviews.=C2=A0 Depending on dynamics within the leadership bodi= es
>> (not just the one a particular liaison comes from) those
>> liaisons may bring strong biases for or against an incumbent to >> the interview or reports to the rest of the Nomcom about the
>> interview as well as insights into how an incumbent is or is not >> effective and how they play well with others.
>
> Is there a rationale for a liaison to participate in a NomCom
> interview?=C2=A0 I don't have a strong opinion about whether where= it causes
> a bias for or against an incumbent as it is up to NomCom members to ma= ke
> the decision(s).

IIRC, it helped with logistics - 10 voting members trying to
interview O(50) folks during the November IETF when they all
have other stuff to do is hard to schedule, so having 5 or
6 more folks who can help in interviews, e.g. taking notes or
ensuring that questions aren't forgotten/skipped seems to me
to be useful. When I was the IESG's liaison I avoided any of
the interviews for AD roles, and only sat in on one or maybe
two of the other interviews, I think other liaisons helped
out more.

S.

>
> Regards,
> S. Moonesamy
>


_______________________________________________
ietf-nomcom mailing list
ietf-nomcom@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-nom= com


--f403045da75cdeb190055dd67452--