Elwyn says... > However, I don't think that a short last call cycle need necessarily > compromise cross-area review. There has always been the possibility for > authors or wg chairs to request a early gen-art review with a view to > checking out whether something is in good shape cross-area and for > non-specialists. This facility is not much used (I think I have done 3 > in 8 years on the gen-art team) but it is there, and I guess the team > could cope with a few more since it doesn't drastically alter the total > workload. So it would be entirely possible for a draft that might be > fast-tracked to get some early review. Do you really think it's likely that a chair who's trying to fast-track a document will likely go out asking for early GenART, SecDir, AppDir, and OpsDir reviews? > Given that there is also open source code, reviewers have the chance to > take a look at that and see the degree of hackiness involved. This brings up something else that I've discussed with Stephen off list: This proposal requires an *open source* implementation. A robust set of proprietary implementations, along with several interoperability testing events, would not qualify. But some untested open source that someone knocked off in an afternoon would. I find that odd. I understand the desire to be able to inspect the implemented code, but that would seem to rule out too many things, including stuff at lower stack layers. If the AD can look at the implementations/deployments and talk with the implementors, the openness of the source code is not an issue. I'd be happy -- ecstatic -- to have two or three proprietary, very-closed-source implementations of most of the IMAP extensions, and have *no* need to see the source code. And I suspect that having shipping code in routers is a good thing for validating new routing protocols, and also suspect that we're not likely to be inspecting the source code of those. I'd really prefer if we'd talk about open source being desirable, but not having it be necessary. Barry