[mpowr] IETF Last Call (was: re: Mailing List Management)

Allison Mankin <mankin@psg.com> Wed, 24 December 2003 22:30 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25949 for <mpowr-archive@odin.ietf.org>; Wed, 24 Dec 2003 17:30:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHVz-00062v-OP for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 17:30:04 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOMU3bd023240 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 17:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHVz-00062l-J8 for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 17:30:03 -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 RAA25943 for <mpowr-web-archive@ietf.org>; Wed, 24 Dec 2003 17:30:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZHVx-0003cz-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 17:30:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZHU7-0003cC-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 17:28:08 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZHT1-0003aX-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 17:26:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHT3-000610-1T; Wed, 24 Dec 2003 17:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHSH-00060c-D9 for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 17:26:13 -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 RAA25877 for <mpowr@ietf.org>; Wed, 24 Dec 2003 17:26:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZHSF-0003ZV-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:26:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZHQa-0003Ww-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:24:28 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AZHQ5-0003Rn-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:23:57 -0500
Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AZHQ3-00065m-LL; Wed, 24 Dec 2003 22:23:55 +0000
To: John C Klensin <john-ietf@jck.com>
cc: Margaret.Wasserman@nokia.com, harald@alvestrand.no, mpowr@ietf.org
In-Reply-To: Message from John C Klensin <john-ietf@jck.com> of "Wed, 24 Dec 2003 00:13:51 EST." <5752541.1072224831@scan.jck.com>
Date: Wed, 24 Dec 2003 14:23:55 -0800
From: Allison Mankin <mankin@psg.com>
Message-Id: <E1AZHQ3-00065m-LL@psg.com>
Subject: [mpowr] IETF Last Call (was: re: Mailing List Management)
Sender: mpowr-admin@ietf.org
Errors-To: mpowr-admin@ietf.org
X-BeenThere: mpowr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-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

John,

Harald looked at your RFC Editor question, but there's still your 
other two.

First I'd like to say something about the overall point -  there 
are degrees here: one person's bending the process even severely,
as Margaret says, or warping it through seizing authority, as John
says, is another person's management of a situation during overload, 
with a lot of process checks in place.  

We're here in these mailing lists looking at the overall set of
problems, as a community, looking at questions of overload,
flow of work, ensuring enough review, differentiating functions... 
let's be careful not to get too tracked onto the power topic.  The
IESG's efforts here to get discussions to take form and see if 
we all can find solutions around WG/AD responsibilities and better 
review structures (the icar mailing list) have everything to do 
with the whole community's ownership and with process.

Taking the first one (I've put the other in separate message):

	* If a WG asks for an IETF Last Call on a document, do
	you think that the relevant AD is, or should be,
	authorized to hold it up indefinitely while going
	through a personal review process?  I note that, at the
	time 2026 was written, when a WG asked for a Last Call,
	the Last Call generally went out -- if the AD was not
	familiar with the document, he or she could review it in
	parallel with the rest of the community.  Is this
	progress?

If the AD holds the document up *indefinitely*, this is a serious
problem, beyond just overload, agreed.  But, sometimes the AD needs to
turn the document back to the WG before Last Call because it has
showstopping cross-area flaws or failure to match the charter.  Documents
would have fewer of these if we had less shortage of early review and
early cross-area review, and if ADs had more cycles to do the early
cross-area review.  This is one problem we're here (or, we're in icar) 
to work on.  RFC 2418 supports rejecting Last Calls with this language:

   a Last-Call is intended as a brief, final check with the
   Internet community, to make sure that no important concerns have been
   missed or misunderstood. The Last-Call should not serve as a more
   general, in-depth review.

The AD is a check and balance for charter/cross-area issues the WG/WG
Chairs may have missed in requesting the Last Call.  The AD's
determination that the document is ready for Last Call need not be a
long review (depending on how hard the WG is to convince, should there
be a showstopping problem).  But you may also be able to see why the 2418 
language can lead to an interpretation of full AD review before approval
of Last Call on some folks' part?  This is why we need to work on the
earlier review problem (looking at big picture).  Personally I consider 
it quite reasonable to have a split: a short AD check that the draft go 
ahead to Last Call or be sent back, and if it goes ahead, any additional
AD review take place during the Last Call period.

Allison



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