Re: [mpowr] Re: Getting Bad Ideas to Fail Early

"James Kempf" <kempf@docomolabs-usa.com> Fri, 30 January 2004 22:46 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04248 for <mpowr-archive@odin.ietf.org>; Fri, 30 Jan 2004 17:46:58 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhPE-0000zp-Dk for mpowr-archive@odin.ietf.org; Fri, 30 Jan 2004 17:46:32 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UMkWfb003830 for mpowr-archive@odin.ietf.org; Fri, 30 Jan 2004 17:46:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhPE-0000ze-6d for mpowr-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 17:46:32 -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 RAA03613 for <mpowr-web-archive@ietf.org>; Fri, 30 Jan 2004 17:46:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmhPB-0005er-00 for mpowr-web-archive@ietf.org; Fri, 30 Jan 2004 17:46:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmhOI-0005Yw-00 for mpowr-web-archive@ietf.org; Fri, 30 Jan 2004 17:45:35 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmhNj-0005SP-00 for mpowr-web-archive@ietf.org; Fri, 30 Jan 2004 17:44:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhNl-0000s2-4p; Fri, 30 Jan 2004 17:45:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmhNI-0000rV-BG for mpowr@optimus.ietf.org; Fri, 30 Jan 2004 17:44:32 -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 RAA01370 for <mpowr@ietf.org>; Fri, 30 Jan 2004 17:44:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmhNF-0005Rk-00 for mpowr@ietf.org; Fri, 30 Jan 2004 17:44:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmhML-0005Le-00 for mpowr@ietf.org; Fri, 30 Jan 2004 17:43:34 -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 1AmhLp-0005F2-00 for mpowr@ietf.org; Fri, 30 Jan 2004 17:43:01 -0500
Message-ID: <035e01c3e782$7601a590$606015ac@dclkempt40>
From: James Kempf <kempf@docomolabs-usa.com>
To: David.Partain@ericsson.com, mpowr@ietf.org
References: <20040120141958.C8D3577A6FA@guns.icir.org> <200401301538.06548.david.partain@ericsson.com>
Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early
Date: Fri, 30 Jan 2004 13:57: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: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

David,

I think we need to make a distinction between the IESG approving publishing
a document, as currently, and a change where an individual AD could approve
a document. I can see a process where, if the reviews come in good and the
WG agrees to make any proposed changes, an individual AD is allowed to
simply approve publication without requiring the entire IESG to review or
even to have to read the reviewers comments. This could save the IESG a lot
of work. I can't see a case where the document gets approved automatically
without the AD's involvement. I believe there will always be an element of
judgement in deciding whether the reviews were adequate, the WG's response
was appropriate, etc. that one would want to have a knowledgable human in
the loop for publication approval.

            jak


----- Original Message ----- 
From: "David Partain (LI/EAB)" <david.partain@ericsson.com>
To: <mpowr@ietf.org>
Sent: Friday, January 30, 2004 6:38 AM
Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early


> Hi all,
>
> Thanks, Mark, for your answer.
>
> On Tuesday 20 January 2004 15.19, Mark Allman wrote:
> > You definately raise a whole lot of good questions (probably better
> > suited for ICAR, but...).  Thanks!
> >
> > But, I want to say a few words about this...
> >
> > > That said, this won't be even remotely trivial.  I just don't
> > > see how we can get away from the fact that that would require
> > > a set of experienced people outside the WG who can provide an
> > > "IESG-like" review at semi-regular intervals in a document's
> > > path through the WG.  But those reviews must also have
> > > "IESG-like" weight, or the exercise may indeed be pointless.
> >
> > I am not sure I agree with this...
> >
> >   * First, if the WG and the reviewers are 180-degrees different in
> >     their thinking then it would seem as if the WG chair could
> >     reasonably say that there is no consensus.
>
> Agreed.  What happens after that is what's interesting.
>
> >     That would assume that
> >     the reviewers would then work closely with the WG to fix things (or,
> >     they wouldn't be part of the WG consensus determination).  That may
> >     or may not happen -- sort of depends on what the early review
> >     mechanism looks like.
>
> Doesn't this (getting consensus) working assume (at least)
> two things?  1. the working group has some reason to respect the
> opinion (good people, history, quality of remarks, obviousness
> of the problems they point out) and (2) the working group
> isn't stacked with folks who have An Agenda that precludes
> listening to criticism.  Not that _that_ would ever happen...
>
> I _would love_ for things to work this way.  I fear, though,
> that calling someone's baby ugly is invariably going to result
> in a defensive posture.
>
> >   * Given a high quality review team it would seem as though the WG
> >     would ignore the reviewers at their own peril.
>
> Fair enough.  Perhaps a mechanism requiring review reports to go
> to the IESG _as well as_ the WG would provide the necessary heads
> up that something's amiss?
>
> >     I would think that when the WG and the reviewers are
> >     completely at odds it could be the WG chair's job to try to work
> >     through the issues.
>
> This isn't really that different from dealing with significant
> conflicts within the WG constituency, is it?
>
> >     (Maybe bring in more reviewers or bring in an
> >     AD or IAB member or other senior IETFer to try to explain the
> >     rational behind some objection (e.g., "must have CC").  It would
> >     behoove the WG to work with the reviewers in the long run, I think.
> >     (And, yes, sometimes that is going to be tough for the WG to
> >     understand.)
>
> I think you and I agree.  Perhaps, though, a formalization of the
> communication between the WG and reviewers which includes the
> IESG in the loop -- without necessarily requiring that they _do_
> something -- would be sufficient to make external reviews useful.
>
> >   * If the WG is stubborn and shoots the document to the IESG anyway
> >     then the early review doesn't necessarily help with the "IESG
> >     overload" problem.  But, it seems that early
> >     cross-area/functional/whatever review could well present
> >     opportunities to work out issues earlier rather than later.  And,
> >     WGs (and, specifically, WG chairs) should be wise enough to attempt
> >     to work through the issues and not just say "we disagree".
>
> If nothing else, it provides the IESG with some external "hard
> facts", which are not always available to a sufficient extent
> today (as I understand it).
>
> >   * In the blatant cases where the WG chair does not try to work through
> >     the issues then the IESG overload problem can be helped by the IESG
> >     replacing the WG chair.
> >
> > Maybe we are thinking about authority a little to much.  Maybe we should
> > be thinking in terms of collaboration and seeing how far that will take
> > us (a theme others have raised repeatedly).
>
> You cannot imagine how much I hope the result of this work is
> exactly that -- a refinement / clarification of the consensus
> process rather than an introduction of chains of authority.
> Our consensus tradition is absolutely one of the strengths
> of the IETF.  However, I fear for the long-term health of our
> current system.
>
> The source of my anxiety is more sociological than anything
> else.  A consensus-driven process thrives in a setting where
> there's a common set of values, where people "just know"
> how things are done and don't violate these unwritten rules.
> I live in a society (Sweden) where this is exactly the case
> and things work relatively smoothly.  The crunch comes when the
> homogeneity of the society is altered (as is happening here and
> in the IETF now) and those common values cease to be as clear
> to everyone.  This certainly has thrown things off kilter in
> the IETF and I'm worried that any attempt to codify the "common
> values" and "unwritten rules" is going to be very difficult.
> I guess we'll all find out.
>
> But now I'm babbling, so I'll move on...
>
> Wishing you all a good weekend,
>
> David
>
>
>
> _______________________________________________
> 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