Re: Updating BCP 10 -- NomCom ELEGIBILITY

Michael Richardson <> Wed, 11 February 2015 16:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE44C1A8957 for <>; Wed, 11 Feb 2015 08:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ryfmc76EJjMI for <>; Wed, 11 Feb 2015 08:23:53 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 0008D1A8862 for <>; Wed, 11 Feb 2015 08:23:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FBFBE00C for <>; Wed, 11 Feb 2015 11:31:18 -0500 (EST)
Received: by (Postfix, from userid 179) id E4E4563A21; Wed, 11 Feb 2015 11:23:51 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id C2F8963A1F for <>; Wed, 11 Feb 2015 11:23:51 -0500 (EST)
From: Michael Richardson <>
To: ietf <>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
In-Reply-To: <>
References: <> <> <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 11 Feb 2015 11:23:51 -0500
Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Feb 2015 16:23:58 -0000

Loa Andersson <> wrote:
    >> Ensure that at least a portion of the Nomcom has contributed in
    >> formal, documented way.  AD, Chair, author.. whatever set of activities
    >> we feel makes it likely they will have clue.

    > I guess I'm old-time minded here, what is wrong with 3 meetings out
    > of 5, and if you want co-authored document.

Have a baby (as a mother or father) and see if you can remain nomcom
eligible.  Try this as a single parent. Or if your partner works a job with
rigid hours (doctor, nurse, RT, lawyer, firefighter, police...).
For many of us in technology, we are the "flexible" parent in the team.
Remember that nomcom eligibility also matters for recall.

(I didn't say that you'd want to volunteer for nomcom in the year that you
gave birth; but consider if weren't eligible in year X, you probably won't be
eligible until year X+2)

Be someone with a limited travel budget, who can only attend meetings in
person when they are "near".  Sometimes it's not the dollars in the budget,
but the travel time that is the problem.
We give this as the reason why the IETF travels to people rather than
repeating Minneapolis/Vancouver all the time.  So someone who finds a happy
medium where they can attend 1 meeting/year in person, and they read mailing
lists, etc.  Assuming that they get over the hurdle of 3/5 to become
eligible, why would we want to throw away all that training?

    >> As for Loa's question about why someone who hasn't done real IETF work
    >> would want to volunteer, the answer is politics and/or ego.  They or
    >> their company might want to hold sway over nomcom or the person might
    >> just want to add this to their resume.

    > With due respect - I don't think this is how it work, do we have any
    > running code? Our rules so far has not stopped anyone form paying and
    > register, sit at the back of a a couple of wg meetings and three IETF
    > meetings later drop his/her name into the hat. But has it happened?

The current system can be gamed if you like, there is no question.

I'm not interested in how we can make the current system harder, or about
this hypothetical Elmer.  If s/he was one of my selecting members, and didn't
come to meetings, then there would be an issue, and the nomcom has ways to
deal with that.

I'm interested in how we can include more people in the nomcom from a more
diverse background.  It's a FIFO problem: if we want diversity at the top,
you have to have diversity at the bottom.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-