Subject: Myths of the IESG: Reading documents is the problem

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Aug 2005 21:15:25 -0400

We're' in the midst of an honest discussion about reducing IESG work
load.  Personally, I think we've missed an important question
somewhere around here.  What do IESG members spend their time on?

I don't currently know the answer to this question.  I'm thinking of
ways to find out and hope to have suggestions in this area.

There seems to be a common perception that a major time sync for the
IESG is reviewing documents and writing up comments.

This does take time, but it is quite efficient.  I do not expect to
find major time savings in increasing the efficiency of getting
information about protocol proposals to the IESG.

We tend to get very good at doing a first pass of a document and if
the document is well written building up an understanding from that
first pass.  In general I and other IESG members I've discussed this
with can pick up the content of a document faster than I could by for
example reading a presentation about the document or having the
authors explain it to mee.

Writing up initial comments is also reasonably efficient.  

There are approximately three levels of review.  The simplest is
reviewing to find out what a document is about: the gola is to
understand the document well enough to know what technologies it
touches and briefly what it is trying to do.  The second and most
common type of review is to have a fairly good understanding of the
document; understand all the conceptual bits although perhaps not all
bits on the wire.  The third level of review involves going over a
document in fine detail, looking for internal inconsistencies or
missing details.

Each successive level of review requires more time.  For me the
differences involve how much time I spend taking notes while reading,
how many passes over the document I need, how many times I need to
jump forward or reread a section and how many references I need to
follow.  There is also some time required for thinking through
details.  the IESG work load trains you to be quite efficient at each
level of review.

An interesting side effect of this is that proposals like RFC 3932
designed to encourage the IESG to review certain classes of document
in less detail may not have as much success as you would initially
think.  It is more efficient in many cases to read a document for a
full review than it is to read for limited criteria.  And if you read
the document in full, you're going to find all the comments you would
have found regardless of whether they were in scope for the review.
Even so, such procedures do have time savings in other parts of the
process.  In particular I do support something like RFC 3932 both
because of time savings and because of other benefits.

So if reducing time spent reading documents is not likely to be a good
target for optimization, are there related activities that are
potential optimization targets?  I think so.  Many aspects of handling
comments could be optimized possibly for significant time savings
especially on the tail of the distribution.  I also think that there
are many logistical/tools issues that could produce significant time
savings.  Finally, time required to review a spec depends
significantly on the quality of specs.  The more we do up front to
improve specs, the less time review takes.

--Sam

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Aug 2005 14:00:33 +0200

The key sentence in what Sam wrote, IMHO, is

> The more we do up front to

If a document reaches the IESG in good shape, it leaves the IESG
much more quickly than one that's in poor shape. The single most
effective way to reduce IESG review time is to produce better
documents - and the criteria for "better" aren't secret, although
there is scope for a central place pointing to the various criteria.

I agree with Sam that raw reviewing time is not by any means
the main source of IESG load - although the fact that o(15) drafts
show up for review every two weeks, with the processing they require,
does add up to a large chunk of time. But certainly one of the
criteria for a proposed alternative review process is: how
much work does it actually divert, and does it add new processing
work instead?

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Aug 2005 12:04:17 -0700

> IESG is reviewing documents and writing up comments.

Sam, thanks for pursuing a line of discussion about where AD time is spent.

You've used the same word that I heard in the plenary, namely "reviewing". I'm 
thinking that it was well-chosen, but might be more complicated than it first 
seemed.

While it's good to hear that the basic act of reading and commenting is not 
necessarily the major time sink that one might have thought, perhaps the 
deeper problem is the difference between the role of facilitating IETF efforts 
versus the role of acting like a technical contributor.  That is, Process 
Assistant versus Technical Expert. Both tasks are difficult and both are 
usually necessary.  And the former also requires reasonably good technical 
skills.  But it is very different, indeed, from the latter.

So perhaps the deeper issue with "reviewing" is that Area Directors might be 
spending too much time as technical contributors and not enough helping 
working group chairs and editors ensure timely, solid progress.

When an AD is participating in a working group meeting making technical 
comments, they are not performing in the role of process assistant.  When they 
provide feedback that challenges technical assumptions or state architectural 
preferences, they also are not performing as process assistants.  They are 
acting as technical contributors.  However wonderful their insight, the 
contribution is NOT one of facilitating working group management.

When the AD is the cognizant AD for the working group, then activity that 
looks like technical contribution ought to prompt a question about who is 
minding the shop?  If the working group is operating to perfection, then the 
absence of the cognizant AD as a process assistance is dandy.  And we do have 
such working groups, now and again.

But mostly working groups need all the procedural and project management 
assistance they can get.  Usually they are not run by professional managers -- 
and even when they are, IETF wg management is quite different from corporate 
development team management. So the perspective of an AD who is trying to 
offer process management suggestions and trying to help the chair navigate 
both within and without the working group is typically needed... even when the 
wg chairs are experienced.

What is especially problematic is when the working group has late-stage 
process and project management difficulties, leading to the obvious question 
of what happened in the earlier stage?

Having a non-cognizant AD press late-stage issues leads to the question of why 
they did not pay attention earlier?  If the topic is important enough for them 
to delay the wg output now, why was it not important enough earlier?  If the 
hassle is, really merely tactical or a matter of engineering preference, 
rather than a solid, legitimate claim that the wg output "won't work" or 
"won't scale", then the obvious question is why it is tolerated.

The draft document on "discuss" criteria is a really good example of trying to 
focus on the primary and essential purpose of late-stage review.  But we also 
need to decide how to make early- and mid-stage work go better, and I keep 
thinking it has more to do with focusing on working group productivity than it 
does in having Area Directors operate as active technical contributors.

By way of example:  Having EKR get up on the MASS/DKIM BOF and hassle us about 
threat analysis is downright painful.  But my own experience is that looking 
at that sort of strategic value-proposition and resolving it in the early 
stage has a vast benefit to the rest of the project.  And working groups need 
assistance in constantly looking for those sorts of high-leverage questions to 
ask.

Now I have no doubt that EKR will perform the technical task of commenting on 
the wonderfulness of whatever threat analysis the DKIM group produces.  At 
that point, he's going to be acting as a technical contributor.  However, his 
pressing for the analysis to be done is process assistance.  He is raising a 
strategic question for the group to answer.
-- 
 
   d/

ps. Our cognizant AD, Russ Housely, has also been pressing us for the analysis 
but EKR was, as always, more visible and more theatrical. So he's far more fun 
to cite, even without the AD role...

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 9 Aug 2005 16:29:01 -0400

Dave,

	Your proposal presuppose an assumption that the best use of
our AD resource is as procedural and process assistant.  Certainly we
don't select for that in our current nomcom process --- and I would
argue that if what we are looking for is more assistance at the
working group level for project management and process management,
perhaps the answer is that we ought to find some sponsors who are
willing to hire some professional staff people to assist working
groups that are full-time process and procedural management experts.

	I would note that people who fill that roll do not necessarily
need to be a deep technical expert, and that if we devolve area
directors to being nothing but glorified project managers, we may have
trouble getting people to volunteer for that job.  

	I personally believe that the job that AD's are best suited
for is to provide technical leadership, and this goes far beyond
simply providing project and procedural management.  Not to say that
this isn't important --- I believe that it is critically important to
give that kind of resource to engineers trying to get a job done.  But
I believe that kind of role may be better suited to staff position,
and not a volunteer position.  (For example, I've noticed that it is
generally very hard for open source projects to find people willing to
volunteer to be a project manager; usually that role is filled by
someone on salary by an interested company.)

	Regards,

						- Ted

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Aug 2005 16:33:46 -0400

--On Tuesday, 09 August, 2005 12:04 -0700 Dave Crocker
<[email-masked]> wrote:

>> There seems to be a common perception that a major time sync
>> for the IESG is reviewing documents and writing up comments.
> 
> You've used the same word that I heard in the plenary, namely
> "reviewing". I'm thinking that it was well-chosen, but might
> be more complicated than it first seemed.
> 
> While it's good to hear that the basic act of reading and
> commenting is not necessarily the major time sink that one
> might have thought, perhaps the deeper problem is the
> difference between the role of facilitating IETF efforts
> versus the role of acting like a technical contributor.  That
> is, Process Assistant versus Technical Expert. Both tasks are
> difficult and both are usually necessary.  And the former also
> requires reasonably good technical skills.  But it is very
> different, indeed, from the latter.
 
> So perhaps the deeper issue with "reviewing" is that Area
> Directors might be spending too much time as technical
> contributors and not enough helping working group chairs and
> editors ensure timely, solid progress.
>...

Dave,

I think we agree, but parts of your argument and the distinction
you are trying to make confused me.  Let me try to make a
slightly different set of distinctions and see if we are
reasonably in agreement.  And let me try to state it extremely,
more extremely than may be plausible in practice.

The difference is less between "process assistant" and
"technical contributor" than it is about timing and issues of
reviewing/ approving one's own work:

Once a document appears for final "approval" review, if
difficulties are found with the specification, that indicates a
systemic failure.  That failure was described during the Problem
Statement work (including, I think, by you) as "late surprise".
But it is worse than that because such late surprises typically,
perhaps inevitably, turn the end game of the document approval
process into a negotiation between a WG that thought it was
finished and the IESG about what will be accepted.  That is,
under the best of circumstances, a lousy way to do
engineering... even when it is unavoidable.

If an AD, or a handy IAB member, walks into a WG meeting while a
document is still under development and says "this is going to
need to address the following issue or it is going nowhere", I
think that is great --and your example of EKR and Russ making
that sort of statement in and around a BOF is an excellent one".
But I would not condemn an AD who says, at a similarly early
stage, "please consider the following alternative, which I am
going to outline in technical detail".  While the substantive
difference is clear in some cases, in others, the line is very
faint... and not one that, IMO, appears to be worth trying to
make more precise.  After all, the ADs do have considerable
technical expertise and we should be anxious to take advantage
of it.   The differences between that type of early,
alternative-presenting, technical contribution and the variety
with which I, at least, have problems are, precisely, that many
of the current type come late and appear as "make me/us happy or
you will be stalled forever" commandments, not as alternatives
to be considered early on.

The second problem is that these "late surprises" cost us time
and, I believe, quality.  Whether the time-cost is in reviewing
documents or in the subsequent negotiation and iterations
(remember that, according to Bill's latest figures, 75% of
documents submitted to the IESG get at least one DISCUSS that
has to be sorted out, often without the quality of consideration
that would go with a WG including the relevant issues in its
normal development process.

And the third one is the case in which an AD is not _a_
contributor to the work of a WG, but becomes the (or a) primary
source of technical input to the WG.  The problem is, I think
obviously, much more severe if the AD input appears late (e.g.,
just before or after Last Call) than if there is more
opportunity for the WG to work out other solutions if
appropriate.  And the notion of an AD who has contributed
technically to a WG in some significant way then pushing back
during IESG review if the WG reaches some other conclusion is
pretty close to intolerable.  Changing the review model would,
presumably, clear that situation up in a hurry.

     john

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 09 Aug 2005 15:41:42 -0500

>trouble getting people to volunteer for that job.  
Hi, Ted,

(offlist) - the current NOMCOM chair posted to the IETF list that for 
two AD positions this cycle, there were only two candidates, and for a 
third position, there were only three.

Are you saying that we may not be able to get even that many candidates 
who are willing to serve, if we ask ADs to provide project management?

Spencer

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 9 Aug 2005 16:49:11 -0400

> who are willing to serve, if we ask ADs to provide project management?

If we forbid AD's from making any technical contributions, but to only
serve as process managers and as project managers and nothing more
than that?  Yeah, I would be concerned about whether we would be able
to find people willing to volunteer to do nothing but that.

It's like trying to find volunteers to write documentation for an
open-source project; the job is absolutely required --- and I'm not
disputing that this is an important role to fill --- but there are
some jobs for which you really need to hire specific talent to fill
that role, and not hope to find volunteers.  The problem is that
there's no glory in just writing documentation or being a process cop.
Granted, we don't want to choose our leaders from people whose only
motivation is to be a glory-hound, but we do need to take human
motivations into account.

					- Ted

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 09 Aug 2005 15:53:22 -0500

Spencer Dawkins wrote:

> Are you saying that we may not be able to get even that many 
> candidates who are willing to serve, if we ask ADs to provide project 
> management?
>
> Spencer 

Ted, my apologies - I did NOT trim the IETF mailing list from my 
addresses before sending the e-mail, and if I encouraged you to speak 
privately on the IETF mailing list, I'm sorry.

Spencer

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Aug 2005 16:55:06 -0400

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:

    Theodore> Dave, Your proposal presuppose an assumption that the
    Theodore> best use of our AD resource is as procedural and process
    Theodore> assistant.  Certainly we don't select for that in our
    Theodore> current nomcom process --- and I would argue that if
    Theodore> what we are looking for is more assistance at the
    Theodore> working group level for project management and process
    Theodore> management, perhaps the answer is that we ought to find
    Theodore> some sponsors who are willing to hire some professional
    Theodore> staff people to assist working groups that are full-time
    Theodore> process and procedural management experts.

I have to second Ted's comments.  I think one of the major benefits we
get from ADs is that they have broad technical understanding across
the IETF ; we should fine ways to use that expertise.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Aug 2005 16:55:52 -0400

>>>>> "Spencer" == Spencer Dawkins <[email-masked]> writes:

    Spencer> (offlist) - the current NOMCOM chair posted to the IETF
    Spencer> list that for two AD positions this cycle, there were
    Spencer> only two candidates, and for a third position, there were
    Spencer> only three.

    Spencer> Are you saying that we may not be able to get even that
    Spencer> many candidates who are willing to serve, if we ask ADs
    Spencer> to provide project management?

Yes.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2005 14:00:04 -0700

On Tue, 9 Aug 2005 16:49:11 -0400, Theodore Ts'o wrote:
>  If we forbid AD's from making any technical contributions

Oh boy...

To quote Harald:  sigh.

In difficult topics, certain things contribute to better communication and 
certain things contribute to worse.

So, Ted, please forgive me for using your posting to note a pattern, but I'm 
sufficiently tired of the very regular and usually hyperbole-filled pattern of 
misreading that happens in this realm, so that I feel the need to take explicit 
and forceful exception to it.

I did not say anything that bore any relationship to "forbid AD's from making 
any technical contributions." 

By way of saying what I said, but with different words:  

     I said that an AD has a job of doing project management and that doing 
other things -- however good at it the AD might be and however much more fun it 
might be -- often can and does take place IN LIEU OF doing that job, and that 
this failure has strategic cost to the productivity of the IETF.  Working groups 
usually need help being productive.  

     Having their cognizant AD provide technical contributions to the working 
group rarely, if ever, satisfies that need.  Having other ADs provide late-stage 
technical intervention also tends to be more counter-productive than productive, 
because their brilliant insight comes too damn late to be very helpful.

     The fact that there is an occasional exception and that the brilliant 
insight sometimes really is useful is being used to obscure just how wasteful it 
is, on the average.  

  d/
  ---
  Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Aug 2005 18:08:27 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave>      I said that an AD has a job of doing project management
    Dave> and that doing other things -- however good at it the AD
    Dave> might be and however much more fun it might be -- often can
    Dave> and does take place IN LIEU OF doing that job, and that this
    Dave> failure has strategic cost to the productivity of the IETF.
    Dave> Working groups usually need help being productive.

I actually think most ADs strike a reasonable balance on this area and
will continue to believe this untill I see significant data that
disagrees with my conclusion.  I will note that I am not as good at
striking this balance as some other ADs.

    Dave>      Having their cognizant AD provide technical
    Dave> contributions to the working group rarely, if ever,
    Dave> satisfies that need.  Having other ADs provide late-stage
    Dave> technical intervention also tends to be more
    Dave> counter-productive than productive, because their brilliant
    Dave> insight comes too damn late to be very helpful.

Strongly disagree.

    Dave>      The fact that there is an occasional exception and that
    Dave> the brilliant insight sometimes really is useful is being
    Dave> used to obscure just how wasteful it is, on the average.

Data please.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Aug 2005 16:37:57 -0700

> reviewing/ approving one's own work:

No doubt there is a productive line of consideration, using your factoring, 
but, no, it is quite different from mine.

Mine is about confusion of roles.  Yours is about timing.

What they probably most have in common is prioritization, in terms of wg need.

So, my disagreement with this characterization notwithstanding, I quite like 
the rest of your note.

Enough to elaborate on it...

> Statement work (including, I think, by you) as "late surprise".

Yes.  And it is interesting how little credence is given to that particular 
problem.  We are repeatedly demanded to produce statistics about it.  That it 
is in the Problem Statement document seems to be of little import.

> finished and the IESG about what will be accepted.  

Thank you for phrasing it this way.

It is difficult to imagine a much better approach to worker dis-incentive by 
"management" than the unpredictability of that part of our process and the 
sense of having been sucker-punched when having to go through the late-stage 
negotiation, especially when the worker-bees feel like they are mostly having 
to either educate the AD -- rather than fix actual problems -- or cater to the 
AD's personal whims.

And, as always, I now need to worry that such frank language will, as always, 
be taken as some sort of outrageous slap at the IESG.  It isn't.  It is simply 
an attempt at plain characterization of the view that occurs periodically 
among the worker bees, notably those who are at the core of the working group 
effort

>That is,

One could argue that it is very nearly always avoidable.  But, the irritating 
fact of life is that such an argument would require mathematical consistency 
in human behavior.  Since we ain't likely to get there, the problem is in 
agreeing that it SHOULD BE nearly always avoidable and therefore SHOULD BE 
treated as a powerful, unfortunate, but necessary tool.

Hence it should be used with surgically care.

And we are a very long way from getting THERE, though I hold out hope that the 
Discuss document will move us in the right direction.

> going to outline in technical detail". 

Me either.

Would that such gentle language were the way that alternatives were offered.

Would that such suggestions were made early in a design process rather than 
after months of effort.  (Yes, you said early, but there is quite a bit of 
distance between "after months of effort" and what we usually call late-stage, 
namely Last Call.  I simply want to stress that every day later such 
suggestions are made, the more damaging to working group morale and productivity.)

>   After all, the ADs do have considerable
> of it.  

You know, as much as we all make a point of saying this, and as much as it is 
true, there is a minor problem that shows itself too often to ignore and it 
comes in two forms:

1. For many topics, no one is really an expert, or at the least, there are 
others in the wg with at least the AD's level of expertise.  Hence, an AD's 
views are important, but it is not necessarily appropriate to give their views 
more weight than those of others.  (This is why I consider an AD's expertise 
best used at recruiting support to reach rough consensus, rather than in its 
more typical current use as a veto or point of personal negotiating leverage.)

2. ADs have the usual human frailty of often not knowing their limitations. 
That can lead to strongly voiced views that are just plain wrong.

Not surprisingly, #1 and #2 occasionally combine.

And isn't THAT fun?

> normal development process.

Good point, nicely made.

> source of technical input to the WG. 

I am having trouble parsing this.

How can one be a/the primary source without being a contributor?

> And the notion of an AD who has contributed
> pretty close to intolerable.  

It is worse than that.  Even if the AD keeps their mouth (and fingers) 
entirely silent during IESG considerations, they will have held undue 
influence over the process, if they make substantial technical contribution 
AND are the cognizant AD.

The term "conflict of interest" has its definition precisely in the danger 
that comes from this sort of confusion of roles.

But that's really for a different discussion thread...

-- 
 
   d/

  Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Aug 2005 20:24:49 -0400

--On Tuesday, 09 August, 2005 16:37 -0700 Dave Crocker
<[email-masked]> wrote:

>> contributor to the work of a WG, but becomes the (or a)
>> primary source of technical input to the WG. 
> 

I intended to say something like "...in which an AD is not
simply one contributor among several other contributors to the
work for the WG, but, instead, takes the lead role within the WG
of providing technical input.

> It is worse than that.  Even if the AD keeps their mouth (and
> fingers) entirely silent during IESG considerations, they will
> have held undue influence over the process, if they make
> substantial technical contribution AND are the cognizant AD.

Yes, of course.
 
> The term "conflict of interest" has its definition precisely
> in the danger that comes from this sort of confusion of roles.
> 

Indeed.  And, in our environment, I suggest that one can have a
serious conflict or roles and relationships without meeting the
usual tests for a conflict of interest.  In terms of impact on
the standards process, there is, of course, no practical
difference between the two cases.

     john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2005 17:53:47 -0700

>  I intended to say something like "...in which an AD is not simply one
>  contributor among several other contributors to the work for the WG, but,
>  instead, takes the lead role within the WG of providing technical input.

ahh.  tnx.

> >  influence over the process, if they make substantial technical
> >  contribution AND are the cognizant AD.
>
>  Yes, of course.

Would that the "of course" reflected a consensus view on the current IESG, but 
apparently it does not, based on a recent exchange I had with them.  Quite 
surprising, really.

> >  The term "conflict of interest" has its definition precisely in the
> >  danger that comes from this sort of confusion of roles.
> >
>  Indeed.  And, in our environment, I suggest that one can have a serious
>  conflict or roles and relationships without meeting the usual tests for a
>  conflict of interest.  In terms of impact on the standards process, there
>  is, of course, no practical difference between the two cases.

We are so used to thinking of "conflict of interest" as involving greed or an 
equivalent, reprehensible self-interest, but it needn't.  

Conflicting ideals are, all the same, conflicts of interest.

  d/
  ---
  Dave Crocker

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 09 Aug 2005 21:20:05 -0400

>to find people willing to volunteer to do nothing but that.

I can guarantee that if my primary responsibility when I was Security 
AD was process and project management, there's no way I'd ever have 
taken the position.  Rather, I was willing to serve because it was a 
way in which I could have more leverage as a security specialist.  

I should add that an AD has to walk a very fine line in making 
technical contributions; such contributions are often taken as having 
far greater weight than they should, because of the obvious possibility 
of a DISCUSS later on.  Every AD knows this, of course -- how often 
have you seen a comment prefaced by "AD hat off" or equivalent?

Let me give a concrete example.  At one point in the development of 
AAA, there was a lot of discussion about the need for proxies.  Now, 
from a security perspective I think proxies are a bad idea, for reasons 
I outlined in my plenary talk.  But I had to be very circumspect in how 
I said this in the WG -- the issue was by no means clear-cut enough 
that I felt entitled to force the issue with the threat, implicit or 
explicit, of a DISCUSS.  

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 10 Aug 2005 10:06:26 +0200

> presumably, clear that situation up in a hurry.

Only if it does more than just replace "AD" with "reviewer" in the above 
sentence.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Aug 2005 15:40:28 +0200

Dave Crocker wrote:
...
> process and project management difficulties, leading to the obvious 
> question of what happened in the earlier stage?
> 
> Having a non-cognizant AD press late-stage issues leads to the question 
> of why they did not pay attention earlier?  If the topic is important 
> enough for them to delay the wg output now, why was it not important 
> enough earlier?  

It seems to me that the *primary* responsibility for ensuring that
the WG considers everything it should consider, at an early enough
stage, lies with the WG Chair(s).

Certainly, the AD has an oversight and mentoring role here,
especially for first-time WG Chairs, but your obvious question
should be directed first to the WG Chair(s) and only second to
the ADs.

I don't mean the ADs have no duties in this area - but they
can't be everywhere at once and read every email.

     Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Aug 2005 09:49:36 -0400

>>>>> "Harald" == Harald Tveit Alvestrand <[email-masked]> writes:

    Harald> --On tirsdag, august 09, 2005 16:33:46 -0400 John C
    Harald> Klensin
    Harald> <[email-masked]> wrote:

    >> And the notion of an AD who has contributed technically to a WG
    >> in some significant way then pushing back during IESG review if
    >> the WG reaches some other conclusion is pretty close to
    >> intolerable.  Changing the review model would, presumably,
    >> clear that situation up in a hurry.

    Harald> Only if it does more than just replace "AD" with
    Harald> "reviewer" in the above sentence.

Another point.  I think that John needs to do a bit more work
explaining when this situation is intolerable.  I have no doubt there
are cases where it would be bad.  However I'm also thinking of cases
where it is reasonable.

Consider the following situation.  An AD tells a working group that
some particular problem must be solved.  The AD proposes a solution as
an individual and advocates for the solution.  The working group
decides to do something else that doesn't actually solve the problem.
It seems both reasonable and necessary for the AD to apply pushback.q

I'm becoming increasingly convinced that there is not a shared
understanding in the community about what is rereasonable and what
would be a conflict of interest.

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Aug 2005 07:22:06 -0700

> should be directed first to the WG Chair(s) and only second to

Brian,

We are talking about the IESG.  So that is what is being commented on.

We can always expand or redirect the scope of the discussion, with the 
predictable effect that it takes the focus off changes in IESG 
responsibilities and activities.  But that won't be productive.

For example, I could easily respond that the *primary* responsibility for 
ensuring that the wg considers everything it should consider lies with wg 
members.  Going down that path would ensure that we never really discuss 
anything about the IESG.  However I would rather look for productive changes 
that can be made in IETF management practises, since it is quite clear that 
SOME changes are needed and we have already spent some years NOT making them...

So, let's stay with the focus of this thread, shall we?

"Certainly, the AD has an oversight and mentoring role here?" captures the 
issue quite nicely.  It is an AD's trade-off between the role as individual 
technical contributor and the role of working group facilitator that I was 
highlighting.

My point is that the AD's primary responsibility is to focus on that oversight 
and mentoring.

d/

ps. I would argue, therefore, that Steve Bellovin's posting about carefully 
contributing to the AAA working group on the problems of proxies was, in fact, 
exactly this sort of strategic management mentoring.  Yes, he viewed it as 
technical contribution because, of course, it was. However he talked about the 
carefulness required in pursuing it and, of course, the strategic reasons 
proxies are a bad idea.  THAT is oversight and mentoring.

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Aug 2005 10:56:03 -0400

--On Wednesday, 10 August, 2005 09:49 -0400 Sam Hartman
<[email-masked]> wrote:

> explaining when this situation is intolerable.  I have no
> doubt there are cases where it would be bad.  However I'm also
> thinking of cases where it is reasonable.

Perhaps we can make some progress by examining each other's
examples.  I don't think that we are likely to find a single
bright line.

> Consider the following situation.  An AD tells a working group
> that some particular problem must be solved.  The AD proposes
> a solution as an individual and advocates for the solution.
> The working group decides to do something else that doesn't
> actually solve the problem. It seems both reasonable and
> necessary for the AD to apply pushback.

>From my perspective, two things are getting mixed up here, and
that is probably why my comment isn't obvious to you.  Steve
Bellovin's example is, I believe, helpful here.   But perhaps we
can think about some cases that fill in after "the working group
decides to do something else"...

(1) The problem is clear and real, and the working group decides
to do something that clearly and obviously doesn't solve the
problem.

	It is entirely reasonable for the AD to push back on the
	"doesn't solve the problem" issue.  If the AD's proposal
	does solve the problem _and_ there are no other
	problem-solving solutions on the table, it is reasonable
	for the AD to remind the WG of that proposed solution.
	But the AD is on very thin ice if things are said to the
	WG that sound even vaguely like "no solution other than
	mine is going to be accepted".

(2) The WG has examined the purported problem and there is a
disagreement between the AD and the WG as to whether the problem
is significant.

	We have a gray area.  It gets appreciably more
	gray if the AD is also pushing a particular solution to
	the alleged problem.

(3) The WG agrees that there was a problem, but has fixed it
with a solution other than the one originally suggested by the
AD.  The AD continues to insist on his or her own solution. 

	This is the case that I believe is intolerable,
	certainly so unless the AD can clearly and publicly
	document the reasons why the WG's solution is inadequate
	and the AD-proposed solution is far superior.

There are other cases, but I believe the above group illustrates
the distinctions.

> understanding in the community about what is rereasonable and
> what would be a conflict of interest.

I agree.
   john

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 10 Aug 2005 12:07:22 -0400

On Tue, Aug 09, 2005 at 02:00:04PM -0700, Dave Crocker wrote: 
> So, Ted, please forgive me for using your posting to note a pattern,
> but I'm sufficiently tired of the very regular and usually
> hyperbole-filled pattern of misreading that happens in this realm,
> so that I feel the need to take explicit and forceful exception to
> it.
> 
> I did not say anything that bore any relationship to "forbid AD's
> from making any technical contributions."

No you didn't; and I apologize if I took a took your position to a
more extreme position than one you were advocating.

HOWEVER, it does seem that you seem to believe that the _primary_
responsibility of an AD is as a project manager and a process
manager/cop.  This would be particularly true if the document review
responsibility is taken away from the AD's, and if an AD is strongly
discouraged from offering their technical experitse as anything other
than "just another joe IETF member", lest they put undue stress on the
process.  

If that is the case, then it may be that it may be very difficult to
find volunteers willing to do what is, quite frankly, scut work.  It
may be utterly necessary work --- like writing technical documentation
or raking out the muck from a horse stable.  But that doesn't
necessarily mean that we will be successful finding volunteers to do
that work.

So if we do that, it may make sense to make the job of being a project
manager and process maven to be that of a staff position.  Some
standards organization do work that way, and it's not necessarily a
bad way of doing business.  It certainly isn't the way we are doing
business today; whether or not it is better seems in my mind to be
debateable.

If that's not what you wanted to advocate, perhaps it would be helpful
if you were to offer some concrete examples of what would be part of
the AD's job in your ideal universe, and what would _not_ be part of
the AD's job in your ideal universe, and what AD's do today that you
feel should result in their being bopped on the nose with a newspaper?

						- Ted

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Aug 2005 09:36:41 -0700

> manager/cop.  

Yes...

RFC 2026, The Internet Standards Process -- Revision 3:
> 14. DEFINITIONS OF TERMS
...
>    Area Director - The manager of an IETF Area.  The Area Directors
>       along with the IETF Chair comprise the Internet Engineering
>       Steering Group (IESG).

Hmmm.  Manager.

And the label is used alone.  No other descriptive word is used.  Nothing 
about technical contribution.

RFC 2418, IETF Working Group Guidelines and Procedures:
> 6.7. Area Director
> 
>    Area Directors are responsible for ensuring that working groups in
>    their area produce coherent, coordinated, architecturally consistent
>    and timely output as a contribution to the overall results of the
>    IETF.

"Coherent, coordinated and timely" are explicitly management tasks.  As i 
noted about Steve Bellovin's AAA reference, there is a strong component of 
"architecturally consistent" that also is management, when the task is done 
properly in the way he described.

> find volunteers willing to do what is, quite frankly, scut work. 

There was no difficulty finding volunteers when area directors had literally 
NO authority, pre-Kobe.

I guess the quality of AD was lower then, as was the quality of IETF output. 
In terms of sampling, clearly such people are no longer prevalent in the IETF...

> manager and process maven to be that of a staff position.

Yes, it is appealing to believe that the task can be routinized to be 
performed by someone with no knowledge of the technical specialties.

But it can't.

> the AD's job in your ideal universe, and what would _not_ be part of

And here's where my frustration kicks in, since I have posted concrete 
examples pretty constantly over the last 3 years.  And, no, I'm not going to 
retrieve them from the archive.

d/

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 10 Aug 2005 12:45:30 -0500

Dear All,

I don't mean to chime in here, but if we can agree that nobody is asking 
ADs to be only process mavens, and nobody is asking ADs to refrain from 
making technical contributions, we could probably make some progress.

I've worked for plenty of managers with technical skills. Some were 
coinventors on patent applications. We still did a budget every year, 
and we still had a plan with milestones that we worked to meet. Whatever 
else the Manager of an IETF Area does, they need to at least manage the 
working groups in that area - that's how I read 2026/2418.

Spencer, who is NOT planning to propose a terminology change to call 
them "Pointy-Haired Area Directors"...

Dave Crocker wrote:

> And the label is used alone.  No other descriptive word is used.  
> Nothing about technical contribution.
>
>
> "Coherent, coordinated and timely" are explicitly management tasks.  
> As i noted about Steve Bellovin's AAA reference, there is a strong 
> component of "architecturally consistent" that also is management, 
> when the task is done properly in the way he described.