Brian, > First point - I unaccountably forget to mention that we agreed on and > published an IETF Mission Statement (RFC 3935). That was a direct response > to the first "root problem" described in RFC 3774. Do you believe that that document will meaningfully contribute to the IETF's producing documents that are more timely and relevent and have better quality? If so, it would be enlightening to hear how and in what timeframe. > If people would stop submitting drafts for publication and > sending technical email, I might get a chance to do so. But actually, I do > prefer to give priority to the IETF's work product rather than to metawork. I suspect that it is not obvious to folks just how significant your comment is. It translates into: "Senior IETF management cannot devote much energy to fixing its strategic timeliness, relevance and quality issues, because it is too busy attending to the daily tactics of process that we agree are deficient in producing timely, relevant documents of high quality." And, yes, I know you don't mean that, but in fact that is the reality your statement reflects. FWIW, it is a classic dilemma in organizations' efforts to remedy strategic problems, since most organizations feel the press of daily deliverables. > > It does not affect quality or relevance. And it does not do much about > > timeliness, in terms of making working groups go faster, reducing > > inappropriateintentional blocks by ADs, or any of the things that are > > the meat of IETF work. > > I disagree. Removing artefacts makes it much easier to look at essentials. Brian, it has been about 3 years since the IETF acknowledged it had a crisis. Are we focusing any better on the essentials now? I think we are focusing less. When do you project that this will change? Fixing mechanical details definitely makes life easier. No doubt about it. But it is folly to think that any of that is really going to get us to focus on essentials more, at some indefinite time in the future. Mechanical details do not get working groups to focus better, consult experts better, or produce better documents more quickly. Really, they don't. Mechanical details do not get ADs to take a more facilitative stance. Really, they don't. > Even late reviews can improve quality, and speaking for myself, their > availability makes it much less likely that I will defer a ballot, so they > improve timeliness. The key word you used is "can". Unfortunately, an one-time (or rare) demonstration of an existence proof for utility is not enough. These processes are expensive. If they do not have regular, substantial benefit, we should be spending our process dollars elsewhere. If we turn out better documents as a result of normal processes, we will not need late-stage reviews because the benefits will have been realized sooner (and probably better and cheaper.) >I'm not really sure on balance what you mean by > relevance. Relevance to what? Judged by who? The IETF turns out a lot of documents. We do not pay much attention to their long-term utility. There is a general sense that the percentage of our output that is useful has gone down dramatically. That means our work is far less relevant. An excellent spec that is too late for the market is not relevant. A spec that provides for a mechanism that is too cumbersome to administer is not relevant. And so on. > > > But I, Dave and ICAR blew the early review issue so far.) .... > I think the answer will be baby steps - even with ICAR's modest goals, it > seemed that we couldn't achieve liftoff. The IESG is thinking about one > baby step (pls wait until the notes from our retreat come out). It really is facinating just how quickly you seem willing to give up on efforts like this. As I've noted in a separate posting earlier, we spend the better part of a decade nursing along failed specification efforts, but we seem to give these sorts of strategic change efforts about 3 months to succeed. Ok, maybe 6... > > > Regular reviews of RFC Editor and IANA performance in place... New > > > procedures for liaison handling defined... Administrative support > > > unit being created by ISOC... > > And you think these affect core issues of IETF utility to the Internet > > community? > Yes. The fact that we are slow in getting RFCs out or in making routine > parameter assignments is damaging to the IETF because it makes our users > (implementers and other standards bodies) unhappy. Efficient handling of > liaisons from other bodies is also very important lubrication for the > whole community. And the admin support is tremendously important - partly > to make sure that meetings, mailing lists and document approvals continue > to happen, and partly to free up enough time for *me* to do my job as > Chair and worry about the things you want me to worry about. My personal > estimate is that about 50% of the issues on my current issues list will be > handed off to the IAD when (s)he is up and running. Brian, I have no doubt that these are all perfectly reasonable to make better. But do you have any basis for saying that problems with ANY of these issues has created a pattern of delay in producing specifications or produced worse specifications or produced specifications that were less relevant to the community? What I am suggesting, here, is that you are focusing on a myriad of details that are, in fact, of tactical importance to the survival of the IETF, not of strategic importance. Tactics are of course significant. But not in the absence of serious efforts to fix deep, strategic problems. > > Brian, we need to distinguish activity from progress. > > > Now there's a truism. and since we all know that, it's probably worth thinking about my choosing to express it at this juncture. 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