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

"Russ White" <7riw77@gmail.com> Sun, 27 March 2016 11:33 UTC

Return-Path: <7riw77@gmail.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 26CD612D186 for <ietf@ietfa.amsl.com>; Sun, 27 Mar 2016 04:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Level:
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=gmail.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 qgOjbcKjDXmg for <ietf@ietfa.amsl.com>; Sun, 27 Mar 2016 04:33:31 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 662CA12D169 for <ietf@ietf.org>; Sun, 27 Mar 2016 04:33:31 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id o6so78880732qkc.2 for <ietf@ietf.org>; Sun, 27 Mar 2016 04:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=w1ExdaQiH2dpvpe9Y354AyxGfjRoFqe2JuVXpgkI+7Y=; b=Y7GRdQ6kyzPn1LhTQiawyLtjtYCec+atwmIC/qe8suShskgk2j6O3IIcshRYNK8wC8 VYoCm5A/lVkbt6r16hPm8h0hq2EPW91OIdK4p22FyY4PtIQihvZDewL/GcDl1bgzgNop 54+PkBBRHKMI/MBSLMIki6NqSwxYca8GOQU7cS3yX0FMLf1qw5DmlGGexzWKSMcAwmnE AUT9MZEEk27pZQpX6MQ+qqLFOgOjepxO+VRIVhcE3XlTffFnEezRHN6bw07w8XbCpvgf J+3CBBoD8Goc7QEhJ4rGQgiHfei8qhQjkgKdnmZeOYwCeTG+Dm65Xp7rilpWdcGj7MY7 zAMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=w1ExdaQiH2dpvpe9Y354AyxGfjRoFqe2JuVXpgkI+7Y=; b=DCvE18IQP+KXwVHwgNLe40wCCaGd/H9VjMI90V8VTvli72DK5Pmf8tRAdalXzAdCTT Wp1v9QtJ7uiIEjVHA/S0gygLJaw6ba8YLeGHJ80gIX0Wwq5VfGNA6D2qcgrjY6djqi+I 84+WtqoELv3bx6ljeuooEhAPgR0sVsiCA+mQIMJvjI+gQFp5GHzMYCgYusY4nNwdwhXu lIk//Bp1ZJmiPGapWFR9GXM3tcufMiYaT8XdEx4pMfuK/cnZWf3UilWeNlItPlLEvWcw XFcODx9PTeP2WMnmTDtA+LxkzEO5vq1coakVFNjgt3rah+Mv1yDDBt7itB+slfDyU6La gbUg==
X-Gm-Message-State: AD7BkJKGMcD7BPOiCYQ/7UiTKWcqsfIxrWWua4N2yrNqm+0E6qd5vPk+hJnpHopBSLjJNg==
X-Received: by 10.13.232.75 with SMTP id r72mr10945383ywe.2.1459078410485; Sun, 27 Mar 2016 04:33:30 -0700 (PDT)
Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id l9sm5376173ywb.27.2016.03.27.04.33.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Mar 2016 04:33:29 -0700 (PDT)
From: "Russ White" <7riw77@gmail.com>
To: <dcrocker@bbiw.net>, "'Melinda Shore'" <melinda.shore@gmail.com>, <ietf@ietf.org>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <4A95BA014132FF49AE685FAB4B9F17F657DF2330@dfweml701-chm> <EDFB7D0B-2A49-46BD-A84C-0E1FA07793FA@piuha.net> <m2lh5veycu.wl%randy@psg.com> <56DD0309.9050701@gmail.com> <56EDAC9F.6060109@dcrocker.net>
In-Reply-To: <56EDAC9F.6060109@dcrocker.net>
Subject: RE: Observations on (non-technical) changes affecting IETF operations
Date: Sun, 27 Mar 2016 07:33:15 -0400
Message-ID: <038a01d1881c$747a50d0$5d6ef270$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGhgxqXYG63e7RGVllMOFy0inZeNgFhbnDfAZcRvcUCPiVbxQE3+BdSAgMwXvafiZ/ZkA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ogJSDOGu1a558TCIY0fkBRcECCo>
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: Sun, 27 Mar 2016 11:33:33 -0000

>       1. When we start an effort, we do not press for demonstrated
community
> need -- but more importantly, demonstrated community interest in /using/
> the output.  So the folk who work on a topic tend to have no sense of
> urgency.  (Even when there is a claimed sense of urgency, such as for
STIR,
> the work often is not pursued in a fashion that matches the claim, with an
> eye towards rapid development and deployment.)

This is certainly true... 

But I think there is a second reason in this neighborhood that also relates
to this one --

>       2. The folk making IETF approvals feel an unfortunate fear of
letting
> flawed specifications through the process, even though the fear does not
> produce obviously superior results.  So we impose high barriers to entry
and
> high barriers to completion.

We've lost the art of base spec -- leave other stuff to later. Maybe I'm
just being nostalgic, but I seem to remember a time when we would pass
through a base protocol with extensibility, and then start talking about
extensions on a case by case basis. Now we seem to see 15-20 drafts proposed
in a few months, all with interlocking bits and pieces, totaling hundreds of
pages of text, and sounding more like a bill being presented before some
legislative body rather than a technical specification. These large scale
"boil the ocean" efforts constructed (apparently) by off line meetings
outside the mailing list and the "normal process," are challenging (to say
the least) to even read, must less to fully participate in. When someone
does try to discuss one of these monstrosities on list, the reply is either
"you're stupid," or "you didn't really read all the drafts," or some such,
shutting the discussion down. Of course no-one has really read the drafts --
they're essentially unreadable, and they describe a system of massive
complexity that few people probably understand -- even the authors. I'm
certain each author understand some small bit, but the overall system is far
too complex to be understood by anyone who doesn't have time to dedicate
themselves full time for several weeks to understand it.

This doesn't "improve the speed," as some folks claim--biting off smaller
chunks would actually be faster, as it would increase community
participation, and help us to drive simpler specifications that people
outside the IETF could actually read and understand. If we could get out of
the habit if "boiling the ocean," then we could, possibly, get back to doing
simple things quickly in a serial fashion with a lot of participation. What
we seem to be doing, instead, is a lot of large scale systems that often
overlap in parallel with specifications so complex and so poorly written
that we don't have high overlapping participation rates, which means speed
and innovation suffer, and quality creeps towards atrocious.

At least that's my view of the process at this point.

What we have on the speed front is a culture issue as much as anything else.

:-)

Russ