Re: [Iasa20] CoI proposal

Ted Hardie <ted.ietf@gmail.com> Mon, 06 May 2019 21:16 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9661201E6 for <iasa20@ietfa.amsl.com>; Mon, 6 May 2019 14:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvvmTqxUg40O for <iasa20@ietfa.amsl.com>; Mon, 6 May 2019 14:16:25 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3821200EA for <iasa20@ietf.org>; Mon, 6 May 2019 14:16:24 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id b3so6700421iob.12 for <iasa20@ietf.org>; Mon, 06 May 2019 14:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1srPXdlgUopX4DD2xikDcrPHrCXbgTzLeJ7t2te98KM=; b=Zdc4ay0N48oFkWpkd+2ygzfPOoEitvigslrgP/J5qcvLQPxxT9hmoT5ufxPhvQlYrY l4GRTI338UHVl2fe4zxl6PLus4Lj6O/xzjGnDsopqAdyNZOa4yRxjON5AmylxhzokDd/ 1IUuqmH4j7sxbY9NTFiulDid3kRFiCbAIP7sKb9mr0sBbiCrq0kTanG/h49DCDvLnCwy N8R2/eEqIWCtyFlDKzzOGtNIfPJIFC+MUrnv2Uw6N1fTGGzK4TPT5R3rnVaNKDzR3GXE 3ZhZlpNaN3gHTj7LUkrvXs/8KlhRMkCAD+Tx1apqzV+R3fYAcP+4hObBxxTLideUVuip JTrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1srPXdlgUopX4DD2xikDcrPHrCXbgTzLeJ7t2te98KM=; b=WlokelVhREQ9K2YGWeL2rY5cIGosQX0TsfDeSpoFUY3kv6jqkG9NCCDfxL2SE2BtlL mKisWupdg6KxKwB325ui5/DPqaboURmVLZygSLe7mRivILhf7W7a/dtp2EUm78Wq50PZ PrWP2+5NPh+wuu3s2G+x/ofD5vOZ1l20OVt3mXLgbq04VKAmoh3SqfVQhyCXlJerUlZD xxu46S2KHuhqlnvReTynrv8QGBF9KY8uzq5rx9MDQ/E36zU2EtwD8Oo/dB4X/5cqs4mQ WJbPgAXmpdRkJ6FSQpI2lCjHOo0taolL1+lnpJc7LxMdztZAlG0DNGdWMmUV55vN3+/Y uyJA==
X-Gm-Message-State: APjAAAXppeBSLHQioArRMIweqRMOkIInapTGq6hJFzdITLgwrhiOY87Y ojGioN4qGaSlt2YJXDyc1E/Uka7XfGXNBYfqLgaUEg==
X-Google-Smtp-Source: APXvYqw7G0KmExUZFFGaN1BxBfDxGOTYevJzieiXkzJEto3iHVBL8cLCNrbd4LVupRhsMliukUWK23laD0bVrXHR+Y0=
X-Received: by 2002:a05:6602:20c4:: with SMTP id 4mr20545985ioz.145.1557177383972; Mon, 06 May 2019 14:16:23 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMCJib6uGRkMhfc+=eW0zzzCb64XJsqrLG9B8hWbmoFhZg@mail.gmail.com> <afdf3ea5-175a-7a52-7fac-e054dc61898f@cs.tcd.ie>
In-Reply-To: <afdf3ea5-175a-7a52-7fac-e054dc61898f@cs.tcd.ie>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 06 May 2019 14:15:57 -0700
Message-ID: <CA+9kkMAOnwhXSr0PNPt5bqjSSzUTTrwvJi2qqU8QhW0X5Ts_aw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d2f5ba05883e9ce2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/eJev8sC0EYKJ9cXL9_lAFWuNCbE>
Subject: Re: [Iasa20] CoI proposal
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 21:16:30 -0000

Howdy,

Comments in-line.

On Mon, May 6, 2019 at 1:57 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> Two possible additional points and one where I probably
> predictably wouldn't quite agree with your suggestion
> below.
>
> First additional point: The board could do well to document
> this as part of the role description to be sent to nomcom,
> so that everyone gets to be aware of things early, and so
> that nomcom can decide if e.g. they wanna ask folks who
> volunteer about any of this.
>
> I agree with this.


> Other stuff below...
>
> On 06/05/2019 21:37, Ted Hardie wrote:
> > Howdy,
> >
> > I think I understand the points that have been made in that thread, both
> by
> > those with NDAs in their past and those with concerns about transparency.
> > In line with that, I believe the appropriate policy runs something like
> > this:
> >
> > The Board members agree that any employment, contract, or affiliation
> (for
> > themselves of their household) that might touch on the work of the IETF
> or
> > the LLC must be disclosed to the Board as a whole.
> >
> > The Board then certifies to the community that each member has provided
> the
> > appropriate disclosure and they are operating in awareness of these
> > potential conflict.
> >
> > Each member provides a summary that can be published.  That may elide
> > details which were provided to the board.
>
> As an addition, I'd suggest that the board encourage people
> to only elide the minimum when that's really needed, IOW, that
> the board actively encourage as full a disclosure as possible.
>
> I also agree with this.


> > (In a situation like the one Adam
> > mentioned, for example, that contract might have been disclosed as
> > "implementation work undertaken under a contract held by FOO LLC", where
> > the name of the contracting part and the nature of the work were
> available
> > to the Board, but not the public. )
>
> I don't quite agree with the above (or at least with what I
> think you mean).
>
> I do accept that we cannot write an algorithm that defines
> all the acceptable details that are allowed to be elided. But,
> I'm not comfortable with the idea that a board member might
> say "I work with an unnamed entity which may cause a CoI."
>

But that's not the situation that Adam was describing.  He was saying he
was doing implementation work for a party that did not want anyone to know
that they had sub-contracted that work to a third party.  In the case of
the LLC, that work would likely have no impact on the decisions of the
Board around contracts and administrative policies.  It still must be
disclosed to the Board, as it is answers the key question "what financial
influences may be present?" in sufficient detail to know that there aren't
any salient financial influences.

But which third party and the nature of the implementation don't need to be
public for the Board to track that; the public disclosure might end up
being more forthcoming to highlight how far it is from the work of the LLC
("implementation work on $FOO under a contract held by FOO LLC"), but that
becomes a matter where Adam has to balance the NDA and the transparency.
If there is only realistic buyer of his work on $FOO, he has to be careful
about saying that; if there are lots, he can obviously say more.  If it
turns out he is working on, say, a new SCTP implementation we're all clear
that the IETF LLC is not conflicted.  As you saw, we ought to encourage
that level of clarity where it is possible.  But there are moments when
that particular answer might be a big disclosure indeed and letting it be
slightly less overt is a reasonable balance for the board member and the
board to strike.


> Doesn't that just sound pretty bad when put like that? What
> use would that be to the community?
>
>
It enables us to be sure that the Board has the information as a body that
it needs to holds it members accountable, and it gives enough information
to the community to see what sort of work the board members do which might
cause conflicts.

regards,

Ted


> Cheers,
> S.
>
> >
> > At some cadence (quarterly, at the start of each meeting, or otherwise),
> > the chair calls for updates to the CoIs submitted to the board and
> > re-certifies to the community that each member has responded.  If a
> member
> > is found to have given incorrect information or to have failed to
> provide a
> > salient update, the board can remove that member under the existing
> > procedures.
> >
> > I think that is close enough to ISOC's policy that those board members
> who
> > have previously served as ISOC trustees should find it easy to follow.
> >
> > Just my personal advice to the board, of course,
> >
> > Ted
> >
> >
> > _______________________________________________
> > iasa20 mailing list
> > iasa20@ietf.org
> > https://www.ietf.org/mailman/listinfo/iasa20
> >
>