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

Ted Hardie <hardie@qualcomm.com> Thu, 19 June 2008 21:57 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 6D3AB28C12F; Thu, 19 Jun 2008 14:57:54 -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 8147F28C12E; Thu, 19 Jun 2008 14:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100
X-Spam-Level:
X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 km1CqnpX5+bq; Thu, 19 Jun 2008 14:57:52 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 73FD628C116; Thu, 19 Jun 2008 14:57:52 -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=1213912672; x=1245448672; 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<p06240604c480857d3cc8 @[10.0.1.196]>|In-Reply-To:=20<485AC27B.6070206@cisco.com >|References:=20<8832006D4D21836CBE6DB469@klensin-asus.vb n.inter-touch.net>=0D=0A=20<485590E2.3080107@gmail.com> =09<p06250116c47c330c7dd0@[75.145.176.242]>=0D=0A=20<4856 DE3A.3090804@gmail.com>=0D=0A=20<C122F91B-59B0-49AC-ABBC- 6752217C4E47@NOKIA.COM>=0D=0A=20<20080619024147.9146C3A69 38@core3.amsl.com>=09<485A353B.30403@dcrocker.net>=0D=0A =20<20080619175645.0CA443A68C2@core3.amsl.com>=0D=0A=20<p 06240601c480518c107f@[10.0.1.196]>=20<485AC27B.6070206@ci sco.com>|Date:=20Thu,=2019=20Jun=202008=2014:57:47=20-070 0|To:=20Eliot=20Lear=20<lear@cisco.com>|From:=20Ted=20Har die=20<hardie@qualcomm.com>|Subject:=20Re:=20Appeal=20aga inst=20IESG=20blocking=20DISCUSS=20on=0D=0A=20draft-klens in-rfc2821bis|CC:=20Russ=20Housley=20<housley@vigilsec.co m>,=0D=0A=20=20=20=20=20=20=20=20"dcrocker@bbiw.net"=0D =0A=09<dcrocker@bbiw.net>,=0D=0A=20=20=20=20=20=20=20=20" iesg@ietf.org"=20<iesg@ietf.org>,=20IETF=20Discussion=0D =0A=09<ietf@ietf.org>|Content-Type:=20text/plain=3B=20cha rset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200 ,2160,5321"=3B=20a=3D"4075918"; bh=jIjopkBDCsErajwkf/Mj4yhks/saqWrxc8R2WBWYK5M=; b=bGOxwyn4Tzj9loUB4JduuA3cKXqsea7c7sIDw+CWoKbyi+F7JNr+jdUZ AwBJILmC0MejKnBWlvwV7c7pJzkZpsoArPKv456dP02/AtERgVyW7o1Wx w3WDC/flUccj0era0Ixpe5/0yr5Ac5OtThoa2uizv3LGD0HIHY0hwpph2 0=;
X-IronPort-AV: E=McAfee;i="5200,2160,5321"; a="4075918"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2008 14:57:52 -0700
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JLvpke005673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jun 2008 14:57:52 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5JLvpDh018058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 19 Jun 2008 14:57:51 -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 14:57:50 -0700
MIME-Version: 1.0
Message-ID: <p06240604c480857d3cc8@[10.0.1.196]>
In-Reply-To: <485AC27B.6070206@cisco.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> <p06240601c480518c107f@[10.0.1.196]> <485AC27B.6070206@cisco.com>
Date: Thu, 19 Jun 2008 14:57:47 -0700
To: Eliot Lear <lear@cisco.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Cc: IETF Discussion <ietf@ietf.org>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>, "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 1:32 PM -0700 6/19/08, Eliot Lear wrote:
>
>Isn't the IESG is meant to serve two roles?  The first is to be the
>arbiter of community consensus.  The second is to be a judge on the
>quality of the work before them, as to whether it is ready to move
>forward.

The IESG is not meant to over-ride the community consensus for
specific technical choices without reason.  It needs to show *why*
it is over-riding a specific technical choice in a way that references
existing consensus, technical correctness, or the health of the
Internet.  Saying "I don't like the way you have done it, do it
my way" is not their job, and the existing "discuss criteria" document
tries to make that clear.

This is not about an overall judgement that a doc is not ready;
this is about over-riding the informed technical judgement of
the people who are doing the work.



>  The threat of the IESG saying, "jeez what a {dumb|complex|...}
>approach" separates us from other standards organizations (or at least
>it did).  The most famous example of all of this is still the
>ETHERNET-MIB WG where they were upset that Jon Postel reset a counter
>size in the final copy of the MIB to match the IEEE specification, and
>those folks were rip roaring upset that he did so.  I don't want the
>IESG to author the docs like Jon did but I do want them to stand in the
>way of dumb ideas.
>
>In this case they should be there to apply our *evolving* standards.  To
>hogtie those folk to me just begs for others to attempt to make use of
>those knots to get their dumb standards.
>
>Shouldn't the response to John's appeal demonstrate the balance between
>their two roles?

I look forward to seeing what it demonstrates.
					Ted



>Eliot

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