Hi, Joel I think this assumes that the quality of the document set that is the output of the IETF is the responsibility of the particular AD. The proposal as I see it is that there is a different review body. So when the working group is done with a document, the AD may review it (or leave it to the shepherd), call the IETF last-call, and then both AD and shepherd present it to the review panel. That means that the IESG no longer has bi-weekly meetings to approve documents, because that is the function of the review panel. The AD and shepherd join a conference call with the review panel, but only for the document they are championing. This means that the responsibility for quality control of a particular document and for the entire body of IETF RFCs rests with the review panel, freeing the IESG members to set up, recharter, and close working groups, and do the other things. They can still review things (like everybody else). One advantage of this is that we can align the reviews along different lines from those that the areas are split along. For example, the Security area deals with all kinds of security protocols, many of them related to cryptography. So there's protocols like TLS, IPsec, and Kerberos. This is a wholly separate thing from the security of a particular protocol or from security considerations for its implementation. It's important for TLS to be secure, but it is no less important for HTTP to be secure. And yet SecDir reviews have become security reviews. They look at the protocol and the security considerations section, not in particular to how the proposal works with security area protocols. What SecDir (and the security ADs) check has only a tenuous relationship to what the security area works on. This is even more clear with the routing area. There is a routing area because there is a lot of work on routing protocols, not because every protocol out there is somehow related to routing. Is there any particular value in a review of some generic protocol (say, HTTP/2.0) by a routing area directorate or by a routing area director? This is not a dig at Stewart and Adrian. They may have a lot of meaningful things to say about HTTP/2.0, but I don't think that has anything to do with their routing area position or expertise. Separating the review function from the IESG allows us to find reviewers along particular relevant review topics: (just off the top of my head) - security (both considerations for implementing and the security of the protocol itself) - deployability (has the working group considered interactions with all kinds of middleboxes? Does it require any non-generally available infrastructure? Does it require high bandwidth to function properly?) - usability (when protocols have interaction with a user interface, does the document cover that enough?) - networking impact (would it cause congestion? would it slow down other flows?) There could be more areas. The review panel could use its own permanent members, or call in subject matter experts for particular protocols. The question, though, is how much would that reduce the load on the IESG. If all we've done is get it down from 35 hours/week to 28 hours/week, I'm not sure it's worth it, because you still can't hold another full-time job. Yoav On Oct 20, 2013, at 10:54 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote: > The obvious risk if one separates WG management from review is that one could easily get the situation where the manager, in working with the WG, says that the document needs X, Y, and not Z. And then the reviewer says "needs Z". And there are more extreme versions of this. > Currently, the ability for the managing AD to say "no, this won't pass muster" is part of his management tool. If he is not the reviewer, he seems to have lost an important tool. I hope I am missing something that would make this sort of approach workable. > > Yours, > Joel