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

Jari Arkko <> Wed, 25 June 2008 18:29 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5508E3A6A9D; Wed, 25 Jun 2008 11:29:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC2583A6A9D for <>; Wed, 25 Jun 2008 11:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id epN+ZB-I44Nc for <>; Wed, 25 Jun 2008 11:29:44 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id C055C3A6A65 for <>; Wed, 25 Jun 2008 11:29:43 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 6FA1D1986ED; Wed, 25 Jun 2008 21:29:45 +0300 (EEST)
Received: from [] (unknown [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 1B2ED198680; Wed, 25 Jun 2008 21:29:45 +0300 (EEST)
Message-ID: <>
Date: Wed, 25 Jun 2008 21:30:46 +0300
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20080505)
MIME-Version: 1.0
To: Lakshminath Dondeti <>
Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
References: <> <> <>
In-Reply-To: <>
X-Virus-Scanned: ClamAV using ClamSMTP
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"


Better understanding of the type of behaviors in this space would 
certainly be useful. And I don't want to disagree with your assessment 
of the behaviors; many of them sound like something that appears in 
practice. In particular, the shepherds are far less involved in the 
Discuss resolutions than the authors. And we do not involve the WGs as 
much as we should. I think writing guidelines on what the role of the 
various persons in the process is would be very useful. And obviously we 
should start by better following of the existing documents, like the 
Proto Shepherd RFC or the Discuss criteria document.

However, with regards to blocking consensus of a WG, please remember 
that the WG is not necessarily the only place where consensus is tested. 
I recently had a case which had significant IETF Last Call discussion. I 
held a Discuss to ensure that the (fairly clear, IMO) conclusion from 
the discussion would be taken into the document. It did eventually, but 
only after significant back-and-forth with the authors. Overriding the 
original WG consensus? Yes. Right thing to do? I think so, not only was 
it right technically but it was something backed up by the Last Call. 
Did we get the details right, did the text go too far or did it fall 
short? I don't know, its a judgment call. The end result was somewhere 
between the LC guidance and authors' opinions. Painful for the WG? Sure.

On text that comes from the IESG: this is more common in recent years 
than it was before. I am one of the ADs who tends to do that, both for 
the documents that I sponsor and for resolving my Discusses. But I would 
rather not do it. But I often end up doing it if there is no progress 
otherwise; I want to get my sponsored documents approved and I want to 
reduce the list of my outstanding Discusses. If I can help my authors by 
proposing text, I will do it. But I would really like to see the 
document shepherds in active role here. Or at least the authors. The 
general guidance for authors whose document gets a Discuss is to first 
confirm whether the raised issue is a real one or not. If it is not, ask 
the Discuss to be cleared. Fight if needed! If it is real, work with 
your shepherd and WG to develop a proposal to fix the problem. Mail the 
proposal to the Discussing ADs in a timely manner. Address explicitly 
all components raised in a Discuss, either by explaining how they are 
not issues or providing a solution to resolve the issue.


IETF mailing list