From exim@www1.ietf.org Tue Dec 9 19:14:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25584 for ; Tue, 9 Dec 2003 19:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATrzN-0001O3-JX for mpowr-archive@odin.ietf.org; Tue, 09 Dec 2003 19:14:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA0E1iR005325 for mpowr-archive@odin.ietf.org; Tue, 9 Dec 2003 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATrzN-0001No-EE for mpowr-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 19:14:01 -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 TAA25576 for ; Tue, 9 Dec 2003 19:13:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATrzL-0004VV-00 for mpowr-web-archive@ietf.org; Tue, 09 Dec 2003 19:13:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATrzL-0004VR-00 for mpowr-web-archive@ietf.org; Tue, 09 Dec 2003 19:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATrzL-0001NS-U4; Tue, 09 Dec 2003 19:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATrye-0001Jc-AA for mpowr@optimus.ietf.org; Tue, 09 Dec 2003 19:13:20 -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 TAA25550 for ; Tue, 9 Dec 2003 19:12:59 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATryc-0004UY-00 for mpowr@ietf.org; Tue, 09 Dec 2003 19:13:14 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATryc-0004UT-00 for mpowr@ietf.org; Tue, 09 Dec 2003 19:13:14 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBA0DDR19648 for ; Wed, 10 Dec 2003 02:13:13 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 02:13:13 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 9 Dec 2003 18:12:46 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Dec 2003 19:12:45 -0500 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcO+oDJZacv+5Ho0RlaVWkgI7uVQDAAEWzlA To: , , X-OriginalArrivalTime: 10 Dec 2003 00:12:46.0528 (UTC) FILETIME=[56BE6400:01C3BEB2] Content-Transfer-Encoding: quoted-printable Subject: [Mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 Hi Scott,=20 > I do think that a focused discussion on the role of the WG=20 > (and WG chair) in the context of the IETF process is a "good=20 > idea." And, I think that having that discussion in the context=20 > of an IETF WG is a reasonable way to proceed but I'd rather=20 > not define the output in the charter before the discussion=20 > starts. I agree. So, let's start this discussion on the mpowr@ietf.org mailing list, and see if we can decide (together as a community) whether we need a WG in this area and, if so, what the charter for that WG should be. >=20 > I do not think that the is IETF consensus on what the role of=20 > the WG (and chairs) *currently* is relative to ADs and the IESG=20 > so it seems getting ahead of the discussion by quite a bit to=20 > assume that the relationship needs to change. I continue to agree. > Lets figure out what we want the roles to be and clearly document them > (if indeed "clearly document" is felt to be a good thing - flexibility > can be very helpful sometimes) This sounds like a reasonable place to start to me. > then someone (historians?) can figure out in retrospect if doing that=20 > resulted in a power shift and if it did, what direction the shift was. I'm not sure that it matters, historically, whether there has been a power shift over time. Instead, I think we should focus (after reaching a common=20 uncerstanding on what our current state actually is) on whether the current model is working well enough or needs to be fixed in some way. Margaret _______________________________________________ Mpowr mailing list Mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 15:43:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25491 for ; Fri, 12 Dec 2003 15:43: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 1AUu7q-0007it-QW for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 15:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKh2xG029681 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 15:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUu7q-0007ie-GP for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:43:02 -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 PAA25480 for ; Fri, 12 Dec 2003 15:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUu7p-00001h-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 15:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUu7o-00001d-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 15:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUu7p-0007iQ-64; Fri, 12 Dec 2003 15:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUu6q-0007hk-Qq for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 15:42:01 -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 PAA25465 for ; Fri, 12 Dec 2003 15:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUu6p-00000T-00 for mpowr@ietf.org; Fri, 12 Dec 2003 15:41:59 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AUu6o-00000I-00 for mpowr@ietf.org; Fri, 12 Dec 2003 15:41:59 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Fri, 12 Dec 2003 14:41:27 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20031209220238.172C19B30A@newdev.harvard.edu> References: <20031209220238.172C19B30A@newdev.harvard.edu> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Fri, 12 Dec 2003 14:41:25 -0600 To: sob@harvard.edu (Scott Bradner) From: Pete Resnick Cc: solutions@alvestrand.no, MPowr Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , On 12/9/03 at 5:02 PM -0500, Scott Bradner wrote: >>The broad goal of this WG would be to shift more responsibility and >>authority to WGs, while ensuring appropriate accountability to the >>IETF as a whole. > >I have not seen a consensus that any such a shift is needed or a good idea. I thought I heard a good deal of comment that shifting some *responsibility* to the chairs was a good idea. On the other hand, I agree: I certainly heard no consensus about shifting *authority*. >I do think that a focused discussion on the role of the WG (and WG >chair) in the context of the IETF process is a "good idea." I think that discussion may be a good idea. >And, I think that having that discussion in the context of an IETF >WG is a reasonable way to proceed And on that I disagree in the strongest possible terms. I think this is a phenomenally bad idea. Right now any AD can, of his or her own choosing and without any change in 2026 or 2418, decide to make their WG chairs responsible for the technical writeup of documents, resolving last call issues, and shepherding of the document through the IESG including resolving discuss issues. An AD can choose to do this now without asking the IETF for any consensus whatsoever. Personally, I think this would be a good thing for an AD to do anyway. It certainly has every appearance of addressing the workload problem and some more of the transparency problem. This is not worthy of a WG. It is worthy of implementation. Having discussions on whether or not it would be a good idea to increase the powers and authority of a WG or WG chair might be interesting. Having ongoing discussions to decide whether or not increasing the responsibilities of WG chairs is working out (once started; see previous paragraph) is fine. But forming a WG when there is no need for documentation of some of these straightforward procedural changes is, IMO, silly. Forming a WG to produce a document to discuss this is simply delaying, and delay is something we've seen more than enough of. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 15:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26312 for ; Fri, 12 Dec 2003 15:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuNK-0008BJ-10 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 15:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCKx1rw031443 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 15:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuNJ-0008B4-Lb for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 15:59:01 -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 PAA26301 for ; Fri, 12 Dec 2003 15:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuNI-0000dR-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 15:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUuNH-0000dO-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 15:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuNI-0008AY-Ha; Fri, 12 Dec 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuMg-00089u-7E for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 15:58:22 -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 PAA26265 for ; Fri, 12 Dec 2003 15:58:19 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuMe-0000cS-00 for mpowr@ietf.org; Fri, 12 Dec 2003 15:58:20 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUuMd-0000cP-00 for mpowr@ietf.org; Fri, 12 Dec 2003 15:58:20 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCKwJn08361 for ; Fri, 12 Dec 2003 22:58:19 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 22:58:18 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 12:57:02 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Dec 2003 15:57:01 -0500 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcPA8FYdkuGCPtLBSkGG76XwLx7AtQAARFAA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 20:57:02.0931 (UTC) FILETIME=[7E40F230:01C3C0F2] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pete, > Right now any AD can, of his or her own choosing and without any=20 > change in 2026 or 2418, decide to make their WG chairs responsible=20 > for the technical writeup of documents, resolving last call issues,=20 > and shepherding of the document through the IESG including resolving=20 > discuss issues. An AD can choose to do this now without asking the=20 > IETF for any consensus whatsoever. >=20 > Personally, I think this would be a good thing for an AD to do=20 > anyway. It certainly has every appearance of addressing the workload=20 > problem and some more of the transparency problem. >=20 > This is not worthy of a WG. It is worthy of implementation. I mostly agree with you. These types of changes do fall completely within the scope of our current BCPs. However, they can't be implemented on an=20 IETF-wide basis "right now", because they are not supported by=20 our current IESG-secretariat procedures, nor are they well-supported=20 by our tools. =20 We will need some procedural and tools changes to support this shift, and those are the types of changes that I expect the=20 PROTO Team to propose to the IESG. We can (and will) make these changes as quickly as we can, while also being prudent and careful. > Having discussions on whether or not it would be a good idea to=20 > increase the powers and authority of a WG or WG chair might be=20 > interesting. Having ongoing discussions to decide whether or not=20 > increasing the responsibilities of WG chairs is working out (once=20 > started; see previous paragraph) is fine. But forming a WG when there=20 > is no need for documentation of some of these straightforward=20 > procedural changes is, IMO, silly. Forming a WG to produce a document=20 > to discuss this is simply delaying, and delay is something we've seen=20 > more than enough of. The discussion of this WG, and its possible formation, is=20 not expected to delay the work of the PROTO Team. Some people believe that we need changes to RFCs 2418 and/or 2026 to modernize, clarify or modify the roles of WG chairs, ADs, etc. If there is community consensus that these types of changes are needed, that is what the WG will work on. IMO, this is a lower priority effort than making the changes=20 to our IESG-Secretariat procedures and tools that will allow us to give WGs (through WG chairs) more visibility and control over their documents in the later document phases.=20 Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 16:45:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28311 for ; Fri, 12 Dec 2003 16:45:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUv5t-0001bA-7H for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 16:45:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCLj5lo006138 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 16:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUv5s-0001av-Tt for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 16:45:04 -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 QAA28290 for ; Fri, 12 Dec 2003 16:45:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUv5q-0001tg-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 16:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUv5q-0001td-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 16:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUv5r-0001aK-Hx; Fri, 12 Dec 2003 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUuz7-0001FH-MV for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 16:38:05 -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 QAA28058 for ; Fri, 12 Dec 2003 16:38:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUuz5-0001jg-00 for mpowr@ietf.org; Fri, 12 Dec 2003 16:38:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AUuz4-0001jd-00 for mpowr@ietf.org; Fri, 12 Dec 2003 16:38:03 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCLbv4t025996; Fri, 12 Dec 2003 13:37:58 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCLbtFB028094; Fri, 12 Dec 2003 13:37:55 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <20031209220238.172C19B30A@newdev.harvard.edu> Date: Fri, 12 Dec 2003 13:37:55 -0800 To: Pete Resnick , sob@harvard.edu (Scott Bradner) From: Ted Hardie Cc: MPowr , solutions@alvestrand.no Content-Type: text/plain; charset="us-ascii" Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , > >Right now any AD can, of his or her own choosing and without any change in 2026 or 2418, decide to make their WG chairs responsible for the technical writeup of documents, resolving last call issues, and shepherding of the document through the IESG including resolving discuss issues. An AD can choose to do this now without asking the IETF for any consensus whatsoever. But, at the moment, this is done at the pleasure of the ADs, and is not a default state of affairs. Having a working group decide whether this should be the *expected* state of affairs does have consequences on how much time working group chairs must expect to dedicate to their tasks, how the nomcom would see certain candidates for AD roles, and how the community may want to structure other tasks (including selecting or providing checks and balances for the working group chairs in their roles). Considering those is something that should be done in public, with an aim for consensus, and soon. A working group is one way of achieving that. This does not mean that ADs cannot or should not give those tasks to the willing working group chairs sooner, but until it is the *IETF* giving those tasks to someone other than the AD, we are still operating at the pleasure of the AD. That needs to change, in my opinion. Just my two cents, obviously, Ted _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:06:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29147 for ; Fri, 12 Dec 2003 17:06: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 1AUvQC-0002hQ-5f for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCM64O4010370 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvQC-0002hB-0H for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:06:04 -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 RAA29125 for ; Fri, 12 Dec 2003 17:06:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvQ9-0002Su-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:06:01 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUvQ9-0002Sr-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:06:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUvQ9-0001N9-O3 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvQ9-0002fl-7J; Fri, 12 Dec 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvQ3-0002f0-H5 for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:05:55 -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 RAA29119 for ; Fri, 12 Dec 2003 17:05:51 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvQ1-0002Sd-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:05:53 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUvQ0-0002Sa-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:05:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCM5qH20152 for ; Sat, 13 Dec 2003 00:05:52 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 00:05:51 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 16:05:50 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Dec 2003 17:05:48 -0500 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcPA8FYdkuGCPtLBSkGG76XwLx7AtQACwnxA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 22:05:50.0025 (UTC) FILETIME=[1A318390:01C3C0FC] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pete, > I thought I heard a good deal of comment that shifting some=20 > *responsibility* to the chairs was a good idea. On the other hand, I=20 > agree: I certainly heard no consensus about shifting *authority*. Are you talking about the comments that people made at the plenary microphone? The response to the Minneapolis plenary straw poll? Or=20 comments that you've heard elsewhere? I don't believe that it would be meaningful to say that the IETF has consensus about a concept as vague as moving responsibility or authority in any particular direction. But, based on the results of the plenary poll, there did seem to be significant support for=20 the IESG's proposal to move more authority and responsibility to WG=20 chairs. There were also some excellent points raised regarding the specifics of the proposal, and we are actively tuning our proposed direction based on community feedback. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:07:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29204 for ; Fri, 12 Dec 2003 17:07:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvRA-0002qA-OM for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCM74WW010903 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvRA-0002pe-3F for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:07:04 -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 RAA29188 for ; Fri, 12 Dec 2003 17:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvR7-0002US-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:07:02 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUvR7-0002UP-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:07:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUvR7-0001QD-SO for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvR7-0002mQ-Rx; Fri, 12 Dec 2003 17:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvJS-0002BV-Cq for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 16:59:06 -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 QAA28652 for ; Fri, 12 Dec 2003 16:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvJQ-0002Br-00 for mpowr@ietf.org; Fri, 12 Dec 2003 16:59:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AUvJP-0002Bn-00 for mpowr@ietf.org; Fri, 12 Dec 2003 16:59:03 -0500 Message-ID: <028201c3c0fb$332bd220$666015ac@dclkempt40> From: "James Kempf" To: "Scott Bradner" , "Pete Resnick" Cc: "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> Date: Fri, 12 Dec 2003 13:59:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I thought I heard a good deal of comment that shifting some > *responsibility* to the chairs was a good idea. On the other hand, I > agree: I certainly heard no consensus about shifting *authority*. > This is a recipe for driving people away. If you give someone the responsibility to do something, they better have the authority to accomplish the task. Otherwise, who would take the job? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:16:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29481 for ; Fri, 12 Dec 2003 17:16:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvZV-0003P4-Pm for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:15:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMFf18013074 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:15:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvZV-0003OZ-Hr for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:15:41 -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 RAA29452 for ; Fri, 12 Dec 2003 17:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvZS-0002gB-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:15:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvZB-0002fp-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvYt-0003NJ-Fi; Fri, 12 Dec 2003 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvSP-0003Cr-SD for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:08:21 -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 RAA29246 for ; Fri, 12 Dec 2003 17:08:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvSN-0002XP-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:08:19 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AUvSN-0002VG-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:08:19 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 60050A2BE4; Fri, 12 Dec 2003 17:07:44 -0500 (EST) To: Margaret.Wasserman@nokia.com, presnick@qualcomm.com, sob@harvard.edu Cc: mpowr@ietf.org, solutions@alvestrand.no In-Reply-To: Message-Id: <20031212220744.60050A2BE4@newdev.harvard.edu> Date: Fri, 12 Dec 2003 17:07:44 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , > But, based on the results > of the plenary poll, there did seem to be significant support for=20 > the IESG's proposal to move more authority and responsibility to WG=20 > chairs. I disagree with this conclusion I did not see such a consensus nor did I hear any hint of such a consensus in talking to people during the meeting Scott _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:21:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29619 for ; Fri, 12 Dec 2003 17:21:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUveh-0003en-79 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCML3WP014051 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUveh-0003eY-0g for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:21: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 RAA29611 for ; Fri, 12 Dec 2003 17:20:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvee-0002oF-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:21:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvee-0002oC-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvef-0003dm-7U; Fri, 12 Dec 2003 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvdl-0003cr-05 for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:20:05 -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 RAA29598 for ; Fri, 12 Dec 2003 17:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvdi-0002nO-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:20:02 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AUvdi-0002mw-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:20:02 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id AA5DAA2C5F; Fri, 12 Dec 2003 17:19:32 -0500 (EST) To: Margaret.Wasserman@nokia.com, presnick@qualcomm.com, sob@harvard.edu Cc: mpowr@ietf.org, solutions@alvestrand.no In-Reply-To: Message-Id: <20031212221932.AA5DAA2C5F@newdev.harvard.edu> Date: Fri, 12 Dec 2003 17:19:32 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , > I wasn't at the Thursday evening plenary, but the minutes > indicate that 60% of the people in the room thought that the > WG Chairs proposal was a good idea, 10% thought it was a=20 > bad idea and 10% didn't know. lets just say that I disagree with the idea that anywhere that % of the folks in the room expressed WG chairs proposal was a "good idea" - so far I have found almost no one who thought that the specific proposal was a good idea - only 2 or 3 people said they did at the mike - the rest expessed varing degrees of objection I do think that most people thought that talking about the issue was a good idea but let get some others say what they saw Scott _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:23:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29682 for ; Fri, 12 Dec 2003 17:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvgc-0003he-CD for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMN2mS014228 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvgc-0003hP-6t for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:23:02 -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 RAA29670 for ; Fri, 12 Dec 2003 17:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvgZ-0002rC-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:23:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvgZ-0002r9-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvgb-0003gy-BB; Fri, 12 Dec 2003 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvfl-0003fe-40 for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:22:09 -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 RAA29655 for ; Fri, 12 Dec 2003 17:22:05 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvfi-0002pj-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:22:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUvfi-0002pg-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:22:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCMM5n26782 for ; Sat, 13 Dec 2003 00:22:05 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 13 Dec 2003 00:22:05 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 14:21:58 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Dec 2003 17:21:58 -0500 Message-ID: Thread-Topic: Test Message -- Please Ignore Thread-Index: AcPA/ls8K3IpyDP8QjOiPE6F8PlFZw== To: X-OriginalArrivalTime: 12 Dec 2003 22:21:59.0134 (UTC) FILETIME=[5BD3CFE0:01C3C0FE] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] Test Message -- Please Ignore 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I've seen cross-postings that don't seem to be showing up on this list. So, I thought I would test if the=20 list actually works. Please ignore. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:38:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00395 for ; Fri, 12 Dec 2003 17:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvvD-0004Wf-3i for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMc6Eh017351 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvvA-0004Va-Kc for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:38:04 -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 RAA00369 for ; Fri, 12 Dec 2003 17:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvv8-0003Ew-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:38:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvv7-0003Et-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvv8-0004V6-Q1; Fri, 12 Dec 2003 17:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvuD-0004LE-AM for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:37:05 -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 RAA00312 for ; Fri, 12 Dec 2003 17:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvuA-0003Bf-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:37:02 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AUvuA-0003BE-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:37:02 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Fri, 12 Dec 2003 16:36:32 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <028201c3c0fb$332bd220$666015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Fri, 12 Dec 2003 16:36:30 -0600 To: "James Kempf" From: Pete Resnick Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Cc: "Scott Bradner" , "MPowr" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , On 12/12/03 at 1:59 PM -0800, James Kempf wrote: >>I thought I heard a good deal of comment that shifting some >>*responsibility* to the chairs was a good idea. On the other hand, >>I agree: I certainly heard no consensus about shifting *authority*. > >This is a recipe for driving people away. If you give someone the >responsibility to do something, they better have the authority to >accomplish the task. Otherwise, who would take the job? Someone else mentioned in private mail that they read it the way you did. Let me clarify, as that isn't what I meant. I thought I heard at the plenary many people who thought it was a good idea to give certain responsibilities to the chairs: - Making sure enough technical reviews are done before docs go to the IESG - Doing a technical writeup of their own - Tracking Last Call and IESG discuss issues and collecting WG responses I thought I heard at the plenary many people who thought that giving chairs "the authority to say no" was a really bad idea. A chair does not need the authority to say no in order to get technical reviews assigned, do a technical writeup, or track outstanding issues. They already have full authority to accomplish those tasks. All that I'm saying is that any AD today *can* ask a chair to do these things, and I think that they should. We don't need a WG to make that happen. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:38:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00414 for ; Fri, 12 Dec 2003 17:38:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvvH-0004Y9-0k for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:38:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMcAnA017481 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvvF-0004Xd-Gd for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:38:09 -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 RAA00375 for ; Fri, 12 Dec 2003 17:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvvD-0003F4-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvvC-0003F1-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvvD-0004Wt-LE; Fri, 12 Dec 2003 17:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvnn-0003sX-1t for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:30: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 RAA29867 for ; Fri, 12 Dec 2003 17:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvnk-0002yn-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:30:24 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AUvnk-0002yk-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:30:24 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AUvnc-0000KU-00; Fri, 12 Dec 2003 23:30:16 +0100 Date: Fri, 12 Dec 2003 23:30:09 +0100 From: Henrik Levkowetz To: sob@harvard.edu (Scott Bradner) Cc: Margaret.Wasserman@nokia.com, presnick@qualcomm.com, sob@harvard.edu, mpowr@ietf.org, solutions@alvestrand.no Message-Id: <20031212233009.5c0775e3.henrik@levkowetz.com> In-Reply-To: <20031212220744.60050A2BE4@newdev.harvard.edu> References: <20031212220744.60050A2BE4@newdev.harvard.edu> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Friday 12 December 2003, Scott wrote: > > But, based on the results > > of the plenary poll, there did seem to be significant support for=20 > > the IESG's proposal to move more authority and responsibility to WG=20 > > chairs. > > I disagree with this conclusion > > I did not see such a consensus nor did I hear any hint of such a consensus > in talking to people during the meeting I agree with Margaret's statement. I looked around when the poll was taken, and there seemed to be significant support for the IESG's proposal. There's been a few voices opposing this very loudly on the solutions and problem-statemen lists, but most people I've been in contact with have - on being asked about their position on this - indicated support. The impression I get is that many people support this, a few oppose it, but are much more vociferous. Henrik _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00727 for ; Fri, 12 Dec 2003 17:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw5l-00054R-Ui for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMn10t019485 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw5l-00054C-MK for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:49:01 -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 RAA00701 for ; Fri, 12 Dec 2003 17:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUw5j-0003RI-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:48:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUw5i-0003RF-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw5k-00053j-HJ; Fri, 12 Dec 2003 17:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw5Z-00053U-6D for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:48:49 -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 RAA00698 for ; Fri, 12 Dec 2003 17:48:44 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUw5W-0003RA-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:48:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUw5V-0003R7-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:48:46 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCMmjH03482 for ; Sat, 13 Dec 2003 00:48:45 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 00:48:46 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 14:48:43 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Date: Fri, 12 Dec 2003 17:48:42 -0500 Message-ID: Thread-Topic: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Thread-Index: AcPBAGp0Snxlkn14R7Cgq8eSePT0uQAAIneg To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 22:48:43.0306 (UTC) FILETIME=[17FD08A0:01C3C102] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pete, > I thought I heard at the plenary many people who thought that giving=20 > chairs "the authority to say no" was a really bad idea. >=20 > A chair does not need the authority to say no in order to get=20 > technical reviews assigned, do a technical writeup, or track=20 > outstanding issues. They already have full authority to accomplish=20 > those tasks. Some of this may be a terminology issue... Do you think that a WG chair should be allowed to hold a document (i.e. not submit it to the IESG) while the chair seeks sufficient cross-area review? Or do you think that a chair is obligated to send a document to the IESG as soon as the WG has consensus to=20 do so, even if, it is the opinion of the chair that the document=20 requires more cross-area review before it is ready to advance? If we give the chair responsibility for obtaining sufficient cross-area review, then we also have to give him the authority to hold the document (even one that has WG consensus) until the cross-area review is completed, don't you think? Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 17:52:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00857 for ; Fri, 12 Dec 2003 17:52:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw8g-00059Y-QQ for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMq2os019802 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw8g-00059J-Eo for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:52:02 -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 RAA00854 for ; Fri, 12 Dec 2003 17:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUw8d-0003WB-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:51:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUw8d-0003W8-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw8f-00058q-9I; Fri, 12 Dec 2003 17:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUw6C-00054n-Kq for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:49:28 -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 RAA00725 for ; Fri, 12 Dec 2003 17:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUw69-0003SA-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:49:25 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUw69-0003RE-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:49:25 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2003 14:51:12 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBCMmrZ0010302; Fri, 12 Dec 2003 14:48:53 -0800 (PST) Received: from cisco.com ([10.25.65.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APB98158; Fri, 12 Dec 2003 14:48:51 -0800 (PST) Date: Fri, 12 Dec 2003 17:48:47 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: sob@harvard.edu (Scott Bradner), Margaret.Wasserman@nokia.com, solutions@alvestrand.no, mpowr@ietf.org To: Henrik Levkowetz From: Melinda Shore In-Reply-To: <20031212233009.5c0775e3.henrik@levkowetz.com> Message-Id: <58C19470-2CF5-11D8-80A3-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, December 12, 2003, at 05:30 PM, Henrik Levkowetz wrote: > The impression I get is that many people support this, a few oppose it, > but are much more vociferous. I think there's general support for the idea of moving more work/ responsibility to the chairs, but when we start talking about the substance of a proposal support start to break down pretty quickly. It's not that there's objection to the broadly-stated ideal, but that right now it's difficult to say how to do it well, and proposals for doing it badly are obviously not going to garner all that much support (but some!). Melinda _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 18:02:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29480 for ; Fri, 12 Dec 2003 17:16:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvZV-0003On-MA for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:15:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCMFftv013054 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 17:15:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvZV-0003OO-8j for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 17:15:41 -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 RAA29444 for ; Fri, 12 Dec 2003 17:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvZS-0002gA-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:15:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUvZB-0002fo-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 17:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvYt-0003My-8v; Fri, 12 Dec 2003 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUvY9-0003Lt-E8 for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 17:14:17 -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 RAA29392 for ; Fri, 12 Dec 2003 17:14:13 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUvY7-0002eh-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:14:15 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUvY6-0002ee-00 for mpowr@ietf.org; Fri, 12 Dec 2003 17:14:14 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCMEEH29333 for ; Sat, 13 Dec 2003 00:14:14 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 00:14:14 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 14:14:06 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Dec 2003 17:14:05 -0500 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcPA/GMALUtHauqwSFaY6rAcdLOkowAAAymQ To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 22:14:06.0806 (UTC) FILETIME=[424C4760:01C3C0FD] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Scott, > > But, based on the results of the plenary poll, there did seem=20 > > to be significant support for the IESG's proposal to move more=20 > > authority and responsibility to WG chairs. >=20 > I disagree with this conclusion >=20 > I did not see such a consensus nor did I hear any hint of=20 > such a consensus in talking to people during the meeting I think that you are disagreeing with a statement that I didn't make. I did not say that there was consensus. In fact, my previous sentence indicated that the concept of consensus on such a vague concept would be meaningless... And, beside, it isn't my perogative to define consensus within the IETF. I wasn't at the Thursday evening plenary, but the minutes indicate that 60% of the people in the room thought that the WG Chairs proposal was a good idea, 10% thought it was a=20 bad idea and 10% didn't know. The other 20% of the people in the room didn't respond, I guess. =20 I consider 60% of the people at the plenary to be "significant support". YMMV. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 18:04:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01278 for ; Fri, 12 Dec 2003 18:04: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 1AUwKL-0005VI-8n for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 18:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCN45br021150 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 18:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwKL-0005V3-3b for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 18:04:05 -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 SAA01225 for ; Fri, 12 Dec 2003 18:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwKF-0003i8-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 18:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUwKF-0003i5-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 18:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwKH-0005UZ-CA; Fri, 12 Dec 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwJb-0005U3-9n for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 18:03:19 -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 SAA01152 for ; Fri, 12 Dec 2003 18:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwJY-0003hT-00 for mpowr@ietf.org; Fri, 12 Dec 2003 18:03:16 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AUwJN-0003hO-00 for mpowr@ietf.org; Fri, 12 Dec 2003 18:03:05 -0500 Message-ID: <02e501c3c104$26e72ba0$666015ac@dclkempt40> From: "James Kempf" To: , Cc: , References: Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Date: Fri, 12 Dec 2003 15:03:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret, > Some of this may be a terminology issue... > > Do you think that a WG chair should be allowed to hold a document > (i.e. not submit it to the IESG) while the chair seeks sufficient > cross-area review? Or do you think that a chair is obligated to > send a document to the IESG as soon as the WG has consensus to > do so, even if, it is the opinion of the chair that the document > requires more cross-area review before it is ready to advance? > > If we give the chair responsibility for obtaining sufficient > cross-area review, then we also have to give him the authority > to hold the document (even one that has WG consensus) until the > cross-area review is completed, don't you think? > I think we may be getting to the nub of the objection here. As near as I can understand from talking with some people who have been vocal in their objections, one of the primary problems they have with your draft is the implication that giving the WG chair the authority to say no essentially mixes development and quality control. From experience with software development, quality control works best when the development team and the QA team are separate, as developers often have difficulty seeing quality problems. But, from your statement above, it seems you have something different in mind. By "authority" you rather mean just official RFC 2026-level approval for the WG chair to manage the review of the document, because a WG chair can't do that today. Not that the WG chair would, in essence, have a line-item veto whereby they could go through a document and change things arbitrarily. Do I understand you correctly? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 12 21:43:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10200 for ; Fri, 12 Dec 2003 21:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUzkF-0006Se-D8 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 21:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBD2h3Be024832 for mpowr-archive@odin.ietf.org; Fri, 12 Dec 2003 21:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUzkF-0006SR-4l for mpowr-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 21:43: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 VAA10172 for ; Fri, 12 Dec 2003 21:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUzkC-0000gC-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 21:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUzkB-0000g5-00 for mpowr-web-archive@ietf.org; Fri, 12 Dec 2003 21:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUzkD-0006R4-Cf; Fri, 12 Dec 2003 21:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUzjG-0006Mp-FS for mpowr@optimus.ietf.org; Fri, 12 Dec 2003 21:42:02 -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 VAA10118 for ; Fri, 12 Dec 2003 21:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUzjD-0000dz-00 for mpowr@ietf.org; Fri, 12 Dec 2003 21:41:59 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AUzjC-0000dY-00 for mpowr@ietf.org; Fri, 12 Dec 2003 21:41:58 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Fri, 12 Dec 2003 20:41:28 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Fri, 12 Dec 2003 20:41:26 -0600 To: Margaret.Wasserman@nokia.com From: Pete Resnick Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Cc: Dave Crocker , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , On 12/12/03 at 5:48 PM -0500, Margaret.Wasserman@nokia.com wrote: >>A chair does not need the authority to say no in order to get >>technical reviews assigned, do a technical writeup, or track >>outstanding issues. They already have full authority to accomplish >>those tasks. > >Some of this may be a terminology issue... > >Do you think that a WG chair should be allowed to hold a document >(i.e. not submit it to the IESG) while the chair seeks sufficient >cross-area review? Or do you think that a chair is obligated to >send a document to the IESG as soon as the WG has consensus to do >so, even if, it is the opinion of the chair that the document >requires more cross-area review before it is ready to advance? I don't think the answers to those questions are mutually exclusive, and I think they might both be "yes", but it may take a bit to explain. Someone earlier in the week thought I might be able to address a comment by Dave Crocker: >Specifically, there is no consensus that WG chairs should _ever_ be >authorized to overrule WG consensus. by replaying something I talked about at the Vienna chair training session about consensus. I think it may also be helpful to answer Margaret's query: Rough consensus is about a meeting of minds in a WG. If a WG is working the way it should, with everyone talking to each other "in good faith", it's pretty easy to figure out when the group has come to rough consensus. However, it is perfectly plausible that a WG chair could try to judge consensus in a WG (one of their responsibilities in 2418, sec. 3.3) and finds no consensus even if almost everyone is saying the same thing. (I used an example of a real WG in Vienna; this example is completely hypothetical.) Suppose 99% of the members of a WG list pipe up on the list and say, "In our document on the Foo protocol, we think the 23rd byte of the packet should always have the value Bar." One member of the list, Pete, pipes up and says, "Wait a minute, if you put Bar in the 23rd byte of the packet, every IP router on the Internet will crash in this very obvious way", laying out a very nice technical argument that seems exactly right, and 5 people give support to the argument. The rest of the 200 members of the WG continue to say, "No, we all agree that Bar should go in the 23rd byte." When asked about Pete's comment, every one of them gives answers of the form, "Well, Pete's an idiot, so that can't be right" or "Who cares? I'm just deploying this on a closed network" or "I don't like Pete and his supporters, so I think we should leave it as-is for spite". If I'm the chair of this WG, I might very well decide that there is *no* consensus to but Bar in the 23rd byte because people in the WG are not addressing each other's arguments. In fact, I might say, "Since there has been a strong argument by Pete that putting Bar in the 23rd byte is bad, some well-reasoned support for that position, and no one else in the WG has seen fit to put in a real argument against, there *is* rough consensus to *not* have Bar in the 23rd byte", instruct the document editor to make the change, and not hand the Foo document to the IESG until said change was made. Such a WG could appeal my decision. They should lose such an appeal. On the other hand, if those other 200 people gave reasoned technical arguments for why it is perfectly safe to put Bar in the 23rd byte, even if they can't convince those other 5, and even if I personally disagree with their reasoning, I shouldn't hold that document. If I did and they appealed, they should win the appeal (and likely I should be fired as WG chair). It is the chair's job to judge consensus and communicate it. However, sometimes that doesn't amount to blindly counting votes or listening to hums. So in answer to your original questions: Yes, a chair can hold a document while seeking cross-area review. If the 99% of the WG shouts, "No, send it along, we don't care if it's had review", that's *not* consensus in the WG that the document has had enough review. However, if the WG *has* come to consensus that there's been plenty of cross-area review already during WG discussions, yes, I think the chair obligated to send it along, even if the chair thinks it needs more. However, both scenarios paint a rather gloomy picture: In the first, the WG has lost its mind; they're not coming to consensus about a document, they're just making unfounded claims. In the latter, the chair has failed pretty significantly. If WG discussion has gone along this far and the chair is the only one left at the end of the discussion who thinks more review is required (meaning also that they didn't get that review done before the rest of the WG started kicking and screaming that the document was ready to go), the chair blew it months ago. The chair should probably get the boot. What we've got is a complete process breakdown at that point, and I'm willing to say that it should be the IESG that sorts it out at that point. Introducing some sort of new "authority" the chair has to overrule consensus isn't addressing the problem in the least. Chairs have plenty of authority to judge consensus now, and in the normal course of events, that will allow them to hold a document when there hasn't been sufficient cross-area review. However, it won't allow them to usurp the consensus of the WG. Did that answer the question? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Dec 14 07:55:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12473 for ; Sun, 14 Dec 2003 07:55:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVmG-0006Xg-UK for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 07:55:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBECtFuv025134 for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 07:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVmE-0006XC-9A for mpowr-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 07:55:14 -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 HAA12463 for ; Sun, 14 Dec 2003 07:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVVmC-0004KO-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 07:55:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVVmB-0004KL-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 07:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVm8-0006Wq-Hr; Sun, 14 Dec 2003 07:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV2jp-0004VE-Fe for mpowr@optimus.ietf.org; Sat, 13 Dec 2003 00:54:49 -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 AAA13629 for ; Sat, 13 Dec 2003 00:54:45 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV2jm-0003mG-00 for mpowr@ietf.org; Sat, 13 Dec 2003 00:54:46 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AV2jm-0003mD-00 for mpowr@ietf.org; Sat, 13 Dec 2003 00:54:46 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBD5skn24854 for ; Sat, 13 Dec 2003 07:54:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 07:54:42 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 13 Dec 2003 07:54:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Dec 2003 07:54:42 +0200 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcPA8FYdkuGCPtLBSkGG76XwLx7AtQAARFAAABLyaEA= To: Cc: , X-OriginalArrivalTime: 13 Dec 2003 05:54:42.0978 (UTC) FILETIME=[9ABD7820:01C3C13D] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pete, > Right now any AD can, of his or her own choosing and without any=20 > change in 2026 or 2418, decide to make their WG chairs responsible=20 > for the technical writeup of documents, resolving last call issues,=20 > and shepherding of the document through the IESG including resolving=20 > discuss issues. An AD can choose to do this now without asking the=20 > IETF for any consensus whatsoever. One reason for formalizing this would be to avoid some arbitrary-ness in interpreting how WGs are run in different areas, or when=20 ADs change. It is already noticable that different areas are run quite different in the IETF from each other. On most topics, it isn't a bid deal, but I do think we are running into some=20 problems because of it, and it does effect the document quality & speed at which some documents get completed. John _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Dec 14 08:42:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12474 for ; Sun, 14 Dec 2003 07:55:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVmG-0006Xf-Nr for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 07:55:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBECtFkZ025131 for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 07:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVmD-0006XB-QK for mpowr-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 07:55:14 -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 HAA12460 for ; Sun, 14 Dec 2003 07:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVVmC-0004KK-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 07:55:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVVmB-0004KF-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 07:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVVm5-0006WR-0M; Sun, 14 Dec 2003 07:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV2fs-0004QY-26 for mpowr@optimus.ietf.org; Sat, 13 Dec 2003 00:50:44 -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 AAA13535 for ; Sat, 13 Dec 2003 00:50:39 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV2fp-0003fc-00 for mpowr@ietf.org; Sat, 13 Dec 2003 00:50:41 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AV2fo-0003fZ-00 for mpowr@ietf.org; Sat, 13 Dec 2003 00:50:40 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBD5odn22025 for ; Sat, 13 Dec 2003 07:50:39 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Dec 2003 07:50:39 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 13 Dec 2003 07:50:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Dec 2003 07:50:37 +0200 Message-ID: Thread-Topic: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Thread-Index: AcPA+yiaji1xcbb+TemHcaYBOnyzHQAQavUw To: Cc: , X-OriginalArrivalTime: 13 Dec 2003 05:50:37.0928 (UTC) FILETIME=[08ADCE80:01C3C13D] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jim, > This is a recipe for driving people away. If you give someone the > responsibility to do something, they better have the authority to = accomplish > the task. Otherwise, who would take the job? I agree with you - to put it another way - who would want the job with more stuff to do (i.e. - responsibility) but no more ability to get it done (i.e. - authority). John _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Dec 14 17:16:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27904 for ; Sun, 14 Dec 2003 17:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeWx-0005AB-Lw for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 17:16:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEMG2Tx019838 for mpowr-archive@odin.ietf.org; Sun, 14 Dec 2003 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeWu-00059f-HV for mpowr-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 17:16:00 -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 RAA27870 for ; Sun, 14 Dec 2003 17:15:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVeWn-0004Wx-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 17:15:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVeWN-0004Wn-00 for mpowr-web-archive@ietf.org; Sun, 14 Dec 2003 17:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeW1-00058k-Od; Sun, 14 Dec 2003 17:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVYUC-00038j-OH for mpowr@optimus.ietf.org; Sun, 14 Dec 2003 10:48:48 -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 KAA16840 for ; Sun, 14 Dec 2003 10:48:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVYUA-0006hr-00 for mpowr@ietf.org; Sun, 14 Dec 2003 10:48:46 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AVYU9-0006hn-00 for mpowr@ietf.org; Sun, 14 Dec 2003 10:48:45 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7CDA0AFC7A; Sun, 14 Dec 2003 10:48:45 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12782-11; Sun, 14 Dec 2003 10:48:44 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5EC08AFBF1; Sun, 14 Dec 2003 10:48:40 -0500 (EST) In-Reply-To: <313436998.1070959744@localhost> References: <313436998.1070959744@localhost> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17A2C000-2E4D-11D8-97F7-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , solutions@alvestrand.no, mpowr@ietf.org From: Keith Moore Date: Sun, 14 Dec 2003 10:49:25 -0500 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.606) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal (fwd) 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't believe this is an appropriate way to proceed. Forming a new WG, or even an informal discussion group, that presumes the desirability of a particular outcome isn't going to foster community-wide consensus about whether or not that outcome is desirable. Instead, it's going to increase division within the community, because the new group will disproportionately attract participants who think that that outcome is desirable. It may also attract a few participants who disagree with that premise and are interested in doing "damage control" but those people will have to work very hard to argue their views to a skeptical group that is not representative of IETF as a whole. That and once any WG has worked for a while on a dubious idea, a lot of pressure is created for IESG to endorse that dubious idea on IETF's behalf. More broadly, I'm concerned that with the creation of several narrowly-focused working groups we are fragmenting the discussion of how to improve IETF in a nonproductive way. For instance, it may well be that IETF would produce better output in a more timely fashion if WGs and/or WG chairs had more responsibility and more authority - but the specifics of _what_ kind of authority and _how much_ authority will improve IETF's output won't naturally emerge from a group that asks the question of _whether_ WGs should have more authority, and especially not from a group that has shifting more authority to WGs as an explicit goal. It's natural that IESG should view this problem in a top-down fashion - their immediate concern is "how do we shed load", which translates almost directly to "how do we give WGs more responsibility". But to make this work the problem needs to be studied bottom-up. i.e., we need to be studying: - first, how to do better engineering of protocols (more timely, more widespread confidence in the soundness of the output); - second, what changes to WG operation would support better protocol engineering; and - third, what shifts in responsibility/authority between WGs and upper management would best facilitate these changes in WG operation Keith On Dec 9, 2003, at 11:49 AM, Harald Tveit Alvestrand wrote: > This is of interest to the Solutions list. > > ---------- Forwarded Message ---------- > Date: 9. desember 2003 10:10 -0500 > From: The IESG > To: IETF-Announce > Subject: Further work on WG (chair) roles - MPOWR WG proposal > > Hi All, > > At IETF 58, the IESG presented a proposal to build a more effective > IETF management structure by moving more authority and responsibility > from the IESG to our ~220 IETF WG chairs. This message summarizes > some of the feedback we received and proposes that the community > consider the formation of a specific WG to pursue this topic. The > process of WG formation would use the following steps: > > - creation of a mailing list to discuss the scope & purpose of the > proposed WG > > - discussion/development of a charter on the list > > - approval of WG charter by IESG (if appropriate) > > Subscription information for the mailing list is provided below. > > BACKGROUND > ========== > > The slides for our original proposal, as presented at the IETF 58 > plenary, can be found at: > > http://www.alvestrand.no/ietf/nov2003-minneapolis/iesg-wgchairs.pdf > > The minutes from the two IETF 58 plenary sessions, including > discussion of this proposal can be found at: > > http://www.alvestrand.no/ietf/nov2003-minneapolis/plenary-notes.txt > > FEEDBACK > ======== > > We received substantial feedback regarding the proposal, both during > the plenaries and elsewhere. Thank you, and keep it coming! While we > heard enough community interest that a further exploration seems > warranted, a number of valid concerns were also raised. For example: > > - The community should not increase the authority and > responsibility of WG chairs without correspondingly > increasing > their accountability to the IETF community. For example, we > need > to be careful that we do not create situations where WG > chairs > can unfairly overrule WG consensus. > > - Our original timeline was unrealistic and did not offer enough > opportunity for community involvement and feedback. The > community would prefer to discuss and develop potential > changes > to our BCPs through an open process, such as an IETF WG. > > - For any proposal of change, thought must be given to a long > enough transition period and some experimental deployment > that will help the community determine the impact before > IETF-wide implementation. > > - The community needs to consider the motivations of WG chairs, > document editors and active WG participants, to ensure that > any > changes will not substantially decrease the number of people > willing to serve in these roles. > > We will be modifying our original proposal in response to this > feedback, and submitting it as an Internet-Draft. > > Proposed MPOWR Working Group > ============================ > > WG Name: MPOWR (Management Positions - Oversight, Work and Results) > > Mailing list: mpowr@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/mpowr > Archives: https://www1.ietf.org/mailman/listinfo/mpowr > > Expected WG home: General Area > > The broad goal of this WG would be to shift more responsibility and > authority to WGs, while ensuring appropriate accountability to the > IETF as a whole. The WG would consider how to move more authority and > responsibility to WGs from the IESG, reviewing both the benefits and > the impacts, and ensuring appropriate accountability to the community. > The expected charter would likely include considering updates to RFCs > 2418 and possibly RFC 2026 to support these changes. Depending upon > how charter discussions go, the group could hold a BOF or a first WG > meeting at IETF 59 in Korea. > > We will send a strawman charter for this WG to the mpowr@ietf.org > mailing list. Community discussion and feedback can take place there. > If and when the community reaches consensus on a charter for a WG, the > charter will be submitted for approval through the usual IETF WG > creation process. > > The IESG will revise its proposal, and submit it as an Internet-Draft > for discussion and consideration by the proposed WG. > > Additional proposals for changes in this area are welcome and should > be published as Internet-Drafts and announced on mpowr@ietf.org. > > If you are interested in participating in this effort, please > subscribe to the mpowr@ietf.org mailing list, as described above. > > If you have suggestions regarding who should (co-)chair this proposed > WG, if and when it is chartered, please send them to Harald Alvestrand > . > > > > > > ---------- End Forwarded Message ---------- > > > > > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 12:28:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17509 for ; Mon, 15 Dec 2003 12:28:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwVm-0005Zk-5k for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 12:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFHS2kb021426 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 12:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwVm-0005ZV-01 for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:28:02 -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 MAA17491 for ; Mon, 15 Dec 2003 12:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwVk-0001AH-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 12:28:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVwVk-0001AE-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 12:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwVl-0005ZE-13; Mon, 15 Dec 2003 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwVb-0005Z2-Qd for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 12:27:51 -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 MAA17485 for ; Mon, 15 Dec 2003 12:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwVa-0001AA-00 for mpowr@ietf.org; Mon, 15 Dec 2003 12:27:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AVwVZ-0001A6-00 for mpowr@ietf.org; Mon, 15 Dec 2003 12:27:49 -0500 Message-ID: <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> From: "James Kempf" To: "Dave Crocker" Cc: "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> Date: Mon, 15 Dec 2003 09:28:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave, > It depends on the defined task. If the task is "coordination", then the > responsibility for tracking document state is entirely appropriate. It > does not need accompanying "authority". > > Let me suggest that "authority" is looking more and more like exactly > the wrong construct for fixing IETF problems. Focusing on authority > ensures that we will need to have curbs against abuse, because there are > certain to be some abuses. > > What is needed is facilitating collaboration. This means that > "authority" rests with collections of people who reach agreements. Any > individual who appears to have authority has it by virtue of delegation > from a collection of participants, for the purpose of efficiency. > I think it does involve authority. 2026 only allows the WG chair to judge rough concensus. If there is rough concensus then the chair must forward the document to the IESG, regardless of how broken (s)he may think it is. Given the current rules in 2026, the WG chair can't simply hold the document for review and send it to a third party group of reviewers, like SIRS, then come back and insist that the WG fix the problems. (S)he can only do that if the reviewing party is the IESG. And the chair can't even send along a list of problems (s)he thinks need attention and request that the review group pay particular attention to, even if it is the IESG. The chair is expected to represent the WG concensus to the IESG, nothing more. We're facing this problem right now in Seamoby. We sent one document out to a review committee at my request (I'm the co-chair), and it came back with a list of problems the reviewers wanted to see fixed. But the reviewer's comments were not any more binding on the design than any others, and the WG members quibbled with the reviewers on the WG list until the reviewers gave up, essentially a successful DoS attack. This isn't "co-ordination", because the WG chair is making a judgement about the need for enforcable QA on the spec, just as a manager would when doing software development. If you don't like the word "authority" then pick another one. > Let's take the specific case of a rogue working group and a > knowlegeable, diligent chair. How is the chair -- or the AD -- to > "control" the wayward choices of a misguided working group? Surely the > superior expertise of the chair should prevail? > > The problems with assuming that the chair has that expertise, and then > assuming that it will always be applied properly. We are not suddenly > going to select better Chairs. Some have enough of the relevant types of > expertise and some do not. Some will invoke it wisely and some will not. > > Let me suggest, instead, that the core test mechanism in the IETF > is the ability to recruit others to a point of view. > > Hence, the expertise of the Chair (or anyone else, for that matter) > should be used to recruit a collection of _other_ participants to > counter the misguided views of the working group. > > One might even think that independent, senior IETF reviewers might be > helpful to this goal... > See comments above. Unless the review makes enforcable changes, it's not worth anything. The WG can continue to quibble until the reviewers give up. There needs to be some check on WGs that don't deliver quality. If you don't like the WG chair exercising their design judgement enforcably, then they at least need to be able to decide what they don't like and submit it, along with the document, to some third party group that has the power (sorry for swearing) to enforce quality. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 13:00:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18443 for ; Mon, 15 Dec 2003 13:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0u-0006k0-0q for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 13:00:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFI0Bg3025881 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 13:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0q-0006jF-Fv for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 13:00: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 NAA18434 for ; Mon, 15 Dec 2003 13:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVx0o-0001gx-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 13:00:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVx0o-0001gu-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 13:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0o-0006ig-78; Mon, 15 Dec 2003 13:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvqT-000330-Pu for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 11:45:22 -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 LAA16122 for ; Mon, 15 Dec 2003 11:45:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvqS-0000S9-00 for mpowr@ietf.org; Mon, 15 Dec 2003 11:45:20 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AVvqS-0000S3-00 for mpowr@ietf.org; Mon, 15 Dec 2003 11:45:20 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBFGppf14263; Mon, 15 Dec 2003 08:51:51 -0800 Date: Mon, 15 Dec 2003 08:44:42 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <165181922.20031215084442@brandenburg.com> To: "James Kempf" CC: MPowr , solutions@alvestrand.no In-Reply-To: <028201c3c0fb$332bd220$666015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, >> I thought I heard a good deal of comment that shifting some >> *responsibility* to the chairs was a good idea. On the other hand, I >> agree: I certainly heard no consensus about shifting *authority*. JK> This is a recipe for driving people away. If you give someone the JK> responsibility to do something, they better have the authority to accomplish JK> the task. Otherwise, who would take the job? It depends on the defined task. If the task is "coordination", then the responsibility for tracking document state is entirely appropriate. It does not need accompanying "authority". Let me suggest that "authority" is looking more and more like exactly the wrong construct for fixing IETF problems. Focusing on authority ensures that we will need to have curbs against abuse, because there are certain to be some abuses. What is needed is facilitating collaboration. This means that "authority" rests with collections of people who reach agreements. Any individual who appears to have authority has it by virtue of delegation from a collection of participants, for the purpose of efficiency. Let's take the specific case of a rogue working group and a knowlegeable, diligent chair. How is the chair -- or the AD -- to "control" the wayward choices of a misguided working group? Surely the superior expertise of the chair should prevail? The problems with assuming that the chair has that expertise, and then assuming that it will always be applied properly. We are not suddenly going to select better Chairs. Some have enough of the relevant types of expertise and some do not. Some will invoke it wisely and some will not. Let me suggest, instead, that the core test mechanism in the IETF is the ability to recruit others to a point of view. Hence, the expertise of the Chair (or anyone else, for that matter) should be used to recruit a collection of _other_ participants to counter the misguided views of the working group. One might even think that independent, senior IETF reviewers might be helpful to this goal... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 13:00:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18458 for ; Mon, 15 Dec 2003 13:00:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0v-0006kQ-GJ for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 13:00:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFI0Dn2025932 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 13:00:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0u-0006kB-OT for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 13:00:12 -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 NAA18438 for ; Mon, 15 Dec 2003 13:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVx0s-0001h3-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 13:00:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVx0s-0001h0-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 13:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVx0t-0006jT-Af; Mon, 15 Dec 2003 13:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVw3q-0003j9-4t for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 11:59:10 -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 LAA16590 for ; Mon, 15 Dec 2003 11:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVw3o-0000iI-00 for mpowr@ietf.org; Mon, 15 Dec 2003 11:59:09 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AVw3n-0000i3-00 for mpowr@ietf.org; Mon, 15 Dec 2003 11:59:08 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBFH5Tf15319; Mon, 15 Dec 2003 09:05:29 -0800 Date: Mon, 15 Dec 2003 08:58:21 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1687762035.20031215085821@brandenburg.com> To: Margaret.Wasserman@nokia.com CC: presnick@qualcomm.com, sob@harvard.edu, mpowr@ietf.org, solutions@alvestrand.no In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret, MWnc> I don't believe that it would be meaningful to say that the IETF MWnc> has consensus about a concept as vague as moving responsibility MWnc> or authority in any particular direction. But, based on the results MWnc> of the plenary poll, there did seem to be significant support for MWnc> the IESG's proposal to move more authority and responsibility to WG MWnc> chairs. Given your response to Scott, the additional point to make is that: "Based on the results of the plenary poll, there also did seem to be significant support for _not_ moving more "authority" to working group chairs. This is not a small matter of "tuning" the IESG proposal. It represents a fundamental disagreement with the authority aspects of the model the IESG proposed. Please recall that a major concern raised in the Problems working group was with to much concentration of power. Authority is power. We solve nothing by taking too much power concentrated into ADs and moving it to Chairs. In fact, we exacerbate things significantly, since Chairs are chosen through an opaque mechanism and -- more significantly -- are certain to be have less experience than ADs. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 14:20:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21127 for ; Mon, 15 Dec 2003 14:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyGE-0002I2-Aa for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 14:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFJK6xd008788 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 14:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyGC-0002Hf-Qy for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 14:20:04 -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 OAA21120 for ; Mon, 15 Dec 2003 14:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyGA-00034l-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 14:20:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVyG9-00034i-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 14:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyGB-0002HM-CM; Mon, 15 Dec 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyG7-0002Gd-Tl for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 14:19:59 -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 OAA21117 for ; Mon, 15 Dec 2003 14:19:57 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyG5-00034d-00 for mpowr@ietf.org; Mon, 15 Dec 2003 14:19:57 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AVyG4-00034a-00 for mpowr@ietf.org; Mon, 15 Dec 2003 14:19:56 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFJJtn06643 for ; Mon, 15 Dec 2003 21:19:55 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 21:19:53 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 13:19:37 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Date: Mon, 15 Dec 2003 14:19:36 -0500 Message-ID: Thread-Topic: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Thread-Index: AcPDIY8LtA6LPiopTC+yF6ZupehLZwAFuyiw To: , Cc: , X-OriginalArrivalTime: 15 Dec 2003 19:19:37.0764 (UTC) FILETIME=[61807E40:01C3C340] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi John, I find that I must respectfully disagree with you. > * While it may be difficult to do so, it is ultimately more > reasonable to judge _IETF_ consensus on a procedural issue by > surveying comments on a wide-participation list than it is to > judge it from a narrowly-constituted WG AFAIK, we don't have any effective mechanism to reach a large percentage of the IETF population that doesn't select for some specific group. Any WG activity and/or process-specific mailing list (such as poised, solutions, problem...) will select for people who have the time and inclination to work on process-oriented activities. However, they do allow everyone who is interested in those discussions to participate. We get, by far, the highest number of respondents when we conduct polls at the plenaries, and perhaps those polls are our best way to judge "IETF consensus". However, they select for people who can afford to attend the meetings, and they are usually limited to simple (yes/no) questions. We do not get a strong enough response to any IETF Last Calls to believe that they reach a large representative sampling of the IETF population. > * Any decisions coming out of the WG will be subject to IESG > approval. If the IESG does not approve, then the WG becomes a > waste of time. If the IESG knows of things of which it will > approve, then, if it believes there is some basis in community > consensus, it is free to make the changes today. That leaves a > (probably very small, IMO) area in which the IESG possibly > prefers to not do something, but might be persuaded by a large > community consensus. But, again, a narrow-focus WG is not the > best was to demonstrate such consensus. This assumes that the IESG already knows every possibility for improving the IETF, and can pre-judge everything that might come out of such a WG. Personally, I trust the community to come up with some good ideas that I would not come up with on my own. The IESG does not have perfect knowledge of the IETF, nor do we encompass the perspectives of all participants. So, I believe that wider community involvement in improving the IETF is needed, not just community review, at an IETF Last Call level, of=20 IESG-developed plans. > * As Pete and others have pointed out, most of the things that a > WG might decide to permit or require under this proposed charter > are already within the scope of authority of a WG Chair ... > assuming that the relevant AD decides to interpret the scope and > authority that way. There are two different sets of changes: - Changes that fall within the current bounds of RFCs 2418 and 2026. - Changes that would require modifications to our BCPs. I agree with you that the IESG can unilaterally enact changes that=20 fall into the first category, and I think we should. Some ADs are=20 already running some experiments in their areas. We're also forming=20 the PROTO Team to do some focused work in this area, and to come up with a set of recommendations to the IESG regarding what types of experiments should be run and eventually what changes should be=20 made. I do NOT believe that it is the perogative of the IESG=20 (hisory not withstanding) to enact changes that lie outside the bounds of RFCs 2418 and 2026. Those changes can only be enacted through community consensus. =20 I agree with you that there are some options, other than a WG,=20 for achieving community review and consensus, but I don't see other options that will allow for the breadth of community input that a well-run WG could allow.=20 =20 > (1) Let's have those ADs who are enthused about transferring > more authority and responsibility to WG Chairs, do it. Within the bounds of RFCs 2418 and 2026, we are already working on this. Some ADs are already running experiments, and we're forming the PROTO Team to provide a focused effort in this area. There is nothing about the proposed WG that should delay these efforts, and I do not think that the IESG can (or will) use=20 "lack of community consensus" as an excuse for not improving the procedures and tools that we developed without any community involvement in the first place. While "just do it" sounds very compelling, we don't want to cause=20 confusion and/or create serious problems that will seriously delay=20 work within the IETF. So, we are "just doing it" more carefully=20 than you might be suggesting. However, I think that the community can (and should) push the IESG to produce results in this area, as well as in the area of early cross-area review. =20 I will, personally, be extremely disappointed in the IESG if we=20 can't show some significant progress in the following two areas by ~March 2004: - Improving the scalability, openness and effectiveness of our internal procedures and tools, particularly=20 improving the visibility and control that WGs have over their documents in the later stages of document processing. - Improving the level of cross-area review that is done outside the IESG, particularly earlier in the process. To me, significant progress would include some specific plans=20 for improvements that may be implemented in 2004, early reports from some ongoing experiments, etc. > Just > make an announcement about what you are expecting WG Chairs to > do and that you will rubber-stamp that action, without delay, > when it gets to you as AD.=20 Some of this is already being done. It isn't clear that individual ADs can run all of the experiments that we'd like to see run. =20 For instance, I'd like WG chairs to have the authority to temporarily=20 suspend the posting privileges of disruptive mailing list participants,=20 but that isn't something I can "just do", since it is not within my=20 perogative to approve the suspension -- the whole IESG needs to approve=20 it.=20 Also, there are two ADs in most areas, so we need to reach some=20 agreement with our co-ADs about what experiments will/won't be run=20 within each area. In most cases, this type of moderating influence is probably a good thing. > (2) The other major concern that has been voiced involves WG > Chairs abusing their (possibly new-found) power. But WG Chairs > serve more or less at the pleasure of ADs. An abuse can be > discussed with the relevant AD (the procedures are pretty clear > about that). If the AD refuses to do anything, that situation > can be appealed (that is less clear from the procedures, but, > IMO, it would be completely rational for the community to > consider recalling any AD who said "my nit-picking reading of > the procedures doesn't permit an appeal in this case, so I vote > to reject it without considering the issues"). I more-or-less agree that this should be sufficient chain of accountability, but unfortunately there are some well-respected=20 and outspoken members of the community who do not agree. So, we need to do some more work before we can any reach consensus in this area. =20 > If, once we have the output from this type of experimental > process, we conclude that the relevant BCPs need rewriting (as I > suspect we will), that is the right time to form WGs, if needed. > They will, at that point, have firm experience behind them to > evaluate. But, right now, I think the criterion for forming > more WGs ought to be "there is evidence that we need to do X, > and we can't even try that without a change in procedures". I think that there is evidence that we need to give WG Chairs more authority to control WG mailing lists. I also think that we want to give WG chairs the authority to hold the WG to a set of internal WG processes that may include criteria for accpetance at various stages and/or certain amounts of cross-area or expert review. Some people say that RFCs 2418 and 2026 already empower WG chairs=20 to do those things, but other argue that having WG chairs do these things would violate RFCs 2418 and 2026... People who have been in my WGs and/or my WG Chairs training know where I fall, but=20 my view is certainly not universal. So, at the very least, it=20 would be nice if our BCPs were less ambiguous about the responsibility=20 and authority of WG chairs. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 15:01:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23329 for ; Mon, 15 Dec 2003 15:01: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 1AVyts-0004Cq-DO for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 15:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFK14li016157 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 15:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyts-0004CV-1V for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 15:01:04 -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 PAA23289 for ; Mon, 15 Dec 2003 15:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyto-00047n-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 15:01:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVyto-00047g-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 15:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVytq-0004BT-8j; Mon, 15 Dec 2003 15:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyt7-00049M-Lz for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 15:00:17 -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 PAA23246 for ; Mon, 15 Dec 2003 15:00:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyt4-00045B-00 for mpowr@ietf.org; Mon, 15 Dec 2003 15:00:14 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AVyt4-00044D-00 for mpowr@ietf.org; Mon, 15 Dec 2003 15:00:14 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Mon, 15 Dec 2003 13:59:43 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Mon, 15 Dec 2003 13:59:41 -0600 To: "James Kempf" From: Pete Resnick Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Cc: "Dave Crocker" , "MPowr" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , On 12/15/03 at 9:28 AM -0800, James Kempf wrote: >We're facing this problem right now in Seamoby. We sent one document >out to a review committee at my request (I'm the co-chair), and it >came back with a list of problems the reviewers wanted to see fixed. >But the reviewer's comments were not any more binding on the design >than any others, and the WG members quibbled with the reviewers on >the WG list until the reviewers gave up, essentially a successful >DoS attack. Depending on the details here, I don't think you need any additional authority to hold this document. It's for exactly the same reasons that a big company can't (or shouldn't be able to) "pack a room" at the IETF and win by a majority: A huge bunch of people agreeing to something does not make a rough consensus when there is a significant though smaller group of folks who disagree and the larger group isn't willing to justify their position. So in your case: If you had a reasonable size reviewer committee (not just 1 or 2 people), that means that you've got a significant number of folks who think there are real problems with the document. Once they started commenting on the documents, they effectively became part of the WG. If by "gave up", you mean they simply stopped posting responses in disgust (as opposed to eventually agreeing with the rest of the WG), then you can reasonably say that your WG did *not* come to rough consensus on those issues. You can say, "Look folks, there are well-argued open issues on the list. I have heard quibbles, but I have heard nothing so far that actually addresses those issues. That's people talking past eachother, but it's not rough consensus. I won't pass the documents on until we achieve rough consensus." Now, if you only had 1 or 2 reviewers and they were unable to garner any additional support, or if the reviewers really did agree with the rest of the WG and you're the only one left, or if the WG actually gave well-reasoned arguments why the outstanding issues aren't really problems but you happen to disagree with them, then you *should* declare rough consensus and pass the document on. If the problems with the document are really that bad, then there should be a reasonable contingent that will object when IETF Last Call comes around and their won't be IETF-wide consensus. But mind you, if it comes down to that, the process broke down long ago: Either there weren't enough intelligent people in the WG to do reasonable work (in which case it shouldn't have been chartered), or something got out of control in the WG some time ago. That can and will happen in WGs, but giving more formal authority to WG chairs isn't addressing that problem. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 15:53:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28865 for ; Mon, 15 Dec 2003 15:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVziD-0006X1-3T for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 15:53:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFKr5S1025101 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 15:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVziC-0006Wm-Rh for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 15:53:04 -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 PAA28853 for ; Mon, 15 Dec 2003 15:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVziB-0007Zj-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 15:53:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AVzi9-0007ZS-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 15:53:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVzi9-0007ZO-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 15:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzi9-0006W3-Eo; Mon, 15 Dec 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzhw-0006Vi-LI for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 15:52:48 -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 PAA28831 for ; Mon, 15 Dec 2003 15:52:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVzhu-0007Yp-00 for mpowr@ietf.org; Mon, 15 Dec 2003 15:52:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AVzht-0007Yh-00 for mpowr@ietf.org; Mon, 15 Dec 2003 15:52:46 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AVzht-0007Yc-00 for mpowr@ietf.org; Mon, 15 Dec 2003 15:52:45 -0500 Message-ID: <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> From: "James Kempf" To: "Pete Resnick" Cc: "Dave Crocker" , "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Date: Mon, 15 Dec 2003 12:53:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, I disagree. I see nothing in 2026 or 2418 that gives a WG chair the authority to hold a document because they believe there are flaws in the design. Rough concensus doesn't mean one person objects, it means some significant number, over a majority object. Besides, if the WG chair does hold the document, what are they supposed to do with it? Under the current rules, the only alternative is for the chair to get on the list and try to work the concensus behind what they believe is the correct solution, and presumably they've tried that already (if they've been a good chair). To go on the list again would just be a DoS attack on the WG chair's time. So the chair can either submit the document to the IESG and let them deal with it (thereby increasing overload) or try to convince the WG that they're making a mistake. I suppose a chair could submit the document to the IESG with a list of flaws that the chair thinks need to get fixed, but even that is going outside of what 2026 and 2418 prescribe as the WG chair's role. The chair is just supposed to represent WG concensus. There is also a point about the role of reviews that I perhaps did not articulate clearly. The point is that the reviewers are outside the WG, so that they function like a traditional QA team in software development, as a check on the spec developers (and thus on WG concensus); otherwise, the utility of the reviews is limited. Thus, they are not, strictly speaking, subject to WG concensus. I don't think it would be helpful to go into microsurgery on the example I gave, but in that particular case, several of the reviewers did, in fact, get involved in the list discussion precisely *because* their reviews had no authority to change WG concensus under current rules, so trying to influence concensus was the only way they could get their changes instituted (to their credit). I agree with Margaret's basic contention: the WG chairs need the authority to be able to hold specs because, in their design judgement, the spec is flawed. If that's possible, then there needs to be some mechanism for resolving those problems, and a third party review sounds right (in addition to reviews at other times, like when a draft goes to WG draft status). I also think (and this impinges on the ICAR charter a little) that any review mechanism needs to be binding on the WG, just as third party QA is in software development. Otherwise, the reviews are of little value. jak ----- Original Message ----- From: "Pete Resnick" To: "James Kempf" Cc: "Dave Crocker" ; "MPowr" ; Sent: Monday, December 15, 2003 11:59 AM Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal > On 12/15/03 at 9:28 AM -0800, James Kempf wrote: > > >We're facing this problem right now in Seamoby. We sent one document > >out to a review committee at my request (I'm the co-chair), and it > >came back with a list of problems the reviewers wanted to see fixed. > >But the reviewer's comments were not any more binding on the design > >than any others, and the WG members quibbled with the reviewers on > >the WG list until the reviewers gave up, essentially a successful > >DoS attack. > > Depending on the details here, I don't think you need any additional > authority to hold this document. It's for exactly the same reasons > that a big company can't (or shouldn't be able to) "pack a room" at > the IETF and win by a majority: A huge bunch of people agreeing to > something does not make a rough consensus when there is a significant > though smaller group of folks who disagree and the larger group isn't > willing to justify their position. > > So in your case: If you had a reasonable size reviewer committee (not > just 1 or 2 people), that means that you've got a significant number > of folks who think there are real problems with the document. Once > they started commenting on the documents, they effectively became > part of the WG. If by "gave up", you mean they simply stopped posting > responses in disgust (as opposed to eventually agreeing with the rest > of the WG), then you can reasonably say that your WG did *not* come > to rough consensus on those issues. You can say, "Look folks, there > are well-argued open issues on the list. I have heard quibbles, but I > have heard nothing so far that actually addresses those issues. > That's people talking past eachother, but it's not rough consensus. I > won't pass the documents on until we achieve rough consensus." > > Now, if you only had 1 or 2 reviewers and they were unable to garner > any additional support, or if the reviewers really did agree with the > rest of the WG and you're the only one left, or if the WG actually > gave well-reasoned arguments why the outstanding issues aren't really > problems but you happen to disagree with them, then you *should* > declare rough consensus and pass the document on. If the problems > with the document are really that bad, then there should be a > reasonable contingent that will object when IETF Last Call comes > around and their won't be IETF-wide consensus. But mind you, if it > comes down to that, the process broke down long ago: Either there > weren't enough intelligent people in the WG to do reasonable work (in > which case it shouldn't have been chartered), or something got out of > control in the WG some time ago. That can and will happen in WGs, but > giving more formal authority to WG chairs isn't addressing that > problem. > -- > Pete Resnick > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 17:20:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03159 for ; Mon, 15 Dec 2003 17:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW14T-0002I0-CS for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 17:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMK9E0008796 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 17:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW14S-0002Hn-DR for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 17:20: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 RAA03154 for ; Mon, 15 Dec 2003 17:20:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW14Q-0003eW-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 17:20:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW14O-0003eO-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 17:20:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW14O-0003eL-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 17:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW14M-0002H4-Nw; Mon, 15 Dec 2003 17:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW14C-0002GG-2y for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 17:19:52 -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 RAA03146 for ; Mon, 15 Dec 2003 17:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW149-0003di-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW147-0003dK-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:19:49 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AW146-0003ae-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:19:47 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Mon, 15 Dec 2003 16:19:16 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Mon, 15 Dec 2003 16:19:14 -0600 To: "James Kempf" From: Pete Resnick Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Cc: "Dave Crocker" , "MPowr" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 12/15/03 at 12:53 PM -0800, James Kempf wrote: >I disagree. I see nothing in 2026 or 2418 that gives a WG chair the >authority to hold a document because they believe there are flaws in >the design. I don't know with whom you're disagreeing, because I never said that and I don't believe that. I don't believe a WG chair has the authority to hold a document because they believe there are flaws in the design, nor do I believe that a chair should have such authority. I said that the chair can hold a document if there is not rough consensus in the WG that the document is ready to go to the IESG. >Rough concensus doesn't mean one person objects, Agreed. >it means some significant number, over a majority object. And with that I disagree. Though it is almost always true that a rough consensus *is* over a majority of people agreeing, sometimes it's not. Sometimes it's a significant *minority* agreeing and the majority not feeling strongly at all. That's part of the reason we often do hums instead of straw polls: Sometimes it's not a matter of the majority, but the strength of the agreement or disagreement. If I've got a WG with 2 people who propose that "X" should be in a protocol, 100 people who express a preference for "X" but don't care strongly one way or the other, and 20 people who object that "X" will actively cause damage, there is *not* rough consensus to put "X" in the protocol. >Besides, if the WG chair does hold the document, what are they >supposed to do with it? Post to the list, "There is still a significant number of outstanding objections to X, Y, and Z, and nobody here has either persuaded the objectors that their problems have been addressed or given any reason why the objections should be ignored. Until those issues are addressed, we do not have rough consensus in this working group to pass the document on to the IESG." >Under the current rules, the only alternative is for the chair to >get on the list and try to work the concensus behind what they >believe is the correct solution , and presumably they've tried that >already (if they've been a good chair). First of all, no, the chair should not work for what *they* believe is the correct solution (at least in their role as chair). The chair can try to get the two sides to come to consensus, but shouldn't push their own agenda. But second of all, even if we're talking about 1 or 2 individuals, section 6.5.1 of 2026 addresses *exactly* this problem: The chair tries to resolve the dispute, and if not then bring it to the AD, and then the IESG, and then the IAB. I suppose if the chair is the *only* person objecting (and I want to know how *that* happened), this process can also be used, just starting from the AD. And again, if we've already gotten to this point by the time the WG is asking for IETF Last Call, there was a serious management breakdown long ago, and I don't want the remedy for that to be "let the chair veto anything they feel like". That will only encourage lousy chairs to leave their objections to the end of the process and then trump. >There is also a point about the role of reviews that I perhaps did >not articulate clearly. The point is that the reviewers are outside >the WG, so that they function like a traditional QA team in software >development, as a check on the spec developers (and thus on WG >concensus); otherwise, the utility of the reviews is limited. Thus, >they are not, strictly speaking, subject to WG concensus. I'm sorry, but this is just nonsense. The point of these kinds of reviews is to get input from folks who wouldn't normally be participating in the WG (due to time constraints or field of expertise), but not to have some sort of unchecked authority over the WG. The IETF is a consensus organization (that's where the "authority" lies), so *of course* reviews are subject to WG consensus. And of course the reviews are still of value. Your entire scenario for them not being of value is that we have a completely rouge WG which refuses to listen. We should not be designing our procedures around that sort of world view. >I don't think it would be helpful to go into microsurgery on the >example I gave, but in that particular case, several of the >reviewers did, in fact, get involved in the list discussion >precisely *because* their reviews had no authority to change WG >concensus under current rules, so trying to influence concensus was >the only way they could get their changes instituted (to their >credit). That I think is exactly the right way to go. Or, if the WG simply refused to heed their reviews, they could have objected under 2026, 6.5.1. >I agree with Margaret's basic contention: the WG chairs need the >authority to be able to hold specs because, in their design >judgement, the spec is flawed. I have yet to hear any reasoned explanation for why this authority is necessary given our other procedures. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 18:30:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06001 for ; Mon, 15 Dec 2003 18:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2A9-0004Zy-6j for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 18:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFNU5Ef017598 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 18:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2A8-0004Zl-UO for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 18:30:05 -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 SAA05998 for ; Mon, 15 Dec 2003 18:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2A6-0005Ns-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 18:30:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2A5-0005Nl-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 18:30:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW2A4-0005Ni-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 18:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2A5-0004ZD-Cc; Mon, 15 Dec 2003 18:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW29M-0004Yo-SC for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 18:29:16 -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 SAA05974 for ; Mon, 15 Dec 2003 18:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW29J-0005MX-00 for mpowr@ietf.org; Mon, 15 Dec 2003 18:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW29E-0005Lw-00 for mpowr@ietf.org; Mon, 15 Dec 2003 18:29:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AW29E-0005Li-00 for mpowr@ietf.org; Mon, 15 Dec 2003 18:29:08 -0500 Message-ID: <04ac01c3c363$48b42510$5b6015ac@dclkempt40> From: "James Kempf" To: "Dave Crocker" Cc: "Pete Resnick" , "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Date: Mon, 15 Dec 2003 15:29:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave, > JK> any review mechanism needs to be binding on the WG, > > This moves us back to the "authority" focus, rather than the "consensus" > focus. Certainly a working group is obligated to deal with comments it > receives. But what does it mean for those comments to be "binding"? > Going down that path gets more complicated, because then we must deal > with questions about the expertise and intent of the reviewer. > To my mind, it means the same thing as in software product development when the QA team comes back to the development group with a list of bugs that caused their regression tests to fail: the code doesn't go to the customers until the development group has fixed the problems. What would you call this if "authority" doesn't sound right? The product group manager isn't acting as a dictator, he's trying to make sure the product is salable. The division director isn't going to let him/her ship their code to customers until the bugs are fixed because they both know that the customers won't buy it. Presumably the QA group was selected for their expertise (otherwise, they wouldn't have gotten the job) and their intent is the same as for the product development group: to ensure that the product is of the highest possible quality so customers buy it. Both the development group and the product group manager know this, as does the QA group. The product development manager gets to say when adequate QA has been done, and typically that's based on his/her judgement about the impact of the remaining bugs on customer usability. I don't see much difference here from the case we are discussing, do you? I don't want to imply by this that the only check on quality should be a final review, quite the contrary. Early review is far better as a quality check, and the WG should also be responsible for coming up with their own quality review plan. BTW, quality review plans are now starting to show up in new proposed charters. > Working groups are usually diligent at dealing with comments. When they > aren't, it provides further examples that the wg is rogue. > Well, obviously we have had different experiences in this area. What's your definition of rogue? That they don't live up to their charter or try to exceed it? What if they fufill the charter but the result of what they come up with is poorly designed? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 21:22:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12220 for ; Mon, 15 Dec 2003 21:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4qb-00020W-8u for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 21:22:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG2M53S007715 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 21:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4qb-00020M-3a for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 21:22:05 -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 VAA12186 for ; Mon, 15 Dec 2003 21:22:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW4qY-0003fa-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 21:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW4qV-0003fO-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 21:22:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW4qV-0003fL-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 21:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4qW-0001zj-RW; Mon, 15 Dec 2003 21:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4qA-0001zI-Ff for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 21:21:38 -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 VAA12168 for ; Mon, 15 Dec 2003 21:21:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW4q7-0003dp-00 for mpowr@ietf.org; Mon, 15 Dec 2003 21:21:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW4q5-0003dg-00 for mpowr@ietf.org; Mon, 15 Dec 2003 21:21:35 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AW4q3-0003db-00 for mpowr@ietf.org; Mon, 15 Dec 2003 21:21:31 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AW4py-000F8l-00; Mon, 15 Dec 2003 21:21:26 -0500 Date: Mon, 15 Dec 2003 21:21:26 -0500 From: John C Klensin To: Margaret.Wasserman@nokia.com, presnick@qualcomm.com cc: mpowr@ietf.org, solutions@alvestrand.no Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Message-ID: <97768643.1071523286@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, 15 December, 2003 14:19 -0500 Margaret.Wasserman@nokia.com wrote: > > Hi John, > > I find that I must respectfully disagree with you. > >> * While it may be difficult to do so, it is ultimately more >> reasonable to judge _IETF_ consensus on a procedural issue by >> surveying comments on a wide-participation list than it is to >> judge it from a narrowly-constituted WG > > AFAIK, we don't have any effective mechanism to reach a large > percentage of the IETF population that doesn't select for some > specific group. > > Any WG activity and/or process-specific mailing list (such as > poised, solutions, problem...) will select for people who have > the time and inclination to work on process-oriented > activities. However, they do allow everyone who is interested > in those discussions to participate. They do not. They allow everyone who is interested in those discussions and can put up with the near-infinite N/S ratio to participate. And that is a small subset of the number of people who are materially concerned with the outcome. Please also note that, as soon as you say that we have no effective mechanism to get IETF community consensus on _anything_ (and you haven't said that, but you are getting close), then we either need to accept the notion that some group has oracular powers to determine consensus or you are proposing that we are out of business. And, while there are members of the community who believe the IESG acquires oracular powers on installation, I don't... and I know you don't either. > We get, by far, the highest number of respondents when we > conduct polls at the plenaries, and perhaps those polls are > our best way to judge "IETF consensus". However, they select > for people who can afford to attend the meetings, and they are > usually limited to simple (yes/no) questions. I would certainly be very concerned if there appeared to be a difference of opinion on an issue between a large number of people at a plenary and a smaller number on a mailing list, despite the greater openness of a mailing list. I would be especially concerned if the difference arose on a procedural matter rather than an engineering one. And my concern would be independent of which side I found myself on. > We do not get a strong enough response to any IETF Last Calls > to believe that they reach a large representative sampling of > the IETF population. See comments above about inability to determine consensus without an Oracle. Also note that I consider "not enough response to Last Calls" and "people comment lavishly on documents they haven't read" to be, at best, symptoms of IETF problems that ought to have high-order bits set. I don't believe that IESG review, no matter how many hours a week people put in, can really substitute for either cross area checks by the community or review and discussion after reading documents. If the workflow is too high to make that plausible, then we need to attack the workflow (whether it hits IESG, WG Chairs, or the community first). Whether they were good solutions or bad ones, the Huston-Rose and O'Dell-Klensin I-Ds of a year or so ago were intended to address the workflow problem. Things that have been under discussion lately discuss ways of moving work around, but not ways to change the total workload to a level that the community can effectively manage and cope with. And, yes, largely as a result, I've gotten impatient with process-diddling (or arguments about process- diddling) that don't address those basic issues of meaningful review and meaningful consensus. >> * Any decisions coming out of the WG will be subject to IESG >> approval. If the IESG does not approve, then the WG becomes a >> waste of time. If the IESG knows of things of which it will >> approve, then, if it believes there is some basis in community >> consensus, it is free to make the changes today. That leaves >> a (probably very small, IMO) area in which the IESG possibly >> prefers to not do something, but might be persuaded by a large >> community consensus. But, again, a narrow-focus WG is not the >> best was to demonstrate such consensus. > > This assumes that the IESG already knows every possibility for > improving the IETF, and can pre-judge everything that might > come out of such a WG. Personally, I trust the community to > come up with some good ideas that I would not come up with on > my own. I am _not_ suggesting or requiring that the IESG be the source of ideas. I am suggesting that there are a lot of ideas floating around already (the ones represented in your I-D included). I'm getting closer to offering some more. I am suggesting that some serous triage of those ideas by the IESG, with the IESG really being willing to take responsibility for what they/you like and don't like, would be in order. I'd be really pleased to see the IESG take the ideas that have been floating around and divide them into * "Good idea, let's do it" * "Terrible idea, we won't accept it under any circumstances" * The community needs to think more about this, work through tradeoffs, and advise us further. Bluntly, if the IESG were to put everything into the third category, either because you (collectively) didn't have an opinion about what would be helpful and what wouldn't, or because you couldn't agree, or because any attempt to have the discussion deteriorated into nit-picking, then I think it is time to start firing IESG members. And I'd like to see the community have more hints about who to fire. If some significant number of things were assigned the first category, and were implemented, it might generate enough interest to get some valuable, but totally frustrated right now, people into the discussions about the third category and additional ideas. > The IESG does not have perfect knowledge of the IETF, nor do > we encompass the perspectives of all participants. So, I > believe that wider community involvement in improving the IETF > is needed, not just community review, at an IETF Last Call > level, of IESG-developed plans. Margaret, the IESG regularly behaves as if it has perfect knowledge, not only of the IETF, but of everything that affects the protocol suite. As far as I can tell, the IESG has concluded that its knowledge and understanding is great enough that it is appropriate for them to exercise a complete gating function on all important Internet innovations (and maybe all unimportant ones as well). A decade or so ago, we could get HTTP developed and deployed, and even assigned a system port, without unanimous IESG agreement that it was a good thing and met all IESG criteria for protocol design. To digress a bit further, there is a huge difference between saying "the IETF functions as a standards body and, if you want the IETF seal of approval, you must satisfy the community, and the IESG as representative of that community, that you have met the IETF's criteria" and saying "in order to do something that is fully functional on the Internet, you need IESG approval". The IESG, with _no_ authorization from any procedural BCP or charter (even if such a document could grant that sort of authority), seems to be rapidly sliding toward the latter. And that, IMnvHO, is bad for the IETF and bad for the Internet. But, if the IESG can believe that it has sufficient depth and breath of understanding to set itself up for that level of gating function, then, sorry, but it is reasonable for the rest of us to assume that level of omniscience should extend to figuring out what the IETF needs. On the other hand, if these things really do require community involvement, and I agree that they do, then I suggest the community, or the (declining) fraction of the community that cares and is willing to put up with the noise), has been involved since Yokohama. The question is what the stopping rule is; when we shift from proposals and discussion to implementation. I am suggesting, based partially by subjective estimates of participation drop-off and the number of new and plausible suggestions coming in, that "now" would be a good time to make that shift (and that it may already be some months too late). And my problem with MPOWR, is that I don't see stopping rules, only an opportunity for more discussion, more generation of suggestions that may not be much different from those already on the table, and, finally, another review point at which you (and I _know_ you are not the worst offender by a wide margin) say "well, the IESG can't know everything it needs to know, so we need another discussion and another WG". At the risk of sounding like, and maybe agreeing with, Dave Crocker, Yokohama was 17 months ago this week, I don't see any significant changes that have resulted from community discussion, so I have to question the value of further discussion of that type. >> * As Pete and others have pointed out, most of the things >> that a WG might decide to permit or require under this >> proposed charter are already within the scope of authority of >> a WG Chair ... assuming that the relevant AD decides to >> interpret the scope and authority that way. > > There are two different sets of changes: > > - Changes that fall within the current bounds of RFCs > 2418 and 2026. > > - Changes that would require modifications to our BCPs. > > I agree with you that the IESG can unilaterally enact changes > that fall into the first category, and I think we should. > Some ADs are already running some experiments in their areas. > We're also forming the PROTO Team to do some focused work in > this area, and to come up with a set of recommendations to the > IESG regarding what types of experiments should be run and > eventually what changes should be made. Good. > I do NOT believe that it is the perogative of the IESG > (hisory not withstanding) to enact changes that lie outside > the bounds of RFCs 2418 and 2026. Those changes can only > be enacted through community consensus. I would like to agree with you. I will do so the moment the IESG starts vigorously rolling back all of the changes it has made in violation of those documents and the boundaries they set. Otherwise, I contend that the IESG can't both * make the changes that appeal to them, independent of existing BCPs and * not make changes for which there seems to be plausible community consensus, but about which the IESG cannot reach unanimity, by citing those existing BCPs as a reason. From my point of view, other reasons, carefully explained and ideally identifying differences in position within the IESG and who holds which ones, would be extremely welcome. But not either appeal to documents that the IESG feels free to ignore on other occasions or "death by sequential WGs". Others probably have other lists, but, from my perspective, I would like to see the IESG roll back, as a start on change and evidence of good faith... (i) AD approval reviews, with arbitrarily long time allowances, between when a WG asks for a Last Call on a document and when the Last Call is issued. We don't need to do it that way. Yes, if a WG asks for an IETF Last Call without a good mutual understanding with the relevant AD, and the AD doesn't look at the document again until the Last Call is under way, the WG risks a nasty late surprise. But the WG should be able to make that decision. (ii) No reviews of documents independently submitted to the RFC Editor that go beyond the "end run" and "potential harm" criteria. And no interpretation of "end run" as "hold publication until some WG, or combination of WGs, have completed their work, even if that is forever. Disclaimers, yes. Encouraging the RFC Editor to push back on authors for more clarification of where their ideas fit in the grand scheme of things, yes. Deep holes into which to throw things, no. And ignoring timeouts... no to that too: The IESG asked for, and negotiated, the current review process and the review process documented in 2026. If the IESG doesn't consider the reviews important enough to do on a timely basis, then the IESG should figure out a way to get out of that business (which might include letting some things go and trusting the RFC Editor to decide). (iii) No IESG rejections of port or protocol assignment requests to IANA unless the IESG is able to reach consensus to reject and supply reasons to the requester that can be made public and that will withstand laugh tests. If the IESG cannot reach such consensus, and do so quickly, it is a decision that this review task, which the IESG assigned itself, is not important enough and the request should go through. Just examples, of course, and maybe not the most important ones. I may try to for another list, and more details, soon. > I agree with you that there are some options, other than a WG, > for achieving community review and consensus, but I don't see > other options that will allow for the breadth of community > input that a well-run WG could allow. The problem isn't the running of the WG. The problem is involvement by a significant fraction of the active, working-on-protocols or other substantive WGs, community. It looks to me as if MPOWR is going to attract a subset of those who are (still?) involved in Solutions, and that is an unrepresentative enough group that it should make you as nervous as it makes me. >> (1) Let's have those ADs who are enthused about transferring >> more authority and responsibility to WG Chairs, do it. > > Within the bounds of RFCs 2418 and 2026, we are already working > on this. Some ADs are already running experiments, and we're > forming the PROTO Team to provide a focused effort in this > area. There is nothing about the proposed WG that should delay > these efforts, and I do not think that the IESG can (or will) > use "lack of community consensus" as an excuse for not > improving the procedures and tools that we developed without > any community involvement in the first place. I don't share your confidence. Of course, I don't expect to hear "lack of community consensus". Instead, I'd just expect the ideas to go swimming around the bottom of some rathole until the IESG decides that it likes them enough to stop nit-picking (or doing whatever causes things to be thrown into such holes). > While "just do it" sounds very compelling, we don't want to > cause confusion and/or create serious problems that will > seriously delay work within the IETF. So, we are "just doing > it" more carefully than you might be suggesting. > > However, I think that the community can (and should) push the > IESG to produce results in this area, as well as in the area of > early cross-area review. Ok. We agree. I consider these notes to be part of doing that pushing, even if not quite the way you might like. > I will, personally, be extremely disappointed in the IESG if > we can't show some significant progress in the following two > areas by ~March 2004: 20 months after Yokohama. > - Improving the scalability, openness and effectiveness > of our internal procedures and tools, particularly > improving the visibility and control that WGs have > over their documents in the later stages of document > processing. > > - Improving the level of cross-area review that is done > outside the IESG, particularly earlier in the process. I would definitely consider those things to be worthwhile accomplishments. Do you have, and are you willing to discuss, your contingency plan if you find yourself "significantly disappointed"? To state that differently, if I believed we would be there by March 2004 (although I'd add a few other things to the list... hints above), I would be settling down and working on MPOWR, or whatever you suggested would get us there, rather than complaining in this way and proposing alternatives. After 17 months, I lack that confidence. If you have a plan about what we do if I turned out to be right and no significant changes occurred by March, then I'm still willing to wait and participate. But I am concerned that, come March, we will still be exchanging these sorts of notes and that little will have occurred of significance other than the expenditure of more time, bits, and hot air. Moreover, as you know, I tend to be a lot more concerned about organizational behavior than about rule-structures. The latter are, at best, an accurate reflection of organizational behavior and culture; they don't cause either. If there are forces within the IESG that are acting to block progress in these areas, or that are likely to (continue to) ignore any rules the community sets, they need to be identified to the Nomcom a long time before March. > To me, significant progress would include some specific plans > for improvements that may be implemented in 2004, early reports > from some ongoing experiments, etc. My standards may be a tad higher, too. If it were three or four months past Yokohama, yes. But, for 20 months out,... >> Just >> make an announcement about what you are expecting WG Chairs to >> do and that you will rubber-stamp that action, without delay, >> when it gets to you as AD. > > Some of this is already being done. > > It isn't clear that individual ADs can run all of the > experiments that we'd like to see run. > > For instance, I'd like WG chairs to have the authority to > temporarily suspend the posting privileges of disruptive > mailing list participants, but that isn't something I can > "just do", since it is not within my perogative to approve > the suspension -- the whole IESG needs to approve it. Ahem. And who made the rule that the whole IESG needs to approve this? The IESG. Without commenting on whether or not it is a good rule or a bad one, you could get that rule changed by convincing the IESG and the IESG alone. And, if you are sufficiently convinced that changing it is important, you could propose that to the IESG and, if you couldn't get agreement, identify to the community the IESG members who didn't like it. > Also, there are two ADs in most areas, so we need to reach > some agreement with our co-ADs about what experiments > will/won't be run within each area. In most cases, this type > of moderating influence is probably a good thing. Sure. But I also keep being told that, increasingly, ADs are dividing up the work in areas and not having much involvement with each other's WGs. Personally, I think that, if true, is an unfortunate trend. But you can't have a "those WGs are yours, and these are mine, and we don't interfere with each other" model and control over each other's experiments and management styles. One or the other. And, again, the spirit of openness would permit the two ADs involved to come forward and tell the community "I favored the following experiment, and she didn't, and we couldn't even reach agreement on doing it with some WGs and not others". Maybe the community would accept that. Maybe the community would decide it wasn't important. Maybe the community would retire one or both of you (via the Nomcom or via recall). I'm not convinced that any of those would be bad outcomes. >> (2) The other major concern that has been voiced involves WG >> Chairs abusing their (possibly new-found) power. But WG >> Chairs serve more or less at the pleasure of ADs. An abuse >> can be discussed with the relevant AD (the procedures are >> pretty clear about that). If the AD refuses to do anything, >> that situation can be appealed (that is less clear from the >> procedures, but, IMO, it would be completely rational for the >> community to consider recalling any AD who said "my >> nit-picking reading of the procedures doesn't permit an >> appeal in this case, so I vote to reject it without >> considering the issues"). > > I more-or-less agree that this should be sufficient chain of > accountability, but unfortunately there are some > well-respected and outspoken members of the community who do > not agree. So, we need to do some more work before we can any > reach consensus in this area. And how will you decide when you have consensus? Do you expect some poor sucker who gets the job of MPOWR chair to make that call? Do you assume that more discussion between the people who are sure that 2026/ 2148 provide all of the flexibility and authority needed (at least assuming the ADs back people up) and the people are believe that documents would need to be rewritten in a major way will change enough minds for a clear consensus to emerge? Is the IESG going to accept it when that WG Chair claims consensus or apply its own judgment? If the latter, can it just apply that judgment now? >> If, once we have the output from this type of experimental >> process, we conclude that the relevant BCPs need rewriting >> (as I suspect we will), that is the right time to form WGs, >> if needed. They will, at that point, have firm experience >> behind them to evaluate. But, right now, I think the >> criterion for forming more WGs ought to be "there is evidence >> that we need to do X, and we can't even try that without a >> change in procedures". > > I think that there is evidence that we need to give WG Chairs > more authority to control WG mailing lists. I also think that > we want to give WG chairs the authority to hold the WG to a > set of internal WG processes that may include criteria for > accpetance at various stages and/or certain amounts of > cross-area or expert review. > > Some people say that RFCs 2418 and 2026 already empower WG > chairs to do those things, but other argue that having WG > chairs do these things would violate RFCs 2418 and 2026... Margaret, even a narrow reading of 2418 and 2026 -- much more narrow than the IESG has applied when it suits their purposes-- says that the ADs, and the IESG, has most or all of this authority. I can find nothing in either document that says "the AD has to do all of this himself or herself". So, if an AD says to a WG Chair (and the WG), "I want you to do X using your own best judgment. When you do it, do it in my name and I promise to back you", the WG Chair gets the authority and _no_ procedures are being violated. Now the community may decide it doesn't like that. It might scream at the nomcom for the AD to be removed, or initiate a recall, or start burning people in effigy. And it might be entirely rational for an AD to decide that he or she is to afraid of those outcomes to do anything. But the authority and ability to do it certainly exists. > People who have been in my WGs and/or my WG Chairs training > know where I fall, but my view is certainly not universal. > So, at the very least, it would be nice if our BCPs were less > ambiguous about the responsibility and authority of WG chairs. Sure. But either * the IESG has to lead the community, change the documents, and take the heat, or * the IESG has to lead, propose a process with some stopping rules in it that will actually lead to consensus and results, or * we will be having this discussion in six months. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 15 23:14:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15390 for ; Mon, 15 Dec 2003 23:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW6az-0005UL-AN for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 23:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG4E5ZU021091 for mpowr-archive@odin.ietf.org; Mon, 15 Dec 2003 23:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW6ay-0005U6-VE for mpowr-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 23:14:05 -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 XAA15377 for ; Mon, 15 Dec 2003 23:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW6ax-00070N-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 23:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW6au-0006zw-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 23:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW6au-0006zt-00 for mpowr-web-archive@ietf.org; Mon, 15 Dec 2003 23:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW6av-0005TL-CN; Mon, 15 Dec 2003 23:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW6aV-0005Sm-VC for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 23:13:36 -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 XAA15356 for ; Mon, 15 Dec 2003 23:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW6aU-0006yO-00 for mpowr@ietf.org; Mon, 15 Dec 2003 23:13:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW6aS-0006yH-00 for mpowr@ietf.org; Mon, 15 Dec 2003 23:13:33 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AW6aS-0006xn-00 for mpowr@ietf.org; Mon, 15 Dec 2003 23:13:32 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Mon, 15 Dec 2003 22:13:02 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <04ac01c3c363$48b42510$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Mon, 15 Dec 2003 22:13:00 -0600 To: "James Kempf" From: Pete Resnick Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Cc: "Dave Crocker" , "MPowr" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FORGED_MUA_EUDORA autolearn=no version=2.60 On 12/15/03 at 3:29 PM -0800, James Kempf wrote: >>Certainly a working group is obligated to deal with comments it >>receives. But what does it mean for those comments to be "binding"? > >To my mind, it means the same thing as in software product >development when the QA team comes back to the development group >with a list of bugs that caused their regression tests to fail: the >code doesn't go to the customers until the development group has >fixed the problems. I'm going to ignore the elephant standing in the room for the moment and actually stick to your analogy: If the QA team finds bugs, it might be the case that the code doesn't go to the customer. Or not. If the development team comes back and says, "We've told you 20 times that the regression test you people in QA are doing is wrong, doesn't represent any customer scenario, and should be eliminated; we are not going to waste time fixing that bug because it won't effect anybody", the software might very well ship. Or perhaps the answer is, "That bug was found too late in the process, and it's not like it lops the head off of the user; it's a minor user interface flub" and the software will ship. Or maybe the development team lead goes to the head of QA and says, "Well, I agree, this bug should be fixed. But the folks actually doing the coding don't agree, so either we let the bug slide, or if you really want I can make a big stink and pass it up to management to deal with." And if push comes to shove, you start firing developers if it really is something that they need to fix and they refuse. In the development organizations I've been a part of, either development agrees with QA (which happens almost all of the time), in which case they fix the bugs, or they don't, in which case either the code ships (because QA was wrong or because it wasn't worth arguing about) or the management that oversees both groups makes the call. Such cases getting to management are rare, I have yet to see upper-level management fire someone over such a dispute, and there has been no need to give the development lead direct "firing authority". Of course, we do have similar backstops in the IETF (specifically 2026 section 6.5.1 which I mentioned before), but like the scenario above, that should kick in and make it all the way up the chain only when the WG in question has completely lost its mind. Folks can appeal up the chain, and the IESG can shut down the WG if it's gone astray. And there's no reason to give the chair the individual power to say "no" if there's no one else saying no. >What would you call this if "authority" doesn't sound right? The >product group manager isn't acting as a dictator, he's trying to >make sure the product is salable. The division director isn't going >to let him/her ship their code to customers until the bugs are fixed >because they both know that the customers won't buy it. Presumably >the QA group was selected for their expertise (otherwise, they >wouldn't have gotten the job) and their intent is the same as for >the product development group: to ensure that the product is of the >highest possible quality so customers buy it. Both the development >group and the product group manager know this, as does the QA group. >The product development manager gets to say when adequate QA has >been done, and typically that's based on his/her judgement about the >impact of the remaining bugs on customer usability. I don't see much >difference here from the case we are discussing, do you? So here's that elephant in the room: *Of course* there's a difference, and I'm a little concerned that you don't see it. Companies like the one you describe are strict hierarchies. The top of the company has the most to gain or lose (monetarily) based on the outcome of the efforts of the folks below. The folks further up the chain get to choose who is going to do the work below. If the upper folks don't like the work being done by the lower folks, they get new lower folks to do the work. The upper folks hire some sets of lower folks to check the work of the other lower folks. Everything is very congenial so long as everyone more or less cooperates. But outside of everything working smoothly, you bet it's a dictatorship. Though it's nice when there is a consensus among all of the groups, if there's not, management has easy ways to solve that problem. The IETF is not like that. The IETF is a consensus organization. We have different levels of consensus (e.g., inside the WG, the whole IETF), but at the end of the day, it's the entire population who decides whether the work is up-to-snuff. We have some procedures to make sure people don't make dumb mistakes along the way (including having some folks we think are smart do some final reviews of our work), and we've got some management structure to deal with things when all hell breaks loose, but even there it's not like the company you describe: The IESG can shut down a WG or say "no" to a document, but even in those cases, the IESG is supposed to try to resolve the conflict and bring the group back to consensus, not just veto. And if in the end we can't come to consensus with management, the rest of us can appeal the decision of the management, and if we decide that they are simply not doing the right thing, we can get rid of them using the recall process (or in the extreme, as happened in 1992, change the management structure altogether). Yes, that means we have given our management a good deal of responsibility and not very much final authority. There are some things that are made really hard by being in an open-membership consensus-based organization. Maybe it would be nice if it were otherwise. Personally, I kind of like it this way. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 10:55:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20947 for ; Tue, 16 Dec 2003 10:55:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHXV-0007z7-DP for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 10:55:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFtDjD030693 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 10:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHXV-0007yy-6z for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:55: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 KAA20842 for ; Tue, 16 Dec 2003 10:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHXS-0007SV-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 10:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHXK-0007R4-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 10:55:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHXJ-0007R1-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 10:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHXK-0007y8-Ge; Tue, 16 Dec 2003 10:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHWg-0007ue-VE for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 10:54:23 -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 KAA20684 for ; Tue, 16 Dec 2003 10:54:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHWe-0007JB-00 for mpowr@ietf.org; Tue, 16 Dec 2003 10:54:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHWb-0007In-00 for mpowr@ietf.org; Tue, 16 Dec 2003 10:54:20 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AWHWb-0007IT-00 for mpowr@ietf.org; Tue, 16 Dec 2003 10:54:17 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBGFsF8K021389; Tue, 16 Dec 2003 16:54:16 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Dec 2003 16:54:15 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'John C Klensin'" Cc: mpowr@ietf.org, solutions@alvestrand.no Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MP OWRWG proposal Date: Tue, 16 Dec 2003 16:53:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 A very good summary, I strongly believe in such an evolutionary way forward. /L-E > -----Original Message----- > From: mpowr-admin@ietf.org [mailto:mpowr-admin@ietf.org]On Behalf Of > John C Klensin > Sent: den 15 december 2003 16:39 > To: Pete Resnick; Margaret.Wasserman@nokia.com > Cc: mpowr@ietf.org; solutions@alvestrand.no > Subject: RE: [mpowr] Re: [Solutions] Further work on WG > (chair) roles - > MPOWRWG proposal > > > Hi. > > I continue to believe, and this discussion illustrates, that we > are going around in circles rather than solving problems. Given > the prior and long-standing IESG position that it can make any > policy on processing of standards that isn't explicitly > prohibited (and maybe some that are), and that any document > coming out of a WG is subject to IESG approval, I suggest > (again) the following: > > * While it may be difficult to do so, it is ultimately more > reasonable to judge _IETF_ consensus on a procedural issue by > surveying comments on a wide-participation list than it is to > judge it from a narrowly-constituted WG, especially a WG that > competes with others and is populated primarily by people who > are more interested in process than in technical work. If the > IESG needs a Last Call to calibrate community preferences/ > consensus, the IESG is empowered (or has empowered itself) to > issue a Last Call on substantially anything, at substantially > any time. > > * Any decisions coming out of the WG will be subject to IESG > approval. If the IESG does not approve, then the WG becomes a > waste of time. If the IESG knows of things of which it will > approve, then, if it believes there is some basis in community > consensus, it is free to make the changes today. That leaves a > (probably very small, IMO) area in which the IESG possibly > prefers to not do something, but might be persuaded by a large > community consensus. But, again, a narrow-focus WG is not the > best was to demonstrate such consensus. > > * As Pete and others have pointed out, most of the things that a > WG might decide to permit or require under this proposed charter > are already within the scope of authority of a WG Chair ... > assuming that the relevant AD decides to interpret the scope and > authority that way. > > So... > > (1) Let's have those ADs who are enthused about transferring > more authority and responsibility to WG Chairs, do it. Just > make an announcement about what you are expecting WG Chairs to > do and that you will rubber-stamp that action, without delay, > when it gets to you as AD. If different ADs come up with > slightly different details and formulas, so much the better: I > agree with Melinda that most of the issues are in the substance > and fine details, but we will learn far more about what is > workable with a few experiments than with endless speculative > debate... and we will learn it _much_ more quickly. If other > ADs try to block this without good reason, write an open letter > to the WG explaining the blockage (don't just put a cryptic > entry into the I-D tracker) and copy the Nomcom. If one AD is > seen as blocking things sufficiently, the WG membership can > presumably find the recall procedures. It is time to put a stop > to the endless looping on this subject. > > (2) The other major concern that has been voiced involves WG > Chairs abusing their (possibly new-found) power. But WG Chairs > serve more or less at the pleasure of ADs. An abuse can be > discussed with the relevant AD (the procedures are pretty clear > about that). If the AD refuses to do anything, that situation > can be appealed (that is less clear from the procedures, but, > IMO, it would be completely rational for the community to > consider recalling any AD who said "my nit-picking reading of > the procedures doesn't permit an appeal in this case, so I vote > to reject it without considering the issues"). > > If, once we have the output from this type of experimental > process, we conclude that the relevant BCPs need rewriting (as I > suspect we will), that is the right time to form WGs, if needed. > They will, at that point, have firm experience behind them to > evaluate. But, right now, I think the criterion for forming > more WGs ought to be "there is evidence that we need to do X, > and we can't even try that without a change in procedures". > Given the precedents of authority the IESG has claimed for > itself in the past, I don't think this one meets that test. > > Do we think we can get more protection than that from more > procedures? Personally, I doubt it. And, if the answer is > "no", we have, I think, just exhausted the topic list for this > proposed WG. > > john > > > --On Friday, December 12, 2003 20:41 -0600 Pete Resnick > wrote: > > >... > > Chairs have plenty of authority to judge consensus now, and in > > the normal course of events, that will allow them to hold a > > document when there hasn't been sufficient cross-area review. > > However, it won't allow them to usurp the consensus of the WG. > >... > > > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:06:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21530 for ; Tue, 16 Dec 2003 11:06:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHi1-00009Q-C0 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:06:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGG65NV000574 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHi0-00009B-V1 for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:06:05 -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 LAA21500 for ; Tue, 16 Dec 2003 11:06:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHhy-0000Mx-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHhw-0000Mj-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:06:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHhw-0000Mg-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHhy-00008R-Ob; Tue, 16 Dec 2003 11:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHhQ-000064-9J for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:05:28 -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 LAA21462 for ; Tue, 16 Dec 2003 11:05:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHhN-0000L2-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHhK-0000Ka-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:25 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AWHhJ-0000KN-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:22 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBGG5GVY015641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2003 08:05:16 -0800 (PST) Received: from [64.134.94.169] (vpn-10-50-0-17.qualcomm.com [10.50.0.17]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBGG5D0O004079; Tue, 16 Dec 2003 08:05:14 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <97768643.1071523286@scan.jck.com> References: <97768643.1071523286@scan.jck.com> Date: Tue, 16 Dec 2003 08:05:12 -0800 To: John C Klensin , Margaret.Wasserman@nokia.com, presnick@qualcomm.com From: Ted Hardie Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Cc: mpowr@ietf.org, solutions@alvestrand.no Content-Type: text/plain; charset="us-ascii" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.6 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 There is a lot in John's original message, including a great deal of emotion. Without wishing to indicate a lack of interest or concern with the other points or over that emotion, I've made comments on a few points below. > >They do not. They allow everyone who is interested in those discussions and can put up with the near-infinite N/S ratio to participate. And that is a small subset of the number of people who are materially concerned with the outcome. > >Please also note that, as soon as you say that we have no effective mechanism to get IETF community consensus on _anything_ (and you haven't said that, but you are getting close), then we either need to accept the notion that some group has oracular powers to determine consensus or you are proposing that we are out of business. And, while there are members of the community who believe the IESG acquires oracular powers on installation, I don't... and I know you don't either. On your first point, having focused groups allows the chairs to ask for (and sometimes get) the conversations to stick to the points in the charter. That can help the n/s ratio. Having a system in which you have a staged series of lists (IETF for very broad discussion on the nature of the IETF, solutions for discussions on what needs to be done, focused groups for specific areas of work) does make for complex procmail rules, but it can help. It may not allow for everyone materially concerned with the outcome to participate, but it does show people where to concentrate their efforts to match their interests. On your second point, I note the wisdom of not trying to get community consensus on some things. We don't pick folks for the IAB, as an example, by community consensus. The IETF decided a long time ago to constitute a specific group for that task (the NomCom); the rules under which the NomCom works are in the -bis stages of revision, but that does not mean we changed to consensus for those decisions. Community consensus might pick different people, but the costs of that seem to be outweighed by the benefits of the other process. I personally believe that the work Solutions is discussing falls into two different camps: work for which small groups can go off and "just do it" and work for which community involvement and buy-in is so critical that any change, even if functionally perfect, would fail if done outside of the normal process because the community wouldn't agree to work under a system it hadn't a hand in designing. Scott's recent BoF on the new standards track is an example of the second; it is clear to me that community consensus on this type of change is critical for the change to succeed. The EDU team seems to me an example of the former, as the development of new training materials kind of falls into a "just do it" category. We may disagree about where ICAR, PROTO, and MPOWR fall in those two categories, but I think we agree that the two categories exist. Getting more work on the "just do it" category done now may be the biggest short term win. It's been hard to do for many reasons, including both the emotional attachment people have to certain ways of doing things and the tendency of some us (including me) to want to think about the whole system, including the eventual mechanisms needed for ongoing change. > I am suggesting that some serous triage of those ideas by the IESG, with the IESG really being willing to take responsibility for what they/you like and don't like, would be in order. The IESG has publicly said that they/we would accept whatever change the community decided on. We have lost two members since that statement and gotten one new one, but I think the decision stands. We have and are trying to facilitate work on ideas we think the community has agreed to discuss. That's "triage" of a very different sort, though. > > * the IESG has to lead the community, change the > documents, and take the heat, or Speaking personally, I think what you are seeing is us, trying both to listen to the community on the work that needs to be done and lead a sometimes highly contentious community effort to create better sets of systems for doing it. However badly we're doing it, that *is* what I believe our effort to be. This is also us, taking the heat. kind regards, Ted Hardie _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22367 for ; Tue, 16 Dec 2003 11:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI6E-0001eN-0O for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGV5j9006342 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI6D-0001eD-RG for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:31:05 -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 LAA22317 for ; Tue, 16 Dec 2003 11:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWI6C-0001Iq-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:31:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWI6A-0001IX-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:31:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWI6A-0001IP-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI69-0001cq-OF; Tue, 16 Dec 2003 11:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI5B-0001aN-QA for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:30:01 -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 LAA22228 for ; Tue, 16 Dec 2003 11:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWI55-0001Cc-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWI46-0001CO-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:28:55 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AWI46-0001BF-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:28:54 -0500 Message-ID: <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> From: "James Kempf" To: "Pete Resnick" Cc: "Dave Crocker" , "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> Subject: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) Date: Tue, 16 Dec 2003 08:28:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, > So here's that elephant in the room: *Of course* there's a > difference, and I'm a little concerned that you don't see it. > > Companies like the one you describe are strict hierarchies. The top > of the company has the most to gain or lose (monetarily) based on the > outcome of the efforts of the folks below. The folks further up the > chain get to choose who is going to do the work below. If the upper > folks don't like the work being done by the lower folks, they get new > lower folks to do the work. The upper folks hire some sets of lower > folks to check the work of the other lower folks. Everything is very > congenial so long as everyone more or less cooperates. But outside of > everything working smoothly, you bet it's a dictatorship. Though it's > nice when there is a consensus among all of the groups, if there's > not, management has easy ways to solve that problem. > > The IETF is not like that. The IETF is a consensus organization. We > have different levels of consensus (e.g., inside the WG, the whole > IETF), but at the end of the day, it's the entire population who > decides whether the work is up-to-snuff. We have some procedures to > make sure people don't make dumb mistakes along the way (including > having some folks we think are smart do some final reviews of our > work), and we've got some management structure to deal with things > when all hell breaks loose, but even there it's not like the company > you describe: The IESG can shut down a WG or say "no" to a document, > but even in those cases, the IESG is supposed to try to resolve the > conflict and bring the group back to consensus, not just veto. And if > in the end we can't come to consensus with management, the rest of us > can appeal the decision of the management, and if we decide that they > are simply not doing the right thing, we can get rid of them using > the recall process (or in the extreme, as happened in 1992, change > the management structure altogether). > So doesn't the fact that the IESG can say "no" make it a hierarchy? I fail to see any difference in the immediate situation between an Area Director returning a document to a working group after AD Review and saying "fix this or I'm not going to submit it to the IESG" and a division director saying "fix these bugs or I'm not going to release the software". Of course, there are differences in accountability. The division director is only accountable to his VP while the AD is accountable to the community. As I've said in other emails, that means that should WG chairs be given more - it you don't like the word "authority" call it something else, maybe "X stuff" - then there needs to be a similar accountability mechanism for them. > Yes, that means we have given our management a good deal of > responsibility and not very much final authority. There are some > things that are made really hard by being in an open-membership > consensus-based organization. Maybe it would be nice if it were > otherwise. Personally, I kind of like it this way. > Sorry, I disagree. No sane person is going to take the responsibility to do something without the authority to get it done. One argument some have made against giving the WG chairs more X stuff is that we don't get very good people as WG chairs. If they aren't given the X stuff to match their responsibility, we'll get even worse. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:36:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22580 for ; Tue, 16 Dec 2003 11:36: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 1AWIB2-0001rS-6M for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGa4YC007148 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB2-0001rD-0n for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:36:04 -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 LAA22546 for ; Tue, 16 Dec 2003 11:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIB0-0001YL-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIAz-0001Xs-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIAz-0001Xp-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIAz-0001od-Mh; Tue, 16 Dec 2003 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHcW-0008Ca-Qq for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:00:24 -0500 Received: from tigger (scoya-desktop.cnri.reston.va.us [10.27.16.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21216; Tue, 16 Dec 2003 11:00:13 -0500 (EST) Date: Tue, 16 Dec 2003 10:58:41 -0500 (Eastern Standard Time) From: Steve Coya To: Pete Resnick cc: MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal In-Reply-To: Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 >>So in your case: If you had a reasonable size reviewer committee (not >>just 1 or 2 people), that means that you've got a significant number >>of folks who think there are real problems with the document. Perhaps it's the _nature_ of the review (and reviewer comments) - along with the instructions conveyed to the reviewers (assuming/hoping instructions were included). For example, a review which points out that the specification is in direct conflict with an existing protocol (i.e. architectural or incompatible) should be seriously considered and addressed, as opposed to an opinion, for example, that a byte count should start at one instead of zero - which can be considered and ..... "respectfully declined" That's just my thought - I could be wrong. Steve _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22595 for ; Tue, 16 Dec 2003 11:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB3-0001rk-2v for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGa5iY007166 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB2-0001rV-Tm for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:36:04 -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 LAA22550 for ; Tue, 16 Dec 2003 11:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIB1-0001YT-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIAy-0001Xk-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIAy-0001Xh-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIAy-0001ne-Ox; Tue, 16 Dec 2003 11:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0zM-00024C-LI for mpowr@optimus.ietf.org; Mon, 15 Dec 2003 17:14:52 -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 RAA03032 for ; Mon, 15 Dec 2003 17:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0zK-0003SU-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:14:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0zJ-0003SN-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:14:50 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AW0zJ-0003RZ-00 for mpowr@ietf.org; Mon, 15 Dec 2003 17:14:49 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBFMLKf03838; Mon, 15 Dec 2003 14:21:20 -0800 Date: Mon, 15 Dec 2003 14:14:12 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <209066081.20031215141412@brandenburg.com> To: "James Kempf" CC: "Pete Resnick" , MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal In-Reply-To: <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, JK> I disagree. I see nothing in 2026 or 2418 that gives a WG chair the JK> authority to hold a document because they believe there are flaws in the That is correct. Chairs do not have the authority to overrule the Working Group. The chair's job is to facilitate, not control. For every example of wayward working groups, we need to worry equally about wayward chairs. The challenge is to find a balance. In the IETF, we try to do that through diverse participation. When a diverse group strongly embraces a decision, then we have a legitimate decision. The challenge with a wayward working group is that it is, at best, a diverse sample of the larger community that shares a common goal. The serious problems occur when it is not diverse or experienced enough or does not have a strongly shared goal. But the same can be true for the knowledge, perspective and possible bias of the chair. JK> design. Rough concensus doesn't mean one person objects, it means some JK> significant number, over a majority object. The rough consensus thing comes in two forms. Objecting and agreeing. So a rough consensus of agreement means that there is not a strong, substantial disagreement. JK> Besides, if the WG chair does JK> hold the document, what are they supposed to do with it? This concern about delaying the process for a chair-invoked hold makes sense to me pnly if there were some sort of surprise at the end of the working group process. But there never is, especially with the glacial pace that most working groups operate at. So a chair who feels that the working group is wayward has months to use, to recruit corrective assistance. We do not have crises, except through delayed oversight. Review early and review often. JK> . I suppose a chair could submit the document to the IESG JK> with a list of flaws that the chair thinks need to get fixed, but even that JK> is going outside of what 2026 and 2418 prescribe as the WG chair's role. Not really. The IETF looks for comments whenever they are offered, and from whoever offers them. As a matter of efficiency, there are good times and bad, for some input. That's why the distinction between "I don't like a decision" versus "The decision won't work" is so important. The former is useful earlier in a process, and wasteful any other time. The latter is always useful. JK> There is also a point about the role of reviews that I perhaps did JK> not articulate clearly. The point is that the reviewers are outside JK> the WG, so that they function like a traditional QA team in software JK> development, as a check on the spec developers (and thus on WG JK> concensus); otherwise, the utility of the reviews is limited. I think that an informed, diligent review is useful, no matter where it came from. The problem is with _relying_ on reviews that come from the developers. JK> Thus, they are not, strictly speaking, subject to WG concensus. On the other hand, consensus among reviewers ought to be pretty noteworthy... JK> any review mechanism needs to be binding on the WG, This moves us back to the "authority" focus, rather than the "consensus" focus. Certainly a working group is obligated to deal with comments it receives. But what does it mean for those comments to be "binding"? Going down that path gets more complicated, because then we must deal with questions about the expertise and intent of the reviewer. Working groups are usually diligent at dealing with comments. When they aren't, it provides further examples that the wg is rogue. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:36:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22600 for ; Tue, 16 Dec 2003 11:36:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB4-0001sK-HX for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGa6kj007200 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB4-0001s3-AZ for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:36:06 -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 LAA22556 for ; Tue, 16 Dec 2003 11:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIB3-0001Yb-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIB0-0001Y5-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIAz-0001Y2-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB0-0001ps-3f; Tue, 16 Dec 2003 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHkz-0000iW-Qz for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:09:09 -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 LAA21671 for ; Tue, 16 Dec 2003 11:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHkx-0000Z4-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHkw-0000Yw-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:09:06 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AWHkw-0000Yt-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:09:06 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D3FD8AFB6F; Tue, 16 Dec 2003 11:09:05 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25519-14; Tue, 16 Dec 2003 11:09:04 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id D350BAFAD4; Tue, 16 Dec 2003 11:09:04 -0500 (EST) Date: Tue, 16 Dec 2003 11:09:04 -0500 From: Keith Moore To: Harald Tveit Alvestrand Cc: moore@cs.utk.edu, John C Klensin , mpowr@ietf.org, solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal Message-Id: <20031216110904.6abd5613.moore@cs.utk.edu> In-Reply-To: <306983108.1071482419@localhost> References: <7450364.1071484725@r3.jck.com> <306983108.1071482419@localhost> X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > - The community, perhaps with good justification, distrusts the value of having discussion take place on relatively obscure mailing lists that do not have a publicly-reviewed charter or an identified chair. probably true. OTOH the community would also have good justification to distrust the value of a discussion that was deliberately framed in such a way as to pre-determine the answer. The community would also have good justification to distrust the value of a discussion that was so narrowly focused that more important considerations were overlooked. MPOWR as proposed has both of these flaws. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 11:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22637 for ; Tue, 16 Dec 2003 11:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB5-0001sc-Ql for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGa7gH007220 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB4-0001sN-MZ for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:36:07 -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 LAA22560 for ; Tue, 16 Dec 2003 11:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIB3-0001Yi-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIB0-0001YC-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIAz-0001Y7-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB0-0001qA-9e; Tue, 16 Dec 2003 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHrW-00016q-Ne for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:15:54 -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 LAA21849 for ; Tue, 16 Dec 2003 11:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHrV-0000k5-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHrU-0000jy-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:15:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWHrU-0000jL-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:15:52 -0500 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBGGFIDM004047; Tue, 16 Dec 2003 11:15:18 -0500 (EST) Message-Id: <200312161615.hBGGFIDM004047@rtp-core-2.cisco.com> To: Margaret.Wasserman@nokia.com cc: john-ietf@jck.com, presnick@qualcomm.com, mpowr@ietf.org, solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal In-reply-to: Your message of Mon, 15 Dec 2003 14:19:36 -0500. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Dec 2003 11:15:17 -0500 From: Eric Rosen 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Margaret> We get, by far, the highest number of respondents when we conduct Margaret> polls at the plenaries, and perhaps those polls are our best way Margaret> to judge "IETF consensus" This mystifies me. Unless the room is filled with people who have given careful thought to the issues, taking a poll of the room is unlikely to give a useful result. If you poll a large room filled with tired people who are primarily there as observers, are you getting informed and considered expert opinions, or are you just getting a reaction to the personalities and to the rhetoric? Polling the plenary is only useful as a way for the "leadership" to manipulate the outcome so that they can claim support. So not surprisingly, there is always a dispute about whether the plenary actually did show consensus. >> (2) The other major concern that has been voiced involves WG >> Chairs abusing their (possibly new-found) power. But WG Chairs >> serve more or less at the pleasure of ADs. An abuse can be >> discussed with the relevant AD (the procedures are pretty clear >> about that). If the AD refuses to do anything, that situation >> can be appealed (that is less clear from the procedures, but, >> IMO, it would be completely rational for the community to >> consider recalling any AD who said "my nit-picking reading of >> the procedures doesn't permit an appeal in this case, so I vote >> to reject it without considering the issues"). Margaret> I more-or-less agree that this should be sufficient chain of Margaret> accountability I don't think so. In the past I've successfully appealed WG chair decisions to the AD by demonstrating that the decision was not supported by WG consensus. But as the chairs get more responsibility, there will be more possible grounds for appeal, and there will be more details that the AD needs to know in order to judge the appeal. Appeals will be even less effective than they currently are. At the very least, it has to be made extremely clear what grounds are appropriate for a chair to use when making a particular decision. Harald has said that we should just trust to everyone's good intentions, but of course that rather misses the point. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 12:23:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22598 for ; Tue, 16 Dec 2003 11:36:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB3-0001s0-Vd for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGa5EF007182 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 11:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIB3-0001rl-Q1 for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:36:05 -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 LAA22553 for ; Tue, 16 Dec 2003 11:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIB2-0001YY-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIAz-0001Y0-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIAz-0001Xx-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 11:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIAz-0001pM-US; Tue, 16 Dec 2003 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHh8-00005o-AL for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 11:05:10 -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 LAA21455 for ; Tue, 16 Dec 2003 11:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHh5-0000K0-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHh4-0000Jt-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:07 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AWHh4-0000Jq-00 for mpowr@ietf.org; Tue, 16 Dec 2003 11:05:06 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2789AAFB6F; Tue, 16 Dec 2003 11:05:06 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24797-14; Tue, 16 Dec 2003 11:05:05 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 17FE8AFC90; Tue, 16 Dec 2003 11:05:05 -0500 (EST) Date: Tue, 16 Dec 2003 11:05:04 -0500 From: Keith Moore To: Pete Resnick Cc: moore@cs.utk.edu, "James Kempf" , Dave Crocker , MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal Message-Id: <20031216110504.08743892.moore@cs.utk.edu> In-Reply-To: References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >I disagree. I see nothing in 2026 or 2418 that gives a WG chair the > >authority to hold a document because they believe there are flaws in > >the design. > > I don't know with whom you're disagreeing, because I never said that > and I don't believe that. I don't believe a WG chair has the > authority to hold a document because they believe there are flaws in > the design, nor do I believe that a chair should have such authority. that might be the case under our current rules. however this has an interesting implication - that IESG is the only party that has the ability to block a document because of design flaws. no wonder IESG has such a high workload! _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 12:56:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25489 for ; Tue, 16 Dec 2003 12:56: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 1AWJQS-0005TC-KG for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 12:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGHu4OC021024 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 12:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJQS-0005T1-FR for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 12:56:04 -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 MAA25476 for ; Tue, 16 Dec 2003 12:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJQQ-0004BL-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJQP-0004BE-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWJQP-0004BB-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJQQ-0005Rs-96; Tue, 16 Dec 2003 12:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJQ5-0005R2-Lb for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 12:55:41 -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 MAA25454 for ; Tue, 16 Dec 2003 12:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJQ4-0004A6-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:55:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJQ2-00049z-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:55:39 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AWJQ2-00048v-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:55:38 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Tue, 16 Dec 2003 11:55:07 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> X-Mailer: Eudora [Macintosh version 6.1a7] Date: Tue, 16 Dec 2003 11:55:05 -0600 To: "James Kempf" From: Pete Resnick Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) Cc: "Dave Crocker" , "MPowr" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,FORGED_MUA_EUDORA, NO_OBLIGATION autolearn=no version=2.60 On 12/16/03 at 8:28 AM -0800, James Kempf wrote: >So doesn't the fact that the IESG can say "no" make it a hierarchy? No, it doesn't. For example: >I fail to see any difference in the immediate situation between an >Area Director returning a document to a working group after AD >Review and saying "fix this or I'm not going to submit it to the >IESG" and a division director saying "fix these bugs or I'm not >going to release the software". Because the development team can't appeal the division director's decision, and the development team members cannot initiate the process to fire the division director. And moreover, the development team cannot decide (with the rest of the departments) to restructure the corporation and get rid of the division director. Also, the division director is under no obligation to negotiate with the development team if the development team disagrees with the division director. The division director has no responsibility to try to resolve disputes, even if it is a nice thing to do. >Of course, there are differences in accountability. The division >director is only accountable to his VP while the AD is accountable >to the community. As I've said in other emails, *that* means that >should WG chairs be given more - it you don't like the word >"authority" call it something else, maybe "X stuff" - then there >needs to be a similar accountability mechanism for them. [emphasis added] First of all, *what* means that chairs should be given more authority? I don't see how that follows from anything you've said. (And I *do* think we're talking about authority here; no need to call it "X stuff".) Second of all, accountability is *not* the only difference between the division director and the AD; the entire set of responsibilities is similarly different. >No sane person is going to take the responsibility to do something >without the authority to get it done. You've said that twice now and I'm still at a loss to know what you're talking about. It sounds like a catch phrase. What responsibility have we given (or do we want to give) to an AD or to a WG chair for which we haven't given them the authority to get it done? An AD has the responsibility to review documents coming out of working groups. Chairs have the responsibility to make sure that consensus is reached on all open document issues. We're talking about giving chairs the responsibility to collect technical reviews early in the process and to do a technical writeup at the end of the process. Yes, for all of these responsibilities, the ADs and chairs should know that the community has the authority to overrule them. But how does that equate to not having the authority to get those things done? Does the prospect of appeal or recall prevent ADs from pushing back on WGs? Does the prospect of appeal or recall prevent a chair from invoking 2026 to say, "Let's try to bring this set of open issues from the review to consensus"? >One argument some have made against giving the WG chairs more X >stuff is that we don't get very good people as WG chairs. Straw man. I've certainly never said that. >If they aren't given the X stuff to match their responsibility, >we'll get even worse. So effectively you're saying that power is the only reward for which good chairs will work. I've not found that to be the case. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 12:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25637 for ; Tue, 16 Dec 2003 12:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJTK-0005dT-IU for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 12:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGHx2eC021657 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 12:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJTK-0005dE-EE for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 12:59:02 -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 MAA25634 for ; Tue, 16 Dec 2003 12:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJTI-0004Kd-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJTH-0004KW-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWJTH-0004KT-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 12:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJTI-0005ci-SP; Tue, 16 Dec 2003 12:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJSo-0005cC-GU for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 12:58:30 -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 MAA25590 for ; Tue, 16 Dec 2003 12:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJSm-0004Il-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:58:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJSj-0004IR-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:58:28 -0500 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWJSj-0004Hz-00 for mpowr@ietf.org; Tue, 16 Dec 2003 12:58:25 -0500 Received: from darkwing.uoregon.edu (llynch@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.10/8.12.10) with ESMTP id hBGHwKRb013114; Tue, 16 Dec 2003 09:58:20 -0800 (PST) Received: from localhost (llynch@localhost) by darkwing.uoregon.edu (8.12.10/8.12.10/Submit) with ESMTP id hBGHwKKL013107; Tue, 16 Dec 2003 09:58:20 -0800 (PST) Date: Tue, 16 Dec 2003 09:58:20 -0800 (PST) From: "Lucy E. Lynch" To: James Kempf cc: MPowr , solutions@alvestrand.no In-Reply-To: <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> Message-ID: References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] Re: Quality Control and that nasty A word 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Tue, 16 Dec 2003, James Kempf wrote: > Sorry, I disagree. No sane person is going to take the responsibility to do > something without the authority to get it done. One argument some have made > against giving the WG chairs more X stuff is that we don't get very good > people as WG chairs. If they aren't given the X stuff to match their > responsibility, we'll get even worse. > > jak Excuse the cross post - but I thought Vixie's take on Authority might be interesting to folks - seems pretty sane to me. ---------- Forwarded message ---------- Date: 16 Dec 2003 07:14:57 +0000 From: Paul Vixie To: nanog@merit.edu Subject: Re: Root Authority > An interesting question I've dealt with a few times: > > From whom do the root nameservers derive their authority? we (i'm speaking for f-root here) have no "authority". nobody has to listen to us, we are the most powerless bunch of folks you'll ever meet. now if you'd asked where we derive our *relevance*, i'd say the same as mr. bush and mr. kletnieks -- from all the root.cache files that point at us. and as long as we don't do anything stupid i guess (and hope) that this state of affairs will continue. (relevance trumps authority.) that having been said, f-root got its start as NS.ISC.ORG and the man who said it was ok for us to be a root name server was jon postel. i'm not sure he had any "authority" either, but folks "pointed at" him and so what he said was relevant in spite of any authority he mightn've had. -- Paul Vixie _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 13:04:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25800 for ; Tue, 16 Dec 2003 13:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJYA-0005j3-El for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 13:04:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGI42Pn022003 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 13:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJYA-0005io-94 for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 13:04:02 -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 NAA25772 for ; Tue, 16 Dec 2003 13:03:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJY8-0004U6-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJY7-0004Ty-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:04:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWJY7-0004Tv-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJY8-0005iA-GG; Tue, 16 Dec 2003 13:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJXH-0005he-Fk for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 13:03:07 -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 NAA25745 for ; Tue, 16 Dec 2003 13:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJXF-0004Sn-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:03:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJXE-0004Sf-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:03:05 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AWJXE-0004Sa-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:03:04 -0500 Message-ID: <01c501c3c3fe$e61bd8c0$5b6015ac@dclkempt40> From: "James Kempf" To: "Pete Resnick" Cc: "Dave Crocker" , "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) Date: Tue, 16 Dec 2003 10:03:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,NO_OBLIGATION autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, By "immediate situation" I meant the situation of how the QA process is handled. By "accountability" I meant how alleged abuses are handled. Your point about appeal is about "accountability", not about "immediate situation". These are two different processes, and it would be well not to confuse them. I agree with you about "accountability", I don't agree about how to structure the "immediate situation". jak ----- Original Message ----- From: "Pete Resnick" To: "James Kempf" Cc: "Dave Crocker" ; "MPowr" ; Sent: Tuesday, December 16, 2003 9:55 AM Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) > On 12/16/03 at 8:28 AM -0800, James Kempf wrote: > > >So doesn't the fact that the IESG can say "no" make it a hierarchy? > > No, it doesn't. For example: > > >I fail to see any difference in the immediate situation between an > >Area Director returning a document to a working group after AD > >Review and saying "fix this or I'm not going to submit it to the > >IESG" and a division director saying "fix these bugs or I'm not > >going to release the software". > > Because the development team can't appeal the division director's > decision, and the development team members cannot initiate the > process to fire the division director. And moreover, the development > team cannot decide (with the rest of the departments) to restructure > the corporation and get rid of the division director. > > Also, the division director is under no obligation to negotiate with > the development team if the development team disagrees with the > division director. The division director has no responsibility to try > to resolve disputes, even if it is a nice thing to do. > > >Of course, there are differences in accountability. The division > >director is only accountable to his VP while the AD is accountable > >to the community. As I've said in other emails, *that* means that > >should WG chairs be given more - it you don't like the word > >"authority" call it something else, maybe "X stuff" - then there > >needs to be a similar accountability mechanism for them. > [emphasis added] > > First of all, *what* means that chairs should be given more > authority? I don't see how that follows from anything you've said. > (And I *do* think we're talking about authority here; no need to call > it "X stuff".) > > Second of all, accountability is *not* the only difference between > the division director and the AD; the entire set of responsibilities > is similarly different. > > >No sane person is going to take the responsibility to do something > >without the authority to get it done. > > You've said that twice now and I'm still at a loss to know what > you're talking about. It sounds like a catch phrase. What > responsibility have we given (or do we want to give) to an AD or to a > WG chair for which we haven't given them the authority to get it > done? An AD has the responsibility to review documents coming out of > working groups. Chairs have the responsibility to make sure that > consensus is reached on all open document issues. We're talking about > giving chairs the responsibility to collect technical reviews early > in the process and to do a technical writeup at the end of the > process. Yes, for all of these responsibilities, the ADs and chairs > should know that the community has the authority to overrule them. > But how does that equate to not having the authority to get those > things done? Does the prospect of appeal or recall prevent ADs from > pushing back on WGs? Does the prospect of appeal or recall prevent a > chair from invoking 2026 to say, "Let's try to bring this set of open > issues from the review to consensus"? > > >One argument some have made against giving the WG chairs more X > >stuff is that we don't get very good people as WG chairs. > > Straw man. I've certainly never said that. > > >If they aren't given the X stuff to match their responsibility, > >we'll get even worse. > > So effectively you're saying that power is the only reward for which > good chairs will work. I've not found that to be the case. > > pr > -- > Pete Resnick > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 13:06:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25904 for ; Tue, 16 Dec 2003 13:06:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJa6-0005od-HU for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 13:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGI62Ic022349 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 13:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJa6-0005oO-Bq for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 13:06:02 -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 NAA25880 for ; Tue, 16 Dec 2003 13:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJa4-0004Yr-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:06:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJa3-0004Yj-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:06:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWJa3-0004Yg-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 13:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJa4-0005nP-L6; Tue, 16 Dec 2003 13:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJZU-0005kl-7Y for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 13:05:24 -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 NAA25853 for ; Tue, 16 Dec 2003 13:05:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJZS-0004X2-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJZR-0004Wv-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:05:22 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AWJZR-0004Wr-00 for mpowr@ietf.org; Tue, 16 Dec 2003 13:05:21 -0500 Message-ID: <01cd01c3c3ff$3780ca90$5b6015ac@dclkempt40> From: "James Kempf" To: "Lucy E. Lynch" Cc: "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> Date: Tue, 16 Dec 2003 10:05:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: Quality Control and that nasty A word 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If you'd rather call it "relevance" than "X-stuff" be my guest. jak ----- Original Message ----- From: "Lucy E. Lynch" To: "James Kempf" Cc: "MPowr" ; Sent: Tuesday, December 16, 2003 9:58 AM Subject: Re: Quality Control and that nasty A word > > On Tue, 16 Dec 2003, James Kempf wrote: > > > Sorry, I disagree. No sane person is going to take the responsibility to do > > something without the authority to get it done. One argument some have made > > against giving the WG chairs more X stuff is that we don't get very good > > people as WG chairs. If they aren't given the X stuff to match their > > responsibility, we'll get even worse. > > > > jak > > Excuse the cross post - but I thought Vixie's take on Authority > might be interesting to folks - seems pretty sane to me. > > ---------- Forwarded message ---------- > Date: 16 Dec 2003 07:14:57 +0000 > From: Paul Vixie > To: nanog@merit.edu > Subject: Re: Root Authority > > > > An interesting question I've dealt with a few times: > > > > From whom do the root nameservers derive their authority? > > we (i'm speaking for f-root here) have no "authority". nobody has to > listen to us, we are the most powerless bunch of folks you'll ever meet. > > now if you'd asked where we derive our *relevance*, i'd say the same as > mr. bush and mr. kletnieks -- from all the root.cache files that point > at us. and as long as we don't do anything stupid i guess (and hope) > that this state of affairs will continue. (relevance trumps authority.) > > that having been said, f-root got its start as NS.ISC.ORG and the man > who said it was ok for us to be a root name server was jon postel. i'm > not sure he had any "authority" either, but folks "pointed at" him and > so what he said was relevant in spite of any authority he mightn've had. > -- > Paul Vixie > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 17:28:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11244 for ; Tue, 16 Dec 2003 17:28:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNfI-00016N-EO for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 17:27:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMReUw004229 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 17:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNfI-000168-9T for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:27:40 -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 RAA11114 for ; Tue, 16 Dec 2003 17:27:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNfF-00005G-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNfE-000059-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:27:37 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWNVC-0007Uj-01 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:17:15 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWNHR-0008Ls-MA for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNHR-0000A7-8V; Tue, 16 Dec 2003 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNGU-0008TX-W4 for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 17:02: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 RAA10399 for ; Tue, 16 Dec 2003 17:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNGS-0007BG-00 for mpowr@ietf.org; Tue, 16 Dec 2003 17:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNGP-0007Ap-00 for mpowr@ietf.org; Tue, 16 Dec 2003 17:02:00 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AWNGP-0007Ag-00 for mpowr@ietf.org; Tue, 16 Dec 2003 17:01:57 -0500 Message-ID: <02c601c3c420$45177a70$5b6015ac@dclkempt40> From: "James Kempf" To: "Dave Crocker" Cc: "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <319857739.20031216121114@brandenburg.com> Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) Date: Tue, 16 Dec 2003 14:02:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave, > A very serious problem with trying to assign responsibility to the Chair > for quality, and the like, is that it _removes_ responsibility away from > the rest of the working group. > This presumes that the motivations of the WG are to not produce a quality spec. While this may sometimes be the case, I don't believe that it is necessarily always the case, or rather, it should not always be the case. The Chair and WG need to work as a team. > The chair is responsible for facilitating a fair, timely, quality > process. The entire working group is responsible for actually achieving > those things. > > This is not semantics. It is a fundamental difference in views about > the role of the Chair. > Clearly, quality requires more than just review at the end of the process. Your pithy formulation of "review early, review often" is relevant here. The WG needs to be responsible for quality, the WG chair needs to be responsible to make sure that is carried through, and have the tools (relevance, what have you) to carry it out. As mentioned earlier, new proposed WG charters are starting to have quality assurance plans. Suppose the IESG were to require that a charter contain a QA plan before the charter is approved. Thus, the WG is taking responsibility for quality by proposing the QA plan, the IESG is judging whether the plan is likely to succeed (from their presumably broader experience) by approving the charter or suggesting changes, and the chair has the responsibility for carrying the QA plan out, with the authority (relevance, etc.) granted to him/her by the WG through the charter. To make this work, the chair would need to have some tools available. The primary tool would be an expert review board like SIRS, and a template of options and standardized processes as to when reviews are typically carried out. The WG could agree to make the review binding, or not, and pick from the template what reviews they intended to have done and when. The IESG's judgement about the plan would depend on the interest group wanting to form the WG, the subject area, etc., (the IESG might also decide that they wanted to review the documents themselves rather than have outside review, for reasons of interest, possible effect on the Internet, etc.). Another QA tool might be implementation (as in "running code"). The working group might include at least one implementation of the protocol, to make sure that it is cleanly designed from an implementation standpoint, or the IESG might suggest that an implementation be done as part of the QA plan if they have concerns. A final tool might be requiring more than one interoperable implementation. I realize that, today, that is required only for DS, but there might be cases where interoperability concerns are high at the PS stage. Would this satisfy your concerns? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 16 17:28:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11407 for ; Tue, 16 Dec 2003 17:28:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNg3-0001Dj-Sw for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 17:28:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMSRqQ004685 for mpowr-archive@odin.ietf.org; Tue, 16 Dec 2003 17:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNg3-0001DU-Oj for mpowr-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:28: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 RAA11298 for ; Tue, 16 Dec 2003 17:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNg1-0000Di-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNg0-0000Db-00 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:28:25 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWNV7-0007Uj-02 for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:17:10 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWNIP-0008Mk-Np for mpowr-web-archive@ietf.org; Tue, 16 Dec 2003 17:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNIO-0000C3-RC; Tue, 16 Dec 2003 17:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLXs-00033l-Lz for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 15:11:52 -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 PAA00922 for ; Tue, 16 Dec 2003 15:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLXp-0000nM-00 for mpowr@ietf.org; Tue, 16 Dec 2003 15:11:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLXo-0000nA-00 for mpowr@ietf.org; Tue, 16 Dec 2003 15:11:49 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AWLXn-0000kn-00 for mpowr@ietf.org; Tue, 16 Dec 2003 15:11:47 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBGKIM310106; Tue, 16 Dec 2003 12:18:22 -0800 Date: Tue, 16 Dec 2003 12:11:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <319857739.20031216121114@brandenburg.com> To: "James Kempf" CC: "MPowr" , solutions@alvestrand.no Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) In-Reply-To: <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, JK> No sane person is going to take the responsibility to do JK> something without the authority to get it done. Rather than debate your point, let me suggest that the question is, then, what the responsibility of the chair is. A very serious problem with trying to assign responsibility to the Chair for quality, and the like, is that it _removes_ responsibility away from the rest of the working group. The chair is responsible for facilitating a fair, timely, quality process. The entire working group is responsible for actually achieving those things. This is not semantics. It is a fundamental difference in views about the role of the Chair. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 11:33:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18530 for ; Wed, 17 Dec 2003 11:33:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWebt-0001oV-Ge for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 11:33:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHGXHCf006970 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 11:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWebt-0001oL-An for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 11:33:17 -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 LAA18508 for ; Wed, 17 Dec 2003 11:33:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWebs-0005S8-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:33:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWebp-0005RU-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:33:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWebp-0005Qh-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWebd-0001nh-8i; Wed, 17 Dec 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWebT-0001nJ-BP for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 11:32:51 -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 LAA18481 for ; Wed, 17 Dec 2003 11:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWebI-0005Pr-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWeas-0005PY-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:32:14 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AWear-0005P4-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:32:14 -0500 Message-ID: <004701c3c4bb$501e5740$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Conta" Cc: "Dave Crocker" , "MPowr" , References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <319857739.20031216121114@brandenburg.com> <02c601c3c420$45177a70$5b6015ac@dclkempt40> <3FDFB128.8040107@txc.com> Date: Wed, 17 Dec 2003 08:32:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] Re: Quality Control and that nasty A word 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > As mentioned earlier, new proposed WG charters are starting to have quality > > assurance plans. Suppose the IESG were to require that a charter contain a > > QA plan before the charter is approved. Thus, the WG is taking > > responsibility for quality by proposing the QA plan, the IESG is judging > > whether the plan is likely to succeed (from their presumably broader > > experience) by approving the charter or suggesting changes, and the chair > > has the responsibility for carrying the QA plan out, with the authority > > (relevance, etc.) granted to him/her by the WG through the charter. > > As long as the chair can be also a developer, this process is > fundamentally weak, and prone to play just as a tool for promoting > the chair's, and chairs friends' work. > Sorry, Alex, but I don't understand what this has to do with figuring out a mechanism whereby QA can be effective, while, at the same time, reducing IESG workload and ensuring that the responsibility for QA rests with the WG. > > [...] > > Would this satisfy your concerns? > > > > jak > > Not mine. Sorry for jumping in. > Could you explain a little more? What exactly do you mean by the chair being a "developer"? If you read Margaret's draft (which I presume you did, since you're commenting on this thread) then you know that she has proposed that chairs are no longer allowed to be authors or editors of drafts, except for a limited period during which they are in transition between one role and another. So, if that's what you mean by being a "developer", that particular concern would be covered if that part of Margaret's draft is instituted. As for the chair's friends, it is up to the IESG to pick someone who can abstract themselves from purely partisan concerns and act as a moderator in the tussles that inevitably arise during standardization. If the chair does not fufill that role, then it is the responsibility of the WG to appeal to the AD to remove the chair. Perhaps there needs to be a statement to this effect in 2026bis? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 11:59:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20285 for ; Wed, 17 Dec 2003 11:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf0o-0003lM-KE for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 11:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHGx24Q014458 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 11:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf0o-0003l7-Ff for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 11:59:02 -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 LAA20248 for ; Wed, 17 Dec 2003 11:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWf0n-0006s0-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:59:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWf0l-0006rr-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWf0l-0006rn-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 11:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf0m-0003kp-2U; Wed, 17 Dec 2003 11:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf09-0003bW-8t for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 11:58:21 -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 LAA20218 for ; Wed, 17 Dec 2003 11:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWf08-0006qf-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:58:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWf07-0006qY-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:58:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWf06-0006q5-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:58:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBHGvim31779; Wed, 17 Dec 2003 18:57:44 +0200 Date: Wed, 17 Dec 2003 18:57:44 +0200 (EET) From: Pekka Savola To: James Kempf cc: MPowr , Subject: Re: [mpowr] Re: Quality Control and that nasty A word In-Reply-To: <004701c3c4bb$501e5740$5b6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, James Kempf wrote: > Could you explain a little more? What exactly do you mean by the chair being > a "developer"? If you read Margaret's draft (which I presume you did, since > you're commenting on this thread) then you know that she has proposed that > chairs are no longer allowed to be authors or editors of drafts, except for > a limited period during which they are in transition between one role and > another. So, if that's what you mean by being a "developer", that particular > concern would be covered if that part of Margaret's draft is instituted. This is not what the draft says. WG chairs can be authors and editors as well, *as long as* they do not serve in the same role for the particular document at the same time. I.e., if there are two chairs, one can author/edit a document without problems still. Removing that possibility might be interesting, but would the WG get anything done then? :-) WG chairs are often the last resort of pushing through the documents when WG falls into paralysis :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 13:09:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24157 for ; Wed, 17 Dec 2003 13:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWg6f-0008WK-0P for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:09:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHI980s032746 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWg6e-0008W5-QZ for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 13:09: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 NAA24142 for ; Wed, 17 Dec 2003 13:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWg6a-00022e-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWg6Z-00022X-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:09:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWg6Z-00022U-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWg6W-0008Vj-LI; Wed, 17 Dec 2003 13:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWg6C-0008VQ-C6 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 13:08:40 -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 NAA24105 for ; Wed, 17 Dec 2003 13:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWg6A-000225-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:08:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWg69-00021s-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:08:38 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWg68-00021n-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:08:36 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHI8Wk3009784; Wed, 17 Dec 2003 11:08:32 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHI8WMl009783; Wed, 17 Dec 2003 11:08:32 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 11:08:32 -0700 (MST) From: Alex Rousskov To: solutions@alvestrand.no cc: MPowr In-Reply-To: <857062833.20031217084004@brandenburg.com> Message-ID: References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <857062833.20031217084004@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, Dave Crocker wrote: > However I think that your own point about the inherent power of the > working group, compared with the derived power of IETF management, > including chairs, is the most important point. > > This is where reference to the IETF's being a volunteer organization > is so important. The troops really are in charge. When we run > things without paying attention to that, we get volunteers who > leave, by giving up on the working group. Dave, While I would really like to see IETF functioning that way, I have a hard time combining "in-charge troops" and "IESG does the final review and approval and might even modify documents at will". Perhaps somebody can help me here. I understand that IESG is elected by the troops. However, if we assume that an election grants superpowers, then it seems natural to assume that IESG-appointed chair can also have superpowers within a WG scope. In other words, you cannot make the "troops" argument against Chair powers without making a similar argument about IESG or AD powers. IESG/ADs simply want to delegate a portion of their power to Chairs, with what they believe sufficient controls. Don't like that? Appeal, elect a different IESG, or drastically change the IESG role. I can understand an organization where the working group is a superpower, with rules and procedures for cross-group review and conflict resolution. I can understand an organization where the IESG is the superpower, with rules and procedures to encourage WG work and elect IESG. If current IETF is the second kind of an organization (and it looks like that to me), are we not fooling ourselves with "troops" arguments? It seems to me that we should either - relax and let IESG disperse its powers to Chairs any way it seems fit; it should be within IESG powers to do so if IESG already has powers of so many more important aspects of WG work - remove superpowers from IESG and have a WG decide on its Chair authority; leave IESG its current final conflict resolution power. Both options have real-life precedence in other SDOs, of course. We seem to be stuck trying to invent a third option that carefully draws a line between effectively powerless WG and an effective IESG superpower, with a Chair standing on that line. Such an option may not exist. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 13:38:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25468 for ; Wed, 17 Dec 2003 13:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgYf-0000zw-BS for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHIc5ct003830 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgYe-0000zf-UO for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 13:38:05 -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 NAA25423 for ; Wed, 17 Dec 2003 13:38:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgYc-00036O-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgYb-00036H-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:38:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgYb-00036E-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgYa-0000xv-UQ; Wed, 17 Dec 2003 13:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgYR-0000us-75 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 13:37:51 -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 NAA25417 for ; Wed, 17 Dec 2003 13:37:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgYP-00035w-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:37:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgYO-00035p-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:37:48 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWgYM-00035m-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:37:47 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBHIbf009245; Wed, 17 Dec 2003 13:37:41 -0500 Message-ID: <3FE0A274.4090002@txc.com> Date: Wed, 17 Dec 2003 13:37:40 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Dave Crocker , MPowr , solutions@alvestrand.no References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <319857739.20031216121114@brandenburg.com> <02c601c3c420$45177a70$5b6015ac@dclkempt40> <3FDFB128.8040107@txc.com> <004701c3c4bb$501e5740$5b6015ac@dclkempt40> In-Reply-To: <004701c3c4bb$501e5740$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070004010304030806060707" Subject: [mpowr] Re: Quality Control and that nasty A word 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070004010304030806060707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see incline: James Kempf wrote: >>>As mentioned earlier, new proposed WG charters are starting to have > > quality > >>>assurance plans. Suppose the IESG were to require that a charter contain > > a > >>>QA plan before the charter is approved. Thus, the WG is taking >>>responsibility for quality by proposing the QA plan, the IESG is judging >>>whether the plan is likely to succeed (from their presumably broader >>>experience) by approving the charter or suggesting changes, and the > > chair > >>>has the responsibility for carrying the QA plan out, with the authority >>>(relevance, etc.) granted to him/her by the WG through the charter. >> >>As long as the chair can be also a developer, this process is >>fundamentally weak, and prone to play just as a tool for promoting >>the chair's, and chairs friends' work. >> > > > Sorry, Alex, but I don't understand what this has to do with figuring out a > mechanism whereby QA can be effective, while, at the same time, reducing > IESG workload and ensuring that the responsibility for QA rests with the WG. > Making the QA the responasbility of the WG is a good thing. But QA should not be only the task of the WG, since I do not think QA will be effective if it is solely a mechanism at WG level. Reducing the IESG load can be achieved by other means than just shifting load to the WG chairs. Personally I would prefer shifting the load to a body of people that are elected (nomcom) as opposed to selected by ADs. Something like the IESG - perhaps IAB, or a somewhat similar group. If I didn't say that already, power of decision on QA should be collective, and impartial. To ensure impartiality from start, decision people should meet certain criteria. >>>[...] >>>Would this satisfy your concerns? >>> >>> jak >> >>Not mine. Sorry for jumping in. >> > > > Could you explain a little more? What exactly do you mean by the chair being > a "developer"? If you read Margaret's draft (which I presume you did, since > you're commenting on this thread) then you know that she has proposed that > chairs are no longer allowed to be authors or editors of drafts, except for > a limited period during which they are in transition between one role and > another. So, if that's what you mean by being a "developer", that particular > concern would be covered if that part of Margaret's draft is instituted. As > for the chair's friends, it is up to the IESG to pick someone who can > abstract themselves from purely partisan concerns and act as a moderator in > the tussles that inevitably arise during standardization. If the chair does > not fufill that role, then it is the responsibility of the WG to appeal to > the AD to remove the chair. > As documents on the standards track are "alive" pretty much as long as the WG is alive, any involvement with output of the WG should be a disqualifing criterium for a WG chair, regardless of the amount of power - current level, or increased level of power. This is practice in many SDOs, and would resolve a problem in IETF that exists currently, even without giving the chairs more power. Additional checks and balances mechanims can be looked at - time limits on serving as chairs, performance reports after each IETF meeting - could be part of the "blue sheet", etc... regards, Alex > Perhaps there needs to be a statement to this effect in 2026bis? > > jak > > > --------------ms070004010304030806060707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxNzE4Mzc0MFowIwYJKoZIhvcNAQkEMRYEFGmNSudE09lRunsp enYM0uPf3iP1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAFc5Xcmk00mto+SJQeRKjFyiY4G9ZuZad3KZVz4qN+KA7OW64iolg48XaBTd RaQkh37ggwtVFcAIeaVy4UKvY3+ZxSd9UfYRxvEiz9OMno3uLiREJL9R7Gw3PsYDeFILLAqJ Mx/hRTw2SDlo4Auz5DANcqIz7kAzkn09xZysjUoqZgAjb/EukWiW36ZI5hi7UwjCAeXzw7+/ +4B7qT6LUar9TyaIiAZ6pSdr0/JW9Wk06I0HAuO1LUW1AgMe1ABVNGEbAGdR4VSw2U/uWMbU eK64DjFUSUrltOQ/zpnsp2MJDdG0miHoZ6o/G/LJsa1wPPhokGNQvNwaGn+IiVG6CvwAAAAA AAA= --------------ms070004010304030806060707-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 13:52:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26023 for ; Wed, 17 Dec 2003 13:52: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 1AWgmB-0001MA-PJ for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHIq37R005210 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 13:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgmB-0001Lx-IA for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 13:52: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 NAA26005 for ; Wed, 17 Dec 2003 13:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgm9-0003bg-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgm8-0003bZ-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:52:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgm8-0003bW-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 13:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgm9-0001L0-8m; Wed, 17 Dec 2003 13:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWglA-0001Ip-3x for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 13:51:00 -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 NAA25975 for ; Wed, 17 Dec 2003 13:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgl7-0003Zn-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgl6-0003Ze-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:50:57 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWgl6-0003ZX-00 for mpowr@ietf.org; Wed, 17 Dec 2003 13:50:56 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBHIoq009458; Wed, 17 Dec 2003 13:50:52 -0500 Message-ID: <3FE0A58B.9050908@txc.com> Date: Wed, 17 Dec 2003 13:50:51 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: James Kempf , MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070700050900020609030901" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070700050900020609030901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Wed, 17 Dec 2003, James Kempf wrote: > >>Could you explain a little more? What exactly do you mean by the chair being >>a "developer"? If you read Margaret's draft (which I presume you did, since >>you're commenting on this thread) then you know that she has proposed that >>chairs are no longer allowed to be authors or editors of drafts, except for >>a limited period during which they are in transition between one role and >>another. So, if that's what you mean by being a "developer", that particular >>concern would be covered if that part of Margaret's draft is instituted. > > > This is not what the draft says. WG chairs can be authors and editors > as well, *as long as* they do not serve in the same role for the > particular document at the same time. I.e., if there are two chairs, > one can author/edit a document without problems still. > My interpretation was the same as yours, which is why I voiced unequivocally, and undiplomatically my concerns. So in fact Margaret's draft does not suggest changing the current practice, as James's interperation suggested. That current practice is a problem even in current conditions, without any additional power to the chairs. > Removing that possibility might be interesting, but would the WG get > anything done then? :-) WG chairs are often the last resort of > pushing through the documents when WG falls into paralysis :-) > > If the WG chairs being the last resort should not be a concern, it means no one is interested in the work of that WG, so the WG should be disbanded, and the work filed as it is - incomplete work, could be resumed later, if interest revives. Alex --------------ms070700050900020609030901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxNzE4NTA1MVowIwYJKoZIhvcNAQkEMRYEFF9lmEz+NxszR0jZ rV7a+h6HpW/GMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBALbIUqwnVee566ga7nP8zRIrhl0XGm1n+ppP6zT8xxMjEE41z+7aBUbPjFgm gRTabCXbnuFwYH1qjTSqlcO3/12bVgzmr7YQrjp/mXYou3PXS3GB8nTJnusXzW8Tist8oAQa jsfdRDcWJbKJLpGCdGsuzBNfLIln0y+WFM6aVoLfMjtADYxe//rMpPwLLhk0CaXDMdZwFSYH RKjrVja9YxGCcqGO4BX1T6l+BUmX1/OI+Qos0qNMR9X0ZyELk6ODB/ZrXhFpPd944DkrWZJF bQ9/C6KQkP/KyZyc/xk2/c0/Dw9lrUCTMfoyi/3RRANVfEKHnW20Z2U+IHEE8zXZ0a0AAAAA AAA= --------------ms070700050900020609030901-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 14:03:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26683 for ; Wed, 17 Dec 2003 14:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgwo-0001ri-OD for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 14:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHJ32WT007170 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 14:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgwo-0001rZ-Hf for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 14:03:02 -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 OAA26676 for ; Wed, 17 Dec 2003 14:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgwm-00046E-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 14:03:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgwl-000467-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 14:02:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgwl-000463-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 14:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgwm-0001qu-Ua; Wed, 17 Dec 2003 14:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgvt-0001qI-Ac for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 14:02:05 -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 OAA26656 for ; Wed, 17 Dec 2003 14:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgvr-00044m-00 for mpowr@ietf.org; Wed, 17 Dec 2003 14:02:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgvq-00044e-00 for mpowr@ietf.org; Wed, 17 Dec 2003 14:02:02 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AWgvp-00044K-00 for mpowr@ietf.org; Wed, 17 Dec 2003 14:02:01 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBHJ1SIx017050; Wed, 17 Dec 2003 11:01:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBHJ1S9k017049; Wed, 17 Dec 2003 11:01:28 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 Dec 2003 11:01:28 -0800 From: David Meyer To: Alex Conta Cc: Pekka Savola , MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word Message-ID: <20031217190128.GA16958@1-4-5.net> References: <3FE0A58B.9050908@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE0A58B.9050908@txc.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Alex, >> If the WG chairs being the last resort should not be a concern, it means >> no one is interested in the work of that WG, so the WG should be >> disbanded, and the work filed as it is - incomplete work, could be >> resumed later, if interest revives. While I agree that in a perfect (maybe different) world, this could be true. In addition, you might make a similar assertion when consensus can't be reached (notably: "No one cares enough about this problem to compromise on a solution" or similar). However, the reality is somewhat different. In the former case (WG chairs as last resort), there are just too many issues surrounding how authors work in a volunteer organization to make such a (categorical) statement. In fact, one of the jobs of a WG chair (IMO) is to manage and (frequently overlooked, but equally important) mentor the WG's authors. Dave _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 15:32:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02162 for ; Wed, 17 Dec 2003 15:32:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiKw-0005lP-9d for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 15:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKW2eP022151 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 15:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiKw-0005lC-5M for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:32:02 -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 PAA02152 for ; Wed, 17 Dec 2003 15:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiKu-0007bX-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 15:32:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiKt-0007bQ-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 15:32:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWiKt-0007bN-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 15:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiKu-0005kX-Cb; Wed, 17 Dec 2003 15:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiKW-0005kG-M5 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 15:31:36 -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 PAA02141 for ; Wed, 17 Dec 2003 15:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiKV-0007b6-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:31:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiKU-0007az-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:31:35 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWiKU-0007aw-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:31:34 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHKVVk3017091; Wed, 17 Dec 2003 13:31:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHKVVao017090; Wed, 17 Dec 2003 13:31:31 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 13:31:31 -0700 (MST) From: Alex Rousskov To: David Meyer cc: MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word In-Reply-To: <20031217190128.GA16958@1-4-5.net> Message-ID: References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, David Meyer wrote: >>> If the WG chairs being the last resort should not be a concern, it >>> means no one is interested in the work of that WG, so the WG >>> should be disbanded, and the work filed as it is - incomplete >>> work, could be resumed later, if interest revives. > > In the former case (WG chairs as last resort), there are just too > many issues surrounding how authors work in a volunteer organization > to make such a (categorical) statement. Nothing in the volunteer nature of an organization implies that half-baked documents without authors are worth promoting to standard levels by heroic chair actions. If we assume that WG documents must be maintained _after_ the IESG marks them as "proposed standard", then what Alex is saying is not that categorical. You are saying that a WG chair can be used as a last resort to save good output of a now-defunct working group. This implies that a frozen (usually at a near-PS level) output is worth saving for reasons other than historical. To me, this is equivalent of releasing beta-quality software without any support or real possibility of upgrades. This should not be done. It is far better not to release such software at all and simply archive it. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:00:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05021 for ; Wed, 17 Dec 2003 16:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWim9-000749-VW for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:00:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHL09gI027129 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWim8-00071Z-UM for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:00:09 -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 QAA05007 for ; Wed, 17 Dec 2003 16:00:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWim7-0001zn-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:00:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWim6-0001zg-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:00:07 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWim6-0001zb-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:00:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWim6-0004bY-RA for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWim5-0006zV-Mb; Wed, 17 Dec 2003 16:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWila-0006xq-IL for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 15:59:34 -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 PAA04925 for ; Wed, 17 Dec 2003 15:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWilY-0001xi-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWilX-0001xZ-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:59:32 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AWilX-0001uj-00 for mpowr@ietf.org; Wed, 17 Dec 2003 15:59:31 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 817F61435C; Wed, 17 Dec 2003 12:59:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2003 12:59:01 -0800 Message-ID: Thread-Topic: [Solutions] Troops versus superpower Thread-Index: AcPEyNYGkcBdrjZ4SSe6HcYATbxDbwAEoZyA From: "Robert Snively" To: "Alex Rousskov" , Cc: "MPowr" Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have to agree with Alex's differentiation of two approaches, but I would like to attach a third alternative that has proven successful in the past. > I can understand an organization where the working group is a > superpower, with rules and procedures for cross-group review and > conflict resolution. I can understand an organization where the IESG > is the superpower, with rules and procedures to encourage WG work and > elect IESG. If current IETF is the second kind of an organization (and > it looks like that to me), are we not fooling ourselves with "troops" > arguments? It seems to me that we should either >=20 > - relax and let IESG disperse its powers to Chairs > any way it seems fit; it should be within IESG > powers to do so if IESG already has powers of so > many more important aspects of WG work >=20 > - remove superpowers from IESG and have a WG decide > on its Chair authority; leave IESG its current > final conflict resolution power. >=20 > Both options have real-life precedence in other SDOs, of course. We > seem to be stuck trying to invent a third option that carefully draws > a line between effectively powerless WG and an effective IESG > superpower, with a Chair standing on that line. Such an option may not > exist. This third approach is also used by many SDOs. By maintaining absolute process supervision powers at a level equivalent to that of IESG, one could successfully disperse the technical=20 review powers to a lower level (WG and below) during the=20 development process and to a wide public during the superpower's process review period. The superpowers verify the process while the process, managed by working group chairs, demands and defines the required liaison and review activities. Chairs that don't require the process of their working group are guided toward correct behavior or removed by the superpower. Bob Snively 408-333-8135 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:08:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05349 for ; Wed, 17 Dec 2003 16:08: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 1AWitn-0007dc-HF for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHL83hp029354 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWitn-0007dF-6j for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:08: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 QAA05338 for ; Wed, 17 Dec 2003 16:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWitl-0002DC-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWitk-0002D5-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWitk-0002D2-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWitl-0007c4-BL; Wed, 17 Dec 2003 16:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWit4-0007PC-G1 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:07:18 -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 QAA05320 for ; Wed, 17 Dec 2003 16:07:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWit2-0002Bx-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:07:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWit2-0002Bq-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:07:16 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWit1-0002Bn-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:07:15 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHL7Bk3018700; Wed, 17 Dec 2003 14:07:11 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHL7BWr018699; Wed, 17 Dec 2003 14:07:11 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 14:07:11 -0700 (MST) From: Alex Rousskov To: Robert Snively cc: solutions@alvestrand.no, MPowr In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] RE: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, Robert Snively wrote: > This third approach is also used by many SDOs. By maintaining > absolute process supervision powers at a level equivalent to that of > IESG, one could successfully disperse the technical review powers to > a lower level (WG and below) during the development process and to a > wide public during the superpower's process review period. I have been told by many IETF people who know better that IETF does not have enough folks willing to do process management only, without the technical work. Thus, I stopped advocating and noticing this option; I assume it is impossible given existing resources. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:28:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06336 for ; Wed, 17 Dec 2003 16:28:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjDB-0008El-0u for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLS4qN031657 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjDA-0008EW-S1 for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:28:04 -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 QAA06328 for ; Wed, 17 Dec 2003 16:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjD9-00035x-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjD7-00035j-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjD6-00035f-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjD7-0008DY-VJ; Wed, 17 Dec 2003 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjD2-0008Cc-Mk for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:27:56 -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 QAA06319 for ; Wed, 17 Dec 2003 16:27:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjD0-000350-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjD0-00034t-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:54 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AWjCz-00033y-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:53 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBHLRLIx018874; Wed, 17 Dec 2003 13:27:21 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBHLRLkN018873; Wed, 17 Dec 2003 13:27:21 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 Dec 2003 13:27:21 -0800 From: David Meyer To: Alex Rousskov Cc: MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word Message-ID: <20031217212721.GA18816@1-4-5.net> References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, Dec 17, 2003 at 01:31:31PM -0700, Alex Rousskov wrote: >> >> On Wed, 17 Dec 2003, David Meyer wrote: >> >> >>> If the WG chairs being the last resort should not be a concern, it >> >>> means no one is interested in the work of that WG, so the WG >> >>> should be disbanded, and the work filed as it is - incomplete >> >>> work, could be resumed later, if interest revives. >> > >> > In the former case (WG chairs as last resort), there are just too >> > many issues surrounding how authors work in a volunteer organization >> > to make such a (categorical) statement. >> >> Nothing in the volunteer nature of an organization implies that >> half-baked documents without authors are worth promoting to standard >> levels by heroic chair actions. Who said anything about half-baked documents without authors or promoting to standards level (other than you)? >> If we assume that WG documents must be maintained _after_ the IESG >> marks them as "proposed standard", then what Alex is saying is not >> that categorical. You are saying that a WG chair can be used as a last >> resort to save good output of a now-defunct working group. I said nothing of the sort. >> This implies that a frozen (usually at a near-PS level) output is worth >> saving for reasons other than historical. Maybe it does, but that has nothing to do with what I was saying. Dave _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:28:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06346 for ; Wed, 17 Dec 2003 16:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjDB-0008F3-Bn for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLS5NA031675 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjDB-0008Eo-5q for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:28:05 -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 QAA06331 for ; Wed, 17 Dec 2003 16:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjD9-000360-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjD6-00035d-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjD6-00035U-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjD7-0008D4-OI; Wed, 17 Dec 2003 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjCM-0008CL-Qb for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:27:14 -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 QAA06308 for ; Wed, 17 Dec 2003 16:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjCK-00033j-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjCK-00033c-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:12 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWjCJ-00033Z-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:27:11 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBHLR8012105; Wed, 17 Dec 2003 16:27:08 -0500 Message-ID: <3FE0CA27.1020308@txc.com> Date: Wed, 17 Dec 2003 16:27:03 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer CC: Pekka Savola , MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> In-Reply-To: <20031217190128.GA16958@1-4-5.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030805090507000509070308" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms030805090507000509070308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dave, Managing the authors from a timeline perspective is one thing, managing them in terms of content of documents they write is a different thing. While the former should be part of the chair's job, I strongly believe the latter should not. Adequate checks and balances have to be in place. Mentoring is important. It does not have to be done by the chairs though. It can be done by more senior members of the WG, or co-authors, or from outside the WG. If an educational arm is being organized, that could be given such a mentoring role as well. Regards, Alex David Meyer wrote: > Alex, > > >>>If the WG chairs being the last resort should not be a concern, it means >>>no one is interested in the work of that WG, so the WG should be >>>disbanded, and the work filed as it is - incomplete work, could be >>>resumed later, if interest revives. > > > While I agree that in a perfect (maybe different) world, > this could be true. In addition, you might make a similar > assertion when consensus can't be reached (notably: "No > one cares enough about this problem to compromise on a > solution" or similar). However, the reality is somewhat > different. In the former case (WG chairs as last resort), > there are just too many issues surrounding how authors > work in a volunteer organization to make such a > (categorical) statement. > > In fact, one of the jobs of a WG chair (IMO) is to manage > and (frequently overlooked, but equally important) mentor > the WG's authors. > > Dave > > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > > --------------ms030805090507000509070308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxNzIxMjcwM1owIwYJKoZIhvcNAQkEMRYEFO+bzvAet7ZHhMjx 7PZLX0p1oyDZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAHyHV4+Dfx80mTm5tp64XDTKuP73qrLDC1ywPebtl+lX7RXJuAd/2Hce9tTT PqOhqQAA8f+1Pismes1I02XCRhE71ZkwgndL0v66EeIOhrPnzSoC4FJfZp61DqQKiUwmYsuR fpFLUx3EZ6rGxqH3P0eoYdhCqPOdE9TUg650gxZyufXAllaNOGS8rNSY1LOs+RsMITK1odl3 2gZVF+qj49x8CYbe4V6/JGO/abGx69fT0B0U4qSAkYYZL5mN+npMpY5C9qfgrlDcRV7EOmEc M5T7nrNx7esqBZaiSIJrSZi9Ly2IGOXGL5GATb0TnzOnEcTIbWS8jyXNL0jNicZFsTYAAAAA AAA= --------------ms030805090507000509070308-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:30:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06448 for ; Wed, 17 Dec 2003 16:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF7-0008Ip-9e for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLU5r7031902 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF7-0008IO-03 for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:30:05 -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 QAA06417 for ; Wed, 17 Dec 2003 16:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjF4-00039F-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjF3-00038w-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjF2-00038t-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF4-0008H2-77; Wed, 17 Dec 2003 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjE5-0008FX-U0 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:29:01 -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 QAA06381 for ; Wed, 17 Dec 2003 16:28:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjE4-00037M-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:29:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjE2-00037C-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:28:59 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AWjE2-00036K-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:28:58 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 8131B1436D; Wed, 17 Dec 2003 13:28:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2003 13:28:25 -0800 Message-ID: Thread-Topic: [Solutions] Troops versus superpower Thread-Index: AcPE4cSQsak4b0BCSNmeanQrm3BkcAAABDYQ From: "Robert Snively" To: "Alex Rousskov" Cc: "MPowr" , Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Since the procedural monitoring does not require the elevated technical knowledge of the technical review, the obvious organization to support it is the IETF Secretariat, perhaps organized as an association of the Internet Society. =20 Parallels are found in IEEE (IEEE Standards Association) and ITIC (INCITS), as well as many other organizations sponsoring SDOs. Process management folks should probably be paid employees,=20 not volunteers. They should receive direction principally from an appropriate policy board and report organizationally=20 to a standards association tied to a sponsoring organization. =20 The policy board may very well be IAB or IESG, but its responsibilities should be as directors, rather than as participants. See what I mean about this being a Big Picture problem? Bob > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, December 17, 2003 1:07 PM > To: Robert Snively > Cc: MPowr; solutions@alvestrand.no > Subject: RE: [Solutions] Troops versus superpower >=20 >=20 >=20 > On Wed, 17 Dec 2003, Robert Snively wrote: >=20 > > This third approach is also used by many SDOs. By maintaining > > absolute process supervision powers at a level equivalent to that of > > IESG, one could successfully disperse the technical review powers to > > a lower level (WG and below) during the development process and to a > > wide public during the superpower's process review period. >=20 > I have been told by many IETF people who know better that IETF does > not have enough folks willing to do process management only, without > the technical work. Thus, I stopped advocating and noticing this > option; I assume it is impossible given existing resources. >=20 > Alex. > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions >=20 >=20 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:43:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07129 for ; Wed, 17 Dec 2003 16:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjRg-0000Xu-IK for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLh4U5002092 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjRg-0000Xf-Dy for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:43:04 -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 QAA07113 for ; Wed, 17 Dec 2003 16:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjRe-0003cK-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjRb-0003c9-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:43:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjRb-0003c1-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjRc-0000X0-TX; Wed, 17 Dec 2003 16:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjRa-0000Wg-GD for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:42:58 -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 QAA07110 for ; Wed, 17 Dec 2003 16:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjRY-0003bd-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:42:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjRX-0003bT-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:42:56 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWjRW-0003bI-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:42:54 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHLgqk3020316; Wed, 17 Dec 2003 14:42:52 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHLgqtE020315; Wed, 17 Dec 2003 14:42:52 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 14:42:52 -0700 (MST) From: Alex Rousskov To: David Meyer cc: MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word In-Reply-To: <20031217212721.GA18816@1-4-5.net> Message-ID: References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> <20031217212721.GA18816@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, David Meyer wrote: > On Wed, Dec 17, 2003 at 01:31:31PM -0700, Alex Rousskov wrote: > >> > >> On Wed, 17 Dec 2003, David Meyer wrote: > >> > >> >>> If the WG chairs being the last resort should not be a concern, it > >> >>> means no one is interested in the work of that WG, so the WG > >> >>> should be disbanded, and the work filed as it is - incomplete > >> >>> work, could be resumed later, if interest revives. > >> > > >> > In the former case (WG chairs as last resort), there are just too > >> > many issues surrounding how authors work in a volunteer organization > >> > to make such a (categorical) statement. > >> > >> Nothing in the volunteer nature of an organization implies that > >> half-baked documents without authors are worth promoting to standard > >> levels by heroic chair actions. > > Who said anything about half-baked documents without > authors or promoting to standards level (other than you)? The original remark by (Pekka Savola?) implied that context, IMO: > Removing that possibility might be interesting, but would the WG get > anything done then? :-) WG chairs are often the last resort of > pushing through the documents when WG falls into paralysis :-) Documents of a paralytic WG are usually half-baked. "Pushing through" in this context implies "promoting to standard levels" to me. If I misunderstood the context, I apologize. I hope my agreement with Alex reaction that such a WG should be disbanded would still stand in the "right" context, whatever that is. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 16:48:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07318 for ; Wed, 17 Dec 2003 16:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjWV-0000hn-AR for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLm38n002705 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjWV-0000hY-4P for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:48: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 QAA07293 for ; Wed, 17 Dec 2003 16:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjWT-0003jk-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjWS-0003jd-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:48:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjWS-0003ja-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjWT-0000gn-Hj; Wed, 17 Dec 2003 16:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjVh-0000f2-UN for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:47: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 QAA07266 for ; Wed, 17 Dec 2003 16:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjVf-0003it-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:47:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjVf-0003im-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:47:11 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AWjVe-0003hT-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:47:10 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBHLkaIx019595; Wed, 17 Dec 2003 13:46:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBHLkaDa019594; Wed, 17 Dec 2003 13:46:36 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 Dec 2003 13:46:36 -0800 From: David Meyer To: Alex Rousskov Cc: MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word Message-ID: <20031217214636.GA19577@1-4-5.net> References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> <20031217212721.GA18816@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, Dec 17, 2003 at 02:42:52PM -0700, Alex Rousskov wrote: >> On Wed, 17 Dec 2003, David Meyer wrote: >> >> > On Wed, Dec 17, 2003 at 01:31:31PM -0700, Alex Rousskov wrote: >> > >> >> > >> On Wed, 17 Dec 2003, David Meyer wrote: >> > >> >> > >> >>> If the WG chairs being the last resort should not be a concern, it >> > >> >>> means no one is interested in the work of that WG, so the WG >> > >> >>> should be disbanded, and the work filed as it is - incomplete >> > >> >>> work, could be resumed later, if interest revives. >> > >> > >> > >> > In the former case (WG chairs as last resort), there are just too >> > >> > many issues surrounding how authors work in a volunteer organization >> > >> > to make such a (categorical) statement. >> > >> >> > >> Nothing in the volunteer nature of an organization implies that >> > >> half-baked documents without authors are worth promoting to standard >> > >> levels by heroic chair actions. >> > >> > Who said anything about half-baked documents without >> > authors or promoting to standards level (other than you)? >> >> The original remark by (Pekka Savola?) implied that context, IMO: >> >> > Removing that possibility might be interesting, but would the WG get >> > anything done then? :-) WG chairs are often the last resort of >> > pushing through the documents when WG falls into paralysis :-) >> >> Documents of a paralytic WG are usually half-baked. "Pushing through" >> in this context implies "promoting to standard levels" to me. >> >> If I misunderstood the context, I apologize. I hope my agreement with >> Alex reaction that such a WG should be disbanded would still stand in >> the "right" context, whatever that is. No worries. I think we're agreeing for the most part. Dave _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 17:21:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06449 for ; Wed, 17 Dec 2003 16:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF7-0008Io-9J for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLU5si031903 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 16:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF7-0008IP-1H for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:30:05 -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 QAA06415 for ; Wed, 17 Dec 2003 16:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjF4-00039C-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjF3-000394-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjF3-000391-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 16:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjF4-0008Hp-GC; Wed, 17 Dec 2003 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjEO-0008Fp-B3 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 16:29:20 -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 QAA06394 for ; Wed, 17 Dec 2003 16:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjEM-000381-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:29:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjEL-00037u-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:29:18 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AWjEL-000371-00 for mpowr@ietf.org; Wed, 17 Dec 2003 16:29:17 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBHLSjIx018904; Wed, 17 Dec 2003 13:28:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBHLSj8a018903; Wed, 17 Dec 2003 13:28:45 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 Dec 2003 13:28:45 -0800 From: David Meyer To: Alex Conta Cc: Pekka Savola , MPowr , solutions@alvestrand.no Subject: Re: [Solutions] Re: [mpowr] Re: Quality Control and that nasty A word Message-ID: <20031217212845.GB18816@1-4-5.net> References: <3FE0A58B.9050908@txc.com> <20031217190128.GA16958@1-4-5.net> <3FE0CA27.1020308@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE0CA27.1020308@txc.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 >> Managing the authors from a timeline perspective is one thing, managing >> them in terms of content of documents they write is a different thing. >> While the former should be part of the chair's job, I strongly believe >> the latter should not. Adequate checks and balances have to be in place. I understand the distinction you are drawing, and I for the most part agree. >> Mentoring is important. It does not have to be done by the chairs >> though. It can be done by more senior members of the WG, or co-authors, >> or from outside the WG. If an educational arm is being organized, that >> could be given such a mentoring role as well. Sure. Dave _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 17:36:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09649 for ; Wed, 17 Dec 2003 17:36: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 1AWkGz-0002yE-6S for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 17:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHMa5EW011417 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 17:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWkGy-0002y4-V1 for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 17:36:05 -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 RAA09639 for ; Wed, 17 Dec 2003 17:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWkGw-0005hK-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 17:36:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWkGv-0005hB-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 17:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWkGv-0005h8-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 17:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWkGw-0002xe-Ud; Wed, 17 Dec 2003 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWkGR-0002ww-Oq for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 17:35:31 -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 RAA09628 for ; Wed, 17 Dec 2003 17:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWkGP-0005gf-00 for mpowr@ietf.org; Wed, 17 Dec 2003 17:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWkGO-0005gY-00 for mpowr@ietf.org; Wed, 17 Dec 2003 17:35:28 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWkGO-0005gV-00 for mpowr@ietf.org; Wed, 17 Dec 2003 17:35:28 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBHMZP013301; Wed, 17 Dec 2003 17:35:25 -0500 Message-ID: <3FE0DA2C.1000807@txc.com> Date: Wed, 17 Dec 2003 17:35:24 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: Robert Snively , MPowr , solutions@alvestrand.no References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070506010704090101020004" Subject: [mpowr] Re: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms070506010704090101020004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, Alex Rousskov wrote: > On Wed, 17 Dec 2003, Robert Snively wrote: > > >>This third approach is also used by many SDOs. By maintaining >>absolute process supervision powers at a level equivalent to that of >>IESG, one could successfully disperse the technical review powers to >>a lower level (WG and below) during the development process and to a >>wide public during the superpower's process review period. > > > I have been told by many IETF people who know better that IETF does > not have enough folks willing to do process management only, without > the technical work. Thus, I stopped advocating and noticing this > option; I assume it is impossible given existing resources. > > Alex. You say you've been told "IETF does not have enough folks willing to do process management only, without the technical work". I believe that. But a separation of process management from technical work, in case of N WGs in IETF, will allow X to chair WG A, and do technical work in as many WGs as X wants except A, which is N-1 WGs. So I do not see why you stopped? Individual X can do both process management and technical work. Regards, Alex C. --------------ms070506010704090101020004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxNzIyMzUyNFowIwYJKoZIhvcNAQkEMRYEFAguOx/RyjgxTyhj EecXRt8hzOeUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAEyuVXbIholYf1d0jJ3TBiO1k0sZZBnTYpu4GN+rA2fUHL/EdwffJfHszFxR NVDDl9KLP91ADHuiXLNgk4lKYY+Dj8Uk1M0Bi6sillHqQoxoZa2kxrEC+G8WJbrKfaj5ofEh Z9p3Usce9V7KdA6z0fIwkC3hT6uNeFbBO+mYFEPSRI63NKjozjxjmZ4AJ+0kHw+dxFpB1jDS DodYxWKi2joztNX6rAjrfjfdcJ7S/enBvQnD+szdzrlq+Q9OSzXbeCKRftzxXztNVWKof+xM DaRX16yk1VK98iil5S7OK9tUnL/C0S2+K1PZd3zkDdznT62hPAAgUWXkScrIbjbtqqsAAAAA AAA= --------------ms070506010704090101020004-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 19:01:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14874 for ; Wed, 17 Dec 2003 19:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWlbE-0005Y0-VG for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 19:01:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI014ef021323 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 19:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWlbE-0005Xq-NH for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 19:01:04 -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 TAA14849 for ; Wed, 17 Dec 2003 19:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWlbB-0001V5-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:01:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWlb9-0001Ut-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:01:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWlb9-0001Up-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:00:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWlbB-0005X7-8j; Wed, 17 Dec 2003 19:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWlaf-0005WK-Vf for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 19:00:30 -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 TAA14840 for ; Wed, 17 Dec 2003 19:00:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWlac-0001Tt-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:00:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWlab-0001Tm-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:00:26 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWlab-0001Tj-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:00:25 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBI00Nk3026357; Wed, 17 Dec 2003 17:00:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBI00M83026356; Wed, 17 Dec 2003 17:00:22 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 17:00:22 -0700 (MST) From: Alex Rousskov To: Alex Conta cc: Robert Snively , MPowr , solutions@alvestrand.no In-Reply-To: <3FE0DA2C.1000807@txc.com> Message-ID: References: <3FE0DA2C.1000807@txc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] Re: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, Alex Conta wrote: > Alex Rousskov wrote: > > On Wed, 17 Dec 2003, Robert Snively wrote: > >>This third approach is also used by many SDOs. By maintaining > >>absolute process supervision powers at a level equivalent to that of > >>IESG, one could successfully disperse the technical review powers to > >>a lower level (WG and below) during the development process and to a > >>wide public during the superpower's process review period. > > > > I have been told by many IETF people who know better that IETF > > does not have enough folks willing to do process management only, > > without the technical work. Thus, I stopped advocating and > > noticing this option; I assume it is impossible given existing > > resources. > > But a separation of process management from technical work, in case > of N WGs in IETF, will allow X to chair WG A, and do technical work > in as many WGs as X wants except A, which is N-1 WGs. True, but does not help on an IESG level where N equals 1. > So I do not see why you stopped? Individual X can do both process > management and technical work. You are ignoring the IESG-level context of this discussion, which is very important. Robert said "at a level equivalent to that of IESG". I responded that, at that level, we will lack manager-only volunteers. There is no 3rd option in an IESG-level context. Robert then said that we can hire those managers. At the WG level, many manager-only volunteers exist. If we believe in IESG as superpower, IESG should control those volunteers and we should relax, submit improvement comments, and vote. If we do not, we should move current IESG powers to WGs, eliminating the IESG overload problem and creating other, different problems. In either case, WG Chair authority seems like a non-issue (for different reasons). Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 19:50:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16407 for ; Wed, 17 Dec 2003 19:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmMf-0007Mj-Mr for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 19:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI0o5OQ028307 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 19:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmMf-0007MU-I6 for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 19:50:05 -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 TAA16369 for ; Wed, 17 Dec 2003 19:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmMd-0002o8-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:50:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmMc-0002no-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWmMb-0002nk-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 19:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmMd-0007Lm-54; Wed, 17 Dec 2003 19:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmMZ-0007LG-N2 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 19:49:59 -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 TAA16356 for ; Wed, 17 Dec 2003 19:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmMX-0002nI-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:49:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmMW-0002nB-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:49:57 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AWmMW-0002lh-00 for mpowr@ietf.org; Wed, 17 Dec 2003 19:49:56 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 6949814386; Wed, 17 Dec 2003 16:49:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2003 16:49:25 -0800 Message-ID: Thread-Topic: [Solutions] Troops versus superpower Thread-Index: AcPE+fXUlyvfeCKQTGGdX9oreRnbgwABF1Hg From: "Robert Snively" To: "Alex Rousskov" , "Alex Conta" Cc: "MPowr" , Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] Troops versus superpower 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alex, That is a very interesting idea. It would allow the WG management type WG leader to verify and guarantee that the proper process is completed, taking much of that load off the central authorities. I still believe that some administrative oversight is required for such a person, since any actions contrary to the procedures leave the WG and the whole IETF open to various legal controversies. That might require DA participation or a much smaller central administrative authority. A publicly accessible check list with a document tied to each check mark might be adequate for such oversight, reducing the centralized administrative load significantly. Completion criteria for the check list items would have to be established so that management type WG leaders had clear indications they could sign off on a check mark. That is one reason why I believe a balloting body requiring both "yes" and "no with comments" responses is still a necessity. Proper completion of the process would be the standard of "technical completion", no further overseen by the IESG. Training would be a continuing project, since the management type WG leader would have to be able to interface with all the editorial and technical liaison interfaces, as well as administering the process. Broad distribution of the project proposal which kicks off a particular check list would also be desirable to make sure proper liaisons were committed. The IESG and area directors would then become technically active (if they chose) through the liaison paths early on in the development process, avoiding the congestion paths near the end of the development process. Could something like that fit into the IETF context? Bob > > But a separation of process management from technical work, in case > > of N WGs in IETF, will allow X to chair WG A, and do technical work > > in as many WGs as X wants except A, which is N-1 WGs. >=20 > True, but does not help on an IESG level where N equals 1. >=20 > > So I do not see why you stopped? Individual X can do both process > > management and technical work. >=20 > You are ignoring the IESG-level context of this discussion, which is > very important. Robert said "at a level equivalent to that of IESG". I > responded that, at that level, we will lack manager-only volunteers. > There is no 3rd option in an IESG-level context. Robert then said that > we can hire those managers. >=20 > At the WG level, many manager-only volunteers exist. If we believe in > IESG as superpower, IESG should control those volunteers and we should > relax, submit improvement comments, and vote. If we do not, we should > move current IESG powers to WGs, eliminating the IESG overload problem > and creating other, different problems. In either case, WG Chair > authority seems like a non-issue (for different reasons). _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 21:33:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18816 for ; Wed, 17 Dec 2003 21:33: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 1AWnyK-0001Zg-3A for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 21:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI2X4Kd006046 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 21:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWnyJ-0001ZR-TU for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 21:33: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 VAA18804 for ; Wed, 17 Dec 2003 21:33:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWnyG-0004xl-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 21:33:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWnyF-0004xW-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 21:33:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWnyF-0004xT-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 21:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWnyH-0001Z7-GM; Wed, 17 Dec 2003 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWnxt-0001YZ-F0 for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 21:32:37 -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 VAA18785 for ; Wed, 17 Dec 2003 21:32:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWnxq-0004vp-00 for mpowr@ietf.org; Wed, 17 Dec 2003 21:32:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWnxp-0004vi-00 for mpowr@ietf.org; Wed, 17 Dec 2003 21:32:34 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AWnxp-0004vE-00 for mpowr@ietf.org; Wed, 17 Dec 2003 21:32:33 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003121802320101600rpd9se> (Authid: sdawkins@comcast.net); Thu, 18 Dec 2003 02:32:01 +0000 Message-ID: <031e01c3c50f$1ffe80e0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Solutions Mailing List" , Date: Wed, 17 Dec 2003 20:32:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [mpowr] Premature MPOWRment? 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We seem to have started the MPOWR mailing list that is being used for no other purpose than as a backup mailing list archive for SOLUTIONS. How about if we stop cross-posting between MPOWR and SOLUTIONS for a bit? No one has screamed that the discussion being crossposted is off-topic for SOLUTIONS yet, so my suggestion would be that we use SOLUTIONS to discuss MPOWR (seems counterintuitive, but we're at least crossposting to SOLUTIONS now)... It's just a thought. Spencer _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 22:14:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19926 for ; Wed, 17 Dec 2003 22:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc4-0003Gq-T1 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3E8K9012566 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc3-0003Dw-Nw for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14: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 WAA19899 for ; Wed, 17 Dec 2003 22:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWoc0-0005ue-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobw-0005uC-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005u7-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoby-0003Df-5s; Wed, 17 Dec 2003 22:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWeua-0003E8-8B for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 11:52:36 -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 LAA19775 for ; Wed, 17 Dec 2003 11:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWeuZ-0006UH-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:52:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWeuY-0006UA-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:52:34 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AWeuX-0006U1-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:52:33 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBHGx8316769; Wed, 17 Dec 2003 08:59:08 -0800 Date: Wed, 17 Dec 2003 08:51:54 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3986118.20031217085154@brandenburg.com> To: "James Kempf" CC: "MPowr" , solutions@alvestrand.no Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) In-Reply-To: <02c601c3c420$45177a70$5b6015ac@dclkempt40> References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <319857739.20031216121114@brandenburg.com> <02c601c3c420$45177a70$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, >> A very serious problem with trying to assign responsibility to the Chair >> for quality, and the like, is that it _removes_ responsibility away from >> the rest of the working group. JK> This presumes that the motivations of the WG are to not produce a quality JK> spec. Sorry, no. It presumes nothing of the sort. It simply uses the observation that explicitly assigning responsibility to one agent serves to imply that other agents do not have the responsibility. This is a pretty well-studied psychological phenomenon. So, consider the difference between saying that the chair is responsible for quality and timeliness, versus saying that the working group is responsible for quality and timeliness and the chair is responsible for facilitating the working group's fulfillment of its responsibility. JK> While this may sometimes be the case, It must _never_ be the case. If the working group is not responsible, then who the heck is the work for? This is another example of how the IETF differs from a regular product company. The people producing a specification must be representative of the community that will use it. JK> Your pithy formulation of "review early, review often" is relevant here. The JK> WG needs to be responsible for quality, the WG chair needs to be responsible JK> to make sure that is carried through No. The working group needs to be responsible for it. The chair needs to coordinate/facilitate getting it done. If the working group does not own that responsibility, then it ultimately does not own the work of the working group. JK> As mentioned earlier, new proposed WG charters are starting to have JK> quality assurance plans. Suppose the IESG were to require that a JK> charter contain a QA plan before the charter is approved. Thus, the JK> WG is taking responsibility for quality by proposing the QA plan, I like that. I suspect its main benefit will be to force the working group to think about QA and to be explicit in the commitment to achieving it. The nice thing about your suggestion is that it imposes a basic requirement and lets the proto-working group participants figure out how to achieve it. That's a very IETF style of solving things. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 22:14:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19927 for ; Wed, 17 Dec 2003 22:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc5-0003H8-8L for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3E93X012584 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc5-0003Gt-3f for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14:09 -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 WAA19908 for ; Wed, 17 Dec 2003 22:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWoc1-0005uu-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobw-0005uG-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005u0-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWobx-0003DI-Vq; Wed, 17 Dec 2003 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWejO-0002Gu-VT for mpowr@optimus.ietf.org; Wed, 17 Dec 2003 11:41: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 LAA19125 for ; Wed, 17 Dec 2003 11:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWejN-0005yH-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:41:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWej8-0005vn-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:41:00 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AWej6-0005pu-00 for mpowr@ietf.org; Wed, 17 Dec 2003 11:40:44 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hBHGlI315908; Wed, 17 Dec 2003 08:47:18 -0800 Date: Wed, 17 Dec 2003 08:40:04 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <857062833.20031217084004@brandenburg.com> To: Pete Resnick CC: MPowr , solutions@alvestrand.no Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal) In-Reply-To: References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, >>One argument some have made against giving the WG chairs more X >>stuff is that we don't get very good people as WG chairs. PR> Straw man. I've certainly never said that. It is pretty close to something that I said. Of course, I tried to be a bit more diplomatic, casting the problem in terms of working group chairs having less experience. The simple point is that we already have a power with ADs sometimes exercising their power inappropriately, so we should assume that moving things down to the chair will suffer at least as much of a problem. Given that chairs are usually less experienced and are chosen in a different fashion, the problem could become much worse. However I think that your own point about the inherent power of the working group, compared with the derived power of IETF management, including chairs, is the most important point. This is where reference to the IETF's being a volunteer organization is so important. The troops really are in charge. When we run things without paying attention to that, we get volunteers who leave, by giving up on the working group. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 22:14:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19978 for ; Wed, 17 Dec 2003 22:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc8-0003Hq-6Y for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3EC5N012628 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc6-0003HM-Rc for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14:12 -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 WAA19894 for ; Wed, 17 Dec 2003 22:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWobz-0005uX-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobv-0005tl-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005tg-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWobx-0003Bi-7J; Wed, 17 Dec 2003 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOVm-0003Qq-Jy for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 18:21:55 -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 SAA13927 for ; Tue, 16 Dec 2003 18:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOVj-0001l0-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:21:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOVi-0001kt-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:21:51 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWOVi-0001kp-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:21:50 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBGNLk027820; Tue, 16 Dec 2003 18:21:46 -0500 Message-ID: <3FDF9389.2050008@txc.com> Date: Tue, 16 Dec 2003 18:21:45 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bradner CC: Margaret.Wasserman@nokia.com, presnick@qualcomm.com, mpowr@ietf.org, solutions@alvestrand.no References: <20031212221932.AA5DAA2C5F@newdev.harvard.edu> In-Reply-To: <20031212221932.AA5DAA2C5F@newdev.harvard.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060301090605090705090404" Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms060301090605090705090404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I watched the mike, and spoke with other IETFers during the plenary - not Scott - most of whom have been around for quite some time, and with no exception I heard more concerns than agreement. So many expressing concerns is too many. It is far from any consensus I have seen in IETF. Alex Scott Bradner wrote: >>I wasn't at the Thursday evening plenary, but the minutes >>indicate that 60% of the people in the room thought that the >>WG Chairs proposal was a good idea, 10% thought it was a=20 >>bad idea and 10% didn't know. > > > lets just say that I disagree with the idea that anywhere that > % of the folks in the room expressed WG chairs proposal was > a "good idea" - so far I have found almost no one who thought that > the specific proposal was a good idea - only 2 or 3 people said they > did at the mike - the rest expessed varing degrees of objection > > I do think that most people thought that talking about the issue > was a good idea > > but let get some others say what they saw > > Scott > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions > > --------------ms060301090605090705090404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTYyMzIxNDVaMCMGCSqGSIb3DQEJBDEWBBSG2n1Shl1wIz0BHCXc 4El4RgRRCDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQCIOuWklhEUcluosDAqgQloZup9HtTunEO6/dUkZSV5nu3Lpaqtl4YyF2EHAZga bwTbkRXhimUMY+EC8kglVtwUkERhUNyGumtgVUmaThzUumJ+DFpHHFRJQ+/FqRJKBn7JXdWX ZVMmkqSGao64oG9f0OFRqJhArc+z4ai4qwoHson26+iV/+BEEfJEBN5/0X6XEojyW72dGn8U puR1rTSYS8S3aCfh113RYPc/w+WdO/xwy6R6K4VHbDXyryIkP4xbmGmHKGKsQaMiN+Wy9iba RbE1tjwLYnymevyC0O5whnWgvyJwZuqk/CBjqKAyqSr+pziDSVgylzq8Jy3fny/9AAAAAAAA --------------ms060301090605090705090404-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 22:14:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19990 for ; Wed, 17 Dec 2003 22:14:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc8-0003Hb-04 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3EBjC012613 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc5-0003G6-L4 for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14:11 -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 WAA19902 for ; Wed, 17 Dec 2003 22:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWoc1-0005uh-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobv-0005tw-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005ti-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWobx-0003CK-JI; Wed, 17 Dec 2003 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWQGR-0000QK-Vx for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 20:14:12 -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 UAA18250 for ; Tue, 16 Dec 2003 20:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWQGP-0005EG-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:14:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWQGO-0005E9-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:14:09 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWQGN-0005Dw-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:14:08 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBH1E0029002; Tue, 16 Dec 2003 20:14:00 -0500 Message-ID: <3FDFADD7.1030701@txc.com> Date: Tue, 16 Dec 2003 20:13:59 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret.Wasserman@nokia.com CC: john-ietf@jck.com, presnick@qualcomm.com, mpowr@ietf.org, solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030509010905000308000100" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms030509010905000308000100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see inline Margaret.Wasserman@nokia.com wrote: > Hi John, > > I find that I must respectfully disagree with you. > > >>* While it may be difficult to do so, it is ultimately more >>reasonable to judge _IETF_ consensus on a procedural issue by >> [...] > > We get, by far, the highest number of respondents when we > conduct polls at the plenaries, and perhaps those polls are > our best way to judge "IETF consensus". However, they select > for people who can afford to attend the meetings, and they are > usually limited to simple (yes/no) questions. > The polls may in fact hide a superficial knowledge of the topic, and may reflect an immediate reaction to the eloquence, or wit of the person conducting the poll. Which is why polls in the plenary are not always the best indication. >> [...] >>Just >>make an announcement about what you are expecting WG Chairs to >>do and that you will rubber-stamp that action, without delay, >>when it gets to you as AD. > > Some of this is already being done. > > It isn't clear that individual ADs can run all of the experiments > that we'd like to see run. > > For instance, I'd like WG chairs to have the authority to temporarily > suspend the posting privileges of disruptive mailing list participants, > but that isn't something I can "just do", since it is not within my > perogative to approve the suspension -- the whole IESG needs to approve > it. > This is extermely dangerous, and am against it! Poeple that make just noise are ignored anyway, and do not need suspension of privileges. Giving such a privilege to chairs is just creating even a better dictatorial environment than the one existing today, and a way to ensure that mailing list will be 100% chair-friendly. Expect then to see some mailing list called 'free-X WG', or 'free-IETF' ! >[...] > >>(2) The other major concern that has been voiced involves WG >>Chairs abusing their (possibly new-found) power. Chairs already have a lot of power, exacerbated by the right to participate directly to the output of the chaired WG. Which gives the easy key to progress in the WG: "have the chair as a co-author of your spec". Such a right does not exist in any of the other major SDOs I am familair with. >> But WG Chairs >>serve more or less at the pleasure of ADs. This is a disturbing acknowledgment of a BIG problem, since it goes two ways - both that the ADs can fire a WG chair at will, and that the ADs can choose and keep a WG chair as long as they want. >> An abuse can be >>discussed with the relevant AD (the procedures are pretty clear >>about that). If the AD refuses to do anything, that situation >>can be appealed (that is less clear from the procedures, but, >>IMO, it would be completely rational for the community to >>consider recalling any AD who said "my nit-picking reading of >>the procedures doesn't permit an appeal in this case, so I vote >>to reject it without considering the issues"). > > > I more-or-less agree that this should be sufficient chain of > accountability, So you yourself are not 100% sure about the chain. The problem is that the check and balances is fragile - to be mild - and too many times not working as it is. More power to the WG chairs, is going to further exacerbate an existing reality - the friends of the WG chairs have a better chance to succeed in a WG. The check and balances mechanism need major changes or major reinforcement, before any more power being given to the WG chairs. > but unfortunately there are some well-respected > and outspoken members of the community who do not agree. Luckily. > So, > we need to do some more work before we can any reach consensus in > this area. > Maybe you just suspend the posting rights to the outspoken ones... > >>If, once we have the output from this type of experimental >>process, we conclude that the relevant BCPs need rewriting (as I >>suspect we will), that is the right time to form WGs, if needed. >>They will, at that point, have firm experience behind them to >>evaluate. But, right now, I think the criterion for forming >>more WGs ought to be "there is evidence that we need to do X, >>and we can't even try that without a change in procedures". > > > I think that there is evidence that we need to give WG Chairs more > authority to control WG mailing lists. Cenzorship made it easy. NOoooooooooooooooooooooooooo. > I also think that we want > to give WG chairs the authority to hold the WG to a set of internal > WG processes that may include criteria for accpetance at various > stages and/or certain amounts of cross-area or expert review. > There is enough room for wrong doing right now, that would just make more room. > [...] it > would be nice if our BCPs were less ambiguous about the responsibility > and authority of WG chairs. > I certainly agree with that. Alex > Margaret > > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions > > --------------ms030509010905000308000100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTcwMTEzNTlaMCMGCSqGSIb3DQEJBDEWBBQ+FsVlhycUQ5LJEeJp 5eQTtihUnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQCXCMOw08T18nj4TlCoWHwSmHZ+juDUBgOIWYtbdEhuAroarYkUpHeoobdfifbB GmDUTf95iTHbtTc9p0bD6NUVTPcD5sxO35QQVmf4mZ1+416lKBXqTYlh+O3UD3ZGJu1ifdsS LtpD/7x9IRolobgTD2Zoj3henkgujkhpFTSsWc2BNv/zjpkVqC6zKHwW9HoAjx2c08H2ovrb Ag4umsJFJIrt5WTgGrgCdfk88wBooH2vJ+G8Pm3ANERkMUlNTjqYh4/KP1ivpUDokJJPFgQm sh+ja8WioXFRUUl/CTcLCI6iwi/WMKaoC3aUNFl1Zmmuk+Xq3vT9b1WxG3noOVe9AAAAAAAA --------------ms030509010905000308000100-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 23:03:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19925 for ; Wed, 17 Dec 2003 22:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc4-0003GK-I7 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3E8HK012536 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc2-0003Dv-Ay for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14:06 -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 WAA19896 for ; Wed, 17 Dec 2003 22:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWoby-0005uU-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobv-0005to-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005th-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWobx-0003Bq-CI; Wed, 17 Dec 2003 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOmc-0004n4-2c for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 18:39:18 -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 SAA14833 for ; Tue, 16 Dec 2003 18:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOmZ-0002Vq-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:39:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOmY-0002Vj-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:39:14 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWOmX-0002Vf-00 for mpowr@ietf.org; Tue, 16 Dec 2003 18:39:13 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBGNd7028005; Tue, 16 Dec 2003 18:39:07 -0500 Message-ID: <3FDF979A.2000907@txc.com> Date: Tue, 16 Dec 2003 18:39:06 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Pete Resnick , Dave Crocker , MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG proposal References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> In-Reply-To: <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000606090505060107030508" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000606090505060107030508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see in line James Kempf wrote: > Pete, > > > I agree with Margaret's basic contention: the WG chairs need the authority > to be able to hold specs because, in their design judgement, the spec is > flawed. > [...] How is this fairness and impartiality supposed to work in case the WG chair is an author or co-author of a competing spec? Would a chair ever block a document he is author or co-author of? I've seen enough in the last 10 years or so in IETF to say that in current conditions, I think this very basic contention is wrong. Alex --------------ms000606090505060107030508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTYyMzM5MDZaMCMGCSqGSIb3DQEJBDEWBBSiZUHfkaDbRhjNjMEC rZ7qYTi6DzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQCQfrJd5IRDjCVoStIFlp/6dgzLHRXttLmqCWVuZFm/pnHapVUelwM+qL1pU+Po BnCgLXCflV2ZHs0M/o8zWIuci7NbKBvdX2iFDmdAg7EryJTKY1cVqBGPuF+nVcCUywKn2R2w lYqbIrLY9aloJEmvX0no9a4X86LBot+MWhhvmGIpxgByp8+VKBuZTPeoXjVS6+TXioqrYetZ 8/sxXwOPXXiHToOXeHxZVx27EqhCCtxDiJ5EgfhGS47L/OmGlnXsngHQEKLUS2XEz3CO7I+I vyhySpX7VkpeUOuQBFDFRHkr14yJwCCZjFsDpNnxVYBHCKeFeQjhzSGFQFCdI0USAAAAAAAA --------------ms000606090505060107030508-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 17 23:03:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19924 for ; Wed, 17 Dec 2003 22:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc4-0003Gb-KQ for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3E8xd012551 for mpowr-archive@odin.ietf.org; Wed, 17 Dec 2003 22:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoc4-0003GB-EN for mpowr-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:14: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 WAA19905 for ; Wed, 17 Dec 2003 22:14:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWoc1-0005um-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWobv-0005u4-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:14:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWobv-0005tr-00 for mpowr-web-archive@ietf.org; Wed, 17 Dec 2003 22:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWobx-0003Ca-OP; Wed, 17 Dec 2003 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWQU4-0000u2-Ai for mpowr@optimus.ietf.org; Tue, 16 Dec 2003 20:28:16 -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 UAA18752 for ; Tue, 16 Dec 2003 20:28:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWQU2-0005hA-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:28:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWQU1-0005h3-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:28:13 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWQU0-0005h0-00 for mpowr@ietf.org; Tue, 16 Dec 2003 20:28:13 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBH1SA029157; Tue, 16 Dec 2003 20:28:10 -0500 Message-ID: <3FDFB128.8040107@txc.com> Date: Tue, 16 Dec 2003 20:28:08 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Dave Crocker , MPowr , solutions@alvestrand.no References: <20031209220238.172C19B30A@newdev.harvard.edu> <028201c3c0fb$332bd220$666015ac@dclkempt40> <165181922.20031215084442@brandenburg.com> <030a01c3c330$cf260dd0$5b6015ac@dclkempt40> <041c01c3c34d$7050d6b0$5b6015ac@dclkempt40> <209066081.20031215141412@brandenburg.com> <04ac01c3c363$48b42510$5b6015ac@dclkempt40> <004e01c3c3f1$af209a70$5b6015ac@dclkempt40> <319857739.20031216121114@brandenburg.com> <02c601c3c420$45177a70$5b6015ac@dclkempt40> In-Reply-To: <02c601c3c420$45177a70$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080405060002090404000708" Subject: [mpowr] Re: Quality Control and that nasty A word 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080405060002090404000708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see in line James Kempf wrote: > Dave, > > >>A very serious problem with trying to assign responsibility to the Chair >>[...] > > This presumes that the motivations of the WG are to not produce a quality > spec. While this may sometimes be the case, I don't believe that it is > necessarily always the case, or rather, it should not always be the case. > The Chair and WG need to work as a team. > In many SDOs, chairs are only moderators, which keeps them (more) impartial (than otherwise). One of the problems in IETF today is that chairs are not only managers, they can be in the same time developers, and measurer of quality. A direct effect is that they can measure favorably, and promote the work they take part in developing. More power in measuring and policing quality can exacerbate the problem. > >>The chair is responsible for facilitating a fair, timely, quality >>process. The entire working group is responsible for actually achieving >>those things. >> >>This is not semantics. It is a fundamental difference in views about >>the role of the Chair. >> > > Clearly, quality requires more than just review at the end of the process. > Your pithy formulation of "review early, review often" is relevant here. The > WG needs to be responsible for quality, the WG chair needs to be responsible > to make sure that is carried through, and have the tools (relevance, what > have you) to carry it out. > > As mentioned earlier, new proposed WG charters are starting to have quality > assurance plans. Suppose the IESG were to require that a charter contain a > QA plan before the charter is approved. Thus, the WG is taking > responsibility for quality by proposing the QA plan, the IESG is judging > whether the plan is likely to succeed (from their presumably broader > experience) by approving the charter or suggesting changes, and the chair > has the responsibility for carrying the QA plan out, with the authority > (relevance, etc.) granted to him/her by the WG through the charter. As long as the chair can be also a developer, this process is fundamentally weak, and prone to play just as a tool for promoting the chair's, and chairs friends' work. > [...] > Would this satisfy your concerns? > > jak Not mine. Sorry for jumping in. Alex --------------ms080405060002090404000708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTcwMTI4MDhaMCMGCSqGSIb3DQEJBDEWBBSAI5UTr2ivM7kttidC rIpIdVp2BTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQBGcT3New22UEOB/3VZYcvnGz5AqMD3uOufTTIdmnMOPMZUze/nXujsKQT001fs nLggbo7Tshk24gu9f30/oayTGKNq4/otD122PQeNUjYxWQx1V8v//uvIcrDRJLBSqZUrTN7+ 5hiV0qyGavBqRGZ0fiIbhQeUNKZSUXERB2He9usx9ZXrxveOjmnkTpTXC73XU/qEFU2Nr1v+ yzDYwZhKRci69azkBZVJTeIvr4+aLsALEWBX10hQ+Mg0b1l0Pfdcgg5CnzpyNbGO5k8tdXd3 k6d6eLNO8BLrDMb4zXkTe0j5NqZ34xv195E6NS66D9Mc6xIJIcF/GUsLdBLh15tcAAAAAAAA --------------ms080405060002090404000708-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 02:52:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09878 for ; Thu, 18 Dec 2003 02:52: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 1AWsx1-0004cM-G1 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 02:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI7q3VI017749 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 02:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWsx1-0004cC-1I for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 02:52: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 CAA09871 for ; Thu, 18 Dec 2003 02:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWswx-0004cY-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 02:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWsww-0004cR-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 02:51:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWsww-0004cO-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 02:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWswz-0004bq-3T; Thu, 18 Dec 2003 02:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWswO-0004bA-IA for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 02:51:24 -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 CAA09858 for ; Thu, 18 Dec 2003 02:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWswK-0004bT-00 for mpowr@ietf.org; Thu, 18 Dec 2003 02:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWswJ-0004bM-00 for mpowr@ietf.org; Thu, 18 Dec 2003 02:51:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWswJ-0004b4-00 for mpowr@ietf.org; Thu, 18 Dec 2003 02:51:19 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBI7olf12418; Thu, 18 Dec 2003 09:50:47 +0200 Date: Thu, 18 Dec 2003 09:50:47 +0200 (EET) From: Pekka Savola To: Alex Conta cc: MPowr , In-Reply-To: <3FE0DA2C.1000807@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] process-only participation in WG [Troops vs superpower] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Wed, 17 Dec 2003, Alex Conta wrote: > You say you've been told "IETF does not have enough folks willing to do > process management only, without the technical work". > > I believe that. > > But a separation of process management from technical work, in case of N > WGs in IETF, will allow X to chair WG A, and do technical work in as > many WGs as X wants except A, which is N-1 WGs. > > So I do not see why you stopped? Individual X can do both process > management and technical work. My assumption is that a person participates in a WG because he wants to contribute to it (usually technically). You assume that capable individuals are willing to do process management in those WGs which they're not interested of (because, if they were, they would be participating to the WG making them uncapable to act as WG chair). That is a huge assumption in the real world. Chairing is a lot of work. Why would I (or someone else) want to waste time on something that I don't even find interesting, while I could use the same time to contribute technically in other WGs? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 10:43:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29729 for ; Thu, 18 Dec 2003 10:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Io-0000Rg-LP for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 10:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIFh2pQ001708 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 10:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Io-0000RT-HA for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 10:43:02 -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 KAA29712 for ; Thu, 18 Dec 2003 10:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0Im-0002Aq-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 10:43:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0Ik-0002Aj-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 10:42:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0Ik-0002Ag-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 10:42:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Im-0000RA-3k; Thu, 18 Dec 2003 10:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0IE-0000Qk-09 for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 10:42:26 -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 KAA29674 for ; Thu, 18 Dec 2003 10:42:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0IB-0002AP-00 for mpowr@ietf.org; Thu, 18 Dec 2003 10:42:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0IA-0002AI-00 for mpowr@ietf.org; Thu, 18 Dec 2003 10:42:23 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AX0I9-0002AF-00 for mpowr@ietf.org; Thu, 18 Dec 2003 10:42:22 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBIFgJ024619; Thu, 18 Dec 2003 10:42:19 -0500 Message-ID: <3FE1CADA.6090305@txc.com> Date: Thu, 18 Dec 2003 10:42:18 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: MPowr , solutions@alvestrand.no References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050603010902020408050000" Subject: [mpowr] Re: process-only participation in WG [Troops vs superpower] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050603010902020408050000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Wed, 17 Dec 2003, Alex Conta wrote: > >>You say you've been told "IETF does not have enough folks willing to do >>process management only, without the technical work". >> >>I believe that. >> >>But a separation of process management from technical work, in case of N >>WGs in IETF, will allow X to chair WG A, and do technical work in as >>many WGs as X wants except A, which is N-1 WGs. >> >>So I do not see why you stopped? Individual X can do both process >>management and technical work. > > [...] > You assume that capable individuals are willing to do process > management in those WGs which they're not interested of (because, if > they were, they would be participating to the WG making them uncapable > to act as WG chair). > I am not sure what you assume by "capable". People in IETF may have good technical capabilities, good people and process capabilities, or all of them. Assuming the latter, the reality is that there are so many relationships between WGs, or between areas in IETF. You yourself probably follow and contribute one way or another to several WGs, based on your personal interest. Chairing one of these WG, would just imply that you would not be a document editor, for instance, prior or during chairing that group. By the way this is a rule that exist today. On the other hand, I think it is quite possible that a "process, and people" capable person to find it very interesting to chair a WG, in which it has no technical interest. > That is a huge assumption in the real world. Chairing is a lot of > work. > Indeed chairing is a lot of work, and a lot of responsibility. I mean here process and people managament work. But chairs combine today this work, with too many technical roles: technical leader, architect, editor, reviewer, etc... in the same WG. This is bad, because it is one of the reasons some WGs are so purely managed - too many - and IETF has timely delivery problems, and other problems as well. Furthermore, the time when IETF was a couple of tens, or hundreds of people has long passed. IETF is nolonger a "small business", where X is 50% of the employees, and is performing %50 of the jobs ... It is a prestigious international open standards organization, well attended, whith a lot of work to do, and a lot of responability on its own sholders, including the creation of an environment of fairness, which is essential for developing standards. The average attendance in the last 5 years or so was way above 1000, in some cases going well over 2000. There is a large pool of people willing and able to do the technical work, and there is a considerable pool of people willing and able to do chairing WGs. People working in this industry make choices for a managerial path, or technical path in their companies. They make that choice in other major SDOs, and they can do that in IETF as well. > Why would I (or someone else) want to waste time on something > that I don't even find interesting, while I could use the same time to > contribute technically in other WGs? Back to your question, I will answer with a question: Do you mean that you would accept to be a WG chair, only if you can be the technical leader, the architect, the editor, and the reviewer of the WG? Alex --------------ms050603010902020408050000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxODE1NDIxOFowIwYJKoZIhvcNAQkEMRYEFGwKsiSJEAPOnpan EENWUY1Th6+0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAEMylhPWUJL8z/moSaO8OfinoW8agwW4npKium2ZhFLm29FBLNEix0hnKp/9 fLb4G3XyLn/K2cZbmYUDqznV9HlUWXI98PBmOGhGfzWCJqrSHINviW1dl5vT/QYgJMnsWmO2 Leap2dbSUd4ZtrID/IbFJJZ//NzYZCqv4aY0gikOl7pxWf1LP4/WcOF8JZgQBQ57TrYryaqD P0M76k8rI2GTfvTORDO7XotghupMfqIPYFSTjNntHff6MHPpDuhx/0bJueD8Z+bNVSyuCTyu m6440cFzqhCOSvNafgDM81jz6LLw4QUvkPMeK99L/MO8u6GZub3ZTjOGL46bqjlxNdoAAAAA AAA= --------------ms050603010902020408050000-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 11:20:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01558 for ; Thu, 18 Dec 2003 11:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0sk-0002L1-0y for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 11:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIGK9SU008981 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 11:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0sg-0002K2-5C for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 11:20:06 -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 LAA01537 for ; Thu, 18 Dec 2003 11:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0sf-0003dY-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0sd-0003dG-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:20:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0sd-0003dB-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0sd-0002JM-Qu; Thu, 18 Dec 2003 11:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0rd-0002Ha-RV for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 11:19:01 -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 LAA01497 for ; Thu, 18 Dec 2003 11:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0rc-0003a7-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0rb-0003Zt-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:19:00 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AX0rb-0003Xw-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:18:59 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hBIGISQe018023; Thu, 18 Dec 2003 17:18:28 +0100 Date: Thu, 18 Dec 2003 17:18:27 +0100 From: Henrik Levkowetz To: Alex Conta Cc: Pekka Savola , MPowr , solutions@alvestrand.no Message-Id: <20031218171827.03130e4c.henrik@levkowetz.com> In-Reply-To: <3FE1CADA.6090305@txc.com> References: <3FE1CADA.6090305@txc.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Thu__18_Dec_2003_17_18_27_+0100_pzvUNrroZgsnKhY5" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [mpowr] Re: [Solutions] Re: process-only participation in WG [Troops vs superpower] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 --Signature=_Thu__18_Dec_2003_17_18_27_+0100_pzvUNrroZgsnKhY5 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thursday, 18 Dec 2003, Alex Conta wrote: > On the other hand, I think it is quite possible that a "process, and > people" capable person to find it very interesting to chair a WG, in > which it has no technical interest. Don't bet on it. I'd say that was hugely improbable. > > > That is a huge assumption in the real world. Chairing is a lot of > > work. > > > > Indeed chairing is a lot of work, and a lot of responsibility. I mean > here process and people managament work. But chairs combine today this > work, with too many technical roles: technical leader, architect, > editor, reviewer, etc... in the same WG. This is bad, because it is one > of the reasons some WGs are so purely managed - too many - and IETF has > timely delivery problems, and other problems as well. I don't believe this is right - I don't think having technically capable chairs have any negative impact on the timely delivery problem at all - probably the opposite. Henrik --Signature=_Thu__18_Dec_2003_17_18_27_+0100_pzvUNrroZgsnKhY5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/4dNTeVhrtTJkXCMRAvV3AJ9jMKstVaDNNcddkS7vKdVHiittFgCcDPJU CpowzS8uM5Vg7D7F1sdMJVc= =TuD9 -----END PGP SIGNATURE----- --Signature=_Thu__18_Dec_2003_17_18_27_+0100_pzvUNrroZgsnKhY5-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 11:42:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02148 for ; Thu, 18 Dec 2003 11:42:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1Dm-0003Em-Cb for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 11:41:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIGfsKv012444 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 11:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1Dm-0003Ed-4q for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 11:41:54 -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 LAA02138 for ; Thu, 18 Dec 2003 11:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX1Df-0004Ai-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:41:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX1DF-0004AO-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:41:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX1DF-00049r-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 11:41:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1Cv-00039a-Ss; Thu, 18 Dec 2003 11:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1C0-00038o-0S for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 11:40:04 -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 LAA02086 for ; Thu, 18 Dec 2003 11:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX1Bu-000484-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:39:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX1BS-00047e-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:39:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AX1BS-00046O-00 for mpowr@ietf.org; Thu, 18 Dec 2003 11:39:30 -0500 Message-ID: <015401c3c585$7fa0c230$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Conta" , "Pekka Savola" Cc: "MPowr" , References: <3FE1CADA.6090305@txc.com> Subject: Re: [mpowr] Re: process-only participation in WG [Troops vs superpower] Date: Thu, 18 Dec 2003 08:39:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, One possible issue with your proposal, which I think Pekka is trying to get at (please correct me if I am wrong) is that up until now, IETF WG chairs have primarily been technical people, engineers who are very involved in developing the technology. If the role of a WG chair is changed to be purely administrative, we may get an increase of "standards people" who don't do much technical work but who are primarily there because their employers fund them to contribute to standards administration, and who don't really have much interest in the technology. Perhaps this is an inevitable consequence of the growth of IETF, but it will certainly change the character of the organization in a direction which I think many in IETF would not be comfortable with. That said, I believe that some changes are needed to ensure more impartiality during WG discussion and consensus calls. jak ----- Original Message ----- From: "Alex Conta" To: "Pekka Savola" Cc: "MPowr" ; Sent: Thursday, December 18, 2003 7:42 AM Subject: [mpowr] Re: process-only participation in WG [Troops vs superpower] > Pekka Savola wrote: > > > On Wed, 17 Dec 2003, Alex Conta wrote: > > > >>You say you've been told "IETF does not have enough folks willing to do > >>process management only, without the technical work". > >> > >>I believe that. > >> > >>But a separation of process management from technical work, in case of N > >>WGs in IETF, will allow X to chair WG A, and do technical work in as > >>many WGs as X wants except A, which is N-1 WGs. > >> > >>So I do not see why you stopped? Individual X can do both process > >>management and technical work. > > > > [...] > > You assume that capable individuals are willing to do process > > management in those WGs which they're not interested of (because, if > > they were, they would be participating to the WG making them uncapable > > to act as WG chair). > > > > I am not sure what you assume by "capable". People in IETF may have good > technical capabilities, good people and process capabilities, or all of > them. > > Assuming the latter, the reality is that there are so many relationships > between WGs, or between areas in IETF. You yourself probably follow and > contribute one way or another to several WGs, based on your personal > interest. Chairing one of these WG, would just imply that you would not > be a document editor, for instance, prior or during chairing that group. > By the way this is a rule that exist today. > > On the other hand, I think it is quite possible that a "process, and > people" capable person to find it very interesting to chair a WG, in > which it has no technical interest. > > > That is a huge assumption in the real world. Chairing is a lot of > > work. > > > > Indeed chairing is a lot of work, and a lot of responsibility. I mean > here process and people managament work. But chairs combine today this > work, with too many technical roles: technical leader, architect, > editor, reviewer, etc... in the same WG. This is bad, because it is one > of the reasons some WGs are so purely managed - too many - and IETF has > timely delivery problems, and other problems as well. > > Furthermore, the time when IETF was a couple of tens, or hundreds of > people has long passed. IETF is nolonger a "small business", where X is > 50% of the employees, and is performing %50 of the jobs ... It is a > prestigious international open standards organization, well attended, > whith a lot of work to do, and a lot of responability on its own > sholders, including the creation of an environment of fairness, which is > essential for developing standards. > > The average attendance in the last 5 years or so was way above 1000, in > some cases going well over 2000. There is a large pool of people willing > and able to do the technical work, and there is a considerable pool of > people willing and able to do chairing WGs. People working in this > industry make choices for a managerial path, or technical path in their > companies. They make that choice in other major SDOs, and they can do > that in IETF as well. > > > > Why would I (or someone else) want to waste time on something > > that I don't even find interesting, while I could use the same time to > > contribute technically in other WGs? > > Back to your question, I will answer with a question: > > Do you mean that you would accept to be a WG chair, only if you can be > the technical leader, the architect, the editor, and the reviewer of the WG? > > Alex > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 12:12:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03227 for ; Thu, 18 Dec 2003 12:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1gy-0004h6-R4 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 12:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIHC4P7018031 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 12:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1gy-0004gk-H4 for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 12:12:04 -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 MAA03168 for ; Thu, 18 Dec 2003 12:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX1gx-00051i-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 12:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX1gv-00051Q-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 12:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX1gv-00051N-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 12:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1gv-0004gB-GC; Thu, 18 Dec 2003 12:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX1gm-0004fg-W0 for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 12:11:53 -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 MAA03163 for ; Thu, 18 Dec 2003 12:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX1gl-00050U-00 for mpowr@ietf.org; Thu, 18 Dec 2003 12:11:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX1gk-00050N-00 for mpowr@ietf.org; Thu, 18 Dec 2003 12:11:51 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX1gj-0004zc-00 for mpowr@ietf.org; Thu, 18 Dec 2003 12:11:49 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hBIHBFN20743; Thu, 18 Dec 2003 19:11:15 +0200 Date: Thu, 18 Dec 2003 19:11:15 +0200 (EET) From: Pekka Savola To: Alex Conta cc: MPowr , Subject: Re: [mpowr] Re: process-only participation in WG [Troops vs superpower] In-Reply-To: <3FE1CADA.6090305@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Thu, 18 Dec 2003, Alex Conta wrote: > > [...] > > You assume that capable individuals are willing to do process > > management in those WGs which they're not interested of (because, if > > they were, they would be participating to the WG making them uncapable > > to act as WG chair). > > > > I am not sure what you assume by "capable". People in IETF may have good > technical capabilities, good people and process capabilities, or all of > them. I meant "capable for the job of WG chair", in your context mostly implying just process management and people skills. > Indeed chairing is a lot of work, and a lot of responsibility. I mean > here process and people managament work. But chairs combine today this > work, with too many technical roles: technical leader, architect, > editor, reviewer, etc... in the same WG. This is bad, because it is one > of the reasons some WGs are so purely managed - too many - and IETF has > timely delivery problems, and other problems as well. Has has already been stated, I do not (either, as was stated) believe timely delivery problems (for example) are caused by the WG chairs who have too many (technical roles), on the contrary. Perhaps you had an assumption, "if those WG chairs wouldn't be reviewing and architecturing, the WG could get to a more timely conclusion faster without WG chair's **interference**". Maybe, not sure if I agree, but I might. However, this would seem to imply that: - a conclusion, even a very bad one, is better than slow progress, or - WG chair's technical input to the WG would be inappropriate or misguided (i.e., WG chair is architecting something that will collapse, but (s)he does not realize that) I disagree about the former, and think that the latter is probably not so relevant (such chairs could probably be convinced of the problems). > The average attendance in the last 5 years or so was way above 1000, in > some cases going well over 2000. There is a large pool of people willing > and able to do the technical work, and there is a considerable pool of > people willing and able to do chairing WGs. I'm not sure whether these are actually so large pools. Let's take an example of 1500 people coming to a meeting. 250 of them (17%) are WG chairs, IESG, IAB etc. Let's assume that about 500 (33%) are more or less tourists, not too actively participating in the process (maybe reading mailing list, or even responding now and then). I'd guess this number is higher, but let's stick to that for now. Assume the rest are those that could be active technical participants -- 750 people, around 7 per WG (evenly distributed). That's not a whole lot of folks. The point is, I don't think there are too many folks who really want to put in the hours for active contribution (editing documents, etc.). In many WGs, this may range from between half a dozen to a dozen. Not a whole lot. The rest just hang around. WG chairs have (often) made time commitments, and feel responsible for the technical progress, and could easily contribute if no one else steps up. With this climate of huge "passive WG participation", this is a real problem in many WGs. > People working in this > industry make choices for a managerial path, or technical path in their > companies. Do those interested in pursuing the managerial path come to the IETF? I hope not, but if they maybe they could be leveraged :-) > > Why would I (or someone else) want to waste time on something > > that I don't even find interesting, while I could use the same time to > > contribute technically in other WGs? > > Back to your question, I will answer with a question: > > Do you mean that you would accept to be a WG chair, only if you can be > the technical leader, the architect, the editor, and the reviewer of the WG? Yes. I have zero interest in being only a process manager. Note the use of _can be_. If there is someone else editing the documents, I probably wouldn't need (or want to) do it. If there is someone else authoring the documents of ideas which need to be written down, maybe I wouldn't need to do it. If everybody else was carefully reviewing the products of the WG, maybe I wouldn't need to do it. If there was active, well-informed dialogue in the WG about the technical directions, maybe I wouldn't need to try to give some coherence/vision about the direction of the WG. As said, in a perfect world of very active and diverse WG participation, many issues would not be such a big problem. But that's not the world we live in.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 13:50:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08067 for ; Thu, 18 Dec 2003 13:50:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3E2-0001C6-P6 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 13:50:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIIoIjC004584 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 13:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3E2-0001Br-Jm for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 13:50:18 -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 NAA08052 for ; Thu, 18 Dec 2003 13:50:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3E0-0001Gd-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3Di-0001Dl-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:50:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3Dh-0001Cn-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:49:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX34A-0000xI-Dj; Thu, 18 Dec 2003 13:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX33b-0000w0-Cl for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 13:39:31 -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 NAA07539 for ; Thu, 18 Dec 2003 13:39:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX33Z-0000o6-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX33X-0000nz-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:39:28 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AX33X-0000nw-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:39:27 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBIIdN027534; Thu, 18 Dec 2003 13:39:23 -0500 Message-ID: <3FE1F45A.2030004@txc.com> Date: Thu, 18 Dec 2003 13:39:22 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Pekka Savola , MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: process-only participation in WG [Troops vs superpower] References: <3FE1CADA.6090305@txc.com> <015401c3c585$7fa0c230$5b6015ac@dclkempt40> In-Reply-To: <015401c3c585$7fa0c230$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050408090106040302030309" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050408090106040302030309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit James, James Kempf wrote: > Alex, > > One possible issue with your proposal, which I think Pekka is trying to get > at (please correct me if I am wrong) is that up until now, IETF WG chairs > have primarily been technical people, engineers who are very involved in > developing the technology. I think I understood Pekka's message. Chairs being technical people does not have to change, nor involvement in developing the technology. Some aspects of involvement would follow more strictly rules that in fact already exist. > If the role of a WG chair is changed to be purely > administrative, > we may get an increase of "standards people" who don't do > much technical work but who are primarily there because their employers fund > them to contribute to standards administration, and who don't really have > much interest in the technology. At the size and number of companies of the IETF meetings attendance nowadays, and the number of other SDOs that IETF members attend, there is a very significant skill diversity already. > Perhaps this is an inevitable consequence > of the growth of IETF, but it will certainly change the character of the > organization in a direction which I think many in IETF would not be > comfortable with. You're absolutely right - the growth of the IETF has an impact. The aspiration to maintain a position of a major international open standards organization cannot be fulfilled without following some basic rules used in standardization. I believe some of discomfort comes from the misunderstanding of open standardization, by confusing i)leading a technical project in a company, with ii) chairing a technical standardization WG in IETF. In developing a proprietary technology in a company, the field is narrowed by a commonality of interests, and rewards. Consequently, a technical leader can do anything, from managing his group, to being the architect, to writing, and reviewing specs. Standardization has some radical differences. An important one is that work is being done by many people/companies of diverse, and/or conflicting, and/or competing, backgrounds, interests, and ideas. The importance of impartiality and equal access is proportional with the number of people, and their diversity. Another different aspect is the reward - being a document author is the immediate personal reward, in which impartiality and equal access are important. > That said, I believe that some changes are needed to > ensure more impartiality during WG discussion and consensus calls. > > jak > Definitely, Alex >> >> >>>On Wed, 17 Dec 2003, Alex Conta wrote: >>> >>> >>>>You say you've been told "IETF does not have enough folks willing to do >>>>process management only, without the technical work". >>>> >>>>I believe that. >>>> >>>>But a separation of process management from technical work, in case of N >>>>WGs in IETF, will allow X to chair WG A, and do technical work in as >>>>many WGs as X wants except A, which is N-1 WGs. >>>> >>>>So I do not see why you stopped? Individual X can do both process >>>>management and technical work. >>> >>>[...] >>>You assume that capable individuals are willing to do process >>>management in those WGs which they're not interested of (because, if >>>they were, they would be participating to the WG making them uncapable >>>to act as WG chair). >>> >> >>I am not sure what you assume by "capable". People in IETF may have good >>technical capabilities, good people and process capabilities, or all of >>them. >> >>Assuming the latter, the reality is that there are so many relationships >>between WGs, or between areas in IETF. You yourself probably follow and >>contribute one way or another to several WGs, based on your personal >>interest. Chairing one of these WG, would just imply that you would not >>be a document editor, for instance, prior or during chairing that group. >>By the way this is a rule that exist today. >> >>On the other hand, I think it is quite possible that a "process, and >>people" capable person to find it very interesting to chair a WG, in >>which it has no technical interest. >> >> >>>That is a huge assumption in the real world. Chairing is a lot of >>>work. >>> >> >>Indeed chairing is a lot of work, and a lot of responsibility. I mean >>here process and people managament work. But chairs combine today this >>work, with too many technical roles: technical leader, architect, >>editor, reviewer, etc... in the same WG. This is bad, because it is one >>of the reasons some WGs are so purely managed - too many - and IETF has >>timely delivery problems, and other problems as well. >> >>Furthermore, the time when IETF was a couple of tens, or hundreds of >>people has long passed. IETF is nolonger a "small business", where X is >>50% of the employees, and is performing %50 of the jobs ... It is a >>prestigious international open standards organization, well attended, >>whith a lot of work to do, and a lot of responability on its own >>sholders, including the creation of an environment of fairness, which is >>essential for developing standards. >> >>The average attendance in the last 5 years or so was way above 1000, in >>some cases going well over 2000. There is a large pool of people willing >>and able to do the technical work, and there is a considerable pool of >>people willing and able to do chairing WGs. People working in this >>industry make choices for a managerial path, or technical path in their >>companies. They make that choice in other major SDOs, and they can do >>that in IETF as well. >> >> >> > Why would I (or someone else) want to waste time on something >> > that I don't even find interesting, while I could use the same time to >> > contribute technically in other WGs? >> >>Back to your question, I will answer with a question: >> >>Do you mean that you would accept to be a WG chair, only if you can be >>the technical leader, the architect, the editor, and the reviewer of the > > WG? > >>Alex >> > > > > --------------ms050408090106040302030309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxODE4MzkyMlowIwYJKoZIhvcNAQkEMRYEFARpi4JUaulzARpZ tXtcxEkHAvJvMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAKJyU0asxUb3tyMAEmnVuYtgDaeu3lgQmGcX/ZtYYO5gr2hCIeX60bcDflz+ KHWBTfxaWyTAfi22HW2fAeqmMouDF4U5gsTp4BAZKDH5Kyn8F+CH9Lex2jOwvQo88rZq9m4F Qo7XA8a8OVbzWb2dsuy0BPWTYqVEP8CjCpJIxGfx3zoKfvnOAYuhhLwvKNUreIbUWDqAEsMZ pyYJ7ZB+R5z9lQnMBh3VYgqPyA3/7LJGCgPMOjJIWzHk6Tz/uYusByxG8LbemVZqBaa+NRGS eIZFL/5zsqmD7GMEbQax/sjevCpO/wBd7b9ihBWRqzg7jwu1l9M3X+VnC6irh7oXAmYAAAAA AAA= --------------ms050408090106040302030309-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 13:50:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08082 for ; Thu, 18 Dec 2003 13:50:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3E2-0001Bq-9J for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 13:50:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIIoIOm004568 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 13:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3E2-0001Bb-3M for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 13:50:18 -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 NAA08047 for ; Thu, 18 Dec 2003 13:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3Dz-0001GT-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3Dk-0001EC-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:50:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3Di-0001Cn-01 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 13:49:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX328-0000sZ-Nh; Thu, 18 Dec 2003 13:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX31q-0000mV-JK for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 13:37:42 -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 NAA07512 for ; Thu, 18 Dec 2003 13:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX31o-0000lj-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX31n-0000lc-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:37:39 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AX31m-0000lV-00 for mpowr@ietf.org; Thu, 18 Dec 2003 13:37:38 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 837F414398; Thu, 18 Dec 2003 10:37:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Dec 2003 10:37:07 -0800 Message-ID: Thread-Topic: [Solutions] process-only participation in WG [Troops vs superpower] Thread-Index: AcPFO8nHQra6jrMZSIWQ5lFb0Rwf+gAVtqFg From: "Robert Snively" To: "Pekka Savola" , "Alex Conta" Cc: "MPowr" , Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] process-only participation in WG [Troops vs superpower] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka Savola wrote... > My assumption is that a person participates in a WG because he wants=20 > to contribute to it (usually technically). >=20 > You assume that capable individuals are willing to do process > management in those WGs which they're not interested of (because, if > they were, they would be participating to the WG making them uncapable > to act as WG chair). >=20 > That is a huge assumption in the real world. Chairing is a lot of=20 > work. Why would I (or someone else) want to waste time on something=20 > that I don't even find interesting, while I could use the=20 > same time to=20 > contribute technically in other WGs? The majority of people who bring work to the IETF at this point in its maturity are bringing that work to solve a problem that they have identified in the internet marketplace. In other words, they expect to make money or help their supporting organizations to make money by creating a=20 technological solution to a real problem. That is the reason people participate, that is the reason they are willing to take on the responsibility of chairing, and that is the reason they are interested in reviewing and forwarding=20 a particular standards track document. A significant minority of people participate in the IETF to protect market solutions that are already in place. They also get heavy support from their organizations. I believe it is a small minority of active participants that are doing it for technical interest with only their own resources. So if we are careful to include the economic and salary incentives to work within IETF as part of Pekka's "wants to contribute" it is easy to believe that working groups with projects that have an economic or practical future will have no problem getting the proper technical and managerial=20 support, while those that do not will have a great deal=20 of difficulty getting support. I believe that recognizing this characteristic is important to the continued success of IETF, even though it cuts against the grain of the supposed culture of IETF. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 14:05:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09180 for ; Thu, 18 Dec 2003 14:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3SK-0002C4-RT for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 14:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIJ54DN008426 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 14:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3SK-0002Bp-Lc for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 14:05:04 -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 OAA09153 for ; Thu, 18 Dec 2003 14:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3SI-00028H-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 14:05:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3SH-00028A-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 14:05:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3SH-000287-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 14: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 1AX3SH-0002Ap-No; Thu, 18 Dec 2003 14:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3S9-0002AT-7j for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 14:04:53 -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 OAA09141 for ; Thu, 18 Dec 2003 14:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3S6-00027e-00 for mpowr@ietf.org; Thu, 18 Dec 2003 14:04:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3S6-00027X-00 for mpowr@ietf.org; Thu, 18 Dec 2003 14:04:50 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AX3S5-00027U-00 for mpowr@ietf.org; Thu, 18 Dec 2003 14:04:49 -0500 Message-ID: <022001c3c599$dc841e20$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Conta" Cc: "Pekka Savola" , "MPowr" , References: <3FE1CADA.6090305@txc.com> <015401c3c585$7fa0c230$5b6015ac@dclkempt40> <3FE1F45A.2030004@txc.com> Subject: Re: [mpowr] Re: process-only participation in WG [Troops vs superpower] Date: Thu, 18 Dec 2003 11:05:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Standardization has some radical differences. An important one is that > work is being done by many people/companies of diverse, and/or > conflicting, and/or competing, backgrounds, interests, and ideas. The > importance of impartiality and equal access is proportional with the > number of people, and their diversity. Another different aspect is the > reward - being a document author is the immediate personal reward, in > which impartiality and equal access are important. > Yes, this gets to the point of "tussles" in the Internet, very well articulated in: Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B., "Tussle in Cyberspace: Defining Tommorow's Internet", Proceedings of Sigcomm 2002. and discussed somewhat in draft-iab-e2e-futures, a recent IAB draft. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 18 15:19:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14392 for ; Thu, 18 Dec 2003 15:19:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4bu-0005UX-P7 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 15:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIKJ2mH021103 for mpowr-archive@odin.ietf.org; Thu, 18 Dec 2003 15:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4bu-0005UI-JO for mpowr-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 15:19:02 -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 PAA14371 for ; Thu, 18 Dec 2003 15:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4bt-0005cs-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 15:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4bs-0005cl-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 15:19:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX4bs-0005ci-00 for mpowr-web-archive@ietf.org; Thu, 18 Dec 2003 15:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4bs-0005Tz-Qf; Thu, 18 Dec 2003 15:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4bo-0005Tk-9r for mpowr@optimus.ietf.org; Thu, 18 Dec 2003 15:18:56 -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 PAA14368 for ; Thu, 18 Dec 2003 15:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4bn-0005cd-00 for mpowr@ietf.org; Thu, 18 Dec 2003 15:18:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4bm-0005cW-00 for mpowr@ietf.org; Thu, 18 Dec 2003 15:18:54 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AX4bl-0005cT-00 for mpowr@ietf.org; Thu, 18 Dec 2003 15:18:53 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBIKIp029219; Thu, 18 Dec 2003 15:18:51 -0500 Message-ID: <3FE20BAA.6010803@txc.com> Date: Thu, 18 Dec 2003 15:18:50 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: MPowr , solutions@alvestrand.no Subject: Re: [mpowr] Re: process-only participation in WG [Troops vs superpower] References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060700010103060709090106" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms060700010103060709090106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Thu, 18 Dec 2003, Alex Conta wrote: > [...] >> > Why would I (or someone else) want to waste time on something >> > that I don't even find interesting, while I could use the same time to >> > contribute technically in other WGs? >> >>Back to your question, I will answer with a question: >> >>Do you mean that you would accept to be a WG chair, only if you can be >>the technical leader, the architect, the editor, and the reviewer of the WG? > > > Yes. I have zero interest in being only a process manager. > > Note the use of _can be_. If there is someone else editing the > documents, I probably wouldn't need (or want to) do it. If there is > someone else authoring the documents of ideas which need to be written > down, maybe I wouldn't need to do it. If everybody else was carefully > reviewing the products of the WG, maybe I wouldn't need to do it. If > there was active, well-informed dialogue in the WG about the technical > directions, maybe I wouldn't need to try to give some coherence/vision > about the direction of the WG. > I believe our last paragraph shows convergence. Alex --------------ms060700010103060709090106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxODIwMTg1MFowIwYJKoZIhvcNAQkEMRYEFJcwxk1FoKxpHll0 ihRRuLyFaTGDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAJbkVxArGyuVf5+SJ1q6HTKtZAJ6ttwV4+IxXkU/OeHPW/+UgeNHxQpTdvcN XGHstQ+uWnt0Th4wGWowoMNq1z00IWc/2kZf/NHudcfNUDHzI8FT/uN50ti81I34DW4+6wZ6 TD+H6JE+4TgIUJXyN+Z4f/4bNO92GnVV7gqT9N0v+DxW+c7iJBEeimMSIAyjq/ADPtK3QnN6 fDYEo4CbwPwYw6416MIt4uGloGdSZj3g/bfxkMiFGR0ZtQ3O5g+No154rxgUjOrkcEBxiNZ9 kRuuEDaQkvMkQoP2Niz+vtAWM+rAPKbJLlwMKUFJOn876Q5C0cQ5vuoPeNPZhk937CsAAAAA AAA= --------------ms060700010103060709090106-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 12:19:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16419 for ; Fri, 19 Dec 2003 12:19: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 1AXOHH-0002Qf-Js for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJHJ3B7009333 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 12:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHH-0002QS-Fn for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 12:19: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 MAA16416 for ; Fri, 19 Dec 2003 12:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOHG-0001VM-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOHE-0001VA-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXOHE-0001V7-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOHE-0002Pm-UJ; Fri, 19 Dec 2003 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOGX-0002P2-Vv for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 12:18:17 -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 MAA16396 for ; Fri, 19 Dec 2003 12:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOGW-0001Tp-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:18:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOGV-0001Ti-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:18:16 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AXOGV-0001Tf-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:18:15 -0500 Message-ID: <011901c3c654$24fdc830$5b6015ac@dclkempt40> From: "James Kempf" To: "MPowr" Date: Fri, 19 Dec 2003 09:18:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret's draft proposes letting WG chairs manage mailing list membership, rather than requiring the IESG to do it as is currently the case. From my experience as a WG chair, I can say that there is nothing as effective in derailing a WG as a disruptive mailing list participant, and once such a disruption occurs, it is often difficult to get any good technical work out of the WG because the really good technical people simply leave. I've also been told by other WG chairs who have tried that the IESG is extremely reluctant to remove someone from a mailing list, even if the evidence of disruption is quite apparent. I suspect that is why this proposal was a crowd pleaser when brought up at the plenary in Minneapolis. However, there have been some concerns expressed. Scott Bradner mentioned the potential of a liability problem, and Alex Contra mentioned the problem of chair abuse. The latter would presumably be when a chair designates as "disruptive" someone who is honestly but persistently expressing an opinion on technical matters that is contrary to what the chair believes should be part of the WG's documents. Clearly, there's a boundary here between disruption and honest disagreement, but the boundary is not always clear. Suppose that in order to join an IETF WG mailing list, a person would have to agree to a mailing list "Code of Conduct" by clicking through a page that describes it. The "Code of Conduct" could be checked by lawyers to make sure it can be defensible legally, as would the signup procedure. And it would mean that the mailing list would need to be hosted somewhere that could support a more elaborate signup procedure than today. Then, when a WG chair believes that a participant is being disruptive, (s)he would send three email messages privately to the particpant, cc'ing the AD, with specific evidence, in the form of emails, posting statistics (for people who are spamming the list), etc., requesting the participant to cease. If the three email messages don't work, the WG chair would then discuss the matter with the AD and, with the AD's approval (sent as an email message to the WG chair), the chair would send email to the participant that his/her posting privileges were being revoked for a three month period. The participant could appeal to the IESG if (s)he felt that (s)he was being treated unfairly. Comments? jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 12:59:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18189 for ; Fri, 19 Dec 2003 12:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOtz-0004GG-3Q for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 12:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJHx3u7016374 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 12:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOty-0004Ft-TU for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 12:59:02 -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 MAA18170 for ; Fri, 19 Dec 2003 12:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOtx-0002nX-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:59:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOtv-0002nI-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXOtv-0002nF-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 12:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOtw-0004FM-LV; Fri, 19 Dec 2003 12:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXOsz-0004E3-Az for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 12:58:01 -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 MAA18151 for ; Fri, 19 Dec 2003 12:57:57 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXOsx-0002m0-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:57:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXOsw-0002lt-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:57:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXOsw-0002lq-00 for mpowr@ietf.org; Fri, 19 Dec 2003 12:57:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJHvv010422 for ; Fri, 19 Dec 2003 19:57:57 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 19:57:56 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 11:56:08 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Mailing List Management Date: Fri, 19 Dec 2003 12:56:07 -0500 Message-ID: Thread-Topic: [mpowr] Mailing List Management Thread-Index: AcPGVDiEcTX1hEJgSaG5C8O0rO7OdgAA107A To: , X-OriginalArrivalTime: 19 Dec 2003 17:56:08.0520 (UTC) FILETIME=[61698480:01C3C659] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi James, Some comments in-line: > However, there have been some concerns expressed. Scott=20 > Bradner mentioned the potential of a liability problem,=20 I do not understand why allowing WG chairs to remove disruptive people from IETF mailing lists (which would be appealable, of course) would present a liability problem. Do we have a legal basis for thinking that it would? I have not heard of any liability suits related to mailing list moderation. > and Alex Contra mentioned the problem of chair abuse.=20 I would expect the chair to get a second-opinion from the AD before revoking an individual's posting privileges. In fact, my draft requires AD approval. If both the chair=20 and AD are being unreasonable, the person can appeal=20 to the full IESG. The rest of your proposal would seem to add considerably more overhead to this process, and I'm not sure what the benefits would be. I wouldn't mind if the IETF had a mailing list "code of conduct". We could send it to lists periodically, like the "note well" notices. If sending to the lists=20 periodically is sufficient for that, it should work for this, without a more sophisticated sign-up mechanism. In general, I would not like our BCPs to contain the level of detail that you've included in your note (3 private warnings, etc.). Although I think that this would be a reasonable approach for most situations, I'd prefer to leave=20 the details to the chair and AD. There are possible situations=20 (obvious and/or offensive spam, posting non-English mail, threats, serious verbal abuse) where I think it would be=20 appropriate for a WG chair to revoke someone's posting=20 privileges for 30 days without three prior warnings. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 13:48:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19583 for ; Fri, 19 Dec 2003 13:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPfP-0006EF-FG for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 13:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJIm3D4023937 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 13:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPfP-0006E0-9r for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 13:48: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 NAA19544 for ; Fri, 19 Dec 2003 13:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPfN-00046F-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 13:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPfL-00045y-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 13:48:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXPfL-00045u-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 13:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPfM-0006DB-UX; Fri, 19 Dec 2003 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPea-0006Cb-7z for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 13:47:12 -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 NAA19521 for ; Fri, 19 Dec 2003 13:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPeY-00044T-00 for mpowr@ietf.org; Fri, 19 Dec 2003 13:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPeW-00044M-00 for mpowr@ietf.org; Fri, 19 Dec 2003 13:47:09 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AXPeW-00044I-00 for mpowr@ietf.org; Fri, 19 Dec 2003 13:47:08 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBJIksk3030995; Fri, 19 Dec 2003 11:46:54 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBJIksmK030994; Fri, 19 Dec 2003 11:46:54 -0700 (MST) (envelope-from rousskov) Date: Fri, 19 Dec 2003 11:46:54 -0700 (MST) From: Alex Rousskov To: James Kempf cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <011901c3c654$24fdc830$5b6015ac@dclkempt40> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Fri, 19 Dec 2003, James Kempf wrote: > Suppose that in order to join an IETF WG mailing list, a person > would have to agree to a mailing list "Code of Conduct" ... And it > would mean that the mailing list would need to be hosted somewhere > that could support a more elaborate signup procedure than today. I believe the above would be a step in the right direction: having formal IETF membership. From technical point of view, this does not preclude anonymous membership; I am not sure about the legal point of view. This does not imply membership fees, from any point of view. For many automation tools, such as ID publication and review management, formal membership is essential. It is also a shame and a problem that IETF does not seem to know how many informal members it has, even approximately; not to mention their technical background and country of origin. Thus, if the legal burden is low, formal membership (i.e., registration) is a good thing, IMO. However, I would be [pleasantly] surprised if you can get consensus on the formal membership issue. You do not have to call it formal membership, but what your propose is, essentially, formal membership. > Then, when a WG chair believes that a participant is being > disruptive, (s)he would send three email messages privately to the > particpant, cc'ing the AD, with specific evidence, in the form of > emails, posting statistics (for people who are spamming the list), > etc., requesting the participant to cease. If the three email > messages don't work, the WG chair would then discuss the matter with > the AD and, with the AD's approval (sent as an email message to the > WG chair), the chair would send email to the participant that > his/her posting privileges were being revoked Sounds reasonable to me. To protect the innocent better, I would require that the suspect being CCed on all related correspondence with the AD. > for a three month period. This should be decided on a case-by-case basis. The rule should have a maximum suspension period and no minimum. The rule can recommend a 15 day suspension for first time offenders (10 day suspension for children; sorry, could not resist). > The participant could appeal to the IESG if (s)he felt that (s)he > was being treated unfairly. As always. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 15:11:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24037 for ; Fri, 19 Dec 2003 15:11:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQxr-0001nv-T7 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 15:11:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJKBBFO006935 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 15:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQxr-0001nm-KB for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 15:11:11 -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 PAA23938 for ; Fri, 19 Dec 2003 15:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQxo-00006l-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 15:11:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQxf-00004d-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 15:11:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXQxf-00004Y-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 15:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQxh-0001lN-67; Fri, 19 Dec 2003 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQwz-0001kL-8f for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 15:10:17 -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 PAA23794 for ; Fri, 19 Dec 2003 15:10:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQww-00001f-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQwu-00001X-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:10:13 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AXQwu-00001S-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:10:12 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBJKA8014580; Fri, 19 Dec 2003 15:10:08 -0500 Message-ID: <3FE35B1F.2000308@txc.com> Date: Fri, 19 Dec 2003 15:10:07 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: MPowr Subject: Re: [mpowr] Mailing List Management References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> In-Reply-To: <011901c3c654$24fdc830$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080901020205030905090501" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080901020205030905090501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit jak, I am very sympathetic with your experience. But, I fundamentally disagree with this proposal. Please see further comments - sorry if they are repetition of what was already said before on this topic: James Kempf wrote: > Margaret's draft proposes letting WG chairs manage mailing list membership, > rather than requiring the IESG to do it as is currently the case. From my > experience as a WG chair, I can say that there is nothing as effective in > derailing a WG as a disruptive mailing list participant, and once such a > disruption occurs, it is often difficult to get any good technical work out > of the WG because the really good technical people simply leave. I am sorry, I cannot agree with such a brute force solution. As IETF has gained over the years such a large international Email attendance, with a unequaled diversity of backgrounds, traditions, educations, opinions, interests, ideas, etc... it should put no barriers to the free expression of ideas, or opinions pertaining to the topics of a WG work. IETF is an OPEN standard, and that is a BIG difference with the other competing SDOs, which have more or even more stringent rules about their mailing lists. Freedom of speech, and free access is one of the characteristics that makes IETF OPEN. Taking away the freedom of speech should have the very high threshold, if not higher than that of today's. > I've also > been told by other WG chairs who have tried that the IESG is extremely > reluctant to remove someone from a mailing list, even if the evidence of > disruption is quite apparent. Hm, that's a browny point for IESG. On the other hand, I think IESG should have helped you resolve the crisis in the WG by other means. Have you asked for other type of help from IESG, other than stopping Email access? This sounds like a typical technical conflict resolution problem, for which there is a science and professionals, who would be glad to help. > I suspect that is why this proposal was a > crowd pleaser when brought up at the plenary in Minneapolis. > > However, there have been some concerns expressed. Scott Bradner mentioned > the potential of a liability problem, and Alex Contra mentioned the problem > of chair abuse. It is Alex Conta. There were other earlier voices on the "solutions" list. Please check. > The latter would presumably be when a chair designates as > "disruptive" someone who is honestly but persistently expressing an opinion > on technical matters that is contrary to what the chair believes should be > part of the WG's documents. Clearly, there's a boundary here between > disruption and honest disagreement, but the boundary is not always clear. > That's is exactly the reason why, if we do anything now, that should be to raise the threshold even higher. > Suppose that in order to join an IETF WG mailing list, a person would have > to agree to a mailing list "Code of Conduct" by clicking through a page that > describes it. The "Code of Conduct" could be checked by lawyers to make sure > it can be defensible legally, as would the signup procedure. And it would > mean that the mailing list would need to be hosted somewhere that could > support a more elaborate signup procedure than today. I wonder what would you put in the code of conduct regarding a technical controversy, or regarding technical content disagreement? > Then, when a WG chair > believes that a participant is being disruptive, (s)he would send three > email messages privately to the particpant, cc'ing the AD, with specific > evidence, in the form of emails, posting statistics (for people who are > spamming the list), etc., requesting the participant to cease. If the three > email messages don't work, the WG chair would then discuss the matter with > the AD and, with the AD's approval (sent as an email message to the WG > chair), the chair would send email to the participant that his/her posting > privileges were being revoked for a three month period. The participant > could appeal to the IESG if (s)he felt that (s)he was being treated > unfairly. > > Comments? > In my opinion, the reluctance of IESG to grant requests of shutting off people from the mailing list, who are within the boundaries of technical content, is wise. Alex > jak > > > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > > --------------ms080901020205030905090501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxOTIwMTAwN1owIwYJKoZIhvcNAQkEMRYEFLpUgumeaFNGR6d8 0SOb9TXeh/mdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAHprIGdDk3mYTxrgArlSXUISMXcFRB/UsIk69Hfk2YFwBn2YOv2bxsmvCgOb sz9Rod3EDdmz7HiNP2CJDlp0/PqsNX2VwMjgnpHnDLgqgYJLSg6RAKi6Oo09EJDUiog6lsCv IgkDp/JzWcFRaFMbCBxDCS2bKTm1p8rusLHKcpgT8I2NMmpxEYexM2sr72YiQ42pa07lEufX jYiXmuBs4TpyovFgjeMSb1/Ji22TzrWe1562+fMC4FMQGZmcq0Ae13IV+tR7Ho9/HAcOqUME 7F1N3t2K01yv8ecUhe2b1PwFdJBV7/WUbzvn54mVDtVq9CVVis30QoPX2Oq8CGeN9HUAAAAA AAA= --------------ms080901020205030905090501-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 16:24:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27761 for ; Fri, 19 Dec 2003 16:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6V-0003oH-Q3 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLOBV0014636 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6V-0003nt-FS for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:24:11 -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 QAA27637 for ; Fri, 19 Dec 2003 16:24:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS6T-0003GW-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6O-0003FC-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6N-0003F9-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6O-0003i0-4d; Fri, 19 Dec 2003 16:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRCP-00028v-Hd for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 15: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 PAA24868 for ; Fri, 19 Dec 2003 15:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRCO-0000am-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:26:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRCN-0000af-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:26:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AXRCN-0000ac-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:26:11 -0500 Message-ID: <022501c3c66e$656c3b80$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Conta" Cc: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <3FE35B1F.2000308@txc.com> Subject: Re: [mpowr] Mailing List Management Date: Fri, 19 Dec 2003 12:26:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Sorry for misspelling your name. > On the other hand, I think IESG should have helped you resolve the > crisis in the WG by other means. Have you asked for other type of help > from IESG, other than stopping Email access? This sounds like a typical > technical conflict resolution problem, for which there is a science and > professionals, who would be glad to help. > With respect to my experience as a WG chair, the problem had nothing to do with a technical conflict. The participant who was being disruptive was sending email about how the AD and the co-chairs were mis-managing the WG, i.e. it was exclusively process comments. At one point, private email was sent to someone involved in the WG threatening them with physical violence at an IETF meeting. After this incident, it was difficult to accomplish any good technical work in the WG. In this case, there was no need to involve the IESG. Between the AD, the other co-chair, and myself, we resolved the problem in a different way. We didn't appeal to the IESG because, as I said, the IESG's track record of removing people who are disruptive is not particularly good (though I think they might have acted in this case). Frankly, after this experience, I have some amount of difficulty understanding your position. Such unprofessional, uncivilized behavior is not tolerated in any other professional group or nonprofessional civil society in general; yet, we routinely tolerate it on IETF mailing lists, if not perhaps in the most extreme form I've cited here. I've advanced this proposal (which I agree with Margaret is perhaps more complex than necessary) in order to meet your and Scott's concerns. Personally, I believe WG chairs and ADs should have the right to throw anybody off the list they agree is being disruptive. If anybody thinks they are being treated unfairly, they can always appeal. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 16:25:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28003 for ; Fri, 19 Dec 2003 16:25:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7C-0004B1-5j for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLOs0A016055 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7C-0004As-0t for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:24:54 -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 QAA27875 for ; Fri, 19 Dec 2003 16:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS7A-0003Q9-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6o-0003ME-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:50 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AXS6n-0003Lx-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:29 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AXS6i-0003HX-Hg for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6Z-0003r0-BU; Fri, 19 Dec 2003 16:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS1P-0003al-EU for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 16:18:55 -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 QAA27471 for ; Fri, 19 Dec 2003 16:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS1N-00031w-00 for mpowr@ietf.org; Fri, 19 Dec 2003 16:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS1M-00031o-00 for mpowr@ietf.org; Fri, 19 Dec 2003 16:18:53 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AXS1M-00031l-00 for mpowr@ietf.org; Fri, 19 Dec 2003 16:18:52 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBJLIo015695; Fri, 19 Dec 2003 16:18:50 -0500 Message-ID: <3FE36B39.8030905@txc.com> Date: Fri, 19 Dec 2003 16:18:49 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: MPowr Subject: Re: [mpowr] Mailing List Management References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <3FE35B1F.2000308@txc.com> <022501c3c66e$656c3b80$5b6015ac@dclkempt40> In-Reply-To: <022501c3c66e$656c3b80$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608060109020309060203" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080608060109020309060203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit jak, James Kempf wrote: > Alex, > > Sorry for misspelling your name. > [...] > With respect to my experience as a WG chair, the problem had nothing to do > with a technical conflict. The participant who was being disruptive was > [...] Thanks for sharing this experience. > > Frankly, after this experience, I have some amount of difficulty > understanding your position. Free speech is so fundamental. > [...] > I've advanced this proposal (which I agree with Margaret is perhaps more > complex than necessary) > [...] > jak I strongly believe in your and Margaret's integrity and good intentions. The problem is not that. This rule may outlast many's presence in IETF, including mine, yours, or Margaret's. A rule like yours, applied by good people could be a good rule. The same rule applied by bad people can be a very bad rule. For this rule, I know well. For others, I may not know. Therefore, it is for all of us to strive to create and adopt rules that cannot be bad in bad people's hands. Alex --------------ms080608060109020309060203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxOTIxMTg0OVowIwYJKoZIhvcNAQkEMRYEFKBUYBL42gxWysri VFmpwLiq1aSsMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAHXaQzVOI8UhTvvr5+x0xtQwngOxACEtEFulaKcf+opWqFRuQxoShBnEMucv 30y6dFA/ZJZioCKpKKAnnF4nXyzC6y2uunqPjj8MPD2C0/HnP0NXEDeaFO93NTN7B99z4TbG qvzPfW38PBYVdXCJLwdY3gvN4dY7Dbv1Z5Tu1N9afD557y8aw8ncsNY+EfGshzBWNiQjvek5 jFGuhziOOcxnCdsGzIvP3OQpm5rAiq0mYVAjCm8A7wJ9AepmD9vpgvoVjCPxxHIHPhtCVQ4k fRfggiSUa0N8F4WGjz7eu0n2xXznAS+7YnUyfUmTBFLJQVIa0i6X/9rEPGWiegoTMy0AAAAA AAA= --------------ms080608060109020309060203-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 16:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28019 for ; Fri, 19 Dec 2003 16:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7D-0004BQ-4Q for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLOtBG016074 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7C-0004BB-VO for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:24:55 -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 QAA27879 for ; Fri, 19 Dec 2003 16:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS7B-0003QL-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6n-0003Lv-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6m-0003FF-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6O-0003iE-EA; Fri, 19 Dec 2003 16:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXREN-0002A0-OX for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 15:28:15 -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 PAA24909 for ; Fri, 19 Dec 2003 15:28:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXREM-0000fh-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:28:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXREL-0000fa-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:28:14 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AXREK-0000fX-00 for mpowr@ietf.org; Fri, 19 Dec 2003 15:28:13 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBJKSCk3035866; Fri, 19 Dec 2003 13:28:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBJKSCpP035865; Fri, 19 Dec 2003 13:28:12 -0700 (MST) (envelope-from rousskov) Date: Fri, 19 Dec 2003 13:28:12 -0700 (MST) From: Alex Rousskov To: Margaret.Wasserman@nokia.com cc: mpowr@ietf.org Subject: RE: [mpowr] Mailing List Management In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Fri, 19 Dec 2003 Margaret.Wasserman@nokia.com wrote: > The rest of your proposal would seem to add considerably more > overhead to this process, and I'm not sure what the benefits would > be. Here are a few benefits: - all participants are more aware of the rules - a formal warning to those who do not know the law or misinterpret the law/context is given before the punishment is administered - a clearly documented procedure makes suspension easier - a clearly documented procedure makes suspension easier to appeal when the safeguards were ignored > In general, I would not like our BCPs to contain the level of detail > that you've included in your note (3 private warnings, etc.). > Although I think that this would be a reasonable approach for most > situations, I'd prefer to leave the details to the chair and AD. Reminds me of a typical site usage or privacy policy that says "we can change the rules of the game at any time, and without notice, and you are supposed to know the new rules immediately after the change". Punishment levels should not be hard-coded, but the procedure to avoid the punishment (warnings and such) should be hard-coded so that chair's, AD's, victim's, and WG's expectations match as close as possible. > There are possible situations (obvious and/or offensive spam, > posting non-English mail, threats, serious verbal abuse) where I > think it would be appropriate for a WG chair to revoke someone's > posting privileges for 30 days without three prior warnings. A newbie subscribes to the mailing list, posts something like "I believe there is a serious problem with your latest protocol draft, but I cannot explain it well enough in English, so here is a French description, FWIW". The guy gets his ``privileges'' revoked for 30 days without warnings and never bothers the WG or the IETF again. Accidently, the Chair was the only WG participant who knew French, but did not share the guy's technical opinion. Three warnings may be an overkill, but a clearly marked _last_ warning must always be present if you want to formalize the procedure. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Dec 19 23:58:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11680 for ; Fri, 19 Dec 2003 23:58:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXZBo-0002FF-W2 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 23:58:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBK4w83B008629 for mpowr-archive@odin.ietf.org; Fri, 19 Dec 2003 23:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXZBm-0002F6-RG for mpowr-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 23:58:06 -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 XAA11670 for ; Fri, 19 Dec 2003 23:58:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXZBj-0000DI-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 23:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXZBi-0000DB-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 23:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXZBi-0000D8-00 for mpowr-web-archive@ietf.org; Fri, 19 Dec 2003 23:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXZBi-0002El-63; Fri, 19 Dec 2003 23:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXZB5-0002EH-SI for mpowr@optimus.ietf.org; Fri, 19 Dec 2003 23:57:23 -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 XAA11662 for ; Fri, 19 Dec 2003 23:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXZB3-0000Cq-00 for mpowr@ietf.org; Fri, 19 Dec 2003 23:57:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXZB2-0000Cj-00 for mpowr@ietf.org; Fri, 19 Dec 2003 23:57:20 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AXZB2-0000Aq-00 for mpowr@ietf.org; Fri, 19 Dec 2003 23:57:20 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003122004565001600rm3rue> (Authid: sdawkins@comcast.net); Sat, 20 Dec 2003 04:56:51 +0000 Message-ID: <085501c3c6b5$b17aa150$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> Subject: Re: [mpowr] Mailing List Management Date: Fri, 19 Dec 2003 22:56:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To be brief - I agree that our "open lists" don't always work for us. I agree that it shouldn't take the entire IESG ("who should be working on stuff that matters more") to suspend posting privileges. I agree that a WG chair (in practice, almost always a pair of WG co-chairs, and if so, both co-chairs should agree) should notify the responsible AD that they are suspending a participant's posting privileges. I agree that suspended participants should have the right of appeal to the responsible AD. I agree that the number of warnings can be variable, but there should be a "last" warning, whatever number that turns out to be. I'm not sure if it's been stated in this thread, but I believe this should be a rare occurance, and notice of suspension should happen on the mailing list (so the curious can go read the postings, which may be in French, babelfish.altavista.com them into an appropriate language, and decide whether an appeal is appropriate). Spencer _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Dec 21 12:52:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00328 for ; Sun, 21 Dec 2003 12:52:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY7k5-0006WH-FJ for mpowr-archive@odin.ietf.org; Sun, 21 Dec 2003 12:51:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBLHpn72025055 for mpowr-archive@odin.ietf.org; Sun, 21 Dec 2003 12:51:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY7k5-0006W2-B3 for mpowr-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 12:51:49 -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 MAA00300 for ; Sun, 21 Dec 2003 12:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AY7k3-0004fV-00 for mpowr-web-archive@ietf.org; Sun, 21 Dec 2003 12:51:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AY7jc-0004fB-00 for mpowr-web-archive@ietf.org; Sun, 21 Dec 2003 12:51:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AY7jc-0004ey-00 for mpowr-web-archive@ietf.org; Sun, 21 Dec 2003 12:51:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY7jJ-0006U5-1p; Sun, 21 Dec 2003 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY7iU-0006TN-9Y for mpowr@optimus.ietf.org; Sun, 21 Dec 2003 12:50:10 -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 MAA00252 for ; Sun, 21 Dec 2003 12:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AY7iI-0004cs-00 for mpowr@ietf.org; Sun, 21 Dec 2003 12:49:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AY7hr-0004cF-00 for mpowr@ietf.org; Sun, 21 Dec 2003 12:49:32 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AY7hr-0004aU-00 for mpowr@ietf.org; Sun, 21 Dec 2003 12:49:31 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D822E61AA5; Sun, 21 Dec 2003 18:48:31 +0100 (CET) Date: Sat, 20 Dec 2003 21:45:17 -0800 From: Harald Tveit Alvestrand To: James Kempf , MPowr Subject: Re: [mpowr] Mailing List Management Message-ID: <383969298.1071956717@localhost> In-Reply-To: <011901c3c654$24fdc830$5b6015ac@dclkempt40> References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, in my opinion Alex Conta and Scott Bradner are wrong. There are cases where, for the good of the working group, a person should have his or her posting privilleges revoked - FAST - as on the order of a day or three. This is NOT a free speech issue - it has to do with the ability of the IETF to conduct its work in an open and orderly fashion - BOTH open AND orderly. For these cases, a simple procedure with 100% clarity on who makes the decision is needed - not a "three strikes and then wait another month" procedure, as any procedure involving the whole IESG is likely to be. There are other cases where a person is highly disruptive but you have a hard time figuring out why it's disruptive or improper; there are still other cases where a valid, rational technical argument gradually descends into name-calling and truly improper conduct. There will always be borderline cases, and because there will be borderline cases, we need procedures for consultation, and we need procedures for appeal and review. But there are cases where the WG chair needs to have this power, and needs to be able to apply it quickly. The rabble-rousers of the world are free to rabble-rouse wherever they want. But no IETF participant should be obliged to listen. Harald _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 22 20:59:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21093 for ; Mon, 22 Dec 2003 20:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbp1-0001mr-2d for mpowr-archive@odin.ietf.org; Mon, 22 Dec 2003 20:58:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBN1ws8S006864 for mpowr-archive@odin.ietf.org; Mon, 22 Dec 2003 20:58:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbp0-0001md-Q3 for mpowr-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 20:58:54 -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 UAA21029 for ; Mon, 22 Dec 2003 20:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYboy-0002J2-00 for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:58:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYbo8-0002Eo-00 for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:58:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYbo7-0002Eb-00 for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbo8-0001kx-IQ; Mon, 22 Dec 2003 20:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbnt-0001kK-Tg for mpowr@optimus.ietf.org; Mon, 22 Dec 2003 20:57:45 -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 UAA20980 for ; Mon, 22 Dec 2003 20:57:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYblJ-000234-00 for mpowr@ietf.org; Mon, 22 Dec 2003 20:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYbhg-0001tq-00 for mpowr@ietf.org; Mon, 22 Dec 2003 20:51:21 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AYbhf-0001tm-00 for mpowr@ietf.org; Mon, 22 Dec 2003 20:51:19 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AYbhS-000LL1-00; Mon, 22 Dec 2003 20:51:09 -0500 Date: Mon, 22 Dec 2003 17:01:53 -0500 From: John C Klensin To: Harald Tveit Alvestrand , MPowr Subject: Re: [mpowr] Mailing List Management Message-ID: <11225820.1072112513@localhost> In-Reply-To: <383969298.1071956717@localhost> References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Saturday, December 20, 2003 21:45 -0800 Harald Tveit Alvestrand wrote: > in my opinion Alex Conta and Scott Bradner are wrong. > > There are cases where, for the good of the working group, a > person should have his or her posting privilleges revoked - > FAST - as on the order of a day or three. > > This is NOT a free speech issue - it has to do with the > ability of the IETF to conduct its work in an open and orderly > fashion - BOTH open AND orderly. > > For these cases, a simple procedure with 100% clarity on who > makes the decision is needed - not a "three strikes and then > wait another month" procedure, as any procedure involving the > whole IESG is likely to be. Two additions to Harald's comments... As people have probably deduced from other comments I've made, I'm very concerned about the ability of the IETF to produce high quality standards in, with apologies to Wirth, as much time as that takes but no longer. I don't think we are doing nearly as well at that -- along either the quality or speed/efficiency dimensions-- as we were several years ago. There are certainly some reasons for that which are unavoidable, e.g., our typical standard today really does seem to be more complex than was typical, say, a decade ago. But some of it is that "we" have just gotten tied up in a lot more procedures and rules and requirements. And, sometimes because of those procedures and requirements and sometimes because there is just less sense of collaboration and community, we seem much more subject to DoS attacks... whether through volume or abuse and whether intentionally or not. Those attacks need be to stopped in a length of time that is inverse to their severity. If someone is merely making a few off-topic postings too many, there should reasonably be warnings and a serious attempt to be sure that the person understands what is, and is not, off-topic before anyone starts contemplating revoking privileges. With more severe attacks, it may be entirely appropriate, IMO, to pull someone off a list instantly and negotiate (or appeal, or whatever) later. Do we need firm rules or procedures to cover these cases? I certainly hope not: not only do I not want to see more procedures, but because I am certain that they will not work, especially against someone whose intent really is to disrupt or prevent work getting done. I believe we should look at every potential new rule or procedure and ask ourselves the questions: (i) What is the problem this proposed rule is trying to solve? (ii) Will it actually solve that problem, or does it only address the easy cases that can be dealt with in other ways and/or some problem that occurred once or twice in the past but may not occur again? Put differently, if some protocol lawyer and potential deliberate abuser comes along and reads the rule, will he or she be able to find a loophole through which to cause harm and then claim that it is permitted behavior since the rule doesn't say anything about it? If the answer to that question is "yes", we are better off without highly-specific rules and procedures in almost all cases. (iii) Can we solve the problem equally well by clearly giving someone discretion and authority (ideally with general guidelines that represent clear community consensus) and then holding them responsible if they abuse one or the other or both? If the answers to those questions don't clearly indicate that we need a new rule we are, IMO, almost always better off without it. And I think the IESG ought to be going through the current collection of procedural rules, finding the ones that wouldn't be approved if the above criteria were applied, and getting rid of them. Now, going down this path probably implies that we will have more appeals, and maybe even a few recalls, in our future than we have had in the past. Personally, I would prefer to see that rather than having us spend large amounts of time getting rules just right which then, because of the loophole problem or other characteristics, end up getting appealed anyway. If the Nomcom does not understand that ADs are going to need to exercise a good deal of discretion so that it selects only people for those positions who can be trusted to do so wisely, then we better given them the message because nothing is going to work otherwise, no matter how many rules we make. If ADs don't understand that WG Chairs intrinsically have a lot of discretion and that they need to select only those people as WG Chairs who can be trusted to exercise it wisely, then we need a different set of ADs -- and, again, the Nomcom needs to understand that the ability to make those selection decisions wisely is an important requirement for ADs. So, should a WG Chair have the authority to put someone off a mailing list for at least a while? Yes, I think so (and really see no alternative that doesn't tie us in knots). Should there be some guidelines so that WG Chairs can guess what is appropriate, yes, if we can get someone to do the work. Should someone ejected from a list have the right to get (via appeal or otherwise), a quick review and response from the AD? Yes, and I hope that doesn't require a rule (see below). Should the WG Chair consult the relevant AD before pushing someone off a list? Yes, that would be sensible and reasonable. Should we _require_ that the WG Chair do that? No, I don't think so, partially because, if something really needs immediate action and the AD isn't available, the action shouldn't need to wait... But a WG Chair who pushes someone off a mailing list --or takes any of several other actions I think a WG Chair should be able to take on his or her own-- ought to expect to get fired if the AD later concludes that the judgments involved were excessively bad. So, the needed rules here are: (1) A WG Chair can eject someone from a meeting or mailing list or take any other reasonable action, if it is reasonably and sensibly required to prevent or eliminate disruptive activities so that the WG can get work done. In exercising that authority, the WG Chair is expected to consult as necessary and reflect current community culture and judgment as to what actions are appropriate under what types of circumstances. (2) Someone who has been ejected from a mailing list or otherwise subjected to WG Chair discipline has the right to appeal and has the right to expect a timely review and response to the first stage appeal to the relevant AD. ADs who do not respond to such appeals on a timely basis are a menace to the smooth and efficient workings of the IETF and should be swiftly recalled. What is interesting about those rules, of course, is that they don't require any changes to existing written formal rules and procedures, only the application of common sense to those rules... and changes to some of our habits and assumptions about how we do business. Two final coments, lest I be accused about writing too-short notes :-( (1) "Free speech" makes a nice chant. There are any number of places on the Internet in which it can be exercised. But, chants aside, the interpretation of "free speech" necessary to have a society work is that one person's free speech not create dangers for, or infringe on the rights of, others. In the IETF context, one should be "free" to "speak" on a given mailing list, or in a WG meeting, if ones postings are reasonably on-topic, constructive, polite, and civilized. If not, we need to remember that the costs of excessive hostile postings (for any definition of "hostile") include driving people off lists and participation in discussions whose input really would be valuable. We must not get to the point at which it becomes acceptable to have the requirements for participating in an IETF WG be not only expertise and a concern about the issues but also the willingness to suffer high-volume abuse. If we drive away the people who do have the expertise and concern but won't take the abuse, any claims we make to _community_ consensus around the results of the relevant WGs work become highly questionable. (2) This issue has nothing to do with debates about the political theory of the rights/ authority of a group versus those of it chair/ moderator/ leadership. Down through the centuries, people and organizations have always discovered that open, everyone-talks-at-once, assemblies are a lousy way of getting anything done and, as a result, figured out some "leadership" selection mechanism. And, regardless of how those people are selected (or for how long, or by whom), they always end up being give the authority to restrain or eject or isolate someone who is being sufficiently disruptive... or the organization doesn't survive and function. So, while I think ongoing discussions about how Chairs are selected, and to whom they have the most responsibility, are worthwhile, I think we need to accept that, in order to get work done, Chairs are going to need some authority to steer or moderate discussions, interpret and enforce agendas, and limit potential damage or disruptions... or we are basically finished around here except for the shouting (or whimpering). john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 11:35:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26691 for ; Tue, 23 Dec 2003 11:35:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpV1-00068h-J6 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 11:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNGZBPB023598 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 11:35:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpV1-00068W-CM for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 11:35:11 -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 LAA26630 for ; Tue, 23 Dec 2003 11:35:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYpV0-0004Zh-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:35:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYpRx-0004S9-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:32:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYpRx-0004S6-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpRx-000638-8D; Tue, 23 Dec 2003 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpQz-0005zz-Im for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 11:31:01 -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 LAA26312 for ; Tue, 23 Dec 2003 11:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYpQt-0004J8-01 for mpowr@ietf.org; Tue, 23 Dec 2003 11:30:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYpPQ-0004HB-00 for mpowr@ietf.org; Tue, 23 Dec 2003 11:29:25 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AYpPQ-0004H8-00 for mpowr@ietf.org; Tue, 23 Dec 2003 11:29:24 -0500 Received: from txc.com ([172.18.253.131]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBNGTK013268; Tue, 23 Dec 2003 11:29:20 -0500 Message-ID: <3FE86D59.8060201@txc.com> Date: Tue, 23 Dec 2003 11:29:13 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: James Kempf , MPowr Subject: Re: [mpowr] Mailing List Management References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> In-Reply-To: <383969298.1071956717@localhost> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010304050802080006070709" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010304050802080006070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harald, Harald Tveit Alvestrand wrote: > James, > > in my opinion Alex Conta and Scott Bradner are wrong. I will describe this as a difference in opinion rather than using terms of right and wrong. I think the current rule regarding managing the IETF mailing is wise, and a needed checks and balances mechanism. Here is why: WG chairs are NOT process and people managers ONLY. WG chairs can be a directly interested party in a technical debate, and therefore, they may directly benefit from the power of removing one or more people from the WG mailing list. > > There are cases where, for the good of the working group, a person > should have his or her posting privilleges revoked - FAST - as on the > order of a day or three. > "Being disruptive to the WG" cannot be measured in absolute terms. If the WG chair is to decide that, and act on it, it may vary from one to another. > This is NOT a free speech issue - it has to do with the ability of the > IETF to conduct its work in an open and orderly fashion - BOTH open AND > orderly. > What does "orderly" mean? IETF should be proud of having multi-voice, aggressive, and perhaps sometimes long debates. That's what makes it very different from a "sanitized", one-voice environment. Dictatorial environments are known to be more orderly than democratic ones. > For these cases, a simple procedure with 100% clarity on who makes the > decision is needed - not a "three strikes and then wait another month" > procedure, as any procedure involving the whole IESG is likely to be. > No problem with clarity of "procedure, and responsibility on decision". > There are other cases where a person is highly disruptive but you have a > hard time figuring out why it's disruptive or improper; there are still > other cases where a valid, rational technical argument gradually > descends into name-calling and truly improper conduct. "Improper conduct" is also sort of relative up to a certain point. What is the status of the "IETF code of conduct"? > [...] > But there are cases where the WG chair needs to have this power, and > needs to be able to apply it quickly. > If WG chairs were process and people managers ONLY, I would not have a problem. Replacing a checks and balances mechanism, with a rule of "power to apply it quickly" makes it like a "state of emergency". > The rabble-rousers of the world are free to rabble-rouse wherever they > want. But no IETF participant should be obliged to listen. > For instance, nobody forces you to read my message. If my message is disruptive to you, you could have: - ignore it, and further - configure a filter to send my messages on this thread, on this list, in this WG, etc.... directly to the TRASH folder. Alex > Harald > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > > --------------ms010304050802080006070709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMjMxNjI5MTNaMCMGCSqGSIb3DQEJBDEWBBR6ABqFBc2ZwKrR81Cl r4mFA0PYwzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQBZ3JrjKKEmjViagTN5gOIHMGsIdFIzU/uaTdzzBsyoEC9TVFAid7dYNibCEXsJ q+xAgjuASsapHEjN2QQ6Fm00VeS2Cw+4hnCtZzy6Ku8F7ArbpvxmfZrumfa0xcXpdp6dTtaC X4HlAFMpLuTz1SU4g6QukUaDpaTy2FNU2bXAfnaYKsr3VmY2nay6IdaxYAXf0DJX6Fakuv4A zBQ2Zdodwi7gk3e7jFjCGb0IuP1tlPfZJYJNMx55tKSTyUl6Bl0lUY3gmThNmRtV2ZpSwe6n 8fRSpNmE7ltc+YmAdnju7tufyqLidIXiAmza50LVnnbL7wcei9JY55AzwLcTbru4AAAAAAAA --------------ms010304050802080006070709-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 11:59:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27460 for ; Tue, 23 Dec 2003 11:59:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpsG-00070p-Up for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 11:59:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNGxCVu026949 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 11:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpsG-00070a-QM for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 11:59:12 -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 LAA27428 for ; Tue, 23 Dec 2003 11:59:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYpsF-0005Ox-01 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYppB-0005Hx-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYppB-0005Hu-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 11:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYppC-0006uA-1G; Tue, 23 Dec 2003 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYpoD-0006s2-Ni for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 11:55:01 -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 LAA27269 for ; Tue, 23 Dec 2003 11:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYpoC-0005Cp-00 for mpowr@ietf.org; Tue, 23 Dec 2003 11:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYpl1-00058i-00 for mpowr@ietf.org; Tue, 23 Dec 2003 11:51:44 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AYpl1-00058f-00 for mpowr@ietf.org; Tue, 23 Dec 2003 11:51:43 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBNGpgk3050394; Tue, 23 Dec 2003 09:51:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBNGpgv9050393; Tue, 23 Dec 2003 09:51:42 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 09:51:42 -0700 (MST) From: Alex Rousskov To: Alex Conta cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <3FE86D59.8060201@txc.com> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Tue, 23 Dec 2003, Alex Conta wrote: > For instance, nobody forces you to read my message. > If my message is disruptive to you, you could have: > - ignore it, and further > - configure a filter to send my messages on this thread, on this > list, in this WG, etc.... directly to the TRASH folder. I had the same thought when reading this thread, but realized that installing a filter or otherwise ignoring a message is not a complete solution because it violates WG Chair responsibility to gauge consensus. If one could ignore or filter only "consensus-unrelated" messages, then we would have a perfect solution. Unfortunately, ignoring/filtering based on sender or subject line does not guarantee that all consensus-related messages will be read. However, it looks like filtering is a solution for everybody else (but the Chair). Participants do not have to gauge consensus so they can ignore whatever they want (and they often do!). Let's assume that everybody but the Chair are ignoring what they consider disruptive postings. In most cases, this is likely to solve the reported problem of disruptive postings blocking technical work. The poor Chair will have to listen to the lonely/loony voice(s) of the participant(s) being ignored and gauge consensus. In fact, the Chair becomes a de facto moderator in this context! This approach does not violate free speech. As you know, none of the countries guaranteeing free speech was able to guarantee that the speech will be heard or have any effect. With the Chair's implied obligation to listen, we are actually doing slightly better than most countries advertising their free speech laws! Can somebody with a real-life disruptive experience comment on this solution? Would it help in their specific cases? Alex. P.S. My understanding is that the Chair is not obligated to respond, only listen (to gauge consensus). _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 12:23:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27995 for ; Tue, 23 Dec 2003 12:23:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqFO-0008IZ-1C for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:23:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNHN5Gd031893 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqFN-0008IK-Ki for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 12:23:05 -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 MAA27979 for ; Tue, 23 Dec 2003 12:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqFM-0005zo-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:23:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqBQ-0005vs-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:19:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYqBQ-0005vg-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqBQ-0008Bt-R0; Tue, 23 Dec 2003 12:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqBK-0008BM-EA for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 12:18:54 -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 MAA27859 for ; Tue, 23 Dec 2003 12:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqBI-0005u8-01 for mpowr@ietf.org; Tue, 23 Dec 2003 12:18:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqAM-0005ts-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:17:56 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AYqAM-0005to-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:17:54 -0500 Received: from txc.com ([172.18.253.131]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBNHHo014202; Tue, 23 Dec 2003 12:17:50 -0500 Message-ID: <3FE878B7.7080803@txc.com> Date: Tue, 23 Dec 2003 12:17:43 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: Harald Tveit Alvestrand , MPowr Subject: Re: [mpowr] Mailing List Management References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <11225820.1072112513@localhost> In-Reply-To: <11225820.1072112513@localhost> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010507050206010808040603" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010507050206010808040603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John C Klensin wrote: > --On Saturday, December 20, 2003 21:45 -0800 Harald Tveit > Alvestrand wrote: > > >>in my opinion Alex Conta and Scott Bradner are wrong. >> [...] > > Two additions to Harald's comments... > > [...] Should > someone ejected from a list have the right to get (via appeal or > otherwise), a quick review and response from the AD? Yes, and I > hope that doesn't require a rule (see below). There is an inherent contradiction between a well thought appeal decision, and quick. Today ADs/IESG do not act quickly on WG chairs requests of "remove" - "quick" will be the incentive to simply approve the decision of the chairs. >[...] No, I don't think so, partially > because, if something really needs immediate action > [...] I fail to understand or see the cases in which there is need for "immediate action". I would appreciate if one would describe it. > But a WG > Chair who pushes someone off a mailing list --or takes any of > several other actions I think a WG Chair should be able to take > on his or her own-- ought to expect to get fired if the AD later > concludes that the judgments involved were excessively bad. > Can you remind of any fired WG chair? I do not remember any, and I certainly do not expect a chair not being able to justify an abusive action within the boundaries of its powers. > [...]Two final coments, lest I be accused about writing too-short > notes :-( > I worked hard to make it shorter :-)... > [...] Down through the > centuries, people and organizations have always discovered that > open, everyone-talks-at-once, assemblies are a lousy way of > getting anything done and, as a result, figured out some > "leadership" selection mechanism. > [...] > john > > complemented by some checks and balances mechanisms, which the current mailing list remove rule I think is. Alex > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > > --------------ms010507050206010808040603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIyMzE3MTc0M1owIwYJKoZIhvcNAQkEMRYEFBdxww64NLmynr6w BhJmma+M4wCIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAItVLT3esNitjkERBdLLPBYjL0oZUTeunlELbA0D01EtMK7YaeWYiL8Izq2r X02eZYSjMA2aFTt+IkuTAPhVcgOvnnseHIKG7a9HSDzvMrGWpaZqhlrvnZS+ENXFk8V40r6F fi/IHlkjrlPC5S8oBo6wRiv20eMMelM5otmcQIvWU5VnW7z7AvgdnjyhVZ54VG99jutsUWC6 vXEKT3KdYiW5tugumceGBTY1+uQo7oN3fZUIKX9ZdCjYkCxNyxsmE3B08OnSi3pkFlqrpK0M 4A0c4IYXqr/j4I5j4dvweHco8Y2a+WJf5X/6PgXNIMVajPB3YGzt5cZZ4bbg6HzAiNIAAAAA AAA= --------------ms010507050206010808040603-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 12:43:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28491 for ; Tue, 23 Dec 2003 12:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqYe-0000Q0-7u for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:43:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNHh0cC001605 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqYe-0000Po-09 for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 12:43:00 -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 MAA28478 for ; Tue, 23 Dec 2003 12:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqYc-0006cN-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:42:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqVn-0006Zd-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:40:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYqVn-0006Za-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqVn-0000Nt-Og; Tue, 23 Dec 2003 12:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqV7-0000Mk-2i for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 12:39:21 -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 MAA28346 for ; Tue, 23 Dec 2003 12:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqV5-0006Vw-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:39:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqRN-0006Nf-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:35:30 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AYqRN-0006NS-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:35:29 -0500 Message-ID: <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Rousskov" , "Alex Conta" Cc: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 09:35:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit AlexR, > > For instance, nobody forces you to read my message. > > If my message is disruptive to you, you could have: > > - ignore it, and further > > - configure a filter to send my messages on this thread, on this > > list, in this WG, etc.... directly to the TRASH folder. > > I had the same thought when reading this thread, but realized that > installing a filter or otherwise ignoring a message is not a complete > solution because it violates WG Chair responsibility to gauge > consensus. If one could ignore or filter only "consensus-unrelated" > messages, then we would have a perfect solution. Unfortunately, > ignoring/filtering based on sender or subject line does not guarantee > that all consensus-related messages will be read. > > However, it looks like filtering is a solution for everybody else (but > the Chair). Participants do not have to gauge consensus so they can > ignore whatever they want (and they often do!). > > > Let's assume that everybody but the Chair are ignoring what they > consider disruptive postings. In most cases, this is likely to solve > the reported problem of disruptive postings blocking technical work. > The poor Chair will have to listen to the lonely/loony voice(s) of the > participant(s) being ignored and gauge consensus. In fact, the Chair > becomes a de facto moderator in this context! > > This approach does not violate free speech. As you know, none of the > countries guaranteeing free speech was able to guarantee that the > speech will be heard or have any effect. With the Chair's implied > obligation to listen, we are actually doing slightly better than most > countries advertising their free speech laws! > > Can somebody with a real-life disruptive experience comment on this > solution? Would it help in their specific cases? > I've had experience with disruptive participants on mailing lists, and the answer is, no it would not help. The problem is that when a disruptor appears, the good technical people tend to leave. It is a little like spam, except there is an easy way to stop it - unsubscribe from the mailing list. After a major incident of mailing list disruption, a WG tends to get derailed and to lose effectiveness, and it can become difficult for the chair to get the WG back on track. After more than one incident, the good technical people tend to write the WG off as "hopeless" and leave for other more productive venues. The solution is to get the disruptor off the list as soon as possible, before people begin to give up on the WG. Unfortunately, this does require a judgement call on the part of the chair and the AD, and its possible that they might judge wrong. That's why it is necessary to have an appeals process for people who feel they've been treated unfairly. From the experience I've had and talking with other WG chairs who have had similar experiences, I feel that the risk of losing a WG to mailing list disruption is much higher than having an autocratic chair that shuts someone out just because they have a different technical opinion. Actually, I've never seen an instance of the latter, and I know of at least two cases of the former. So I believe that allowing the WG chair and AD to remove mailing list participants with the particpant allowed to appeal to the IESG if they feel treated unfairly is the right way to go. I believe that both WG chairs should agree if there are co-chairs for the WG, and the AD should be consulted. However, I'm still undecided about whether the WG chairs should be allowed to remove someone if the AD doesn't respond quickly enough, as John Klensin has proposed. On the one hand, I see the need for speed, having experienced the problems a lag can cause when an AD is busy elsewhere. On the other, I believe the risk is much higher that a WG chair may make a wrong judgement call if AD approval is not required. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 12:47:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28595 for ; Tue, 23 Dec 2003 12:47: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 1AYqca-0000VZ-IN for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNHl4Bp001947 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqca-0000VK-9W for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 12:47:04 -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 MAA28581 for ; Tue, 23 Dec 2003 12:46:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqcX-0006iC-01 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:47:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqYe-0006e8-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:43:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYqYe-0006dy-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqYf-0000QO-5y; Tue, 23 Dec 2003 12:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqYZ-0000PO-BV for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 12:42:55 -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 MAA28430 for ; Tue, 23 Dec 2003 12:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqYX-0006cN-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqYG-0006bp-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:42:36 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AYqYF-0006bm-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:42:35 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBNHgSk3052213; Tue, 23 Dec 2003 10:42:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBNHgSm7052212; Tue, 23 Dec 2003 10:42:28 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 10:42:28 -0700 (MST) From: Alex Rousskov To: James Kempf cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Tue, 23 Dec 2003, James Kempf wrote: > I've had experience with disruptive participants on mailing lists, and the > answer is, no it would not help. > > The problem is that when a disruptor appears, the good technical people tend > to leave. Could the good technical people be quickly advised by more experienced IETFers (e.g., the Chair) to setup a simple filter? Sure, some e-mails will still get through, but if the good technical people care enough about the WG work, it seems like a small price to pay to stay involved in that work. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 12:56:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28936 for ; Tue, 23 Dec 2003 12:56:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYql5-0000mu-5Z for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNHtp7s003022 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 12:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYql5-0000mf-1d for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 12:55:51 -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 MAA28890 for ; Tue, 23 Dec 2003 12:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYql3-00071d-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqkI-0006xG-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:55:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYqkI-0006xB-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 12:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqkJ-0000jo-1w; Tue, 23 Dec 2003 12:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqkB-0000iq-PC for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 12:54:55 -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 MAA28769 for ; Tue, 23 Dec 2003 12:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqkA-0006ur-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqie-0006uI-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:53:20 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AYqid-0006uD-00 for mpowr@ietf.org; Tue, 23 Dec 2003 12:53:19 -0500 Message-ID: <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Rousskov" Cc: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 09:53:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, > > I've had experience with disruptive participants on mailing lists, and the > > answer is, no it would not help. > > > > The problem is that when a disruptor appears, the good technical people tend > > to leave. > > Could the good technical people be quickly advised by more experienced > IETFers (e.g., the Chair) to setup a simple filter? Sure, some e-mails > will still get through, but if the good technical people care enough > about the WG work, it seems like a small price to pay to stay involved > in that work. > So I guess I don't see any difference between the chair sending out email saying "filter this guy's email" and the chair removing the person from the list, except from a theoretical standpoint. The net effect is the same: nobody reads the disruptor's email. Also, I'm not sure I agree that everyone should be forced into the inconvenience of having to modify their spam filters just so that a single person can continue to post. The other problem with this is that I would presume that the chairs and the disruptor, with participation of the AD, would undergo some kind of private discussion about the disruptor's behavior with the intent that the disruptor could be readmitted to the list when they've cleaned up their act, so to speak. The removal is not meant to permanently disable posting rights, after all. If the problem is handled by having everyone put the disruptor's name in the spam filter, then the chair has to send out an email saying "all right, X has agreed to be a good boy/girl, you can take him out of your spam filter now". Perhaps this kind of public humiliation would serve as a deterrent, but I think it more likely that quiet negotiation and reintroduction of the person into the WG community in a less intrusive way would be preferable. jak _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 13:18:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29476 for ; Tue, 23 Dec 2003 13:18: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 1AYr70-0001ea-5W for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 13:18:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNIIUiC006350 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 13:18:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYr70-0001eL-0G for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 13:18:30 -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 NAA29439 for ; Tue, 23 Dec 2003 13:18:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYr6y-0007ec-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYr38-0007Xa-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:14:30 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYqzl-0007SE-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqzm-0001Pk-Rv; Tue, 23 Dec 2003 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYqyx-0001O9-Ci for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 13:10:11 -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 NAA29178 for ; Tue, 23 Dec 2003 13:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYqyv-0007MO-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYqv5-0007Im-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:06:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AYqsE-0007H2-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:03:14 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBNI2ZC6014243; Tue, 23 Dec 2003 10:02:35 -0800 (PST) Received: from cisco.com ([10.25.65.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APJ60601; Tue, 23 Dec 2003 10:02:34 -0800 (PST) Date: Tue, 23 Dec 2003 13:02:31 -0500 Subject: Re: [mpowr] Mailing List Management Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: "MPowr" To: "James Kempf" From: Melinda Shore In-Reply-To: <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> Message-Id: <2D588725-3572-11D8-B7AE-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, December 23, 2003, at 12:53 PM, James Kempf wrote: > So I guess I don't see any difference between the chair sending out > email > saying "filter this guy's email" and the chair removing the person > from the > list, except from a theoretical standpoint. The net effect is the same: > nobody reads the disruptor's email. Except for the people who don't filter, which we know from experience to be other people who like a brawl. I'd say it's actually a net loss in terms of the utility of the mailing list. Melinda _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 13:47:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00451 for ; Tue, 23 Dec 2003 13:47:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrYH-0002kK-Qf for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 13:46:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNIkfQp010550 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 13:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrYH-0002k5-LV for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 13:46:41 -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 NAA00439 for ; Tue, 23 Dec 2003 13:46:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYrYF-000160-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:46:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYrUX-0000ye-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:42:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYrRr-0000qC-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 13:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrRs-0002Ze-5M; Tue, 23 Dec 2003 13:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrQr-0002Y9-6F for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 13:39:01 -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 NAA00204 for ; Tue, 23 Dec 2003 13:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYrQp-0000nT-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:38:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYrNA-0000bY-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:35:13 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AYrJi-0000QG-00 for mpowr@ietf.org; Tue, 23 Dec 2003 13:31:38 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBNIVZk3054059; Tue, 23 Dec 2003 11:31:35 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBNIVZVp054058; Tue, 23 Dec 2003 11:31:35 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 11:31:35 -0700 (MST) From: Alex Rousskov To: James Kempf cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Tue, 23 Dec 2003, James Kempf wrote: > So I guess I don't see any difference between the chair sending out > email saying "filter this guy's email" and the chair removing the > person from the list, except from a theoretical standpoint. The e-mail will advise about available options (such as "filter this guy's email"). It does not have to recommend any specific action. > The net effect is the same: nobody reads the disruptor's email. The effects are radically different: "nobody reads" versus "people who consider guy's e-mail disruptive do not read". > Also, I'm not sure I agree that everyone should be forced into the > inconvenience of having to modify their spam filters just so that a > single person can continue to post. The inconvenience seem to be very minor given today's mail management software. When/if IETF starts managing its own lists, this can be further automated/simplified on IETF side. > If the problem is handled by having everyone put the disruptor's > name in the spam filter, then the chair has to send out an email > saying "all right, X has agreed to be a good boy/girl, you can take > him out of your spam filter now". Yes. More precisely, the chair will forward (quote) X's e-mail explaining X's intentions to the list. The decision to alter filters remains with each participant, as always. > Perhaps this kind of public humiliation would serve as a deterrent, > but I think it more likely that quiet negotiation and reintroduction > of the person into the WG community in a less intrusive way would be > preferable. I assume that quiet negotiation happens and fails before any action is taken: Chair: Would you please pause while we talk in private? X: No (and continues to post 5 messages/minute) Chair: Posts "your options" e-mail on the list Chair: Would you please pause while we talk in private? X: Sure (stops posting for a day) Chair: Let's negotiate the settlement in private Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 14:17:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01801 for ; Tue, 23 Dec 2003 14:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYs1J-0003su-Qp for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:16:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNJGfML014926 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYs1J-0003sf-M4 for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 14:16:41 -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 OAA01773 for ; Tue, 23 Dec 2003 14:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYs1H-00037A-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:16:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYrzh-0002nd-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:15:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYrvp-0002bk-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:11:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrvq-0003f0-SY; Tue, 23 Dec 2003 14:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYrvU-0003dB-5F for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 14:10:40 -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 OAA01515 for ; Tue, 23 Dec 2003 14:10:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYrvR-0002Xs-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:10:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYrs1-0002Qa-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:07:05 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AYrqc-0002Fo-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:05:38 -0500 Message-ID: <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Rousskov" Cc: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 11:06:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit AlexR, I guess I see this as requiring a lot of mechanism and difficulty just to preserve the "right" of someone to post, and post disruptive email at that. To my mind, there is a limit to which other people should be inconvenienced by someone who is attempting to prevent useful work from getting done. Also, there's Melinda's point. My feeling is that as long as there is recourse for people who feel they are unfairly treated, people's rights to speak freely are preserved. jak ----- Original Message ----- From: "Alex Rousskov" To: "James Kempf" Cc: "MPowr" Sent: Tuesday, December 23, 2003 10:31 AM Subject: Re: [mpowr] Mailing List Management > On Tue, 23 Dec 2003, James Kempf wrote: > > > So I guess I don't see any difference between the chair sending out > > email saying "filter this guy's email" and the chair removing the > > person from the list, except from a theoretical standpoint. > > The e-mail will advise about available options (such as "filter this > guy's email"). It does not have to recommend any specific action. > > > The net effect is the same: nobody reads the disruptor's email. > > The effects are radically different: "nobody reads" versus "people who > consider guy's e-mail disruptive do not read". > > > Also, I'm not sure I agree that everyone should be forced into the > > inconvenience of having to modify their spam filters just so that a > > single person can continue to post. > > The inconvenience seem to be very minor given today's mail management > software. When/if IETF starts managing its own lists, this can be > further automated/simplified on IETF side. > > > If the problem is handled by having everyone put the disruptor's > > name in the spam filter, then the chair has to send out an email > > saying "all right, X has agreed to be a good boy/girl, you can take > > him out of your spam filter now". > > Yes. More precisely, the chair will forward (quote) X's e-mail > explaining X's intentions to the list. The decision to alter filters > remains with each participant, as always. > > > Perhaps this kind of public humiliation would serve as a deterrent, > > but I think it more likely that quiet negotiation and reintroduction > > of the person into the WG community in a less intrusive way would be > > preferable. > > I assume that quiet negotiation happens and fails before any action is > taken: > > Chair: Would you please pause while we talk in private? > X: No (and continues to post 5 messages/minute) > Chair: Posts "your options" e-mail on the list > > Chair: Would you please pause while we talk in private? > X: Sure (stops posting for a day) > Chair: Let's negotiate the settlement in private > > Alex. > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 14:32:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03288 for ; Tue, 23 Dec 2003 14:32:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsGP-0004oa-9E for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:32:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNJWHSB018502 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsGP-0004oL-4i for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 14:32:17 -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 OAA03256 for ; Tue, 23 Dec 2003 14:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsGM-000673-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:32:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYsDp-0005c6-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:29:38 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYsBI-00057L-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:27:00 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYsBI-0000uO-Rv for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsBJ-0004UV-5Y; Tue, 23 Dec 2003 14: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 1AYsAY-0004Ro-HH for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 14:26:14 -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 OAA02649 for ; Tue, 23 Dec 2003 14:26:11 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsAV-0004yV-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYs7M-0004YL-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:22:58 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AYs57-0003vE-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:20:37 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBNJKUU20742 for ; Tue, 23 Dec 2003 21:20:31 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Dec 2003 21:20:30 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 23 Dec 2003 13:20:28 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 14:20:28 -0500 Message-ID: Thread-Topic: [mpowr] Mailing List Management Thread-Index: AcPJda4YbBosm3/YS36Ha9DNaIh7LwAEsliQ To: , Cc: X-OriginalArrivalTime: 23 Dec 2003 19:20:28.0913 (UTC) FILETIME=[D34B3610:01C3C989] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The problem with the "filter e-mail" approach is simple: it=20 doesn't work for new people. How will a new person know who to filter? Will the new person give up on a WG before he discovers that everyone in the group is filtering a certain set of (sometimes) disruptive posters? =20 Will new peoples' good ideas get filtered out if they share=20 them in response to the wrong person? =20 It is important that we have constructive and orderly mailing lists, especially in an environment where we often say that=20 the "real work" is done via e-mail. We wouldn't tolerate=20 clearly disruptive behaviour (threats, personal invective,=20 repeated off-topic or out-of-scope comments, etc.) in a=20 face-to-face meeting, so why would we be willing to tolerate=20 this behaviour on our mailing lists? Freedom of speech does not give people the right to use our resources (mail servers, disk space, etc.) to send their messages. Our mailing lists exist for the purpose of=20 conducting constructive work within the IETF, and we should be able to revoke the posting privileges (and _yes_, I do mean "privileges") of people who disrupt our work. Margaret > -----Original Message----- > From: mpowr-admin@ietf.org [mailto:mpowr-admin@ietf.org]On=20 > Behalf Of ext > Alex Rousskov > Sent: Tuesday, December 23, 2003 11:52 AM > To: Alex Conta > Cc: MPowr > Subject: Re: [mpowr] Mailing List Management >=20 >=20 >=20 > On Tue, 23 Dec 2003, Alex Conta wrote: >=20 > > For instance, nobody forces you to read my message. > > If my message is disruptive to you, you could have: > > - ignore it, and further > > - configure a filter to send my messages on this thread, on this > > list, in this WG, etc.... directly to the TRASH folder. >=20 > I had the same thought when reading this thread, but realized that > installing a filter or otherwise ignoring a message is not a complete > solution because it violates WG Chair responsibility to gauge > consensus. If one could ignore or filter only "consensus-unrelated" > messages, then we would have a perfect solution. Unfortunately, > ignoring/filtering based on sender or subject line does not guarantee > that all consensus-related messages will be read. >=20 > However, it looks like filtering is a solution for everybody else (but > the Chair). Participants do not have to gauge consensus so they can > ignore whatever they want (and they often do!). >=20 >=20 > Let's assume that everybody but the Chair are ignoring what they > consider disruptive postings. In most cases, this is likely to solve > the reported problem of disruptive postings blocking technical work. > The poor Chair will have to listen to the lonely/loony voice(s) of the > participant(s) being ignored and gauge consensus. In fact, the Chair > becomes a de facto moderator in this context! >=20 > This approach does not violate free speech. As you know, none of the > countries guaranteeing free speech was able to guarantee that the > speech will be heard or have any effect. With the Chair's implied > obligation to listen, we are actually doing slightly better than most > countries advertising their free speech laws! >=20 > Can somebody with a real-life disruptive experience comment on this > solution? Would it help in their specific cases? >=20 > Alex. >=20 > P.S. My understanding is that the Chair is not obligated to > respond, only listen (to gauge consensus). >=20 > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr >=20 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 14:40:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04498 for ; Tue, 23 Dec 2003 14:40:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsO0-0005YF-UK for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNJe8rj021323 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 14:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsNz-0005Xj-WA for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 14:40: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 OAA04469 for ; Tue, 23 Dec 2003 14:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsNx-0007Td-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:40:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYsMr-0007Ka-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:38:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYsKx-0006zm-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 14:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsKz-00058h-GC; Tue, 23 Dec 2003 14:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsKE-00057V-1o for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 14:36:14 -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 OAA03802 for ; Tue, 23 Dec 2003 14:36:10 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsKB-0006qZ-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:36:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYsHT-0006Jc-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:33:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AYsEi-0005nC-00 for mpowr@ietf.org; Tue, 23 Dec 2003 14:30:32 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBNJUU025161 for ; Tue, 23 Dec 2003 21:30:31 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Dec 2003 21:30:30 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 23 Dec 2003 11:30:27 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 14:30:26 -0500 Message-ID: Thread-Topic: [mpowr] Mailing List Management Thread-Index: AcPI+D759d6NtHk4Suiq3gACNec3PQAkZr3Q To: , , X-OriginalArrivalTime: 23 Dec 2003 19:30:27.0566 (UTC) FILETIME=[381E68E0:01C3C98B] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi John, > So, the needed rules here are: >=20 > (1) A WG Chair can eject someone from a meeting or > mailing list or take any other reasonable action, if it > is reasonably and sensibly required to prevent or > eliminate disruptive activities so that the WG can get > work done. In exercising that authority, the WG Chair > is expected to consult as necessary and reflect current > community culture and judgment as to what actions are > appropriate under what types of circumstances. > =09 > (2) Someone who has been ejected from a mailing list or > otherwise subjected to WG Chair discipline has the right > to appeal and has the right to expect a timely review > and response to the first stage appeal to the relevant > AD. ADs who do not respond to such appeals on a timely > basis are a menace to the smooth and efficient workings > of the IETF and should be swiftly recalled. >=20 > What is interesting about those rules, of course, is that they > don't require any changes to existing written formal rules and > procedures, only the application of common sense to those > rules... and changes to some of our habits and assumptions about > how we do business. I don't agree that these rules can be enacted without any changes to=20 our written formal rules. RFC 2418 says: As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair should attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair must involve the Area Director in the issue. As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG. In other words, it explicitly requires IESG approval to revoke the posting privileges of a disruptive participant, or to enact=20 any other type of mailing list control. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 15:46:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09034 for ; Tue, 23 Dec 2003 15:46:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtPW-0000Ha-L7 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 15:45:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKjkLW001082 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 15:45:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtPW-0000HN-Gv for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:45:46 -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 PAA09007 for ; Tue, 23 Dec 2003 15:45:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtPV-0002Ju-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 15:45:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtNe-0002G8-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 15:43:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtLr-0002CD-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 15:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtLs-0000Am-Id; Tue, 23 Dec 2003 15:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtLi-0000AX-Qs for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 15:41:50 -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 PAA08848 for ; Tue, 23 Dec 2003 15:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtLh-0002An-00 for mpowr@ietf.org; Tue, 23 Dec 2003 15:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtJw-00027I-00 for mpowr@ietf.org; Tue, 23 Dec 2003 15:40:01 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AYtJE-00022P-00 for mpowr@ietf.org; Tue, 23 Dec 2003 15:39:16 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBNKdFk3060185; Tue, 23 Dec 2003 13:39:15 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBNKdFmA060184; Tue, 23 Dec 2003 13:39:15 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 13:39:15 -0700 (MST) From: Alex Rousskov To: Margaret.Wasserman@nokia.com cc: mpowr@ietf.org Subject: RE: [mpowr] Mailing List Management In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Tue, 23 Dec 2003 Margaret.Wasserman@nokia.com wrote: > The problem with the "filter e-mail" approach is simple: it doesn't > work for new people. If our task were to eliminate 100% of what the Chair considers "disruptive" postings to 100% of participants, then you would be right. Since our task, I think, is to prevent serious disruptions, the problem you are implying is not a big deal (it does not create serious disruptions). > How will a new person know who to filter? Newbies should read the archives for the last month or so (at least). They can be advised by old timers as well. > Will the new person give up on a WG before he discovers that > everyone in the group is filtering a certain set of (sometimes) > disruptive posters? Possibly. Such a person is probably not very interested in a working group to start with (did not read the archives and got discouraged by 10 e-mails from the same participant). > Will new peoples' good ideas get filtered out if they share them in > response to the wrong person? The Chair will not filter out any ideas and can advise accordingly. The above can only happen if somebody filters based on subject alone, (which is their right to do and they get the effect they wanted). > It is important that we have constructive and orderly mailing lists, > especially in an environment where we often say that the "real work" > is done via e-mail. Agreed. > We wouldn't tolerate clearly disruptive behaviour (threats, personal > invective, repeated off-topic or out-of-scope comments, etc.) in a > face-to-face meeting, so why would we be willing to tolerate this > behaviour on our mailing lists? Hm... We wouldn't? I wonder how you would deal with such behavior in a face-to-face meeting. Call the police? Since we cannot define what disruptive is, we should be very careful with making any formal rules with this undefined term. Immediate suspension does not sound like a "very careful" approach to me. Furthermore, the filtering suggestion does not tolerate disruptive behaviour. It makes it invisible to all but the Chair. > Freedom of speech does not give people the right to use our > resources (mail servers, disk space, etc.) to send their messages. > Our mailing lists exist for the purpose of conducting constructive > work within the IETF, and we should be able to revoke the posting > privileges (and _yes_, I do mean "privileges") of people who disrupt > our work. Yes, but the argument seems to be revolving around _how_ such "privileges" can be revoked, not whether they can be revoked. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 16:17:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11997 for ; Tue, 23 Dec 2003 16:17:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYttW-0001ep-2P for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 16:16:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNLGkFk006365 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 16:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYttV-0001ea-Un for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 16:16:45 -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 QAA11814 for ; Tue, 23 Dec 2003 16:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYttU-0005SS-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:16:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtqa-0004nY-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:13:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AYtmf-00044d-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:09:41 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AYtm5-000270-FH for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:09:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtm0-0001Do-Lr; Tue, 23 Dec 2003 16:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtld-0001DZ-7e for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 16:08:37 -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 QAA10211 for ; Tue, 23 Dec 2003 16:08:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtlb-0003ud-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:08:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtis-0003PE-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:05:47 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AYtgF-000321-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:03:04 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBNL2xk3061189; Tue, 23 Dec 2003 14:02:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBNL2x5e061188; Tue, 23 Dec 2003 14:02:59 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 14:02:59 -0700 (MST) From: Alex Rousskov To: James Kempf cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Quick question: While X's e-mails are blocked without a formal last warning, can the WG decide on anything of value? For example, can the WG decide on submitting the current draft as proposed standard? Or accepting an individual draft as a WG work item? If yes, then this would be a convenient way for the Chair's party to win consensus on the issue (by silencing a few people who oppose the decision). Surely, their posting "privileges" will be restored a week later, but it would take _another_ appeal to overrule any WG decisions made during that week. Would it not? Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 16:26:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13030 for ; Tue, 23 Dec 2003 16:26:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYu2o-00027F-FM for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 16:26:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNLQM4l008127 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 16:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYu2o-000270-B2 for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 16:26:22 -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 QAA12877 for ; Tue, 23 Dec 2003 16:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYu2m-0006OH-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYu0h-00066I-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:24:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AYtyl-0005xz-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:22:11 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AYtuj-0002Od-Ce for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 16:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtui-0001lI-Ea; Tue, 23 Dec 2003 16:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtuV-0001kh-0i for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 16:17:47 -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 QAA12162 for ; Tue, 23 Dec 2003 16:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtuT-0005d1-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtsU-0005D6-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:15:43 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AYtp2-0004V5-00 for mpowr@ietf.org; Tue, 23 Dec 2003 16:12:08 -0500 Message-ID: <2ed401c3c999$7a806540$5b6015ac@dclkempt40> From: "James Kempf" To: "Alex Rousskov" Cc: "MPowr" References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 13:12:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit AlexR, Like I said in previous email, there is always the possibility for the WG chairs and AD to make an error in judgement. Presumably, if the AD is maintaining good management oversight, the probability of this happening is low. If it does happen, appeals are always possible. In a situation like you outline, I'd presume the party involved would appeal. jak ----- Original Message ----- From: "Alex Rousskov" To: "James Kempf" Cc: "MPowr" Sent: Tuesday, December 23, 2003 1:02 PM Subject: Re: [mpowr] Mailing List Management > > Quick question: While X's e-mails are blocked without a formal last > warning, can the WG decide on anything of value? For example, can the > WG decide on submitting the current draft as proposed standard? Or > accepting an individual draft as a WG work item? > > If yes, then this would be a convenient way for the Chair's party to > win consensus on the issue (by silencing a few people who oppose the > decision). Surely, their posting "privileges" will be restored a week > later, but it would take _another_ appeal to overrule any WG decisions > made during that week. Would it not? > > Alex. > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 18:24:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18943 for ; Tue, 23 Dec 2003 18:24:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYvsL-0006Ic-9x for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 18:23:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNNNfHe024208 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 18:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYvsL-0006IN-49 for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 18:23:41 -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 SAA18911 for ; Tue, 23 Dec 2003 18:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYvsI-00045U-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 18:23:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYvqQ-00043L-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 18:21:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYvon-00041h-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 18:20:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYvop-0006Fr-Fd; Tue, 23 Dec 2003 18:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYvoW-0006EZ-TF for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 18:19:45 -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 SAA18869 for ; Tue, 23 Dec 2003 18:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYvoT-00040g-00 for mpowr@ietf.org; Tue, 23 Dec 2003 18:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYvmd-0003wn-00 for mpowr@ietf.org; Tue, 23 Dec 2003 18:17:48 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AYvmE-0003uh-00 for mpowr@ietf.org; Tue, 23 Dec 2003 18:17:23 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1AYvmB-000Alb-00; Tue, 23 Dec 2003 18:17:21 -0500 Date: Tue, 23 Dec 2003 18:17:15 -0500 From: John C Klensin To: Margaret.Wasserman@nokia.com, harald@alvestrand.no, mpowr@ietf.org Subject: RE: [mpowr] Mailing List Management Message-ID: <1746729.1072203435@KLENSIN-TP> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret, And I repeat, the IESG has ignored or modified, without notice to the community, far more specific rules. If the AD wants to delegate that authority, while retaining responsibility, the spirit of the rules is certainly met. I agree that, if this is tried more often and seems to work, it would be good to eventually fix 2418. But the IESG can't have it both ways: either it is within your authority (and I do mean "authority" here) to authorize arrangements like the one I outlined, or you need to recind, immediately, a long series of violations and changes to very explicit rules that the IESG has made for its convenience or in order to increase its involvement in various decisions. There is only one significant distinction between what I've proposed and the dozens of "more control, and more work, for the IESG" policy/ procedural decisions made over the last several years: this suggestion involves the IESG less in a decision, while every other case I can recall increases IESG involvement and workload. john --On Tuesday, December 23, 2003 14:30 -0500 Margaret.Wasserman@nokia.com wrote: > > Hi John, > >> So, the needed rules here are: >> >> (1) A WG Chair can eject someone from a meeting or >> mailing list or take any other reasonable action, if it >> is reasonably and sensibly required to prevent or >> eliminate disruptive activities so that the WG can get >> work done. In exercising that authority, the WG Chair >> is expected to consult as necessary and reflect current >> community culture and judgment as to what actions are >> appropriate under what types of circumstances. >> >> (2) Someone who has been ejected from a mailing list or >> otherwise subjected to WG Chair discipline has the right >> to appeal and has the right to expect a timely review >> and response to the first stage appeal to the relevant >> AD. ADs who do not respond to such appeals on a timely >> basis are a menace to the smooth and efficient workings >> of the IETF and should be swiftly recalled. >> >> What is interesting about those rules, of course, is that they >> don't require any changes to existing written formal rules and >> procedures, only the application of common sense to those >> rules... and changes to some of our habits and assumptions >> about how we do business. > > I don't agree that these rules can be enacted without any > changes to our written formal rules. > > RFC 2418 says: > > As with face-to-face sessions occasionally one or more > individuals may engage in behavior on a mailing list which > disrupts the WG's progress. In these cases the Chair > should attempt to discourage the behavior by communication > directly with the offending individual rather than on the > open mailing list. If the behavior persists then the Chair > must involve the Area Director in the issue. As a last > resort and after explicit warnings, the Area Director, with the > approval of the IESG, may request that the mailing list > maintainer block the ability of the offending individual to > post to the mailing list. (If the mailing list software > permits this type of operation.) Even if this is done, the > individual must not be prevented from receiving messages > posted to the list. Other methods of mailing list control > may be considered but must be approved by the AD(s) and the > IESG. > > In other words, it explicitly requires IESG approval to revoke > the posting privileges of a disruptive participant, or to > enact any other type of mailing list control. > > Margaret > > > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 19:20:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21084 for ; Tue, 23 Dec 2003 19:20:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwkZ-000895-Cw for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:19:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO0JhC7031305 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwkZ-00088q-9L for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 19:19:43 -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 TAA21073 for ; Tue, 23 Dec 2003 19:19:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYwkX-0006Nk-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:19:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYwii-0006LH-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:17:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYwh0-0006J0-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwh0-00083z-US; Tue, 23 Dec 2003 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwgj-000834-Ec for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 19:15:45 -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 TAA20995 for ; Tue, 23 Dec 2003 19:15:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYwgh-0006HB-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYwet-0006Ef-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:13:52 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AYwe3-0006BP-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:12:59 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003122400122901600ro9k7e> (Authid: sdawkins@comcast.net); Wed, 24 Dec 2003 00:12:29 +0000 Message-ID: <0a3701c3c9b2$a4401290$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 18:12:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, this has been fun. First, Margaret is right, and we don't need more obstacles for new participants. Second, the post-everything-and-advise-people-to-filter gives you archives that look like puke. See your favorite WG mailing list archives for examples. e2e is about 50% spam, and that's just from not requiring membership to post. Third, saying that WG chairs don't have the right to moderate on the input side, but do have the right to advise filtering on the output side, is insane. Yes, people can ignore the WG chair advice, but does anyone really think that advise-to-filter wouldn't be appealed in exactly the same way as suspension of posting rights? I know that's what *I* would do, if I felt I'd been filtered unfairly. Fourth, what is the poor sap AD supposed to do when the filtered participant appeals a consensus call made while the participant was filtered? Is the AD supposed to look at the filtered mailing list (probably the wrong answer), the unfiltered mailing list (which no one else was looking at), or (best of all) the mailing list through the ADs *own* filters? They do have them, you know. Fifth, is this thread really the model discussion for mpowr? We're talking about list moderation, and for better or worse, we have decades of experience with list/newsgroup moderation. What if we try to work on a HARD problem? Spencer ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, December 23, 2003 1:20 PM Subject: RE: [mpowr] Mailing List Management The problem with the "filter e-mail" approach is simple: it doesn't work for new people. How will a new person know who to filter? Will the new person give up on a WG before he discovers that everyone in the group is filtering a certain set of (sometimes) disruptive posters? Will new peoples' good ideas get filtered out if they share them in response to the wrong person? _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 19:26:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21313 for ; Tue, 23 Dec 2003 19:26:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwqO-0008Ho-Dx for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:25:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO0PiJl031846 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:25:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwqO-0008HZ-8C for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 19:25:44 -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 TAA21293 for ; Tue, 23 Dec 2003 19:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYwqM-0006dQ-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:25:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYwoc-0006ZY-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:23:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYwmm-0006Uz-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwmm-0008ES-PK; Tue, 23 Dec 2003 19:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYwmd-0008Du-2t for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 19:21:51 -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 TAA21141 for ; Tue, 23 Dec 2003 19:21:47 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYwmb-0006T1-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:21:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYwkf-0006PG-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:19:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AYwjg-0006MQ-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:18:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBO0Im029085 for ; Wed, 24 Dec 2003 02:18:48 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Dec 2003 02:18:48 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 23 Dec 2003 16:18:46 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 19:18:45 -0500 Message-ID: Thread-Topic: [mpowr] Mailing List Management Thread-Index: AcPJqu/Zqq+82NqpSPCo6bPbAfXcZgABR4AQ To: , , X-OriginalArrivalTime: 24 Dec 2003 00:18:46.0474 (UTC) FILETIME=[7F124AA0:01C3C9B3] Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi John, > And I repeat, the IESG has ignored or modified, without notice > to the community, far more specific rules.=20 Yes, I understand that the IESG has developed several procedures that have severely bent, if not actually broken, the existing rules. I pointed this out rather frequently before I was=20 appointed to the IESG, and (because I was not subjected to a brain transplant when I joined the IESG) I continue to believe that it is true. I also think that the steady accumulation of=20 process hurdles and IESG control points has been damaging to=20 the IETF. > If the AD wants to > delegate that authority, while retaining responsibility, the > spirit of the rules is certainly met. I agree that, if this is > tried more often and seems to work, it would be good to > eventually fix 2418. If RFC 2418 said that approval of the responsible AD was needed, then I would feel comfortable granting a blanket approval to my=20 WG chairs. However, it says that IESG approval is needed. Perhaps we should discuss this at an IESG meeting and see if the IESG is willing to grant such a blanket approval for a period of experimentation (say 3-to-6 months) after which, if things have worked well, we could update RFC 2418. Would that make sense to you? I don't think that it makes sense for the IESG to grant a=20 permanent blanket approval, because I don't think it is a good thing when our actual procedures differ substantially from our document ones. And, yes, I do know that there are several other ways in which they already do.=20 > But the IESG can't have it both ways: either it is within your > authority (and I do mean "authority" here) to authorize > arrangements like the one I outlined, or you need to recind, > immediately, a long series of violations and changes to very > explicit rules that the IESG has made for its convenience or in > order to increase its involvement in various decisions. There > is only one significant distinction between what I've proposed > and the dozens of "more control, and more work, for the IESG" > policy/ procedural decisions made over the last several years: > this suggestion involves the IESG less in a decision, while > every other case I can recall increases IESG involvement and > workload. Personally, I think that there is a big difference between=20 these two things... I think that it is fine and healthy for the IESG to delegate the=20 authority that the IESG has been granted by the community (with=20 the IESG retaining accountability for the results), but I think=20 it is unhealthy and damaging for the IESG to assume authority that=20 hasn't been granted to the IESG by the community. However, there are a lot of shades of gray here... You and I may not agree about which IESG rules and procedures violate=20 the BCPs, and I am certain that there is no clear agreement about that amongst IESG members or the IETF at large. I also don't think that we should make rapid, sweeping changes=20 to processes that have grown up over many years. I think that we need, as a community, to decide what changes we think are needed and determine a prudent and careful plan to make them over time. I know that you have your personal pet peeves about our current process, and I have mine. For example, I still=20 think that the default action should be approval of WG=20 documents, and that it should take consensus (or at least a majority) of the IESG to block a document. But, I am=20 not sure that view is in the majority in any segment of=20 the IETF, and I certainly don't think that we have consensus=20 that such a change would be beneficial. Margaret =20 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 19:52:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22110 for ; Tue, 23 Dec 2003 19:52:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxFW-0000hg-5i for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:51:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO0pg7N002698 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 19:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxFW-0000hR-0s for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 19:51:42 -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 TAA22095 for ; Tue, 23 Dec 2003 19:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYxFU-0007WX-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYxDb-0007VJ-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:49:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYxBv-0007To-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 19:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxBw-0000bz-NY; Tue, 23 Dec 2003 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxBn-0000bY-3E for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 19:47:51 -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 TAA22014 for ; Tue, 23 Dec 2003 19:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYxBj-0007Sn-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYx9n-0007QC-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:45:47 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AYx8H-0007O7-00 for mpowr@ietf.org; Tue, 23 Dec 2003 19:44:14 -0500 Received: from txc.com ([172.18.253.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBO0iB020543; Tue, 23 Dec 2003 19:44:11 -0500 Message-ID: <3FE8E154.9040601@txc.com> Date: Tue, 23 Dec 2003 19:44:04 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Alex Rousskov , MPowr Subject: Re: [mpowr] Mailing List Management References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> In-Reply-To: <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000603050907090706030305" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 This is a cryptographically signed message in MIME format. --------------ms000603050907090706030305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit James Kempf wrote: >[...] > > The problem is that when a disruptor appears, the good technical people tend > to leave. [...] I have never seen this happen, and it is hard to imagine such dynamics: people's interest is the work in a WG, how can it be the mailing list? Can you point to an Email archive that would show this? > Unfortunately, this does require a > judgement call on the part of the chair and the AD, and its possible that > they might judge wrong. If I think of analogies to daily life, it is nightmarish. > That's why it is necessary to have an appeals > process for people who feel they've been treated unfairly. The appeal will be innefective, because the incentive is to uphold the decisions. > From the > experience I've had and talking with other WG chairs who have had similar > experiences, I feel that the risk of losing a WG to mailing list disruption > is much higher than having an autocratic chair that shuts someone out just > because they have a different technical opinion. Actually, I've never seen > an instance of the latter, and I know of at least two cases of the former. I am confused. How could you see the latter, since the rule is not yet in effect. > So I believe that allowing the WG chair and AD to remove mailing list > participants with the particpant allowed to appeal to the IESG if they feel > treated unfairly is the right way to go. I believe that both WG chairs > should agree if there are co-chairs for the WG, and the AD should be > consulted. If this consultation is to take place, why not to leave the decision to the ADs, as it is today? > However, I'm still undecided about whether the WG chairs should be allowed > to remove someone if the AD doesn't respond quickly enough, as John Klensin > has proposed. On the one hand, I see the need for speed, having experienced > the problems a lag can cause when an AD is busy elsewhere. What lag? Can you be more explicit? I asked this before, and no one explained why it is necessary to have a quick action? > On the other, I > believe the risk is much higher that a WG chair may make a wrong judgement > call if AD approval is not required. > I would feel more comfortable if the WG chair would make a proposal and the decision would be taken by the ADs. We could attach a time limit for the ADs action, to resolve the issue of IESG not acting, although I think the no action, is caused by the uncomfort to take such decisions. Alex C. > jak > --------------ms000603050907090706030305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMjQwMDQ0MDRaMCMGCSqGSIb3DQEJBDEWBBT1QWNVIucqQRMPqaH+ hUH7V35ajjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQBnY0bn/5cEnx79chZJCSXgheaTKCKOWGWOlrEfSbQ1io/hepWX1uf66RB+mVfJ GjLg8LfY7C8eqiglAdl2npOic9IPMNdvjAQLe6nX4e9Octl4WVTm+qHso2QQ/UC+GpXF9PdP 7H5J47aH9AgTv9uzLdAUsP9COtYVueGGrhSydVH4yZsl3pBgRpCDBWZbHxkIce4vEhxTpD7G NCJO1urdIZPXIllm8/1Ujjpi/KqWrLsd0JJwI2G2vUErtIseaeGZQl80I/svUkWiYdA8PmZx CNXWfo2FHlT5LcDUm9+g44fk7Ah2odcRCrmuCAnl8qJ068iLV9bG/3QXMcf2q7IrAAAAAAAA --------------ms000603050907090706030305-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 20:32:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23022 for ; Tue, 23 Dec 2003 20:32:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxsE-0001kD-DK for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 20:31:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO1Vgum006701 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 20:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxsE-0001k0-5p for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 20:31:42 -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 UAA23005 for ; Tue, 23 Dec 2003 20:31:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYxsC-0000hj-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 20:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYxqN-0000f0-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 20:29:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYxoe-0000cF-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 20:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxof-0001c3-9K; Tue, 23 Dec 2003 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYxoc-0001bd-ES for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 20:27:58 -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 UAA22817 for ; Tue, 23 Dec 2003 20:27:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYxoV-0000aR-00 for mpowr@ietf.org; Tue, 23 Dec 2003 20:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYxmc-0000Wm-00 for mpowr@ietf.org; Tue, 23 Dec 2003 20:25:55 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AYxlF-0000TI-00 for mpowr@ietf.org; Tue, 23 Dec 2003 20:24:29 -0500 Received: from txc.com ([172.18.253.133]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBO1OR020955; Tue, 23 Dec 2003 20:24:27 -0500 Message-ID: <3FE8EAC4.1020403@txc.com> Date: Tue, 23 Dec 2003 20:24:20 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret.Wasserman@nokia.com CC: rousskov@measurement-factory.com, mpowr@ietf.org Subject: Re: [mpowr] Mailing List Management References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020503020507070703020300" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 This is a cryptographically signed message in MIME format. --------------ms020503020507070703020300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Margaret.Wasserman@nokia.com wrote: > The problem with the "filter e-mail" approach is simple: it > doesn't work for new people. > [...] > > It is important that we have constructive and orderly mailing > lists, especially in an environment where we often say that > the "real work" is done via e-mail. We wouldn't tolerate > clearly disruptive behaviour (threats personal invective, > repeated off-topic or out-of-scope comments, etc.) in a > face-to-face meeting, so why would we be willing to tolerate > this behaviour on our mailing lists? > I have not experienced a mailing list disturbed by "personal invective" postings. Do you have a pointer to one? Certainly, this type of messages addressed to a certain person fall into "violating a code of conduct". I didn't have in mind this type of messages. However, this type is easy to categorize, and it is much easier to ignore, or filter. On the other hand, "off-topic", and "out of scope" is relative. There is a difference between advertising pills on a TCP list and messages about "flow control", on a thread discussing "congestion control" (off-topic). It would be very useful, if "disruptive" would be very clearly qualified. Alex > Freedom of speech does not give people the right to use our > resources (mail servers, disk space, etc.) to send their > messages. > Our mailing lists exist for the purpose of > conducting constructive work within the IETF, and we > should be able to revoke the posting privileges (and > _yes_, I do mean "privileges") of people who disrupt our > work. > > Margaret > >>-----Original Message----- >>From: mpowr-admin@ietf.org [mailto:mpowr-admin@ietf.org]On >>Behalf Of ext >>Alex Rousskov >>Sent: Tuesday, December 23, 2003 11:52 AM >>To: Alex Conta >>Cc: MPowr >>Subject: Re: [mpowr] Mailing List Management >> >> >> >>On Tue, 23 Dec 2003, Alex Conta wrote: >> >> >>>For instance, nobody forces you to read my message. >>>If my message is disruptive to you, you could have: >>>- ignore it, and further >>>- configure a filter to send my messages on this thread, on this >>> list, in this WG, etc.... directly to the TRASH folder. >> >>I had the same thought when reading this thread, but realized that >>installing a filter or otherwise ignoring a message is not a complete >>solution because it violates WG Chair responsibility to gauge >>consensus. If one could ignore or filter only "consensus-unrelated" >>messages, then we would have a perfect solution. Unfortunately, >>ignoring/filtering based on sender or subject line does not guarantee >>that all consensus-related messages will be read. >> >>However, it looks like filtering is a solution for everybody else (but >>the Chair). Participants do not have to gauge consensus so they can >>ignore whatever they want (and they often do!). >> >> >>Let's assume that everybody but the Chair are ignoring what they >>consider disruptive postings. In most cases, this is likely to solve >>the reported problem of disruptive postings blocking technical work. >>The poor Chair will have to listen to the lonely/loony voice(s) of the >>participant(s) being ignored and gauge consensus. In fact, the Chair >>becomes a de facto moderator in this context! >> >>This approach does not violate free speech. As you know, none of the >>countries guaranteeing free speech was able to guarantee that the >>speech will be heard or have any effect. With the Chair's implied >>obligation to listen, we are actually doing slightly better than most >>countries advertising their free speech laws! >> >>Can somebody with a real-life disruptive experience comment on this >>solution? Would it help in their specific cases? >> >>Alex. >> >>P.S. My understanding is that the Chair is not obligated to >> respond, only listen (to gauge consensus). >> >>_______________________________________________ >>mpowr mailing list >>mpowr@ietf.org >>https://www1.ietf.org/mailman/listinfo/mpowr >> > > > --------------ms020503020507070703020300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMjQwMTI0MjBaMCMGCSqGSIb3DQEJBDEWBBRpLNhEzcmX0m3zeRkb lc9b9Mu4JzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQB3VWwPp7ZeY/6penl7PNKY0hmvD26bRBTxiy+qMXa+pFGYC+9H/Jw2o0iC0Tmw Go/PMiQ3tBFkYQgnem14HRUd6bmtQROffbupUFRB/wwmKO7smgTmjhylOPwIBbnrZw9gIPP8 7crDPgEeSJu3jL5HfuMV5/eE5b5og9cVGWRwdUKE0dRne11fTVCiidr9SfsFsF94yr5LeoW+ gwmALJ9o4HZf8NtbaFy+pDStZ6DuvrfP+7NdyxQeBZs9oOze1QXLUB+1jJeBQEhv1+Pa24k4 MyXpaGntVwmLHzCa+FCOVWdOCG9+3bEbDlfoc9125Kuyq7iZ8Dq3V80gh8zJzB5lAAAAAAAA --------------ms020503020507070703020300-- _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Dec 23 21:20:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24258 for ; Tue, 23 Dec 2003 21:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYycm-00039n-6R for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 21:19:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO2Jmor012129 for mpowr-archive@odin.ietf.org; Tue, 23 Dec 2003 21:19:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYycl-00039Y-WE for mpowr-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 21:19:48 -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 VAA24162 for ; Tue, 23 Dec 2003 21:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYycj-00023r-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 21:19:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYyat-0001yo-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 21:17:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYyZ6-0001vk-00 for mpowr-web-archive@ietf.org; Tue, 23 Dec 2003 21:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYyZ7-00037Q-Kn; Tue, 23 Dec 2003 21:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYyYz-00036L-9y for mpowr@optimus.ietf.org; Tue, 23 Dec 2003 21:15:53 -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 VAA24037 for ; Tue, 23 Dec 2003 21:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYyYw-0001uM-00 for mpowr@ietf.org; Tue, 23 Dec 2003 21:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYyX6-0001s4-00 for mpowr@ietf.org; Tue, 23 Dec 2003 21:13:56 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AYyVt-0001ot-00 for mpowr@ietf.org; Tue, 23 Dec 2003 21:12:42 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc11) with SMTP id <2003122402121101100ii6k8e> (Authid: sdawkins@comcast.net); Wed, 24 Dec 2003 02:12:11 +0000 Message-ID: <0b3801c3c9c3$5d0b1940$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: [mpowr] Mailing List Management Date: Tue, 23 Dec 2003 20:12:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No one asked my opinion, of course, but when I read Margaret's last paragraph, I did wonder why we don't assume that the working group will produce useful specifications in a timely fashion, and then manage by exception for working groups that don't. If it was the IESG's role to make sure that the bottom twenty percent of our documents never see the light of day as RFCs, ADs would have more time to figure out which documents needed to be blocked. Spencer ----- Original Message ----- From: To: ; ; Sent: Tuesday, December 23, 2003 6:18 PM Subject: RE: [mpowr] Mailing List Management [deleted down to] I know that you have your personal pet peeves about our current process, and I have mine. For example, I still think that the default action should be approval of WG documents, and that it should take consensus (or at least a majority) of the IESG to block a document. But, I am not sure that view is in the majority in any segment of the IETF, and I certainly don't think that we have consensus that such a change would be beneficial. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 24 00:22:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28245 for ; Wed, 24 Dec 2003 00:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ1Sx-0008Sb-Ur for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 00:21:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO5LpWT032515 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 00:21:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ1Sx-0008SM-Ls for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 00:21:51 -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 AAA28225 for ; Wed, 24 Dec 2003 00:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ1St-0006oh-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 00:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ1R6-0006hV-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 00:19:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZ1PH-0006XB-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 00:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ1PF-0008ND-2C; Wed, 24 Dec 2003 00:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ1Oz-0008ML-P5 for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 00:17:45 -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 AAA27948 for ; Wed, 24 Dec 2003 00:17:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ1Ox-0006UK-00 for mpowr@ietf.org; Wed, 24 Dec 2003 00:17:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ1N5-0006Mz-00 for mpowr@ietf.org; Wed, 24 Dec 2003 00:15:48 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AZ1LD-0006Hs-00 for mpowr@ietf.org; Wed, 24 Dec 2003 00:13:52 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AZ1LD-000ElL-00; Wed, 24 Dec 2003 00:13:51 -0500 Date: Wed, 24 Dec 2003 00:13:51 -0500 From: John C Klensin To: Margaret.Wasserman@nokia.com, harald@alvestrand.no, mpowr@ietf.org Subject: RE: [mpowr] Mailing List Management Message-ID: <5752541.1072224831@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Tuesday, 23 December, 2003 19:18 -0500 Margaret.Wasserman@nokia.com wrote: >> And I repeat, the IESG has ignored or modified, without notice >> to the community, far more specific rules. > > Yes, I understand that the IESG has developed several > procedures that have severely bent, if not actually broken, > the existing rules. I pointed this out rather frequently > before I was appointed to the IESG, and (because I was not > subjected to a brain transplant when I joined the IESG) I > continue to believe that it is true. I also think that the > steady accumulation of process hurdles and IESG control > points has been damaging to the IETF. Yes, we agree. >> If the AD wants to >> delegate that authority, while retaining responsibility, the >> spirit of the rules is certainly met. I agree that, if this >> is tried more often and seems to work, it would be good to >> eventually fix 2418. > > If RFC 2418 said that approval of the responsible AD was > needed, then I would feel comfortable granting a blanket > approval to my WG chairs. However, it says that IESG > approval is needed. Perhaps we should discuss this at an IESG > meeting and see if the IESG is willing to grant such a blanket > approval for a period of experimentation (say 3-to-6 months) > after which, if things have worked well, we could update RFC > 2418. Would that make sense to you? Yes. More generally, this is an aspect of a point I've been trying to make, although obviously not successfully, and perhaps not clearly enough. There are a number of proposals for change floating around for which we have good theorizing, but no operational experience and no good way to predict the absence (or nature) of unexpected and unintended consequences. So, if we can possibly figure out a way to do so, I'd like to see us try them with a minimum of fuss and without trying to formally change the procedures and get all of the little details right by using a mixture of speculation and nit-picking. Once we find something that works, and preferably have gone through a round or two of tuning as needed, that is the right time to reflect that knowledge and experience, to the extent really needed, in formal procedures. > I don't think that it makes sense for the IESG to grant a > permanent blanket approval, because I don't think it is > a good thing when our actual procedures differ substantially > from our document ones. And, yes, I do know that there > are several other ways in which they already do. And I challenge the IESG to either move ahead with some of these "experiments" or, if it concludes that would be unwise given a careful reading of the written procedures, to eliminate every instance in which it has adopted procedures or practices at variance with the documented procedures. >> But the IESG can't have it both ways: either it is within your >> authority (and I do mean "authority" here) to authorize >> arrangements like the one I outlined, or you need to recind, >> immediately, a long series of violations and changes to very >> explicit rules that the IESG has made for its convenience or >> in order to increase its involvement in various decisions. >> There is only one significant distinction between what I've >> proposed and the dozens of "more control, and more work, for >> the IESG" policy/ procedural decisions made over the last >> several years: this suggestion involves the IESG less in a >> decision, while every other case I can recall increases IESG >> involvement and workload. > > Personally, I think that there is a big difference between > these two things... > > I think that it is fine and healthy for the IESG to delegate > the authority that the IESG has been granted by the community > (with the IESG retaining accountability for the results), but > I think it is unhealthy and damaging for the IESG to assume > authority that hasn't been granted to the IESG by the > community. Ah. So the IESG won't do the things that I --and others-- have suggested and which you consider relatively benign, but feels free to do the things that you consider "unhealthy and damaging"? Ok, I agree with your conclusion. Are you going to tell us who needs recalling? :-( > However, there are a lot of shades of gray here... You and I > may not agree about which IESG rules and procedures violate > the BCPs, and I am certain that there is no clear agreement > about that amongst IESG members or the IETF at large. I'd be happy to supply a short list of candidate items if you and others think that would be helpful. I don't believe that I can generate a comprehensive list, but incremental progress would be very helpful here, IMO. > I also don't think that we should make rapid, sweeping changes > to processes that have grown up over many years. I think that > we need, as a community, to decide what changes we think are > needed and determine a prudent and careful plan to make them > over time. I would suggest, in line with your "unhealthy and damaging" analysis above, that the IESG has made far more radical and sweeping changes in the last several years, on its own initiative and without any attempt at explicit community approval, than anything that has been seriously proposed here (or on the Solutions list, etc.). > I know that you have your personal pet peeves about our > current process, and I have mine. For example, I still > think that the default action should be approval of WG > documents, and that it should take consensus (or at least > a majority) of the IESG to block a document. But, I am > not sure that view is in the majority in any segment of > the IETF, and I certainly don't think that we have consensus > that such a change would be beneficial. I agree that guessing about consensus on that one is a tough problem. Let me try out some easy problems, as an introduction to the list posited above: * 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? * At the time 2026 was written, the RFC Editor timeout for IESG review of an independent submission document was two weeks. If the IESG needed more time, it was required to ask for it from the RFC Editor, typically specifying a reason. And the IESG approval mechanism was a call for objections with an internal timeout. Now, the timeout is four weeks, the IESG apparently routinely simply ignores that timeout, and the approval process requires a formal vote and writeup. Is this progress? * At the time 2026 (and 2418) were written, most IANA allocations of port and protocol numbers were done at IANA's own discretion and initiative, with IANA asking questions when needed (and selecting whom to ask). Now, a large fraction of those require either IESG approval, or approval of experts appointed by the IESG. In both cases the reviews are apparently done on a "when we get around to it" basis, with no timeouts or quality control: if some AD doesn't push for something to get done, it may take a _very_ long time. Now, given the changed circumstances at IANA, some additional (and more formal) review and technical input is certainly justified in many of these circumstances. But I can find nothing in 2026 or 2418 that assigns authority to IESG to decide how these things should be handled, put itself in the loop, etc., without going back to the community for authorization. Do you think the IESG actions and assertions of authority in this case are appropriate? Do you think they are healthy for the community given that some of the tasks, once created and assumed, don't get done in a timely fashion? I understand that you are not the source of these problems, but perhaps the examples above make my point more clear. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 24 04:28:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02186 for ; Wed, 24 Dec 2003 04:28:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ5J9-0002zs-5T for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 04:27:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO9Rxlv011513 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 04:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ5J8-0002zc-JD for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 04:27:58 -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 EAA02083 for ; Wed, 24 Dec 2003 04:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ5J5-0000AD-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 04:27:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ5HI-000042-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 04:26:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZ5FO-0007nR-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 04:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ5FP-0002jj-Bw; Wed, 24 Dec 2003 04:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ4Wb-0000zU-9D for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 03:37:49 -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 DAA01259 for ; Wed, 24 Dec 2003 03:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ4WY-0006k4-00 for mpowr@ietf.org; Wed, 24 Dec 2003 03:37:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ4Uh-0006iV-00 for mpowr@ietf.org; Wed, 24 Dec 2003 03:35:52 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AZ4Ta-0006gT-00 for mpowr@ietf.org; Wed, 24 Dec 2003 03:34:42 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6639061BE0; Wed, 24 Dec 2003 09:34:11 +0100 (CET) Date: Wed, 24 Dec 2003 00:29:53 -0800 From: Harald Tveit Alvestrand To: John C Klensin , Margaret.Wasserman@nokia.com, mpowr@ietf.org Subject: RFC Editor doc approvals (RE: [mpowr] Mailing List Management) Message-ID: <653042715.1072225793@localhost> In-Reply-To: <5752541.1072224831@scan.jck.com> References: <5752541.1072224831@scan.jck.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit changing the subject, since this has gone far away from list management... --On 24. desember 2003 00:13 -0500 John C Klensin wrote: > * At the time 2026 was written, the RFC Editor timeout > for IESG review of an independent submission document > was two weeks. If the IESG needed more time, it was > required to ask for it from the RFC Editor, typically > specifying a reason. And the IESG approval mechanism > was a call for objections with an internal timeout. > Now, the timeout is four weeks, the IESG apparently > routinely simply ignores that timeout, and the approval > process requires a formal vote and writeup. Is this > progress? corrections: 1) as far as I remember, the rfc editor never did anything when the timeout expired. not even when it was 2 weeks. 2) the IESG approval mechanism at the moment is "one (shepherding) AD has to have read the document and put it on the IESG agenda, no objection must be raised when he does". 3) no formal writeup is needed for approval. the appearance of "ballots" for these items in the tracker recently is because it's easier to reuse the mechanism than to be sure we remember who had the objection and why, not because we wish to add more formality or delay to the process. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 24 08:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10099 for ; Wed, 24 Dec 2003 08:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ996-0003Qq-Je for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 08:33:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBODXqBX013188 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 08:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ996-0003Qd-F9 for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 08:33:52 -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 IAA10096 for ; Wed, 24 Dec 2003 08:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ995-0003OU-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 08:33:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ97C-0003MH-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 08:31:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZ95O-0003Kx-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 08:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ95O-0003OY-FA; Wed, 24 Dec 2003 08:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZ95G-0003Np-UQ for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 08:29:55 -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 IAA10068 for ; Wed, 24 Dec 2003 08:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ95F-0003Jy-00 for mpowr@ietf.org; Wed, 24 Dec 2003 08:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ93M-0003Iz-00 for mpowr@ietf.org; Wed, 24 Dec 2003 08:27:57 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AZ92e-0003Hu-00 for mpowr@ietf.org; Wed, 24 Dec 2003 08:27:12 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AZ92c-000L2X-00; Wed, 24 Dec 2003 08:27:10 -0500 Date: Wed, 24 Dec 2003 08:27:10 -0500 From: John C Klensin To: Harald Tveit Alvestrand , Margaret.Wasserman@nokia.com, mpowr@ietf.org Subject: Re: RFC Editor doc approvals (RE: [mpowr] Mailing List Management) Message-ID: <35351182.1072254430@scan.jck.com> In-Reply-To: <653042715.1072225793@localhost> References: <5752541.1072224831@scan.jck.com> <653042715.1072225793@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Wednesday, 24 December, 2003 00:29 -0800 Harald Tveit Alvestrand wrote: > changing the subject, since this has gone far away from list > management... > > --On 24. desember 2003 00:13 -0500 John C Klensin > wrote: > >> * At the time 2026 was written, the RFC Editor timeout >> for IESG review of an independent submission document >> was two weeks. If the IESG needed more time, it was >> required to ask for it from the RFC Editor, typically >> specifying a reason. And the IESG approval mechanism >> was a call for objections with an internal timeout. >> Now, the timeout is four weeks, the IESG apparently >> routinely simply ignores that timeout, and the approval >> process requires a formal vote and writeup. Is this >> progress? > > corrections: > > 1) as far as I remember, the rfc editor never did anything > when the timeout expired. not even when it was 2 weeks. If the RFC Editor is following this list, I'll let them respond. But my recollection is that "never did anything" was the result of a clear understanding that the IESG would be very irritated if they did so and, perhaps, would even attempt to retaliate. > 2) the IESG approval mechanism at the moment is "one > (shepherding) AD has to have read the document and put it on > the IESG agenda, no objection must be raised when he does". > 3) no formal writeup is needed for approval. My apologies for misunderstanding this. I have been told, by different ADs at different times, that the document had not been put on the ballot because he or she hadn't gotten around to doing a writeup for said ballot and/or that the clearance hadn't gone back to the RFC Editor because no one had gotten around to writing up the approval note. Perhaps I misunderstood. At the same time, it would be far more consistent with the letter of 2026 that, if the IESG does not succeed in doing a review within some fixed period of time, the RFC Editor takes that as acceptance and goes ahead and publishes. How would today's IESG feel about the RFC Editor doing that? And you will note that I didn't raise the problem of IESG review going far beyond the "conflict with existing IETF WG activity" and "harm to the Internet" criteria set out in 2026. This time :-( > the appearance of "ballots" for these items in the tracker > recently is because it's easier to reuse the mechanism than to > be sure we remember who had the objection and why, not because > we wish to add more formality or delay to the process. Again, I picked up the "ballot" terminology from a couple of different ADs, not directly from the categories in the tracker. But, again, sorry for any misunderstanding. I suspect this again illustrates the importance of the IESG's being much more clear to the community about the procedures it has adopted and is following. regards, john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 24 14:14:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19066 for ; Wed, 24 Dec 2003 14:14:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZESO-00074H-5M for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 14:14:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOJE8rB027163 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 14:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZESO-000742-0x for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 14:14: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 OAA19058 for ; Wed, 24 Dec 2003 14:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZESL-0005LZ-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 14:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZEQa-0005Jb-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 14:12:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZEPM-0005GQ-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 14:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZEPN-00071E-SU; Wed, 24 Dec 2003 14:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZEOS-00070V-Fb for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 14:10:04 -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 OAA18986 for ; Wed, 24 Dec 2003 14:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZEOQ-0005F2-00 for mpowr@ietf.org; Wed, 24 Dec 2003 14:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZEMZ-0005Cq-00 for mpowr@ietf.org; Wed, 24 Dec 2003 14:08:08 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AZELS-0005Am-00 for mpowr@ietf.org; Wed, 24 Dec 2003 14:06:58 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77A1B61BF6; Wed, 24 Dec 2003 20:06:26 +0100 (CET) Date: Wed, 24 Dec 2003 10:55:27 -0800 From: Harald Tveit Alvestrand To: John C Klensin , mpowr@ietf.org Subject: Re: RFC Editor doc approvals (RE: [mpowr] Mailing List Management) Message-ID: <690576085.1072263327@localhost> In-Reply-To: <35351182.1072254430@scan.jck.com> References: <5752541.1072224831@scan.jck.com> <653042715.1072225793@localhost> <35351182.1072254430@scan.jck.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On 24. desember 2003 08:27 -0500 John C Klensin wrote: > > > --On Wednesday, 24 December, 2003 00:29 -0800 Harald Tveit Alvestrand > wrote: > >> changing the subject, since this has gone far away from list >> management... >> >> --On 24. desember 2003 00:13 -0500 John C Klensin >> wrote: >> >>> * At the time 2026 was written, the RFC Editor timeout >>> for IESG review of an independent submission document >>> was two weeks. If the IESG needed more time, it was >>> required to ask for it from the RFC Editor, typically >>> specifying a reason. And the IESG approval mechanism >>> was a call for objections with an internal timeout. >>> Now, the timeout is four weeks, the IESG apparently >>> routinely simply ignores that timeout, and the approval >>> process requires a formal vote and writeup. Is this >>> progress? >> >> corrections: >> >> 1) as far as I remember, the rfc editor never did anything >> when the timeout expired. not even when it was 2 weeks. > > If the RFC Editor is following this list, I'll let them respond. But my > recollection is that "never did anything" was the result of a clear > understanding that the IESG would be very irritated if they did so and, > perhaps, would even attempt to retaliate. I hope we have a more cooperative environment now..... >> 2) the IESG approval mechanism at the moment is "one >> (shepherding) AD has to have read the document and put it on >> the IESG agenda, no objection must be raised when he does". >> 3) no formal writeup is needed for approval. > > My apologies for misunderstanding this. I have been told, by different > ADs at different times, that the document had not been put on the ballot > because he or she hadn't gotten around to doing a writeup for said ballot > and/or that the clearance hadn't gone back to the RFC Editor because no > one had gotten around to writing up the approval note. Perhaps I > misunderstood. different things .... "writeup not done" is a problem with standards-track documents, not RFC-Editor ones. The other one - "approval note" - can be a problem. Often, the IESG will approve a document but ask for an IESG note to be added. In that case, someone has to type up the note. That sometimes causes delay - search for documents in state "Approved - Announcement to be sent" with substate "Point raised - writeup needed". > At the same time, it would be far more consistent with the letter of 2026 > that, if the IESG does not succeed in doing a review within some fixed > period of time, the RFC Editor takes that as acceptance and goes ahead > and publishes. How would today's IESG feel about the RFC Editor doing > that? > > And you will note that I didn't raise the problem of IESG review going > far beyond the "conflict with existing IETF WG activity" and "harm to the > Internet" criteria set out in 2026. This time :-( > >> the appearance of "ballots" for these items in the tracker >> recently is because it's easier to reuse the mechanism than to >> be sure we remember who had the objection and why, not because >> we wish to add more formality or delay to the process. > > Again, I picked up the "ballot" terminology from a couple of different > ADs, not directly from the categories in the tracker. But, again, sorry > for any misunderstanding. In fact we just added use of "ballots" for Informational documents in general, as an administrative tool, not because we want to raise the bar. So you WILL hear the terminology. > > I suspect this again illustrates the importance of the IESG's being much > more clear to the community about the procedures it has adopted and is > following. It does. And being clear to the community requires writing down the procedures, which most often means making them more rigid and harder to change. Nothing's perfect.... _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Dec 24 17:30:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25949 for ; 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 ; 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 ; 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 cc: Margaret.Wasserman@nokia.com, harald@alvestrand.no, mpowr@ietf.org In-Reply-To: Message from John C Klensin 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 Message-Id: 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 From exim@www1.ietf.org Wed Dec 24 18:02:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26316 for ; Wed, 24 Dec 2003 18:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZI12-0006uS-E8 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 18:02:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBON28cY026557 for mpowr-archive@odin.ietf.org; Wed, 24 Dec 2003 18:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZI12-0006uG-6O for mpowr-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 18:02: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 SAA26306 for ; Wed, 24 Dec 2003 18:02:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZI0z-00041T-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 18:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZHz7-0003zd-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 18:00:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZHxz-0003xj-00 for mpowr-web-archive@ietf.org; Wed, 24 Dec 2003 17:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHy0-0006rW-O8; Wed, 24 Dec 2003 17:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZHx8-0006r3-8z for mpowr@optimus.ietf.org; Wed, 24 Dec 2003 17:58:06 -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 RAA26220 for ; Wed, 24 Dec 2003 17:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZHx5-0003wy-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZHv8-0003vS-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:56:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AZHul-0003ud-00 for mpowr@ietf.org; Wed, 24 Dec 2003 17:55:39 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AZHuj-000BC9-L4; Wed, 24 Dec 2003 22:55:37 +0000 To: John C Klensin cc: Margaret.Wasserman@nokia.com, harald@alvestrand.no, mpowr@ietf.org Subject: Standards Process wrt IANA (was Re: [mpowr] Mailing List Management) In-Reply-To: Message from John C Klensin of "Wed, 24 Dec 2003 00:13:51 EST." <5752541.1072224831@scan.jck.com> Date: Wed, 24 Dec 2003 14:55:37 -0800 From: Allison Mankin Message-Id: 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 * At the time 2026 (and 2418) were written, most IANA allocations of port and protocol numbers were done at IANA's own discretion and initiative, with IANA asking questions when needed (and selecting whom to ask). Now, a large fraction of those require either IESG approval, or approval of experts appointed by the IESG. In both cases the reviews are apparently done on a "when we get around to it" basis, with no timeouts or quality control: if some AD doesn't push for something to get done, it may take a _very_ long time. Now, given the changed circumstances at IANA, some additional (and more formal) review and technical input is certainly justified in many of these circumstances. But I can find nothing in 2026 or 2418 that assigns authority to IESG to decide how these things should be handled, put itself in the loop, etc., without going back to the community for authorization. Do you think the IESG actions and assertions of authority in this case are appropriate? Do you think they are healthy for the community given that some of the tasks, once created and assumed, don't get done in a timely fashion? In this case, there's a question about what degree of process people consider enough. It's true that RFC 2026 doesn't discuss the relationship with the IANA. But routinely, assignment processes and interactions with IANA are written by document editors into BCPs or standards track RFCs, which get IETF Last Call, after WG review, and therefore have community authorization to the same extent that any WG-advanced standard does. IANA also consents to the IANA contents of the documents - that this is not formalized is another part of the big picture functions discussion we are all trying to have, and part of the procedure point you and Harald exchanged earlier today. IANA negative reviews and remedies can be seen in the tracker for specific documents, but the procedures in use today are not clearly documented. The use of Expert Review appointments by IESG (when requested by WG documents) was approved by the community in RFC 2434, BCP 26. So again this process was authorized by the IETF. Are there a bunch of overload problems in the IANA processing system, on all sides (IANA too). Resounding yes. Many arise in the steps having to do with the IANA processing for the approved documents, which is not the issue in your comment, but should resonate for many document editors. ADs play hastener on these, rather than roadblock. The big picture is to take on a structured review of such functions and their overloads, but saying that the IESG seized IANA-related functions without community process doesn't present the history, because the community has supported the BCPs. There are questions related to the symptoms of a number of the functional problems in these points John raised. There's a structured discussion here -- a working group discussion? Perhaps we should get back to the charter discussion, and perhaps the charter to be discussed is shaping up differently than first proposed. My non-vacation Dec 24 is over, happy holiday everyone! Allison _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Thu Dec 25 01:53:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06295 for ; Thu, 25 Dec 2003 01:53:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZPMU-00042r-MD for mpowr-archive@odin.ietf.org; Thu, 25 Dec 2003 01:52:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBP6qkPM015546 for mpowr-archive@odin.ietf.org; Thu, 25 Dec 2003 01:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZPMU-00042f-Fm for mpowr-web-archive@optimus.ietf.org; Thu, 25 Dec 2003 01:52:46 -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 BAA06275 for ; Thu, 25 Dec 2003 01:52:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZPMR-0006NG-00 for mpowr-web-archive@ietf.org; Thu, 25 Dec 2003 01:52:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZPKG-0006Kj-00 for mpowr-web-archive@ietf.org; Thu, 25 Dec 2003 01:50:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZPI9-0006Hh-00 for mpowr-web-archive@ietf.org; Thu, 25 Dec 2003 01:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZPHt-0003uk-1x; Thu, 25 Dec 2003 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZPHW-0003uH-GX for mpowr@optimus.ietf.org; Thu, 25 Dec 2003 01:47:42 -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 BAA06202 for ; Thu, 25 Dec 2003 01:47:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZPHM-0006HS-00 for mpowr@ietf.org; Thu, 25 Dec 2003 01:47:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZPEC-0006Fv-00 for mpowr@ietf.org; Thu, 25 Dec 2003 01:44:13 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AZPD2-0006EU-00 for mpowr@ietf.org; Thu, 25 Dec 2003 01:43:00 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id hBP6nlc07534 for ; Wed, 24 Dec 2003 22:49:47 -0800 From: Dave Crocker To: X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: dcrocker@brandenburg.com Date: Wed, 24 Dec 2003 22:42:22 -0800 Message-ID: <20031224224222.696311@bbprime> In-Reply-To: <35351182.1072254430@scan.jck.com> Subject: Re: RFC Editor doc approvals (RE: [mpowr] Mailing List Management) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 24 Dec 2003 08:27:10 -0500, John C Klensin wrote: > > > =09* At the time 2026 was written, the RFC Editor timeout > > > =09for IESG review of an independent submission document > > > =09was two weeks. > > > > 1) as far as I remember, the rfc editor never did anything when > > the timeout expired. not even when it was 2 weeks. > > If the RFC Editor is following this list, I'll let them respond. But > my recollection is that "never did anything" was the result of a > clear understanding that the IESG would be very irritated if they > did so and, perhaps, would even attempt to retaliate. This thread is missing some fairly basic underpinnings that were true during the 1989-1993 period that I was an AD, which I generally call the start of the "modern" IETF: 1. The RFC Editor operation was independent of the IETF, although it of course had a number of substantial points of coordination. 2. The IESG did not get to do a pocket veto on any documentfor which there was no serious claim it impacted existing IETF work or would likely have significant, negative impact on Internet operation. In other words, folks, the RFC Editor engaged in a number of courtesies with the IETF, via the IESG, but was entirely free to exercise its own judgments about documents that did not originate in the IETF and did not seek standards status. This has changed in recent years, much to the detriment of the open publication policy that used to hold true for the RFC series. Now, it appears that the IESG gets a complete veto over any RFC, no matter its source or desired status. d/ _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Dec 27 13:25:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20270 for ; Sat, 27 Dec 2003 13:25:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaJ7T-0001rr-NL for mpowr-archive@odin.ietf.org; Sat, 27 Dec 2003 13:25:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBRIOxOU007178 for mpowr-archive@odin.ietf.org; Sat, 27 Dec 2003 13:24:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaJ7T-0001rf-J7 for mpowr-web-archive@optimus.ietf.org; Sat, 27 Dec 2003 13:24:59 -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 NAA20237 for ; Sat, 27 Dec 2003 13:24:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaJ7R-0003XW-00 for mpowr-web-archive@ietf.org; Sat, 27 Dec 2003 13:24:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaJ4V-0002yS-00 for mpowr-web-archive@ietf.org; Sat, 27 Dec 2003 13:21:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AaJ0i-0002Vg-00 for mpowr-web-archive@ietf.org; Sat, 27 Dec 2003 13:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaJ0j-0001cr-9L; Sat, 27 Dec 2003 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaJ00-0001aT-UR for mpowr@optimus.ietf.org; Sat, 27 Dec 2003 13:17:17 -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 NAA19701 for ; Sat, 27 Dec 2003 13:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaIzy-0002Px-00 for mpowr@ietf.org; Sat, 27 Dec 2003 13:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaIy9-0002Mp-00 for mpowr@ietf.org; Sat, 27 Dec 2003 13:15:22 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AaIwp-0002Kg-00 for mpowr@ietf.org; Sat, 27 Dec 2003 13:13:59 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07CB361B8F; Sat, 27 Dec 2003 19:13:27 +0100 (CET) Date: Fri, 26 Dec 2003 21:54:23 -0800 From: Harald Tveit Alvestrand To: Alex Rousskov , James Kempf Cc: MPowr Subject: Re: [mpowr] Mailing List Management Message-ID: <902909174.1072475663@localhost> In-Reply-To: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, I have dealt with at least one environment where the level of disruptive participants was far higher than most IETF lists. One of the things that was actively mentioned was that a banned participant could get other people to forward their argument while they were banned, if they had one they considered important. None ever did. Harald --On 23. desember 2003 14:02 -0700 Alex Rousskov wrote: > > Quick question: While X's e-mails are blocked without a formal last > warning, can the WG decide on anything of value? For example, can the > WG decide on submitting the current draft as proposed standard? Or > accepting an individual draft as a WG work item? > > If yes, then this would be a convenient way for the Chair's party to > win consensus on the issue (by silencing a few people who oppose the > decision). Surely, their posting "privileges" will be restored a week > later, but it would take _another_ appeal to overrule any WG decisions > made during that week. Would it not? > > Alex. > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr > > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 29 14:02:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08446 for ; Mon, 29 Dec 2003 14:02:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2eY-00051T-MB for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 14:02:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTJ2A3w019299 for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 14:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2eY-000518-Fh for mpowr-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 14:02:10 -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 OAA08432 for ; Mon, 29 Dec 2003 14:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab2eW-0000hn-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 14:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab2cx-0000dR-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 14:00:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab2Zr-0000X8-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 13:57:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2ZY-0004w5-LB; Mon, 29 Dec 2003 13:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2Z1-0004vq-D1 for mpowr@optimus.ietf.org; Mon, 29 Dec 2003 13:56: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 NAA08288 for ; Mon, 29 Dec 2003 13:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab2Yu-0000W8-00 for mpowr@ietf.org; Mon, 29 Dec 2003 13:56:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab2Vx-0000QS-00 for mpowr@ietf.org; Mon, 29 Dec 2003 13:53:18 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ab2RI-0000Jd-00 for mpowr@ietf.org; Mon, 29 Dec 2003 13:48:28 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBTIlwk3071504; Mon, 29 Dec 2003 11:47:58 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBTIlvi4071503; Mon, 29 Dec 2003 11:47:57 -0700 (MST) (envelope-from rousskov) Date: Mon, 29 Dec 2003 11:47:57 -0700 (MST) From: Alex Rousskov To: Harald Tveit Alvestrand cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <902909174.1072475663@localhost> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> <902909174.1072475663@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Fri, 26 Dec 2003, Harald Tveit Alvestrand wrote: > I have dealt with at least one environment where the level of > disruptive participants was far higher than most IETF lists. > > One of the things that was actively mentioned was that a banned > participant could get other people to forward their argument while > they were banned, if they had one they considered important. > > None ever did. None ever considered banned argument important or none ever forwarded the banned argument? I suspect that once/if we have easier banning rules, more people will feel compelled to circumvent them. In fact, even with the existing rules, IETF participants have faked e-mail, subscribed to the list with more than one name, and done other terrible things (as privately confirmed by a senior IETFer who was working on formalizing the banning process). IMO, this means that "easy" rules should be nearly perfect or should not be. Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 29 15:06:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10367 for ; Mon, 29 Dec 2003 15:06:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab3eP-0006rs-2X for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 15:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTK65n1026397 for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 15:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab3eO-0006rg-SL for mpowr-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 15:06:04 -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 PAA10275 for ; Mon, 29 Dec 2003 15:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab3eL-0002gK-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 15:06:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab3bp-0002Tm-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 15:03:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab3Xi-0002Jr-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 14:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab3XY-0006cI-GU; Mon, 29 Dec 2003 14:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab3X3-0006bX-MT for mpowr@optimus.ietf.org; Mon, 29 Dec 2003 14:58:29 -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 OAA09842 for ; Mon, 29 Dec 2003 14:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab3Wv-0002FQ-00 for mpowr@ietf.org; Mon, 29 Dec 2003 14:58:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab3Pr-00029Z-00 for mpowr@ietf.org; Mon, 29 Dec 2003 14:51:04 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1Ab3Ny-00023U-00 for mpowr@ietf.org; Mon, 29 Dec 2003 14:49:06 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB3E061BDA; Mon, 29 Dec 2003 20:48:24 +0100 (CET) Date: Mon, 29 Dec 2003 11:27:40 -0800 From: Harald Tveit Alvestrand To: Alex Rousskov Cc: MPowr Subject: Re: [mpowr] Mailing List Management Message-ID: <1124503550.1072697260@localhost> In-Reply-To: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> <902909174.1072475663@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On 29. desember 2003 11:47 -0700 Alex Rousskov wrote: > > On Fri, 26 Dec 2003, Harald Tveit Alvestrand wrote: > >> I have dealt with at least one environment where the level of >> disruptive participants was far higher than most IETF lists. >> >> One of the things that was actively mentioned was that a banned >> participant could get other people to forward their argument while >> they were banned, if they had one they considered important. >> >> None ever did. > > None ever considered banned argument important or none ever forwarded > the banned argument? None ever forwarded mail from a banned person (the observable fact). As far as I know, no banned person ever asked someone else to forward - but I can't guarantee that it never happened. > > I suspect that once/if we have easier banning rules, more people will > feel compelled to circumvent them. In fact, even with the existing > rules, IETF participants have faked e-mail, subscribed to the list > with more than one name, and done other terrible things (as privately > confirmed by a senior IETFer who was working on formalizing the > banning process). Note that all of the "terrible" things you mention have happened WITHOUT an effective banning process. > > IMO, this means that "easy" rules should be nearly perfect or should > not be. I don't follow the logic.... _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 29 15:42:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12633 for ; Mon, 29 Dec 2003 15:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab4DI-0000MA-BF for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 15:42:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTKg8XE001366 for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 15:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab4DI-0000Lx-4I for mpowr-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 15:42: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 PAA12626 for ; Mon, 29 Dec 2003 15:42:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab4DG-0004U7-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 15:42:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab4BQ-0004Rz-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 15:40:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab4AG-0004OW-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 15:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab4AH-0000J4-7e; Mon, 29 Dec 2003 15:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab49R-0000Ic-4I for mpowr@optimus.ietf.org; Mon, 29 Dec 2003 15:38:09 -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 PAA12535 for ; Mon, 29 Dec 2003 15:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab49P-0004ME-00 for mpowr@ietf.org; Mon, 29 Dec 2003 15:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab47a-0004If-00 for mpowr@ietf.org; Mon, 29 Dec 2003 15:36:15 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ab478-0004FB-00 for mpowr@ietf.org; Mon, 29 Dec 2003 15:35:46 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBTKZjk3076984; Mon, 29 Dec 2003 13:35:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBTKZjvK076983; Mon, 29 Dec 2003 13:35:45 -0700 (MST) (envelope-from rousskov) Date: Mon, 29 Dec 2003 13:35:45 -0700 (MST) From: Alex Rousskov To: Harald Tveit Alvestrand cc: MPowr Subject: Re: [mpowr] Mailing List Management In-Reply-To: <1124503550.1072697260@localhost> Message-ID: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> <902909174.1072475663@localhost> <1124503550.1072697260@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 On Mon, 29 Dec 2003, Harald Tveit Alvestrand wrote: > Note that all of the "terrible" things you mention have happened > WITHOUT an effective banning process. Exactly. This implies, to me, that there will be even more violations if the banning process is formalized but has cheap loopholes. > I don't follow the logic.... If the rules of the games are unknown a priory but determined by the Oracle on a case-by-case basis, a violator will think twice before upsetting the Oracle because the Oracle may adapt and punish even more severely. Violations will still happen, of course. If the rules are formal and known a priory, a violator that found a legal loophole, would be more inclined to use it because the rules would prohibit the punishment (by loophole definition). More violations (of the rules intent) will happen. Thus, if we are going to formalize something, we must make sure there are no cheap loopholes. If the latter is impossible, we may be better of without formalization. Think, for example, of US tax law: those with resources to find loopholes pay no or lesser taxes and do not feel threatened or guilty. One could argue that they are violating the [original] intent of the law, but they certainly do not violate the law (by loophole definition). Alex. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 29 17:04:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14409 for ; Mon, 29 Dec 2003 17:04:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5UA-0002P5-Dx for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 17:03:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTM3cuR009239 for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 17:03:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5UA-0002Ow-7Q for mpowr-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 17:03:38 -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 RAA14398 for ; Mon, 29 Dec 2003 17:03:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab5Tt-00073y-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 17:03:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab5PM-0006vs-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 16:58:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab5L9-0006nR-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 16:54:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5Kr-00024I-4J; Mon, 29 Dec 2003 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5KD-000240-B2 for mpowr@optimus.ietf.org; Mon, 29 Dec 2003 16:53:21 -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 QAA14142 for ; Mon, 29 Dec 2003 16:53:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab5K1-0006kz-00 for mpowr@ietf.org; Mon, 29 Dec 2003 16:53:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab5GI-0006ep-00 for mpowr@ietf.org; Mon, 29 Dec 2003 16:49:18 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Ab5Cj-0006Zp-00 for mpowr@ietf.org; Mon, 29 Dec 2003 16:45:37 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1Ab5Ce-0002Tg-00; Mon, 29 Dec 2003 16:45:32 -0500 Date: Mon, 29 Dec 2003 16:45:32 -0500 From: John C Klensin To: Alex Rousskov , Harald Tveit Alvestrand cc: MPowr Subject: Re: [mpowr] Mailing List Management Message-ID: <78624766.1072716332@scan.jck.com> In-Reply-To: References: <011901c3c654$24fdc830$5b6015ac@dclkempt40> <383969298.1071956717@localhost> <3FE86D59.8060201@txc.com> <2ca901c3c97b$347b1db0$5b6015ac@dclkempt40> <2ccf01c3c97d$b5993ec0$5b6015ac@dclkempt40> <2d7d01c3c987$cfa411f0$5b6015ac@dclkempt40> <902909174.1072475663@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Monday, 29 December, 2003 11:47 -0700 Alex Rousskov wrote: > I suspect that once/if we have easier banning rules, more > people will feel compelled to circumvent them. In fact, even > with the existing rules, IETF participants have faked e-mail, > subscribed to the list with more than one name, and done other > terrible things (as privately confirmed by a senior IETFer who > was working on formalizing the banning process). > > IMO, this means that "easy" rules should be nearly perfect or > should not be. Alex, I can't imagine why you think this follows. In many organizations, and in the IETF in other areas than mailing list management, it is the hard/rigid rules that inspire people to see if they can game them. It is the very specific rules that encourage people to do slightly outrageous things, safe in the knowledge that they can claim unfairness if those things violate the spirit, but not the letter, of the rules. By contrast, whatever the other merits of the idea, "the WG chair can kick someone off a list, at least for a while, for being --in that person's opinion-- disruptive or generally irritating" isn't going to encourage rule-circumvention as an end in itself, if only because that would certainly be "generally irritating". Now, if you had said "if we start kicking people off lists regularly and in large quantities, that would encourage circumvention", I'd probably agree... but suggest that would demonstrate that we have other problems which it would be good to get on the table. The bottom line, it seems to me, is that we need to function, as Dave Crocker has been pointing out (I hope I've correctly understood him), as a collaborative community. No amount of rule-making is going to cause either a sense of collaboration or a sense of community to happen. If we can't keep (or recover) that sense, then we need a rather different set of rules and structures, to the point that debates about mailing list participation is a waste of time. Within such a community, it seems quite rational to me to tell WG Chairs that they have lead responsibility for WG progress. If something or someone is interfering with that progress --including disruptions on mailing lists-- then they should be encouraged to stop it and, if necessary, pushed out of the way. Should the AD be fully informed about such an action? Of course. Should it be appealable? Even more obviously. But the right way to deal with problems of these sorts _within a community_ is to catch them earlier and push back (which, IMO, should include involving the whole WG in a "shunning" process when that seems useful), not to try to solve them by creating ever-more-rigid and complex procedures. Fewer formal procedures, more exercise of good sense, more unambiguous negative reinforcement for failure to exercise good sense.... john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Dec 29 17:18:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15074 for ; Mon, 29 Dec 2003 17:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5iD-0003KK-FR for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 17:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTMI9fA012789 for mpowr-archive@odin.ietf.org; Mon, 29 Dec 2003 17:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5iD-0003KC-A5 for mpowr-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 17:18:09 -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 RAA15068 for ; Mon, 29 Dec 2003 17:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab5iB-00003E-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 17:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab5gK-00000W-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 17:16:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab5fB-0007lz-00 for mpowr-web-archive@ietf.org; Mon, 29 Dec 2003 17:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5fB-0003Cz-TT; Mon, 29 Dec 2003 17:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab5eS-0003CN-AP for mpowr@optimus.ietf.org; Mon, 29 Dec 2003 17:14:16 -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 RAA15003 for ; Mon, 29 Dec 2003 17:14:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab5eL-0007jM-00 for mpowr@ietf.org; Mon, 29 Dec 2003 17:14:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab5ca-0007fq-00 for mpowr@ietf.org; Mon, 29 Dec 2003 17:12:20 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1Ab5at-0007Yn-00 for mpowr@ietf.org; Mon, 29 Dec 2003 17:10:35 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id hBTMHRc11088 for ; Mon, 29 Dec 2003 14:17:27 -0800 From: Dave Crocker To: MPowr X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Mon, 29 Dec 2003 14:09:56 -0800 Message-ID: <2003122914956.233169@bbprime> In-Reply-To: <78624766.1072716332@scan.jck.com> Subject: Re: Re: [mpowr] Mailing List Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, > The bottom line, it seems to me, is that we need to function, as > Dave Crocker has been pointing out (I hope I've correctly understood > him), as a collaborative community. No amount of rule-making is > going to cause either a sense of collaboration or a sense of > community to happen. If we can't keep (or recover) that sense, then > we need a rather different set of rules and structures, to the point > that debates about mailing list participation is a waste of time. > Within such a community, it seems quite rational to me to tell WG > Chairs that they have lead responsibility for WG progress. If > something or someone is interfering with that progress --including > disruptions on mailing lists-- then they should be encouraged to > stop it and, if necessary, pushed out of the way. Should the AD be > fully informed about such an action? Of course. Should it be > appealable? Even more obviously. But the right way to deal with > problems of these sorts _within a community_ is to catch them > earlier and push back (which, IMO, should include involving the > whole WG in a "shunning" process when that seems useful), not to try > to solve them by creating ever-more-rigid and complex procedures. > > Fewer formal procedures, more exercise of good sense, more > unambiguous negative reinforcement for failure to exercise good > sense.... I am quite happy with all of the above text and more than willing to accept attribution of any of it to me, whether I previously said it or not... Here's a small amount I will offer as a response to the above content: The IETF has succeeded because it has us an extraordinarily open and collaborative process, to develop timely solutions for requirements shared by a community eager to obtain thos solutions. The IETF has notably employed highly flexible and subjective mechanisms to achieve this, in the belief that it needed only enough mechanism to permit an effort to function, and that more mechanism than was needed serves as a hindrance, not a help. "Rough Consensus" means that there is strong community support for a decision. If there is strong community support, then little formality is needed. If there is no strong community support, then substantial formality provides only veneer of legitimacy, not its reality . If there is strong community support, there is collaboration. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr