[Icar] Re: [Solutions] Summary of Discussion on Reforming IETF Quality Control Process

Alex Rousskov <rousskov@measurement-factory.com> Mon, 12 January 2004 21:08 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19522 for <icar-archive@odin.ietf.org>; Mon, 12 Jan 2004 16:08:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9IR-0005Vb-Im for icar-archive@odin.ietf.org; Mon, 12 Jan 2004 16:08:28 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CL8RGB021169 for icar-archive@odin.ietf.org; Mon, 12 Jan 2004 16:08:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9IR-0005VM-Dd for icar-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:08:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19444 for <icar-web-archive@ietf.org>; Mon, 12 Jan 2004 16:08:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9IP-000019-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 16:08:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9GJ-0007gY-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 16:06:16 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9F7-0007cS-00 for icar-web-archive@ietf.org; Mon, 12 Jan 2004 16:05:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9F8-0004s8-Sm; Mon, 12 Jan 2004 16:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9EG-0004r4-G4 for icar@optimus.ietf.org; Mon, 12 Jan 2004 16:04:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19023 for <icar@ietf.org>; Mon, 12 Jan 2004 16:04:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9EE-0007Zq-00 for icar@ietf.org; Mon, 12 Jan 2004 16:04:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9CO-0007X3-00 for icar@ietf.org; Mon, 12 Jan 2004 16:02:12 -0500
Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9BS-0007TY-00 for icar@ietf.org; Mon, 12 Jan 2004 16:01:14 -0500
Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i0CL1Dk3026752; Mon, 12 Jan 2004 14:01:13 -0700 (MST) (envelope-from rousskov@measurement-factory.com)
Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i0CL1CPa026751; Mon, 12 Jan 2004 14:01:12 -0700 (MST) (envelope-from rousskov)
Date: Mon, 12 Jan 2004 14:01:12 -0700 (MST)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>
cc: icar@ietf.org, solutions@alvestrand.no
In-Reply-To: <5.1.0.14.0.20040110013737.018ef758@localhost>
Message-ID: <Pine.BSF.4.58.0401121338490.15125@measurement-factory.com>
References: <003701c3d737$5b361530$386015ac@dclkempt40> <5.1.0.14.2.20040109203410.04552a28@ms101.mail1.com> <003701c3d737$5b361530$386015ac@dclkempt40> <5.1.0.14.0.20040110013737.018ef758@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Icar] Re: [Solutions] Summary of Discussion on Reforming IETF Quality Control Process
Sender: icar-admin@ietf.org
Errors-To: icar-admin@ietf.org
X-BeenThere: icar@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=unsubscribe>
List-Id: Improved Cross-Area Review <icar.ietf.org>
List-Post: <mailto:icar@ietf.org>
List-Help: <mailto:icar-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

On Sat, 10 Jan 2004, Joel M. Halpern wrote:

> I may be missing something, but the problem I see reading this is
> that this gives the IESG no assistance in deciding which documents
> it needs to review.

Why do you think IESG needs an assistance with this? Can IESG decide
on a case by case basis, as ADs see new documents popping up in a "now
soliciting reviews" state? What kind of assistance do you have in
mind?

> There was another proposal which I read to say ~the IESG needs to
> review documents for which there is disagreement about the results
> of other reviews.~ While one can argue about whether that is good or
> not, it at least spells out when the IESG needs to review a
> document, and when it does not need to.

You may be talking about the "IESG must resolve reviewer-WG conflicts"
rule I have been pushing for. That rule co-exists nicely with "IESG
may review any document as any IETF participant can" rule.  Put
together, the two rules essentially define how IESG interacts with WGs
as far as reviews are concerned: first as a normal reviewer, then as
the final conflict resolution authority if needed.

> ... my understanding of one aspect of this discussion is to help
> replace the current ~the IESG must review everything~ with a useful
> alternative review procedure, and a useful definition of which
> things the IESG needs to review.

I do not think we can pre-define what IESG needs to review without
being either too broad or too restrictive. I would rather avoid the
whole problem by letting IESG decide what warrants full review. Note
that there is some balance in this approach: since IESG is just a
"regular" reviewer, they are subject to the same deadlines and
timeouts. Thus, IESG (as a whole) should be careful not to overload
itself with non-essential reviews because they will start missing
deadlines on essential ones.

> The text below seems to say taht there are no documents the IESG
> needs to review.

Not exactly. The text below implies that we cannot define a priori
what IESG needs to review, but we give IESG an interface to review
anything that IESG thinks is important enough to be worth their
review.

Alex.

> At 10:43 PM 1/9/2004 -0700, Alex Rousskov wrote:
> >There should be no "requires full IESG review" flag or state for
> >any document. IESG is not a special case when it comes to review.
> >IESG or any single AD can submit a review for any document that is
> >up for review, at any time. This is no different from any IETF
> >participant submitting a review. If IESG feels that a particular
> >document needs full IESG review, it is their internal business,
> >invisible and unpredictable to others (in general), until they
> >submit a review. In general, one does not know a priori whether a
> >document will be reviewed by IESG until the IESG submits the
> >review.

_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar