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

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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