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.
- More haste, less speed. Phillip Hallam-Baker
- Re: More haste, less speed. Viktor Dukhovni
- Re: More haste, less speed. Phillip Hallam-Baker
- Re: More haste, less speed. Viktor Dukhovni
- Re: More haste, less speed. Gary E. Miller
- Re: More haste, less speed. Viktor Dukhovni
- Re: More haste, less speed. Joe Touch