Re: [Iasa20] Fiduciary duties and temporal power (was: 6635bis)

Richard Barnes <rlb@ipv.sx> Wed, 01 May 2019 20:51 UTC

Return-Path: <rlb@ipv.sx>
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 2128B120094 for <iasa20@ietfa.amsl.com>; Wed, 1 May 2019 13:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 nT6nm6X7_2-s for <iasa20@ietfa.amsl.com>; Wed, 1 May 2019 13:51:32 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 8AFAD120021 for <iasa20@ietf.org>; Wed, 1 May 2019 13:51:32 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id w6so167178otl.7 for <iasa20@ietf.org>; Wed, 01 May 2019 13:51:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rzmn5MYxpgcOVmFKLI8lnUpedvbS1lS7NI5bWH2z3KA=; b=HxGVIjXDAdtDjDcfoYmR5Cj2a9BP46PDpFnNtSllwG7ImR5wzO5Hm4R7SWiJaCYFVX G0CI94eo5RAMVrRJTjiRg/UvSRFwz7brCIPQZ5lSF9zzICEewXh6ggA3d7oTM6WvApld KcPyaAohowpD0netAphQDiaHD0rTRY7cDGtI9n1ciS6SYdCWZOofcRcYL4/+hoGGcYSM 2cfMUvvYLsNtkx0mw4WdKv2dAzU10kwQk8RJmge4yZU4UQ9HmBVYawtkT/kbO4AM1ioC 85Oozi4/V5iG7dMVHD3us/GKAOnvG6Xk2y8BJzRpYvavc2fSf36gYntkJO69n/Ji2Q8Y mkBw==
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=Rzmn5MYxpgcOVmFKLI8lnUpedvbS1lS7NI5bWH2z3KA=; b=WVIt00sn12v0WAFSb/94JYNQOTf61mWGZgMEHpfwzs6fTXMeo+B+X3ZR2S+Sgh2b9x VWk58XW26cLO8KHYJ0fa82O+rhrVNTCmcoiMViARJueQnJouZfl79G/4sRg67Zxbfgmr +2YjIJRgHPf2Km5c7XhQIjFlO7dX2jbLNl0kOdSoZN2ANZ5sWwGzJ5TtrSBLn1hXtDbQ 5INM+jI++KQhVwxxFFKquGjAQ+ahwBpZKbD9SQgvuUZS6NXzlBf6atpJCxR0ytgvHvyT pVxaa70x1PS5e1RUKPK2OYUFsOi7nL0fmm7eHh5RmwP7ZiHyLmzk+Kd3iQF4niGkFA7F C79g==
X-Gm-Message-State: APjAAAXKr0EmWzfkMSxoqKFeO1Btr/CZfVPXEN5+WWPW08YkfPxDLZYp 0Hj2AXo89sBblPbk4/Zz/qoTPhngq4Zpxuouk36ePg==
X-Google-Smtp-Source: APXvYqxUrnCR9UJlO3b8AOPqXHygVz05ERGE8FOE0UqIqUOJPMOSj44J8DeHZHRgwLvWgOuCTt0rLPJE889GSBtiyUM=
X-Received: by 2002:a05:6830:210d:: with SMTP id i13mr13281158otc.331.1556743891782; Wed, 01 May 2019 13:51:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgS2RggOz3OBsg5R_AfFmaXkoKfMoc-pLxBoKF99u2GJtQ@mail.gmail.com> <0989D185CE1FEDB9975C614A@PSB>
In-Reply-To: <0989D185CE1FEDB9975C614A@PSB>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 01 May 2019 16:51:03 -0400
Message-ID: <CAL02cgTphCas8c9YpAkMue873v_PdPmdR8Xhs8-oS7UD-vm-dw@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad23860587d9ae1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/qVPa6c-Dvz0Eq51jYzsKp5SPHaM>
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 20:51:36 -0000

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

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.

So like I said, we should avoid putting RFC text in areas where there are
likely conflicts with legal obligations.  Render unto Caesar the things
that are Caesar's.

--Richard



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