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

Brian E Carpenter <> Thu, 26 June 2008 23:24 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 653113A6A0A; Thu, 26 Jun 2008 16:24:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8DA53A69FC for <>; Thu, 26 Jun 2008 16:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8eEDOmoAf42W for <>; Thu, 26 Jun 2008 16:24:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 704FB3A69C0 for <>; Thu, 26 Jun 2008 16:24:41 -0700 (PDT)
Received: by with SMTP id b25so211510rvf.49 for <>; Thu, 26 Jun 2008 16:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=goptQg3yZlhXPdrPKfVUhYu4GeN1+1fyFf5R6Z/Xljs=; b=o/VMhcF8SszUyHL48580Tg1hBdYO+0y/6neJAvgBbkS+GfCguSFmo8zrimcq0keUyE 8/9vtC/7uywP9PLclSl16bhFzbBKzOAN9VbnkcjU20GF9DjNiS7c31xw6an6pcouCBgN gl1SnwRwq7Iz7cXYwyf0ZORZX6BTuHHn6FvEY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=yBL2Shawfaw8hLBe8K03G23hLeTrGz7Vfo/nmKKg99jpZ8iIBNyUnVsBZ3Bj7I4mL+ qqPvvWCxSHjccIKdisTov8+f8ds5013/ZE9M+TZaXhbSb7yVUXbtV3Jnr1D2QfgC0yc+ yLGcGKcUDtXJG6LO/vTD6f6exfo+7XJp5lDfA=
Received: by with SMTP id r13mr370487rvl.177.1214522685036; Thu, 26 Jun 2008 16:24:45 -0700 (PDT)
Received: from ? ( []) by with ESMTPS id k2sm1183178rvb.4.2008. (version=SSLv3 cipher=RC4-MD5); Thu, 26 Jun 2008 16:24:44 -0700 (PDT)
Message-ID: <>
Date: Fri, 27 Jun 2008 11:23:47 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
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: <>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


On 2008-06-26 23:43, Lakshminath Dondeti wrote:
> On 6/25/2008 2:41 PM, Brian E Carpenter wrote:

>> 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.

At one level I agree. But suppose that the set of people who are
active in the SXFG7M WG are so focused on the sxfg7m protocol that
they have all missed the fact that it's extremely damaging to
normal operations of the m7gfxs protocol? And this includes the
responsible AD, who has no deep knowledge of m7gfxs? This is the sort
of problem that IETF Last Call and IESG review is intended to find,
and it may well mean that the WG consensus ends up being irrelevant
to the IETF non-consensus. (I'm not in the least suggesting that
this applies to the draft that led to the appeal that led to this

My conclusion, again, is that in the end this is the sort of
judgment call that we *expect* the IESG to make. And when we
feel they've misjudged, we appeal, and that tunes their judgment
for the future.

IETF mailing list