Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE)

From: John C Klensin <[email-masked]>
Date: Wed, 04 Nov 2020 14:17:57 -0500

--On Saturday, October 3, 2020 09:25 +1300 Brian E Carpenter
<[email-masked]> wrote:

> I think that the root cause of the problems we experienced in
> 2018 and 2019 was split responsibility about the line
> management of both RFC production and tools implementation.
> This was built into the old model, with the IAD, the RSOC, and
> the RSE all believing they were supposed to be in charge. The
> arrival of the LLC sharpened up this problem, but also makes
> it clear that the LLC -- and *only* the LLC -- should be
> responsible for line management.

Brian,

While I might have said the same thing a few months ago, after
reading the subsequent thread (although I'm going back to the
above to reply), thinking about some other correspondence (in
and out of the IETF) and other situations, reflecting on "the
RFC Editor function long ago", the "moral authority" and
"provides guidance when asked by the RPC" characterizations, and
the implications of what seem to me to be frightening
similarities between Henrik's (and Leif's) description of his
situation and Heather's description of what caused her to leave,
I partially disagree.

In that old model, the IAD (and IAOC), the RSOC (and IAB), the
RSE (and predecessors), and (by the way) the IESG all thought
(and acted as if) they were part of a team effort, working
together for the best results for the IETF community and the
Internet... with perhaps-surprisingly little attention paid on a
regular basis to who was "in charge".   Now, that has clearly
changed and the "who is in charge" question has become
fundamental.  Perhaps the cause(s) [1] of that are inevitable or
unavoidable at there is no going back to more collaborative and
cooperative times.  

However, if the LLC and its ExecDir are "in charge" and they see
their role as running things like a good company with
responsible management controls over employees and contractors
-- and it is easy to understand the LLC agreement and several of
the IASA2 documents that way so they are not to blame for going
down that path -- then, unless we can figure out how to erect
some very strong boundaries (and get them to agree because it is
not clear the community can dictate to them), the difference
between "responsible for line management" and "it is part of our
job to lay out contractual language and, even more important,
rules about how contractors behave" [2] is strictly up to the
LLC and its interpretation(s).  

For this particular case, where this is leading is that, as long
as the LLC has the ability to say "you cannot give that advice
or issue those instructions" or "you are not allowed to say
anything to the IETF public without our approval", the "advisor
versus executive editor" question is ultimately meaningless --
they are just contractors subject to the LLC's rules.  Now, I
wouldn't expect any of the current actors in the LLC to impose
restrictions that broad or draconian, but that doesn't mean they
or their successors couldn't (they might even feel obligated to
do so if acceptance of particular advice would, e.g., increase
costs.

I'm coning to realize that another pair of issues I've tried to
raise are relevant to this.  Whether as advisor, executive
editor, or some other characterization of the role, there are
knowledge and skills involved that are rarely taught in, e.g.,
network engineering school.  This list keeps coming back to
variations on "the community makes the ultimate decisions about
strategic issues".  Unless we are willing to write into the job
description for this position (with either of these titles or
another one) "willing and with the needed skills to educate the
IETF community about publications and publication strategy
issues" and then write into the job description of IETF
participants "willing to either be educated about publications
and publication strategy issues or to know what they don't know
and stay out of the discussions" (and figure of a way to enforce
the IETF community requirement without suppressing dissent) then
we are going to have terrible difficulty recruiting someone of
the caliber I assume you want for the position and retaining
them once recruited... even if the LLC is not the ultimate
arbiter of strategic decisions.

back to lurking...
   john

[1]  These are perhaps caricatures, not quotes, but I see "need
to watch out for the welfare and best interests of the company",
"I'm going to be perceived of as 'in charge' and blamed if
things go wrong, so I'd best assert control", or fundamental
changes in the characteristics of the people who volunteer for
various leadership roles and who, from them, are selected as
likely parts of the puzzle.

[2] The recent consultation about contractor conflicts of
interest is an interesting example of this.  I'm pleased that
the Jay (and the LLC) have been responsive to community concerns
about accidentally cutting off valuable substantive input, but
nothing actually obligates them to do that -- we advise and they
do what they think best (perhaps even first for the company and
second for the IETF).

---

From: Jay Daley <[email-masked]>
Date: Thu, 5 Nov 2020 10:43:52 +1300

John

> On 5/11/2020, at 8:17 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

You are mistakenly interpreting Henrik’s message to mean that he was over managed by me, when the complaint about me is actually about under management.  

> do so if acceptance of particular advice would, e.g., increase

I agree that this is a risk, but I think it’s a much bigger risk than can be mitigated against here as it applies to all contractual relationships.  I have on my work plan a consultation about contractual terms and I think that would be a good place to raise this - i.e. to introduce a "safe harbour" clause for a contractor providing their honest opinion to the IETF community.

> do what they think best (perhaps even first for the company and

I disagree.  RFC 8711 is explicit:

      Responsiveness to the community.  The IETF LLC is expected to act
      consistently with the documented consensus of the IETF community,
      to be responsive to the community's needs, and to adapt its
      decisions in response to consensus-based community feedback.

If your response to that is that the LLC could choose to ignore that then we’re again into a much bigger set of issues.

Jay

> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 05 Nov 2020 02:03:18 -0800

Hi John,
> > responsible for line management.

In general, there is more than one root cause to problems.

>unavoidable at there is no going back to more collaborative and

There was a time when the RFC Editor had the final say.  If I am not 
mistaken, that was based on the person's experience instead of the 
job description.  That worked well as long as someone out there was 
writing the check without asking too many questions.  The structure 
(after the transition) created contractual relationships together 
with the accountability which comes with that.  There were also 
several "governance" entities in the structure which made 
accountability more complex.

A structure does not work well if there isn't some cooperation,  At 
the same time, people from the outside expect someone to be in charge 
of daily operations.  The discussion looks one about the title of 
that person.  Another angle to the discussion is the "governance" entities.

The strategy over the years was to put the IETF Chair on most of the 
committees.  The person automatically became the one in charge of 
everything.  Is that a sustainable approach?

One of the issues identified by IETF Administration was that there 
isn't any contract performance framework.  Would copying and pasting 
a framework from somewhere else would work well?

Regards,
S. Moonesamy