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

Richard Barnes <rlb@ipv.sx> Wed, 01 May 2019 00:53 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 C79881201CC for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 17:53:54 -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 jTQQcANtQBEQ for <iasa20@ietfa.amsl.com>; Tue, 30 Apr 2019 17:53:51 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 065DD1201CE for <iasa20@ietf.org>; Tue, 30 Apr 2019 17:53:51 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id w197so12863797oia.2 for <iasa20@ietf.org>; Tue, 30 Apr 2019 17:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zK+fIkEJdhxbHr5IaHNXBq9hsVdbxb5gXKpudMAxZkw=; b=oo7Fl/Xju06qnMOAR5S3ry1Iq7LBpK36zeMRXsWb0lvrfUgPQFBBZle5JHMbZCmTz3 IP3eaUGNDScB6tOxpVXXzubyPJQo07oTKMUZyxfBBZI+Bo6+e6b6Z+jvueH942sY8JxV HfMr4rqSFDOcIpeQsNNzZxon8CAv4oJoMdYuVHM9WCMW9p8L5/XOpMEuhs1ljjbscNYZ USVW4b7z8+lcIPDkI1H8RRvp5aEz6xQfD3m0Esn+7JW2YIz42wK+K6q8oKQySDWjRuHZ GXzFklmAIqRnkQXK1WRrupWOPqK3VTMXPAyjWNwPYfnVCStgkywBE0gMNWUJvIH3UzlW 39Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zK+fIkEJdhxbHr5IaHNXBq9hsVdbxb5gXKpudMAxZkw=; b=eaVmvsdX2gP9TuweL7uBIFmPTKoMmwhJM55aFCK5JK7EiNCxKso7hRsjgIiuGi+eOT iQels2v6ogGpv2uHTRSvVfApNuqxyL8463NH0eZUTT/yFowu9wkkxRoPemoJRIAVniFS A3Jn8sVYtag4BB1CgPVLqeGdfVJ31wbpApZBVb5GScYyz/3/gT8mv9HW4J1CjMlGR1fG nwgTXgayOxTNr/kdvmapZjo8qVJKdzgIEserwu33TYwYkTKth3jEYnmGXo+FPXGCJBnn pDQ6xHhyoUAs7YjTmyFUyt2FMGIslvdz1hP6yE7oazE0YlZCzWpC9YyxdvIA6yFZ5aFG Cq9w==
X-Gm-Message-State: APjAAAWP9tTY3uHeNKUcwF3evu/9EBcBrqBhET7e8U4t5HQb7wTy7NAt 4jOudObKE8kUKchtlzRsB7a/XQx+LmAE9gk7Z2uOOMzHsH4tCg==
X-Google-Smtp-Source: APXvYqwj7ZVlcxRcqFUtBGkfkKX9iUr70nb25cGuIKly5pPq0fi2lgNUq2pHnV3lT1T4AYuG5HVAyTAMlGH8TVwh9vc=
X-Received: by 2002:aca:f496:: with SMTP id s144mr4774562oih.135.1556672030067; Tue, 30 Apr 2019 17:53:50 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 30 Apr 2019 20:53:23 -0400
Message-ID: <CAL02cgS2RggOz3OBsg5R_AfFmaXkoKfMoc-pLxBoKF99u2GJtQ@mail.gmail.com>
To: IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006272220587c8f3ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/xsqfaxtFRJE9CnzW85RCuw1J9QA>
Subject: [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 00:53:55 -0000

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