Re: [Iasa20] Fiduciary duties and temporal power (was: 6635bis)
John C Klensin <john-ietf@jck.com> Wed, 01 May 2019 19:11 UTC
Return-Path: <john-ietf@jck.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 8964C120021 for <iasa20@ietfa.amsl.com>; Wed, 1 May 2019 12:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 FPJvcK3xmf1u for <iasa20@ietfa.amsl.com>; Wed, 1 May 2019 12:11:21 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1608A12008D for <iasa20@ietf.org>; Wed, 1 May 2019 12:11:21 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hLudT-000OtK-0j; Wed, 01 May 2019 15:11:19 -0400
Date: Wed, 01 May 2019 15:11:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: Richard Barnes <rlb@ipv.sx>, IASA 2 WG <iasa20@ietf.org>
Message-ID: <0989D185CE1FEDB9975C614A@PSB>
In-Reply-To: <CAL02cgS2RggOz3OBsg5R_AfFmaXkoKfMoc-pLxBoKF99u2GJtQ@mail.gmail.com>
References: <CAL02cgS2RggOz3OBsg5R_AfFmaXkoKfMoc-pLxBoKF99u2GJtQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/591xFPCRL_aZbOpqtfxh1Qa-VqM>
Subject: Re: [Iasa20] Fiduciary duties and temporal power (was: 6635bis)
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: Wed, 01 May 2019 19:11:24 -0000
Richard, I think this is helpful. I also think it is consistent with what at least a few of us have been trying to say, comments that, it feels to me, have gotten lost in a certain amount of talking past each other and discussions that are just distractions. For me, there is really only has been one key point in this discussion other than the ones you cover below and it is clearly tied to expectations of how the LLC will behave: For a variety of reasons, several of us would prefer that the LLC not find itself going down a path toward something that could be home for empire-builders; something that could accumulate significant numbers of people who are perceived of, or perceive themselves as, internal staff; that the risks of its becoming a power center that could control the IETF standards process, non-fiscal IETF policy and strategy, or RFC Series policy and strategy are minimized as much as possible. If one substitutes "significant authority" for "significant ... people" in the above it would be part of the same concern, In some of those areas we see the potential for tradeoffs between that concern and entirely legitimate and desirable focus of the LLC Board for management and fiscal efficiency. There are two ways to deal with that tradeoff. One is to give the LLC Board complete flexibility about those decisions and how they are made, assuming that, if a relevant situation arises, they will have the right in-depth knowledge and the right instincts to do what is best for the community. The other is to create (or retain) a requirement so that, if such a situation should arise, the LLC Board MUST come back to the community, explain the situation, and ask for permission. Now I think there are differences in reasoning among those of us who feel that the latter is the better answer. Some have very specific concerns about specific decisions that might be made. Others have memories of situations in which they believe that the IAOC abused provisions about personnel matters and/or contractual negotiations or requirements to take strategic actions and decisions out of the sight of the IETF community and/or to provide minimal information after the fact and would like to constrain such (real or imagined) behavior as much as possible. Still others have concerns about second-level effects of various national laws around the world and how they might affect hiring, staffing, or eligibility decisions relative to future roles. One thing I think we have in common, but that I think may have been lost in several of the on-list comments, is that none of us would say "the LLC must never, under any circumstances, add any extra employees and should, in preference to doing that, self-destruct". What we are trying to say is "We don't see the combination of circumstances now that would make that necessary; if specific circumstances in the future arise that would, the LLC needs to come back and ask rather than having the authority to make the decision on its own and possibly in secret". It is very clear to me that the employee vs contractor boundary (much less details of which tax forms are filed in which countries) is a fairly poor surrogate for what I'm getting at above. I would welcome others and more of them, but they haven't emerged. But, absent a very specific situation that requires the LLC to start hiring employees, I don't see it as desirable to remove that barrier. If the circumstances do arise, let's hear about them then, in enough detail, and let the community make an informed decision. Until then, we do ourselves no harm, and would have saved some very long discussion threads, by just letting the restriction stand, clarifying and tightening it further if anyone has good ideas about how to that. best, john --On Tuesday, April 30, 2019 20:53 -0400 Richard Barnes <rlb@ipv.sx> wrote: > Hey all, > > I thought that the "go to jail" part of Sean's message didn't > come through quite strongly enough, and there seems to be > persistent confusion about who can reasonably do what in this > relationship between IETF/IAB on the one hand and ISOC/LLC on > the other. So I wanted to frame out how I've been thinking > about this relationship, which might help clarify what some > folks are thinking here. > > tl;dr: > - Fiduciary duties trump RFCs > - RFCs are thus constrained, but still useful > - Temporal power isn't everything > > The brute fundamental fact here is that there is nothing the > IETF or IAB can do to constrain the board or management of > ISOC and the LLC to do something that they view as contrary to > the interests of those organizations. In the parlance, this > is known as the Duty of Loyalty [1], and the directors and > officers of those corporations can be sued or jailed if they > breach it. Nothing in an RFC will cause any sane board member > to violate their fiduciary duties. > > A natural consequence of that fact is that it's not useful to > have RFC text that, if followed, could cause the LLC's > management to breach their duties. Rather, the RFCs > describing the relationship should focus on establishing what > the LLC should do where it isn't already constrained by law -- > which is a lot! > > All that said, the IETF and IAB do have certain powers that > are unalienably theirs. Just like only the Pope can name > consecrate a bishop [2], only the IAB can name an RSE, RFC > Publisher, etc. The LLC can terminate the contract or > employment of the person named RSE, but they cannot take that > person's status as RSE away. > > As I said long ago at the IASA2 BoF, good fences make good > neighbors [3]. An RFC can't constrain the LLC to do something > illegal, so we shouldn't try. Our effort would be much better > spent focusing on clear descriptions of how we expect the LLC > to be have in the ways that matter. > > --Richard > > [1] <https://www.law.cornell.edu/wex/duty_of_loyalty>, among > other duties [2] Within the bounds of that tradition > [3] Yes, I know that's not what the poem means, but it's true > here
- [Iasa20] Fiduciary duties and temporal power (was… Richard Barnes
- Re: [Iasa20] Fiduciary duties and temporal power … John C Klensin
- Re: [Iasa20] Fiduciary duties and temporal power … Richard Barnes
- Re: [Iasa20] Fiduciary duties and temporal power … John Levine
- Re: [Iasa20] Fiduciary duties and temporal power … John C Klensin