Re: Proposed IETF Trust Conflict of Interest Policy for Community Review

Stephen Farrell <> Wed, 30 March 2016 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E7D812D5AC; Wed, 30 Mar 2016 02:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JiGl-272Zd7P; Wed, 30 Mar 2016 02:52:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F43212D58D; Wed, 30 Mar 2016 02:52:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D45D2BE38; Wed, 30 Mar 2016 10:52:00 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yknLRQ31rC9s; Wed, 30 Mar 2016 10:52:00 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 568F3BE55; Wed, 30 Mar 2016 10:52:00 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1459331520; bh=YNdwSYeIPQzeWEFLfJ13xj2J/+45nWXmP/tTyy3r/Hw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OX+scSLtFihKOe9NP95g7sC4yV3NaWX1tEXEIm0ZDmDrnNUaMmRfVMx/Smpv3gFgB HWzMfIqTQXni5R4EGFJ/Phhhu7AKmQKQTg1PMNCqfZqc0w08s9gNFyUMmp5YI6qqjf PaZAW5hBMg/4Wm8/jvXgzd4sD2PDP3lC0rJFThBc=
Subject: Re: Proposed IETF Trust Conflict of Interest Policy for Community Review
To: Brian E Carpenter <>,,
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 30 Mar 2016 10:52:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060802000907060908080102"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2016 09:52:11 -0000

On 30/03/16 02:44, Brian E Carpenter wrote:
>> - Why isn't this aiming to end up being a document subject to IETF
>>   consensus? I can imagine there may be good or bad reasons for
>>   either doing this via the IETF process or not doing it via the
>>   IETF process, but I wondered - it seems like this is not just
>>   some minor operational thing, and considering these issues and
>>   aiming to get IETF consensus on how/when to declare conflicts
>>   of interest could be useful more generally. Is there something
>>   substantially different about the trust in this respect vs.
>>   other IETF roles such as chair, author, AD etc?
> IANAL, but I think the answer is yes: a Trust does have a very
> specific legal status, in a way that the IETF or IAB don't have.
> So I think it's normal that the Trust enacts its own CoI policy,
> and of course correct that the Trust asks for community input
> first.

I can well believe that that's the case, but also not being an
"L" I don't know. Even if so, the trust could decide that they
wanted their scheme to have IETF consensus, which is a separable

OTOH, maybe it'd be good to have a better way to deal with CoI
in general. The former doesn't have to block on the latter though.

Among reasons for a broader consideration of CoI, and not just
as needed for the trust right now, is that we don't currently
have any way for folks to declare such a conflict, (well,
except that IESG members can ballot "recuse" I guess). I've
had a couple of cases where I've told various folks that I
didn't want to be the AD for a WG because I was working on
something related, but there was no way to record that so
that someone looking back could know about it. That said,
figuring out something usable and useful might be a lot of

>> - Some trustees are selected by nomcom or other bodies. Wouldn't
>>   those proposing themselves for selection need to say something
>>   about known conflicts to selecting bodies like nomcom, so that
>>   we don't select folks who are conflicted out of being useful?
>>   And doesn't that mean that the list of conflicts needs to be
>>   public? And why shouldn't it be public? (Or did you intend it
>>   to be public? I wasn't sure.)
> I think it would be good practice to make it public (even if certain
> details were kept private). But it isn't just at selection time;
> a new CoI could arise anytime, e.g. due to a change of job.

Sure. Mostly I meant that if CoI's are needed as a useful input
for nomcom, then they need to be published. There may be many
other reasons why publishing is good too, but we only really need

In any case, if the trustees work out a process that works for
them and that involves published CoI declarations, then that's
an ok thing for now. If the trustee's scheme works, we might want
to look at adopting a variation of it more widely later on.


>     Brian