Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)

John C Klensin <john-ietf@jck.com> Thu, 26 June 2008 23:36 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9194C3A694C; Thu, 26 Jun 2008 16:36:23 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49C93A694C for <ietf@core3.amsl.com>; Thu, 26 Jun 2008 16:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.116
X-Spam-Level:
X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=1.283, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CBa3aIA0T7M for <ietf@core3.amsl.com>; Thu, 26 Jun 2008 16:36:21 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DF5FB3A68DA for <ietf@ietf.org>; Thu, 26 Jun 2008 16:36:20 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KC10k-000B3V-AE; Thu, 26 Jun 2008 19:36:18 -0400
Date: Thu, 26 Jun 2008 19:36:17 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Message-ID: <CE24B45F0E7AC31704D4FED5@p3.JCK.COM>
In-Reply-To: <48642503.2000805@gmail.com>
References: <20080624203548.D3A8D3A67FD@core3.amsl.com> <48622DEB.7060403@piuha.net> <486267E0.8080704@qualcomm.com> <48628ED6.1000800@piuha.net> <4862BB84.4070401@gmail.com> <486380C4.6000607@qualcomm.com> <48642503.2000805@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Jari Arkko <jari.arkko@piuha.net>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Friday, 27 June, 2008 11:23 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

>...
> At one level I agree. But suppose that the set of people who
> are active in the SXFG7M WG are so focused on the sxfg7m
> protocol that they have all missed the fact that it's
> extremely damaging to normal operations of the m7gfxs
> protocol? And this includes the responsible AD, who has no
> deep knowledge of m7gfxs? This is the sort of problem that
> IETF Last Call and IESG review is intended to find, and it may
> well mean that the WG consensus ends up being irrelevant to
> the IETF non-consensus. (I'm not in the least suggesting that
> this applies to the draft that led to the appeal that led to
> this thread.)
> 
> My conclusion, again, is that in the end this is the sort of
> judgment call that we *expect* the IESG to make. And when we
> feel they've misjudged, we appeal, and that tunes their
> judgment for the future.

Brian,

Again, I agree.  And this sort of example is precisely one of
the major reasons why proposals to let a WG override an IESG
conclusion about consensus are problematic (the other involves a
WG that has been "captured" by a particular interest in order to
get a particular protocol output, but I'd expect an AD to notice
that and deal with it long before documents go into Last Call).

However, it means that we need to treat appeals about IESG
judgment calls as a completely normal and orderly part of the
process, rather than something sufficiently unusual that either 

	(i) the IESG treats an appeal as an attack on them
	collectively and starts circling the wagons rather than
	considering the appeal as a normal and formal request
	from the community for reconsideration, or that 
	
	(ii) IETF participants believe that they need to fear
	retaliation from one or more ADs if they generate appeals

independent of what might or might not be going on with recent
cases, I believe we have seen both phenomena in the last several
years.

This is not an easy problem.

     john


_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf