Re: Updating BCP 10 -- NomCom ELEGIBILITY

Dave Crocker <> Sat, 10 January 2015 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B3171A1A54 for <>; Sat, 10 Jan 2015 12:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6X3S3W6o41Kf for <>; Sat, 10 Jan 2015 12:39:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00BB51A036D for <>; Sat, 10 Jan 2015 12:38:59 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0AKcu6Q010867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Sat, 10 Jan 2015 12:38:59 -0800
Message-ID: <>
Date: Sat, 10 Jan 2015 12:38:47 -0800
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: ietf <>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sat, 10 Jan 2015 12:38:59 -0800 (PST)
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: Sat, 10 Jan 2015 20:39:01 -0000

On 1/9/2015 3:00 PM, Russ Housley wrote:
> There was a long discussion of Day Passes in 2010, and it lead to this IESG statement:
> In my view, this was the right decision. 

Minor point:

     The IESG is making "decisions" about IETF qualifications for
nomcom?  What hasn't the IESG acquired IETF rough consensus approval for

Major point:

     What IETF-specific knowledge and skills do we expect from Nomcom
members?  How do the current selection criteria increase the likelihood
of meeting that expectation?  Is that increase in likelihood large or small?

     In reality, the basic criterion we currently have often gives us
one or more members with no significant knowledge of IETF management or
process issues.  Periodically, the criterion gives of a nearly complete
slate of such well-intentioned, but naive, voting members.

     If we care about having a slate of voting nomcom members who have
practical knowledge of IETF operation, we need to require that at least
some of Nomcom's voting members have significant, hands-on experience
with important parts of that operations.

    In the current IETF, a filter based solely on meeting attendance
guarantees a significant likelihood of voting members will little-to-no
knowledge of IETF operation.

Dave Crocker
Brandenburg InternetWorking