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

Russ Housley <> Tue, 24 June 2008 22:31 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B33B03A67F2; Tue, 24 Jun 2008 15:31:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC9A13A6914 for <>; Tue, 24 Jun 2008 15:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.165
X-Spam-Status: No, score=-101.165 tagged_above=-999 required=5 tests=[AWL=1.434, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AoEoJyde5+5y for <>; Tue, 24 Jun 2008 15:31:47 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id DB0CF3A67D9 for <>; Tue, 24 Jun 2008 15:31:01 -0700 (PDT)
Received: (qmail 31802 invoked by uid 0); 24 Jun 2008 22:24:15 -0000
Received: from unknown (HELO ( by with SMTP; 24 Jun 2008 22:24:15 -0000
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 24 Jun 2008 18:24:20 -0400
From: Russ Housley <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
In-Reply-To: <>
References: <> <> <p06250116c47c330c7dd0@[]> <> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <> <> <> <> <> <>
Mime-Version: 1.0
Message-Id: <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

I'm sorry for the way that this discussion has gone. I joined the 
discussion in order to let the whole community see both sides of the 
disagreement.  However, in an attempt to provide clarity and correct 
inaccurate statements, the discussion turned into tit for tat.  The 
back-and-forth banter did not help any of the people that wanted to 
understand the issues or context for the disagreement.  For my part 
in that situation, I apologize.  I'll try very hard to not repeat my 
mistakes in the future.

As Chair of the IESG, I am going to do my best to find ways to reduce 
the number of late surprises.  This is in line with the goal that I 
set when I took on this position: incremental improvement to the IETF 
standards process.

The I-D Tracker and the way that IESG ballot positions are used is at 
the center of the issues raised by this appeal.  The I-D Tracker was 
built with two goals in mind.  First, it was intended to increase 
transparency.  Second, it was intended to help ADs manage the 
document review and approval process.  The first goal seems to have 
been achieved to a greater degree than I ever realized.  As a result, 
IESG members now find themselves being asked to explain processes 
that were previously invisible to the community.  As such, I think it 
is time to consider whether the IESG ballot structure needs 
revision.  The ballot was designed for ADs and the Secretariat; it 
tells whether a document is ready for approval.  Today, it appears 
that we also need a ballot that tells the document authors, WG 
chairs, and PROTO shepherds what actions are needed to move a document forward.

At this point I cannot give any explicit actions that will be taken, 
I sincerely hope that the handling of this appeal will provide 
insights for the next steps.  I think it is time to let the IESG 
process the appeal.

All the best,

IETF mailing list