Re: [Iasa20] CoI proposal

[Stephen Farrell <[e-mail]>]

Hiya,

On 06/05/2019 22:15, Ted Hardie wrote:
> Howdy,
> 
> Comments in-line.
> 
> On Mon, May 6, 2019 at 1:57 PM Stephen Farrell <[e-mail]>
> 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.

I get the point. And this kind of thing is apt to be hard
to impossible to resolve in the abstract, so I'm ok that the
board consider it and come up with their best plan. (And
thanks btw for all the willingness to work the topic.)

So without trying to reach 100% agreement, what makes me
most uncomfortable with this example is the idea of unnamed
parties that cause a CoI. I'm much less concerned with the
detail of what a person is doing being public.

>> 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.

Meeting that last goal would make me happy. I personally
don't think we'd meet that goal if a board member has to
recuse but can't explain why. E.g. I reckon the community
would entirely understand "board-member X recused on this
item as they work with company Y" but would be puzzled by
"board member X recused because of an undisclosed detail
from their CoI declaration."

Anyway, all that said, if the board are happy to encourage
members to disclose as much as possible, I'm fine with
this being resolved later if needed.

Cheers,
S.


> 
> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>
>>
> 
> 
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20
>