Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 09 August 2017 19:32 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 <ietf-nomcom@ietfa.amsl.com>; 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 <ietf-nomcom@ietfa.amsl.com>; 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 <ietf-nomcom@ietf.org>; Wed, 9 Aug 2017 12:32:32 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id s143so46160821ywg.1 for <ietf-nomcom@ietf.org>; 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: <CA+9kkMC4yWGptsTxhQgHQp4mRppMfpXdw_ZLz47Sgyyb=przDQ@mail.gmail.com>
References: <CAKKJt-cd2-tS=3QnvRcsDKcZ8=o5Z98wUr-=tp8OeP9J1M0M8g@mail.gmail.com> <4622.1502292425@obiwan.sandelman.ca> <CAKKJt-fxhFnnK3T2nVj2bD=Ve7z6L0oJFjYFqBb59TusJDwFzQ@mail.gmail.com> <1250df52-b5b3-4f71-bab1-790d156af1e9@nostrum.com> <CA+9kkMC4yWGptsTxhQgHQp4mRppMfpXdw_ZLz47Sgyyb=przDQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 09 Aug 2017 14:32:31 -0500
Message-ID: <CAKKJt-df4-tx6hHCQnGB8wNe21ayYS4+GtAnwFsvdLD1EE_L4w@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Robert Sparks <rjsparks@nostrum.com>, NomCom-Discussion <ietf-nomcom@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f498a2150c2055657248d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/EuFc-SG3c0oxC1aPEbffubRpPR0>
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 <ietf-nomcom.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-nomcom/>
List-Post: <mailto:ietf-nomcom@ietf.org>
List-Help: <mailto:ietf-nomcom-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 19:32:36 -0000

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 <ted.ietf@gmail.com> 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.
>>
>
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 <spencerdawkins.ietf@gmail.com> 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
>>
>>
>>
>