Re: [Iasa20] Fiduciary duties and temporal power (was: 6635bis)
John C Klensin <john-ietf@jck.com> Fri, 03 May 2019 21:57 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 382F41202E1 for <iasa20@ietfa.amsl.com>; Fri, 3 May 2019 14:57:53 -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 MU0le0SU9_Iu for <iasa20@ietfa.amsl.com>; Fri, 3 May 2019 14:57:49 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 20BE41202DB for <iasa20@ietf.org>; Fri, 3 May 2019 14:57:49 -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 1hMgBf-0009pt-K9; Fri, 03 May 2019 17:57:47 -0400
Date: Fri, 03 May 2019 17:57:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Richard Barnes <rlb@ipv.sx>
cc: IASA 2 WG <iasa20@ietf.org>
Message-ID: <6901AC68D166606628A110A0@PSB>
In-Reply-To: <CAL02cgTphCas8c9YpAkMue873v_PdPmdR8Xhs8-oS7UD-vm-dw@mail.gmail.com>
References: <CAL02cgS2RggOz3OBsg5R_AfFmaXkoKfMoc-pLxBoKF99u2GJtQ@mail.gmail.com> <0989D185CE1FEDB9975C614A@PSB> <CAL02cgTphCas8c9YpAkMue873v_PdPmdR8Xhs8-oS7UD-vm-dw@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/oN-cCjugvjALMxentfrL6FsN33E>
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: Fri, 03 May 2019 21:57:53 -0000
Richard, I hope others are in better shape, but I'm finding the multiple discussions of 6635bis to be a little overwhelming and that I'm facing a choice of following it closely and staying on top of other obligations to the Internet community, the IETF, and, quite incidentally, to paying customers. My summary was an attempt to cut through that, but it obviously wasn't sufficient (both because of the control surface issue you identify blow) and the other threads that have arisen. so I would like to express the wish that someone, probably the WG Chairs, try to take an active role in trying to summarize what has and has not been discussed and settled and what is still open. Given that the IAB has chosen to ask the WG to discuss this document and the WG (and its leadership) have apparently agreed, the question of final authority should be irrelevant to whether or not the WG can react conclusions. To your question/point below... --On Wednesday, May 1, 2019 16:51 -0400 Richard Barnes <rlb@ipv.sx> wrote: > Hi John, > > I appreciate the desires here. I sympathize with many of > them. But we disagree about the available control surface. > Where you really lose me is here: > > """ > 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. > """ > > If we were to publish an RFC with such a MUST, it would have > no force. But this is precisely the type of comment and assertion to which I've objected earlier. Certainly there are cases in which it would have no force. Most of them come with edge-case or otherwise unlikely examples that, should the cases arise, would probably be symptoms of far more difficult problems with the LLC and its Board than the issue itself. Before looking at those examples and the general situation, it is probably worth remembering that, when the IETF writes "MUST" into a technical standard, that standard is still voluntary and anyone who feels like it can ignore it. Would that cause you to say "it would have no force". If the party ignoring it also claimed conformance to the relevant IETF standard, that might constitute fraud, but, at least to the best of my knowledge, the IETF has never considered taking a lead role in trying to prosecute such fraud. So, again, "no force". What a MUST does is to set out a very clear community expectation. Could the LLC Board decide to ignore such an expectation even absent conflicting legal or regulatory requirements (for which see below)? Of course they could. So, for similar things written as firm requirements, could the IAB or IESG. That leads to a number of questions about what deterrents and remedies the community has when such bodies ignore or bend established rules or intent. I don't think the question of whether there are adequate safeguards and potential remedies for the LLC Board is worth reopening; it certainly isn't a matter for 6635bis. Ultimately, what the community depends on -- with the IESG, the IAB, the IETF Trust, and the LLC Board -- is making our expectations clear and trusting that the people the Nomcom appoints to that role will conform to those expectations when they can and that, when they cannot, that they will feel some obligation to explain the situation to the community. A lot of those expectations are part of the culture and not written into normative-sounding requirements. In the case of this particular issue, I personally would have thought that trying to nail things down was a waste of time had some people close to the LLC Board said things that I (and at least a few others) heard as "decisions between more employees-staff and contracts and contractors are entirely up to the Board, we can handle it as we think appropriate, and the community isn't entitled to any input in the matter". Well, I disagree because of the desires expressed earlier and I therefore want to see the expectations made clear. That doesn't take away from the LLC Board's ability to do whatever ever they want to if they choose to ignore the community and there is no higher authority that could turn a requirement into something with "force", but it at least would not permit them to say "the community authorized us to make our own decisions about this". So... If there were some circumstance that required the > LLC to take on an employee (e.g., an IRS determination of the > type John Levine mentioned), then the LLC would be required to > do it, full stop. No contingency on community consent. To > behave otherwise would be breaking the law. Yes, absolutely, but back up a step or two. For anyone who has dealt with the IRS on the question of who is an employee and who is a contractor, or who has made a good-faith effort to understand the rules, the odds of being taken by surprise by an IRS determination that someone is really an employee are just about zero. The people who get caught by that rule are generally ones who have decided to pretend someone is an independent contractor despite their having a number of well-documented characteristics of employees because it brings them some advantage and they think they can get away with it. Even when they don't get caught, the practice is generally stupid (unless one's only criterion is that bottom-line advantage) and, since it has come up, unless the organization the Executive(s) and Board are supposed to be serving are entirely corrupt, a breach of fiduciary responsibility. So, if people think that the MUST would be improved by "subject to applicable law", go for it. I consider that obvious and implicit. But, more to the point I was trying to make, if the LLC hires someone as a contractor and the IRS decides that person is an employee (a situation that is basically impossible if a contract with a multi-person enterprise is involved), then the Executive Director and LLC Board should definitely and without question conform, as you suggest. They should also explain to the IETF community how and why they mismanaged or miscalculated things in a way that required that correction and, IMO, especially if it ever happens more than once, offer to resign both because of whatever it would say about the management problems and because the IRS has the right to impose several financial penalties if the "consultant" categorization that they have to order corrected appears to be the result of either a deliberate act to avoid taxes or the result of negligence. That is, again, a place where the fiduciary responsibility comes in but, even if it didn't, putting the IETF Administration LLC in the position of having to spend resources paying penalties rather than on IETF-related programs and activities would be lousy fiscal policy. > The only function such language could have would be to give a > bit more weight to the complaints that people could already > make to the NOMCOM. And even then, what do you want NOMCOM to > do with that feedback? Pick someone who prioritizes RFC > compliance over obeying the law? That doesn't seem like it > would produce good results for the community. To the extent to which the community cares about those preferences/ desires, I want to see the LLC Board given an unambiguous message about them. I don't want to have a situation in which the LLC Board can say, as you, John Levine, and others apparently want to be able to say "the community left this issue entirely in our hands and either didn't give us guidance or their guidance doesn't count". As to what the Nomcon is told, it would be the same thing Nomcoms are always (I hope) asking for and being told about incumbents who are seeking an additional term: where there is community consensus or a clear preference, are these incumbents being supportive of that consensus or preference and being effective about it, or are they dashing off on their own and substituting their judgment and preferences for those of the community? If the answer is the latter, I hope the Nomcom will decide it is time to select others. Unless we have started believing in Kings rather than rough consensus, that is the only thing that can produce good results for the community. If, on the other hand, the community gives the LLC Board ambiguous guidance or no guidance at all, unless there is a disaster, the worst thing that can be said about someone to the Nomcom is that their guesses as to what the community might have wanted disagrees with those of the person making the comment. I hope the difference is clear. Similar comments would apply to John Levine's follow-up comment about controlling the budget to discourage mission bloat. To the extent possible without micromanaging, the community needs to provide clear guidance and to monitor the budget. But, if the LLC is confronted with some situation that is a legal requirement that falls outside the budget or budgetary process, I expect they will deal with that in a way that is effective, efficient, and consistent with law -- and then explain to the community why they were unable to anticipate and avoid the situation that caused that action. Really no difference and the two are complementary, not conflicting. > So like I said, we should avoid putting RFC text in areas > where there are likely conflicts with legal obligations. I hope the above is an adequate explanation on that subject. Again drawing an analogy to our technical work, we have a long history of putting text in RFCs that conflicts with legal obligations and national laws. We approved standards for IP, TCP, and SMTP at a time when there were national regulations in a number of places requiring the use of other protocols. We are stressing privacy and encryption in many of our protocol designs in spite of (or because of) increasing pressures in a number of places to either restrict use of encryption or to require government access. Those analogies are not exact, but no one that I know of --certainly not me-- has advocated trying to force the LLC to violate the law. Instead, we are expressing a preference for one legal mechanism over another and expecting that the LLC will implement that preference in a way that is consistent with applicable law. > Render unto Caesar the things that are Caesar's. There are a few problems with trying to cite Caesar and his authority. For starters, he has been dead for somewhat in excess of 1900 years, so claims about his possessions are questionable. The IETF claims to reject kings, but giving authority to someone who claimed, not only to rule by divine right but to be divine, seems a little out of line. I know what you meant, but this is not a helpful observation if taken even a little bit seriously. best, john > On Wed, May 1, 2019 at 3:11 PM John C Klensin > <john-ietf@jck.com> wrote: > >> 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