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

Lakshminath Dondeti <> Thu, 26 June 2008 11:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 791A43A6901; Thu, 26 Jun 2008 04:43:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 572E53A6A75 for <>; Thu, 26 Jun 2008 04:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rpJtgwWPimII for <>; Thu, 26 Jun 2008 04:42:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95F1F3A686D for <>; Thu, 26 Jun 2008 04:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1214480579; x=1246016579; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<>|Date:=20Th u,=2026=20Jun=202008=2004:43:00=20-0700|From:=20Lakshmina th=20Dondeti=20<>|User-Agent:=20Thun derbird=|MIME-Version:=201 .0|To:=20Brian=20E=20Carpenter=20<brian.e.carpenter@gmail .com>|CC:=20Jari=20Arkko=20<>,=20ietf|Subject:=20Re:=20Qualitative=20Analysis=20of=20 IETF=20and=20IESG=20trends=20(Re:=20Measuring=20IETF=0D =0A=20and=20IESG=20trends)|References:=20<20080624203548.>=09< >=09<>=20<48628ED6.1000800@p>=20<>|In-Reply-To:=20<>|Content-Type:=20text/plain=3B =20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5200,2160,5325"=3B=20a=3D"4243729"; bh=9o1nYdzMCyX20q2hBWbmlm+L20vnJ+JYs2ngtJ7Obpw=; b=Buro/LW5pnnLmjHX270wmu5JAXoQy080iBmXfmoZXKsQ+I6YrOC3oBrP ps3ocZ/gunlPnp3b5qtF6GeNxqb6wsnACy15vagfJCVCawEwqz2OZgSQ2 rAEhx+nOuwNdlLs17OxQOAnVC89SMmZf8ovGGqiHQ0n0wkq+znP/icBGk 0=;
X-IronPort-AV: E=McAfee;i="5200,2160,5325"; a="4243729"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2008 04:42:59 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m5QBgxfc010695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Jun 2008 04:42:59 -0700
Received: from [] ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m5QBgtIQ023162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jun 2008 04:42:57 -0700
Message-ID: <>
Date: Thu, 26 Jun 2008 04:43:00 -0700
From: Lakshminath Dondeti <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Brian E Carpenter <>
Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
References: <> <> <> <> <>
In-Reply-To: <>
Cc: Jari Arkko <>,
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"

On 6/25/2008 2:41 PM, Brian E Carpenter wrote:
> On 2008-06-26 06:30, Jari Arkko wrote:
>> Lakshminath,
>> 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.
> Our fundamental collective job is defined in RFC 3935:
>    The mission of the IETF is to produce high quality, relevant
>    technical and engineering documents that influence the way people
>    design, use, and manage the Internet in such a way as to make the
>    Internet work better.
> That means that it is *not* our collective job to ensure that a WG
> consensus survives critical review by the IETF as a whole and by
> the IESG, if there's reason to believe that the IETF as a whole
> doesn't agree with the WG consensus. And it's clearly the IESG's
> job to ensure that the critical review and final consensus (or lack
> of consensus) occur.

But, surely the WG consensus counts as part of the overall IETF 
consensus process, doesn't it?  Please see the example in my response to 
Jari.  The shepherding AD (or at least the document shepherd) has an 
idea of the WG consensus as well as the IETF consensus.  We cannot 
simply weigh the latest opinions more than all the discussions that have 
happened as part of the WG consensus.

> That, IMHO, is the proper role of a DISCUSS and the proper reason
> for delays in document approval. And if we see fluctuation in
> these delays, and fluctuation in the amount of active intervention
> by the ADs, it does not follow that the IESG is to blame. Maybe
> there are external factors, maybe there are WGs that are forgetting
> the IETF's mission, maybe our technology is getting harder and
> more complex. So I'm very dubious about using either quantitative
> *or* qualitative observations to point the finger at the IESG, or
> at process issues in general, without digging much deeper.
> Of course, the IESG needs to pay attention to delays,
> so Jari's data (like the earlier data that Bill Fenner used to
> produce) are very valuable. And of course, individual ADs
> have to think carefully whether a given issue is or is not
> worthy of a DISCUSS, and sometimes they get it wrong. But
> that will always be true, however we tune the process and
> procedures.

I am suggesting that we make further progress along the lines of the 
definition of the role of the document shepherd and reassert (or clearly 
define and state the expectations) on the roles of the document shepherd 
and shepherding AD.


>     Brian
IETF mailing list