Re: Observations on (non-technical) changes affecting IETF operations

<l.wood@surrey.ac.uk> Tue, 22 March 2016 01:03 UTC

Return-Path: <l.wood@surrey.ac.uk>
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 07AF212D5B9 for <ietf@ietfa.amsl.com>; Mon, 21 Mar 2016 18:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=surreyac.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt_4Nuc5Yjq2 for <ietf@ietfa.amsl.com>; Mon, 21 Mar 2016 18:03:19 -0700 (PDT)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E312D52A for <ietf@ietf.org>; Mon, 21 Mar 2016 18:03:19 -0700 (PDT)
Received: from [193.109.255.147] by server-8.bemta-14.messagelabs.com id 01/62-03645-5D990F65; Tue, 22 Mar 2016 01:03:17 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-8.tower-72.messagelabs.com!1458608597!18142888!1
X-Originating-IP: [131.227.200.43]
X-StarScan-Received:
X-StarScan-Version: 8.11; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29850 invoked from network); 22 Mar 2016 01:03:17 -0000
Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-8.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 22 Mar 2016 01:03:17 -0000
Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 22 Mar 2016 01:03:16 +0000
Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.200.4) by EXHY021v.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 22 Mar 2016 01:03:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surreyac.onmicrosoft.com; s=selector1-surrey-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CfeenQMiVHX86b2GZk2lYcUw7crWl1n1HWnuXjFbNbk=; b=WFx/auDVjEmg+eqwSDzEDP/7MOetKvH+OrA8DII2GAns2yZ+rRvBERVh2PlbK0HEbU+pHqeeIjqYeHVatsWCtOrZpvDA9pIrn6YZ3TY2DCVx2H+B5sW0QNsQMT+KYeNKyV78hrmLLUOyA4HxQXSsbT7LKWcz6SAGahTdiP7BBUQ=
Received: from DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) by DB4PR06MB460.eurprd06.prod.outlook.com (10.141.238.24) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 01:03:15 +0000
Received: from DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) by DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) with mapi id 15.01.0443.014; Tue, 22 Mar 2016 01:03:15 +0000
From: <l.wood@surrey.ac.uk>
To: <phill@hallambaker.com>, <jari.arkko@piuha.net>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
Thread-Topic: Observations on (non-technical) changes affecting IETF operations
Thread-Index: AQHRcz0wlfMBQBJlIkqfbuGGxGcwj59Q8wQAgBHZqgCAAUW0AIAAE44AgACfYig=
Date: Tue, 22 Mar 2016 01:03:15 +0000
Message-ID: <DB4PR06MB457A17F9C3E428860347A24AD800@DB4PR06MB457.eurprd06.prod.outlook.com>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <82AB329A76E2484D934BBCA77E9F5249A9FA6A7F@PALLENE.office.hd> <CAMm+Lwh+eY4miBH6n2ttwz00ypx9tVv0A4rM2v=VMQi6LH1h+w@mail.gmail.com> <DC437F67-52A1-4319-87D0-0499C9493983@piuha.net>, <CAMm+LwiegpHeEVz-7ZONOgwDoyPypkDv7x5fa3c8CrarO+UcMw@mail.gmail.com>
In-Reply-To: <CAMm+LwiegpHeEVz-7ZONOgwDoyPypkDv7x5fa3c8CrarO+UcMw@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.192.208.66]
x-ms-office365-filtering-correlation-id: df885bc3-dd4b-46e3-8f13-08d351edbffa
x-microsoft-exchange-diagnostics: 1; DB4PR06MB460; 5:pRDwU4UytrB7ve983eBnpZbIqGRn6AY2aPsxKZ6rzw7gWtT2NoMqQ7i5IJfkF5X8095OlWLQ5XlbPT3nHp8GKXWkvoPiGXsmJpc+muKGx+8n56jhNFyBmT/d6cCzgQU+N28RomysI9HVil506uHb+g==; 24:c2c5IIA4YSEfHrP8iIo5r5CYqldv8VW7g0g0V9dqSO2fbVyeyNLf0zGyULv9P84V0rSh0rv9ROmbCPj1+nsT1YFXrCFKpg9yI22I2D6ezy0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB460;
x-microsoft-antispam-prvs: <DB4PR06MB4606C3249F7974981C97BF4AD800@DB4PR06MB460.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB4PR06MB460; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB460;
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(76576001)(33656002)(561944003)(19580395003)(122556002)(4326007)(93886004)(3900700001)(5004730100002)(5003600100002)(19580405001)(6116002)(2906002)(74482002)(3660700001)(3846002)(102836003)(1096002)(586003)(1220700001)(10400500002)(3280700002)(2900100001)(2950100001)(87936001)(77096005)(5001770100001)(86362001)(5008740100001)(189998001)(15975445007)(106116001)(54356999)(92566002)(81166005)(11100500001)(50986999)(5002640100001)(66066001)(76176999)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB460; H:DB4PR06MB457.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 01:03:15.8402 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB460
X-OrganizationHeadersPreserved: DB4PR06MB460.eurprd06.prod.outlook.com
X-OriginatorOrg: surrey.ac.uk
X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk
X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/B86VDizZfflK1xjv6V1BcQBM-RA>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Mar 2016 01:03:22 -0000

> The mode of failure I keep seeing in IETF is the following:
> 
> 1) A very narrow scope is decided 'to focus'
> 
> 2) Poorly thought out aspects of the proposal are defended because the
> problems they cause are 'out of scope'
>
> 3) The resulting RFC describes a protocol that is worse than useless.
>
> 4) The proposal fails in the market.
> 
> 5) The experience is used as 'proof' that the problem is insoluble. (optional)

This holds for the IRTF too - though step 5 there is 'let's form an IETF workgroup to push it into adoption! This time for sure!'

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: ietf <ietf-bounces@ietf.org> on behalf of Phillip Hallam-Baker <phill@hallambaker.com>
Sent: Tuesday, 22 March 2016 2:27 AM
To: Jari Arkko
Cc: IETF
Subject: Re: Observations on (non-technical) changes affecting IETF operations

On Mon, Mar 21, 2016 at 10:17 AM, Jari Arkko <jari.arkko@piuha.net> wrote:

> Yes, but I would approach this from a slightly different end-point. It is always the case that convincing others of something new is a lot of work. In my mind, standards or open source work both succeed best when performed by those who actually are deploying and in charge of building mainstream systems (commercial or open source) for the topic. So it is not so much about IETF folk reaching the adopters, but having the adopters drive the IETF work…
>


One of the problems I see is that 'consensus' is wielded as an input
to the process rather than being the output.

People are already telling me that there is 'no consensus' for my
proposal for the LURK BOF. How on earth is there supposed to be
consensus if we haven't even met yet?

The mode of failure I keep seeing in IETF is the following:

1) A very narrow scope is decided 'to focus'

2) Poorly thought out aspects of the proposal are defended because the
problems they cause are 'out of scope'

3) The resulting RFC describes a protocol that is worse than useless.

4) The proposal fails in the market.

5) The experience is used as 'proof' that the problem is insoluble. (optional)


What should be obvious, I hope, is that the narrower your scope, the
narrower the appeal of your solution.

The risk in considering a wide scope is that the solution becomes
overly complex. But it can also make the solution simpler by forcing
the designers to consider what the fundamental issues are and deal
with them in a modular, extensible fashion.

I have a proposal:

* Use cases are not subject to consensus calls.
* Requirements derived from the use cases are.

What I want to use a specification for is really none of anyone else's
business. When a person proposes a use case, what they are essentially
saying is 'this is what the specification has to do if you want my
support'. So why should that be subject to a consensus requirement?

During the SAML design, there was a working group on use cases that
spent a lot of time voting on use cases. Some of the work was useful
in that it did help clarify what the use case was. But the time they
spent arguing over whether given use cases were in or out was a total
waste of time because I was writing the architecture specification and
I made sure that I could meet every use case anyone ever proposed.

In design, I actually find the more absurd use cases turn out to be
the most useful because they can lead to a different way of thinking
about the problem.