Pete Resnick wrote: ... > On 5/3/13 7:59 AM, Thomas Narten wrote: > > > Like everyone, I wish things moved more quickly, but every attempt > > I've ever seen that tries to speed things up ends up reducing the > > quality or having some other undesirable side effect. > > > > Can you talk a bit more about this, including some examples? > > I'm trying to reconcile the concern that we "end up reducing the quality" and > that we "NOT neglect longer-term stuff that will have real and significant, but > not immediate benefits." ADs have finite resources and can't accomplish > both immediate and longer-term stuff maximally all of the time. My > inclination would be to say, "If they are in conflict, weight the longer-term > over the immediate, even if that might result in some reducing of quality on > any single document." Am I over-reading your earlier message to say that > you think the weighting should go toward the immediate? I think we agree > that doing the longer-term stuff will end up with increased quality over the > long term, but doing more of the longer-term stuff is sure to reduce the > amount of time spent on immediate, which means document reviews and > therefore some short term lowering of quality. Is that OK, or is that an > example of the kind of thing we've attempted that ends up with bad results? > Pete, I would agree with you that weighting longer term is the 'right thing', but given that people wait for an RFC number to implement, and then take the position that RFC (PS) == STD, you never get to the longer term because the bar is set so high on the first hurdle that it becomes impossible for people to justify the effort to go for the next one. When the I-D series was introduced specifically to deal with the issue of RFC == STD, we didn't get it right. In hind sight we should have done something more like the IEEE does with 802.11, and explicitly put a big DRAFT: in the title. Industry doesn't seem to get confused about DRAFT: N or DRAFT: AC, and still deploys, then moves on with full standards. We could still do that, and likely get motivation to move a DRAFT: to PS (remove the DRAFT: from the title) by wider review and deployment. I realize this is really doing nothing more than introducing an extra step in the process, but in some ways it is more of a formalization of the expected behavior at the first RFC step. One could go so far as to not remove DRAFT: until the spec met DS, and move the default from PS to DS at the same time as removing the extra step from the process. One could really get crazy and just remove DS from the list, because nobody understands what that one is for anyway, and then when the DRAFT: gets removed from the title it is really the STD people are expecting ... ;) In any case I don't see 60/40 as a tail-heavy process. If the WG time were cut in half and the IESG/RFC-editor time stayed the same, maybe it would be tail-heavy, but realistically more 'balanced'. At the end of the day, the only way to reduce the time at IESG review is to have a document with clear objectives up front that the document can be evaluated against, and for the WG to put a quality document in their hands. Too often the WG takes so long that the objectives drift, if they were even clearly stated up front, and comments like "you have to have been involved in the mail thread" show up during review. If something is not clear in the document, and it was cleared up in a meeting or on the mail list, that clarification needs to get moved into the document or subsequent reviewers / implementers will never get it, and the result is delay and/or poor quality documents. Tony