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

Russ Housley <> Tue, 24 June 2008 14:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 635393A6A10; Tue, 24 Jun 2008 07:45:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 735A33A6899 for <>; Tue, 24 Jun 2008 07:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.8
X-Spam-Status: No, score=-100.8 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b6fdtdjLlvNl for <>; Tue, 24 Jun 2008 07:45:10 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 0C0CD3A68D3 for <>; Tue, 24 Jun 2008 07:45:08 -0700 (PDT)
Received: (qmail 19638 invoked by uid 0); 24 Jun 2008 14:45:06 -0000
Received: from unknown (HELO ( by with SMTP; 24 Jun 2008 14:45:06 -0000
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 24 Jun 2008 10:19:06 -0400
To: Bernard Aboba <>
From: Russ Housley <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
In-Reply-To: <BLU137-W4906E79A3BA47548403D8493A10@phx.gbl>
References: <BLU137-W4906E79A3BA47548403D8493A10@phx.gbl>
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"


Many of the IESG activities are listed in John's appeal.  The DISCUSS 
Criteria document is probably the biggest step that was taken.  ADs 
routine challenge each other to stay within those guidelines.

At the IESG Retreat we had a discussion on this topic.  It is very 
hard to measure.  During the discussion, we quickly discovered that 
there are a number of DISCUSS positions related to some comment that 
was raised in Last Call but not addressed in any way.  One cannot 
call these "late surprises" and most of them are resolved very quickly.

We have a way to count DISCUSS positions, but we do not have a way to 
figure out what percentage of them are perceived as "late surprises" 
by the community.  So, while we are taking action in an attempt to 
make things better, we do not have a way to measure our success or 
failure beyond community perception.  Suggestions on making this more 
objective and less subjective are greatly appreaciated.


At 10:41 PM 6/23/2008, Bernard Aboba wrote:
>Russ Housley said:
>"I agree with this principle. In fact, I think that the IESG has 
>taken many steps over the last four or more years to reduce the 
>nearly-end-of-process surprises. Obviously, you do not think these 
>measures have been sufficient. One lesson from the many attempts to 
>make updates to RFC 2026 is that such policy documents needs to set 
>expectations without taking away flexibility and judgement. "
>Can you elaborate on what steps the IESG has taken to reduce the 
>"nearly-end-of-process surprises" and why effect this has had, if 
>any?  For example, have the delays resulting from IESG reviews 
>actually *decreased* as a result?
>The research by Prof. Simcoe of the Rotman School is not encouraging:

IETF mailing list