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

Eliot Lear <lear@cisco.com> Mon, 28 March 2016 08:15 UTC

Return-Path: <lear@cisco.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 E933712D71D for <ietf@ietfa.amsl.com>; Mon, 28 Mar 2016 01:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wBdksljDc73i for <ietf@ietfa.amsl.com>; Mon, 28 Mar 2016 01:15:08 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577B912D71A for <ietf@ietf.org>; Mon, 28 Mar 2016 01:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3069; q=dns/txt; s=iport; t=1459152908; x=1460362508; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=B/1F9jYB4FH7FctmKGXey7qGdOcSJjL0SzzCja4RpUE=; b=Dsly0I6z5oqHisY8ULAI44Jo08KUcARccawEJuVgwvP6pix6Pys4Iizc MCFXIf3fKfmg3Z43KgQORWI2Ms0gOjHY06Vlia6ajuOtwktdULYfRTKVP hqJbKUR+LmQTRW96xiGMgxc2/SplKaSCJWNWEuHv8Br7MGev1mZseCpqz w=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgCy5vhW/xbLJq1bvVuCDw6BcIYNA?= =?us-ascii?q?oFWFAEBAQEBAQFkJ4RCAQEEI1URCxgJFgsCAgkDAgECAUUGAQwIAQEQiBOvc5A?= =?us-ascii?q?VAQEBAQEBBAEBAQEBARIIimKHPIJWAQSXYYMegWaJAok3hVSPCx4BQ4NnOokGA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.24,405,1454976000"; d="asc'?scan'208";a="633750908"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2016 08:15:05 +0000
Received: from [10.61.64.55] (ams3-vpn-dhcp55.cisco.com [10.61.64.55]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2S8F5hv001717; Mon, 28 Mar 2016 08:15:05 GMT
Subject: Re: Observations on (non-technical) changes affecting IETF operations
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>
From: Eliot Lear <lear@cisco.com>
Message-ID: <56F8E809.5050208@cisco.com>
Date: Mon, 28 Mar 2016 10:15:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EDAC9F.6060109@dcrocker.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TABXxvDcTvXsW9gaTdr6kOjaSenL8iq8O"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/B3ZrBi_3H6-MQEwyx2Stw0j7JEY>
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: Mon, 28 Mar 2016 08:15:10 -0000

Hi Dave,

On 3/19/16 8:46 PM, Dave Crocker wrote:
>
>      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 not so straight forward as one might think.  Some markets are
quite complex and some will stall or fragment without standards, even if
the key players in those spaces know nothing of the IETF.  I think in
these circumstances it's incumbent on the IESG to be perceptive and
reach beyond our normal community to take a "best guess" as to what is
needed.  IMHO this is the case with ITS, for example.

Sometimes the guesses will be wrong, and we should simply allow for some
efforts that may not succeed.  So long as those are the exception and
not the rule, we're in a good space.
>
>      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.
>

Indeed.  And there are many dimensions to that fear.

Eliot