Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Ted Hardie <hardie@qualcomm.com> Thu, 19 June 2008 18:33 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 8DC6F3A694C; Thu, 19 Jun 2008 11:33:09 -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 16E123A694C; Thu, 19 Jun 2008 11:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 NUj+BUdYuoXo; Thu, 19 Jun 2008 11:33:06 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D21473A6817; Thu, 19 Jun 2008 11:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1213900438; x=1245436438; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240601c480518c107f @[10.0.1.196]>|In-Reply-To:=20<20080619175645.0CA443A68C2 @core3.amsl.com>|References:=20<8832006D4D21836CBE6DB469@ klensin-asus.vbn.inter-touch.net>=0D=0A=20<485590E2.30801 07@gmail.com>=09<p06250116c47c330c7dd0@[75.145.176.242]> =0D=0A=20<4856DE3A.3090804@gmail.com>=0D=0A=20<C122F91B-5 9B0-49AC-ABBC-6752217C4E47@NOKIA.COM>=0D=0A=20<2008061902 4147.9146C3A6938@core3.amsl.com>=09<485A353B.30403@dcrock er.net>=0D=0A=20<20080619175645.0CA443A68C2@core3.amsl.co m>|Date:=20Thu,=2019=20Jun=202008=2011:33:54=20-0700|To: =20Russ=20Housley=20<housley@vigilsec.com>,=0D=0A=20=20 =20=20=20=20=20=20"dcrocker@bbiw.net"=0D=0A=09<dcrocker@b biw.net>|From:=20Ted=20Hardie=20<hardie@qualcomm.com> |Subject:=20Re:=20Appeal=20against=20IESG=20blocking=20DI SCUSS=20on=0D=0A=20draft-klensin-rfc2821bis|CC:=20"ietf@i etf.org"=20<ietf@ietf.org>,=20"iesg@ietf.org"=20<iesg@iet f.org>|Content-Type:=20text/plain=3B=20charset=3D"us-asci i"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5321"=3B =20a=3D"3894813"; bh=5XUAHKTvi2Uexmc9edlv0rvTyFpy7P+/Ue9aoLYgtRU=; b=gwoKE+biJpIgw2/4sjvnWCrmzzFMntNcOurbUI/aT1LT7JhksojsKzdi QH3/D4eWcMiWQwaAmAOSeuTf1Dvk86pu2sPSfK1gSsCzUHZJR6YgnF44q yiTM62VD0NBlQgIpKv7vDMWlUCzT8ibQXn0VP1U/I+Sl563Tak/Vbac96 A=;
X-IronPort-AV: E=McAfee;i="5200,2160,5321"; a="3894813"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2008 11:33:58 -0700
Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JIXw0x027338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jun 2008 11:33:58 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JIXvqF025482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Jun 2008 11:33:57 -0700
Received: from [10.0.1.196] (10.50.0.118) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 19 Jun 2008 11:33:56 -0700
MIME-Version: 1.0
Message-ID: <p06240601c480518c107f@[10.0.1.196]>
In-Reply-To: <20080619175645.0CA443A68C2@core3.amsl.com>
References: <8832006D4D21836CBE6DB469@klensin-asus.vbn.inter-touch.net> <485590E2.3080107@gmail.com> <p06250116c47c330c7dd0@[75.145.176.242]> <4856DE3A.3090804@gmail.com> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <20080619024147.9146C3A6938@core3.amsl.com> <485A353B.30403@dcrocker.net> <20080619175645.0CA443A68C2@core3.amsl.com>
Date: Thu, 19 Jun 2008 11:33:54 -0700
To: Russ Housley <housley@vigilsec.com>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Cc: "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@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

At 10:50 AM -0700 6/19/08, Russ Housley wrote:
>
>That seems to be the crux of the appeal.  Does every possible thing
>upon which an AD can raise a DISCUSS position need to align with a
>written rule?  Don't we select leaders because we have some
>confidence in their judgement?
>
>Russ

Russ,
	This is casting the problem in ways that continue to miss
the point.  Of course we expect individual Area Directors to exercise
judgement, and we expect the IESG as a body to do the same.

	But we also expect them to exercise due care in listening
to the folks actually doing the work, and not over-rule them when they
clearly have considered the issues.  In this case, John's appeal makes
clear that the folks writing the document considered the issue
and made a decision to value continuity.  A DISCUSS position
to reconfirm that in light of an Area Director's concerns would
be valid (and probably welcome); once confirmed though, it
should get dropped.  Otherwise, it over-rules a community decision
with the individual technical judgement of the Area Director. 

 	There are very few cases where that is okay.  It applies when
there is a documented, larger community consensus that the WG or
submission group decision ignores (a working group decision that
congestion control wasn't important would get pushback on this
front, for example).  It applies when the Area Director can demonstrate
harm to the Internet as a result of the decision; the "can demonstrate"
there, though, is to the *community* not just to himself or the IESG.
It applies when the Area Director can demonstrate that the proposal
simply *does not work* to the satisfaction of the larger community, no
matter what the proposers believe.

	Most DISCUSS don't need to meet any of those tests because
the WGs or proposers agree that the issues need to be addressed, so
there is no over-ride present.  That's good, because over-riding the
considered technical judgement of the folks doing the work doesn't
just generate appeals, it drives folks away.  The extent to which
the current IESG is sliding back into substituting its technical
judgement for the WGs' is a worrying trend that I've already pointed
out.  This appeal may seem to be on a small point in a single
document, but the issue is quite fundamental.  The IETF can drive
itself into irrelevance very quickly by appearing to be driven by
ex cathedra pronouncements; even the Pope has done that only
once since his infallibility was declared doctrine.  Doing so constantly
over things where the AD's opinion is not backed by community
consensus is currently getting you an appeal.  The next step could
well be reformation.

	I hope the IESG considers John's appeal in this light
and responds promptly to the issues he has raised.

				Ted Hardie

	








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