ietf
[Top] [All Lists]

Re: Looking for Area Directors Under Lampposts

2015-11-12 18:22:38
John,
On 13/11/2015 10:31, John C Klensin wrote:

...
A quick search suggests that the last formal proposal along the
lines outlined in my earlier note was
draft-klensin-stds-review-panel-00 somewhat over a decade ago.
There was some interest on the IETF list, but it rapidly became
clear that no one of the IESG was interested in considering it.

Memory fades, but I think the reality was not an absence of any interest
(I was interested, for one). However, there was evidently no consensus
(however rough) in the IESG to consider it. It was certainly a topic at
IETF 63 (Paris) in the IESG meeting and in plenary, and it subsequently
came up on the poisson and pesci lists. But as General AD at the time,
I didn't get the sense that there was enough support in the community to
sponsor it. Maybe that was a misjudgement, of course.

(more below...)

I note however that may process-improvement and
workload-reduction from that general period also died after it
became clear there was no IESG interest.  They include at least
two workload-bounding or productivity-enhancing proposals:
      draft-huston-ietf-pact
      draft-klensin-overload

several proposals to rework the way process change proposals are
handled (the only one I can find easily was a reductio ad
absurdum strawman in draft-klensin-process-planb but my
recollection was that I was motivated to write it after an
extended and heated discussion in plenaries and/or the IETF list.

The other bit of context that is relevant to this (and to my
assertion) was the collapse of the Newtrk WG work.  Different
people have different interpretations but my version is that the
WG managed to reach consensus on some fairly significant
documentation and standards track changes.  The IESG considered
those changes, decided they were unworkable and unacceptable,
and rejected them by refusing to initiate an IETF Last Call.
Since that time, I believe there has not been a single process
change proposal approved, or even subjected to IETF Last Call,
unless it was initiated from within the IESG (typically with one
or more AD authors).  Even the relatively modest proposal to
assign STD numbers at Proposed Standard time
(draft-klensin-std-numbers) could not get considered.

Would that have changed had any of these proposals been exciting
to create outrange on the IETF list or set off some sort of food
fight?  I don't know.  I suspect not, largely because of how
demoralized the parts of the community who believe that some
process evolution would be healthy because after the Newtrk
problem, but YMMD.

I'm not asking to try to catch you out btw, but first
I've no idea how the IESG could prevent the community
considering stuff,

See above.  There is no point in spending time "considering"
anything, or even writing it up, if it appear clear that the
IESG would decline to issue a Last Call (at least in the absence
of rabble-rousing, coummunity outrage, and/or threats of
recalls).

John is right. But in fairness to the 2005/2007 IESGs, it wasn't
that people denied there was a problem. It was an absence of rough
consensus around even the general type of solution. So the chance
of getting the newtrk documents through the IESG was extremely low.

If there's a lesson, it's that getting enough of the community involved
to override such a roadblock in the IESG is the key - and a WG like
newtrk, or the ad hoc pesci list that I set up, couldn't do that.

    Brian

and second, whilst I've been on the
IESG I really don't think anyone who served would've
taken that stance. (An IESG might be able to stall
stuff, but not prevent consideration.)

I can't remember how long you have been on the IESG but am quite
willing to believe that the current IESG would be more disposed
to encourage community debate and consensus development on a
proposal it disliked or that limited its authority than some of
its predecessors have been.  If anyone wants to try the
experiment, a few of the drafts cited above could be updated
with little trouble to make them contemporary.

As to the broader topic, the IESG has spent some time
on considering the whole AD workload thing and we did
not manage to reach consensus on anything that looked
like it'd really work out as a general solution. (Efforts
continue but more on a per-area basis at the moment.)

I think that summary could be equally well applied to (typically
informal) discussions that have occurred at irregular intervals
in the last 20 years.

One conclusion I've reached as a result is that that
also reflects the lack of consensus in the broader
community as to what they want the IESG to do or not
do. Absent such a consensus, I doubt that we'll find
this discussion that productive, though I'd love to be
wrong there.

I actually agree with that, which is precisely the reason I've
tried (as have others) to get community discussion going on
goals and options.  However, I more or less gave up after
several of the documents cited above and some related
discussions.  Time for someone younger and who is trying less
hard to not care to take over.

I also suspect that absent such a consensus the IESG
will inexorably end up more of a non-technical management
and bureaucratic body that slowly but surely takes on more
work and makes itself bigger. If that's true, then the
lack of community consensus to figure this out is also
a sort of decision, though not one many of us would like
(I hope).

Although it saddens me, I agree with that as well.  If nothing
else, observations in other standards bodies --bodies whose path
the IETF seems to be charging down-- strongly suggest that
traditional organizational patterns apply: workload will expand
to fill available cycles and more, membership will shift toward
those who have the time (largely because of good support and
limited "day job" commitments or day jobs that are primarily
standards-oriented), that shift will accelerate the workload
increase, and technical expertise will be squeezed out because
good technical people are too valuable to be dedicated to that
sort of bureaucracy and management outside their own
organizations.  There will always be individual exceptions (at
least until the patterns grinds those people down and out) but,
as a general pattern... I've seen it too many times outside the
IETF and the "inside" patterns seem clear.

best,
    john