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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 870783A698D; Thu, 26 Jun 2008 04:35:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3D783A698D for <>; Thu, 26 Jun 2008 04:35:19 -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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KZzeoMaRIeJK for <>; Thu, 26 Jun 2008 04:35:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4DE833A6983 for <>; Thu, 26 Jun 2008 04:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1214480121; x=1246016121; 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:35:21=20-0700|From:=20Lakshmina th=20Dondeti=20<>|User-Agent:=20Thun derbird=|MIME-Version:=201 .0|To:=20Jari=20Arkko=20<>|CC:=20ietf|Subject:=20Re:=20Qualitative=20Analysis=20of=20 IETF=20and=20IESG=20trends=20(Re:=20Measuring=20IETF=0D =0A=20and=20IESG=20trends)|References:=20<20080624203548.>=09< >=20<>=20<48628ED6.1000800@p>|In-Reply-To:=20<> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-15=3B =20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5325"=3B=20 a=3D"4069342"; bh=N1V0KXnTfdxW9rauoHxKurD4fEoTrq9ssv0JJhqGKu0=; b=ahdwVVVbmZKjJ1aVqi6zhHPysIwOwqKb98l3qT/YHIlXRJIZvY7XpkZn N4r5Tk5PpYMmOEmf0lV4XclcqoBtmGSeFdejG+5NSC8oy+JtOq4cIX9sx T8TbfWIzTx6BHU43h0K++HAOXQSOTet21fT57sQ3DfxY3Q5T3aZ6Yu3ua 8=;
X-IronPort-AV: E=McAfee;i="5200,2160,5325"; a="4069342"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2008 04:35:21 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m5QBZLcb002048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Jun 2008 04:35:21 -0700
Received: from [] ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m5QBZHnw001823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jun 2008 04:35:19 -0700
Message-ID: <>
Date: Thu, 26 Jun 2008 04:35:21 -0700
From: Lakshminath Dondeti <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Jari Arkko <>
Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
References: <> <> <> <>
In-Reply-To: <>
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"


Thanks.  Some thoughts inline:

On 6/25/2008 11:30 AM, 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.

Of course.  I will try and see if I can put something of an initial 
draft coherently.

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

So, here is where I am probably confused as to how consensus is 
determined.  I understand that the documents are eventually "IETF 
Consensus" with the IESG determining what the consensus is.  The 
sponsoring AD has the overall view of any given document better than 
anyone else, at least in the authoritative role (for this discussion, I 
am just considering WG documents).

Consider a hypothetical case: a large WG has strong consensus on one of 
their documents, they believe it is within the charter's scope and think 
that the document is in the best interest of the Internet.  The WG 
chairs assess the consensus, and forward the document to the shepherding 
AD.  The shepherding AD takes one last look, determines everything is in 
order and sends it to last call.  A few people on the IETF Discussion 
list think that the proposed specification is about to doom the 
Internet.  A few others who have not even read the document agree based 
on emails.  Most of the WG members are either not on the IETF list or 
choose to stay silent.

The shepherding AD considers those comments, thinks that those issues 
have been addressed already and puts the document on the IESG agenda. 
All other ADs (except one) think that everything is fine and vote No 
Objection.  One AD agrees with the few people on the IETF Discussion 
list and decides to put a DISCUSS and proceeds to hack the document.  In 
the current model, other than the very few exceptions cited recently, 
the AD gets what he or she wants for the most part.  It is plausible 
that AD may do this even if no one else identified a problem.

Responding to Brian here: Note that I am not pointing fingers at IESG 
alone, but yes, I am pointing fingers at our process in that the 
hypothetical situation described above is "allowed" to happen at the 
moment.  Brian suggests "external" factors, but I am sorry I am not 
convinced.  If there are WGs that have forgotten the IETF's mission, it 
is one of the primary roles of the ADs and the IESG to steer those WGs 
in the right direction.  If our technology is becoming harder and more 
complex, it calls for involving more people and increasing transparency 
and not the other way around.

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

Jari, as I have noted before, if the status quo is considered the best 
way forward, I would rather you continue to propose text.  I as an 
author and document shepherd have appreciated that compared to the 
alternative.  That alternative, the iterative guess work, takes forever.

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

What I am getting at is that the shepherding AD believes that the 
document is ready to move forward when he or she puts the document on 
the IESG agenda.  He or she should make a decision about the DISCUSS:

1.  Editorial changes are needed for clarification.  Suggests an RFC Ed 
note that the rest of the IESG is okay with as well, sends a 1-wk call 
to the WG, and then sends approved announcement if there are no objections.

2. Technical changes are needed.  The DISCUSS AD identified something 
everyone else missed or made a mistake about and the Shepherding AD (as 
well as the rest of the IESG) agrees with that assessment.  This should 
be a big deal.  The shepherding AD has been following the work for 
several years at some level (I understand the turnover in the AD 
position, but let's consider the general case) but still missed the 
issue that the DISCUSS AD identified after a quick read of the same 

The Shepherding AD, document shepherd and the document authors 
understand the issue, prepare a short summary of the issue that every 
one agrees on, and a optionally possible solution and go back to the 
working group.  Clearly, this has to be a new issue or an old issue with 
substantial new information that will presumably convince many people to 
change their minds.  The process starts again.

3. No changes are needed.  Work as quickly as possible to convince the 
DISCUSS AD to remove the DISCUSS using all means at his or her disposal. 
  Note that this is not a discussion between two ADs at this stage in 
the process; the Shepherding AD represents years of work, and has 
considered most if not all of the information available.  The DISCUSS AD 
comparatively has less information.

This avoids coming up with compromise text between just the authors and 
one or more DISCUSS ADs.  There are many other people in the process and 
they have a huge say in how the document got to the shape it is in by 
the time it arrives at the IESG.


> Jari
IETF mailing list