[rfc-i] "Executive-level management": What is the purpose of the RSE?

Andrew Sullivan ajs at shinkuro.com
Mon Jan 10 05:25:22 PST 2011


Hi Glenn,

On Thu, Jan 06, 2011 at 10:58:37PM -0500, Glenn Kowack wrote:
> 
> A large fraction of your observations below are rooted in your
> asking: are we allowing use of the term "executive-level management"
> (introduced in RFC 5620) to drive our thinking about the RFC Series
> Editor?

I'd like to think that my view isn't quite that burdened by simple
terminological concern, but that it's rather trying to expose a
fundamental cleavage that we have to face.  You say this:

> Based on what I saw during my term, enlarging the scope of the RSE
> across the entire editor is necessary to allow the community to know
> who is responsible, and for someone to make a coherent whole of the
> Editor and the Series.

It seems to me that, in arguing that, you are making two different
claims:

    1.  There is a list of things that needs to be done.  You base
    your claim quite correctly in your experience as TRSE.

    2.  Some_one_ has to do those things -- i.e. has to "make a
    coherent whole".

What I was trying to argue (though, I guess, not as successfully as
I'd like) is that (2) does not follow from (1).  

In city government, there are (broadly) two models: the "strong mayor"
model; and the "weak mayor" or "city manager" model.  Similarly, in
this case, I think there are really two possibilities: we can have one
person who has several responsibilities and quite a lot of control; or
else we can have those responsibilities divided up among many people,
with someone doing the work of a kind of senior special advisor to the
community, and all the control vested in the community.  I think the
former is embodied in your recommendation, and the latter is what I
was trying to describe as the "non-professional" model.  Also, the
non-professional model isn't really "executive-level management".
Finally, to the extent RFC 5620 defines "executive-level management",
the RSE job so described doesn't sound like what I'd call an executive
manager.

This is why I argue we have a stark choice.  These models are very
different.  They involve different costs and benefits.  For instance,
your recommendations have a significant cost, as near as I can tell,
because they seem to suggest some changes to BCP 101 are needed: if
the RSE has some important level of control over people doing RFC
production, then that must have some effect on contracts.  By the same
token, I tried to argue in my previous mail that the committee and
community driven model the IETF has adopted imposes serious costs to
the IETF participants, and it isn't at all clear how that analogy
would translate to the RSE.
 
I like Olaf's suggestion elsewhere in this thread that there are
distinct pieces that can be teased apart and then reasoned about
separately.  

Paul Hoffman's suggestion for vesting policy control in an explicitly
chosen panel is I think a suggestion in line with this "distributed
authority model".
 
> The thought process I tried to convey, particularly in the
> Motivations, was to determine what a successful Editor and Series
> requires for leadership, and what that requires w/r/t authority and
> responsibility.

I get that.  What I am arguing is that there is in fact another way to
do this, which is to break the "leadership" and "authority and
responsibility" components apart.  We have actually done this in some
places, and so it is not impossible.  Such separation comes with
costs.  It may well be that people who think that leadership can come
without the responsibility and authority have not faced the costs that
will bring; but unless we are explicit about this we will never come
to any agreement.
 
> During the above period, each of the the folks above hired and fired
> editors, made or participated in policy decisions, did editing and
> production, and represented the Editor to the community and
> elsewhere.  Certainly there's some cause to call it 'leadership'.
> Note that I didn't say anything like "to the exclusion of any
> others."

Nobody suggested that it was exclusive.  But as you point out here,
the past Editors had a much broader job than the RSE descriptions so
far have contemplated.  And this is normal, because RFCs 4844 and 5620
broke some of the functions out into discrete components (ones that
are, in fact, not part of the RSE, such as direct editing and
production).  Having adopted those changes, we can't just pretend that
the past fact of "The RFC Editor" means that we need to have the same
structure in the future.  Therefore, the analogy with the past needs
strong supporting arguments.

Moreover, the present isn't like the past anyway.  The broader IETF
itself has changed dramatically over the period in question, and one
can fairly ask whether, when the facts change, one ought to change
one's opinion.  So again, the analogy with the past needs strong
supporting arguments.

If those arguments are in your text, I have overlooked them.  
 
> The community has different activities, roles, and practices.  The
> RFC Editor is fundamentally production-oriented, with a steady,
> daily processing activity that is in service to another segment of
> the community (the streams).  It operates - at the level of the
> things produced - with highly defined requirements.  Further, the
> demands for steady, quality, accurate, timely production are intense
> and unrelenting.  All of these characteristics are more tightly and
> specifically applied than elsewhere in the community.  There is
> certainly still some ad hoc-ery, but it can never be their only
> approach. Let's recall that producing 30 documents a month is not
> the same as producing one technical specification a year or
> participating in 3 meetings a year.

"Motivations" says that production and day to day operation seem to
chug along mostly just fine on their own.  Therefore, I am not sure
why the production-oriented nature is evidence in favour of an active
and strong leader with a lot of independent authority.  It seems to me
that the stability of regular production could be construed as
evidence that the direction and policy for the RSE could indeed come
from a board or committee or something.  That was why I made the
analogy with IETF processes.

But I do wish to emphasise that the IETF processes come with a great
cost.  In other discussions, we have seen much gnashing of teeth about
the kind of oversight that we get from the IESG.  It is a commonplace
to note that IESG members are now effectively full-time donations from
companies.  Join any conversation at an IETF meeting, and you're as
likely as not to run into someone making a remark about a DISCUSS
raised by someone unfamiliar with some issue during IESG review.  Some
WGs are notorious for their sluggish (not to say glacial) progress.
And we even have a BINGO game in the IETF because, despite the large
numbers of attendees at meetings, a tiny number of people seem to show
up in all the "important" functions (and at the mic).  So adopting
that sort of distribution of authority and responsibility is not
something that comes for nothing.  I just think that, as a community,
we need to decide what it is we want.

Best regards,

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the rfc-interest mailing list