Ted, I finding myself agreeing with you in many ways, but probably for different reasons. I'm trying to better formulate the differences instead of (or at least before) posting something incoherent, but, in the meantime... --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie <hardie@xxxxxxxxxxxx> wrote: > At 2:28 PM -0700 9/16/05, Dave Crocker wrote: >> >> And since all other public development efforts for process >> change have frankly fallen flat, as Brian has cited, what is >> your basis for believing that a working group charter will >> somehow make yet-another public process more effective at >> developing a specification for change? > > Possibly I'm wrong in this, but I believe that the public > process works when the community cares about the outcome. The > IASA work is done, and I believe it is a success because > enough people cared about the outcome to make it one. I think there are two conditions. The first is caring and the second is a very narrow and specific focus, with serious thought and debate going into that focus. There were good things about the AdminRest->IASA process and bad things about it, but there was a clearly-defined problem to be solved and a process that produced a solution. Dave believes, I think, that, as it worked out, it was the wrong problem to be solving at the time and I'm at least sympathetic to that view, but that doesn't change the properties of "fairly well-defined problem, fairly well-defined solution space, mechanisms that were fairly open at critical times (although, IMO, not nearly open enough at others). In that regard, I see the difference between, e.g., IPR and Poisson as being the difference between creating a WG with a very specific focus and problem to be solved and creating a more or less standing WG and telling them to look at Process issues, figure out what needs to be done, and do it. As we could all predict from our experience with technical/engineering WGs with narrow and well-understood scope versus those that are expected to figure out what the problem is before trying to solve it, IPR was productive while Poisson spent a lot of time in the weeds. In that context, part of what concerns me about the PESCI idea is that the is no clear problem definition. If there were a clear and concise problem definition on which there was obvious community consensus, I wouldn't worry much about the committee -- the problem definition would provide a good platform from which to evaluate success. If it were a spontaneously-occurring design team in which a few colleagues got together to sort out a problem and generate a proposal that would be treated as an individual submission with not more authority than any other such submission, I wouldn't worry about it: as Dave points out, some of our best work comes out of such teams. But this one appears to represent neither of those cases. But this is neither of those cases. Instead, either the problem area is open-ended or there are ideas that will steer it that Brian has not made public (I assume from his note that it is the first). The group isn't going to be spontaneous, it is going to be hand-picked by the IETF Chair and presided over by him and that will give it and its product a certain level of authority. There is also actually a difference between "sufficient people who care to do the work" and "a sufficient number of experienced and relevant people in the community who care and are involved enough to be sure the work is right". That, to me, is the area of greatest difference between process WGs and engineering/ specification ones: with the latter, most of the people who get in there and do serious work are directly involved with the quality of the outcome (whether they do well or not is a separate matter). Process WGs tend to draw a disproportionate number of people who are interested in and care about process but who are not otherwise significantly contributing to the IETF's technical work. So... > As I said at the beginning of this thread, I believe using > PESCI to scope the work and develop support for is fine. I'm even concerned about that for the reasons above. Agenda-setting is an important part of the process and the historical observations about the importance of being the party who picks the battlefield or moves first are relevant. If the group were to be chosen via a more open process, including some "advice and consent" by, e.g., the IESG or IAB or Nomcom, than Brian apparently contemplates, I'd feel better about it. But... > I'm > deeply concerned, however, about it doing the development work > itself, as a process in which selected volunteers replace the > public work of those who will use the outcome. While we agree, I think, about the risks of the "selected volunteers" part, I'm not sure whether we agree or not on the rest of the sentence. If, by "public work of those who will use the outcome" you intend to suggest a process that is controlled by the IESG, I don't think that works either. The current IESG was chosen, successfully or not, in line with the current procedural model and it and its predecessors defined the way in which that model is interpreted and used. That selection process should not bias the outcome of the development process toward one with which the IESG is comfortable. IESG input is, IMO, very important about what is workable or not and why. But, if we are going to redesign procedures, I think there has to be a realistic possibility to making procedures that work for the community and then selecting an IESG (or its successor) to match, rather than selecting procedures on the basis of a good fit to the current IESG. best, john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf