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

"Eggert, Lars" <lars@netapp.com> Tue, 22 March 2016 10:02 UTC

Return-Path: <lars@netapp.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 0394512D538 for <ietf@ietfa.amsl.com>; Tue, 22 Mar 2016 03:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kGhOfLr-n_Uy for <ietf@ietfa.amsl.com>; Tue, 22 Mar 2016 03:02:22 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC19D12D1B8 for <ietf@ietf.org>; Tue, 22 Mar 2016 03:02:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,376,1455004800"; d="asc'?scan'208";a="100987132"
Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 22 Mar 2016 03:02:03 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 22 Mar 2016 03:02:03 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::c07c:8fcd:f7e4:f32b%21]) with mapi id 15.00.1156.000; Tue, 22 Mar 2016 03:02:02 -0700
From: "Eggert, Lars" <lars@netapp.com>
To: "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
Thread-Topic: Observations on (non-technical) changes affecting IETF operations
Thread-Index: AQHRcz0kIP0RMK4ZLEex0nr7tB39eJ9ReSAAgBHI5wCAAUW0AIAAE44AgACgz4CAAJaHgA==
Date: Tue, 22 Mar 2016 10:02:02 +0000
Message-ID: <B32FDEA7-D224-4CE9-9315-D5413FEC572E@netapp.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> <DB4PR06MB457A17F9C3E428860347A24AD800@DB4PR06MB457.eurprd06.prod.outlook.com>
In-Reply-To: <DB4PR06MB457A17F9C3E428860347A24AD800@DB4PR06MB457.eurprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.120.60.37]
Content-Type: multipart/signed; boundary="Apple-Mail=_A46F0336-D1A7-4C80-A65E-40E02386D401"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ZfR5qUkmkfE2d9CoJHjaI8gTJMU>
Cc: "phill@hallambaker.com" <phill@hallambaker.com>, "ietf@ietf.org" <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 10:02:27 -0000

On 2016-03-22, at 2:03, l.wood@surrey.ac.uk wrote:
>> 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!'

No, it doesn't "hold for the IRTF." Please don't generalize from your dislike of the DTNRG's bundle protocol to the DTNRG as a whole, and then to the entire IRTF.

Lars