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
>
>
>