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(_at_)joelhalpern(_dot_)com>
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