Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC

S Moonesamy <sm+ietf@elandsys.com> Tue, 08 October 2013 22:37 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B548211E80E6 for <ietf@ietfa.amsl.com>; Tue, 8 Oct 2013 15:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6SlS7zSX5+f for <ietf@ietfa.amsl.com>; Tue, 8 Oct 2013 15:37:28 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 543D311E8127 for <ietf@ietf.org>; Tue, 8 Oct 2013 15:36:51 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.234.128]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r98MaYep025523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Oct 2013 15:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1381271807; bh=IA52NiJSLj7WTZucQXdAtrvHjbxx2z/VMQaboLFITW8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CoUW70fBh365J/cipolb4ibQAXYe1blIORDekMbYynC6jCJIDSJ2jPC7WnnKix2R1 yy8cPID12Gm2sodsgfVFGeF5wFMmk4PvptikzcvlqpkzTypL/QlMZddd0m7zWvmXW+ sj9GkYg3yjcJdJBWJmTp2OAXwr4PhRBOA0V9q70I=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1381271807; i=@elandsys.com; bh=IA52NiJSLj7WTZucQXdAtrvHjbxx2z/VMQaboLFITW8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AdOZXdpuJHHrFTOhsS7GC5LCVF2Aj3HsR/6PdedORSkYhVitpGMMlZg/feVhT6eD4 BOX4Dvnywc91j98Tj2KcaI/9RYGm2NVfF3j5U3DMPXeBChGXTwTRZp9TwiK5MXyVkm 2QAjneiU/edVOM+XacEwU0PQXqB2JLb+J5su2Usg=
Message-Id: <6.2.5.6.2.20131008054041.0d74aa88@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 08 Oct 2013 13:56:14 -0700
To: ietf@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC
In-Reply-To: <20131007164829.16131.73595.idtracker@ietfa.amsl.com>
References: <20131007164829.16131.73595.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Pete Resnick <presnick@qti.qualcomm.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 22:37:29 -0000

At 09:48 07-10-2013, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'On Consensus and Humming in the IETF'
>   <draft-resnick-on-consensus-05.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be

I found the review by Dave Crocker [1] interesting.  Instead of 
reading the latest revision of the draft I wrote a draft [2].  I read 
what Pete Resnick said about consensus after that to compare notes.

The intended status of draft-resnick-on-consensus-05 is 
Informational.  What we have here is a document about consensus which 
will reflect the consensus of the IETF.  Should the document reflect 
the consensus of the IETF or not?

In Section 1:

   'Our ideal is full consensus, but we don't require it: Full consensus
    would allow a single intransigent person who simply keeps saying
    "No!" to stop the process cold.'

The above introduces the term "full consensus".  I took a quick look 
and I found at least one occurrence of the term in IETF discussions 
[3].  However, none of the IETF process documents use that term.

   "If the chair of a working group determines that a technical issue
    brought forward by an objector has been truly considered by the
    working group, and the working group has made an informed decision
    that the objection has been answered or is not enough of a
    technical problem to prevent moving forward, the chair can declare
    that there is rough consensus to go forward, the objection
    notwithstanding."

The word "objector" emphasizes that there is one person who 
dissents.  My preference is to consider the objection and address it 
instead of viewing the issue as dissent from one person.

    "This document attempts to explain some features of rough consensus,
     explain what is not rough consensus, and suggest ways that we might
     achieve rough consensus and judge it in the IETF."

The title of the document is "on consensus and humming in the 
IETF".  According to the above sentence the document attempts to 
discuss about rough consensus.  In my opinion there a nuance between 
"consensus" and "rough consensus".  As a quick reaction I would say 
that rough consensus provides a faster path to shape up a 
proposal.  It helps to cut down on document delivery time to the 
IESG.  The consensus part is sought by getting a broader perspective.

Section 2 sounds like objection-based processing.  A binary choice 
(re. technical question) can end up polarizing a discussion.  The 
section provides a good discussion about lack of disagreement.

One of the questions I wondered about is whether the person making 
the determination should use technical judgement or whether the 
person should only make a determination about the comments 
received.  I mentioned in an unrelated discussion that if it is the 
consensus of the group that the sky is green, that's what goes in the 
document.  The person making the determination can flag it as an 
issue as a matter of technical judgement.  I'll highlight a point 
from Section 3:

   "Remember, if the objector feels that the issue is so essential that it
    must be attended to, they always have the option to file an appeal."

There are very few people who exercise that option.

According to the title of Section 4 humming should be the start of a 
conversation, not the end.  BCP 25 states that:

   "Consensus can be determined by a show of hands, humming, or any
    other means on which the WG agrees (by rough consensus, of course)."

I am not sure whether hums are for a starting point or not.  It can 
be argued in different ways, for example, see Section 4.  Humming 
helps to get a sense of the room without people making a decision 
under duress.  It is a useful way to resolve a controversy.  I would 
say that it ties in Section 5, i.e. consensus is the path, not the 
destination.  A show of hands is a disguised way to vote [4].

Section 5 identifies a few issues with the way people talk about 
"consensus".  I understand what Pete Resnick wrote as he has 
explained that to me in an unrelated discussion.  The text discusses 
about "making the call".  I don't know whether the reader will easily 
understand the meaning of that.

Section 6 and Section 7 attempt to explain that a high percentage of 
votes in a direction does not necessarily mean that there is rough 
consensus for that.  I agree with the conclusion in Section 8.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ietf/current/msg82843.html
2. http://tools.ietf.org/html/draft-moonesamy-consensus-00
3. http://www.ietf.org/mail-archive/web/isms/current/msg00943.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg25014.html