[rfc-i] The RFC Series Manager

John C Klensin john+rfc at jck.com
Sat Jan 24 17:43:57 PST 2009



--On Friday, January 23, 2009 20:36 +0100 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:

> 
> John,
> 
> Again, a sincere and respectful thanks for providing yet
> another
> perspective and explanation of your concerns.

And thank you for the careful consideration and reply.

> Although I agree with significant parts of your concerns there
> is one
> detail where I think we have to agree to disagree. More inline.

I think the disagreement is much smaller than you perceive.

>...
> This is where I agree. Recently I  observed how a (liaison)
> situation
> required quick coordination among IAB members, and that the
> IAB is not
> particularly accustomed to operating in a fast-response mode.

I would suggest that even the IESG is not particularly
accustomed to operating in the fast-response mode and that they
inherently operate more to tight operational schedules than any
of the other components of our systems.  Hence the general
comment about Boards.


> I think that our difference in approach is the level on which
> these
> feedback and iteration loops are described in contracts and
> agreements.

Yep.  I'm arguing for spelling it out a little more because:

	-- I understand that the IAOC's plan is to do the
	solicitation in a way that does not require the
	Production House or Publisher, and possibly even not the
	RSE, to demonstrate that they are already members of the
	IETF community and thoroughly familiar with the RFC
	process.  
	
	-- We are ultimately talking about contracts here, some
	of them contracts that will involve significant amounts
	of money.  If people quote prices and make contractual
	commitments based on their assumptions about what the
	expectations are (including expectations about review
	and who is in charge) and those assumptions turn out to
	be wrong --or, more specifically, that there is a
	mismatch between IASA and IAB assumptions and contractor
	assumptions-- then the only thing that can be guaranteed
	is that there will be unhappiness, probably unhappiness
	all around.

So the question I ask myself when I review these various
documents is "if I ignore what I think I know about how the RFC
Editor has functioned, look at the documents alone, and assume
that, while the IAOC consists of reasonable people, they are
going to try to get the best deal for their money and aren't
going to like paying for budget overruns, do I know enough to
price this job?"  To take the most obvious example, the answer
is that, unless I understand the nature of the iteration loops,
how long they can go on, what the mechanism is for saying
"enough, stop!", and who gets to make that decision if there are
disagreements, I don't.  More broadly, if the relationships in
the documents appear to create a situation in which the actors
in one piece of the puzzle can take actions that cause actors in
another piece to incur costs or be unable to perform their
tasks, I either need to understand how those issues are resolved
(e.g., if I'm the victim, do I get to say "no, unless you pay me
X", and how much control do I have over the value of "X") or I'm
not going to bid at all, or not going to bid without a huge
safety margin in my price, neither of which helps the IASA or
IETF.

To some extent, that is a comment on the RFI and not the Model,
but I think the community has to be ok with the relationships.

> What we need to be satisfied of is that the Model describes
> sufficient
> brush strokes to enter the bidding process. That the bidding
> process describes sufficient detail to get a feel for the job
> and to
> get the contract terms correct. I do not think that any of
> those
> documents will be able to describe the culture that exists in
> an organization.

Exactly.  See above.  And note that, if we had already been
doing things this way for a few years, we would have worked out
enough of the kinks that we could tell a potential bidder "go
look at what is happening there and assume there won't be big
changes".  In addition, if we are even a little bit smart, we
won't be competing multiple parts of this arrangement at the
same time.   So a potential new contractor for task area A will
be looking at sliding into a system in which the contractors for
task areas B and C are already running.  The problem here, and a
different version of why I'm pushing for tighter language, is
that we have a multiple-body problem with all three (or four)
task areas in the air at once and no points of stability to
which someone can anchor a contract.

> I truly believe that if one engages in a business relation one
> engages
> in a relation where one is prepared to commit to each-other and
> prepared to work towards the best outcome possible (that is
> what I
> expect professionals to do).

Absolutely.  But a different metaphor is that good contracts,
like good fences, make good neighbors and collaborators.  My
definition of a good contract for that purpose is one that makes
roles clear enough that people with good intentions do not end
up in disputes about roles, requirements, or relationships.  I'm
much less concerned about mechanisms for punishing those who
deliberately break the rules.

> I take a danger when using a metaphor:
> Much like in a marriage, the details on who puts the kids to
> bed are
> not spelled out in the wedding papers. And much like in a
> marriage
> there might be arguments about doing the dishes or the
> toothpaste-
> tube  cap. Taking the metaphor to an extreme there are
> marriages that
> collapse on arguments about the toothpaste-tube cap. In order
> to not
> have the same statistical failure rate as in marriages a
> contract
> between business partners is more detailed, but not to the
> level of
> all the various feedback loops that exists in relations.

If a business relationship collapses over the business
equivalent of the toothpaste-tube cap, the business
relationship, like the marriage, has far more fundamental
problems.  But, to stretch that metaphor a bit further, the
problems often don't lie in what is explicitly not specified, or
agreed by both parties (implicitly or explicitly) as not needing
to be specified, but in the things that are considered important
enough to specify but which the two parties understand
differently.  And that is where we get back to the feedback and
approval loops.   If the documents and RFI clearly identify the
fact that there are loops, that a certain amount of iteration is
the norm rather than the exception, that multiple people may
need to sign off multiple times, etc., I have no problem --and I
certainly do not feel a need to see, e.g., specification of
upper bounds on those loops or every loop spelled out in detail.
If some actual potential bidder has a problem with insufficient
information in that sort of area, let them spell it out in the
RFI -- that is exactly the sort of thing an RFI step is normally
about.

By contrast, if the documents are such that someone who is not
deeply familiar with the way the IETF functions can read an RFP
and conclude that there are no loops except in exceptional
situations, and that our model is that, except in unusual and
infrequent circumstances, once something comes over the wall
from one of the streams, it is a publication-process issue and
never goes back over that wall, then you have a disconnect
between the expectations and understanding of the IETF and those
of a potential bidder and the price and conditions they bid.
FWIW, while I've never been happy with how it works for
technical documents in practice, that "document make a one-way,
single-time, trip over the wall" model is very common in many
editing environments so, if you are not explicit, having someone
make the wrong inference based on their experience is a fairly
likely outcome.

> I also think we differ in believing that one can manage with
> authority
> without having the (ultimate) hire and fire capabilities. I
> believe
> that the model and the RFI reflect that authority, and based
> on discussions
> with others I don't think I am the only one with that believe.

First of all, we are really talking about terminating or
unilaterally adjusting contracts here, not hiring or firing
individuals across those contractual boundaries.  It makes a
difference.  Second, despite my reputation for running around
screaming and doing imitations of the Red Queen (apologies to
anyone who doesn't get that reference ... it isn't important),
I've always believe that having to fire someone for anything
other than gross non-feasance or malfeasance represents a
serious management failure.   I'm also a firm believer in the
principle that someone in a management position who discovers
that he or she can't manage in that environment and who can't
figure out a way to remedy the situation should quit.  So, at
some level I don't really care about "ultimate hire and fire
capabilities".

That said, the perception of authority is often a requirement
for efficient and focused negotiations.  If someone in one of
these roles actually has to use that authority very often,
you've hired the wrong person.   "Ultimate hiring and firing"
authority (or equivalent) aren't necessary to that perception of
authority.  However, there is a huge difference between: 

	* RSE goes to IAOC and says "we have a problem; I've
	tried to resolve it in the following ways and it hasn't
	worked; if you don't respond within a reasonable (and
	specified) period of time with a different plan, the
	following action will be taken...".
	
	and
	
	* RSE goes to IAD and says "we have a problem; I've
	tried to resolve it in the following ways and it hasn't
	worked; while I recommend so-and-so, would you please
	initiate your own investigation and evaluation and
	decide what to do"

In the former case, the RSE has the practical authority, even
though the "ultimate" version is something of a matter of
semantics because action cannot be taken without IAOC approval
(or an IAOC decision to sleep through the issue and solution
space).  In the latter case, especially if the nature of the
problem requires a fairly deep understanding of the publication
issues, the IAD has become the RSM and the RSE has no authority
to do anything but _ask_ someone else to make a determination
about what should be done and to do it, presumably on his or her
own schedule.

There are points in between, but maybe the distinction is clear.

There are a bunch of issues with the second approach, including
the competence of the IAD to exercise the level of knowledge and
understanding that are expected to be part of the RSE's job
profile, but the most important of them is that you can't hold
the RSE accountable for anything unless the RSE can, at least,
make an evaluation and decision about what needs to be done,
present that evaluation and decision to the IAOC, and expect
action within a relatively short period of time.  I would
presume that action could be to do what the RSE suggests, to
tell the RSE "no, and if you feel you can work with that, you
can quit", in principle to "fire" the RSE instead, or to suggest
and work out another alternative.   But the IAOC is a
review-and-consent body in this model, not a body that is
expected to engage in extensive review, mediation, evaluation,
or second-guessing of its own.

> If you are referring to the 5378 mess then the IAOC has a very
> minor
> role. In fact one could actually argue whether the Trust (same
> set of
> people) has a role here (its only put in place to execute the
> IETFs
> instructions). One could actually take this a step further and
>...

Partially because of your central leadership point, let's turn
this into a separate discussion, ideally after 15 February,
whenever that turns out to be.

>...
>  > The question then becomes "who is the RFC Series Manager"?
> In
>  > trying to sort out authority to match responsibilities and
>  > discussing terminology like "Executive Management
>  > Responsibility", many of us have assumed that it should be
> the
>  > RSE.  When I read your comments about hiring and firing, I
> think
>  > you have concluded that it should not be... although we may
> just
>  > be confusing each other with choices of terminology.

> Let me be clear: That managerial role is expected to be with
> the RSE,
> expressing that more strongly in the model and the RFI is the
> main
> point of the feedback we received.  And I hope that my recent
> text
> modifications made that clearer than in version 3 of the
> document
> (I'll post version 04 later today). Also based on the feedback
> the
> RFI, that will also be posted today, intends to make that role
> more clear.

I will try to look at both RSN.

> The only thing where I think we differ the RSE has authority
> to hire
> and fire. For all practical purposes: What is the difference
> between:
> "You better do as I say or get sacked" and "You better do as I
> say or
> I will strongly recommend you get sacked"? The difference is
> how much
> that advice is taken at face value. It could well be that the
> RSE is not
> functioning so escalating the 'ultimate' question is a good
> thing.

See above.  My problem is not with "ultimate" or not, but with
whether the RSE is a relatively autonomous actor with management
authority or, to put it very strongly, an employee on the IAD's
staff.

> There is a detail here that I want to mention: there is a
> possibility that
> the RSE and the Production Center are under one contract with
> key personnel
> clauses in that case the RSE will de-facto have more authority.

Sure, except that I think the way the model and RFI are designed
either eliminates that case or drastically restricts the range
of possible bidders.  

This particular type of RFC Editor reorg is a very expensive
effort.   I've got other things that I could be doing in the
time I can give to the IETF and I presume others, including the
IAB and IAOC members, do too.  It was clear, at least to me,
that 4844 and 4846 were worthwhile to give us a handle on a
better description of what is going on.   The development of the
"streams" model was very useful, at least as long as we took it
as descriptive and avoided taking it too seriously.   And, at
least IMO, the contributions of that model to the new "headers
and boilerplate" work and the IESG's  efforts to get 3932
straightened out, are very beneficial.  But this effort to
further parse out the model, describe tasks, etc., has been
justified in only one way, which is to be able to compete the
pieces separately, primary in the hope of saving money.  You've
heard several of us question whether that --especially the
separation of the publication house and RSE functions-- can
work, but let's leave that aside.

So, we now have an RSE job description that just about requires
that whomever take the job be an active, or recently-active
member of the community, with considerable knowledge of
publication processes, considerable knowledge and experience
with the traditional workings of the RFC Editor process, and a
level of technical skill and understanding that is roughly
comparable to what we expect of IAB and IESG members.  If I
correctly understand his comment, Bob Braden has pointed out
that a large fraction of what he, Sandy, and Alice spend their
time on is now part of the RSE job, not the publication house
one -- more than an FTE.  

However, I suggest that there are no more than a few dozen
people in the community with the needed skills and knowledge.
Most of them have jobs, most of them would prefer to spend their
lives in other ways, and so on.  There isn't a lot about that
role that is going to be really attractive, especially as a
career path, to most IETF participants and, if it is full time,
it isn't a hobby, a volunteer task, or probably something to be
done for a few years as a service to the community.   So, while
I hope the population of likely candidates is non-zero, it isn't
going to be large.  And, while I'll come back to this, I'll note
for the moment that some fraction of those candidates will
probably not consider direct, line, management of production
processes and the people who carry them out to be a particularly
fun way to spend time.

By contrast, all of that IETF-specific knowledge and experience
has been parsed out of the Production House description.  That
is as it should be if your goal is to be able to get bids from
professional technical editing houses with good computer and
network knowledge but without a requirement for in-depth IETF
experience.  Compare the target for the production house
description and bidders to the definition of the Secretariat
tasks when that activity went out for bid.   The job, in theory,
should be able to be done by any competent and experienced group
of technical editors who are well-organized, well-managed, have
familiarity with networking terminology, etc.   You do need
highly competent technical editors -- some copy-editing or
thesis-draft-improving group isn't going to be able to do the
job and the SOW sort of reflects that.  There aren't as many of
those groups out there as you might think --many of the good
ones are in-house in various companies who make technology
products-- but I know a few who might conceivably be talked into
bidding and I know a few individuals whose experience and skills
leads me to believe that they could assemble such a group.
Others have their own lists, so there is probably a reasonable
population of candidate bidders.

However, if you put the RSE and Production House together, you
basically can't get bids from any Technical Editing group who
can't find someone who wants to be RSE.  That gives you an even
smaller list of bidders for the combination than you might get
for the RSE because some of the possible RSE candidates might
not want to take on line management of people (rather than,
e.g., loose contractual management of organizations), some of
the editing groups might not want to add what would certainly be
a senior and expensive position in their organizations, etc.

On the other hand, if that is what you want -- if the IAOC has
more or less concluded that having the two be separate is not
plausible -- then please drop the charade.  If would be far
easier to write a satisfactory RFP with the two jobs combined,
some of us would stop worrying and complaining about
interactions and loops that the RSM (or IAD, or IAOC) might have
to monitor and manage, and you would get, IMO, a lot fewer and
more uniform bids to evaluate.

>...
>  > However, if the RSE isn't also the RSM, then either:
>  >
>  > 	(1) You need to figure out how to appoint the RSM,
>  > 	presumably as an Executive Management position for which
>  > 	the appropriate mechanisms are formal searches and
>  > 	retained search firms, not an IAB appointment mechanism
>  > 	designed to find volunteers from the IETF community.
>  > 	
> 
> This is a  strong argument for not having the RSE selected by
> the IAB (the first argument I see for one particular choice)

Indeed it is, although I think I suggested it months ago.

>...
> Have a nice weekend...

You too.
best,
   john





More information about the rfc-interest mailing list