The problem is that the IESG, in reality, treats these deadlines as
optional.
When there's no limit on the amount of work that can be imposed on IESG
from external sources, treating such deadlines as optional (or at least
relaxing them) is common sense.
This is a very good example of the approach that many folks have taken, in
thinking about these problems. It is really pretty amazing, given the nature
and history of this community. It is not immodest to assert that we are a
community of relatively self-actualized participants, with a considerable
history of solving difficult protocol (process) problems. Yet in the matter
of solving serious deficiencies in our organizational processes, we shrug and
give up, rather than look for changes that solve the bottlenecks, improve
quality and retain the underlying culture of the original IETF process.
For example, as you note, the IESG approves working groups and working group
charters. So the IESG does, in fact, have the ability to control the later
demand placed on it.
Another example is the kind of mission creep that John Klensin noted. The
IESG review is supposed to be for some vary narrow purposes, but the scope has
greatly expanded.
A policy that creates an expectation that an individual submission will
be published and receive the implicit endorsement of IETF (disclaimers
to the contrary notwithstanding), taking up resources from the RFC
Editor and/or IESG, is even sillier. Or at best anachronistic.
Many of these problems derive from the IESG believing that it is solely
capable of being responsible for doing all the reviews for all documents. The
official scope of the IESG review of non standards-track individual
submissions is supposed to be pretty darned limited. Equally, the reasonable
scope of the IESG for work that is from an experienced working group
reasonably ought to be limited.
If one reviews the IETF mailing list postings, there is a extremely
consistent pattern of responses from the IESG.
Every proposal for any change that might, in any way, affect its
authority, is dismissed quickly and completely. And these dismissals
tend to be based, at best, on very weak conjectures about possible
human behaviors, and without any attention to the downside of keeping
things the way they are.
So we have a process that isn't working.
We have at least 3 years in which the community forcefully sounded the
the alarm.
Yet we have no changes that make our output more timely, relevant and
useful.
Working groups need to do work that is more relevant, focused and
timely to current Internet needs.
The IESG needs to be more timely and constructive in helping working
groups achieve these improvements.
The usual reference to fear of releasing bad specifications onto the
net nicely ignores the dangers of releasing no specifications, or of
having the specifications get developed elsewhere.
Yet these latter outcomes are what is happening.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf