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

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

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