More haste, less speed.

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 06 March 2017 16:27 UTC

Return-Path: <hallam@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 74E741297CE for <ietf@ietfa.amsl.com>; Mon, 6 Mar 2017 08:27:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 0yquRdZnto2I for <ietf@ietfa.amsl.com>; Mon, 6 Mar 2017 08:27:29 -0800 (PST)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 C860E129540 for <ietf@ietf.org>; Mon, 6 Mar 2017 08:27:28 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id p77so124374794ywg.1 for <ietf@ietf.org>; Mon, 06 Mar 2017 08:27:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=MWMBfFWkgVbw5+mI44Fgw2JGEB/EonQRudsa5sxXFds=; b=OajLqIFqh3DhCGJkRlzqsBoZ3cRt8Tn+7gzotHZ4kgmXuLpYHl0bHiB7c33LRPs9Pu Y2kCLTxSGivjJsExOiNk3lTYFO9uIGnQOLb6lz2rAOCKVYvQYcyBKEkXgoTgC2lNiBIa ygqTbsl3j0syRDR119WZ60BAnecabqHAZMtlltT7Dm/yJvQzmdKFezcuPLOeq4mxjMzH h4HQU64Zae8YHa5NbffnsoM9Hv195Tg7XdACn+jY5/EYeCL6nsmMQKPTTcVt5r8MmRyy Xvd8SVk+nhVeRW1rqdxHMCVl/MROjLnwfw/rzjkPEUxP4PiTamEsV2+Siyo/D07iXOZf /H/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=MWMBfFWkgVbw5+mI44Fgw2JGEB/EonQRudsa5sxXFds=; b=OkU4hKN7aGbqRZCemsk4e9PQfhGoo5Sk/W6BHSY+PnGZBAiJHI8eNNLwCJP0lZDOj9 +PlxgEpvlvu/gk/SeriLBxiDM9bYS18+R1OcX5Fcv7dqBxGSooXO0CAM+QRxN7KOfCnL P9c6j7sCjIo8YBp1YTvgB0lr9Q4/LRU8qddLJeq4SGUq7uI/NdU0+x6CFgZk+KUyeH/c AFm00S/neowp3e59G0+7/1BMvriEBLt0FK0EdgtCTtHv5PZPvRRzahuUBEhzSQDAp3L5 nYmybpYW3GIEIHqx9ff+1E0eMFBVJnzKhZj1prVLBvMAkEa2SdMWRjsyj/t19NcX30nU 0hqA==
X-Gm-Message-State: AMke39nBfLU8i1aww892nHXYDWBz0bFxveqs/aZfqcNL7sOsUsNtW0Dk97Q5MgkCMF7AcqWl8dboSjtgp27yJw==
X-Received: by 10.129.172.25 with SMTP id k25mr11766366ywh.165.1488817647873; Mon, 06 Mar 2017 08:27:27 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.83.19.20 with HTTP; Mon, 6 Mar 2017 08:27:27 -0800 (PST)
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 06 Mar 2017 11:27:27 -0500
X-Google-Sender-Auth: H3axGI5X-E2tDdkuc8haw503GFM
Message-ID: <CAMm+Lwg1dvzMSKbWwoF0V6ZM5Q5_WVYxvpV=4_u=T0OTjCPxPQ@mail.gmail.com>
Subject: More haste, less speed.
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1badfc097287054a125fab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2dz58rAAm7-r07JvhvP3W7XantI>
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, 06 Mar 2017 16:27:30 -0000

Specifications are moving through IETF faster than ever. Rarely is the
question asked, is this actually a good thing.

The specific reason for raising this topic is a complaint on the DNSops
list about large public resolvers failing to support DPRIV. But that is not
the only example of what I see as an anti-pattern for standards development.

1) A group identifies a security need

2) Asserting that the need is urgent and the very most important thing is
speed, a draft is cobbled together that meets the functional requirements
the group has identified.

3) Deployment stakeholders point out the practical problems they would face
implementing the draft in the current form.

4) The objections are brushed aside because of the urgent need for speed.

5) A couple of years later the draft is published as an RFC

6) A couple of years later, it is noticed than none of the essential
stakeholders have deployed.

7) Attacks on the stakeholders' lack of interest in security, gaslighting
of the individuals who raised the blocking deployment issues.

8) Further attempts to address the issue are blocked because 'what needs to
happen' is deployment of 'the standard'

9) Those people who point out that this behavior is problematic are cast
out from the tribe.

This isn't just one isolated incident. It is now a firmly established
pattern. I have seen it happen on three separate projects in the DNS area
alone. First with DNSSEC, then with DANE and now with DPRIV. And there are
real costs.

DNSSEC was deployed in .com for almost a decade late because of the refusal
to fix the NXT record issue. As a result, we lost a critical window where
deployment would have been a lot easier than it became.

DANE conflates publication of security policy with public key validation
and distribution.

And now we have DPRIV which is built with no regard for the architectural
constraints of running the large public DNS resolvers whose adoption is
essential for success.

Every time I point out that the same group of individuals are engaging in
the same behavior that caused their last proposal to fail, I am accused of
trying to re-fight old battles and what we all need to do is to ram this
next RFC through the process as fast as we possibly can because this time
we really need to do it fast.


What concerns me here is not so much the waste of time but the fact that as
long as there is a purported standard meeting some need, its existence and
failure to achieve adopted blocks attempts to solve the problem in ways
that could be acceptable to the deployment stakeholders.

So what I propose is a mechanism to formalize the raising of deployment
objections. The basic idea being that is a group decides to behave this way
and the IESG decides to let them, the fact that their proposed solution
fails to meet what key stakeholders assert are show stopper deployment
issues is noted. If the WG then produces a specification that fails to
achieve deployment, the existence of the objections can then be taken into
account when considering chartering a new group.