From nobody Wed Aug 2 14:30:56 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 1C0EA131838 for ; Wed, 2 Aug 2017 14:30:55 -0700 (PDT) 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 unhgsVmlVbB7 for ; Wed, 2 Aug 2017 14:30:53 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 915E313218D for ; Wed, 2 Aug 2017 14:30:42 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l82so37013851ywc.2 for ; Wed, 02 Aug 2017 14:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=HjXVBD6UuBhq/EwbTzurGi4TElLr15oTzrv7mmj8h20=; b=H7ep+eaNKFpZpzgO6E+XHKYq+1brX3eV3YmTveFH+d+v+f1wFgrg/GDDBuH/sXyfBY g9zPxO5NBg2+obDLc7Vbhtn05xncDor6FcbvQARQ2SiKRs6NMhh/sCb+4xYz0sdyv3fV 5IEegpir0TEJI5oFN5Zi55pnxD9SL8elqvEgHu8jgeVzqvG+wTcPB7G0Hz7arB639zjd hevXzG+g2iwyTt1uUw8bJvJ4zL5sr9YN7Nwl0ybsdHMQZKm3aK6UohWu1lyx81r3T2qM wtCxAMFZvKVeS1Qz5ca/MVKxLnA7usZ389Nn/AL5YVe0WoLaoodzHQURrkNeSIgQKFbm l4UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=HjXVBD6UuBhq/EwbTzurGi4TElLr15oTzrv7mmj8h20=; b=jify7WlFwglBFjvGm72y7D4qoodIFtZ4XVQCCt64RTxZwMdWEFwu0yN0TUO2YIvadc o58dtvegH7ChthjSQIYVmYJJgYZwvPQHqWgatxroJfamxpwnkJp2ABfPio1Up0k5n48V zruMm1AhPLiBCAXXLSwBEAKruCcNAUY9iBKoCwwcakaWxNj3XOx2uQLdl7q9LpEgFXVB jXt5l3hHJQBEqEAbTjWvVIBxdFooe155Kzxcst5TdOfO66R3Sl7gDRtk+3mh3PuWKLgA pXFXvODCyDu5ZDtql4WHT/f2CE0B11P6l4kL41bNXx/OJTTPRKPOgEPUBssKkv6ZI3Mv q6Qw== X-Gm-Message-State: AIVw1116KoydH4UKStYBLpAzf1eJlb90aJgzFWEuQl+DfiHj26UEe6PY Vv3qjlnZPkLNGmOOVQIHB1XnmJAXZw== X-Received: by 10.37.36.14 with SMTP id k14mr7755877ybk.211.1501709441474; Wed, 02 Aug 2017 14:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 2 Aug 2017 14:30:41 -0700 (PDT) From: Spencer Dawkins at IETF Date: Wed, 2 Aug 2017 16:30:41 -0500 Message-ID: To: NomCom-Discussion Cc: Alexey Melnikov Content-Type: multipart/alternative; boundary="001a113d4580d0a9a70555cbf94b" Archived-At: Subject: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Wed, 02 Aug 2017 21:30:55 -0000 --001a113d4580d0a9a70555cbf94b Content-Type: text/plain; charset="UTF-8" Dear Nomcom Process Devotees, Alissa has asked me to put together a short(!) draft that will remind future Nomcoms to request IAOC to provide an Advisor. Details are below. I'd like to discuss this draft on this mailing list initially. Please comment and question as appropriate. Thanks, Spencer ---------- Forwarded message ---------- From: Date: Wed, Aug 2, 2017 at 4:27 PM Subject: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt To: Spencer Dawkins A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt has been successfully submitted by Spencer Dawkins and posted to the IETF repository. Name: draft-dawkins-iesg-nomcom-advisor-iaoc Revision: 00 Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee Document date: 2017-08-02 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg- nomcom-advisor-iaoc-00.txt Status: https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomcom- advisor-iaoc/ Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom- advisor-iaoc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg- nomcom-advisor-iaoc-00 Abstract: This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee about the operations of the IETF Administrative Oversight Committee. This document updates RFC 7437. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113d4580d0a9a70555cbf94b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nomcom Process Devotees,

Alissa ha= s asked me to put together a short(!) draft that will remind future Nomcoms= to request IAOC to provide an Advisor.

Details ar= e below.

I'd like to discuss this draft on thi= s mailing list initially.

Please comment and quest= ion as appropriate.

Thanks,

Spencer

---------- F= orwarded message ----------
From: <internet-dra= fts@ietf.org>
Date: Wed, Aug 2, 2017 at 4:27 PM
Subject= : New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.tx= t
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>



A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt has been successfully submitted by Spencer Dawkins and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dawkins-iesg-nomcom-advisor-iaoc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB, IESG, and IAOC Selection, Con= firmation, and Recall Process: IAOC Advisor for the Nominating Committee Document date:=C2=A0 2017-08-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft= -dawkins-iesg-nomcom-advisor-iaoc-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomco= m-advisor-iaoc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-adviso= r-iaoc-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-dawkins-ies= g-nomcom-advisor-iaoc-00


Abstract:
=C2=A0 =C2=A0This specification formalizes an ad hoc practice used to provi= de
=C2=A0 =C2=A0advice to the IETF Nominating Committee about the operations o= f the
=C2=A0 =C2=A0IETF Administrative Oversight Committee.

=C2=A0 =C2=A0This document updates RFC 7437.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a113d4580d0a9a70555cbf94b-- From nobody Wed Aug 2 16:05:27 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 5EB36129B35 for ; Wed, 2 Aug 2017 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 (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 MvgxJ2WuARLC for ; Wed, 2 Aug 2017 16:05:23 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 9450B131C89 for ; Wed, 2 Aug 2017 16:05:23 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id t86so26543756pfe.2 for ; Wed, 02 Aug 2017 16:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Mjyl0J+LhcqgkwLES2cBvXI78ioD5PTzfyGQst41PXE=; b=h4YcrCBo0ZZLbVMzN3hfIrDB/T1J/bMu3bnJZV0woLQ8ppazzLLA6BY6P7aH+u5XVE kbYshsnqTilKKca5dfUB6hGF2Wc81k5CLDxfXM9+26ipBXjl2eit2YULJK4HveqXSj0R 15T1G4eiWMClMXqHA3nBkVUV1OWB5NkT/Ix8/UPxTcXSFdM5hxE3zIv3Xzn/Zw6mQJiA v0xwsViy8dTw9Z9imTOEyJ0eLZ+HDyJTqxfwlkOQoLknQhtbEW9CzCoQ5XVFOtEORg7m Jq3YKtDKzqvrJArFWS+NBHmuxJBj8Hrk6SW0migxYNXPpzpNq/rNj4KCkOE39ZruiW7P rB0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Mjyl0J+LhcqgkwLES2cBvXI78ioD5PTzfyGQst41PXE=; b=OE7g8uUdW2Z3qKowkSZ3nFj6pxldtHOYQGDEeItsUox7sm69f3wW/2tAzPwBSIqXLN ltlsq7ejzn8BYiQBiQYOFKqIn6cO341aOcuEgzJWF18rr9hl1Q1ib4L854zSKzjachaL uBxKLmYTPUoCzLy7EjiHQ5Y7Xdxw6bZmL+RlG2QryxyYXHMhuqEOdG8pQeiiy1Nen9bN ktex0if0JtoYNsZ0LGrxa+V4AaH6RGcIbKCwpGJQQh0kVh8kpv94aKPbaq7aN/V1pD6U /2ByecddtomuQ+4SYrI5wGx3Mw7i+yAwmlZatCK7XQJF2/rlzSn9Jws/r5ZscFntDcf4 rF7w== X-Gm-Message-State: AIVw1114nZWuhTI828TuemKtVOq31lp+/QFFUky0bfEnN9e7ibmt0+kB 0QwkJq1PNifkfbWa X-Received: by 10.99.95.71 with SMTP id t68mr25056826pgb.353.1501715122948; Wed, 02 Aug 2017 16:05:22 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 206sm4374338pfc.61.2017.08.02.16.05.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 16:05:22 -0700 (PDT) To: ietf-nomcom@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <04007555-40fc-4fb8-10b5-ecdfd7d9c703@gmail.com> Date: Thu, 3 Aug 2017 11:05:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Wed, 02 Aug 2017 23:05:25 -0000 On 03/08/2017 09:30, Spencer Dawkins at IETF wrote: > Dear Nomcom Process Devotees, > > Alissa has asked me to put together a short(!) draft that will remind > future Nomcoms to request IAOC to provide an Advisor. > > Details are below. > > I'd like to discuss this draft on this mailing list initially> > Please comment and question as appropriate. It's a good idea. In fact it's so obviously a good idea that I'm not sure it needs as much rationale as you've included; personally I'd be happy with just section 6 plus boilerplate. But the rationale does no harm. Regards Brian > > Thanks, > > Spencer > > ---------- Forwarded message ---------- > From: > Date: Wed, Aug 2, 2017 at 4:27 PM > Subject: New Version Notification for > draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > To: Spencer Dawkins > > > > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > has been successfully submitted by Spencer Dawkins and posted to the > IETF repository. > > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > Revision: 00 > Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall > Process: IAOC Advisor for the Nominating Committee > Document date: 2017-08-02 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg- > nomcom-advisor-iaoc-00.txt > Status: https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomcom- > advisor-iaoc/ > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom- > advisor-iaoc-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg- > nomcom-advisor-iaoc-00 > > > Abstract: > This specification formalizes an ad hoc practice used to provide > advice to the IETF Nominating Committee about the operations of the > IETF Administrative Oversight Committee. > > This document updates RFC 7437. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From nobody Wed Aug 2 16:12:36 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 D23131321A4 for ; Wed, 2 Aug 2017 16:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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 2pyk0JbDgYYH for ; Wed, 2 Aug 2017 16:12:32 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0078.outbound.protection.outlook.com [104.47.37.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDD71321A0 for ; Wed, 2 Aug 2017 16:12:32 -0700 (PDT) Received: from SN2PR07MB2558.namprd07.prod.outlook.com (10.167.15.12) by SN2PR07MB2560.namprd07.prod.outlook.com (10.167.15.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Wed, 2 Aug 2017 23:12:31 +0000 Received: from SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) by SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) with mapi id 15.01.1304.023; Wed, 2 Aug 2017 23:12:31 +0000 From: "Bradner, Scott" To: Spencer Dawkins at IETF CC: NomCom-Discussion , Alexey Melnikov Thread-Topic: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt Thread-Index: AQHTC+TQdPkq+uwYk0CRXPAjOuAqAQ== Date: Wed, 2 Aug 2017 23:12:31 +0000 Message-ID: <8A190D84-BCBC-4C42-94A2-4DC2603A25EC@harvard.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sob@harvard.edu; x-originating-ip: [136.248.127.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR07MB2560; 7:LMOSBekjsUBvYZPKNYGfhtc5quW1IdjVMeYsbNsq2Q3GkM6gNz7HQCZC8+c40+PgRWoKhgLUatBLyqoorLkvkc79B+eAMMkf/xe5g2YeKAvb4d3w6i2GVYvNgvMTluZVVzYEoKtQxN7rm+Ls/Dk31pMn/l9AhvnYYt6BZTs9qIEYrpKNNvJYq9RQvt0WGD/Dr+fnPJKVe6E47NoCcPomSRNhL59une78b4QF++MlEK516hB8YVB2IhCf+nyQ1s6FcZgIr0BUckBX555ujlYUzyArwhN5f6S5tMLuVI7DwhNMjLbwF+SPkWvG6UtwQSWwN62HB/yJPRoUdCViGstWbSWyeb0Xa+62t+uSpCU71IBuLbfFw//mBikBnZTSd83GvN0fBK+6MmPiRgwWirksssVGoQLFDj65SoYJeiNWmZqCyPvkWhav5xwrkqtCArpQQXdqhc5aCXTPdJ5iRNVT8xSTXTezfzGs8Keo/0CsoFANNZOTI3c38w26gz86HkgXliooVqTkds0EBpCnk074KmYO3Vg2mGLyqpyyH+PeMhGw6EWOd4IVHxCVbRNo/srBE4rNa9hsS14i7DZhQjWwiIeKQl7iWLcFUsCJzXW83+PUsmyf7zbHKhfNXO5mC8bZmfOgaLJh0Sf0m+E8MH/MH58orTrKftOHRZeGPSjDqX42u0bbby3wWjxCl38FH4QtBIJWbZ/zNoXoiQM1aI8BJNIIjWIIgwqSvtlyF6199Rg2Pt4XzVZr9s9XSJkZ1gzIThSGrgXMEOnzMlZrOo4Bdssbo5XFKVeGQYc70PXJc9w= x-ms-office365-filtering-correlation-id: d94aa8f3-faae-4eec-1f61-08d4d9fbf3bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR07MB2560; x-ms-traffictypediagnostic: SN2PR07MB2560: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR07MB2560; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR07MB2560; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39410400002)(39450400003)(39840400002)(39850400002)(39400400002)(377454003)(189002)(377424004)(24454002)(199003)(88552002)(5660300001)(3846002)(3280700002)(2906002)(3660700001)(15650500001)(6486002)(38730400002)(81166006)(81156014)(8676002)(82746002)(230783001)(305945005)(7736002)(8936002)(77096006)(39060400002)(53936002)(110136004)(102836003)(83716003)(68736007)(6506006)(6116002)(86362001)(66066001)(6246003)(36756003)(229853002)(105586002)(8666007)(99286003)(2950100002)(6916009)(101416001)(189998001)(54906002)(54356999)(76176999)(97736004)(50986999)(2900100001)(6512007)(33656002)(106356001)(6306002)(53546010)(25786009)(4326008)(478600001)(966005)(6436002)(75432002)(14454004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2560; H:SN2PR07MB2558.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: harvard.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 23:12:31.4708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2560 Archived-At: Subject: Re: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Wed, 02 Aug 2017 23:12:35 -0000 seems well thought out to me Scott > On Aug 2, 2017, at 5:30 PM, Spencer Dawkins at IETF wrote: >=20 > Dear Nomcom Process Devotees, >=20 > Alissa has asked me to put together a short(!) draft that will remind fut= ure Nomcoms to request IAOC to provide an Advisor. >=20 > Details are below. >=20 > I'd like to discuss this draft on this mailing list initially. >=20 > Please comment and question as appropriate. >=20 > Thanks, >=20 > Spencer >=20 > ---------- Forwarded message ---------- > From: > Date: Wed, Aug 2, 2017 at 4:27 PM > Subject: New Version Notification for draft-dawkins-iesg-nomcom-advisor-i= aoc-00.txt > To: Spencer Dawkins >=20 >=20 >=20 > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > has been successfully submitted by Spencer Dawkins and posted to the > IETF repository. >=20 > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > Revision: 00 > Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall P= rocess: IAOC Advisor for the Nominating Committee > Document date: 2017-08-02 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg-n= omcom-advisor-iaoc-00.txt > Status: https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomco= m-advisor-iaoc/ > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-adv= isor-iaoc-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg-= nomcom-advisor-iaoc-00 >=20 >=20 > Abstract: > This specification formalizes an ad hoc practice used to provide > advice to the IETF Nominating Committee about the operations of the > IETF Administrative Oversight Committee. >=20 > This document updates RFC 7437. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From nobody Thu Aug 3 02:09:23 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 218D1131D1A for ; Thu, 3 Aug 2017 02:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Tt9DA12epA7z for ; Thu, 3 Aug 2017 02:09:19 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE84132325 for ; Thu, 3 Aug 2017 02:09:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v73997PK015671; Thu, 3 Aug 2017 10:09:07 +0100 Received: from 950129200 (25.70.114.87.dyn.plus.net [87.114.70.25]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v73995g4015636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Aug 2017 10:09:06 +0100 Reply-To: From: "Adrian Farrel" To: "'Spencer Dawkins at IETF'" , "'NomCom-Discussion'" Cc: "'Alexey Melnikov'" References: In-Reply-To: Date: Thu, 3 Aug 2017 10:09:04 +0100 Message-ID: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014C_01D30C40.8A102330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpdmMQO+1Mp9RZkzaXlaoCeayn16LFfltw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23234.005 X-TM-AS-Result: No--26.882-10.0-31-10 X-imss-scan-details: No--26.882-10.0-31-10 X-TMASE-MatchedRID: vWvnoyq7eMxbJCKOm3VRCaj5v7I4/SgYIZnpVU5Vh5bDWyVjzEqpvGKH pZv+RSYvnhLJWEjAGHPtP6Pv+A+w8w/80a3o2lzSIFBEE5CFomIiBIwVnqqixZAKUibQNUrS1/5 Upb6/94i8IKanJHvnZm7hbmASKcrp/auzApmkedEwEhHW5KVAzxH6y9a7QCl/QLhNmgIRxg5W3Z WqiXYbmIn3uZMbLHbFQs0ueGZxVcNBXoFkn1Z4Vt3HBFohOctM0+QbBcjoBewGEn2iDG04tq+zL yPWlXeQjlL/hujrw1tDfxQ/WK0M/Lebfccgl9iNTuOOxH2rT/HS7l9oY/zO1JJ8xD5rV15ZItI8 7B4WWSIPjOdXhbMBrmMdYzySsvg8j/xLIaDSshHIvQIyugvKdXmd+25VkQszygAO5QccC3iyn7R Jlv/chozrT6Ke+UlrT7jCYv2QJPGHxi2fvkKUM/Q1K5DO1u1D0L2eqCmMq5beqxAOXbCz6Yxj2g ynNQ8jPvm9QgHL9uBwUSK4/EeOxSOSuAnftGqPjNnoU1fopotpgrYvic2QdZ6Ss6O2bihGoEzCi UbLtjyRGA23JsTa34Dqq/69HfgsA7f8DkoYc/90PA/ki2kI7EtU4/pKr/obDsbtrO33TVeLFgnz +hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEozraubH2nx6gF+AN4QjuBe5QR mIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBeP7GAQSe5/nfbBROhn2OIGPC7j/m zpDFqfL6D8TtOZrM87s4OnYGuCwXotg6ps9+GbKItl61J/yZUdXE/WGn0FSlnU38LCY8u1MF0/q NNIN9bkrsq6X+UeRRgndEtDQrKhT7kHV6Dixgu0JaBoEGMYtF8LMRoB0lrI+LKKOeOaBJRMZUCE HkRt Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 09:09:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014C_01D30C40.8A102330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Spencer, =20 Thanks for this work. Will help the whole thing go better. =20 My gut feeling is to be nervous about "an advisor who is knowledgeable = about IAOC operations" but not actually serving on the IAOC is that the = input and feedback about the operation, direction, and needs of the = *current* IAOC may be significantly skewed. =20 You would not, I think, suggest that the advisory part of the role of = the IESG liaison could be filled by a non-serving person. =20 I do understand that you are trying to find a way in which the advisor = is not selected from a pool of one. But that might be a price that is = not worth paying. =20 Anyway, I see the IAOC made up as: =20 - appointed by NomCom for 2 years (odd year) - appointed by NomCom for 2 years (even year) - appointed by the IESG for 2 years (even year) - appointed by the IAB for 2 years (odd year) - appointed by the ISOC Board of Trustees for two years (even year) - ISOC President/CEO (ex officio) (annual) - IETF Chair (ex officio) (two year cycle, odd year) - IAB Chair (ex officio) -(annual) - IAD (non-voting) (annual) =20 It is debatable whether you would want any of the bottom four to be the = advisor although I note that you haven't excluded them in your text. I assume that you do not want a candidate to be the advisor (and maybe = you should explicitly make that point?). Obviously outgoing (i.e., standing down) members could be the advisor. So in odd years you appear to have a choice of at least 3 members = (possibly more if someone plans to stand down). And in even years you appear to have a choice of at least 2 members = (possibly more if someone plans to stand down). =20 I consider that preferable to allowing the IAOC to send someone who = might not have the right reading of the current dynamic. =20 It should not be the case that this advisor role is a significant = additional burden on the workload. =20 Thanks, Adrian =20 From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of = Spencer Dawkins at IETF Sent: 02 August 2017 22:31 To: NomCom-Discussion Cc: Alexey Melnikov Subject: [ietf-nomcom] Fwd: New Version Notification for = draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt =20 Dear Nomcom Process Devotees, =20 Alissa has asked me to put together a short(!) draft that will remind = future Nomcoms to request IAOC to provide an Advisor. =20 Details are below. =20 I'd like to discuss this draft on this mailing list initially. =20 Please comment and question as appropriate. =20 Thanks, =20 Spencer =20 ---------- Forwarded message ---------- From: Date: Wed, Aug 2, 2017 at 4:27 PM Subject: New Version Notification for = draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt To: Spencer Dawkins A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt has been successfully submitted by Spencer Dawkins and posted to the IETF repository. Name: draft-dawkins-iesg-nomcom-advisor-iaoc Revision: 00 Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall = Process: IAOC Advisor for the Nominating Committee Document date: 2017-08-02 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-dawkins-iesg-nomcom-advisor-ia= oc-00.txt Status: = https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomcom-advisor-iaoc/ Htmlized: = https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-advisor-iaoc-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-dawkins-iesg-nomcom-advisor-i= aoc-00 Abstract: This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee about the operations of the IETF Administrative Oversight Committee. This document updates RFC 7437. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =20 ------=_NextPart_000_014C_01D30C40.8A102330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey = Spencer,

 

Thanks for this work. Will = help the whole thing go better.

 

My gut feeling is to be = nervous about "an advisor who is knowledgeable about IAOC = operations" but not actually serving on the IAOC is that the input = and feedback about the operation, direction, and needs of the *current* = IAOC may be significantly skewed.

 

You would not, I think, = suggest that the advisory part of the role of the IESG liaison could be = filled by a non-serving person.

 

I do understand that you are = trying to find a way in which the advisor is not selected from a pool of = one. But that might be a price that is not worth = paying.

 

Anyway, I see the IAOC made up = as:

 

- appointed by NomCom for 2 = years (odd year)

- appointed by NomCom for 2 = years (even year)

- appointed by the IESG for 2 = years (even year)

- appointed by the IAB for 2 = years (odd year)

- appointed by the ISOC Board = of Trustees for two years (even year)

- ISOC President/CEO (ex = officio) (annual)

- IETF Chair (ex officio) (two = year cycle, odd year)

- IAB Chair (ex officio) = -(annual)

- IAD (non-voting) = (annual)

 

It is debatable whether you = would want any of the bottom four to be the advisor although I note that = you haven't excluded them in your text.

I assume that you do not want = a candidate to be the advisor (and maybe you should explicitly make that = point?).

Obviously outgoing (i.e., = standing down) members could be the advisor.

So in odd years you appear to = have a choice of at least 3 members (possibly more if someone plans to = stand down).

And in even years you appear = to have a choice of at least 2 members (possibly more if someone plans = to stand down).

 

I consider that preferable to = allowing the IAOC to send someone who might not have the right reading = of the current dynamic.

 

It should not be the case that = this advisor role is a significant additional burden on the = workload.

 

Thanks,

Adrian

 

From: ietf-nomcom = [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of Spencer = Dawkins at IETF
Sent: 02 August 2017 22:31
To: = NomCom-Discussion
Cc: Alexey Melnikov
Subject: = [ietf-nomcom] Fwd: New Version Notification for = draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt

=

 

Dear Nomcom Process Devotees,

 

Alissa has asked me to put together a short(!) draft = that will remind future Nomcoms to request IAOC to provide an = Advisor.

 

Details are below.

 

I'd like to discuss this draft on this mailing list = initially.

 

Please comment and question as = appropriate.

 

Thanks,

 

Spencer

 

---------- Forwarded = message ----------
From: <internet-drafts@ietf.org>=
Date: Wed, Aug 2, 2017 at 4:27 PM
Subject: New Version = Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
To: = Spencer Dawkins <spencerdawkins.ietf@gmail.c= om>



A new version of I-D, = draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
has been successfully = submitted by Spencer Dawkins and posted to the
IETF = repository.

Name:          =  draft-dawkins-iesg-nomcom-advisor-iaoc
Revision:    =    00
Title:          IAB, IESG, = and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for = the Nominating Committee
Document date:  = 2017-08-02
Group:          Individual = Submission
Pages:          6
URL:  =           https://www.ietf.org/internet-drafts/draft-dawkins-iesg= -nomcom-advisor-iaoc-00.txt
Status:        =  https://datatracker.ietf.org/doc/draft-dawkins-iesg-nom= com-advisor-iaoc/
Htmlized:       https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-a= dvisor-iaoc-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-ies= g-nomcom-advisor-iaoc-00


Abstract:
   This = specification formalizes an ad hoc practice used to provide
  =  advice to the IETF Nominating Committee about the operations of = the
   IETF Administrative Oversight = Committee.

   This document updates RFC = 7437.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF = Secretariat

 

------=_NextPart_000_014C_01D30C40.8A102330-- From nobody Thu Aug 3 03:40:47 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 BA3E7131D6B for ; Thu, 3 Aug 2017 03:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 YDHDS2jLh2Fs for ; Thu, 3 Aug 2017 03:40:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0068.outbound.protection.outlook.com [104.47.42.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BAC131D2C for ; Thu, 3 Aug 2017 03:40:42 -0700 (PDT) Received: from SN2PR07MB2558.namprd07.prod.outlook.com (10.167.15.12) by SN2PR07MB2558.namprd07.prod.outlook.com (10.167.15.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 10:40:42 +0000 Received: from SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) by SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) with mapi id 15.01.1304.025; Thu, 3 Aug 2017 10:40:42 +0000 From: "Bradner, Scott" To: Adrian Farrel CC: Spencer Dawkins at IETF , NomCom-Discussion , Alexey Melnikov Thread-Topic: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt Thread-Index: AQHTDET0CiM+xc9aQUmGoX90D+3x+w== Date: Thu, 3 Aug 2017 10:40:42 +0000 Message-ID: <20EC1E8C-6A9A-43E3-B2CB-E3F4E9625A5B@harvard.edu> References: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> In-Reply-To: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sob@harvard.edu; x-originating-ip: [136.248.127.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR07MB2558; 6:0AGY4QbSUI56Uk2N/48NIsANA85YNXs7mqyMwrqxxBoPbnd3W6q3N2+vuxpb0LhC2k26xpHZYWTlREVxpTLQbnx5wrDnh3NbjVYSvUizbo4762qEPagaZciSqHWL+YbvMPuRdLchlAKjcz54rvubNNSO8HyGdrGgpaN33JhKObY00kkItfiCLRd1Rgzr9vcbhebtunnUTlCq9Yl57+92zLJSxOr3m+rNEp7kaIe6jFWbLg5YNsfq3dxSWLwx1sAYQkEJvoxQnei0jh4aP3GYWd4IOjbfWDD45i31iPe2/SGKz1ju1tSaisZAO4En3VcePR067HQ3Sal+FWzd75Z+Ng==; 5:+xn1iKJrire220nT9youXGsGmplOHf9E3njSvas61j12pPEF36OeX/mPqo++xG2nKKN/5uEEqAGCpdsMeigtPLbPScIkcv5pnqa6lBv3NM0xhDxdsBenjrkzgp+pLGjZNPYZUt7k2N8018DiEJvy1Q==; 24:flpgYKDl7Dbsu7IY6OmdP1lGeuYWazJe9ZyyhlN5dvGTm32/Ptf+qevYBZF4Vfg+xIsxU6Pi9oJYcSouj3Msm4bXWHiPJtRW6naFQnDGA88=; 7:1H45nHOqd/OllMYGbXiKR3bUeDlYvdmgvrV0xwASnTBi18PxAFNY3vq087yPbDbSKxxjt/9cH2WxLvl+NaL+Ia+Qb3z9ydP7d+b7OtmN4O0PYfLbu7XW9ptSEkEt13YV7o76RDdeG7r22AamlsKDH3THvk+q8jw81PWoL6++p2H0DDENaAprThsgMA9xn3jYWf9ZC+CywUPiMvo9Lj8sKP+avwEpHIvQu9LK2pLRV4I= x-ms-office365-filtering-correlation-id: aa45e526-bde0-4f3d-156a-08d4da5c16dc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR07MB2558; x-ms-traffictypediagnostic: SN2PR07MB2558: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR07MB2558; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR07MB2558; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(52314003)(377454003)(189002)(24454002)(199003)(377424004)(54906002)(102836003)(82746002)(478600001)(8676002)(3280700002)(99286003)(8666007)(81166006)(86362001)(966005)(68736007)(6246003)(14454004)(81156014)(189998001)(6512007)(230783001)(2906002)(8936002)(101416001)(53936002)(6306002)(6916009)(15650500001)(25786009)(6486002)(77096006)(105586002)(7736002)(106356001)(66066001)(3846002)(2900100001)(2950100002)(88552002)(305945005)(75432002)(229853002)(6436002)(5660300001)(6506006)(36756003)(4326008)(50986999)(76176999)(3660700001)(54356999)(39060400002)(33656002)(6116002)(38730400002)(97736004)(83716003)(110136004)(53546010); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2558; H:SN2PR07MB2558.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: harvard.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <9B10813D147C1D42A35208C7F8312C36@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 10:40:42.0826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2558 Archived-At: Subject: Re: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 10:40:46 -0000 seems to me that someone who has served on the IAOC within the past few yea= rs would be knowledgeable enough about=20 the operation to be useful=20 Scott > On Aug 3, 2017, at 5:09 AM, Adrian Farrel wrote: >=20 > Hey Spencer, > =20 > Thanks for this work. Will help the whole thing go better. > =20 > My gut feeling is to be nervous about "an advisor who is knowledgeable ab= out IAOC operations" but not actually serving on the IAOC is that the input= and feedback about the operation, direction, and needs of the *current* IA= OC may be significantly skewed. > =20 > You would not, I think, suggest that the advisory part of the role of the= IESG liaison could be filled by a non-serving person. > =20 > I do understand that you are trying to find a way in which the advisor is= not selected from a pool of one. But that might be a price that is not wor= th paying. > =20 > Anyway, I see the IAOC made up as: > =20 > - appointed by NomCom for 2 years (odd year) > - appointed by NomCom for 2 years (even year) > - appointed by the IESG for 2 years (even year) > - appointed by the IAB for 2 years (odd year) > - appointed by the ISOC Board of Trustees for two years (even year) > - ISOC President/CEO (ex officio) (annual) > - IETF Chair (ex officio) (two year cycle, odd year) > - IAB Chair (ex officio) -(annual) > - IAD (non-voting) (annual) > =20 > It is debatable whether you would want any of the bottom four to be the a= dvisor although I note that you haven't excluded them in your text. > I assume that you do not want a candidate to be the advisor (and maybe yo= u should explicitly make that point?). > Obviously outgoing (i.e., standing down) members could be the advisor. > So in odd years you appear to have a choice of at least 3 members (possib= ly more if someone plans to stand down). > And in even years you appear to have a choice of at least 2 members (poss= ibly more if someone plans to stand down). > =20 > I consider that preferable to allowing the IAOC to send someone who might= not have the right reading of the current dynamic. > =20 > It should not be the case that this advisor role is a significant additio= nal burden on the workload. > =20 > Thanks, > Adrian > =20 > From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of Spen= cer Dawkins at IETF > Sent: 02 August 2017 22:31 > To: NomCom-Discussion > Cc: Alexey Melnikov > Subject: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-ie= sg-nomcom-advisor-iaoc-00.txt > =20 > Dear Nomcom Process Devotees, > =20 > Alissa has asked me to put together a short(!) draft that will remind fut= ure Nomcoms to request IAOC to provide an Advisor. > =20 > Details are below. > =20 > I'd like to discuss this draft on this mailing list initially. > =20 > Please comment and question as appropriate. > =20 > Thanks, > =20 > Spencer > =20 > ---------- Forwarded message ---------- > From: > Date: Wed, Aug 2, 2017 at 4:27 PM > Subject: New Version Notification for draft-dawkins-iesg-nomcom-advisor-i= aoc-00.txt > To: Spencer Dawkins >=20 >=20 >=20 > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > has been successfully submitted by Spencer Dawkins and posted to the > IETF repository. >=20 > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > Revision: 00 > Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall P= rocess: IAOC Advisor for the Nominating Committee > Document date: 2017-08-02 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg-n= omcom-advisor-iaoc-00.txt > Status: https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomco= m-advisor-iaoc/ > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-adv= isor-iaoc-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg-= nomcom-advisor-iaoc-00 >=20 >=20 > Abstract: > This specification formalizes an ad hoc practice used to provide > advice to the IETF Nominating Committee about the operations of the > IETF Administrative Oversight Committee. >=20 > This document updates RFC 7437. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > =20 > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From nobody Thu Aug 3 06:22:36 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 21F0D126C23 for ; Thu, 3 Aug 2017 06:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 RfF0GT6CH2Q9 for ; Thu, 3 Aug 2017 06:22:30 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 16EEA12702E for ; Thu, 3 Aug 2017 06:22:30 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id e124so12274024oig.2 for ; Thu, 03 Aug 2017 06:22:30 -0700 (PDT) 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=jy1LlxJtoWw7h7mXGu02C5QsiAR8mjA08AKtEHLwwP4=; b=JPJbCl5hg1ztm3pRLLRnMgGHFAk+y69LgzUUaOq3AD3Qqs9kK3xsLHBecVW9pA8NUJ pBymYkYTA4WgGQMUIL0s+DARHk/iczGdb9zleQW4SSzDf+vIxGnkDIVrceoebdvcu69O ghDEdaTWDsG0yLojngpPWFkzFcgzWcjKaG0s8YJq5lW805TUy2jc+JmpDmtwtz85cCLF 4+sbKZH+X461d93PPVN1cUxdWpuWKHpB68akdcJYkIhDfY066qHSUWpeB9++nYCJ/RXu M+ZeznJFmwEHYoIPiE3nvobfjTC4O7mY60xvIj89l7X6hZvBMPZwpQdCSnKiZSSiNid6 uK8Q== 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=jy1LlxJtoWw7h7mXGu02C5QsiAR8mjA08AKtEHLwwP4=; b=GU736/X2LMGibDkAVQNGMKg/KIVN5VblmJpjrR9d1Vbp0DNCtVdxE2tqBEMBUIYcXP /yI3xTLG1QYLcs8cwKC0HlUv4a6bxydPNw4O10T54m7THuaGNkcpY/rjk00FOGpd/YL2 Ge5davrDW9DVsfxgzJcF49eZF30/AkziU5mEnEf0GO6uJRqLLebmpROW34pevLlXjwY7 iQdDlb+gNCSql/iBBKq+63iaskDqsjhrt8Ezroow0qPfvvR3+X+nQ88ZlnvROnoL3tXP c96QV8G4eZW2z4W4rkdu8w/UMI+125PL3I3RO/m45CMFURi2Udd7PO/jpDhzQkXylh9k xQfg== X-Gm-Message-State: AIVw111FGlyI5atGGVqTNslpYTA8h8Bi0ik7HA9coZOMr713gwH3bMaX fZNf8DLJGge63Q3PwJ15SYYy5CwT+A== X-Received: by 10.202.230.212 with SMTP id d203mr1845509oih.59.1501766549455; Thu, 03 Aug 2017 06:22:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.34 with HTTP; Thu, 3 Aug 2017 06:22:09 -0700 (PDT) In-Reply-To: <20EC1E8C-6A9A-43E3-B2CB-E3F4E9625A5B@harvard.edu> References: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> <20EC1E8C-6A9A-43E3-B2CB-E3F4E9625A5B@harvard.edu> From: "Andrew G. Malis" Date: Thu, 3 Aug 2017 09:22:09 -0400 Message-ID: To: "Bradner, Scott" Cc: Adrian Farrel , NomCom-Discussion , Alexey Melnikov Content-Type: multipart/alternative; boundary="001a1141aedeb747a80555d94575" Archived-At: Subject: Re: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 13:22:34 -0000 --001a1141aedeb747a80555d94575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could the IETF=E2=80=99s Administrative Director serve as the advisor? He o= r she would certainly be knowledgeable about the IAOC. Or is there a prohibition that prevents the AD from advising Nomcom? Cheers, Andy On Thu, Aug 3, 2017 at 6:40 AM, Bradner, Scott wrote: > seems to me that someone who has served on the IAOC within the past few > years would be knowledgeable enough about > the operation to be useful > > Scott > > > > On Aug 3, 2017, at 5:09 AM, Adrian Farrel wrote: > > > > Hey Spencer, > > > > Thanks for this work. Will help the whole thing go better. > > > > My gut feeling is to be nervous about "an advisor who is knowledgeable > about IAOC operations" but not actually serving on the IAOC is that the > input and feedback about the operation, direction, and needs of the > *current* IAOC may be significantly skewed. > > > > You would not, I think, suggest that the advisory part of the role of > the IESG liaison could be filled by a non-serving person. > > > > I do understand that you are trying to find a way in which the advisor > is not selected from a pool of one. But that might be a price that is not > worth paying. > > > > Anyway, I see the IAOC made up as: > > > > - appointed by NomCom for 2 years (odd year) > > - appointed by NomCom for 2 years (even year) > > - appointed by the IESG for 2 years (even year) > > - appointed by the IAB for 2 years (odd year) > > - appointed by the ISOC Board of Trustees for two years (even year) > > - ISOC President/CEO (ex officio) (annual) > > - IETF Chair (ex officio) (two year cycle, odd year) > > - IAB Chair (ex officio) -(annual) > > - IAD (non-voting) (annual) > > > > It is debatable whether you would want any of the bottom four to be the > advisor although I note that you haven't excluded them in your text. > > I assume that you do not want a candidate to be the advisor (and maybe > you should explicitly make that point?). > > Obviously outgoing (i.e., standing down) members could be the advisor. > > So in odd years you appear to have a choice of at least 3 members > (possibly more if someone plans to stand down). > > And in even years you appear to have a choice of at least 2 members > (possibly more if someone plans to stand down). > > > > I consider that preferable to allowing the IAOC to send someone who > might not have the right reading of the current dynamic. > > > > It should not be the case that this advisor role is a significant > additional burden on the workload. > > > > Thanks, > > Adrian > > > > From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of > Spencer Dawkins at IETF > > Sent: 02 August 2017 22:31 > > To: NomCom-Discussion > > Cc: Alexey Melnikov > > Subject: [ietf-nomcom] Fwd: New Version Notification for > draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > > > Dear Nomcom Process Devotees, > > > > Alissa has asked me to put together a short(!) draft that will remind > future Nomcoms to request IAOC to provide an Advisor. > > > > Details are below. > > > > I'd like to discuss this draft on this mailing list initially. > > > > Please comment and question as appropriate. > > > > Thanks, > > > > Spencer > > > > ---------- Forwarded message ---------- > > From: > > Date: Wed, Aug 2, 2017 at 4:27 PM > > Subject: New Version Notification for draft-dawkins-iesg-nomcom- > advisor-iaoc-00.txt > > To: Spencer Dawkins > > > > > > > > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > has been successfully submitted by Spencer Dawkins and posted to the > > IETF repository. > > > > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > > Revision: 00 > > Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall > Process: IAOC Advisor for the Nominating Committee > > Document date: 2017-08-02 > > Group: Individual Submission > > Pages: 6 > > URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg= - > nomcom-advisor-iaoc-00.txt > > Status: https://datatracker.ietf.org/ > doc/draft-dawkins-iesg-nomcom-advisor-iaoc/ > > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom- > advisor-iaoc-00 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-dawkins-iesg-nomcom-advisor-iaoc-00 > > > > > > Abstract: > > This specification formalizes an ad hoc practice used to provide > > advice to the IETF Nominating Committee about the operations of the > > IETF Administrative Oversight Committee. > > > > This document updates RFC 7437. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > _______________________________________________ > > ietf-nomcom mailing list > > ietf-nomcom@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > --001a1141aedeb747a80555d94575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could the IETF=E2=80=99s Administrative Director serve as = the advisor? He or she would certainly be knowledgeable about the IAOC. Or = is there a prohibition that prevents the AD from advising Nomcom?

<= /div>
Cheers,
Andy


On Thu, Aug 3, 2017 at 6:40 AM, B= radner, Scott <sob@harvard.edu> wrote:
seems to me that someone who has served on the IAOC within the p= ast few years would be knowledgeable enough about
the operation to be useful

Scott


> On Aug 3, 2017, at 5:09 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Hey Spencer,
>
> Thanks for this work. Will help the whole thing go better.
>
> My gut feeling is to be nervous about "an advisor who is knowledg= eable about IAOC operations" but not actually serving on the IAOC is t= hat the input and feedback about the operation, direction, and needs of the= *current* IAOC may be significantly skewed.
>
> You would not, I think, suggest that the advisory part of the role of = the IESG liaison could be filled by a non-serving person.
>
> I do understand that you are trying to find a way in which the advisor= is not selected from a pool of one. But that might be a price that is not = worth paying.
>
> Anyway, I see the IAOC made up as:
>
> - appointed by NomCom for 2 years (odd year)
> - appointed by NomCom for 2 years (even year)
> - appointed by the IESG for 2 years (even year)
> - appointed by the IAB for 2 years (odd year)
> - appointed by the ISOC Board of Trustees for two years (even year) > - ISOC President/CEO (ex officio) (annual)
> - IETF Chair (ex officio) (two year cycle, odd year)
> - IAB Chair (ex officio) -(annual)
> - IAD (non-voting) (annual)
>
> It is debatable whether you would want any of the bottom four to be th= e advisor although I note that you haven't excluded them in your text.<= br> > I assume that you do not want a candidate to be the advisor (and maybe= you should explicitly make that point?).
> Obviously outgoing (i.e., standing down) members could be the advisor.=
> So in odd years you appear to have a choice of at least 3 members (pos= sibly more if someone plans to stand down).
> And in even years you appear to have a choice of at least 2 members (p= ossibly more if someone plans to stand down).
>
> I consider that preferable to allowing the IAOC to send someone who mi= ght not have the right reading of the current dynamic.
>
> It should not be the case that this advisor role is a significant addi= tional burden on the workload.
>
> Thanks,
> Adrian
>
> From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of Spencer Dawkins at = IETF
> Sent: 02 August 2017 22:31
> To: NomCom-Discussion
> Cc: Alexey Melnikov
> Subject: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins= -iesg-nomcom-advisor-iaoc-00.txt
>
> Dear Nomcom Process Devotees,
>
> Alissa has asked me to put together a short(!) draft that will remind = future Nomcoms to request IAOC to provide an Advisor.
>
> Details are below.
>
> I'd like to discuss this draft on this mailing list initially.
>
> Please comment and question as appropriate.
>
> Thanks,
>
> Spencer
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Wed, Aug 2, 2017 at 4:27 PM
> Subject: New Version Notification for draft-dawkins-iesg-nomcom-a= dvisor-iaoc-00.txt
> To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.t= xt
> has been successfully submitted by Spencer Dawkins and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dawkins-iesg-nomco= m-advisor-iaoc
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB, IESG, and IAOC Selection= , Confirmation, and Recall Process: IAOC Advisor for the Nominating Committ= ee
> Document date:=C2=A0 2017-08-02
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts= /draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-dawkins-iesg-= nomcom-advisor-iaoc/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-advisor-iaoc-00
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-dawkin= s-iesg-nomcom-advisor-iaoc-00
>
>
> Abstract:
>=C2=A0 =C2=A0 This specification formalizes an ad hoc practice used to = provide
>=C2=A0 =C2=A0 advice to the IETF Nominating Committee about the operati= ons of the
>=C2=A0 =C2=A0 IETF Administrative Oversight Committee.
>
>=C2=A0 =C2=A0 This document updates RFC 7437.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>
> __________________= _____________________________
> ietf-nomcom mailing list
> ietf-nomcom@ietf.org
> https://www.ietf.org/mailman/listinfo/iet= f-nomcom

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

--001a1141aedeb747a80555d94575-- From nobody Thu Aug 3 06:36:22 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 D5F6013203F for ; Thu, 3 Aug 2017 06:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 trZU92U1YIww for ; Thu, 3 Aug 2017 06:36:08 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0073.outbound.protection.outlook.com [104.47.41.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695AD132046 for ; Thu, 3 Aug 2017 06:36:05 -0700 (PDT) Received: from SN2PR07MB2558.namprd07.prod.outlook.com (10.167.15.12) by SN2PR07MB2559.namprd07.prod.outlook.com (10.167.15.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 13:36:03 +0000 Received: from SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) by SN2PR07MB2558.namprd07.prod.outlook.com ([10.167.15.12]) with mapi id 15.01.1304.025; Thu, 3 Aug 2017 13:36:04 +0000 From: "Bradner, Scott" To: "Andrew G. Malis" CC: Adrian Farrel , NomCom-Discussion , Alexey Melnikov Thread-Topic: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt Thread-Index: AQHTDET0J4McLjCbzkaWNEWmjorDBqJynnqAgAAD4oA= Date: Thu, 3 Aug 2017 13:36:03 +0000 Message-ID: <235599E5-EF86-4A22-AC5B-0B33F6E3A7C8@harvard.edu> References: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> <20EC1E8C-6A9A-43E3-B2CB-E3F4E9625A5B@harvard.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sob@harvard.edu; x-originating-ip: [136.248.127.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR07MB2559; 6:maHx3C9K5k0p+0iBC1Yf/sn7Br2/EValTNmKzWkq0TyVftCpnSwzcSplFF3zbTyd9tN8ohGJhrzjB3egMki1WYzMjCaZDSpgdPlT724ntzqVkt5MQzYEwt9V1EE0nMp5okOi4Q+F1+zkD2wui/IxMAjUyFBU90jH/GIbG+HmqZJxowYNv9qKqW8RxQb7riI8Httj+g3j+0C9YTuvyUITJfd7F2dDS/kmj8m90SIiE+0tqh1C/PxFf59L9GnYAMPu/gOJH47c7X71VUlkm2gKa0k+N9zPNqFVhSF6IDqAplJZWGzprWiWX5YBMl938TcgJWaq7ifLLAZJOAx5fbMn8A==; 5:6aGq8zEDS96yN7uUd2ZwpwyHIMuO0gxp7pn7AkTuG0ULOz4J/96UaJsgzxaE4FBLNMuqykDJjh7tJ0R6CNhPsAaz1GhRf6sjsd2jzmDGC9xMmYYHcmzLJCdX2bXStnecZHlEHa+6zsPKtT98weViog==; 24:8lqf6rzhWuoS8CqrVoHnVbys9IKbSzK+Jx3ftBZoDP2ByghM/L/QH18xXLlQ5eHlnKTOAZOq9j+LDbGoDLUaKzlYDSjVYBe/F656cdueDac=; 7:qRwx+raGhTeqpirtFAlYddlw5CBDlN0PlhfJe9JRUY3KMJ3wDqTGNYraKKcYWjW8VFXRVsari4ZLzK4PXNM5p9BS+5dY5i0Zqg4NCbwNUWxgp8FXLVk2KgSL8JdBqPLZuEG54A6t3a80nydRe7AOzXbxmrTR7UsyhK6HzR1xljnFMTZvM0XC7rCgb69JYUpfBPD9RIRdqUwPFMuOEmFrTMser+ZfbmUCJS0+cDFv6Rw= x-ms-office365-filtering-correlation-id: 5025e5d4-afa7-4682-f585-08d4da74965f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR07MB2559; x-ms-traffictypediagnostic: SN2PR07MB2559: x-exchange-antispam-report-test: UriScan:(20558992708506)(120809045254105)(35762410373642); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR07MB2559; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR07MB2559; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(52314003)(377454003)(377424004)(189002)(24454002)(199003)(83716003)(54356999)(82746002)(97736004)(7736002)(76176999)(50986999)(6306002)(54906002)(88552002)(3280700002)(6512007)(1411001)(93886004)(68736007)(75432002)(6246003)(3660700001)(189998001)(53936002)(110136004)(305945005)(106356001)(33656002)(66066001)(39060400002)(4326008)(25786009)(36756003)(15650500001)(38730400002)(8936002)(8676002)(81156014)(81166006)(101416001)(105586002)(229853002)(6436002)(14454004)(5660300001)(6506006)(230783001)(53546010)(102836003)(3846002)(6116002)(2900100001)(8666007)(2906002)(2950100002)(77096006)(6486002)(6916009)(478600001)(86362001)(966005)(99286003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2559; H:SN2PR07MB2558.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: harvard.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: harvard.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 13:36:03.9702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6ffa22f4-4568-4105-ad43-2e3ad4726957 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2559 Archived-At: Subject: Re: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 13:36:11 -0000 dGhhdCB3b3VsZCBiZSAgdGhlIElBRCBpbmZsdWVuY2luZyB0aGUgc2VsZWN0aW9uIG9mIHRoZSBw ZW9wbGUgdGhhdCBoZSBvciBzaGUgcmVwb3J0cyB0byAtIGRvZXMgbm90IHNlZW0gbGlrZSBhIGdv b2QgaWRlYQ0KDQpTY290DQoNCj4gT24gQXVnIDMsIDIwMTcsIGF0IDk6MjIgQU0sIEFuZHJldyBH LiBNYWxpcyA8YWdtYWxpc0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gQ291bGQgdGhlIElFVEbi gJlzIEFkbWluaXN0cmF0aXZlIERpcmVjdG9yIHNlcnZlIGFzIHRoZSBhZHZpc29yPyBIZSBvciBz aGUgd291bGQgY2VydGFpbmx5IGJlIGtub3dsZWRnZWFibGUgYWJvdXQgdGhlIElBT0MuIE9yIGlz IHRoZXJlIGEgcHJvaGliaXRpb24gdGhhdCBwcmV2ZW50cyB0aGUgQUQgZnJvbSBhZHZpc2luZyBO b21jb20/DQo+IA0KPiBDaGVlcnMsDQo+IEFuZHkNCj4gDQo+IA0KPiBPbiBUaHUsIEF1ZyAzLCAy MDE3IGF0IDY6NDAgQU0sIEJyYWRuZXIsIFNjb3R0IDxzb2JAaGFydmFyZC5lZHU+IHdyb3RlOg0K PiBzZWVtcyB0byBtZSB0aGF0IHNvbWVvbmUgd2hvIGhhcyBzZXJ2ZWQgb24gdGhlIElBT0Mgd2l0 aGluIHRoZSBwYXN0IGZldyB5ZWFycyB3b3VsZCBiZSBrbm93bGVkZ2VhYmxlIGVub3VnaCBhYm91 dA0KPiB0aGUgb3BlcmF0aW9uIHRvIGJlIHVzZWZ1bA0KPiANCj4gU2NvdHQNCj4gDQo+IA0KPiA+ IE9uIEF1ZyAzLCAyMDE3LCBhdCA1OjA5IEFNLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9n LmNvLnVrPiB3cm90ZToNCj4gPg0KPiA+IEhleSBTcGVuY2VyLA0KPiA+DQo+ID4gVGhhbmtzIGZv ciB0aGlzIHdvcmsuIFdpbGwgaGVscCB0aGUgd2hvbGUgdGhpbmcgZ28gYmV0dGVyLg0KPiA+DQo+ ID4gTXkgZ3V0IGZlZWxpbmcgaXMgdG8gYmUgbmVydm91cyBhYm91dCAiYW4gYWR2aXNvciB3aG8g aXMga25vd2xlZGdlYWJsZSBhYm91dCBJQU9DIG9wZXJhdGlvbnMiIGJ1dCBub3QgYWN0dWFsbHkg c2VydmluZyBvbiB0aGUgSUFPQyBpcyB0aGF0IHRoZSBpbnB1dCBhbmQgZmVlZGJhY2sgYWJvdXQg dGhlIG9wZXJhdGlvbiwgZGlyZWN0aW9uLCBhbmQgbmVlZHMgb2YgdGhlICpjdXJyZW50KiBJQU9D IG1heSBiZSBzaWduaWZpY2FudGx5IHNrZXdlZC4NCj4gPg0KPiA+IFlvdSB3b3VsZCBub3QsIEkg dGhpbmssIHN1Z2dlc3QgdGhhdCB0aGUgYWR2aXNvcnkgcGFydCBvZiB0aGUgcm9sZSBvZiB0aGUg SUVTRyBsaWFpc29uIGNvdWxkIGJlIGZpbGxlZCBieSBhIG5vbi1zZXJ2aW5nIHBlcnNvbi4NCj4g Pg0KPiA+IEkgZG8gdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGZpbmQgYSB3YXkg aW4gd2hpY2ggdGhlIGFkdmlzb3IgaXMgbm90IHNlbGVjdGVkIGZyb20gYSBwb29sIG9mIG9uZS4g QnV0IHRoYXQgbWlnaHQgYmUgYSBwcmljZSB0aGF0IGlzIG5vdCB3b3J0aCBwYXlpbmcuDQo+ID4N Cj4gPiBBbnl3YXksIEkgc2VlIHRoZSBJQU9DIG1hZGUgdXAgYXM6DQo+ID4NCj4gPiAtIGFwcG9p bnRlZCBieSBOb21Db20gZm9yIDIgeWVhcnMgKG9kZCB5ZWFyKQ0KPiA+IC0gYXBwb2ludGVkIGJ5 IE5vbUNvbSBmb3IgMiB5ZWFycyAoZXZlbiB5ZWFyKQ0KPiA+IC0gYXBwb2ludGVkIGJ5IHRoZSBJ RVNHIGZvciAyIHllYXJzIChldmVuIHllYXIpDQo+ID4gLSBhcHBvaW50ZWQgYnkgdGhlIElBQiBm b3IgMiB5ZWFycyAob2RkIHllYXIpDQo+ID4gLSBhcHBvaW50ZWQgYnkgdGhlIElTT0MgQm9hcmQg b2YgVHJ1c3RlZXMgZm9yIHR3byB5ZWFycyAoZXZlbiB5ZWFyKQ0KPiA+IC0gSVNPQyBQcmVzaWRl bnQvQ0VPIChleCBvZmZpY2lvKSAoYW5udWFsKQ0KPiA+IC0gSUVURiBDaGFpciAoZXggb2ZmaWNp bykgKHR3byB5ZWFyIGN5Y2xlLCBvZGQgeWVhcikNCj4gPiAtIElBQiBDaGFpciAoZXggb2ZmaWNp bykgLShhbm51YWwpDQo+ID4gLSBJQUQgKG5vbi12b3RpbmcpIChhbm51YWwpDQo+ID4NCj4gPiBJ dCBpcyBkZWJhdGFibGUgd2hldGhlciB5b3Ugd291bGQgd2FudCBhbnkgb2YgdGhlIGJvdHRvbSBm b3VyIHRvIGJlIHRoZSBhZHZpc29yIGFsdGhvdWdoIEkgbm90ZSB0aGF0IHlvdSBoYXZlbid0IGV4 Y2x1ZGVkIHRoZW0gaW4geW91ciB0ZXh0Lg0KPiA+IEkgYXNzdW1lIHRoYXQgeW91IGRvIG5vdCB3 YW50IGEgY2FuZGlkYXRlIHRvIGJlIHRoZSBhZHZpc29yIChhbmQgbWF5YmUgeW91IHNob3VsZCBl eHBsaWNpdGx5IG1ha2UgdGhhdCBwb2ludD8pLg0KPiA+IE9idmlvdXNseSBvdXRnb2luZyAoaS5l Liwgc3RhbmRpbmcgZG93bikgbWVtYmVycyBjb3VsZCBiZSB0aGUgYWR2aXNvci4NCj4gPiBTbyBp biBvZGQgeWVhcnMgeW91IGFwcGVhciB0byBoYXZlIGEgY2hvaWNlIG9mIGF0IGxlYXN0IDMgbWVt YmVycyAocG9zc2libHkgbW9yZSBpZiBzb21lb25lIHBsYW5zIHRvIHN0YW5kIGRvd24pLg0KPiA+ IEFuZCBpbiBldmVuIHllYXJzIHlvdSBhcHBlYXIgdG8gaGF2ZSBhIGNob2ljZSBvZiBhdCBsZWFz dCAyIG1lbWJlcnMgKHBvc3NpYmx5IG1vcmUgaWYgc29tZW9uZSBwbGFucyB0byBzdGFuZCBkb3du KS4NCj4gPg0KPiA+IEkgY29uc2lkZXIgdGhhdCBwcmVmZXJhYmxlIHRvIGFsbG93aW5nIHRoZSBJ QU9DIHRvIHNlbmQgc29tZW9uZSB3aG8gbWlnaHQgbm90IGhhdmUgdGhlIHJpZ2h0IHJlYWRpbmcg b2YgdGhlIGN1cnJlbnQgZHluYW1pYy4NCj4gPg0KPiA+IEl0IHNob3VsZCBub3QgYmUgdGhlIGNh c2UgdGhhdCB0aGlzIGFkdmlzb3Igcm9sZSBpcyBhIHNpZ25pZmljYW50IGFkZGl0aW9uYWwgYnVy ZGVuIG9uIHRoZSB3b3JrbG9hZC4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBBZHJpYW4NCj4gPg0K PiA+IEZyb206IGlldGYtbm9tY29tIFttYWlsdG86aWV0Zi1ub21jb20tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGDQo+ID4gU2VudDogMDIgQXVn dXN0IDIwMTcgMjI6MzENCj4gPiBUbzogTm9tQ29tLURpc2N1c3Npb24NCj4gPiBDYzogQWxleGV5 IE1lbG5pa292DQo+ID4gU3ViamVjdDogW2lldGYtbm9tY29tXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtZGF3a2lucy1pZXNnLW5vbWNvbS1hZHZpc29yLWlhb2MtMDAu dHh0DQo+ID4NCj4gPiBEZWFyIE5vbWNvbSBQcm9jZXNzIERldm90ZWVzLA0KPiA+DQo+ID4gQWxp c3NhIGhhcyBhc2tlZCBtZSB0byBwdXQgdG9nZXRoZXIgYSBzaG9ydCghKSBkcmFmdCB0aGF0IHdp bGwgcmVtaW5kIGZ1dHVyZSBOb21jb21zIHRvIHJlcXVlc3QgSUFPQyB0byBwcm92aWRlIGFuIEFk dmlzb3IuDQo+ID4NCj4gPiBEZXRhaWxzIGFyZSBiZWxvdy4NCj4gPg0KPiA+IEknZCBsaWtlIHRv IGRpc2N1c3MgdGhpcyBkcmFmdCBvbiB0aGlzIG1haWxpbmcgbGlzdCBpbml0aWFsbHkuDQo+ID4N Cj4gPiBQbGVhc2UgY29tbWVudCBhbmQgcXVlc3Rpb24gYXMgYXBwcm9wcmlhdGUuDQo+ID4NCj4g PiBUaGFua3MsDQo+ID4NCj4gPiBTcGVuY2VyDQo+ID4NCj4gPiAtLS0tLS0tLS0tIEZvcndhcmRl ZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gPiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KPiA+IERhdGU6IFdlZCwgQXVnIDIsIDIwMTcgYXQgNDoyNyBQTQ0KPiA+IFN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGF3a2lucy1pZXNnLW5vbWNvbS1hZHZp c29yLWlhb2MtMDAudHh0DQo+ID4gVG86IFNwZW5jZXIgRGF3a2lucyA8c3BlbmNlcmRhd2tpbnMu aWV0ZkBnbWFpbC5jb20+DQo+ID4NCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWRhd2tpbnMtaWVzZy1ub21jb20tYWR2aXNvci1pYW9jLTAwLnR4dA0KPiA+IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3BlbmNlciBEYXdraW5zIGFuZCBwb3N0ZWQg dG8gdGhlDQo+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZTogICAgICAgICAgIGRy YWZ0LWRhd2tpbnMtaWVzZy1ub21jb20tYWR2aXNvci1pYW9jDQo+ID4gUmV2aXNpb246ICAgICAg IDAwDQo+ID4gVGl0bGU6ICAgICAgICAgIElBQiwgSUVTRywgYW5kIElBT0MgU2VsZWN0aW9uLCBD b25maXJtYXRpb24sIGFuZCBSZWNhbGwgUHJvY2VzczogSUFPQyBBZHZpc29yIGZvciB0aGUgTm9t aW5hdGluZyBDb21taXR0ZWUNCj4gPiBEb2N1bWVudCBkYXRlOiAgMjAxNy0wOC0wMg0KPiA+IEdy b3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdlczogICAgICAgICAg Ng0KPiA+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZGF3a2lucy1pZXNnLW5vbWNvbS1hZHZpc29yLWlhb2MtMDAudHh0DQo+ID4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRhd2tp bnMtaWVzZy1ub21jb20tYWR2aXNvci1pYW9jLw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGF3a2lucy1pZXNnLW5vbWNvbS1hZHZpc29yLWlh b2MtMDANCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1kYXdraW5zLWllc2ctbm9tY29tLWFkdmlzb3ItaWFvYy0wMA0KPiA+DQo+ ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIHNwZWNpZmljYXRpb24gZm9ybWFsaXplcyBh biBhZCBob2MgcHJhY3RpY2UgdXNlZCB0byBwcm92aWRlDQo+ID4gICAgYWR2aWNlIHRvIHRoZSBJ RVRGIE5vbWluYXRpbmcgQ29tbWl0dGVlIGFib3V0IHRoZSBvcGVyYXRpb25zIG9mIHRoZQ0KPiA+ ICAgIElFVEYgQWRtaW5pc3RyYXRpdmUgT3ZlcnNpZ2h0IENvbW1pdHRlZS4NCj4gPg0KPiA+ICAg IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzQzNy4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBpZXRmLW5vbWNvbSBtYWlsaW5nIGxpc3QNCj4gPiBpZXRm LW5vbWNvbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWV0Zi1ub21jb20NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGlldGYtbm9tY29tIG1haWxpbmcgbGlzdA0KPiBpZXRmLW5vbWNvbUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbm9t Y29tDQo+IA0KDQo= From nobody Thu Aug 3 06:40:23 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 8EF8313203A for ; Thu, 3 Aug 2017 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 pSD2gYik4gru for ; Thu, 3 Aug 2017 06:40:19 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 C1113132039 for ; Thu, 3 Aug 2017 06:40:18 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e124so12744078oig.2 for ; Thu, 03 Aug 2017 06:40:18 -0700 (PDT) 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=2TqDx3BQdGAxFcU0JTwN9w80pO3DV6XlnkaEy0o2nCw=; b=LD4YaXp/9YpvweQlyMUz7sJ4LelEhlV+4ClGB5VSHFwHuNMIatgudGzWIoOR0ZWbrP T97JlxZkzJxQgXbKGJmdDcsJOMKluaPDZ7sxGtUWXnaINoILf1mvbP9OoQIkiVwQ+Ymg AKD9JWb7xQ+4hkzMrCuzCjJNOMKPz6l5KpXjbZKjBK4Bz+gOHBZsHzUv8iX4ScNy/ltv Ch1M+YAV7eUzJCayKeP67t9IivAElZ0+wcjbVoDizO6pUmI+BuWo3X8LRKjJ3gyZH5Iy EX7eO5iJjMhmSonPWYQbTsrGMmWYCnym+KTLMzhK8va0QtqACEDAtZjLR1RbgHEj1n5d 9wxQ== 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=2TqDx3BQdGAxFcU0JTwN9w80pO3DV6XlnkaEy0o2nCw=; b=eSEdf9mL83uvyduKkMzdzCruFo8ftS9GSXz5Mvxun//k3jOvJrxWlbOAyT8Z4Ov7Ms rx//D8psUp8az8zuhnrzYfNnu46q6F6kwvqKsXDV7AzP5I9rLmP8BXdNXbVZelx5B66z 5HdRnOHuu7sK2b0WSrpCQB8IvcW87x4FRYlm1CvKm/qCN3yTk+wUKJB0MjlArBrBtIU7 rKAD+65IhZ7AMnyaoFhyIFwe6sjEr2bWm6ClXr378PfAxcXudirT77oigNLIwniU8NRY aiueSDFLt9xiVhyyERgwYCjV46vI0z8JXgtbFaFaUotSoPtjfAqCL6+ZP8TPPaG1vcag OUnQ== X-Gm-Message-State: AIVw112ouu8/nE/Olb1lih0Ue5RWs7c4OE4OacZdhTYwyNxv6zG+OcBJ iih8zMRSSkqsaPBP8kaCoY4TElMJ3g== X-Received: by 10.202.69.197 with SMTP id s188mr1703181oia.148.1501767618019; Thu, 03 Aug 2017 06:40:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.34 with HTTP; Thu, 3 Aug 2017 06:39:57 -0700 (PDT) In-Reply-To: <235599E5-EF86-4A22-AC5B-0B33F6E3A7C8@harvard.edu> References: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> <20EC1E8C-6A9A-43E3-B2CB-E3F4E9625A5B@harvard.edu> <235599E5-EF86-4A22-AC5B-0B33F6E3A7C8@harvard.edu> From: "Andrew G. Malis" Date: Thu, 3 Aug 2017 09:39:57 -0400 Message-ID: To: "Bradner, Scott" Cc: Adrian Farrel , NomCom-Discussion , Alexey Melnikov Content-Type: multipart/alternative; boundary="001a113dd3be684a930555d985f6" Archived-At: Subject: Re: [ietf-nomcom] New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 13:40:21 -0000 --001a113dd3be684a930555d985f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Scott, There is that =E2=80=A6 :-) Cheers, Andy On Thu, Aug 3, 2017 at 9:36 AM, Bradner, Scott wrote: > that would be the IAD influencing the selection of the people that he or > she reports to - does not seem like a good idea > > Scot > > > On Aug 3, 2017, at 9:22 AM, Andrew G. Malis wrote: > > > > Could the IETF=E2=80=99s Administrative Director serve as the advisor? = He or she > would certainly be knowledgeable about the IAOC. Or is there a prohibitio= n > that prevents the AD from advising Nomcom? > > > > Cheers, > > Andy > > > > > > On Thu, Aug 3, 2017 at 6:40 AM, Bradner, Scott wrote: > > seems to me that someone who has served on the IAOC within the past few > years would be knowledgeable enough about > > the operation to be useful > > > > Scott > > > > > > > On Aug 3, 2017, at 5:09 AM, Adrian Farrel wrote= : > > > > > > Hey Spencer, > > > > > > Thanks for this work. Will help the whole thing go better. > > > > > > My gut feeling is to be nervous about "an advisor who is knowledgeabl= e > about IAOC operations" but not actually serving on the IAOC is that the > input and feedback about the operation, direction, and needs of the > *current* IAOC may be significantly skewed. > > > > > > You would not, I think, suggest that the advisory part of the role of > the IESG liaison could be filled by a non-serving person. > > > > > > I do understand that you are trying to find a way in which the adviso= r > is not selected from a pool of one. But that might be a price that is not > worth paying. > > > > > > Anyway, I see the IAOC made up as: > > > > > > - appointed by NomCom for 2 years (odd year) > > > - appointed by NomCom for 2 years (even year) > > > - appointed by the IESG for 2 years (even year) > > > - appointed by the IAB for 2 years (odd year) > > > - appointed by the ISOC Board of Trustees for two years (even year) > > > - ISOC President/CEO (ex officio) (annual) > > > - IETF Chair (ex officio) (two year cycle, odd year) > > > - IAB Chair (ex officio) -(annual) > > > - IAD (non-voting) (annual) > > > > > > It is debatable whether you would want any of the bottom four to be > the advisor although I note that you haven't excluded them in your text. > > > I assume that you do not want a candidate to be the advisor (and mayb= e > you should explicitly make that point?). > > > Obviously outgoing (i.e., standing down) members could be the advisor= . > > > So in odd years you appear to have a choice of at least 3 members > (possibly more if someone plans to stand down). > > > And in even years you appear to have a choice of at least 2 members > (possibly more if someone plans to stand down). > > > > > > I consider that preferable to allowing the IAOC to send someone who > might not have the right reading of the current dynamic. > > > > > > It should not be the case that this advisor role is a significant > additional burden on the workload. > > > > > > Thanks, > > > Adrian > > > > > > From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of > Spencer Dawkins at IETF > > > Sent: 02 August 2017 22:31 > > > To: NomCom-Discussion > > > Cc: Alexey Melnikov > > > Subject: [ietf-nomcom] Fwd: New Version Notification for > draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > > > > > Dear Nomcom Process Devotees, > > > > > > Alissa has asked me to put together a short(!) draft that will remind > future Nomcoms to request IAOC to provide an Advisor. > > > > > > Details are below. > > > > > > I'd like to discuss this draft on this mailing list initially. > > > > > > Please comment and question as appropriate. > > > > > > Thanks, > > > > > > Spencer > > > > > > ---------- Forwarded message ---------- > > > From: > > > Date: Wed, Aug 2, 2017 at 4:27 PM > > > Subject: New Version Notification for draft-dawkins-iesg-nomcom- > advisor-iaoc-00.txt > > > To: Spencer Dawkins > > > > > > > > > > > > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > > has been successfully submitted by Spencer Dawkins and posted to the > > > IETF repository. > > > > > > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > > > Revision: 00 > > > Title: IAB, IESG, and IAOC Selection, Confirmation, and > Recall Process: IAOC Advisor for the Nominating Committee > > > Document date: 2017-08-02 > > > Group: Individual Submission > > > Pages: 6 > > > URL: https://www.ietf.org/internet- > drafts/draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > > Status: https://datatracker.ietf.org/ > doc/draft-dawkins-iesg-nomcom-advisor-iaoc/ > > > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom= - > advisor-iaoc-00 > > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-dawkins-iesg-nomcom-advisor-iaoc-00 > > > > > > > > > Abstract: > > > This specification formalizes an ad hoc practice used to provide > > > advice to the IETF Nominating Committee about the operations of th= e > > > IETF Administrative Oversight Committee. > > > > > > This document updates RFC 7437. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > _______________________________________________ > > > ietf-nomcom mailing list > > > ietf-nomcom@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > > > _______________________________________________ > > ietf-nomcom mailing list > > ietf-nomcom@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > > > --001a113dd3be684a930555d985f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott,

There is that =E2=80=A6 :-)

Cheers,
Andy


On Thu, Aug 3, 2017 at= 9:36 AM, Bradner, Scott <sob@harvard.edu> wrote:
that would be=C2=A0 the IAD influencing the selection= of the people that he or she reports to - does not seem like a good idea
Scot

> On Aug 3, 2017, at 9:22 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>
> Could the IETF=E2=80=99s Administrative Director serve as the advisor?= He or she would certainly be knowledgeable about the IAOC. Or is there a p= rohibition that prevents the AD from advising Nomcom?
>
> Cheers,
> Andy
>
>
> On Thu, Aug 3, 2017 at 6:40 AM, Bradner, Scott <sob@harvard.edu> wrote:
> seems to me that someone who has served on the IAOC within the past fe= w years would be knowledgeable enough about
> the operation to be useful
>
> Scott
>
>
> > On Aug 3, 2017, at 5:09 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> >
> > Hey Spencer,
> >
> > Thanks for this work. Will help the whole thing go better.
> >
> > My gut feeling is to be nervous about "an advisor who is kno= wledgeable about IAOC operations" but not actually serving on the IAOC= is that the input and feedback about the operation, direction, and needs o= f the *current* IAOC may be significantly skewed.
> >
> > You would not, I think, suggest that the advisory part of the rol= e of the IESG liaison could be filled by a non-serving person.
> >
> > I do understand that you are trying to find a way in which the ad= visor is not selected from a pool of one. But that might be a price that is= not worth paying.
> >
> > Anyway, I see the IAOC made up as:
> >
> > - appointed by NomCom for 2 years (odd year)
> > - appointed by NomCom for 2 years (even year)
> > - appointed by the IESG for 2 years (even year)
> > - appointed by the IAB for 2 years (odd year)
> > - appointed by the ISOC Board of Trustees for two years (even yea= r)
> > - ISOC President/CEO (ex officio) (annual)
> > - IETF Chair (ex officio) (two year cycle, odd year)
> > - IAB Chair (ex officio) -(annual)
> > - IAD (non-voting) (annual)
> >
> > It is debatable whether you would want any of the bottom four to = be the advisor although I note that you haven't excluded them in your t= ext.
> > I assume that you do not want a candidate to be the advisor (and = maybe you should explicitly make that point?).
> > Obviously outgoing (i.e., standing down) members could be the adv= isor.
> > So in odd years you appear to have a choice of at least 3 members= (possibly more if someone plans to stand down).
> > And in even years you appear to have a choice of at least 2 membe= rs (possibly more if someone plans to stand down).
> >
> > I consider that preferable to allowing the IAOC to send someone w= ho might not have the right reading of the current dynamic.
> >
> > It should not be the case that this advisor role is a significant= additional burden on the workload.
> >
> > Thanks,
> > Adrian
> >
> > From: ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] On Behalf Of Spencer Dawkin= s at IETF
> > Sent: 02 August 2017 22:31
> > To: NomCom-Discussion
> > Cc: Alexey Melnikov
> > Subject: [ietf-nomcom] Fwd: New Version Notification for draft-da= wkins-iesg-nomcom-advisor-iaoc-00.txt
> >
> > Dear Nomcom Process Devotees,
> >
> > Alissa has asked me to put together a short(!) draft that will re= mind future Nomcoms to request IAOC to provide an Advisor.
> >
> > Details are below.
> >
> > I'd like to discuss this draft on this mailing list initially= .
> >
> > Please comment and question as appropriate.
> >
> > Thanks,
> >
> > Spencer
> >
> > ---------- Forwarded message ----------
> > From: <internet-dr= afts@ietf.org>
> > Date: Wed, Aug 2, 2017 at 4:27 PM
> > Subject: New Version Notification for draft-dawkins-iesg-nomcom-<= wbr>advisor-iaoc-00.txt
> > To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
> >
> >
> >
> > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc= -00.txt
> > has been successfully submitted by Spencer Dawkins and posted to = the
> > IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dawkins-iesg-= nomcom-advisor-iaoc
> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB, IESG, and IAOC Sele= ction, Confirmation, and Recall Process: IAOC Advisor for the Nominating Co= mmittee
> > Document date:=C2=A0 2017-08-02
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dr= afts/draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
> > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-dawkins-= iesg-nomcom-advisor-iaoc/
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-<= wbr>advisor-iaoc-00
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-d= awkins-iesg-nomcom-advisor-iaoc-00
> >
> >
> > Abstract:
> >=C2=A0 =C2=A0 This specification formalizes an ad hoc practice use= d to provide
> >=C2=A0 =C2=A0 advice to the IETF Nominating Committee about the op= erations of the
> >=C2=A0 =C2=A0 IETF Administrative Oversight Committee.
> >
> >=C2=A0 =C2=A0 This document updates RFC 7437.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of= submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > ietf-nomcom mailing list
> > ietf-nomcom@ietf.org<= br> > > https://www.ietf.org/mailman/listinf= o/ietf-nomcom
>
> _______________________________________________
> ietf-nomcom mailing list
> ietf-nomcom@ietf.org
> https://www.ietf.org/mailman/listinfo/iet= f-nomcom
>


--001a113dd3be684a930555d985f6-- From nobody Thu Aug 3 10:01:50 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 DD9411320CF for ; Thu, 3 Aug 2017 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 dgeuaOP01N7D for ; Thu, 3 Aug 2017 10:01:47 -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 0E7411320C9 for ; Thu, 3 Aug 2017 10:01:47 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ddJVJ-0005eY-GK; Thu, 03 Aug 2017 13:01:45 -0400 Date: Thu, 03 Aug 2017 13:01:37 -0400 From: John C Klensin To: Spencer Dawkins at IETF , NomCom-Discussion cc: Alexey Melnikov Message-ID: <18658F3EEA38067A4230D855@PSB> In-Reply-To: References: 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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 17:01:49 -0000 --On Wednesday, August 2, 2017 16:30 -0500 Spencer Dawkins at IETF wrote: > Dear Nomcom Process Devotees, > > Alissa has asked me to put together a short(!) draft that will > remind future Nomcoms to request IAOC to provide an Advisor. > > Details are below. > > I'd like to discuss this draft on this mailing list initially. > > Please comment and question as appropriate. Spencer, While I concur with those who have indicated that this draft is ok (or close) assuming that is what the community wants to do, I want to raise a question about the latter that may or may not be directly relevant to the document. As time has passed and the Nomcom has apparently become increasingly dependent on questionnaires, interviews, and Advisors rather than first-hand knowledge of possible candidates by the voting members, questions of influences on the Nomcom become increasingly important. For the Nomcom to invite someone from a particular body to attend a meeting or call to offer advice on specific issues (consistent with RFC 7437 Section 4.3, second paragraph), a standing Advisor (or Liaison) role is another matter and, other than the technical considerations about oversight of the Nomcom process and the "sitting member" requirements that you describe in Section 4 of the I-D, it is not clear that you (and the draft) anticipate any difference in practice. My concern about all of these roles is the potential for the appearance of undue influence. Is a particular Liaison or Advisor likely to defend a colleague in the same organization? Or exaggerate faults to get rid of one who is personally unpopular with the Liaison or Advisor (or even the whole body)? Is the presence of an incumbent likely to have a chilling effect on a community member who wants to make a well-thought-out argument for, e.g., throwing as many of the incumbents out as possible and starting over on that body? (I know the answer to the latter is "yes", the only questions are how widespread and important it is).) When the Nomcom was first designed and the community assumed that a significant number, perhaps most, of its members would have sufficient experience with likely candidates, that was, itself, a safeguard against abuses. Now, that is not so clear. So it seems to me that we should be at least considering: (1) Encouraging Nomcoms to ask whatever questions about operation, job requirements, etc., seem appropriate of various bodies without needing to rely on Liaisons or Advisors for that rule. (2) Trying to figure out how to isolate Liaisons and Advisors from input (especially informal input) to the Nomcom about the membership, operations at a personal level, and possible candidates for their (and probably other) bodies and to do so in a way that increases community confidence that the Nomcom is seeking out and considering all of the information it wants or needs rather than even potentially being unduly influenced by representatives of bodies to which it is making appointments. While I agree with the observations about allowing an IAD to influence appointments to the body that hires and oversees him or her, very nearly the same observation could apply to allowing an IAB or IESG member to influence choices of people he or she will ultimately need to work, with, who will support or impede their agendas, etc. (3) Encourage the Nomcom to invite Liaisons or Advisors to only participate in discussions for which they are directly and obviously relevant and, in the interest of transparency and increased confidence in the process, document those choices for the community (4) More than 20 years into the current model, perhaps many of the same arguments apply to "sitting members" of other bodies that you have made for the IAOC appointee. Similarly, perhaps it is time to consider whether the job of overseeing the propriety of the Nomcom process ought to be linked with giving the Nomcom advice about particular bodies or even particular candidates or appointments. best, john From nobody Thu Aug 3 10:41:39 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 CBA8F13237F for ; Thu, 3 Aug 2017 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 6Slew5-JaOlV for ; Thu, 3 Aug 2017 10:41:35 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 04C6D132376 for ; Thu, 3 Aug 2017 10:41:35 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p68so12950905ywg.0 for ; Thu, 03 Aug 2017 10:41:34 -0700 (PDT) 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=6WHu1YETGW9ZZSxZghAyD18SL9gUryrfwktKaNd5d0U=; b=fJwVfSR7XWj1S4xGxjJ1Q5NEzuV8agXhGbHhrVxvwSYluVdPyMBgWpG5PXmEpHdzlj 0wqOweG8Ta1Y5j4Mr319zyYaBkOptE3v0yYsW+4cdHOoI7nVOGcZuUQxKjzlOySxgZ04 TraXqqPi6Pyd4U2iqnYV65CsHGctG9hh1o7v3f+CbtZm3Wjw/p9PobM4D11zZcT/1b6m VYZeE/uLOT2EUN7JEw0GARGm5s6+mX081w4b45euo3GhwlGxlP7E56beU0whsppMrrJY KLgN92kNApf4t89vnhf3IF8En2rhIkl5vGJbrSrQ0EgwjiZYmEwA5VcrpyptJgBITpnI MzCw== 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=6WHu1YETGW9ZZSxZghAyD18SL9gUryrfwktKaNd5d0U=; b=Woh7+YcDWZ7+vSacNr6FX9TTFhkNqxLxGPbf0BMbl+Dnm8MfECSzKK50tyyFL1AUIu bx/YFV/SwpNsh1iTyraOmi/poJ/CpcuXlARX4zj1VBEQ2zUqSUUEBmZv1pIUSt3OmfG3 gzEYWDUGE1bSbvX6TsYA+yiP9RWuBQ/kN4OdirPIOwmdQldN5O3OY8cVMzMxcRBPbtn7 JAQmBk0jFpdZ70sfwrkQ+QlXkZJI4fmKUkgLyPxoO3GCKorQ+Sz2n//uQqWIBwSFaUUi xbn4zCA83bCYIrX2YhcCxpYZhvQapUmbfWBGpbzrU4/tZ/qpq6sFNrp+BuZF7E9ujm3x c4cw== X-Gm-Message-State: AIVw111MZwovUsh4tE6FfjLE9YQNiDavVBQ7uSuF7bnyVWCqq8tm4C7H 2nt/UvIjUakBBqnlWm0jte53AzFEzw== X-Received: by 10.37.66.81 with SMTP id p78mr1927806yba.170.1501782093884; Thu, 03 Aug 2017 10:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Thu, 3 Aug 2017 10:41:32 -0700 (PDT) In-Reply-To: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> References: <014b01d30c38$2848fc10$78daf430$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Thu, 3 Aug 2017 12:41:32 -0500 Message-ID: To: "adrian@olddog.co.uk" Cc: NomCom-Discussion , Alexey Melnikov Content-Type: multipart/alternative; boundary="001a11c019fa3c89980555dce487" Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 17:41:38 -0000 --001a11c019fa3c89980555dce487 Content-Type: text/plain; charset="UTF-8" Hi, Adrian, On Thu, Aug 3, 2017 at 4:09 AM, Adrian Farrel wrote: > Hey Spencer, > > > > Thanks for this work. Will help the whole thing go better. > Thanks for the feedback. > My gut feeling is to be nervous about "an advisor who is knowledgeable > about IAOC operations" but not actually serving on the IAOC is that the > input and feedback about the operation, direction, and needs of the > *current* IAOC may be significantly skewed. > I'm not wild about allowing this, but ... > You would not, I think, suggest that the advisory part of the role of the > IESG liaison could be filled by a non-serving person. > > > > I do understand that you are trying to find a way in which the advisor is > not selected from a pool of one. But that might be a price that is not > worth paying. > > > > Anyway, I see the IAOC made up as: > > > > - appointed by NomCom for 2 years (odd year) > > - appointed by NomCom for 2 years (even year) > > - appointed by the IESG for 2 years (even year) > > - appointed by the IAB for 2 years (odd year) > > - appointed by the ISOC Board of Trustees for two years (even year) > > - ISOC President/CEO (ex officio) (annual) > > - IETF Chair (ex officio) (two year cycle, odd year) > > - IAB Chair (ex officio) -(annual) > > - IAD (non-voting) (annual) > > > > It is debatable whether you would want any of the bottom four to be the > advisor although I note that you haven't excluded them in your text. > > I assume that you do not want a candidate to be the advisor (and maybe you > should explicitly make that point?). > > Obviously outgoing (i.e., standing down) members could be the advisor. > > So in odd years you appear to have a choice of at least 3 members > (possibly more if someone plans to stand down). > > And in even years you appear to have a choice of at least 2 members > (possibly more if someone plans to stand down). > I did a pre-submission version of this draft that tried to do this analysis, and it turned into a swamp. Just as one example - multiple people have expressed to me that ex officio members of IAOC should be eligible to serve even if their positions are under review, as long as they've said they aren't willing to serve again, but the Nomcom always has the ability to waterboard an incumbent into serving another term if that's the right thing to do, and I'd need to add text to say whether serving as an advisor to a Nomcom disqualifies you from being returned by that Nomcom - https://tools.ietf.org/html/rfc7437#section-4.8 sidesteps that for liaisons, but there's not text that I can find that does the same for advisors. Given that Alissa has already kicked off IASA 2.0, I'm thinking that it's fairly likely that carefully tuned text that addresses all the corner cases we can think of, would be Overtaken By Events before it gets used. So, I wrote this as being permissive ("Nomcoms can ask for advisors, and IAOCs can provide advisors"), and assumed that the worst consequences I can imagine could be challenged by the Nomcom membership. Your mileage may vary, of course. > I consider that preferable to allowing the IAOC to send someone who might > not have the right reading of the current dynamic. > I'm sympathetic to this point of view, but note that I served as the IAB's liaison to Nomcom during my first year on the IAB, and it's certainly arguable that the recently departed IAB members probably knew more about the IAB than I did, just a few months in :-) ... Spencer It should not be the case that this advisor role is a significant > additional burden on the workload. > > > > Thanks, > > Adrian > > > > *From:* ietf-nomcom [mailto:ietf-nomcom-bounces@ietf.org] *On Behalf Of *Spencer > Dawkins at IETF > *Sent:* 02 August 2017 22:31 > *To:* NomCom-Discussion > *Cc:* Alexey Melnikov > *Subject:* [ietf-nomcom] Fwd: New Version Notification for > draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > > > > Dear Nomcom Process Devotees, > > > > Alissa has asked me to put together a short(!) draft that will remind > future Nomcoms to request IAOC to provide an Advisor. > > > > Details are below. > > > > I'd like to discuss this draft on this mailing list initially. > > > > Please comment and question as appropriate. > > > > Thanks, > > > > Spencer > > > > ---------- Forwarded message ---------- > From: > Date: Wed, Aug 2, 2017 at 4:27 PM > Subject: New Version Notification for draft-dawkins-iesg-nomcom- > advisor-iaoc-00.txt > To: Spencer Dawkins > > > > A new version of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt > has been successfully submitted by Spencer Dawkins and posted to the > IETF repository. > > Name: draft-dawkins-iesg-nomcom-advisor-iaoc > Revision: 00 > Title: IAB, IESG, and IAOC Selection, Confirmation, and Recall > Process: IAOC Advisor for the Nominating Committee > Document date: 2017-08-02 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg- > nomcom-advisor-iaoc-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-dawkins-iesg-nomcom-advisor-iaoc/ > Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom- > advisor-iaoc-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg- > nomcom-advisor-iaoc-00 > > > Abstract: > This specification formalizes an ad hoc practice used to provide > advice to the IETF Nominating Committee about the operations of the > IETF Administrative Oversight Committee. > > This document updates RFC 7437. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --001a11c019fa3c89980555dce487 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Adrian,

On Thu, Aug 3, 2017 at 4:09 AM, Adrian Farrel = <adrian@olddog.= co.uk> wrote:

Hey Spencer,

<= p class=3D"MsoNormal">=C2=A0

Thanks for this work. Will help the whole thing go better.=


Thanks for the feed= back.
=C2=A0

My gut feeling is to be nervous about "an advisor who i= s knowledgeable about IAOC operations" but not actually serving on the= IAOC is that the input and feedback about the operation, direction, and ne= eds of the *current* IAOC may be significantly skewed.


I'm not wild about allowing this, bu= t ...
=C2=A0

You would not, I think, suggest that the = advisory part of the role of the IESG liaison could be filled by a non-serv= ing person.

=C2=A0

I do understand that you are tr= ying to find a way in which the advisor is not selected from a pool of one.= But that might be a price that is not worth paying.

=C2=A0

Anyway, I see the IAOC made up as:=

=C2=A0

- appointed by NomCom for 2 years (odd year)<= u>

- appointed by NomCom for 2= years (even year)

-= appointed by the IESG for 2 years (even year)

- appointed by the IAB for 2 years (odd year)=

- appointed by the ISO= C Board of Trustees for two years (even year)

- ISOC President/CEO (ex officio) (annual)=

- IETF Chair (ex officio) = (two year cycle, odd year)

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">- IAB Chair (ex officio) -(annual)

- IAD (non-voting) (annual)

=

=C2=A0

It is debatable whether you would want any of the bottom = four to be the advisor although I note that you haven't excluded them i= n your text.

I assum= e that you do not want a candidate to be the advisor (and maybe you should = explicitly make that point?).

Obviously outgoing (i.e., standing down) members could be the adv= isor.

So in odd year= s you appear to have a choice of at least 3 members (possibly more if someo= ne plans to stand down).

And in even years you appear to have a choice of at least 2 members (p= ossibly more if someone plans to stand down).


I did a pre-submission version of this draft that= tried to do this analysis, and it turned into a swamp.=C2=A0
Just as one example - multiple people have expressed to me that= ex officio members of IAOC should be eligible to serve even if their posit= ions are under review, as long as they've said they aren't willing = to serve again, but the Nomcom always has the ability to waterboard an incu= mbent into serving another term if that's the right thing to do, and I&= #39;d need to add text to say whether serving as an advisor to a Nomcom dis= qualifies you from being returned by that Nomcom -=C2=A0https://tools.ietf.org/html/rfc743= 7#section-4.8 sidesteps that for liaisons, but there's not text tha= t I can find that does the same for advisors.

Give= n that Alissa has already kicked off IASA 2.0, I'm thinking that it'= ;s fairly likely that carefully tuned text that addresses all the corner ca= ses we can think of, =C2=A0would be Overtaken By Events before it gets used= . So, I wrote this as being permissive ("Nomcoms can ask for advisors,= and IAOCs can provide advisors"), and assumed that the worst conseque= nces I can imagine could be challenged by the Nomcom membership.
=
Your mileage may vary, of course.
=C2=A0

I consider that p= referable to allowing the IAOC to send someone who might not have the right= reading of the current dynamic.

I'm sympathetic to this point of view, but note that I ser= ved as the IAB's liaison to Nomcom during my first year on the IAB, and= it's certainly arguable that the recently departed IAB members probabl= y knew more about the IAB than I did, just a few months in :-) ...

Spencer

It should not be the cas= e that this advisor role is a significant additional burden on the workload= .

=C2=A0<= /p>

Thanks,

Adrian

=C2=A0

From: ietf-nomcom [mailto:ietf-nomcom-bounces@= ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: 0= 2 August 2017 22:31
To: NomCom-Discussion
Cc: Alexey Me= lnikov
Subject: [ietf-nomcom] Fwd: New Version Notification for d= raft-dawkins-iesg-nomcom-advisor-iaoc-00.txt

<= /div>

=C2= =A0

Dear Nomcom Process Devotees,<= /u>

=C2=A0

Alissa has asked me to put together a short(!) dra= ft that will remind future Nomcoms to request IAOC to provide an Advisor.

=C2=A0

<= /div>

Details are below.

=

=C2=A0

I'd like to discuss this draft on this mailing list initiall= y.

=C2=A0<= /p>

Please comment and question as appropr= iate.

=C2=A0

Thanks,

=C2=A0

Spencer

= =C2=A0

---------- Forwarded message ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Wed, Aug 2, 2017 at 4:27 PM
Subject: New Version Notifi= cation for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
To: Spence= r Dawkins <spencerdawkins.ietf@gmail.com>



A new versi= on of I-D, draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt
has been s= uccessfully submitted by Spencer Dawkins and posted to the
IETF reposito= ry.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-dawkins-iesg= -nomcom-advisor-iaoc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Titl= e:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB, IESG, and IAOC Selection, Confirm= ation, and Recall Process: IAOC Advisor for the Nominating Committee
Doc= ument date:=C2=A0 2017-08-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In= dividual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-dawkins-iesg-nomc= om-advisor-iaoc-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-dawkins= -iesg-nomcom-advisor-iaoc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-dawkins-ies= g-nomcom-advisor-iaoc-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html= /draft-dawkins-iesg-nomcom-advisor-iaoc-00


Abstract:=C2=A0 =C2=A0This specification formalizes an ad hoc practice used to prov= ide
=C2=A0 =C2=A0advice to the IETF Nominating Committee about the opera= tions of the
=C2=A0 =C2=A0IETF Administrative Oversight Committee.
=C2=A0 =C2=A0This document updates RFC 7437.




Please no= te that it may take a couple of minutes from the time of submission
unti= l the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0

=

--001a11c019fa3c89980555dce487-- From nobody Thu Aug 3 10:53:08 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 93C06131D1D for ; Thu, 3 Aug 2017 10:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 WxwiTkiUYwtX for ; Thu, 3 Aug 2017 10:53:05 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 51DF3131CEA for ; Thu, 3 Aug 2017 10:53:05 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id p68so13130867ywg.0 for ; Thu, 03 Aug 2017 10:53:05 -0700 (PDT) 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=hhHzENWkLEXE27TfEvlHSSyTKJ4lnCOgkjEGjP4RMw0=; b=trczZZuqQztfz3XE2mUj9pi+0tXbz7ucjcMViqoj73ES/Pcz4pkqtpThzplTIV0MbA lQ9sgWzg/B5OztkIKLg26gUsyNXl2Tbs/1eT9tBnTwA/IoZuefTqfg357vfCPNH+v6NT 7n7tgHC/orhaWoUQZPIzM6kP8LYTSRTFEMla15aa9TgRlefmvV+gxzugSt+Xa0wr8AUr vlobBrRb4/9VN0pmsr9iu2AWkuaG7drBO4SjPLphmAJAZO9j30KfSgf3I9AZ+ELBgokG osPkWu+4mYkf6vY1PLlkrJ8AGDgeVieeNxa+L/9KOA7j7VUS8v21rMZPmZPn97Lr5vxs sqsA== 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=hhHzENWkLEXE27TfEvlHSSyTKJ4lnCOgkjEGjP4RMw0=; b=EIwsAsmyAo5dTSdjVVWW7vjvySgwGcESv2mlZaH0kLFL6CAQV9cKbNbl7hZg0VDSbU WUSYFYStitaKQNr7X0I201qEo9aE9L7u2Mdy7J5LlrBxiGfBL3QjV1ymsuaj9s65R9iU 73/UbqpFBsczGTra7OYYIyYnnBLzy2PMUfHNIOaX/blNb3gsJf4pPhzHpQqtY0W06gIX kqZNuz0X6klGenY5ydzo5qaMkpYF54ebd0+1nvuETMAHiA6f92uSvDMHOyw/XGYkiWTd phD5c6rlyntjNiwLDvy3rtLvyUTUwClA1x1YCvk9YKGh1e6IBsy2YZ9txAk8LjUAU3nk VksA== X-Gm-Message-State: AIVw110prcx/lA39os5uJYNkhL4axIMKBD3Dn65iCUQnUR4BSGXAh3M9 roa+HWe7FfsXq2mcj8bCD7qaVH7oCA== X-Received: by 10.37.105.82 with SMTP id e79mr1949685ybc.39.1501782784456; Thu, 03 Aug 2017 10:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Thu, 3 Aug 2017 10:53:03 -0700 (PDT) In-Reply-To: <18658F3EEA38067A4230D855@PSB> References: <18658F3EEA38067A4230D855@PSB> From: Spencer Dawkins at IETF Date: Thu, 3 Aug 2017 12:53:03 -0500 Message-ID: To: John C Klensin Cc: NomCom-Discussion , Alexey Melnikov Content-Type: multipart/alternative; boundary="94eb2c14e02865c19e0555dd0dd0" Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Thu, 03 Aug 2017 17:53:08 -0000 --94eb2c14e02865c19e0555dd0dd0 Content-Type: text/plain; charset="UTF-8" Hi, John, On Thu, Aug 3, 2017 at 12:01 PM, John C Klensin wrote: > > > --On Wednesday, August 2, 2017 16:30 -0500 Spencer Dawkins at > IETF wrote: > > > Dear Nomcom Process Devotees, > > > > Alissa has asked me to put together a short(!) draft that will > > remind future Nomcoms to request IAOC to provide an Advisor. > > > > Details are below. > > > > I'd like to discuss this draft on this mailing list initially. > > > > Please comment and question as appropriate. > > Spencer, > > While I concur with those who have indicated that this draft is > ok (or close) assuming that is what the community wants to do, I > want to raise a question about the latter that may or may not be > directly relevant to the document. > > As time has passed and the Nomcom has apparently become > increasingly dependent on questionnaires, interviews, and > Advisors rather than first-hand knowledge of possible candidates > by the voting members, questions of influences on the Nomcom > become increasingly important. For the Nomcom to invite someone > from a particular body to attend a meeting or call to offer > advice on specific issues (consistent with RFC 7437 Section 4.3, > second paragraph), a standing Advisor (or Liaison) role is > another matter and, other than the technical considerations > about oversight of the Nomcom process and the "sitting member" > requirements that you describe in Section 4 of the I-D, it is > not clear that you (and the draft) anticipate any difference in > practice. > I'm definitely working the "series of incremental updates" side of the street. I understand your concerns (below), and agree with about three quarters of them without further discussion. These concerns do go quite a bit beyond what Alissa asked me to work on, but I will pass this along to the rest of the IESG and see what they think. Thanks for the input. Spencer > My concern about all of these roles is the potential for the > appearance of undue influence. Is a particular Liaison or > Advisor likely to defend a colleague in the same organization? > Or exaggerate faults to get rid of one who is personally > unpopular with the Liaison or Advisor (or even the whole body)? > Is the presence of an incumbent likely to have a chilling effect > on a community member who wants to make a well-thought-out > argument for, e.g., throwing as many of the incumbents out as > possible and starting over on that body? (I know the answer to > the latter is "yes", the only questions are how widespread and > important it is).) When the Nomcom was first designed and the > community assumed that a significant number, perhaps most, of > its members would have sufficient experience with likely > candidates, that was, itself, a safeguard against abuses. Now, > that is not so clear. > > So it seems to me that we should be at least considering: > > (1) Encouraging Nomcoms to ask whatever questions about > operation, job requirements, etc., seem appropriate of various > bodies without needing to rely on Liaisons or Advisors for that > rule. > > (2) Trying to figure out how to isolate Liaisons and Advisors > from input (especially informal input) to the Nomcom about the > membership, operations at a personal level, and possible > candidates for their (and probably other) bodies and to do so in > a way that increases community confidence that the Nomcom is > seeking out and considering all of the information it wants or > needs rather than even potentially being unduly influenced by > representatives of bodies to which it is making appointments. > While I agree with the observations about allowing an IAD to > influence appointments to the body that hires and oversees him > or her, very nearly the same observation could apply to allowing > an IAB or IESG member to influence choices of people he or she > will ultimately need to work, with, who will support or impede > their agendas, etc. > > (3) Encourage the Nomcom to invite Liaisons or Advisors to only > participate in discussions for which they are directly and > obviously relevant and, in the interest of transparency and > increased confidence in the process, document those choices for > the community > > (4) More than 20 years into the current model, perhaps many of > the same arguments apply to "sitting members" of other bodies > that you have made for the IAOC appointee. Similarly, perhaps > it is time to consider whether the job of overseeing the > propriety of the Nomcom process ought to be linked with giving > the Nomcom advice about particular bodies or even particular > candidates or appointments. > > best, > john > > --94eb2c14e02865c19e0555dd0dd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, John,

On Thu, Aug 3, 2017 at 12:01 PM, John C Klensin = <john@jck.com><= /span> wrote:


--On Wednesday, August 2, 2017 16:30 -0500 Spencer Dawkins at
IETF <= spencerdawkins.ietf@gmail.com> wrote:

> Dear Nomcom Process Devotees,
>
> Alissa has asked me to put together a short(!) draft that will
> remind future Nomcoms to request IAOC to provide an Advisor.
>
> Details are below.
>
> I'd like to discuss this draft on this mailing list initially.
>
> Please comment and question as appropriate.

Spencer,

While I concur with those who have indicated that this draft is
ok (or close) assuming that is what the community wants to do, I
want to raise a question about the latter that may or may not be
directly relevant to the document.

As time has passed and the Nomcom has apparently become
increasingly dependent on questionnaires, interviews, and
Advisors rather than first-hand knowledge of possible candidates
by the voting members, questions of influences on the Nomcom
become increasingly important.=C2=A0 For the Nomcom to invite someone
from a particular body to attend a meeting or call to offer
advice on specific issues (consistent with RFC 7437 Section 4.3,
second paragraph), a standing Advisor (or Liaison) role is
another matter and, other than the technical considerations
about oversight of the Nomcom process and the "sitting member" requirements that you describe in Section 4 of the I-D, it is
not clear that you (and the draft) anticipate any difference in
practice.

I'm definitely working th= e "series of incremental updates" side of the street.=C2=A0
=

I understand your concerns (below), and agree with abou= t three quarters of them without further discussion.=C2=A0

These concerns do go quite a bit beyond what Alissa asked me to wo= rk on, but I will pass this along to the rest of the IESG and see what they= think.

Thanks for the input.

=
Spencer
=C2=A0
My conce= rn about all of these roles is the potential for the
appearance of undue influence.=C2=A0 Is a particular Liaison or
Advisor likely to defend a colleague in the same organization?
Or exaggerate faults to get rid of one who is personally
unpopular with the Liaison or Advisor (or even the whole body)?
Is the presence of an incumbent likely to have a chilling effect
on a community member who wants to make a well-thought-out
argument for, e.g., throwing as many of the incumbents out as
possible and starting over on that body?=C2=A0 (I know the answer to
the latter is "yes", the only questions are how widespread and important it is).)=C2=A0 =C2=A0When the Nomcom was first designed and the community assumed that a significant number, perhaps most, of
its members would have sufficient experience with likely
candidates, that was, itself, a safeguard against abuses.=C2=A0 Now,
that is not so clear.

So it seems to me that we should be at least considering:

(1) Encouraging Nomcoms to ask whatever questions about
operation, job requirements, etc., seem appropriate of various
bodies without needing to rely on Liaisons or Advisors for that
rule.

(2) Trying to figure out how to isolate Liaisons and Advisors
from input (especially informal input) to the Nomcom about the
membership, operations at a personal level, and possible
candidates for their (and probably other) bodies and to do so in
a way that increases community confidence that the Nomcom is
seeking out and considering all of the information it wants or
needs rather than even potentially being unduly influenced by
representatives of bodies to which it is making appointments.
While I agree with the observations about allowing an IAD to
influence appointments to the body that hires and oversees him
or her, very nearly the same observation could apply to allowing
an IAB or IESG member to influence choices of people he or she
will ultimately need to work, with, who will support or impede
their agendas, etc.

(3) Encourage the Nomcom to invite Liaisons or Advisors to only
participate in discussions for which they are directly and
obviously relevant and, in the interest of transparency and
increased confidence in the process, document those choices for
the community

(4) More than 20 years into the current model, perhaps many of
the same arguments apply to "sitting members" of other bodies
that you have made for the IAOC appointee.=C2=A0 Similarly, perhaps
it is time to consider whether the job of overseeing the
propriety of the Nomcom process ought to be linked with giving
the Nomcom advice about particular bodies or even particular
candidates or appointments.

best,
=C2=A0 =C2=A0john


--94eb2c14e02865c19e0555dd0dd0-- From nobody Tue Aug 8 19:45:17 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 73C351320A6; Tue, 8 Aug 2017 19:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 d73XKo6gJJgw; Tue, 8 Aug 2017 19:45:06 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 831B912426E; Tue, 8 Aug 2017 19:44:54 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l82so32434220ywc.2; Tue, 08 Aug 2017 19:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Syn2gSc1UCMWj7rMNNxYnLVxkYwgM0BbUVkQcA+H6Bk=; b=KldqT52TOM3sATMoz2kVwEsq6P71iW63wjn56NEHDOlsDPbGpbMIxCwOYy0Xz+qJSA /zXpDNSZPxBX7nk2k8ntfOUVUKSz091/21Do9UVBEuflrSje3Z8pjo7RW5prcF8QIiSg Rg8VNmGirionsFzVKWU4Nd2WKOMIRnRjKcdk8DF9ykNSD2aL7tyo2Q+19jWc+MaQpsMr uxV2rRKLa4GGQKb5e0QO0xRmtxTeqSP5mxxGZ9+Ugt4DkR0+dn7K+2+dI9MMS1ZEik3u 8yEZYHW1y8hE6elWRbPT5wxVTcpCJKMnXWMppdHZZs02uVMvZzWBa+qON/KbiQjeN0Jt z8VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Syn2gSc1UCMWj7rMNNxYnLVxkYwgM0BbUVkQcA+H6Bk=; b=Lx91DGqeyvUeDrtqDVzAgt1crX/yLUjdSrnj7RFZp3Cj29ow59EBNWu0or15pp3SUR eSWO2R/tVide6Mwov0mG5tX05tZ2mUAcUHXGuxZg0T6x6SRabz9g/xh8HIaG7GOH86Dv XhpKT3aRU/sxwuYMlOi2LYmKVxF/0u4PWbLYh7F8hsYTb1jD2R50E9NnFCkP9lGaGQMY q4VSMgCf5VnNqTzNF1bm9pP4jibeE4ilTXj4Z9JINReAaEaYGtAUOcY7Hq0cL78bW4TX cAgUDwEEOT/5qbUHNGi5PXxNXssjazJdgpwHs31vvG1LR6uNU8G23hkXXcYFXnptQaXc fxDw== X-Gm-Message-State: AHYfb5gfFphIrSwF1DnzJoTEHyErovfzUo0ME0vXLmdqmIxj6Sl8ss1x EeFN08n0hBU25axTnwksOqKpqzBA42zH X-Received: by 10.37.105.82 with SMTP id e79mr5272196ybc.39.1502246693538; Tue, 08 Aug 2017 19:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Tue, 8 Aug 2017 19:44:53 -0700 (PDT) From: Spencer Dawkins at IETF Date: Tue, 8 Aug 2017 21:44:53 -0500 Message-ID: To: "ietf@ietf.org" Cc: "iesg@ietf.org" , NomCom-Discussion Content-Type: multipart/alternative; boundary="94eb2c14e02888976b055649101d" Archived-At: Subject: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 02:45:09 -0000 --94eb2c14e02888976b055649101d Content-Type: text/plain; charset="UTF-8" Dear all, At Alissa Cooper's request, I put together a short draft that updates BCP 10, the Nomcom process, adding a reminder that Nomcoms can ask the IAOC to provide an advisor, and the IAOC can provide one. Yeah, I thought that was already in BCP 10, but it's not :-) ... For your reading pleasure, the draft is available at URL: https://www.ietf.org/internet-drafts/draft-dawkins-iesg- nomcom-advisor-iaoc-01.txt Status: https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomcom- advisor-iaoc/ Htmlized: https://tools.ietf.org/html/draft-dawkins-iesg-nomcom- advisor-iaoc-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-dawkins-iesg- nomcom-advisor-iaoc-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-dawkins-iesg- nomcom-advisor-iaoc-01 BUT please send questions and comments to the (public) IETF-Nomcom mailing list, which is intended for conversations about BCP 10 updates. If you're not already subscribed to that mailing list, the URL for it is https://www.ietf.org/mailman/listinfo/ietf-nomcom. Alexey Melnikov has graciously agreed to AD-sponsor the draft. Thanks, Spencer, as an individual --94eb2c14e02888976b055649101d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

At Alissa Cooper's reques= t, I put together a short draft that updates BCP 10, the Nomcom process, ad= ding a reminder that Nomcoms can ask the IAOC to provide an advisor, and th= e IAOC can provide one.=C2=A0

Yeah, I thought that= was already in BCP 10, but it's not :-) ...

F= or your reading pleasure, the draft is available at=C2=A0


BUT ple= ase send questions and comments to the (public) IETF-Nomcom mailing list, w= hich is intended for conversations about BCP 10 updates.=C2=A0
If you're not already subscribed to that mailing list, the= URL for it is=C2=A0https://www.ietf.org/mailman/listinfo/ietf-nomcom.
Alexey Melnikov has graciously agreed to AD-sponsor the draft.<= /div>

Thanks,

Spencer, as an in= dividual
--94eb2c14e02888976b055649101d-- From nobody Wed Aug 9 08:27:10 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 D21E81323C1; Wed, 9 Aug 2017 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 saaDd_M3Y2xH; Wed, 9 Aug 2017 08:27:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69CA1323B3; Wed, 9 Aug 2017 08:27:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EED8920567; Wed, 9 Aug 2017 11:29:20 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 97A8D806BA; Wed, 9 Aug 2017 11:27:05 -0400 (EDT) From: Michael Richardson To: "ietf\@ietf.org" , NomCom-Discussion , "iesg\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 15:27:09 -0000 --=-=-= Content-Type: text/plain Spencer Dawkins at IETF wrote: > At Alissa Cooper's request, I put together a short draft that updates BCP 10, > the Nomcom process, adding a reminder that Nomcoms can ask the IAOC to > provide an advisor, and the IAOC can provide one. The other entities provide liasons, and I see that your document explains why an advisor is listed. I understand that the word "advisor" is from BCP10, and allows the nomcom to add advisors to the nomcom. I'd call this an "import", because the nomcom pulls someone in. The other liason are not nomcom decisions, and so there is some subtle distinction. It's also not clear to be that we want the NOMCOM to ask for an IAOC advisor, or if we the IAOC appoints someone. The previous tradition was the IAOC appointed someone, and they gave us Ole even after he was no longer a seated IAOC member. As a voting member and chair, I found the IAOC (liason) very useful in explaining not only what the IAOC does, but also what the IAB and IESG do not do, even when sometimes IAOC activities get relayed via IETF Chair or IAB chair. Many voting members are ignorant of the IAOC and sometimes look for characteristics in an IESG or IAB member that would be more appropriate for IAOC. So I strongly agree with always having an IAOC liason/advisor, even when not appointing someone directly to the IAOC. {nomcom: 2002,2012,2013. chair: 2014} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmLKckACgkQgItw+93Q 3WWZJQf9Gz/jrxzQ6dQ8R5fdtPkwgSayBM09fqjRKkI0uN+M37xI/uQ+z+g1PPQr wgi0/X8mtsYm2TjsZZD6Y2QiEFFmUV/bwB+vueetNqo7kiayxYIZqSTs3UjQ4ewe 9nSToM4xUF83Ao5KUXBZgK+LKqVX7ngbOXNm/vspig03S1dM4PPltswmbJPhPiiK EhTr/XwaCDY9sAWIPwFnfmVCC4iVyq6z3vpSdKDUmwUPsM8EEle6iNI7PU3xQNNb 3RJhPrbp23+LZgEJcLDhGguPGtQGkwRzBy12Pt+9fpN//cv/IdWBHj4kGWfAiG+V lB630K2ltyxHEz0r4i87XT0BjgdTlQ== =/SHU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 9 09:04: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 5797D1323CB for ; Wed, 9 Aug 2017 09:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=WqqbyR3t; dkim=pass (1024-bit key) header.d=elandsys.com header.b=TG+KRzP8 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 9ZH3GpAYdY5w for ; Wed, 9 Aug 2017 09:04:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1E1323A6 for ; Wed, 9 Aug 2017 09:04:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.53.59]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v79G3ouS014306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2017 09:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1502294641; x=1502381041; bh=VS2QYmoZTB0T3ZiMQrJ6xzCivKxkaAIpulx+MQ2yH5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WqqbyR3t5Ry+D9s+AwlyfvMgSHs903IjFQWp6YqFnadm1USqZ2RJq9M3j2I1QiwY+ +9JtT1pMHrJ8vfGOc5L1/EGFvwsSHLz8vsQtpCfScOYWYgpxAEOOJb+kkTFgiuZwDI zHuXmvNaWBRbFhWdMD/UEAigvfgVHhbSJk5ZFEdY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1502294641; x=1502381041; i=@elandsys.com; bh=VS2QYmoZTB0T3ZiMQrJ6xzCivKxkaAIpulx+MQ2yH5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TG+KRzP87VjfoEuYJlB/zqg/mZZq+ArUc1lzR9qPuPTUEE+ljvA89h4MafmXLx+Mv QRNJUJGZQmgrWNUHunjQV3lveiyjFqicLzMkJlMbwMdmyBuBz1xSWevXiCJXtWd6Fr m3LOYmfF61BMqfcRQ4HIk8abVRaXM31gLj5axmsQ= Message-Id: <6.2.5.6.2.20170809085713.0df50b60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Aug 2017 09:03:34 -0700 To: Spencer Dawkins at IETF From: S Moonesamy Cc: ietf-nomcom@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 16:04:10 -0000 Hi Spencer, [Cc trimmed] At 19:44 08-08-2017, Spencer Dawkins at IETF wrote: >At Alissa Cooper's request, I put together a short draft that >updates BCP 10, the Nomcom process, adding a reminder that Nomcoms >can ask the IAOC to provide an advisor, and the IAOC can provide one. The new text in Section 6.1 says: ""may propose the addition of an advisor" in the first paragraph and "Committee members are encouraged to propose the addition of an advisor" in the second paragraph. I read that as meaning that the editor is saying two slightly different things. Regards, S. Moonesamy From nobody Wed Aug 9 10:06:05 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 96058132423; Wed, 9 Aug 2017 10:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 UfAeOgEyPMoW; Wed, 9 Aug 2017 10:05:46 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 738ED132417; Wed, 9 Aug 2017 10:05:46 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id s143so43782298ywg.1; Wed, 09 Aug 2017 10:05:46 -0700 (PDT) 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=SK8TW0apcHwTr5i9DWY+777K6aSL8WgwbeDc7KMBWVE=; b=Xck6YL+Z3cJc9AC2FfQ6r59QiIXbu9bwt03KkPs6qvoFlmdb1BuBlTkiKf53nxsjTi jYnrvQSCmdamtd2WzGJi+BH7FGL77W4n25wvnfjTHK+PxJ0rEnr13D2FRbSPZ/ZHaBQO CPeIm8iGlP0/zAF/AitYHSvecFHJKf4FJ4c1QIGQk1LS8qx7wKAm9I0I/KuNGwCzZAoI YfdmSOq/bIUkT06hm4ICXQ5LawjDfkFquIXKmzZwjh1Bd4W47jgNYLOjLPXURRgLI7yL qDNvfNC9vUjQlhsbfDJio5LyazXIrstYXFD5j+7DxWdnBSyI5Syd+vOBbdwpO16M0N/7 WuXg== 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=SK8TW0apcHwTr5i9DWY+777K6aSL8WgwbeDc7KMBWVE=; b=jwwL8F41fo90zZD8ozD+jblku5H4236c2MnS15reylLPLuANOIIQGR1vCEeePPVw8G 5EgVK9e33kHUpTqoRrdyCjWX+LP5TCQM7ES3Ka7cBgWYCEzmsLJ7FSTXfobAVehz8Odd O45QoWpEAokMYwTp1l4VChCNArIfWTKqhwJ6IML6T91hxLZaFC6/O7GFnqoQ5wMBZJzY LxEN5gEGZfAT0+XyOIs4k9QSqy1Sly8KpSiz/D36LG2/3YpSOeiktkP5r82AsKbPL05K 9Yzqr8D/MwzJlDUl19ujg9HneRO2gH5CIKvSnrGGd8yeh+lHhqdU4ficcx/qzdRmL1sn S6ug== X-Gm-Message-State: AHYfb5gKhNSl7IlKjIZUlgr6ukaisk09qpM5d7OEz6t4dSoYPUdYn8fM cVKn0dkz1N4VQTmSf3Cbj5g4yiizOPy0 X-Received: by 10.37.38.146 with SMTP id m140mr7080299ybm.66.1502298345408; Wed, 09 Aug 2017 10:05:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 10:05:44 -0700 (PDT) In-Reply-To: <4622.1502292425@obiwan.sandelman.ca> References: <4622.1502292425@obiwan.sandelman.ca> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 12:05:44 -0500 Message-ID: To: Michael Richardson Cc: "ietf@ietf.org" , NomCom-Discussion , "iesg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18f336398f5f055655173b" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 17:05:49 -0000 --94eb2c18f336398f5f055655173b Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson wrote: > > Spencer Dawkins at IETF wrote: > > At Alissa Cooper's request, I put together a short draft that > updates BCP 10, > > the Nomcom process, adding a reminder that Nomcoms can ask the IAOC > to > > provide an advisor, and the IAOC can provide one. > > The other entities provide liasons, and I see that your document explains > why > an advisor is listed. I understand that the word "advisor" is from > BCP10, > and allows the nomcom to add advisors to the nomcom. I'd call this an > "import", because the nomcom pulls someone in. > Yeah. I'm kind of dancing here, because I'm trying to reuse terminology in a new and exciting(?) way. This document could - Remind the Nomcom that they will probably need help understanding what the IAOC does, so they should ask, OR - Tell the IAOC to appoint (let's call it) an Advisor, at the same time the IAB and IESG are appointing liaisons. The first option is where I headed, because I tend to write permissive BCP text ("BCP text is hard to get right"). The second option would probably appear in a new section that looks a lot like https://tools.ietf.org/html/rfc7437#section-4.8, except that the eligibility would be different. I'd be OK doing that, if it makes sense to others. For extra credit, https://tools.ietf.org/html/rfc7437#section-4.3 could actually require that an IAOC advisor be named, at the same level of "required" that the IAB and IESG liaisons are required. There would be more text changes going this way (but, see below). > > The other liason are not nomcom decisions, and so there is some subtle > distinction. > > It's also not clear to be that we want the NOMCOM to ask for an IAOC > advisor, > or if we the IAOC appoints someone. The previous tradition was the IAOC > appointed someone, and they gave us Ole even after he was no longer a > seated > IAOC member. > > As a voting member and chair, I found the IAOC (liason) very useful in > explaining not only what the IAOC does, but also what the IAB and IESG do > not > do, even when sometimes IAOC activities get relayed via IETF Chair or IAB > chair. Many voting members are ignorant of the IAOC and sometimes look for > characteristics in an IESG or IAB member that would be more appropriate > for IAOC. > So I strongly agree with always having an IAOC liason/advisor, even when > not > appointing someone directly to the IAOC. > I'm willing to make this position a requirement, if that's the right answer. It's optional in the current draft. > {nomcom: 2002,2012,2013. chair: 2014} Thanks for your continued review and advice. I'm {nomcom: 2011 liaison}, so appreciate people with more, and especially more recent, experience telling me what they're thinking. Spencer --94eb2c18f336398f5f055655173b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson <mcr= +ietf@sandelman.ca> wrote:

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > At Alissa Cooper's request, I put together a short d= raft that updates BCP 10,
=C2=A0 =C2=A0 > the Nomcom process, adding a reminder that Nomcoms can a= sk the IAOC to
=C2=A0 =C2=A0 > provide an advisor, and the IAOC can provide one.

The other entities provide liasons, and I see that your document exp= lains why
an advisor is listed.=C2=A0 =C2=A0 I understand that the word "advisor= " is from BCP10,
and allows the nomcom to add advisors to the nomcom. I'd call this an "import", because the nomcom pulls someone in.

Yeah. I'm kind of dancing here, because I'm tryin= g to reuse terminology in a new and exciting(?) way.=C2=A0

This document could
  • Remind the Nomcom that they = will probably need help understanding what the IAOC does, so they should as= k, OR
  • Tell the IAOC to appoint (let's call it) an Advisor, at t= he same time the IAB and IESG are appointing liaisons.
Th= e first option is where I headed, because I tend to write permissive BCP te= xt ("BCP text is hard to get right").

Th= e second option would probably appear in a new section that looks a lot lik= e=C2=A0https://= tools.ietf.org/html/rfc7437#section-4.8, except that the eligibility wo= uld be different. I'd be OK doing that, if it makes sense to others.

For extra credit,=C2=A0https://tools.ietf.org/html/rfc7437#se= ction-4.3 could actually require that an IAOC advisor be named, at the = same level of "required" that the IAB and IESG liaisons are requi= red. There would be more text changes going this way (but, see below).

The other liason are not nomcom decisions, and so there is some subtle dist= inction.

It's also not clear to be that we want the NOMCOM to ask for an IAOC ad= visor,
or if we the IAOC appoints someone.=C2=A0 The previous tradition was the IA= OC
appointed someone, and they gave us Ole even after he was no longer a seate= d
IAOC member.

As a voting member and chair, I found the IAOC (liason) very useful in
explaining not only what the IAOC does, but also what the IAB and IESG do n= ot
do, even when sometimes IAOC activities get relayed via IETF Chair or IAB chair.=C2=A0 Many voting members are ignorant of the IAOC and sometimes loo= k for
characteristics in an IESG or IAB member that would be more appropriate for= IAOC.
So I strongly agree with always having an IAOC liason/advisor, even when no= t
appointing someone directly to the IAOC.

I'm willing to make this position a requirement, if that's the ri= ght answer. It's optional in the current draft.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">{nomcom: 2002,2012,2013. c= hair: 2014}

Thanks for your continued revie= w and advice. I'm {nomcom: 2011 liaison}, so appreciate people with mor= e, and especially more recent, experience telling me what they're think= ing.

Spencer=C2=A0
--94eb2c18f336398f5f055655173b-- From nobody Wed Aug 9 10:10: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 964AA132350 for ; Wed, 9 Aug 2017 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 u1ikc37lBqSa for ; Wed, 9 Aug 2017 10:10:20 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 7D2EA132256 for ; Wed, 9 Aug 2017 10:10:20 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id s143so43859811ywg.1 for ; Wed, 09 Aug 2017 10:10:20 -0700 (PDT) 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=wrO9VqAuYIfv4sqxQHpCQP5pxo/37RVSHCt+7WrcIO4=; b=AuthRQHbelz3jIPe/z1QQvdUn8LWoUB9h3BOaYeuWpRU/e2o2cBbsMRZYSFafkNgzQ g9OM2HEhiCr501Exe9nsIO9pdNGrFTNRWdq+pxliLX47ivTLa22EHwQbomqXSF61axwc ZVXsQQ5/V0wvwGwhO4+AY40UHjs5tR53MwqPugwYy6O8mIaWJ1sB7Y+iDhJn2vzIh9/m QtRqSuetluSPp9tHFnp4lII3FkSJwrYJBsQiCcdiDPjDrRf7w3t8ncAUSYb8Fw6Rj0pU JDiddAmNaBC7nrIuNGlsD+BXQgAeZs/rgU7vNtjhw6Ucz4/e4QJA46xQS+667cwE/ACT Tvow== 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=wrO9VqAuYIfv4sqxQHpCQP5pxo/37RVSHCt+7WrcIO4=; b=W9kiMAsnfkAEY5cKUduoO0MH0lXg5MKt6SymFWPDPwL5c5UEH7mdDspkteYW4QhMnP MDqmuWdlqLj6LmbyAf57NNRTj1hK1TiGqYTQpJ+cz5UINby9K11laEikP0+gOK5XYRp2 kyqgv2Bf7/oUjGfj08a7b1uVKd0wlfjjWWGPsUShH5+bNlEff29NFjeASqcogEq+WLwJ b8uSFc0/7Qx4sJ4jTFzUTPTd6xB4TSjPRa2S+YUKg+dTgN/5NhZfW0+wLEVj3ZeTfaZC 3UJGVceyvPJggZ2vBPoC+X9anGUELEXnLCUvBJHgwwRF/Hrd/5IWtSBPnm51p/m5flKM lAeQ== X-Gm-Message-State: AHYfb5hSgLLDwDVpaYtdwbOvJQFFsnOlkrkTrsQ/QdhGTjao4WmUdYxh aHU/AJBlZCSbVAnTmHNkFYJUnCvZgA== X-Received: by 10.129.141.9 with SMTP id d9mr3045284ywg.339.1502298619377; Wed, 09 Aug 2017 10:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 10:10:18 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20170809085713.0df50b60@elandnews.com> References: <6.2.5.6.2.20170809085713.0df50b60@elandnews.com> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 12:10:18 -0500 Message-ID: To: S Moonesamy Cc: NomCom-Discussion Content-Type: multipart/alternative; boundary="f403045e60128e19c70556552757" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 17:10:28 -0000 --f403045e60128e19c70556552757 Content-Type: text/plain; charset="UTF-8" Hi, SM, On Wed, Aug 9, 2017 at 11:03 AM, S Moonesamy wrote: > Hi Spencer, > > [Cc trimmed] > > At 19:44 08-08-2017, Spencer Dawkins at IETF wrote: > >> At Alissa Cooper's request, I put together a short draft that updates BCP >> 10, the Nomcom process, adding a reminder that Nomcoms can ask the IAOC to >> provide an advisor, and the IAOC can provide one. >> > > The new text in Section 6.1 says: ""may propose the addition of an > advisor" in the first paragraph and "Committee members are encouraged to > propose the addition of an advisor" in the second paragraph. I read that > as meaning that the editor is saying two slightly different things. I think you're reading that part correctly. The problem is, that the editor wasn't saying two slightly different things clearly :-( The first paragraph is intended to say "you can do this", and the second paragraph is intended to say, "you don't have to do this, but you really want to". So, something needs to change. Let's see where the conversation in Michael's thread ends up, because if the role becomes required, that text changes significantly anyway, but thanks for the usual careful read - you're right. Spencer --f403045e60128e19c70556552757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, SM,

On Wed, Aug 9, 2017 at 11:03 AM, S Moonesamy <<= a href=3D"mailto:sm+ietf@elandsys.com" target=3D"_blank">sm+ietf@elandsys.c= om> wrote:
Hi Spencer,

[Cc trimmed]

At 19:44 08-08-2017, Spencer Dawkins at IETF wrote:
At Alissa Cooper's request, I put together a short draft that updates B= CP 10, the Nomcom process, adding a reminder that Nomcoms can ask the IAOC = to provide an advisor, and the IAOC can provide one.

 The new text in Section 6.1 says: ""may propose the addition of a= n advisor" in the first paragraph and "Committee members are enco= uraged to propose the addition of an advisor" in the second paragraph.= =C2=A0 I read that as meaning that the editor is saying two slightly differ= ent things.

I think you're reading that= part correctly. The problem is, that the editor wasn't saying two slig= htly different things clearly :-(

The first paragr= aph is intended to say "you can do this", and the second paragrap= h is intended to say, "you don't have to do this, but you really w= ant to".

So, something needs to change. Let&#= 39;s see where the conversation in Michael's thread ends up, because if= the role becomes required, that text changes significantly anyway, but tha= nks for the usual careful read - you're right.

Spencer=C2=A0
--f403045e60128e19c70556552757-- From nobody Wed Aug 9 12:02:25 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 DA52213247C; Wed, 9 Aug 2017 12:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 pTvhWKNRvjQk; Wed, 9 Aug 2017 12:02:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1954132471; Wed, 9 Aug 2017 12:02:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8506C2009E; Wed, 9 Aug 2017 15:04:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A6308806BA; Wed, 9 Aug 2017 15:02:13 -0400 (EDT) From: Michael Richardson To: Spencer Dawkins at IETF cc: "ietf\@ietf.org" , NomCom-Discussion , "iesg\@ietf.org" In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 19:02:17 -0000 --=-=-= Content-Type: text/plain Spencer Dawkins at IETF wrote: > Yeah. I'm kind of dancing here, because I'm trying to reuse terminology in a > new and exciting(?) way. understood. > This document could > * Remind the Nomcom that they will probably need help understanding what the > IAOC does, so they should ask, OR > * Tell the IAOC to appoint (let's call it) an Advisor, at the same time the > IAB and IESG are appointing liaisons. > The first option is where I headed, because I tend to write permissive BCP > text ("BCP text is hard to get right"). I think that I'd prefer the IAOC be told to pick someone, but I'm listening to other opinions. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmLXDUACgkQgItw+93Q 3WVv+ggAsX+CK4dS6Y+N1wj/0dAjOUa21v0uV8zD4XtdhsXDGB23G2Lq+MLJrBbt c4PdW7FGH0otkYhELWq6YRT/zrrW4TiaftBezMckAEt7xAD0K9F+GgSdSDiPfdii aaiULRp0CKUofyvBec/y1mjhjhP4aG7dB/+kYnO1LX8XtrFmtneNZopo73+Kd+bM NciXQA1pGSFYve79DtsM+HRuJdY98X4Ok0Z/T8muDPDecx0j7V9xSRPh9PtvGEKz 81kSgI//GUB31A0QWSDN1XBbgk6RZ/T5/3oQwgRlp0TanBSUmlBngZrzU8a/Ii/v i2OqjmiPlzm8yTWoirFriWlqCc4QWA== =fuMF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 9 12:32:37 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 C599813249B for ; Wed, 9 Aug 2017 12:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 Jez4AGnd2Kud for ; Wed, 9 Aug 2017 12:32:33 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 19A35132489 for ; Wed, 9 Aug 2017 12:32:32 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id s143so46160821ywg.1 for ; Wed, 09 Aug 2017 12:32:32 -0700 (PDT) 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=2HnP32V8NKqRnrKVK8LAOiKgwBTC0Pkxmc3dy/6+s3A=; b=u0Q9WjU1ADWLv005CrDP/AHxoJglaNgPrxTzij8Ho+wnE9z0EiKy3FWu3M6fmZ3Bnk nM6BiDcClYl3pZdHeOMAsQyG+whFATPhv5YOc/+lVopMMo3w6Fm9ySqNjWwg92hEAiIr TWY/R3V6fAqB41/eHrTqopolG2hLkvPUFL+9DG4LWXp0AEuGKv1kSTJpABZPpquOOQDj VcTJ25c17+s+fc0IXTmVB8ivzXmXdaHF9y2QjKT3dOFanx9P+4uSwsyIFcnVJlZA1n6H z+h+W4FiJ7BeUyjmP+98zdxElrtiQl2dJSRaEdMOtEFs2thNR7Ibzg4jggkOWqdzJcgL ZtKQ== 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=2HnP32V8NKqRnrKVK8LAOiKgwBTC0Pkxmc3dy/6+s3A=; b=TeIst2P33PGd4XLvtMuEjx16iJ4WmW269rwdE5jIwlm3ABSI43jvoBKEWMGn8fQD99 BRx1J8IrF3UXsdUMwVnS2NFWiFWxGCr2zR9F3N0xIjAKKmUxEz0keo6VWKMYQYcBmW0h 7RmcU5OZYNUcaoB9SF15J8ekxZunqDaXov4MSn6465FTqzMelwrQFCFpOQWWBcj1M0y9 xOk81LouP1BH6gyUxtb67hPqmIGXklHgj5gKEsSstUcflQ36wzPDFGCR8S7M6l/a3TKx /TYBjC5TQ8k/uvE2Y6E2EFJAerrwKCg6ULqdej+qJ6FAmt3iQzFhNSfUpAP2pGjWKGgX PjKw== X-Gm-Message-State: AHYfb5gp4jU6O0Whfa2x9VE48DymlABlTI7Vxm0cqJvDP81+hl4sjhaS GfIiD89oVYNJhHjY/cx74NAgYxvCIg== X-Received: by 10.37.15.139 with SMTP id 133mr7013669ybp.75.1502307151857; Wed, 09 Aug 2017 12:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 12:32:31 -0700 (PDT) In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 14:32:31 -0500 Message-ID: To: Ted Hardie Cc: Robert Sparks , NomCom-Discussion Content-Type: multipart/alternative; boundary="001a113f498a2150c2055657248d" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 19:32:36 -0000 --001a113f498a2150c2055657248d Content-Type: text/plain; charset="UTF-8" Hi, Robert and Ted, (revectoring to the ietf-nomcom mailing list, which is intended for conversations like this, even though it should probably be called something like "nomcom-interest" or "nomcom-discuss" to make that more obvious) On Wed, Aug 9, 2017 at 1:59 PM, Ted Hardie wrote: > On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks > wrote: > >> Spencer - >> >> The attempt to avoid the term liaison is not working well for me. >> > Welcome to the club :-) Honestly, the biggest reason I can think of, to just call this role a liaison, is that past IAOCs and Nomcoms have ended up with a "IAOC liaison to the Nominating Committee", and that worked, at least well enough that no one appealed. It's fair to note that Michael Richardson reminds me, the IAOC did send Ole as their liaison to Nomcom when he wasn't a sitting member, so it's easy to trip over the requirements, as Robert notes. > I think the biggest thing making you want to avoid that term are the >> requirements on liaisons to oversee process as you call out in the >> document. Instead of trying to to refashion terms, why don't you just >> change things so that it is explicit that only the IAB, IESG, and ISOC >> liaisons have that duty. Then you won't run into trouble with the "other >> unrepresented organizations" text you quote. >> >> You can make it clear that for the IESG and IAB, seated members are >> required. Any other body can delegate outside its membership. >> >> That _seems_ to me to be a more straightforward adjustment. What am I >> missing? >> >> There's at least one other potential shift: removing the IAOC liaison > from the list of liaisons who might serve as replacement Nomcom chair. If > you remove that and the other process duties, it's not clear why it is > useful to call two different sets of responsibilities by the same name. > You can do it, of course, as long as you've specified it. But I don't > personally see much of an advantage. > If I switched to calling the position a liaison, and also created a new section that said "Duties of Liaisons who aren't from the IAB, IESG, or ISOC", and didn't include anything in that section except pointers to the paragraphs in https://tools.ietf.org/html/rfc7437#section-4.7 that DO apply, I'd be OK with that. If I was smart, I'd think about splitting https://tools.ietf.org/html/rfc7437#section-4.7 into "duties of IAB, IESG, and ISOC liaisons" and "duties of all liaisons", rather than just have pointers to (currently unnumbered) paragraphs, which won't age well as RFC 7437 is updated. What I'm REALLY trying to avoid is writing a bunch of new text in a BCP, when the IASA20 design team has already reported out to the community. > My take is that we want the IAOC job or its successor to eventually by > folks with specific skills in financial oversight, program management, and > community relations. Having the IAOC rep be able to explain those tasks to > a Nomcom is very valuable, and I support getting this formalized. I care > about that much more than what we call it. > ACK. And thank you, Robert and Ted, for your feedback. Spencer > Ted > > >> RjS >> >> On 8/9/17 12:05 PM, Spencer Dawkins at IETF wrote: >> >> Hi, Michael, >> >> On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson < >> mcr+ietf@sandelman.ca> wrote: >> >>> >>> Spencer Dawkins at IETF wrote: >>> > At Alissa Cooper's request, I put together a short draft that >>> updates BCP 10, >>> > the Nomcom process, adding a reminder that Nomcoms can ask the >>> IAOC to >>> > provide an advisor, and the IAOC can provide one. >>> >>> The other entities provide liasons, and I see that your document >>> explains why >>> an advisor is listed. I understand that the word "advisor" is from >>> BCP10, >>> and allows the nomcom to add advisors to the nomcom. I'd call this an >>> "import", because the nomcom pulls someone in. >>> >> >> Yeah. I'm kind of dancing here, because I'm trying to reuse terminology >> in a new and exciting(?) way. >> >> This document could >> >> - Remind the Nomcom that they will probably need help understanding >> what the IAOC does, so they should ask, OR >> - Tell the IAOC to appoint (let's call it) an Advisor, at the same >> time the IAB and IESG are appointing liaisons. >> >> The first option is where I headed, because I tend to write permissive >> BCP text ("BCP text is hard to get right"). >> >> The second option would probably appear in a new section that looks a lot >> like https://tools.ietf.org/html/rfc7437#section-4.8, except that the >> eligibility would be different. I'd be OK doing that, if it makes sense to >> others. >> >> For extra credit, https://tools.ietf.org/html/rfc7437#section-4.3 could >> actually require that an IAOC advisor be named, at the same level of >> "required" that the IAB and IESG liaisons are required. There would be more >> text changes going this way (but, see below). >> >>> >>> The other liason are not nomcom decisions, and so there is some subtle >>> distinction. >>> >>> It's also not clear to be that we want the NOMCOM to ask for an IAOC >>> advisor, >>> or if we the IAOC appoints someone. The previous tradition was the IAOC >>> appointed someone, and they gave us Ole even after he was no longer a >>> seated >>> IAOC member. >>> >>> As a voting member and chair, I found the IAOC (liason) very useful in >>> explaining not only what the IAOC does, but also what the IAB and IESG >>> do not >>> do, even when sometimes IAOC activities get relayed via IETF Chair or IAB >>> chair. Many voting members are ignorant of the IAOC and sometimes look >>> for >>> characteristics in an IESG or IAB member that would be more appropriate >>> for IAOC. >>> So I strongly agree with always having an IAOC liason/advisor, even when >>> not >>> appointing someone directly to the IAOC. >>> >> >> I'm willing to make this position a requirement, if that's the right >> answer. It's optional in the current draft. >> >> >>> {nomcom: 2002,2012,2013. chair: 2014} >> >> >> Thanks for your continued review and advice. I'm {nomcom: 2011 liaison}, >> so appreciate people with more, and especially more recent, experience >> telling me what they're thinking. >> >> Spencer >> >> >> > --001a113f498a2150c2055657248d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Robert and Ted,

(revectoring to the= ietf-nomcom mailing list, which is intended for conversations like this, e= ven though it should probably be called something like "nomcom-interes= t" or "nomcom-discuss" to make that more obvious)

On Wed, Aug 9, 2017 at 1= :59 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks <= rjsparks@nostrum.= com> wrote:
=20 =20 =20

Spencer -

The attempt to avoid the term liaison is not working well for me.


Welcome to the club :-)=C2=A0

Honestly, the big= gest reason I can think of, to just call this role a liaison, is that past = IAOCs and Nomcoms have ended up with a "IAOC liaison to the Nominating= Committee", and that worked, at least well enough that no one appeale= d. =C2=A0

It's fair to note that Michael Richa= rdson reminds me, the IAOC did send Ole as their liaison to Nomcom when he = wasn't a sitting member, so it's easy to trip over the requirements= , as Robert notes.
<= div dir=3D"ltr">

I think the biggest thing making you want to avoid that term are the requirements on liaisons to oversee process as you call out in the document. Instead of trying to to refashion terms, why don't you just change things so that it is explicit that only the IAB, IESG, and ISOC liaisons have that duty. Then you won't run into trouble with the "other unrepresented organizations" text y= ou quote.

You can make it clear that for the IESG and IAB, seated members are required. Any other body can delegate outside its membership.

That _seems_ to me to be a more straightforward adjustment. What am I missing?

There's at least one other po= tential shift: removing the IAOC liaison from the list of liaisons who migh= t serve as replacement Nomcom chair.=C2=A0 If you remove that and the other= process duties, it's not clear why it is useful to call two different = sets of responsibilities by the same name.=C2=A0 You can do it, of course, = as long as you've specified it.=C2=A0 But I don't personally see mu= ch of an advantage.

If I switched to calling the position a liaison, and also created a new se= ction that said "Duties of Liaisons who aren't from the IAB, IESG,= or ISOC", and didn't include anything in that section except poin= ters to the paragraphs in=C2=A0https://tools.ietf.org/html/rfc7437#section-4.7 that DO= apply, I'd be OK with that.

If I was smart, I= 'd think about splitting=C2=A0https://tools.ietf.org/html/rfc7437#section-4.7 into= "duties of IAB, IESG, and ISOC liaisons" and "duties of all= liaisons", rather than just have pointers to (currently unnumbered) p= aragraphs, which won't age well as RFC 7437 is updated.

<= /div>
What I'm REALLY trying to avoid is writing a bunch of new tex= t in a BCP, when the IASA20 design team has already reported out to the com= munity.
=C2=A0
My take is that we want the IAOC job or its successor to eventually b= y folks with specific skills in financial oversight, program management, an= d community relations.=C2=A0 Having the IAOC rep be able to explain those t= asks to a Nomcom is very valuable, and I support getting this formalized.= =C2=A0 I care about that much more than what we call it.
<= /div>

ACK.=C2=A0

A= nd thank you, Robert and Ted, for your feedback.

S= pencer
=C2=A0
=
Ted
=C2=A0

RjS


On 8/9/17 12:05 PM, Spencer Dawkins at IETF wrote:
Hi, Michael,

On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com&= gt; wrote:
=C2=A0 =C2=A0 > At Alissa Cooper's request, I put to= gether a short draft that updates BCP 10,
=C2=A0 =C2=A0 > the Nomcom process, adding a reminder th= at Nomcoms can ask the IAOC to
=C2=A0 =C2=A0 > provide an advisor, and the IAOC can pro= vide one.

The other entities provide liasons, and I see that your document explains why
an advisor is listed.=C2=A0 =C2=A0 I understand that the word "advisor" is from BCP10,
and allows the nomcom to add advisors to the nomcom. I'd call this an
"import", because the nomcom pulls someone in.

Yeah. I'm kind of dancing here, because I'm trying= to reuse terminology in a new and exciting(?) way.=C2=A0

This document could
  • Remind the Nomcom that they will probably need help understanding what the IAOC does, so they should ask, OR
  • Tell the IAOC to appoint (let's call it) an Advisor= , at the same time the IAB and IESG are appointing liaisons.
The first option is where I headed, because I tend to write permissive BCP text ("BCP text is hard to get right").

The second option would probably appear in a new section that looks a lot like=C2=A0https://tools.ietf.or= g/html/rfc7437#section-4.8, except that the eligibility would be different. I'd be OK doing that, if it makes sense to others.

For extra credit,=C2=A0https://tools.ietf.org/html= /rfc7437#section-4.3 could actually require that an IAOC advisor be named, at the same level of "required" that the IAB and IESG liaisons are required. There would be more text changes going this way (but, see below).

The other liason are not nomcom decisions, and so there is some subtle distinction.

It's also not clear to be that we want the NOMCOM to ask for an IAOC advisor,
or if we the IAOC appoints someone.=C2=A0 The previous tradition was the IAOC
appointed someone, and they gave us Ole even after he was no longer a seated
IAOC member.

As a voting member and chair, I found the IAOC (liason) very useful in
explaining not only what the IAOC does, but also what the IAB and IESG do not
do, even when sometimes IAOC activities get relayed via IETF Chair or IAB
chair.=C2=A0 Many voting members are ignorant of the IAOC and sometimes look for
characteristics in an IESG or IAB member that would be more appropriate for IAOC.
So I strongly agree with always having an IAOC liason/advisor, even when not
appointing someone directly to the IAOC.

I'm willing to make this position a requirement, if that's the right answer. It's optional in the current draft.
=C2=A0
{nomcom: 2002,2012,2013. chair: 2014}

Thanks for your continued review and advice. I'm {nomcom: 2011 liaison}, so appreciate people with more, and especially more recent, experience telling me what they're thinking.

Spencer=C2=A0



--001a113f498a2150c2055657248d-- From nobody Wed Aug 9 12:56:31 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 E0E3E1324B4; Wed, 9 Aug 2017 12:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 M-btwPnfCFfX; Wed, 9 Aug 2017 12:56:21 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 4F14D1324B3; Wed, 9 Aug 2017 12:56:21 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id s143so46530250ywg.1; Wed, 09 Aug 2017 12:56:21 -0700 (PDT) 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=ggoyIoOhEu5EBjtHOC6k5Vlt6EFWBURvbEhpPpu9zpo=; b=LwmS2fsfL2Sq/TkHBMekm7nZxrxYoO1hwLPnS79kuLjoUUZJVwI6+GMh/qRX+quc7U M+fDmDeAFg9OrGfgO1RaxBo1JCMYRPZtd6yr8S/Mb/UNgwCvG03EM0+adSAC+ZOSxhli XGfkEgpqeV38ccd5MFwjEdGdqpShBLHZiIx0T2vcqfZ1gKIg6jOfdKO/KIkjbGWBD2eT LFMNMlpm4X7U0DVC51SUiBLlxyZEzg4orzmyG4wKpoAnXDYZEc2zbA6Qv8mM0VxCyy0M SX43Oo6ieS8wGHkz0eOHZ4cKqoW180IyKp3Jka2ABHiROFxgMN1pmgOeswQrF5ss1BR0 3D2Q== 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=ggoyIoOhEu5EBjtHOC6k5Vlt6EFWBURvbEhpPpu9zpo=; b=DPK58gQ3FljeXHdSVpKsGe7pEpBGPgqKXnJNCVe3o9bNzdTBnUyaRmDoX0xci44GMn 8KoaP/hzAPXl+phsXQYy/WBkWvF5E+ZxfwuxdbjgX8MQMUovtxaTrYVAwCXhsd1Q7RLl I9wKBCOOmG69Q08sqPa+nZvG3tpzNh8ZTO3EjPUZPm772afVjYGzzlzGrqd61pqCdoap OIRAS6tnHhq/nuxKtIv+cV7UdmFtP6ZDl+sdcdgLW2KkBDV+y1vOM9R81sx2czC9AScg Z6TiXo5Wlzs96pl2RX5V1c412B0+IE6plsVHW2SeIKAKtqonzZZfgM+DgJvW/+RsMJ0C XPfw== X-Gm-Message-State: AHYfb5gOWat3z9Rf94eP4Hq0TdpHY493v8Y6xGuLYudJEDtb3unruGrs tBt0NIZ98MtLiEbXeNqua3WS7ZggXA== X-Received: by 10.37.172.72 with SMTP id r8mr7983960ybd.38.1502308580453; Wed, 09 Aug 2017 12:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 12:56:19 -0700 (PDT) In-Reply-To: <5e20388a-a6dd-691d-feeb-8f5363119c0c@nostrum.com> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5e20388a-a6dd-691d-feeb-8f5363119c0c@nostrum.com> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 14:56:19 -0500 Message-ID: To: Robert Sparks Cc: Ted Hardie , IETF , "iesg@ietf.org" , NomCom-Discussion Content-Type: multipart/alternative; boundary="f403045eb43047fa2205565779f4" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 19:56:24 -0000 --f403045eb43047fa2205565779f4 Content-Type: text/plain; charset="UTF-8" Revectoring to the ietf-nomcom list, which is intended for conversations like this ... On Wed, Aug 9, 2017 at 2:17 PM, Robert Sparks wrote: > > > On 8/9/17 1:59 PM, Ted Hardie wrote: > > On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks > wrote: > >> Spencer - >> >> The attempt to avoid the term liaison is not working well for me. >> >> I think the biggest thing making you want to avoid that term are the >> requirements on liaisons to oversee process as you call out in the >> document. Instead of trying to to refashion terms, why don't you just >> change things so that it is explicit that only the IAB, IESG, and ISOC >> liaisons have that duty. Then you won't run into trouble with the "other >> unrepresented organizations" text you quote. >> >> You can make it clear that for the IESG and IAB, seated members are >> required. Any other body can delegate outside its membership. >> >> That _seems_ to me to be a more straightforward adjustment. What am I >> missing? >> > There's at least one other potential shift: removing the IAOC liaison from > the list of liaisons who might serve as replacement Nomcom chair. If you > remove that and the other process duties, it's not clear why it is useful > to call two different sets of responsibilities by the same name. You can > do it, of course, as long as you've specified it. But I don't personally > see much of an advantage. > > My take is that we want the IAOC job or its successor to eventually by > folks with specific skills in financial oversight, program management, and > community relations. Having the IAOC rep be able to explain those tasks to > a Nomcom is very valuable, and I support getting this formalized. I care > about that much more than what we call it. > > I think the thing that's bothering me is that the current proposal still > leaves the unintended trouble if the "Any committee member may propose the > addition of a liaison" is exercised. > Yes, and that's borked. I'm a tiny bit loath to turn this draft into a "liaison responsibilities cleanup" draft, although Robert correctly points out that if we wanted to clean up the liaison responsibilities, we would have changes to make. If this draft continues to be about an advisor, I'd be happy to address the liaison responsibilities in another draft. of course. When we have text in BCPs that is rarely/never executed, we don't look at it very often. You'd be impressed at the list of people who told me they didn't realize what all the liaison responsibilities are. I won't embarrass the ones who told me that, and who have previously served as liaison (so, subject to those responsibilities) without noticing that, but I can confirm that *I* didn't notice them, in 2011 as the IAB liaison to the Nomcom :-) That text doesn't age any better than error-path code that doesn't get triggered for a very long time, of course. But I digress. > If you strip away all the rationalization text, the change in Spencer's > current document reduces to "Hey future nomcoms - it would be a good idea > if you found an advisor that can talk to you about the IAOC, and the > current IAOC might be a good body to ask to help you find one". I don't > object to that. Perhaps the rationalization is a distraction? > It's only there to explain why this role isn't a liaison. If the role becomes a liaison, the rationalization text would, of course, go away. > But the rationalization part also argues that we want to say "If you think > you want a liaison from some other body, you might want to look closely at > asking for an advisor instead." > One could make the case that "Any committee member may propose the addition of a non-voting liaison" is also borked. Of course, I don't know why that text is there in the first place. It's also in RFC 3777, and in RFC 2727, which means it was added after RFC 2282 was published in 1998. So I wonder if this was intended to prevent a problem I don't know about? Thanks again for the feedback. It's helpful. Spencer --f403045eb43047fa2205565779f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Revectoring to the ietf-nomcom list, which is intended for= conversations like this ...

On Wed, Aug 9, 2017 at 2:17 PM, Robert Sparks = <rjsparks@nost= rum.com> wrote:
=20 =20 =20



On 8/9/17 1:5= 9 PM, Ted Hardie wrote:
On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks <= rjsparks@nostrum.com> wrote:

Spencer -

The attempt to avoid the term liaison is not working well for me.

I think the biggest thing making you want to avoid that term are the requirements on liaisons to oversee process as you call out in the document. Instead of trying to to refashion terms, why don't you just change things so that it is explicit that only the IAB, IESG, and ISOC liaisons have that duty. Then you won't run into trouble with the "other unreprese= nted organizations" text you quote.

You can make it clear that for the IESG and IAB, seated members are required. Any other body can delegate outside its membership.

That _seems_ to me to be a more straightforward adjustment. What am I missing?

There's at least one other potential shift: removing the IAOC liaison from the list of liaisons who might serve as replacement Nomcom chair.=C2=A0 If you remove that and the other process duties, it's not clear why it is useful to call two different sets of responsibilities by the same name.=C2=A0 You can do it, of course, as long as you've specified it.=C2=A0 But I don't personally see much of an advantage.

My take is that we want the IAOC job or its successor to eventually by folks with specific skills in financial oversight, program management, and community relations.=C2=A0 Having the IAOC rep be able to explain those tasks to a Nomcom is very valuable, and I support getting this formalized.=C2=A0 I care about that much more than what we ca= ll it.
 I think the thing that's bothering me is that the current proposal still leaves the unintended trouble if the "Any committee member m= ay propose the addition of a liaison" is exercised.

Yes, and that's borked.=C2=A0

I'm a tiny bit loath to turn this draft into a "liaison r= esponsibilities cleanup" draft, although Robert correctly points out t= hat if we wanted to clean up the liaison responsibilities, we would have ch= anges to make.=C2=A0

If this draft continues to be= about an advisor, I'd be happy to address the liaison responsibilities= in another draft. of course.

<rant>

When we have text in BCPs that is rarely/never executed, = we don't look at it very often. You'd be impressed at the list of p= eople who told me they didn't realize what all the liaison responsibili= ties are. I won't embarrass the ones who told me that, and who have pre= viously served as liaison (so, subject to those responsibilities) without n= oticing that, but I can confirm that *I* didn't notice them, in 2011 as= the IAB liaison to the Nomcom :-)

That text doesn= 't age any better than error-path code that doesn't get triggered f= or a very long time, of course.

But I digress.

</rant>
=C2=A0
If you strip away= all the rationalization text, the change in Spencer's current document reduces to "Hey future nomcoms - it= would be a good idea if you found an advisor that can talk to you about the IAOC, and the current IAOC might be a good body to ask to help you find one". I don't object to that. Perhaps the rationaliza= tion is a distraction?

It's only = there to explain why this role isn't a liaison. If the role becomes a l= iaison, the rationalization text would, of course, go away.
=C2= =A0
But the rationalization part also argues that we want to say "= ;If you think you want a liaison from some other body, you might want to look closely at asking for an advisor instead."
=

One could make the case that "Any committee member may propose the addit= ion of a non-voting=C2=A0liaison"=C2=A0is also borked.

Of course, I don't know why that=C2=A0 text is there in the first pla= ce. It's also in RFC 3777, and in RFC 2727, which means it was added af= ter RFC 2282 was published in 1998.=C2=A0 So I wonder if this was intended = to prevent a problem I don't know about?

Thank= s again for the feedback. It's helpful.

Spence= r
--f403045eb43047fa2205565779f4-- From nobody Wed Aug 9 13:15:46 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 6DAD2132476 for ; Wed, 9 Aug 2017 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 feCX7LOHgDO1 for ; Wed, 9 Aug 2017 13:15:43 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 BAB9C13244C for ; Wed, 9 Aug 2017 13:15:43 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c28so32096632pfe.3 for ; Wed, 09 Aug 2017 13:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d9gCnQ6Ozw4CSkf87muUaj6uaBHeRUxawZjp3WMH1e0=; b=aP3apcpnjaCnPhPFwRaVHYu/Owgq2ui03mwstS7ey8825UzSrOOUM8jEK4eRij9KLN mh4muwl19/eZQ6kyBGAJgUTo2Pgr3ih7Ttmt3iuB/BDjzHf6uJ9Q3kaUcxsvtkNiWvkX IUFydzVwq1LzdAOcJRIMO+/Rty4pkcNyDqHCMzfF7y8xdTqbQmMqO+4bveHLAWUFMj+u MULy4kPoNrSo5cK9uMhtfG9LzgBFNRy+KL+wMpGoTv76brr3B7Jwc1SWnU5i/MV66YKd NFhxS5Knuych+1wVdGHN0zD4Od4Q5Jl5WDgvkhTjfFAsKTRJjtkiRxZ7mj0cKijqZhDy nyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=d9gCnQ6Ozw4CSkf87muUaj6uaBHeRUxawZjp3WMH1e0=; b=JWNWjq3j4vlBzB3RRno8Y8JOgG8wOOvPCvqT/rZq6V73xa8tafzVJjhLMySJZpuLYL CsVhBPUpA/8Ik0niK1d11EL58ggdh3dVKLazIf0lJiC7SiBrMKd2IY5iefowxMkXsaHc +HH5TCsXsbJU000V400YKcswgozDVWZtlkvgqBtEopXPy5Gy3u3PHLODrvS+eOJWQHZ+ MVzWETYGMyii1hIkef4XtQ0ngBDANTK/n6RtvO0rdJzyWF0lUL7hklwHfdRoSMoFZMCE 4BP3Q3yjiB+K7HmX/QbZrbjJ44r5l/6R6iDqxxYYCJ6Uy+6afYpwjNYljMcznGNLvtyZ DLQQ== X-Gm-Message-State: AHYfb5iy3odN6/ygHpL1vieLeybgWIA/NZsjqA2AhrJA09fmeaT4hSdQ BtrA/cTihTBcpQ== X-Received: by 10.84.178.129 with SMTP id z1mr10367982plb.260.1502309743343; Wed, 09 Aug 2017 13:15:43 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r25sm7887368pgu.7.2017.08.09.13.15.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 13:15:42 -0700 (PDT) To: Robert Sparks References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> Cc: NomCom-Discussion , Spencer Dawkins at IETF From: Brian E Carpenter Organization: University of Auckland Message-ID: <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> Date: Thu, 10 Aug 2017 08:15:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 20:15:45 -0000 (Adjusted the CC) On 10/08/2017 06:48, Robert Sparks wrote: > Spencer - > > The attempt to avoid the term liaison is not working well for me. 'Liaison' implies 2-way communication; 'advisor' implies 1-way comunication. I think we need to decide which we want. Brian From nobody Wed Aug 9 14:33:51 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 32FF7132339 for ; Wed, 9 Aug 2017 14:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 AK6ZcXb8P5tD for ; Wed, 9 Aug 2017 14:33:47 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 DB696132191 for ; Wed, 9 Aug 2017 14:33:46 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x3so73851146oia.1 for ; Wed, 09 Aug 2017 14:33:46 -0700 (PDT) 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=DYizO/fEWCbkfhJdwp4i/zq6rxP65rzLpIoCvcrNb4k=; b=f6o9dz0rljQCRtg3WO9WfVPNayZVLbtNqIHYgmz7NHI88MgcjYdu65/V4gEdJooH/E oirQZZvoqrQs/AnZjG1tMpvw6vQipIPM8iJ2VtHNI4jK38KVNrOcbB7LkBDI8sGWged5 y5KxyqnTIa8oarKRQ/SiUgS7NiV9IykTMJNG+RYDBjWuMratIpGpzRMAhDYu3VylKr+u wpSsf/SOzCCPcti0CNa7mumrbW4leY68fbNOyuLk+Pc9vCrYrnjdzyIVhx+cEuiJA9we Kq2mT5IhgRYYd6ZN7Cq6rVVoXkj5he+B3am5uqKdoXyGXePZXZlDLOCn1Ond7Ulpv8E/ qNlQ== 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=DYizO/fEWCbkfhJdwp4i/zq6rxP65rzLpIoCvcrNb4k=; b=gAnXCrsypFzS+YTijtEg3WDNTes50CjKMy55iJBwo0+yw50mhTi6D27t1EE+8Vsmpm czTVvKjjfjKaePkp7tqN0W1ry6vDRRkg0LrdQ7imLVXo4tvYGrjZb3/odBXHx608SPl6 ebmWuVWQTGLJG59AXU4e/GTgoJDDVMf3VtMWqOSj3VFEOcbLV2IeHititjNZpaQPRGkG x/IlEOCZpq0Cnebx6HqWxV+wM8fBQiNbcZxlMXcAARbh6iwt4bDCK4KAF+VJvgk6xVYH lZLgn/J0o+BsSMq6o/gNTdILtY5y/VXqSX6oUBNIdqixBBXmOe3VnwhrdOXp9A6JB4Ak MfOA== X-Gm-Message-State: AHYfb5hd/l1cjmZx/cl0PyFlLeNc7XXVLxgeSRR3QxGS+VqbY/Uwkbxy qpFxMx6CELdDzL1OjMfzdIRyJTgPPQ== X-Received: by 10.202.213.79 with SMTP id m76mr9874249oig.54.1502314426293; Wed, 09 Aug 2017 14:33:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.34 with HTTP; Wed, 9 Aug 2017 14:33:25 -0700 (PDT) In-Reply-To: <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> From: "Andrew G. Malis" Date: Wed, 9 Aug 2017 17:33:25 -0400 Message-ID: To: Brian E Carpenter Cc: Robert Sparks , NomCom-Discussion Content-Type: multipart/alternative; boundary="001a113acab2b861ae055658d5f7" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 21:33:49 -0000 --001a113acab2b861ae055658d5f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way, I=E2=80=99ve = often seen the case where there are two liaison individuals between a pair of organizations, one for each direction. Cheers, Andy On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > (Adjusted the CC) > > On 10/08/2017 06:48, Robert Sparks wrote: > > Spencer - > > > > The attempt to avoid the term liaison is not working well for me. > > 'Liaison' implies 2-way communication; 'advisor' implies 1-way > comunication. > I think we need to decide which we want. > > Brian > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > --001a113acab2b861ae055658d5f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

=E2=80=9CLiaison=E2=80=9D as an = actual person can be one-way, I=E2=80=99ve often seen the case where there = are two liaison individuals between a pair of organizations, one for each d= irection.

Cheers,
Andy


On Wed, = Aug 9, 2017 at 4:15 PM, Brian E Carpenter <brian.e.carpenter@gma= il.com> wrote:
(Adjusted th= e CC)

On 10/08/2017 06:48, Robert Sparks wrote:
> Spencer -
>
> The attempt to avoid the term liaison is not working well for me.

'Liaison' implies 2-way communication; 'advisor' imp= lies 1-way comunication.
I think we need to decide which we want.

=C2=A0 =C2=A0 Brian

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

--001a113acab2b861ae055658d5f7-- From nobody Wed Aug 9 16:03:44 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 C7B8F127B60 for ; Wed, 9 Aug 2017 16:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 RSux644nOv5M for ; Wed, 9 Aug 2017 16:03:41 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 CE8501204DA for ; Wed, 9 Aug 2017 16:03:40 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s143so48950876ywg.1 for ; Wed, 09 Aug 2017 16:03:40 -0700 (PDT) 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=G7gqKEaHgPJmfhpjWMXWkStGZQjCbS/DETvGK8QnQ78=; b=DqylX18m7lgtFfiJfclysUTkGSkPVfRLAOb6BbLCrJNgCIPx0ANPN4Ue0yNSRVGHPa y2KYFeR8UdpFKcIMfWPtII3BGNBq0teVaAEAw50Wamxcvoh6rlyt9t7hrmRSC58fuisE W4OeRAolPnEEppyKa8SgaOduutDbWOJhHnLOiG3k37KcM1JauQDI0I7IFQK3wdZxFevS 9CnP6LCgeWYyAULw6rKsjWvVaFcKVtKDKFYRA7YlUO2YFn0XDR06YMORp41628OluRUP 1PZbUdIklk/szhwxcJWAndM36XTVAZnUxV4CWQG3o1Aj3ErTHP9pqIfcNARfwSE3UO/6 /G1Q== 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=G7gqKEaHgPJmfhpjWMXWkStGZQjCbS/DETvGK8QnQ78=; b=ObYMWQjO8d62i3cLvxbFL20IlffaC5tnZHJJZs3wa7NQzQO3WZc/7edcEk2OPqAjwT NOh7lO5jXJv8xA7Jm5W/ogOyfP2XQcNET2nlPRETj7gb5jmFhiD8V1U7hSu0cCCRpGAu W1uy3eraduP04F6cfZzaqYmJR/1ayowytXfI0elrMTu/gPxsmFvRFYfp++EuIq9dsxM+ Mm2piXiShf4np1D4+ira0RL9/48oogTo33dyktTpcgf85xl2otJUl5rxF3fin3SISGyX NOyk8p/6qrozKFYwaitPU4chE/6RY6pOi2HN4Uu06fY36YyVldm8qwGTjMSCTJyi161C FOXg== X-Gm-Message-State: AHYfb5gFNh9CkB0k2SzcCS51GVmwv6scQMitsHPT09PkQS1TwuJrez5u spTJvcL/IW+w8V2ojIJFNqgvLnFdEw== X-Received: by 10.37.15.139 with SMTP id 133mr7492641ybp.75.1502319819811; Wed, 09 Aug 2017 16:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 16:03:39 -0700 (PDT) In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 18:03:39 -0500 Message-ID: To: "Andrew G. Malis" Cc: Brian E Carpenter , NomCom-Discussion , Robert Sparks Content-Type: multipart/alternative; boundary="001a113f498a32fcca05565a1715" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 09 Aug 2017 23:03:43 -0000 --001a113f498a32fcca05565a1715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis wrote: > Brian, > > =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way, I=E2=80=99v= e often seen the case > where there are two liaison individuals between a pair of organizations, > one for each direction. > Well, I think Andy is right here (the IAB certainly appoints IETF liaisons to other SDOs as directional), but that's side-stepping the more interesting question, which is not what we call this role, but whether we expect Nomcom to send anything back to the IAOC via the (the draft calls it) advisor. And that question may not need to affect the resulting text ( https://tools.ietf.org/html/rfc7437#section-4.9 says An advisor is responsible for such duties as specified by the invitation that resulted in the appointment. which is pretty darned broad), but if it might affect the resulting text, that would be good to know sooner, rather than later. Thanks, Spencer > Cheers, > Andy > > > On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> (Adjusted the CC) >> >> On 10/08/2017 06:48, Robert Sparks wrote: >> > Spencer - >> > >> > The attempt to avoid the term liaison is not working well for me. >> >> 'Liaison' implies 2-way communication; 'advisor' implies 1-way >> comunication. >> I think we need to decide which we want. >> >> Brian >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > --001a113f498a32fcca05565a1715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis = <agmalis@gmail.co= m> wrote:
Brian,

=E2=80=9CLiaison=E2=80=9D as a= n actual person can be one-way, I=E2=80=99ve often seen the case where ther= e are two liaison individuals between a pair of organizations, one for each= direction.

Well, I think Andy = is right here (the IAB certainly appoints IETF liaisons to other SDOs as di= rectional), but that's side-stepping the more interesting question, whi= ch is not what we call this role, but whether we expect Nomcom to send anyt= hing back to the IAOC via the (the draft calls it) advisor.

<= /div>
And that question may not need to affect the resulting text (https://tools.ietf.= org/html/rfc7437#section-4.9 says=C2=A0

=C2=A0 =C2=A0An adviso= r is responsible for such duties as specified by the
=C2=A0 =C2=A0invita= tion that resulted in the appointment.

=
which is pretty darned broad), but if it m= ight affect the resulting text, that would be good to know sooner, rather t= han later.

Thanks,

Spencer
=C2=A0
Cheers,
Andy

<= /div>

<= div class=3D"gmail-h5">On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
(Adjusted the CC)

On 10/08/2017 06:48, Robert Sparks wrote:
> Spencer -
>
> The attempt to avoid the term liaison is not working well for me.

'Liaison' implies 2-way communication; 'advisor' imp= lies 1-way comunication.
I think we need to decide which we want.
<= br> =C2=A0 =C2=A0 Brian
=

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


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


--001a113f498a32fcca05565a1715-- From nobody Wed Aug 9 17:42: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 3941C1324D3 for ; Wed, 9 Aug 2017 17:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=joelhalpern.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 QN1sVW60GMdi for ; Wed, 9 Aug 2017 17:42:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 408A6131CB2 for ; Wed, 9 Aug 2017 17:42:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 28A9B429EDE; Wed, 9 Aug 2017 17:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1502325728; bh=UA3VK5sjW/lBGUf7bC1Uwl37PgLTmu68Wr/oKvfA010=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pkQB8Yyk4Uecoh/1AuhtvXAmpS/yXxUaSQ6ZThQCtCSil0/exRZJFa6KnhClg4Jaz lh3vAYseYPcUgrof6CN1HVNCCD09u1IeCPyRe8p7j0Hb2tO2cFVtLH7UqHrG3llGL+ s3BxZeIYzwzdHZarvRCePug1FCJLZ84aJtTc0tmE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 94B14429ED5; Wed, 9 Aug 2017 17:42:07 -0700 (PDT) To: Spencer Dawkins at IETF Cc: NomCom-Discussion References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> From: Joel Halpern Message-ID: <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> Date: Wed, 9 Aug 2017 20:42:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 00:42:10 -0000 As the IAOC is not an approval body, I have trouble seeing why the nomcom would need to send anything to the IAOC. Even if the Nomcom had operational feedback from the community about the IAOC as a body, it seems to me that the advisor would not be the means to send such back. I seem to be in the minority, but I like calling this something other than liaison, because of the set of roles that apply to liaisons, but not to this IAOC suggested information source. I mildly prefer Spencer's current formulation that the nomcom asks for the advisor. The factor that strikes me is that this way the nomcom and its chair can ensure that they are comfortable with the appointee. (That is not their right with the liaisons, as those individuals are responsible to their providing bodies.) Yours, Joel On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote: > Dear all, > > On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis > wrote: > > Brian, > > “Liaison” as an actual person can be one-way, I’ve often seen the > case where there are two liaison individuals between a pair of > organizations, one for each direction. > > > Well, I think Andy is right here (the IAB certainly appoints IETF > liaisons to other SDOs as directional), but that's side-stepping the > more interesting question, which is not what we call this role, but > whether we expect Nomcom to send anything back to the IAOC via the (the > draft calls it) advisor. > > And that question may not need to affect the resulting text > (https://tools.ietf.org/html/rfc7437#section-4.9 says > > An advisor is responsible for such duties as specified by the > invitation that resulted in the appointment. > > which is pretty darned broad), but if it might affect the resulting > text, that would be good to know sooner, rather than later. > > Thanks, > > Spencer > > Cheers, > Andy > > > On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter > > > wrote: > > (Adjusted the CC) > > On 10/08/2017 06:48, Robert Sparks wrote: > > Spencer - > > > > The attempt to avoid the term liaison is not working well for me. > > 'Liaison' implies 2-way communication; 'advisor' implies 1-way > comunication. > I think we need to decide which we want. > > Brian > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > > > > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From nobody Wed Aug 9 18:11:00 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 352FE1323BA for ; Wed, 9 Aug 2017 18:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 NWRPo1FvLSY1 for ; Wed, 9 Aug 2017 18:10:56 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 BCA891201F8 for ; Wed, 9 Aug 2017 18:10:55 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id p68so50185219ywg.0 for ; Wed, 09 Aug 2017 18:10:55 -0700 (PDT) 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=k4RRuMQh4pBD4nlZx/H0Byrau23Fr8qImKqOeJQ8PO0=; b=uYlV7DYPVLTAZUSmkKIgyutw0KCGpnMb574yLN3tirOHEk6ccqi3/iwa4BxVQwpZxP fnQxL6ynZpTRgxPCa7y39zho8aLZ4cpjfnRWxtKQhKgOivDWUaz+Wi7vbD4ySaYdQEPt 1C4Sdpk1l92zk4mQNEQsRL7ZCJugsGpFnHAbUTA2NLtmLf/Me6lRnLKhcSWSBKMfYGt8 aVkH5AXNmLCcpzDuXNseAxK6R0Sl35PyKQfxqujefVJ2br5KxjBPWaRnx8pBQgSMYXGL qzgxgPNCtGR0qTC0MZTUJ7JDsyl3YaaXd5wZzMP0DFNfn2nr+7Jt8tMebvrljj3LC7BD juXg== 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=k4RRuMQh4pBD4nlZx/H0Byrau23Fr8qImKqOeJQ8PO0=; b=TpkHGfPV/m/k4WbpoKVXfOFzKlWSqHzbLAATOcZy98X7JDto7CtqQSfPvGmykb7nnI HgTXkcCjE632IEkz/oZhJOJvVK6bhDpCsvEbIAS4yotulwkQRS1zC329qcT451MdnHgn ZqYfkb6vyd7bo8xI8m2cjvhi7Vr3YceiHPvbyI/1YKABmQMR1PbMHwKFt2DtP25Pdq1F WgUSgnc8bzN8jYlIOp0ZSegk19PQcv1tb4Dibz0pnDMvMMwVnPjquJ4XdRUDZHRwhfob 71SjfhOjadSgrOmJz6Oz+oPTRDQnH3BiGCXzskFZxEXaT7SoVJtBpXsct1bgWrUWb8sh l88Q== X-Gm-Message-State: AHYfb5i6Wxq1N3eKibDYqw3mPPWKozeieKDafE1MqlZEGeQKjYqOmCDT 9y8S1QGKI/DJV72DLNceurchIjcG0S5Z X-Received: by 10.129.96.85 with SMTP id u82mr8445848ywb.57.1502327454868; Wed, 09 Aug 2017 18:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 18:10:54 -0700 (PDT) In-Reply-To: <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 20:10:54 -0500 Message-ID: To: Joel Halpern Cc: NomCom-Discussion Content-Type: multipart/alternative; boundary="001a11471de248ae3d05565bde8c" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 01:10:58 -0000 --001a11471de248ae3d05565bde8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Joel, On Wed, Aug 9, 2017 at 7:42 PM, Joel Halpern wrote: > As the IAOC is not an approval body, I have trouble seeing why the nomcom > would need to send anything to the IAOC. Even if the Nomcom had > operational feedback from the community about the IAOC as a body, it seem= s > to me that the advisor would not be the means to send such back. > There's certainly no reason why that feedback would HAVE to go through one person, so, yeah, I think so. The IAOC not being an approval body was the other reason I was OK with not requiring the person the IAOC sent to the Nomcom to carry out several of the liaison responsibilities, as well. > I seem to be in the minority, but I like calling this something other tha= n > liaison, because of the set of roles that apply to liaisons, but not to > this IAOC suggested information source. > > I mildly prefer Spencer's current formulation that the nomcom asks for th= e > advisor. The factor that strikes me is that this way the nomcom and its > chair can ensure that they are comfortable with the appointee. (That is n= ot > their right with the liaisons, as those individuals are responsible to > their providing bodies.) > I wasn't thinking about that, but I like the side effect. Joel, that does act as a safety valve, because the set of possible advisors from the IAOC isn't bounded, the way the existing liaisons from confirming bodies are. This is Spencer's Opinion, but after hanging around the Nomcom past chairs (at Russ's request, while compiling the issues that fed into https://datatracker.ietf.org/doc/draft-dawkins-nomcom-3777-issues/), I came away with the feeling that the Nomcom is given really wide discretion, because there is no Plan B if process rules got in the way of a Nomcom delivering candidate slates. The Prime Directive is "come up with slates of confirmable candidates in a timely fashion and maintain confidentialty". If that happens, mission accomplished. That's why I thought adding advice for Nomcoms is OK, but adding hard requirements probably isn't OK. And that's why I thought it was best to encourage the Nomcom committee members to request an advisor, in the usual way, and allow them to ask the IAOC for suggestions, but not to require them to have an advisor, and not to constrain who the IAOC might suggest. As Joel points out, the current draft doesn't require the Nomcom to accept that suggestion. And finding out whether Spencer's Opinion is anyone else's opinion, is why we're having this conversation now :-) Spencer > Yours, > Joel > > On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote: > >> Dear all, >> >> On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis > > wrote: >> >> Brian, >> >> =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way, I=E2= =80=99ve often seen the >> case where there are two liaison individuals between a pair of >> organizations, one for each direction. >> >> >> Well, I think Andy is right here (the IAB certainly appoints IETF >> liaisons to other SDOs as directional), but that's side-stepping the mor= e >> interesting question, which is not what we call this role, but whether w= e >> expect Nomcom to send anything back to the IAOC via the (the draft calls >> it) advisor. >> >> And that question may not need to affect the resulting text ( >> https://tools.ietf.org/html/rfc7437#section-4.9 says >> >> An advisor is responsible for such duties as specified by the >> invitation that resulted in the appointment. >> >> which is pretty darned broad), but if it might affect the resulting text= , >> that would be good to know sooner, rather than later. >> >> Thanks, >> >> Spencer >> >> Cheers, >> Andy >> >> >> On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter >> > >> wrote: >> >> (Adjusted the CC) >> >> On 10/08/2017 06:48, Robert Sparks wrote: >> > Spencer - >> > >> > The attempt to avoid the term liaison is not working well for >> me. >> >> 'Liaison' implies 2-way communication; 'advisor' implies 1-way >> comunication. >> I think we need to decide which we want. >> >> Brian >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> >> >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> >> >> >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> > --001a11471de248ae3d05565bde8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Joel,

On Wed, Aug 9, 2017 at 7:42 PM, Joel Halpern <= ;jmh@joelhalpern.c= om> wrote:
As the IAOC is not an approval body, I have trouble seeing why the nomco= m would need to send anything to the IAOC.=C2=A0 Even if the Nomcom had ope= rational feedback from the community about the IAOC as a body, it seems to = me that the advisor would not be the means to send such back.

There's certainly no reason why that feedback wo= uld HAVE to go through one person, so, yeah, I think so.

The IAOC not being an approval body was the other reason I was OK wi= th not requiring the person the IAOC sent to the Nomcom to carry out severa= l of the liaison responsibilities, as well.
=C2=A0
I seem to be in the minority, but = I like calling this something other than liaison, because of the set of rol= es that apply to liaisons, but not to this IAOC suggested information sourc= e.

I mildly prefer Spencer's current formulation that the nomcom asks for = the advisor.=C2=A0 The factor that strikes me is that this way the nomcom a= nd its chair can ensure that they are comfortable with the appointee. (That= is not their right with the liaisons, as those individuals are responsible= to their providing bodies.)

I wasn'= ;t thinking about that, but I like the side effect. Joel, that does act as = a safety valve, because the set of possible advisors from the IAOC isn'= t bounded, the way the existing liaisons from confirming bodies are.
<= div>
This is Spencer's Opinion, but after hanging around = the Nomcom past chairs (at Russ's request, while compiling the issues t= hat fed into https://datatracker.ietf.org/doc/draft-dawkins-nomcom-3777= -issues/), I came away with the feeling that the Nomcom is given really= wide discretion, because there is no Plan B if process rules got in the wa= y of a Nomcom delivering candidate slates.=C2=A0 The Prime Directive is &qu= ot;come up with slates of confirmable candidates in a timely fashion and ma= intain confidentialty". If that happens, mission accomplished.

That's why I thought adding advice for Nomcoms is OK,= but adding hard requirements probably isn't OK.

And that's why I thought it was best to encourage the Nomcom committ= ee members to request an advisor, in the usual way, and allow them to ask t= he IAOC for suggestions, but not to require them to have an advisor, and no= t to constrain who the IAOC might suggest. As Joel points out, the current = draft doesn't require the Nomcom to accept that suggestion.
<= br>
And finding out whether Spencer's Opinion is anyone else&= #39;s opinion, is why we're having this conversation now :-)
=
Spencer
=C2=A0
Yours,
Joel

On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote:
Dear all,

On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis <agmalis@gmail.com <mailto:agmalis@gmail.com>> = wrote:

=C2=A0 =C2=A0 Brian,

=C2=A0 =C2=A0 =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way,= I=E2=80=99ve often seen the
=C2=A0 =C2=A0 case where there are two liaison individuals between a pair o= f
=C2=A0 =C2=A0 organizations, one for each direction.


Well, I think Andy is right here (the IAB certainly appoints IETF liaisons = to other SDOs as directional), but that's side-stepping the more intere= sting question, which is not what we call this role, but whether we expect = Nomcom to send anything back to the IAOC via the (the draft calls it) advis= or.

And that question may not need to affect the resulting text (https://tools.ietf.org/html/rfc7437#section-4.9 says

=C2=A0 =C2=A0 An advisor is responsible for such duties as specified by the=
=C2=A0 =C2=A0 invitation that resulted in the appointment.

which is pretty darned broad), but if it might affect the resulting text, t= hat would be good to know sooner, rather than later.

Thanks,

Spencer

=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 Andy


=C2=A0 =C2=A0 On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter
 =C2=A0 =C2=A0 <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
=C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (Adjusted the CC)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 10/08/2017 06:48, Robert Sparks wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Spencer -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > The attempt to avoid the term liaison is n= ot working well for me.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 'Liaison' implies 2-way communication; = 'advisor' implies 1-way
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comunication.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think we need to decide which we want.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian

=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-nomcom mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-nomcom@ietf.org <mailto:ietf-nomcom@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/ietf-nomcom
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.or= g/mailman/listinfo/ietf-nomcom>



=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 ietf-nomcom mailing list
 =C2=A0 =C2=A0 iet= f-nomcom@ietf.org <mailto:ietf-nomcom@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/lis= tinfo/ietf-nomcom
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/ietf-nomcom>




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



--001a11471de248ae3d05565bde8c-- From nobody Wed Aug 9 18:45:37 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 C35C013250C for ; Wed, 9 Aug 2017 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, 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 liVYmn9ssB-H for ; Wed, 9 Aug 2017 18:45:33 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6C513250D for ; Wed, 9 Aug 2017 18:45:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 5DDD84A5E1A6; Wed, 9 Aug 2017 21:45:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5reYsMW2fQ2f; Wed, 9 Aug 2017 21:45:30 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 1A48B4A5E18F; Wed, 9 Aug 2017 21:45:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Scott O. Bradner" In-Reply-To: <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> Date: Wed, 9 Aug 2017 21:45:29 -0400 Cc: Spencer Dawkins at IETF , NomCom-Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <5CDA062B-C9FA-413A-9411-90CAA52B91E6@sobco.com> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> To: Joel M Halpern X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 01:45:36 -0000 send questions to clarify the IAOC view on qualifications for an IAOC = seat or about anything that was not covered by the IAOC=E2=80=99s statement to the noncom (i.e. something they forgot like = actual travel commitment ) Scott > On Aug 9, 2017, at 8:42 PM, Joel Halpern wrote: >=20 > As the IAOC is not an approval body, I have trouble seeing why the = nomcom would need to send anything to the IAOC. Even if the Nomcom had = operational feedback from the community about the IAOC as a body, it = seems to me that the advisor would not be the means to send such back. >=20 > I seem to be in the minority, but I like calling this something other = than liaison, because of the set of roles that apply to liaisons, but = not to this IAOC suggested information source. >=20 > I mildly prefer Spencer's current formulation that the nomcom asks for = the advisor. The factor that strikes me is that this way the nomcom and = its chair can ensure that they are comfortable with the appointee. (That = is not their right with the liaisons, as those individuals are = responsible to their providing bodies.) >=20 > Yours, > Joel >=20 > On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote: >> Dear all, >> On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis > wrote: >> Brian, >> =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way, = I=E2=80=99ve often seen the >> case where there are two liaison individuals between a pair of >> organizations, one for each direction. >> Well, I think Andy is right here (the IAB certainly appoints IETF = liaisons to other SDOs as directional), but that's side-stepping the = more interesting question, which is not what we call this role, but = whether we expect Nomcom to send anything back to the IAOC via the (the = draft calls it) advisor. >> And that question may not need to affect the resulting text = (https://tools.ietf.org/html/rfc7437#section-4.9 says >> An advisor is responsible for such duties as specified by the >> invitation that resulted in the appointment. >> which is pretty darned broad), but if it might affect the resulting = text, that would be good to know sooner, rather than later. >> Thanks, >> Spencer >> Cheers, >> Andy >> On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter >> > >> wrote: >> (Adjusted the CC) >> On 10/08/2017 06:48, Robert Sparks wrote: >> > Spencer - >> > >> > The attempt to avoid the term liaison is not working well = for me. >> 'Liaison' implies 2-way communication; 'advisor' implies 1-way >> comunication. >> I think we need to decide which we want. >> Brian >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >=20 > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From nobody Wed Aug 9 18:53:54 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 D430C131CDF for ; Wed, 9 Aug 2017 18:53:52 -0700 (PDT) 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 glcn2IdS_NQa for ; Wed, 9 Aug 2017 18:53:50 -0700 (PDT) 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 84696129B25 for ; Wed, 9 Aug 2017 18:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 16E94BDD8; Thu, 10 Aug 2017 02:53:48 +0100 (IST) 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 V-4B18VsHpA7; Thu, 10 Aug 2017 02:53:47 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D57E7BDCC; Thu, 10 Aug 2017 02:53:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1502330026; bh=uXEKqDMlo3P039AmLAo5tss7g8clEfJZQzQioFbweq4=; h=Subject:Cc:References:To:From:Date:In-Reply-To:From; b=yhgLthCdlurznUZdcQPoOLJkfr3ENg97Vwuj9mJK17hrenH/lchOtLJxupCBiTkvZ K4ix9Zw4C7DIEAtv7c1N4EiLMwSyEcWsCKFJ9An8wcd2rbKDw0MNlmxao1yILEmRLR 52mfmLc3YQcwmcEcFkV/5a8RuBDbqiiwEevZAwGQ= References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> To: NomCom-Discussion From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> Date: Thu, 10 Aug 2017 02:53:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BMumt3HbeEKUGQXKiBdaxLBtu5f6LBVbq" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 01:53:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BMumt3HbeEKUGQXKiBdaxLBtu5f6LBVbq Content-Type: multipart/mixed; boundary="fwcvgbfXNOGCOrIs0ipGepuoNdEWTOvlp"; protected-headers="v1" From: Stephen Farrell To: NomCom-Discussion Cc: Spencer Dawkins at IETF Message-ID: <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> In-Reply-To: --fwcvgbfXNOGCOrIs0ipGepuoNdEWTOvlp Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, FWIW, my take: - I don't care if we use the term liaison or advisor - I do think the IAOC has to pick the person - I do think every nomcom needs such a person helping out - I'm fine if a recent but not current IAOC member is the stuckee, where recent is say <=3D 2 years since being an IAOC appointee. Weasel wording around that goal is fine so long as the intent is clear. - If the stuckee is not a current IAOC member, then I think there needs to be some form of appeal of the appointment possible, even if that's via some hard to exercise mechanism. S. --fwcvgbfXNOGCOrIs0ipGepuoNdEWTOvlp-- --BMumt3HbeEKUGQXKiBdaxLBtu5f6LBVbq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZi7yqAAoJEC88hzaAX42ix9IH/21B8r7Olj+QaU6/Uwxg9FuK AOj+rUkby1/gTBhdmMIC3L7wuRU1nlDtNC9zrzzQ5y+wKow13cZg/1YBNDZOrcnb PPZasHUC1coCSs+Yl0uwsmkkjKzXFRGiDJg/F10DPikmOBT8H5jRRy/+vPno+Wv4 DrpYDCMod92953eZap4Kpgp/+osuD0fZHJsfXNfQ6g8jv6UpOZoX32jbGP0hKkQ7 peFg5RlkH1ELY5q41QA/GRjMYcuraVEjJ1nF4vD6lKRyPaZADAtkoO2E+KmY9yhY YAQIMcWVyDOYCbpbS7U9a42pn1mqten4/MUzwEiazckAMpe+g54mvYNIBCuxDoI= =Mmc9 -----END PGP SIGNATURE----- --BMumt3HbeEKUGQXKiBdaxLBtu5f6LBVbq-- From nobody Wed Aug 9 19:26:10 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 DD85C13251F for ; Wed, 9 Aug 2017 19:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=joelhalpern.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 qgZUhSliFvLn for ; Wed, 9 Aug 2017 19:26:07 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 EEF9C132521 for ; Wed, 9 Aug 2017 19:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D73BC42A720; Wed, 9 Aug 2017 19:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1502331966; bh=OYUNKOwSunbyPgm2B5urXX/EZl2JX/LjvE7inzIuIQ8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ckm0TUb5Xg38tvwVuaccRkGDeHGim07RwtbMzC24efMiz3KYcK7BsaY1RqTb7d+9A +wXC0cp16y44b3ok/FwSPGUoechTNTM/STYAPTshVlHmeaWRbH7G0oEOiQ453MMNfj EcLJtqZmqMlIBHpkwF1VxqpgktECVeP8xZWOPkUY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1EE7C42A717; Wed, 9 Aug 2017 19:26:05 -0700 (PDT) To: "Scott O. Bradner" Cc: Spencer Dawkins at IETF , NomCom-Discussion References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <5CDA062B-C9FA-413A-9411-90CAA52B91E6@sobco.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 9 Aug 2017 22:26:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5CDA062B-C9FA-413A-9411-90CAA52B91E6@sobco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 02:26:09 -0000 I do not tend to view asking a quesiton as providing information. The nomcom can and does ask all sorts of folks questions The difference is that the liaisons have responsibilities to the bodies they come from regarding the process. This IAOC information source does not have such responsibilities. Yours, Joel On 8/9/17 9:45 PM, Scott O. Bradner wrote: > send questions to clarify the IAOC view on qualifications for an IAOC seat or about anything that was not covered by the > IAOC’s statement to the noncom (i.e. something they forgot like actual travel commitment ) > > Scott > >> On Aug 9, 2017, at 8:42 PM, Joel Halpern wrote: >> >> As the IAOC is not an approval body, I have trouble seeing why the nomcom would need to send anything to the IAOC. Even if the Nomcom had operational feedback from the community about the IAOC as a body, it seems to me that the advisor would not be the means to send such back. >> >> I seem to be in the minority, but I like calling this something other than liaison, because of the set of roles that apply to liaisons, but not to this IAOC suggested information source. >> >> I mildly prefer Spencer's current formulation that the nomcom asks for the advisor. The factor that strikes me is that this way the nomcom and its chair can ensure that they are comfortable with the appointee. (That is not their right with the liaisons, as those individuals are responsible to their providing bodies.) >> >> Yours, >> Joel >> >> On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote: >>> Dear all, >>> On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis > wrote: >>> Brian, >>> “Liaison” as an actual person can be one-way, I’ve often seen the >>> case where there are two liaison individuals between a pair of >>> organizations, one for each direction. >>> Well, I think Andy is right here (the IAB certainly appoints IETF liaisons to other SDOs as directional), but that's side-stepping the more interesting question, which is not what we call this role, but whether we expect Nomcom to send anything back to the IAOC via the (the draft calls it) advisor. >>> And that question may not need to affect the resulting text (https://tools.ietf.org/html/rfc7437#section-4.9 says >>> An advisor is responsible for such duties as specified by the >>> invitation that resulted in the appointment. >>> which is pretty darned broad), but if it might affect the resulting text, that would be good to know sooner, rather than later. >>> Thanks, >>> Spencer >>> Cheers, >>> Andy >>> On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter >>> > >>> wrote: >>> (Adjusted the CC) >>> On 10/08/2017 06:48, Robert Sparks wrote: >>> > Spencer - >>> > >>> > The attempt to avoid the term liaison is not working well for me. >>> 'Liaison' implies 2-way communication; 'advisor' implies 1-way >>> comunication. >>> I think we need to decide which we want. >>> Brian >>> _______________________________________________ >>> ietf-nomcom mailing list >>> ietf-nomcom@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >>> >>> _______________________________________________ >>> ietf-nomcom mailing list >>> ietf-nomcom@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >>> >>> _______________________________________________ >>> ietf-nomcom mailing list >>> ietf-nomcom@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom > From nobody Wed Aug 9 22:31: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 D4BB7132542 for ; Wed, 9 Aug 2017 22:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5aCCRb6Z24WN for ; Wed, 9 Aug 2017 22:31:13 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 E6D73132519 for ; Wed, 9 Aug 2017 22:31:12 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id o86so36938438pfj.1 for ; Wed, 09 Aug 2017 22:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=x/3W2J7cs/Onwxc27+VyXExHBKqOqMdV1FyUVXwGtdE=; b=XGmV5ruCGDkihkXRzERT6Sfo0CaeYiGSycNW0MVr2EzBNzA9iiJTSHVb2i1weMhyfu TYet3YDoftqNpP2YFKAuV/uBbGrGYOZ+OS3HFxqVUX93ItxYr0sa9V0l4LHCzpWbrZNu RMK33/q/ZeCKx15J1g2Xo8lClfIZ+VOFEtnKUB0Zh3bIV8D2vUX1bDbcoh21ZsJb+EM3 9F/P16qgE3AMXMNJPCpfem5v0dLiGzCKhE6GNfYkIug8loGCJDGffzMfgT3ZykYZSKgo h0zQ5oZqtDGBoetyyR4qpOETwGtprPtjyC8kfcycVcs0IR7L3yA3MpaJCBxnT4zvu6/u ts5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=x/3W2J7cs/Onwxc27+VyXExHBKqOqMdV1FyUVXwGtdE=; b=r0+SpiPRhzX7Q4iqAcu09UfzwRvkvKdX1SGf41WP6gqdF5SWGS0+hCmzkMIgMrF35D n9JevT7SxQYQFFrL4rsMfayAd2AvLZnK7kIOBLWEqpzukLRd5log1xnsWrrrHha3pJ6M qWisYOLXAkCVlDiml41Y3ydWCXi8mSWKvzOlQuiC7ru+tiugcPRkyv6BSzDgylL/YwIJ MkMJbr5Rbu3U4/n26m46BJtwZb4G08Xxry5RWOLNKVkFKSmL6i2p0ZZd9QtV0pbrJhQ3 hRB8jSWd2Dw3l+42LIlRjilS+lUeCugkuPKyItdz3QOzbRccF89rHd3xQ9UGtC5bz0B1 zkiw== X-Gm-Message-State: AHYfb5i/gET0HjXErVEXkVrEtdEmWE95XqeD5aLAmT6/xbjewydfJ8LU zMMdEPMO0vYp5+Ke X-Received: by 10.98.109.65 with SMTP id i62mr10915021pfc.309.1502343072217; Wed, 09 Aug 2017 22:31:12 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f88sm10931204pff.74.2017.08.09.22.31.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 22:31:11 -0700 (PDT) To: ietf-nomcom@ietf.org References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <10f48675-7a42-1f9a-0d75-e75bf9468c5d@gmail.com> Date: Thu, 10 Aug 2017 17:31:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 10 Aug 2017 05:31:15 -0000 On 10/08/2017 12:42, Joel Halpern wrote: > As the IAOC is not an approval body, I have trouble seeing why the=20 > nomcom would need to send anything to the IAOC. Even if the Nomcom had= =20 > operational feedback from the community about the IAOC as a body, it=20 > seems to me that the advisor would not be the means to send such back. >=20 > I seem to be in the minority, but I like calling this something other=20 > than liaison, because of the set of roles that apply to liaisons, but=20 > not to this IAOC suggested information source. >=20 > I mildly prefer Spencer's current formulation that the nomcom asks for = > the advisor. The factor that strikes me is that this way the nomcom an= d=20 > its chair can ensure that they are comfortable with the appointee.=20 > (That is not their right with the liaisons, as those individuals are=20 > responsible to their providing bodies.) That's what I wanted to say, but said in a confusing way. Brian >=20 > Yours, > Joel >=20 > On 8/9/17 7:03 PM, Spencer Dawkins at IETF wrote: >> Dear all, >> >> On Wed, Aug 9, 2017 at 4:33 PM, Andrew G. Malis > > wrote: >> >> Brian, >> >> =E2=80=9CLiaison=E2=80=9D as an actual person can be one-way, I=E2= =80=99ve often seen the >> case where there are two liaison individuals between a pair of >> organizations, one for each direction. >> >> >> Well, I think Andy is right here (the IAB certainly appoints IETF=20 >> liaisons to other SDOs as directional), but that's side-stepping the=20 >> more interesting question, which is not what we call this role, but=20 >> whether we expect Nomcom to send anything back to the IAOC via the (th= e=20 >> draft calls it) advisor. >> >> And that question may not need to affect the resulting text=20 >> (https://tools.ietf.org/html/rfc7437#section-4.9 says >> >> An advisor is responsible for such duties as specified by the >> invitation that resulted in the appointment. >> >> which is pretty darned broad), but if it might affect the resulting=20 >> text, that would be good to know sooner, rather than later. >> >> Thanks, >> >> Spencer >> >> Cheers, >> Andy >> >> >> On Wed, Aug 9, 2017 at 4:15 PM, Brian E Carpenter >> >= >> wrote: >> >> (Adjusted the CC) >> >> On 10/08/2017 06:48, Robert Sparks wrote: >> > Spencer - >> > >> > The attempt to avoid the term liaison is not working well fo= r me. >> >> 'Liaison' implies 2-way communication; 'advisor' implies 1-way= >> comunication. >> I think we need to decide which we want. >> >> Brian >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> >> >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >> >> >> >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> >=20 > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom >=20 From nobody Fri Aug 11 14:41:13 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 E6B3E13252C for ; Fri, 11 Aug 2017 14:41:11 -0700 (PDT) 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=MiWD8g05; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=FDnSFCAn 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 SQQBzagSdNih for ; Fri, 11 Aug 2017 14:41:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 172CF132561 for ; Fri, 11 Aug 2017 14:41:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.83.78]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v7BLewgG008054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Aug 2017 14:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1502487669; x=1502574069; bh=v7BROVAXnCJInw5KsnuUqbhImjVWCMlJOlie5sd289w=; h=Date:To:From:Subject:In-Reply-To:References; b=MiWD8g05yDpl/BnWMvsMtjMi/sRjwl1b2GA5oiJBfq/ML7Yf5BC2SYmqlHgAFy7fF /xZ5x+asuZF8I8lIPbZUqrbMD3SR0xpOFStDWUwxIlYiQDVmoVwXPqt74tqAKDpaKj HXwvQ1Ao5mLN2nUw51QNh4nFvxB4z4uPQsWWyiao= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1502487669; x=1502574069; i=@elandsys.com; bh=v7BROVAXnCJInw5KsnuUqbhImjVWCMlJOlie5sd289w=; h=Date:To:From:Subject:In-Reply-To:References; b=FDnSFCAnrHXMaQhuYQHsZeNr5yEkvEWLaNVP/+JF9nEpo8udhRkekFCZmUDcKtopb Td+x9l9wiUybZHljuNyfXT/h+vDpXPGuIKiJUQD8WyKkQ5LW/78/hfszdYF5moUean i3BQYZAuSEQla8FW8uEpN8ENoa79O1tNoIAxRelY= Message-Id: <6.2.5.6.2.20170811142232.0ee31fc0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Aug 2017 14:34:57 -0700 To: John C Klensin , ietf-nomcom@ietf.org From: S Moonesamy In-Reply-To: <18658F3EEA38067A4230D855@PSB> References: <18658F3EEA38067A4230D855@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [ietf-nomcom] Fwd: New Version Notification for draft-dawkins-iesg-nomcom-advisor-iaoc-00.txt 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: Fri, 11 Aug 2017 21:41:12 -0000 Hi John, At 10:01 03-08-2017, John C Klensin wrote: >While I concur with those who have indicated that this draft is >ok (or close) assuming that is what the community wants to do, I >want to raise a question about the latter that may or may not be >directly relevant to the document. > >As time has passed and the Nomcom has apparently become >increasingly dependent on questionnaires, interviews, and >Advisors rather than first-hand knowledge of possible candidates >by the voting members, questions of influences on the Nomcom >become increasingly important. For the Nomcom to invite someone Yes, it seems that Nomcom relies on the questionnaires and interviews instead of having first-hand knowledge of the possible candidates. >So it seems to me that we should be at least considering: > >(1) Encouraging Nomcoms to ask whatever questions about >operation, job requirements, etc., seem appropriate of various >bodies without needing to rely on Liaisons or Advisors for that >rule. Is there an issue for which it would be more efficient for a person with knowledge of the inner workings to get the information from the IAOC? If that is not the case, the healthy choice would be for Nomcom to ask questions about the job requirements and/or the operations of the body. Regards, S. Moonesamy From nobody Tue Aug 22 20:11:21 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 54BBD1321DE for ; Tue, 22 Aug 2017 20:11:19 -0700 (PDT) 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 MJr2sql00g0A for ; Tue, 22 Aug 2017 20:11:17 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 71B791321BF for ; Tue, 22 Aug 2017 20:11:17 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s187so2831603ywf.2 for ; Tue, 22 Aug 2017 20:11:17 -0700 (PDT) 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=mjD3s+MjelHJkRPh56fM/VJouWg7jfJVU5+F2NmYlC8=; b=hLpTNLBW3nvjp3XVkQlG2Xc90RcI9AE6hOrWtFK8zE8pEC5h3fEJWRqhASvvMbgYpx 4m/lC1ZOI9VW++C9OyEI+t6Wgkio0kJwMTGDAJa1yx7Zl4xgHQ9lh96GaxASXeMP0Uz+ a7rbwT9ANhdibvCBaRaTO5LH5JdCr/NvOTrl06xparc3D3v9rWZNTz+OQjJo+bjGuPeO 3woeVPPBTbllhyKBn7sJNG+7ZZF6eVVdXtnF7OlZPwXJhRjQYHMoEZ6k1uoG+1S3PGqs zyvgrju+95thnXoVYDsxDpuVhEsSN8eY43PbddIbVXMOpqHOseYyh9D/aaARqFHYTng6 qc0A== 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=mjD3s+MjelHJkRPh56fM/VJouWg7jfJVU5+F2NmYlC8=; b=erU8ZjTyfQcRAOAsdeIzuMsqv3iZozGKXB2GRufLHSVXmDBGH+eyzIyq2WOBsnVfoE WToGPk4lkDccVoOBmO3ED5gxSi61fkCz8IJPK8NClRaQtfLC97M+1BLRXCBdMkNG7ycB engA6WjCu8G14GuQBAkKGK1VxbuMU4UdFyXKFhSZa4ecA3T8ftVBcduOScp+Tjipj6tB 76VZwXQh/xxCm+6CQ9dh7We4rMraJbwSRrMXyAXnt+lKnzSLSYINWtGm45zOZcNdTSER 3RhXvt9TDLptTfWMUUZbOilF5pNaZLlYwQJsPcYxzpjvnw4Gl7TNXrTanF72ntMdVK9/ tZZw== X-Gm-Message-State: AHYfb5hBwDM5lgSMvBvZ7tekJ/Ftfp4ulvJGLVbro6kRAwAZrHnUHDAk Vqo1NhwhnBYkbEnoezPPn8nCDbommw== X-Received: by 10.37.52.80 with SMTP id b77mr961304yba.293.1503457876389; Tue, 22 Aug 2017 20:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Tue, 22 Aug 2017 20:11:15 -0700 (PDT) In-Reply-To: <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Tue, 22 Aug 2017 22:11:15 -0500 Message-ID: To: Stephen Farrell Cc: NomCom-Discussion Content-Type: multipart/alternative; boundary="001a1147c8f8a8335005576310ba" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Wed, 23 Aug 2017 03:11:19 -0000 --001a1147c8f8a8335005576310ba Content-Type: text/plain; charset="UTF-8" Hi, Stephen, On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell wrote: > > Hiya, > > FWIW, my take: > > - I don't care if we use the term liaison or advisor > - I do think the IAOC has to pick the person > - I do think every nomcom needs such a person helping > out > Sorry for my delay in responding. On your other points, I think I know what to do with your feedback, but this one is worth talking about some more. There are different levels of "Nomcoms needing someone who speaks IAOC-ese fairly fluently". I'm shooting for "don't forget to think about how you'll know whether you've got a viable IAOC candidate to forward to the confirming body, and if you don't know who can help, the IAOC should be well-placed to make suggestions about people who can help". I could be shooting for "the Nomcom has to ask for help", or even "has to ask the IAOC for help". At the extreme, I could be shooting for "change the definition of committee membership so that if you don't have representation from the IAOC, you've got a really big problem", to match not having a liaison from the IAB or IESG. Are people comfortable with this being more permissive than prescriptive? Thanks, Spencer > - I'm fine if a recent but not current IAOC member is > the stuckee, where recent is say <= 2 years since > being an IAOC appointee. Weasel wording around that > goal is fine so long as the intent is clear. > - If the stuckee is not a current IAOC member, then I > think there needs to be some form of appeal of the > appointment possible, even if that's via some hard > to exercise mechanism. > > S. > > --001a1147c8f8a8335005576310ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Stephen,

On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell <steph= en.farrell@cs.tcd.ie> wrote:
- I'm fine if a recent but not current IAOC member is
=C2=A0 the stuckee, where recent is say <=3D 2 years since
=C2=A0 being an IAOC appointee. Weasel wording around that
=C2=A0 goal is fine so long as the intent is clear.
- If the stuckee is not a current IAOC member, then I
=C2=A0 think there needs to be some form of appeal of the
=C2=A0 appointment possible, even if that's via some hard
=C2=A0 to exercise mechanism.

S.


--001a1147c8f8a8335005576310ba-- From nobody Thu Aug 24 07:58:45 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 6A3BE132962 for ; Thu, 24 Aug 2017 07:58:43 -0700 (PDT) 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 ZkgzxhyumOFI for ; Thu, 24 Aug 2017 07:58:41 -0700 (PDT) Received: from bsa2.jck.com (ns.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 D34FB132940 for ; Thu, 24 Aug 2017 07:58:41 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dktag-000EZU-91; Thu, 24 Aug 2017 10:58:38 -0400 Date: Thu, 24 Aug 2017 10:58:32 -0400 From: John C Klensin To: Spencer Dawkins at IETF , Stephen Farrell cc: NomCom-Discussion Message-ID: In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@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 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: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 14:58:43 -0000 --On Tuesday, August 22, 2017 22:11 -0500 Spencer Dawkins at IETF wrote: > On your other points, I think I know what to do with your > feedback, but this one is worth talking about some more. > > There are different levels of "Nomcoms needing someone who > speaks IAOC-ese fairly fluently". > > I'm shooting for "don't forget to think about how you'll know > whether you've got a viable IAOC candidate to forward to the > confirming body, and if you don't know who can help, the IAOC > should be well-placed to make suggestions about people > who can help". > > I could be shooting for "the Nomcom has to ask for help", or > even "has to ask the IAOC for help". > > At the extreme, I could be shooting for "change the definition > of committee membership so that if you don't have > representation from the IAOC, you've got a really big > problem", to match not having a liaison from the IAB or IESG. > > Are people comfortable with this being more permissive than > prescriptive? Spencer, I'm almost always comfortable with more permissive or, more specifically, with guidelines and principles rather than rules. That is in part because I think the IETF has a terrible track record when we try to make specific rules, almost always discovering either that they are not quite right and require either workarounds or more effort to try to fix or because they lead to quibbling about the rules rather than getting useful work done. However, as I've tried to say before, I'm worried about a different problem in this case, which is whether, as the individual knowledge of Nomcom members goes down, the presence of all of those liaisons could have undue influence by any of: (i) influencing the Nomcom for or against particular candidates. (ii) influencing the Nomcom too much about the role of the relevant bodies or job descriptions. That is especially hazardous because part of the original intent of the Nomcom was that it be able to make decisions that particular bodies were going in the wrong direction and then make appointments with the express intention of changing that. (iii) Having a chilling effect on community members who wanted to make comments (favorable or unfavorable) about particular candidates that they wouldn't want generally known, or known to the candidates or their supporters or opponents... especially when the liaison was believed to have a strong (again, whether positive or negative) relationship with that candidate. These are obviously far more general issues than how to add an IAOC liaison or how, but I believe that specifying an additional liaison, especially from a body with the composition and role of the IAOC, could considerable amplify any issues or concerns of that type. best, john From nobody Thu Aug 24 09:17:34 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 B9AE91329B8 for ; Thu, 24 Aug 2017 09:17:32 -0700 (PDT) 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 rsgM0lMibXas for ; Thu, 24 Aug 2017 09:17:29 -0700 (PDT) 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 B290A126C7A for ; Thu, 24 Aug 2017 09:17:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D1A2BE55; Thu, 24 Aug 2017 17:17:27 +0100 (IST) 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 qgyx5Q4sMsdE; Thu, 24 Aug 2017 17:17:27 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A77EBE50; Thu, 24 Aug 2017 17:17:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1503591447; bh=8rxhIQIHBbrS8V9R9VdFCH/myK2xch2uEF+wImq6oL0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=E0l3EpmWoTu6QPRflEJxtFx/1CQOjgffa5mmXfyWP0LDuivofiIA0GHOlHfHYvdFC QxroOJBtokylqVZMWMeLMKZpTGnDtXojE9mM3lxxmO6xIsXg8unN/C7NPHxuwrCeZ2 8fidA721sLZmAMZqkARcsaE3njV7E0ZRBvX5foio= To: Spencer Dawkins at IETF Cc: NomCom-Discussion References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> Date: Thu, 24 Aug 2017 17:17:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RiC82x5PDdLg9soxihVGb93V7snQOl84K" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 16:17:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RiC82x5PDdLg9soxihVGb93V7snQOl84K Content-Type: multipart/mixed; boundary="ABm6Gt01jfhvc7wm1DcqmhVVusSVfIfgt"; protected-headers="v1" From: Stephen Farrell To: Spencer Dawkins at IETF Cc: NomCom-Discussion Message-ID: <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> In-Reply-To: --ABm6Gt01jfhvc7wm1DcqmhVVusSVfIfgt Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 23/08/17 04:11, Spencer Dawkins at IETF wrote: > Hi, Stephen, >=20 > On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> FWIW, my take: >> >> - I don't care if we use the term liaison or advisor >> - I do think the IAOC has to pick the person >> - I do think every nomcom needs such a person helping >> out >> >=20 > Sorry for my delay in responding. Ditto:-) >=20 > On your other points, I think I know what to do with your feedback, but= > this one is worth talking about some more. >=20 > There are different levels of "Nomcoms needing someone who speaks IAOC-= ese > fairly fluently". >=20 > I'm shooting for "don't forget to think about how you'll know whether > you've got a viable IAOC candidate to forward to the confirming body, a= nd > if you don't know who can help, the IAOC should be well-placed to make > suggestions about people > who can help". >=20 > I could be shooting for "the Nomcom has to ask for help", or even "has = to > ask the IAOC for help". >=20 > At the extreme, I could be shooting for "change the definition of commi= ttee > membership so that if you don't have representation from the IAOC, you'= ve > got a really big problem", to match not having a liaison from the IAB o= r > IESG. It's not a hill on which I'd die, but I don't think it extreme to expect every nomcom to have an IAOC-helper, even for years when there is no IAOC appointment for nomcom to make. So I think your last target above is the better one. I am fine with the description of "helper" being vague-ish to allow for iasa2 etc. Cheers, S. >=20 > Are people comfortable with this being more permissive than prescriptiv= e? >=20 > Thanks, >=20 > Spencer >=20 >=20 >> - I'm fine if a recent but not current IAOC member is >> the stuckee, where recent is say <=3D 2 years since >> being an IAOC appointee. Weasel wording around that >> goal is fine so long as the intent is clear. >> - If the stuckee is not a current IAOC member, then I >> think there needs to be some form of appeal of the >> appointment possible, even if that's via some hard >> to exercise mechanism. >> >> S. >> >> >=20 --ABm6Gt01jfhvc7wm1DcqmhVVusSVfIfgt-- --RiC82x5PDdLg9soxihVGb93V7snQOl84K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZnvwWAAoJEC88hzaAX42idzMH/jKyZ13BAS6WSJbfFLKJHsHs /K9L4yqYaqL0vUpfUgRqDqbGPJLD47vgA69qgDnjCTnVSBzVxPXU1ApyCvvydiKf fg6gWQ1RwSF2xv8pwb9tXXw+7Y7WSpv0FDYguBK3pSmNjlKyki1/P0eqeSKDL91N APZ6T6mZA0ACZayYQvvR4x5+SB5etkQuWUKXRHKXfvWR6ett70Yc85HYHCWQVp2n 2Yu5Vd0Z8Q9qxlEwfw1+BaAx6e7FoL4pUYHjWDVo3B8C4eTLAgJk9NDZQmxxwb5Z Wtu2y2NOqHgoGJbzose3C8dCQAMRR+vnB6a3he5BfOOTGblLukyaeHY6aHdwSEg= =3hHn -----END PGP SIGNATURE----- --RiC82x5PDdLg9soxihVGb93V7snQOl84K-- From nobody Thu Aug 24 14:01:17 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 4B27E132403 for ; Thu, 24 Aug 2017 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 zuQ7Y-ormABf for ; Thu, 24 Aug 2017 14:01:13 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 3513A1323A8 for ; Thu, 24 Aug 2017 14:01:13 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id y64so3807201ywf.1 for ; Thu, 24 Aug 2017 14:01:13 -0700 (PDT) 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=xwjduL52sNqWy+NH6NFusPnYrHiX7W6Wc59W7S8Ewfg=; b=VMDCcabxKStb7nWOQ4HdK0MR6q1GeXeSuzV5WkwuXyj0cmfM+3C+2tfYviyMDV/wKT Qt9y8xmw5gA0aKHHodqVa37u33DoQHZm2leD0FJXhkSlU10TH/d8P3O/pv8jki4FPXPW aLiydhzGuVgYCw23ziW78C259KY1x2LiA1ewTqcUuIRKx6g0urOOIQPJZk4TqZ6ksYZf 09eWkrL/suz1agaUk6Jdkl2mr5UpcQ40hcw7k7XkoRECGamhxxAEYWLVZ84Np1A+ow65 nslj70G0d6VDMQqPmG3R2K9PhsqFAlVKqxng8LCyXTzrno9pjNpL+Rf7xxr2eWdqmQ8z nIjA== 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=xwjduL52sNqWy+NH6NFusPnYrHiX7W6Wc59W7S8Ewfg=; b=N5kDWz0RYbx4WD7ME7ryu44VnlPf3rlnV531jLs3NUjgh/ZsYPXdCNzE4f9RbyMXoP /JQHjqAebCjEF1lNMSaWtrOxu2Bk7x8XPfMYNXjUtQpC6rTi0erxiCEEo+TtJKk/3Q4H odoUCeXpKYlu8rlrSaw2D+FNdsCWcGo5HnShZ0SJUGeXwUU18ZJFC+8L9yvWmbuWR6mz UoCaOPGqxJvS8zPEEaEhhi0poU+Kfn2KDSR+6Obm9pElZ6mvxe6ppVQpHFTks3qYOujs I3tICDk5RVAaXTtHwVNTOo6QA25fwJehjqUUnSYyhz6yz8rCRMF/jYJpZYF0BDx73gG6 7xSQ== X-Gm-Message-State: AHYfb5ibTg6s6u++VYFBiE/uixOYkb0dM94QrGDDDNAkU7y2zI689Amc F7C1cEBcjUibimezXwTWaO8G/D49Ueke X-Received: by 10.129.229.4 with SMTP id s4mr5938150ywl.130.1503608472142; Thu, 24 Aug 2017 14:01:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 14:01:11 -0700 (PDT) In-Reply-To: <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 16:01:11 -0500 Message-ID: To: Stephen Farrell Cc: NomCom-Discussion Content-Type: multipart/alternative; boundary="089e08222cb4dd090105578620a9" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 21:01:16 -0000 --089e08222cb4dd090105578620a9 Content-Type: text/plain; charset="UTF-8" Hi, Stephen, On Thu, Aug 24, 2017 at 11:17 AM, Stephen Farrell wrote: > > Hiya, > > On 23/08/17 04:11, Spencer Dawkins at IETF wrote: > > Hi, Stephen, > > > > On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> FWIW, my take: > >> > >> - I don't care if we use the term liaison or advisor > >> - I do think the IAOC has to pick the person > >> - I do think every nomcom needs such a person helping > >> out > >> > > > > Sorry for my delay in responding. > > Ditto:-) > > > > > On your other points, I think I know what to do with your feedback, but > > this one is worth talking about some more. > > > > There are different levels of "Nomcoms needing someone who speaks > IAOC-ese > > fairly fluently". > > > > I'm shooting for "don't forget to think about how you'll know whether > > you've got a viable IAOC candidate to forward to the confirming body, and > > if you don't know who can help, the IAOC should be well-placed to make > > suggestions about people > > who can help". > > > > I could be shooting for "the Nomcom has to ask for help", or even "has to > > ask the IAOC for help". > > > > At the extreme, I could be shooting for "change the definition of > committee > > membership so that if you don't have representation from the IAOC, you've > > got a really big problem", to match not having a liaison from the IAB or > > IESG. > > It's not a hill on which I'd die, but I don't think it extreme > to expect every nomcom to have an IAOC-helper, even for years > when there is no IAOC appointment for nomcom to make. So I think > your last target above is the better one. > I agree with your starting point, for a couple of reasons. First, in private conversations, I am told that some Nomcoms get feedback about AD nominees that is actually more appropriate for IAOC nominees, because the community isn't quite sure where the dividing line between the two bodies is. I don't know more details, because that feedback is Nomcom-confidential, and I wasn't on the Nomcom(s) where that happened, but, yes, having someone who can say "but that's our job" in the room seems helpful, whether that particular Nomcom is reviewing an IAOC position or not. (I wouldn't be surprised to hear that Nomcoms have also gotten feedback about IAOC nominees that should have been pointed at IESG nominees, but no one has told me that, so forget I said it) Second, and more important than it should be, the reason the past Nomcom didn't ask for a liaison from IAOC was because it's not part of https://tools.ietf.org/html/rfc7437, and the past chair/advisor didn't think of it, because he had not reviewed an IAOC position and hadn't asked for a liaison when he was chair. So, if a Nomcom doesn't have an IAOC advisor because they're not reviewing an IAOC position, our running code is that it's easy to forget to ask for one when a Nomcom does review an IAOC position ;-) Let me chew on how I can say that Nomcoms really need that input, but what I'm concerned about is that a Nominating Committee is defined as The nominating committee comprises at least a Chair, 10 voting volunteers, two liaisons, and an advisor. and if I state having an IAOC advisor is a (new) requirement, a Nominating Committee that doesn't have one would be vulnerable to an appeal to the ISOC board, because the structure doesn't match what's in the BCP - and because we're talking about IASA 2.0, sending a representative for IAOC may not even make sense, but the BCP text wouldn't go away by itself (BCP text that could go away by itself was the point of https://tools.ietf.org/html/rfc3933, but whatever). I may be excessively sensitive about making this prescriptive, because we had to write a new BCP to make a one-word change in a couple of BCPs, so I'm happy to listen to reason. Spencer, (in this case) as author of https://tools.ietf.org/html/rfc7475, which was less simple than you might hope ... I am fine with the description of "helper" being vague-ish to > allow for iasa2 etc. > > Cheers, > S. > > > > > Are people comfortable with this being more permissive than prescriptive? > > > > Thanks, > > > > Spencer > > > > > >> - I'm fine if a recent but not current IAOC member is > >> the stuckee, where recent is say <= 2 years since > >> being an IAOC appointee. Weasel wording around that > >> goal is fine so long as the intent is clear. > >> - If the stuckee is not a current IAOC member, then I > >> think there needs to be some form of appeal of the > >> appointment possible, even if that's via some hard > >> to exercise mechanism. > >> > >> S. > >> > >> > > > > --089e08222cb4dd090105578620a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Stephen,

On Thu, Aug 24, 2017 at 11:17 AM, Stephen Farrell <ste= phen.farrell@cs.tcd.ie> wrote:

Hiya,

On 23/08/17 04:11, Spencer Dawkins at IETF wrote:
> Hi, Stephen,
>
> On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> FWIW, my take:
>>
>> - I don't care if we use the term liaison or advisor
>> - I do think the IAOC has to pick the person
>> - I do think every nomcom needs such a person helping
>>=C2=A0 =C2=A0out
>>
>
> Sorry for my delay in responding.

Ditto:-)

>
> On your other points, I think I know what to do with your feedback, bu= t
> this one is worth talking about some more.
>
> There are different levels of "Nomcoms needing someone who speaks= IAOC-ese
> fairly fluently".
>
> I'm shooting for "don't forget to think about how you'= ;ll know whether
> you've got a viable IAOC candidate to forward to the confirming bo= dy, and
> if you don't know who can help, the IAOC should be well-placed to = make
> suggestions about people
> who can help".
>
> I could be shooting for "the Nomcom has to ask for help", or= even "has to
> ask the IAOC for help".
>
> At the extreme, I could be shooting for "change the definition of= committee
> membership so that if you don't have representation from the IAOC,= you've
> got a really big problem", to match not having a liaison from the= IAB or
> IESG.

It's not a hill on which I'd die, but I don't think it e= xtreme
to expect every nomcom to have an IAOC-helper, even for years
when there is no IAOC appointment for nomcom to make. So I think
your last target above is the better one.

I agree with your starting point, for a couple of reasons.
First, in private conversations, I am told that some Nomcoms ge= t feedback about AD nominees that is actually more appropriate for IAOC nom= inees, because the community isn't quite sure where the dividing line b= etween the two bodies is. I don't know more details, because that feedb= ack is Nomcom-confidential, and I wasn't on the Nomcom(s) where that ha= ppened, but, yes, having someone who can say "but that's our job&q= uot; in the room seems helpful, whether that particular Nomcom is reviewing= an IAOC position or not.=C2=A0

(I wouldn't be= surprised to hear that Nomcoms have also gotten feedback about IAOC nomine= es that should have been pointed at IESG nominees, but no one has told me t= hat, so forget I said it)

Second, and more importa= nt than it should be, the reason the past Nomcom didn't ask for a liais= on from IAOC was because it's not part of=C2=A0https://tools.ietf.org/html/rfc7437, and the pa= st chair/advisor didn't think of it, because he had not reviewed an IAO= C position and hadn't asked for a liaison when he was chair. So, if a N= omcom doesn't have an IAOC advisor because they're not reviewing an= IAOC position, our running code is that it's easy to forget to ask for= one when a Nomcom does review an IAOC position ;-)

Let me chew on how I can say that Nomcoms really need that input, but wha= t I'm concerned about is that a Nominating Committee is defined as=C2= =A0

=C2=A0 =C2=A0The nominating committee com= prises at least a Chair, 10 voting
=C2=A0 =C2=A0volunteers, two l= iaisons, and an advisor.

and if I state havi= ng an IAOC advisor is a (new) requirement, a Nominating Committee that does= n't have one would be vulnerable to an appeal to the ISOC board, becaus= e the structure doesn't match what's in the BCP - and because we= 9;re talking about IASA 2.0, sending a representative for IAOC may not even= make sense, but the BCP text wouldn't go away by itself (BCP text that= could go away by itself was the point of=C2=A0https://tools.ietf.org/html/rfc3933, but whatever).=

I may be excessively sensitive about making this = prescriptive, because we had to write a new BCP to make a one-word change i= n a couple of BCPs, so I'm happy to listen to reason.

Spencer, (in this case) as author of https://tools.ietf.org/html/rfc7475, which was less s= imple than you might hope ...



<= /div>
I am fine with the d= escription of "helper" being vague-ish to
allow for iasa2 etc.

Cheers,
S.

>
> Are people comfortable with this being more permissive than prescripti= ve?
>
> Thanks,
>
> Spencer
>
>
>> - I'm fine if a recent but not current IAOC member is
>>=C2=A0 =C2=A0the stuckee, where recent is say <=3D 2 years since=
>>=C2=A0 =C2=A0being an IAOC appointee. Weasel wording around that >>=C2=A0 =C2=A0goal is fine so long as the intent is clear.
>> - If the stuckee is not a current IAOC member, then I
>>=C2=A0 =C2=A0think there needs to be some form of appeal of the
>>=C2=A0 =C2=A0appointment possible, even if that's via some hard=
>>=C2=A0 =C2=A0to exercise mechanism.
>>
>> S.
>>
>>
>


--089e08222cb4dd090105578620a9-- From nobody Thu Aug 24 14:49:05 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 07E051323B5 for ; Thu, 24 Aug 2017 14:49:03 -0700 (PDT) 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 F7HuC2NvDUrZ for ; Thu, 24 Aug 2017 14:49:00 -0700 (PDT) Received: from bsa2.jck.com (ns.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 C7577126BFD for ; Thu, 24 Aug 2017 14:49:00 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dkzzm-000F5E-Ni; Thu, 24 Aug 2017 17:48:58 -0400 Date: Thu, 24 Aug 2017 17:48:52 -0400 From: John C Klensin To: Spencer Dawkins at IETF , Stephen Farrell cc: NomCom-Discussion Message-ID: <84754C020045513D2990D80F@PSB> In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@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 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: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 21:49:03 -0000 --On Thursday, August 24, 2017 16:01 -0500 Spencer Dawkins at IETF wrote: > Second, and more important than it should be, the reason the > past Nomcom didn't ask for a liaison from IAOC was because > it's not part of https://tools.ietf.org/html/rfc7437, and the > past chair/advisor didn't think of it, because he had not > reviewed an IAOC position and hadn't asked for a liaison when > he was chair. So, if a Nomcom doesn't have an IAOC advisor > because they're not reviewing an IAOC position, our running > code is that it's easy to forget to ask for one when a Nomcom > does review an IAOC position ;-) > > Let me chew on how I can say that Nomcoms really need that > input, but what I'm concerned about is that a Nominating > Committee is defined as > > The nominating committee comprises at least a Chair, 10 > voting volunteers, two liaisons, and an advisor. > > and if I state having an IAOC advisor is a (new) requirement, > a Nominating Committee that doesn't have one would be > vulnerable to an appeal to the ISOC board, because the > structure doesn't match what's in the BCP - and because we're > talking about IASA 2.0, sending a representative for IAOC may > not even make sense, but the BCP text wouldn't go away by > itself (BCP text that could go away by itself was the point of > https://tools.ietf.org/html/rfc3933, but whatever). > > I may be excessively sensitive about making this prescriptive, > because we had to write a new BCP to make a one-word change in > a couple of BCPs, so I'm happy to listen to reason. > > Spencer, (in this case) as author of > https://tools.ietf.org/html/rfc7475, which was less simple > than you might hope ... >... Spencer, noting the concerns I expressed in my earlier note, consider saying, instead of, "there will be an IAOC Liaison" (or helper, observer, hanger-on) something like "before starting its work to filter and select candidates, the Nomcom will consider which bodies from which to seek advice or representation with that consideration including, but not necessarily limited to, all bodies to which Nomcoms are charged with appointing members whether members are being appointed in that year or not". That consideration process will include the precise role of any individuals included in the Nomcom's work with regard to whether they simply provide information when asked or participate in some or all Nomcom discussions or deliberations." I'm sure you can write better sentences, but an approach like that reminds the Nomcom that the IAOC is relevant, that, if the Nomcom should in the future start appointing people to other bodies internal or external to the IETF, we don't have to redo this. And I think it is IASA 2.0 proof -- it that process abolishes the IAOC and creates three bodies named Tom, Dick, and Harry, the document still works and the Nomcom gets to figure out who is relevant. john From nobody Thu Aug 24 14:54:40 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 97B4413235C for ; Thu, 24 Aug 2017 14:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 jycdP2aOL_qt for ; Thu, 24 Aug 2017 14:54:37 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 C565A1321E6 for ; Thu, 24 Aug 2017 14:54:36 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id s143so4426514ywg.0 for ; Thu, 24 Aug 2017 14:54:36 -0700 (PDT) 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=2TGomfH7p9AR9VcXAjDH7kAahI0CfKFkbxFbJb4G70E=; b=tEgvKuKDPat99ziiP3mGPu2GLL5LvS62FoQCGNPYQK2hk89XWzrjR/Uy8Qmkr8CFvw UevHw+zmL6gYCZTg22vSynAFg/FMPzsKhn5HxUUTlG2hlsq1BRbdosWHn5+AA87QAWbb F09fOS/kV0HsmrhgqS2yExteRHPzCqZ4q3zJv8sqFN5TQL6+zbaScR9CbEn4AZQBNhlU LGdfyRc+zhRBGXMWAGI0gQ15n2XfxkTKe0jRUX7a2bKJpYcvj/M8L7Em00DggLWqr24X Ajt3aY3H0ltWLhHseVxWxGJ4NycrF2Tum4MEv2spxci3b9Yht2VfeGU42oj/NhrWL8Wa 0OiA== 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=2TGomfH7p9AR9VcXAjDH7kAahI0CfKFkbxFbJb4G70E=; b=SOxzKpHQIBcUM+lmsOtflMm3ZgpStMiINnNUVtwARk3JpViH9I2rYVuDzabg6Dz1H2 yLUWcU4gnclb0rQcbqX5SF/VNucA56+xDLk6ALXAyVw0OIFSC9HH+iKcfow8C0YjgbqC Llb4hmOCORD6UmIKZP+U29kDfbECzFpfUqsDyBkbzwZnGigUfwy1pXPY8azKfOnI7If2 U2zagwwVvfyndWyyAPdrLPaZ7m3luhBKbdVbpwzEJK7Pm8d8x7MKm/CqHQhdvspbUp2n hqmiy9xBIob5EH6Z65gBkvVslZ2foOsON6QBq5czBu0ymcvqn2kk06nMTrblhiN24E9J eJUw== X-Gm-Message-State: AHYfb5jVhYMwjqiDycvCTC6t2Pcsr0rqIL1O4rMxlovx7dEAbWVEU56C LRsMpXdafSbOsu7bizGhSLq2xNgarQ== X-Received: by 10.129.229.4 with SMTP id s4mr6052486ywl.130.1503611675846; Thu, 24 Aug 2017 14:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 14:54:34 -0700 (PDT) In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 16:54:34 -0500 Message-ID: To: John C Klensin Cc: NomCom-Discussion , Alexey Melnikov Content-Type: multipart/alternative; boundary="089e08222cb4d1ad29055786dfa8" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 21:54:40 -0000 --089e08222cb4d1ad29055786dfa8 Content-Type: text/plain; charset="UTF-8" Hi, John, and CC Alexey, who is shepherding this draft, On Thu, Aug 24, 2017 at 9:58 AM, John C Klensin wrote: > > > --On Tuesday, August 22, 2017 22:11 -0500 Spencer Dawkins at > IETF wrote: > > > On your other points, I think I know what to do with your > > feedback, but this one is worth talking about some more. > > > > There are different levels of "Nomcoms needing someone who > > speaks IAOC-ese fairly fluently". > > > > I'm shooting for "don't forget to think about how you'll know > > whether you've got a viable IAOC candidate to forward to the > > confirming body, and if you don't know who can help, the IAOC > > should be well-placed to make suggestions about people > > who can help". > > > > I could be shooting for "the Nomcom has to ask for help", or > > even "has to ask the IAOC for help". > > > > At the extreme, I could be shooting for "change the definition > > of committee membership so that if you don't have > > representation from the IAOC, you've got a really big > > problem", to match not having a liaison from the IAB or IESG. > > > > Are people comfortable with this being more permissive than > > prescriptive? > > Spencer, > > I'm almost always comfortable with more permissive or, more > specifically, with guidelines and principles rather than rules. > That is in part because I think the IETF has a terrible track > record when we try to make specific rules, almost always > discovering either that they are not quite right and require > either workarounds or more effort to try to fix or because they > lead to quibbling about the rules rather than getting useful > work done. > > However, as I've tried to say before, I'm worried about a > different problem in this case, which is whether, as the > individual knowledge of Nomcom members goes down, the presence > of all of those liaisons could have undue influence by any of: > > (i) influencing the Nomcom for or against particular candidates. > > (ii) influencing the Nomcom too much about the role of the > relevant bodies or job descriptions. That is especially > hazardous because part of the original intent of the Nomcom was > that it be able to make decisions that particular bodies were > going in the wrong direction and then make appointments with the > express intention of changing that. > > (iii) Having a chilling effect on community members who wanted > to make comments (favorable or unfavorable) about particular > candidates that they wouldn't want generally known, or known to > the candidates or their supporters or opponents... especially > when the liaison was believed to have a strong (again, whether > positive or negative) relationship with that candidate. > > These are obviously far more general issues than how to add an > IAOC liaison or how, but I believe that specifying an additional > liaison, especially from a body with the composition and role of > the IAOC, could considerable amplify any issues or concerns of > that type. > I have seen your e-mail about that, and I think I understand this issue pretty well. I agree that how the Nomcom reviews positions and nominees has changed pretty massively since 1992. The problem with problems with Nomcom is, it's really hard to know what problems have been encountered over the years, unless one or more Nomcom chairs reveals a problem that they encountered. Some do that, pretty publicly, but even in those cases, people outside the Nomcom don't have the details that would be helpful in solving problems. I might reasonably point out that there's been an "IAOC liaison" on every Nomcom from 2009-2010 to 2014-2015, but maybe we've just been lucky - I just don't know. So, here's what I'm thinking. Tl;dr Alissa (as Gen-AD) is out on leave until October (although she did surface for an informal telechat earlier today). I'm not comfortable proposing more than minor changes, until she can participate in that discussion. When she returns, I'll tell her what I'm hearing (and that I can't dismiss that concern out of hand). That's on my calendar as a reminder. The long part ... The last time we made a Nomcom process change that was more than a paragraph long, what Russ did, was convene about ten years worth of Nomcom past chairs to exchange, maintaining as much confidentiality as they could (so, no names), descriptions of problems they'd encountered. Common problems went into https://tools.ietf.org/html/draft-dawkins-nomcom-3777-issues-00, and that formed the basis of most of the BCP changes I authored (most notoriously, https://datatracker.ietf.org/doc/rfc5680/). That's why we had some confidence that we were talking about real problems. ISTM like it's worth doing something like that, every decade or so, which is how long it's been since I was working on that draft. Maybe all the problems that were identified then have gone away without BCP changes, or maybe more recent Nomcom chairs have encountered different problems that are worth thinking about, but (inserting by reference every conversation you and I have ever had about how hard it is to get BCPs right the first time), if we've already had problems that recur often enough to justify BCP updates, I'd like to understand them. Thanks, Spencer > best, > john > > > > --089e08222cb4d1ad29055786dfa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, John, and CC Alexey, who is shepherding this draft,
On Thu, Aug 24, 2017= at 9:58 AM, John C Klensin <john-ietf@jck.com> wrote:


--On Tuesday, August 22, 2017 22:11 -0500 Spencer Dawkins at
IETF <spencerdawkins.ietf@gmail.com> wrote:

> On your other points, I think I know what to do with your
> feedback, but this one is worth talking about some more.
>
> There are different levels of "Nomcoms needing someone who
> speaks IAOC-ese fairly fluently".
>
> I'm shooting for "don't forget to think about how you'= ;ll know
> whether you've got a viable IAOC candidate to forward to the
> confirming body, and if you don't know who can help, the IAOC
> should be well-placed to make suggestions about people
> who can help".
>
> I could be shooting for "the Nomcom has to ask for help", or=
> even "has to ask the IAOC for help".
>
> At the extreme, I could be shooting for "change the definition > of committee membership so that if you don't have
> representation from the IAOC, you've got a really big
> problem", to match not having a liaison from the IAB or IESG.
>
> Are people comfortable with this being more permissive than
> prescriptive?

Spencer,

I'm almost always comfortable with more permissive or, more
specifically, with guidelines and principles rather than rules.
That is in part because I think the IETF has a terrible track
record when we try to make specific rules, almost always
discovering either that they are not quite right and require
either workarounds or more effort to try to fix or because they
lead to quibbling about the rules rather than getting useful
work done.

However, as I've tried to say before, I'm worried about a
different problem in this case, which is whether, as the
individual knowledge of Nomcom members goes down, the presence
of all of those liaisons could have undue influence by any of:

(i) influencing the Nomcom for or against particular candidates.

(ii) influencing the Nomcom too much about the role of the
relevant bodies or job descriptions.=C2=A0 That is especially
hazardous because part of the original intent of the Nomcom was
that it be able to make decisions that particular bodies were
going in the wrong direction and then make appointments with the
express intention of changing that.

(iii)=C2=A0 Having a chilling effect on community members who wanted
to make comments (favorable or unfavorable) about particular
candidates that they wouldn't want generally known, or known to
the candidates or their supporters or opponents... especially
when the liaison was believed to have a strong (again, whether
positive or negative) relationship with that candidate.

These are obviously far more general issues than how to add an
IAOC liaison or how, but I believe that specifying an additional
liaison, especially from a body with the composition and role of
the IAOC, could considerable amplify any issues or concerns of
that type.

I have seen your e-mail abou= t that, and I think I understand this issue pretty well.=C2=A0
I agree that how the Nomcom reviews positions and nominees has= changed pretty massively since 1992.=C2=A0

The pr= oblem with problems with Nomcom is, it's really hard to know what probl= ems have been encountered over the years, unless one or more Nomcom chairs = reveals a problem that they encountered.=C2=A0

Som= e do that, pretty publicly, but even in those cases, people outside the Nom= com don't have the details that would be helpful in solving problems.= =C2=A0

I might reasonably point out that there'= ;s been an "IAOC liaison" on every Nomcom from 2009-2010 to 2014-= 2015, but maybe we've just been lucky - I just don't know.

So, here's what I'm thinking.

Tl;dr

Alissa (as Gen-AD) is out on leave = until October (although she did surface for an informal telechat earlier to= day).=C2=A0

I'm not comfortable proposing more= than minor changes, until she can participate in that discussion.=C2=A0

When she returns, I'll tell her what I'm hea= ring (and that I can't dismiss that concern out of hand). That's on= my calendar as a reminder.

The long part ...

The last time we made a Nomcom process change that was= more than a paragraph long, what Russ did, was convene about ten years wor= th of Nomcom past chairs to exchange, maintaining as much confidentiality a= s they could (so, no names), descriptions of problems they'd encountere= d. Common problems went into=C2=A0https://tools.ietf.org/html/draft-dawkin= s-nomcom-3777-issues-00, and that formed the basis of most of the BCP c= hanges I authored (most notoriously,=C2=A0https://datatracker.ietf.org/doc/rfc5680/). That&#= 39;s why we had some confidence that we were talking about real problems.

ISTM like it's worth doing something like t= hat, every decade or so, which is how long it's been since I was workin= g on that draft.

Maybe all the problems that were = identified then have gone away without BCP changes, or maybe more recent No= mcom chairs have encountered different problems that are worth thinking abo= ut, but (inserting by reference every conversation you and I have ever had = about how hard it is to get BCPs right the first time), if we've alread= y had problems that recur often enough to justify BCP updates, I'd like= to understand them.

Thanks,

<= div>Spencer
=C2=A0
best,
=C2=A0 =C2=A0 =C2=A0john




--089e08222cb4d1ad29055786dfa8-- From nobody Thu Aug 24 16:05:41 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 5A1B91329B2 for ; Thu, 24 Aug 2017 16:05:39 -0700 (PDT) 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 U8tqU6M4lNLe for ; Thu, 24 Aug 2017 16:05:37 -0700 (PDT) Received: from bsa2.jck.com (ns.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 91E911329C2 for ; Thu, 24 Aug 2017 16:05:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dl1Bu-000FMZ-Fy; Thu, 24 Aug 2017 19:05:34 -0400 Date: Thu, 24 Aug 2017 19:05:28 -0400 From: John C Klensin To: Spencer Dawkins at IETF cc: NomCom-Discussion , Alexey Melnikov Message-ID: <8D0453C3C2E54A22171A86E7@PSB> In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@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 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: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Thu, 24 Aug 2017 23:05:39 -0000 Spencer, --On Thursday, August 24, 2017 16:54 -0500 Spencer Dawkins at IETF wrote: > Hi, John, and CC Alexey, who is shepherding this draft, >... >> However, as I've tried to say before, I'm worried about a >> different problem in this case, which is whether, as the >> individual knowledge of Nomcom members goes down, the presence >> of all of those liaisons could have undue influence by any of: >... > I have seen your e-mail about that, and I think I understand > this issue pretty well. > > I agree that how the Nomcom reviews positions and nominees has > changed pretty massively since 1992. > > The problem with problems with Nomcom is, it's really hard to > know what problems have been encountered over the years, > unless one or more Nomcom chairs reveals a problem that they > encountered. > > Some do that, pretty publicly, but even in those cases, people > outside the Nomcom don't have the details that would be > helpful in solving problems. > > I might reasonably point out that there's been an "IAOC > liaison" on every Nomcom from 2009-2010 to 2014-2015, but > maybe we've just been lucky - I just don't know. > > So, here's what I'm thinking. > > Tl;dr > > Alissa (as Gen-AD) is out on leave until October (although she > did surface for an informal telechat earlier today). > > I'm not comfortable proposing more than minor changes, until > she can participate in that discussion. > > When she returns, I'll tell her what I'm hearing (and that I > can't dismiss that concern out of hand). That's on my calendar > as a reminder. Seems completely sensible. > The long part ... > > The last time we made a Nomcom process change that was more > than a paragraph long, what Russ did, was convene about ten > years worth of Nomcom past chairs to exchange, maintaining as > much confidentiality as they could (so, no names), > descriptions of problems they'd encountered. Common problems > went into > https://tools.ietf.org/html/draft-dawkins-nomcom-3777-issues-0 > 0, and that formed the basis of most of the BCP changes I > authored (most notoriously, > https://datatracker.ietf.org/doc/rfc5680/). That's why we had > some confidence that we were talking about real problems. >... > Maybe all the problems that were identified then have gone > away without BCP changes, or maybe more recent Nomcom chairs > have encountered different problems that are worth thinking > about, but (inserting by reference every conversation you and > I have ever had about how hard it is to get BCPs right the > first time), if we've already had problems that recur often > enough to justify BCP updates, I'd like to understand them. Yes. But I think there is a source of data that might be hard to capture and invisible to Nomcom chairs. That doesn't mean it isn't there or isn't valid. I've heard, several times, from IETF participants (just participants with no leadership responsibilities, although my list includes a few WG chairs), in conversations that typically occur after Nomcom appointments are announced. The conversations went something like the following: > How could they possibly reappoint X, he is terrible, mistreated the WG, and systematically ignored everyone who disagreed with him. < Did you discuss those issues and examples with the Nomcom. > No, I hoped someone else would do so. < Why not? If you don't raise the issues, how can you expect others to do so? > Y was the liaison (or even X's co-AD), I think they are buddies, and ADs protect each other anyway, so I'm afraid of retaliation... from X if X is reappointed and from Y and maybe the rest of the IESG is X is not. I have no confidence in Y's ability to keep my comments, or the fact that I made them, away from X or other IESG members. < I've heard similar things four or five times. Not a huge number, but enough to cause me to believe that there is a problem and that others may be hearing the same things. I've heard similar things before Nomcoms have made their selections but then I just suggest private conversations with Nomcom chairs... something that would be visible to those chairs if they occurred (and I have no way to know whether they did or not). john From nobody Thu Aug 24 17:31:22 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 4CAEF1329CD for ; Thu, 24 Aug 2017 17:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=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 g4mEHalWRbKB for ; Thu, 24 Aug 2017 17:31:17 -0700 (PDT) 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 2961B132377 for ; Thu, 24 Aug 2017 17:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E0980BE55; Fri, 25 Aug 2017 01:31:14 +0100 (IST) 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 Fzz_G-_bH-L2; Fri, 25 Aug 2017 01:31:13 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5B6CBE53; Fri, 25 Aug 2017 01:31:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1503621073; bh=oNy9g62ATefwMCKg6VJPW522FKvYCM1FQmw4gTVoP04=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EQV8LrXMTaJxvnmtL2t+kvmZTFLvQgNB9AqEoS4knYhPT/Qm6AonhpxBPWoq/73bA pDR+x5m6RlC6ecE5GiDzweiFeQ13CByfQgkm+7Z1QSiUMrGXcwT6vePFVoNf20bFNV hqH911lu2EyyyF6b185YI2ZGihulKDqMDMu31U7U= To: Spencer Dawkins at IETF Cc: NomCom-Discussion References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 25 Aug 2017 01:31:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L4C0bpT5jg512O6HiUX1If76b3Ie09M4L" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Fri, 25 Aug 2017 00:31:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L4C0bpT5jg512O6HiUX1If76b3Ie09M4L Content-Type: multipart/mixed; boundary="mQfxBe6wxWEoFxv4ELkTeDWsigJ4Tgjaw"; protected-headers="v1" From: Stephen Farrell To: Spencer Dawkins at IETF Cc: NomCom-Discussion Message-ID: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> In-Reply-To: --mQfxBe6wxWEoFxv4ELkTeDWsigJ4Tgjaw Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 24/08/17 22:01, Spencer Dawkins at IETF wrote: > Hi, Stephen, >=20 > On Thu, Aug 24, 2017 at 11:17 AM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 23/08/17 04:11, Spencer Dawkins at IETF wrote: >>> Hi, Stephen, >>> >>> On Wed, Aug 9, 2017 at 8:53 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>> >>>> >>>> Hiya, >>>> >>>> FWIW, my take: >>>> >>>> - I don't care if we use the term liaison or advisor >>>> - I do think the IAOC has to pick the person >>>> - I do think every nomcom needs such a person helping >>>> out >>>> >>> >>> Sorry for my delay in responding. >> >> Ditto:-) >> >>> >>> On your other points, I think I know what to do with your feedback, b= ut >>> this one is worth talking about some more. >>> >>> There are different levels of "Nomcoms needing someone who speaks >> IAOC-ese >>> fairly fluently". >>> >>> I'm shooting for "don't forget to think about how you'll know whether= >>> you've got a viable IAOC candidate to forward to the confirming body,= and >>> if you don't know who can help, the IAOC should be well-placed to mak= e >>> suggestions about people >>> who can help". >>> >>> I could be shooting for "the Nomcom has to ask for help", or even "ha= s to >>> ask the IAOC for help". >>> >>> At the extreme, I could be shooting for "change the definition of >> committee >>> membership so that if you don't have representation from the IAOC, yo= u've >>> got a really big problem", to match not having a liaison from the IAB= or >>> IESG. >> >> It's not a hill on which I'd die, but I don't think it extreme >> to expect every nomcom to have an IAOC-helper, even for years >> when there is no IAOC appointment for nomcom to make. So I think >> your last target above is the better one. >> >=20 > I agree with your starting point, for a couple of reasons. >=20 > First, in private conversations, I am told that some Nomcoms get feedba= ck > about AD nominees that is actually more appropriate for IAOC nominees, > because the community isn't quite sure where the dividing line between = the > two bodies is. I don't know more details, because that feedback is > Nomcom-confidential, and I wasn't on the Nomcom(s) where that happened,= > but, yes, having someone who can say "but that's our job" in the room s= eems > helpful, whether that particular Nomcom is reviewing an IAOC position o= r > not. I think a whole bunch of IETF plenaries provide evidence that the community do get at least IESG/IAOC responsibilities mixed up, (as they ought - given that loads of I* stuff is just administrivia:-) but all such comments ought be properly weighed in all cases by the sitting nomcoms. (I mean "properly" in the sense that whatever sane community comment is offered is valid commentary by definition and hence deserves knowledgeable consideration, which requires help from folks who're up to date on the relevant body's stuff.) > (I wouldn't be surprised to hear that Nomcoms have also gotten feedback= > about IAOC nominees that should have been pointed at IESG nominees, but= no > one has told me that, so forget I said it) >=20 > Second, and more important than it should be, the reason the past Nomco= m > didn't ask for a liaison from IAOC was because it's not part of > https://tools.ietf.org/html/rfc7437, and the past chair/advisor didn't > think of it, because he had not reviewed an IAOC position and hadn't as= ked > for a liaison when he was chair. So, if a Nomcom doesn't have an IAOC > advisor because they're not reviewing an IAOC position, our running cod= e is > that it's easy to forget to ask for one when a Nomcom does review an IA= OC > position ;-) >=20 > Let me chew on how I can say that Nomcoms really need that input, but w= hat > I'm concerned about is that a Nominating Committee is defined as >=20 > The nominating committee comprises at least a Chair, 10 voting > volunteers, two liaisons, and an advisor. >=20 > and if I state having an IAOC advisor is a (new) requirement, a Nominat= ing > Committee that doesn't have one would be vulnerable to an appeal to the= > ISOC board, because the structure doesn't match what's in the BCP -=20 I don't get why that's a problem. If this draft updates the BCP, then it becomes part of the BCP. For a minor update like this, I don't see a big deal here. > and > because we're talking about IASA 2.0, sending a representative for IAOC= may > not even make sense, but the BCP text wouldn't go away by itself (BCP t= ext > that could go away by itself was the point of > https://tools.ietf.org/html/rfc3933, but whatever). >=20 > I may be excessively sensitive about making this prescriptive, because = we > had to write a new BCP to make a one-word change in a couple of BCPs, s= o > I'm happy to listen to reason. John's suggestion to say that helpers are needed for all the major bodies to which nomcoms appoint members seems like it should be fine when well wordsmithed. Cheers, S. PS: I don't think this is mega-urgent, so fixing it for the next cycle or the one after are both fine. >=20 > Spencer, (in this case) as author of https://tools.ietf.org/html/rfc747= 5, > which was less simple than you might hope ... >=20 >=20 >=20 > I am fine with the description of "helper" being vague-ish to >> allow for iasa2 etc. >> >> Cheers, >> S. >> >>> >>> Are people comfortable with this being more permissive than prescript= ive? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>>> - I'm fine if a recent but not current IAOC member is >>>> the stuckee, where recent is say <=3D 2 years since >>>> being an IAOC appointee. Weasel wording around that >>>> goal is fine so long as the intent is clear. >>>> - If the stuckee is not a current IAOC member, then I >>>> think there needs to be some form of appeal of the >>>> appointment possible, even if that's via some hard >>>> to exercise mechanism. >>>> >>>> S. >>>> >>>> >>> >> >> >=20 --mQfxBe6wxWEoFxv4ELkTeDWsigJ4Tgjaw-- --L4C0bpT5jg512O6HiUX1If76b3Ie09M4L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZn2/QAAoJEC88hzaAX42iKAIH/RsQ9YnV91DC+tTS4yyNNAL5 vEcsvD6k7a9BTKdeGjXjzXbHOwwSaZPrlhaRj7RzzgKrNNxo6SnIkJLzfSGLQ8Ep yjSxGrmnHgLAdbDSQ8q2b7OwTq0bbouKjDPAz4mh4X75QxYBxUsR7i1lyAAZTWFq P+nP2d8clrD39vW40OuaOk6+D+zhreWkWer2SJGnNnFvAw4uGlSIsoEbMEOtSyhy eV8v5V6UVruFMFTbLmTp1chZiEvRQvSwkTfdGJCNw7yVEoMrvWrqvNP9/AV3uE36 RsATnN5sJK5G7kugrzw14YwQZGXbee9V9GkULQ5k6wptra+U8HPf7tnrM7B1bGQ= =twNW -----END PGP SIGNATURE----- --L4C0bpT5jg512O6HiUX1If76b3Ie09M4L-- From nobody Thu Aug 24 18:03:00 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 2E0B71329D5 for ; Thu, 24 Aug 2017 18:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y36hzNWEE-Rp for ; Thu, 24 Aug 2017 18:02:58 -0700 (PDT) Received: from bsa2.jck.com (ns.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 4FB45132377 for ; Thu, 24 Aug 2017 18:02:58 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dl31S-000FVS-HO; Thu, 24 Aug 2017 21:02:54 -0400 Date: Thu, 24 Aug 2017 21:02:48 -0400 From: John C Klensin To: Stephen Farrell , Spencer Dawkins at IETF cc: NomCom-Discussion Message-ID: <51834349A25B99F85321F96C@PSB> In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@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 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: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Fri, 25 Aug 2017 01:03:00 -0000 --On Friday, August 25, 2017 01:31 +0100 Stephen Farrell wrote: >... > John's suggestion to say that helpers are needed for all the > major bodies to which nomcoms appoint members seems like it > should be fine when well wordsmithed. Just for the record, my suggestion wasn't "are needed" but that the Nomcom should consider each one and decide what, if anything, was needed and how any advisors/helpers who are needed should interact with the Nomcom. Put differently, I'm in favor of reminding Nomcoms about cases they should consider (thereby covering the "no one thought of it" cases) but much less in favor of telling them what they should conclude or what they should do about it. john From nobody Thu Aug 24 21:02:52 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 26133132197 for ; Thu, 24 Aug 2017 21:02:51 -0700 (PDT) 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 kzQetyXGK2D8 for ; Thu, 24 Aug 2017 21:02:49 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 18E7A12008A for ; Thu, 24 Aug 2017 21:02:49 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h127so7374161ywf.3 for ; Thu, 24 Aug 2017 21:02:49 -0700 (PDT) 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=fubMEw0Q5nrB/D8LgrdObOiBeBDnOhBm7r0Wuv4cjrA=; b=Clyg2lw1H9MrDdMnZjruOpV+Gkh1m9T794ABxOH7QsNsTJJ0zQXPeV5N1nJVoyVg1n +k0q5OPQXs2WrjDAkeuxq4VIt6Vgzf2RXkukgjAbdPX0SSyJdpy2tiZHMjk0jznTPKYM 8CWVLh3O0bKG/WxnieWylnE/F9xh9bU67HNha5CeSx4JaylFxys6VGP7twqBECbNVVrn 4FIZXkR4lq+2fu/7El0KaoQkncpXX+1arfUcGDHh+U2bU3diUbQloe4fb5kztOIsamZb X6BhBLIjVQDcoJ5AqhgKIjU4nHCgUIJ3uA+8jZXd79v2C+7c6vu+xEAR4a8SI0va2aL0 0SWg== 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=fubMEw0Q5nrB/D8LgrdObOiBeBDnOhBm7r0Wuv4cjrA=; b=jaihjbz0SamoWVIKt1V/JhkBW2AyGlRM04crXQ3Ta8dnDSnZxvR6LapVNEy3CaUMWf VtabXRRPl23HRAFjGc/ILPRJ/kjVJTLSZXoUhA1CMS++9wZPfie++U4S3nSvPvldenl9 +UHALrzV28rHKq/X2YKZf+KGXc7LqfC7OBqQq9M1YUxZQGtA3TjQKF6qWT4EpctaYjCH Ehxu6IGokQ9+mY6qfAXVacmR889T/ZrvUGixSkNiklfVK5Vf8C2PAxJiderExqHH+pnf 1nJ1EQAap4h3L+yTX99qpsg0NpjgNqUvPyju6N94UMvtFCgT+soitFr1+9lz6p8g1Lzj nyCw== X-Gm-Message-State: AHYfb5gxBdvxJuCUMxU3YUGlrPsDC8RVCzMggiV7Bver2eqeQVYzWjNn RmgrRO3Gxi1whaDNZmltF6k1kzVHGw== X-Received: by 10.37.183.196 with SMTP id u4mr7238136ybj.39.1503633768070; Thu, 24 Aug 2017 21:02:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 24 Aug 2017 21:02:47 -0700 (PDT) In-Reply-To: References: <4622.1502292425@obiwan.sandelman.ca> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <5f26388a-93aa-7133-6973-de669a9bb2f4@gmail.com> <6e62d88a-ba0e-18eb-3a45-88851b6e7c46@joelhalpern.com> <0c83a20d-325b-d928-a157-638fcaf81adf@cs.tcd.ie> <2e2ecf8a-e843-795b-f96b-b183e2b3a84c@cs.tcd.ie> From: Spencer Dawkins at IETF Date: Thu, 24 Aug 2017 23:02:47 -0500 Message-ID: To: Stephen Farrell Cc: NomCom-Discussion Content-Type: multipart/alternative; boundary="089e08225bec9e43c305578c04d8" Archived-At: Subject: Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee 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: Fri, 25 Aug 2017 04:02:51 -0000 --089e08225bec9e43c305578c04d8 Content-Type: text/plain; charset="UTF-8" Hi, Stephen, On Thu, Aug 24, 2017 at 7:31 PM, Stephen Farrell wrote: > > Hiya, > > On 24/08/17 22:01, Spencer Dawkins at IETF wrote: > deleted down to ... > > > > Let me chew on how I can say that Nomcoms really need that input, but > what > > I'm concerned about is that a Nominating Committee is defined as > > > > The nominating committee comprises at least a Chair, 10 voting > > volunteers, two liaisons, and an advisor. > > > > and if I state having an IAOC advisor is a (new) requirement, a > Nominating > > Committee that doesn't have one would be vulnerable to an appeal to the > > ISOC board, because the structure doesn't match what's in the BCP - > > I don't get why that's a problem. If this draft updates the BCP, then > it becomes part of the BCP. For a minor update like this, I don't see > a big deal here. And Alissa thought I could write coherent text. Based on what, I wonder? What I was trying to describe was Current BCP structure: > The nominating committee comprises at least a Chair, 10 voting > volunteers, two liaisons, and an advisor. Updated BCP structure: > The nominating committee comprises at least a Chair, 10 voting > volunteers, two liaisons, and an advisor, plus whatever the heck we call the person bearing IAOC clue. So, that would make having an IAOC clue-bearer mandatory (which I have some sympathy with, please see deleted text where I gave two reasons why I previously agreed with you about this being desirable), and if a Nomcom didn't have an IAOC clue-bearer, the Nomcom doesn't match the updated BCP structure. So, maybe that doesn't actually matter, but the DOS attack is someone who doesn't like the results of that Nomcom for at least one of the 15 or so confirmed candidates, and appeals the entire outcome of that Nomcom to the ISOC Board because the Nomcom wasn't properly constituted. Maybe that will never happen, but if it did, we would be in for a wild ride for 6-8 weeks while we tried to figure out who was actually going to be on the IAB, IESG, and IAOC as people's terms end for the reviewed positions during the first IETF meeting week of the year, with no confirmed candidates to replace them. Maybe we really do have a Plan B, but I have no idea what it would be (noting that we had no quick solution when Wes Eddy's term expired and there was no confirmed candidate to replace him in 2013, a situation you and I have some familiarity with). John's formulation is interesting, but I don't see it as a small change. Maybe in another draft, or maybe as part of the conversation I've committed to have with Alissa upon her return, but I'd expect discussion. Updating BCPs without planting land mines is hard. Enjoy your day :-) Spencer --089e08225bec9e43c305578c04d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Stephen,

On Thu, Aug 24, 2017 at 7:31 PM, Stephen Farrell <step= hen.farrell@cs.tcd.ie> wrote:

Hiya,

On 24/08/17 22:01, Spencer Dawkins at IETF wrote:

deleted down to ...
=C2=A0
>
> Let me chew on how I can say that Nomcoms really need that input, but = what
> I'm concerned about is that a Nominating Committee is defined as >
>=C2=A0 =C2=A0 The nominating committee comprises at least a Chair, 10 v= oting
>=C2=A0 =C2=A0 volunteers, two liaisons, and an advisor.
>
> and if I state having an IAOC advisor is a (new) requirement, a Nomina= ting
> Committee that doesn't have one would be vulnerable to an appeal t= o the
> ISOC board, because the structure doesn't match what's in the = BCP -

I don't get why that's a problem. If this draft updates the = BCP, then
it becomes part of the BCP. For a minor update like this, I don't see a big deal here.

And Alissa thought I could= write coherent text. Based on what, I wonder?

Wha= t I was trying to describe was =C2=A0

Current BCP = structure:

>=C2=A0 =C2=A0 The nominating commit= tee comprises at least a Chair, 10 voting
>=C2=A0 =C2=A0 volunteers, = two liaisons, and an advisor.

Updated BCP str= ucture:

>=C2=A0 =C2=A0 The nominating committee= comprises at least a Chair, 10 voting
>=C2=A0 =C2=A0 volunteers, two= liaisons, and an advisor, plus whatever the heck
=C2=A0 =C2=A0 = =C2=A0 we call the person bearing IAOC clue.

So, t= hat would make having an IAOC clue-bearer mandatory (which I have some symp= athy with, please see deleted text where I gave two reasons why I previousl= y agreed with you about this being desirable), and if a Nomcom didn't h= ave an IAOC clue-bearer, the Nomcom doesn't match the updated BCP struc= ture.

So, maybe that doesn't actually matter, = but the DOS attack is someone who doesn't like the results of that Nomc= om for at least one of the 15 or so confirmed candidates, and appeals the e= ntire outcome of that Nomcom to the ISOC Board because the Nomcom wasn'= t properly constituted.=C2=A0

Maybe that will neve= r happen, but if it did, we would be in for a wild ride for 6-8 weeks while= we tried to figure out who was actually going to be on the IAB, IESG, and = IAOC as people's terms end for the reviewed positions during the first = IETF meeting week of the year, with no confirmed candidates to replace them= . Maybe we really do have a Plan B, but I have no idea what it would be (no= ting that we had no quick solution when Wes Eddy's term expired and the= re was no confirmed candidate to replace him in 2013, a situation you and I= have some familiarity with).

John's formulati= on is interesting, but I don't see it as a small change. Maybe in anoth= er draft, or maybe as part of the conversation I've committed to have w= ith Alissa upon her return, but I'd expect discussion.

Updating BCPs without planting land mines is hard.

Enjoy your day :-)

Spencer
--089e08225bec9e43c305578c04d8--