Re: Updating BCP 10 -- NomCom ELEGIBILITY

Michael Richardson <> Wed, 11 February 2015 20:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5AB531A700C for <>; Wed, 11 Feb 2015 12:48:56 -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 Q6d1aS3HW2UM for <>; Wed, 11 Feb 2015 12:48:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7DD71A6FFF for <>; Wed, 11 Feb 2015 12:48:53 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 3554C203CD; Wed, 11 Feb 2015 15:56:20 -0500 (EST)
Received: by (Postfix, from userid 179) id ED9E463A21; Wed, 11 Feb 2015 15:48:52 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id D6183637F4; Wed, 11 Feb 2015 15:48:52 -0500 (EST)
From: Michael Richardson <>
To: Brian E Carpenter <>
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 15:48:52 -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 20:48:56 -0000

Brian E Carpenter <> wrote:
    > Being geeks, we have a tendency to invent solutions that
    > are theoretically wonderful but quite impractical. The current
    > 3/5 rule avoids that and is fairly easy to check algorithmically.

    > I think we need to keep that simplicity as much as possible. So
    > something like the following might work.

    > Either
    > 3 out of the last 5 meetings
    > or
    > 3 out of the last 10 meetings and (RFC author or WG Chair or AD in the
    > last 5 years)

When you say "RFC author", I guess you mean something which went through the
process to get a number.  I guess that means that having your name on the
front page now has more significant value now.   If two IDs merge, now it
matters who is an editor, and who is in "Contributors" at the end...

I would like to know why my previous list was too long or unclear?
I specifically listed:

  0) attend the meeting in person.

  1) be a document shepherd or working group chair on a document
     that entered AUTH48.

"WG chair" was listed above, and I added "that entered AUTH48", because I
wanted to deal with the possible way to game things where a WG is created as
a sinecure. No dead WG.  It's the act of going through AUTH48 that I care
about, not who you were. [The authors of the document get caught by 2]

And I included shepherd, because I want to provide more opportunities for
more people; if you attend meetings rarely, you are unlikely to be visible to
ADs for selection as an WG chair, but shepherds are in short supply.
And all the above things are trivially checked in the datatracker.

  2) be the document uploader (pressed submit) on a document that
     was scheduled into a WG session.

So anyone can upload at any time.  If the WG takes your document on,
then the datatracker clearly knows this, so that part is easy to check.
If you draft-author- is scheduled, this will require some additional
datatracker effort for the WG chairs to indicate that your document goes into
the agenda... but, I we wanted to be able to track which documents were
discussed into which WG anyway for all sorts of reasons, so I think that his
work will already happen.

  3) opened a ticket on a document that was scheduled into a WG session.

While the Issue tracker is not well integrated into the datatracker, I know
that many want it to be, and also that many want many other improvements.
Again, knowing that an issue was discussed at a WG session is pretty
important thing to track, I think... so really the datatracker OUGHT to know this.

  4) scribed for the I* telechats.

This requires secretariat/I* action to confirm, and is frankly probably my
least interesting way.

Now, I can see how "AD" could make one eligible, and how an AD after a 6
year term, could easily become non-eligible having taken a break. But:

     I don't like AD this way because it looks too much like the previous
     IESG is selecting the new IESG. Yeah, random selection.

     Since former ADs are well known, often well spoken (thus causing them to
     write IDs), and are often asked to join directorates and do reviews
     (therefore opening issues), and might even be really really good
     shepherds...  I prefer rules about what you do, not who you are/were.

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

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