Re: Observations on (non-technical) changes affecting IETF operations
George Michaelson <ggm@algebras.org> Tue, 22 March 2016 01:51 UTC
Return-Path: <ggm@algebras.org>
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 55E9812D0E1 for <ietf@ietfa.amsl.com>; Mon, 21 Mar 2016 18:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 TU28vIvLLaTl for <ietf@ietfa.amsl.com>; Mon, 21 Mar 2016 18:50:54 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB6C12D62A for <ietf@ietf.org>; Mon, 21 Mar 2016 18:50:49 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id r187so158617325oih.3 for <ietf@ietf.org>; Mon, 21 Mar 2016 18:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-transfer-encoding; bh=ha07j4FymJhDkYcIKfQxpCRQP2lERvPWQBkVlfD4Ae4=; b=oAixYw8cfwvhp7u9selKOBgfI0E+bKLZRMyU80qyaf1xuUgAejRcXaNvOsWltS7TSs xeU5c3gEWU4GlduU01E1GK/nLGpgboP7dNmN2Xq5IPUn8f7NocsT4lqYtZPIN628UkgR b+NFHjS3sN8cvBuMAzELZCqlos0YrQIKca/8NlAbIt9+SKyS9HlJTWCKC+gf4Mw0klT5 UUuL0193Jk8fxYDFP/7zRVCQsEzU9YeZ2g7rQxSWmJY4ccAZa+RQNkLEwMSTOoIn/Q2v p1+W23tRSXAU76Dhztp/vS4hgELphoG7g8PacXXO9hli8XlgGeokJWi8GLS1O/05W/xL yPVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-transfer-encoding; bh=ha07j4FymJhDkYcIKfQxpCRQP2lERvPWQBkVlfD4Ae4=; b=QqysOIpb7ewx+h81JLD40tpIEUzdL15mIMXqIRS7A6z8JpwKjL1ehwDcYqnvDxLi9F BGEp/ZdXWQBKDZzSnNtHdwoaYz3el8SyyMkkQF5WV85qpBcvCi1YSp6xumKUE/k8uUGj sTJV4PQ+Bs99A5p/vQBQxIKBmKbDsSomGlWC36HkIlsUm8E6poXlHJZ/X9+BM2FOmxQ2 iO6VTHeOvfZ0rWoDvlQQ5Tfjs9hZ2Qced2Q2mc/XpQcdLGUEA5BPbIV7Ba2zgZXC+xHN cbzB95pME8x1LhlQgoyxuZw96mkS5+jrHPGf/TNYR88vPpLPYrIySFIpxz+3K2Q0C7l5 LKDQ==
X-Gm-Message-State: AD7BkJK7xLBT0/6X3cdn5GC0b9NHJtkEPvcbDrNX1fm+DppuoatVhh2fcrU1DNpOivfanFgwgmNdZHj4zKoGpw==
MIME-Version: 1.0
X-Received: by 10.202.59.137 with SMTP id i131mr18843329oia.62.1458611448637; Mon, 21 Mar 2016 18:50:48 -0700 (PDT)
Received: by 10.182.187.97 with HTTP; Mon, 21 Mar 2016 18:50:48 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:c904:ab6c:482b:322b]
In-Reply-To: <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> <DB4PR06MB457A17F9C3E428860347A24AD800@DB4PR06MB457.eurprd06.prod.outlook.com>
Date: Tue, 22 Mar 2016 11:50:48 +1000
Message-ID: <CAKr6gn2XhETqsMdKgBUocMtqZf7e9Wq-y19qsFRCrrffSKrnpA@mail.gmail.com>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
From: George Michaelson <ggm@algebras.org>
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dDiKQjJ8w0G8xZX_pxyEKc2pg0M>
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:51:00 -0000
The concrete counter-instantiation of why new groups might need to be spun up to reconsider old problems, might be the textual Subject: why your proposal to fix spam will fail [check applicable] message, with a list of instances of: [x] "because we tried this before and it failed" [x] "because it cannot scale" [x] "because all known algorithms which satisfy your condition are infeasible" reasons. Basically, its a variant of the appeal to authority: prior experience in the IETF is not always a good indicator of future experience, because O(hard) problems are a function of both algorithms and Moore's law, and are subject to change. Obviously, where the message retains its authority, unappealling or otherwise, is the implicit: [x] "because we don't like this class of solution and it has no chance of getting adopted" In this list (regarding SPAM but more generally) On Tue, Mar 22, 2016 at 11:03 AM, <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!' > > 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. >
- Getting off Things - namely this mailing list tom p.
- Observations on (non-technical) changes affecting… Jari Arkko
- RE: Observations on (non-technical) changes affec… Linda Dunbar
- Re: Observations on (non-technical) changes affec… Jari Arkko
- RE: Observations on (non-technical) changes affec… Dave Cridland
- Re: Observations on (non-technical) changes affec… Randy Bush
- Re: Observations on (non-technical) changes affec… Melinda Shore
- Re: Observations on (non-technical) changes affec… Joel M. Halpern
- Re: Observations on (non-technical) changes affec… Rich Kulawiec
- Re: Observations on (non-technical) changes affec… Stephen Farrell
- Re: Observations on (non-technical) changes affec… Randy Bush
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Security for the Internet of Things and Other Thi… Jari Arkko
- RE: Observations on (non-technical) changes affec… Dirk Kutscher
- Re: Observations on (non-technical) changes affec… Jari Arkko
- Re: Observations on (non-technical) changes affec… Michael Richardson
- Re: Security for the Internet of Things and Other… Michael Richardson
- Re: Security for the Internet of Things and Other… Carsten Bormann
- Getting on with Things Eliot Lear
- Re: Security for the Internet of Things and Other… Theodore V Faber
- RE: Getting on with Things Adrian Farrel
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Stewart Bryant
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Stewart Bryant
- Re: Getting on with Things Eliot Lear
- Re: Observations on (non-technical) changes affec… Brian E Carpenter
- Re: Getting on with Things Michael Richardson
- Re: Getting on with Things Carsten Bormann
- Re: Getting on with Things Medel Ramirez
- Re: Security for the Internet of Things and Other… Phillip Hallam-Baker
- Re: Getting on with Things Gmail
- Re: Security for the Internet of Things and Other… Livingood, Jason
- Re: Security for the Internet of Things and Other… Scott Kitterman
- Re: Security for the Internet of Things and Other… Eliot Lear
- Re: Security for the Internet of Things and Other… Stewart Bryant
- Re: Observations on (non-technical) changes affec… Charles Eckel (eckelcu)
- Re: Observations on (non-technical) changes affec… Dave Crocker
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… Jari Arkko
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… Charles Eckel (eckelcu)
- Re: Observations on (non-technical) changes affec… l.wood
- Re: Observations on (non-technical) changes affec… George Michaelson
- Re: Observations on (non-technical) changes affec… Eggert, Lars
- Re: Observations on (non-technical) changes affec… Phillip Hallam-Baker
- Re: Observations on (non-technical) changes affec… lloyd.wood
- Re: Observations on (non-technical) changes affec… Eggert, Lars
- Re: Observations on (non-technical) changes affec… S Moonesamy
- Re: Observations on (non-technical) changes affec… Joseph Lorenzo Hall
- Re: Observations on (non-technical) changes affec… Joseph Lorenzo Hall
- Re: Observations on (non-technical) changes affec… S Moonesamy
- Re: Observations on (non-technical) changes affec… Randy Bush
- RE: Observations on (non-technical) changes affec… Russ White
- Re: Observations on (non-technical) changes affec… Melinda Shore
- Re: Observations on (non-technical) changes affec… Eliot Lear