Re: deprecating Postel's principle- considered harmful

"Martin Thomson" <mt@lowentropy.net> Wed, 08 May 2019 02:17 UTC

Return-Path: <mt@lowentropy.net>
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 1AE2012002E for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 19:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_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=lowentropy.net header.b=IB+Zsbxt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yiapp5Ap
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 zQKRQUZOFFbR for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 19:17:38 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31904120073 for <ietf@ietf.org>; Tue, 7 May 2019 19:17:38 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 833C9239B8 for <ietf@ietf.org>; Tue, 7 May 2019 22:17:37 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 07 May 2019 22:17:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=wsEEErK0Uqze+G0t1Z1dduXdbBsenDU ZM6UNY8lIHmU=; b=IB+ZsbxtdxP1rE95jKCbiu6Fv5/r+POimEjsq8JoObjprRF ZoFi9b1E4ZfjnX7OwshdQsORG8QWSaYoLPjuIUW4f4M27SpSPFM1Ume4dLVvQ4ks pGNWXcg6/XmCNB8z01bnPGPoy5ZcKayizpa4Z4jQtJ7DcOfN2t8AtnWgSVwEWcCM QN6VC4iBPKkq2KpbmBBziEsahVNIHhiHHZKyFSpVGpmdM2/JDvbTCrJlVue5KUI1 V60P/B2pWSBQ8gCFiJqmFxovVt7C5lnx4cnnb7XOsxWBd8m5uC4+rWtPE1pnWo/t mnW8sEzlLHi/pUbTQs+1rtV2e7avG5erxIPvmZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wsEEEr K0Uqze+G0t1Z1dduXdbBsenDUZM6UNY8lIHmU=; b=yiapp5Ap2juEvzETHYZOC2 HayadodzMhxAUICCxAaL4PQvE8HdC6nuPvMJsuuq9pvxLh5Zdg2gctOGzkjuEQ6B KAo2dUkG7TPqsc6WwZwG9wPY62uCYeDZTnZQ/SvdXV7Sv88y03JApMlwk7T9s65q QKRnNNeXBCbRiA8cZuODbN1IwvsFqO1uyWJJ73lEmUDvCpB5i8EF9bNVKDJtnoGb gJ+OjlsJzZs39yMaarzqjT0gvbZzJEi9ifhBsuf6z91TCFBRYqJrZvHf+ZSs+Ijt tGSk4zdOtLFbZfE04wndF5juypvUxMJ9Sx2I5Yf1Kxdy6oAgoUPHqqaLeJxJaIhg ==
X-ME-Sender: <xms:QTzSXLveQNJiqEGlVG8rBETX7yYSxMOSdoMxJhU6CT2v6Cst7ECLIQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkedugdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:QTzSXGGKsycTTS1gQqViqW7bQHw661EFzdyNgYq13EiVCzV2twYSyg> <xmx:QTzSXOwIA5cv8wVnQBCJEITeo9Z6h0cr74GquQUIRd2_6Dii6Nx51Q> <xmx:QTzSXNjcXBwNbVrX0pE0cKWANuYMkmPI5n-DAhJKs2B2z4FjgIp89Q> <xmx:QTzSXIrGOfm9LHfAzAQvS3rwUZbOHy2Cm9EC_V91esQLfHPSNvvxCw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCBDC7C3DB; Tue, 7 May 2019 22:17:36 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1
Mime-Version: 1.0
Message-Id: <520aac30-6555-46e5-bba0-0810eec7c5d0@www.fastmail.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com>
Date: Tue, 07 May 2019 22:17:39 -0400
From: Martin Thomson <mt@lowentropy.net>
To: ietf@ietf.org
Subject: Re: deprecating Postel's principle- considered harmful
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/E0Ie02ozp33-vdrn5b_o_w6rhSc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 May 2019 02:17:40 -0000

(The discussion seems to have settled on ietf@, so I'm sticking to that.  Thanks to everyone who contributed to the now 70+ emails in my inbox.  Having to sleep while people are at work has that effect.  I'll try to respond to the main points, and to hell with my Narten score for this week.)

Though I think that I disagree with Deborah (and I'll explain why below), I think that her suggested title goes some way to capture the intent of this effort.  Yes, this is intended to deprecate the robustness principle.  To my mind, the meme that the robustness principle engendered is more of a problem than its application.  As Warren suggests, this is not an ideal, but a principle to be applied with due consideration, but that lesson gets lost.

In the time I've been doing the protocol-y thing and engineering more broadly, I've seen the principle abused more than it is applied with that sort of awareness.  To that end - and to Brian's request for a softening of the language - it's important to have a strong title.  I appreciate that this is less principled and more about marketing, but I won't apologize for that.

As Henning points out (and Barry also), application of the robustness principle results in technical debt.  I did consider using the phrase "technical debt" in the draft, but was unsure whether that term was well enough understood.  More seriously, "technical debt" has baggage that could be problematic in this context.  It's almost exactly the right concept - projects routinely take on technical debt in the process of getting stuff shipped and that is more or less what the robustness principle recommends.  As Matthew points out, we probably wouldn't have an Internet without it.  But the scale is different.  Individual implementations or deployments might be the ones to make the decision, but the cost of that decision can transfer to the entire protocol community.  If it were the decision of a protocol community to take on that debt, it would be less of a problem, but decisions are made by a few with fairly serious externalities.

Randy's anecdote about technical debt in SNMP was a good one.  Robert Sparks had a similar experience with SIP that we've discussed previously.  In these cases, the problem was eventually solved, but it wasn't cheap or fast.  Mark Andrews' example about DNS flag day shows that it doesn't have to be too expensive, but perhaps that you do have to be a little aggressive to get results.

Which comes to the Deborah's suggestion that this advocates for "forklifts".  I don't know how deploying patches turns into "forklifts".  Protocol changes don't necessarily imply big product changes.  What is relevant is time.  In a mail to the IAB, Stephen pointed out that the timescales on which changes can be made are highly relevant and that the document might be read as implying software update on the same timeframe as a browser might be updated.

While I firmly believe that software needs to be more responsive, in part because that is critical for security, I realize that some deployments are highly constrained in the pace at which fixes can be deployed.  In those environments it is appealing to have workarounds deployed rather than to find and agree upon systemic fixes.  The document could probably recognize constraints on deployment timelines better, but I don't think it invalidates the central argument.

As an aside, I've had the experience of meeting someone responsible a bug that our team spent weeks building and deploying workarounds for.  We quickly established that they were unaware of the problem, willing to fix it, and able to do so more effectively than we were.  It was intensely frustrating.  Several people attributed this sort of problem to incompetence/laziness, but I would never suggest that.  As both Tony and Adam were careful to point out, the reasons a bug manifests is not explained so trivially.

Christian pointed out that "modern" protocols are being better at defining error handling paths in an attempt to close off those opportunities for applications of the robustness principle.  (And yes, we have people being more strict.)  This misses what is, I think, the most positive change in how we build protocols.  Holes in specifications are being addressed collaboratively because people are talking to each other and because people are willing to make changes in implementations or specifications as appropriate.  That's not especially new (thanks again for the SNMP example Randy), but it is worth recognizing.

Brian lamented the unconstrained extensibility in CBOR, which I suggest is something that he should take up with the groups that are working on the protocol(s) he is talking about.  Even the idea that you might just go off and robustness principle the protocol until it works right is the whole reason I wrote this draft.

Christian also mentions IP extension headers and Henning multipart in SIP as potential counterexamples.  Cases where the spec is clear, but the implementations refuse to comply.  We've plenty of experience with this on the web also.  The remedy Henning suggests (have the community declare the feature dead and move on) is in my opinion the best thing to do; it's what CSS did and it worked out well, but it took ages to deal with the fallout.  Again, it took an active community with a shared understanding of the goals.

I'm very appreciative of the feedback you have all given on the draft.