[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
- [mpowr] IETF Last Call (was: re: Mailing List Man… Allison Mankin
- Standards Process wrt IANA (was Re: [mpowr] Maili… Allison Mankin