I do not really have time or desire to enter an extended discussion on this document. It's pretty clear to me we just disagree. But I did want to be on record as not supporting this document so that silence wouldn't be taken as agreement or support. A few specific followups below. > > This document seems to have a bit of missing the forest for the > > trees. In the overall scheme of things, I don't believe the draft will > > materially help, and is at best a distraction from dealing with > > meaningful problems. > Do you mean the experiment or if this became a permanent > part of the process? Your comments read as if you're concerned > mostly about the latter, and you make no mention of the > former. Mostly the latter. But given I don't see this experiment being successful, I think the community has better ways of spending its limited resources. > As it happens, I agree that this is not going to produce > a huge improvement. But its not intended to, and modest > improvements (as opposed to modest proposals:-) should also > be ok. If not then we're in a worse process-rut than even I > think. If there is an improvement, I expect it will be too small to be worth bothering with. And given the community's limited resources (a not insubstantial amount of collective cycles has already gone into this document), it seems better to use those resources where there is some hope of making a real difference. > > The crux of the issue is that any attempt at "fast tracking" is > > fundamentally about short-circuiting some aspect of our review > > processes. > I'd prefer s/short-circuiting/speeding-up/ Sorry, I think short-circuiting is the right term. Saying you are just speeding things up is just spin. The reality is that it takes time to do quality standards/technical work. And, it takes iteration. The only kind of iteration that makes sense is sequential. Get some review, revise, then review the new version. When one tries to overlap sequential reviews, the result is almost always a poorer quality document. It is important that the revisions get reviewed by a fresh set of eyes. If you short-circuit such iteration, you inevitably get poorer quality documents. Also, it's really unfair to reviewers to have all of them stumble across the same issues. > > This document risks substituting process for judgement. I'd rather see > > more of the latter and less of the former. > Disagree. The WG chairs exercise judgement to kick off the > process. The IESG exercise judgement as usual with no changes. This document would use a different kind of judgement. One that is more formulaic. The kind of judgement I'd rather see is the WG/WG chairs/ADs getting together and making the case for a particular document being so important/urgent that it needs to be accelerated. And then have them work out a plan to actually get reviews in a more timely manner, etc. E.g., get committments from folk to review and revise quickly. Have a realistic workplan that folk commit to. If its not possible to get folk to commit to being responsive, doesn't that implicitely say something about the overall urgency of the document? But make that case on a number of factors (importance of having the RFC in place, etc.) rather than just on the fact that there was some sort of running code associated with it. > I think incorporating the discuss criteria should be an interesting > part of the experiment. (I've found them really helpful in reviewing > documents these last couple of years.) Discuss criteria are an IESG-level construct, developed to find balance between "nit picking" by the IESG very late in the process vs. correcting real problems. That same criteria is not appropriate to apply to a document that hasn't gone through WG LC, which is at a much earlier stage of the process. > > No doubt, when a AD or reviewer suggests "this needs > > fixing", the proponents will hold up this document and say "you > > shouldn't do this, per the RFC -- you're violating the spirit of this > > document, only really really critical stuff needs to get addressed..." > > No thanks. That is not what the IETF is about. > I don't see how you get to "No doubt..." I do entirely doubt that'll > happen for most all editors. This community is really good at citing process to justify whatever action (or inaction) they would like to see. Like it or not, this could become another such tool. Thomas