Re: Updating BCP 10 -- round two

Michael Richardson <> Wed, 11 February 2015 19:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BEE651A1B46 for <>; Wed, 11 Feb 2015 11:11:57 -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 mfaR3wDPFora for <>; Wed, 11 Feb 2015 11:11:55 -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 18C6A1A0AFE for <>; Wed, 11 Feb 2015 11:11:55 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 33526203B0; Wed, 11 Feb 2015 14:19:21 -0500 (EST)
Received: by (Postfix, from userid 179) id 412C763A21; Wed, 11 Feb 2015 14:11:54 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 1DD82637F4; Wed, 11 Feb 2015 14:11:54 -0500 (EST)
From: Michael Richardson <>
To: Donald Eastlake <>
Subject: Re: Updating BCP 10 -- round two
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
Date: Wed, 11 Feb 2015 14:11:53 -0500
Message-ID: <>
Archived-At: <>
Cc: ietf <>
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 19:11:58 -0000

Donald Eastlake <> wrote:
    > (3) I see no reason for nomcom eligibility to be sticky. Seems like a

I'm not proposing sticky. Definitely not.
I'm proposing too levels: a high bar to become, and a slightly lower bar to remain.

    > (4) Over the years, there has been a marked increase in the stridency
    > of efforts to get more and more volunteers. I never quite understood
    > this. The claim is almost always made that a bigger pool of volunteers
    > is more "representative" and always better but, in an organization

Let me propose one quantitative way in which a larger pool is good: it
reduces the odds of hitting the no-more-than-2 rule, and it also may reduce
the number of 2-from-one-company that occurs.  This is something we could
check: compare size of pool each year to how often there was two people from
one entity, or when a person had to be turned away as the third.

    > pool (say, less than 42) would be problematic, IETF participants cover
    > a vast range of interest and involvement and it seems pretty clear to
    > me that we want only those with relatively high interest and
    > involvement. Pushing people to volunteer who would not otherwise have
    > volunteered, on balance, causes more volunteers with a low level of
    > interest or involvement. I have been on 4 nomcoms, once as chair, once
    > as past chair, and twice as a voting member. In every case, there was
    > a voting member that was pretty much deadwood - either doing notably
    > less than any other voting member or doing almost nothing. In those 4

What I reading is: even when the recruiting was less strident, there was
still deadwood --- that seems to dispel this hypothesis:

    > Perhaps if the volunteer recruitment was less strident, this [deadwood]
    > would be less common, but there is obviously always a chance of it
    > happening for a variety of reasons. So it seems to me to make sense to
    > have one or two alternates who would not vote unless a voter was
    > removed/resigned/...

    > (5) I think the current criteria are pretty good, maybe 80% of ideal.
    > But, hey, pretty much ignoring my own points 1 and 2 above, I might as
    > well say what I would do if I had a magic wand: The attendance
    > requirement could be relaxed some to 3 out of 7 or the like and a
    > requirement should be added that the volunteer have been either a
    > shepherd or front page author/editor of an IETF stream RFC issued
    > within the past 4 years or served on the IESG or IAB within the past 4
    > years. (I don't see any reason to add WG Chairmanship as, to a first

So, this would further increase the burden: further limit the pool.
And this business with an IESG or IAB member... that sounds like creation of
an old-boys club, which you said you didn't want.

3 meetings out of 7, depending on which three, is more or less 1 meeting a
year, but it's not actually 1 meeting a year.
We know that the random selection is going to happen in June/July, ideally
prior to meeting #2 of the year.  So the past 7 meetings will be the March
meeting, plus the three meetings in the past two years.

{The only reason I was nomcom eligible in 2012 after a child restricted my
ability to travel was because in 2012, the selection was in early August,
after meeting #2.  The only reason I argued to attend the next meeting was
because I was on nomcom...  I was a very common remote attendee. You should
all try it a couple of times.}

We need people who can attend at least the November meeting to do interviews.
So in order to be willing/able to volunteer in May/June, if you have only
funding to attend once a year, you need to not attend in March.
But that means that you won't be eligible, so you can't even volunteer.

What that rule did is make sure that the IETF Nomcom only never comes from
well funded entities, most of whom are vendors.  If we want more operators,
we might want to recognize that they have other meetings
(ARIN/NANOG/RIPE/Apricot) that many of them struggle to get funded to attend.

If we want more academics/students, we might also recognize that as well.
If we want more young people represented... I could go on.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [