Pete Resnick wrote: > Not disagreeing with your message, but a couple of clarifying points: > > On 5/3/13 12:41 PM, Tony Hain wrote: > > > 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 Thomas said "longer-term", I took him to mean *all* of the things that > are longer time horizon, like management/mentoring of WGs and chairs, > doing more early cross-area participation (including by ADs) in the design of > and work on protocols (not just review), etc. In particular, I didn't understand > him to mean longer-term as having anything to do with advancement on the > standards track. I think the above longer-term goals are important. I think > movement along the standards track will be the outcome if we get to > working well, but not a goal in-and-of itself. I actually view all of the housekeeping activities as short term. Thomas will have to state what he meant. > > > 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'. > > > > I'll point you to Jari's excellent reminder that "time" is probably the least of > the heaviness on the tail end. What is tail heavy is the work > investment: We do WG last call reviews, IETF-wide Last Call reviews, > directorate reviews, IESG reviews, all at the end of the process. We spend > scant little energy (of the wider IETF community and leadership) on early > design reviews and protocol development early and in the middle of the > document process. As Jari said, that model ends us up with late surprises, > lack of transparency, etc., and probably uses much more energy overall than > if we invested it earlier in the process. Sure, this can translate to delays, but > that's only one (maybe minor) effect of being tail-heavy. While I agree that it would appear to be a heavy workload, that is just because it is concentrated enough to see. If you actually did all the work across all the participants to review every document at every iteration, nothing would get done. Even when the IETF was ~60 people creating a few documents a year, reviews happened late, and changes were made. Yes earlier comments from outside the WG will reduce overall surprise and workload, but finding the right reviewers is tricky. One could require that every BOF be presented to every Open Area meeting, then required public comment from every other AD before being allowed to form a WG. This would front load the review and raise general awareness about what is being discussed. Unfortunately since that event and resulting documents are half a decade apart, potential reviewers have long since forgotten any concerns they might have had, and need to start fresh anyway. For long standing WGs one could consider doing the same at every charter change, but again, document movement within the WG needs to be faster for any of that to matter. The only way I can see to reduce the time from BOF to RFC is to reduce the public expectation on the quality of that initial document which will get wide review and initial implementation. We should be talking about ~ 3 years to get to STD, not the initial draft that gets review beyond the WG. In practice what we have today is functionally STD at initial publication, so there is a very concentrated effort at one point in time. If the process to get from WG I-D to initial RFC was basically a sanity-check, the detailed IESG and cross-area review could be spread out during implementation prior to the update that removed the DRAFT: status. Realistically though, human nature would take over and nothing would happen until the WG tried to take that step and we would be having the same discussion about tail work load. Bottom line, we need a signal to other areas that a WG document is ready for serious in depth review, and a document title change seems to be what people are looking for. At the same time WGs need to do a better job of spreading awareness earlier in the process to get comments from those that have different perspectives, then actually listen to them during document development. Surprise comes from being isolated, and/or shouting down voices that later come back during review to highlight flaws. If the process to get to DRAFT: status was less burdensome, documents would move more quickly and less effort would have gone into the flawed document before it got seriously reviewed. Tony