> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf