Re: Hum theatre

Larry Masinter <masinter@adobe.com> Thu, 07 November 2013 03:21 UTC

Return-Path: <masinter@adobe.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 C13B811E813F for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2013 19:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.478
X-Spam-Level:
X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SXLIFE=1.07, SARE_UNSUB22=0.948]
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 YdN5t+61-jJ8 for <ietf@ietfa.amsl.com>; Wed, 6 Nov 2013 19:21:10 -0800 (PST)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2319211E822D for <ietf@ietf.org>; Wed, 6 Nov 2013 19:21:09 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUnsHGecruKLNYFNoCmkz3PGvWt0NVbUj@postini.com; Wed, 06 Nov 2013 19:21:10 PST
Received: from inner-relay-2.corp.adobe.com (inner-relay-2.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA73KtWY023931; Wed, 6 Nov 2013 19:20:56 -0800 (PST)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA73KtOU006488; Wed, 6 Nov 2013 19:20:55 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 6 Nov 2013 19:20:54 -0800
From: Larry Masinter <masinter@adobe.com>
To: "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Date: Wed, 6 Nov 2013 19:20:53 -0800
Subject: Re: Hum theatre
Thread-Topic: Hum theatre
Thread-Index: Ac7bYGAdS1a8KXsSR0SgLD5Q69wJhwAB/2kd
Message-ID: <5hgi1gn93unue26c25rsu5nw.1383794453562@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5hgi1gn93unue26c25rsu5nw1383794453562emailandroidcom_"
MIME-Version: 1.0
Cc: IETF Discussion <ietf@ietf.org>
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: Thu, 07 Nov 2013 03:21:15 -0000

An IETF hum is better used as a method for building a community consensus, by showing outliers the strength of other opinions.

As such it is important theatre. As a method of assessing opinions, it isn't very good, for many of the reasons cited.

Larry
http://larry.masinter.net


Dave Crocker <dhc@dcrocker.net> wrote:

Folks,

An IETF hum is a method of surveying a group for its views.
Unfortunately the hums that were taken at the end of this week's IAB
plenary do not permit any meaningful interpretation.


Here's why...

Surveys are extremely sensitive to the phrasing of the questions, the
phrasing and range of the response choices, the sequencing of the
questions, and the context of the asking.  Get any of these wrong and
you can get the wrong information, or even just the appearance of
information -- that is, misunderstandings -- but nothing actually useful.

A common response to such a concern is "well, at least we'll get some
answers", but that's like saying "well, at least we'll get some noise."
  The fact that the noise is misunderstood to be signal does not
actually make it signal.



The different phrasings of a question can produce very different
understandings by responders.  The challenge is to formulate a question
that is likely to be interpreted similarly amongst responders (and the
person asking.)  It's also a challenge to ask a question that captures
something that is actually meaningful (and was intended) rather than
merely sounding good.

The offered response choices can bias the responses.  A set of choices
like (Good, Excellent) obviously leaves out (Bad, Don't Care, Don't
Know.)  Or they can have bias in their phrasing by making some choices
more or less appealing (Could be better, Excellent), rather than
equivalent vocabulary in tone (Bad, Good).  So it's a challenge to make
sure that choices cover the proper range and with equanimity to the
alternative choices.

A sequence of questions also needs to be carefully orchestrated.  For
example today's questions took as a given that surveillance is an
attack.  Due diligence might expect establishing that relationship
explicitly.  And yes, it is possible that some IETF attendees do not see
it as an attack.  Another example of sequencing is dealing with
subtleties and complexities.  For example some anti-surveillance
mechanisms are certain to defeat popular operational management
mechanisms.  Do we care about the tradeoffs?

Lastly, environmental context can encourage or discourage candor.
Examples include the genders of the asker and respondent, any
relationship they might have, or the presence of others.  Would you
really provide candid answers about possible problems with your sex life
when being asked with your partner present?  Amongst a group of
co-workers?  Your parents?



The hums asked at the plenary were problematic along each of these lines.

The first question was theatre, essentially making the context
political.  By way of example, note the difference between what was asked:

      The IETF is willing to respond to the pervasive surveillance attack?

which has loaded language with 'pervasive' and 'attack', versus a more
neutral and purely technical question meant to cover the same basic concern:

     The IETF is willing to improve its specifications to be more
resistant to surveillance?

But this isn't exactly a balanced question either.  By that, I mean that
the answer really is already known.  A good question is one that has a
chance of getting some support for each choice.  So perhaps a better
example would be:

      The IETF is willing to require adding resistance to surveillance
to all of its protocols?

The questions typically also did not offer "don't know" or "don't care"
choices.  Some folk probably knew that they don't know enough yet,
limiting their ability to support the kinds of questions being asked.

The IETF's doing anything privacy-related that is useful is going to
require considering tradeoffs and some of those tradeoffs might reduce
the utility of a service. So the actual choices that will be made might
turn out to be quite different from what was implied by the dominant
answers to the plenary questions.

And lastly, consider carefully the context of the room and ask whether
everyone actually felt completely free to give a "no" hum to the initial
questions.  I suggest that the emotions of the room created a strong
bias against no's.   Maybe not for you.  Maybe not for me.  But probably
for many of the folk sitting near you.

We now find ourselves with a set of hums that appears to establish a
direction but which can't survive even basic analysis, as the later
postings on the ietf mailing list demonstrate.



Here's what I suggest:  A single, simple, conceptual question that
supplies all of the 'guidance' we can legitimately offer, at this stage:

      The IETF needs to press for careful attention to privacy
      concerns in its work, including protection against surveillance.

           [ ]  No
           [ ]  Yes
           [ ]  Don't Yet Know
           [ ]  Don't Care



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net