[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
- [Icar] Summary of Discussion on Reforming IETF Qu… James Kempf
- [Icar] Re: [Solutions] Summary of Discussion on R… Margaret Wasserman
- [Icar] Re: [Solutions] Summary of Discussion on R… James Kempf
- [Icar] Re: [Solutions] Summary of Discussion on R… Alex Rousskov
- [Icar] Re: [Solutions] Summary of Discussion on R… Joel M. Halpern
- [Icar] Re: [mpowr] Re: [Solutions] Summary of Dis… Margaret Wasserman
- [Icar] Assessing wg risk and criticality Dave Crocker
- [Icar] Re: [Solutions] Summary of Discussion on R… Alex Rousskov
- [Icar] Re: [Solutions] Summary of Discussion on R… Alex Rousskov
- [Icar] Re: [mpowr] Re: [Solutions] Summary of Dis… Alex Rousskov
- [Icar] Reviewers: One single group or per-area gr… Michael A. Patton
- Re: [Icar] Reviewers: One single group or per-are… Dave Crocker
- Re: [Icar] Reviewers: One single group or per-are… Alex Rousskov
- Re: [Icar] Reviewers: One single group or per-are… Harald Tveit Alvestrand
- Re: [Icar] Reviewers: One single group or per-are… Alex Rousskov