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