One of the things that's worked quite well in several working groups I participate in is (and I know this sounds radical) a culture of insisting on running code before publication. I'm not convinced that what works in the IEEE would work in the IETF, unfortunately. I think the process is a bit different—in the IEEE a lot of times what you are proposing is going to have implications in silicon, and that tends to concentrate the mind in a way that software doesn't. Maybe that's a bug we should try to fix, because broken software can have some pretty severe consequences, as we've seen of late. But how do we get there from here? I think one of the differences between the IETF and IEEE is that at least in some parts of the IETF, what is being proposed is motivated by a grass-roots wish to improve things, rather than an industry push. Yes, IETF members generally have employers, but our culture is more bottom-up than top-down. A lot of the work that gets done here is work that the "corporate sponsor" might not even have a use for. One way out of this is to say "only work on stuff that has major corporate buy-in," but I don't think we want that. Consequently, I think the availability of reviewers is always going to be different in IETF than IEEE. But I'm willing to be convinced otherwise. And I agree with you that the IETF last call review process is badly broken. The problem is that it becomes an N^2 algorithm when in principle every IETF participant is on the hook for every document. That doesn't work, and so we don't do it—instead we rely on the directorates and on the ADs to serve the function that last call ought to serve. I don't know how to address this, but I think it would be worthwhile to try to think about solutions. I did some thinking about it late in my AD term, but when I didn't get renewed I dropped it.
