--On Thursday, November 12, 2015 19:44 +0000 Stephen Farrell
<stephen.farrell@xxxxxxxxx> wrote:
>
> John,
>
> On 12/11/15 19:16, John C Klensin wrote:
>> No IESG that was seated when the suggestions came up has
>> been willing to let the community consider them.
>
> Can you point at something to back that up?
Keep in mind that a proposal for process change is dead in the
water unless someone on the IESG decides to take it up as an
individual submission or there is a discussion about starting a
WG (also effectively impossible, especially if a BOF is
required, without support from within the IESG. Decisions to
initiate an IETF Last Call are also completely within the IESG"s
discretion -- I suppose one could appeal a decision to not
initial a Last Call, but that has, at least according to my
memory, never been attempted.
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.
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).
> 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