Re: [arch-d] deprecating Postel's principle- considered harmful
John C Klensin <john-ietf@jck.com> Wed, 08 May 2019 13:10 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AE91200FE; Wed, 8 May 2019 06:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 co07pzZ8zhOk; Wed, 8 May 2019 06:10:37 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49F81200F6; Wed, 8 May 2019 06:10:37 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hOMLE-0003Sh-6y; Wed, 08 May 2019 09:10:36 -0400
Date: Wed, 08 May 2019 09:10:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: architecture-discuss@ietf.org
cc: ietf@ietf.org
Message-ID: <99FE5EE91CE738A39D99CAC2@PSB>
In-Reply-To: <BA365F84-3BD8-4B6B-B454-B32E4B6B6D23@piuha.net>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.c om> <CAHw9_iKE9SSOK_9AUpoMaS9pGz91LuJr1_HNv0B-6RxT_rb2dw@mail.gmail.com> <BA365F84-3BD8-4B6B-B454-B32E4B6B6D23@piuha.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/OOQncrtHhbOW23Bq3PyHerrS5fM>
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2019 13:10:40 -0000
Hi. Having read through this long thread, I want to add one perspective, very nearly contemporaneously with when the robustness principle was first enunciated, that complements several of the comments that have been made, especially by Rich, Joe, and Jari. When one is designing and writing standards in almost any field that involves significant complexity, there is an almost inevitable choice between: -- trying to specify every possible detail so that an implementer knows what to do in every case and for every design choice, including what is supposed to be done about each variety of deviation from the standard by others. -- specifying the normal cases and general philosophy of the design or protocol and trust that, with a bit of guidance, implementers who are reasonably intelligent and acting in good faith will sort things out correctly. We know a few things about the first option. It causes the standards development process to take much longer than the second. Because standards designers are not infallible, it is prone to errors, errors that could make the standard completely unworkable. For at least some protocols (or devices), it may not even be possible unless there are complete and deployed implementations around that can be examined and analyzed, preferably in combination, in trying to build the standards. The IETF, its predecessors, and the Internet community more generally, have tended to pick the second option. As someone else pointed out, the three-stage standards process was intended as a mechanism to be clear about what we did and didn't know and what we were prepared to pin down and insist on, with Proposed being close to "preliminary specification for testing and evaluation" and an assumption that no enterprise in its right mind would deploy an implementation based on a Proposed Standard into large-scale production. In the context of that choice, the robustness principle is a guideline about how to think about and deal with the unanticipated cases and the cases that were not considered important enough to specify in detail, enough detail to cover "what happens if someone else sends bad stuff". It is not robust (sic) against grossly sloppy behavior, stupidity, or fools, much less damn fools. Any implementer who effectively says "I know I sent you garbage, but the robustness principle obligates you to accept it an cope" has missed the point and deserves, at least, community derision. Those aren't problems with the principle itself, much less grounds for deprecating it. They might be arguments for specifying a bit more (and, again, that is where the three-stage, or at least the two-state, standards process were supposed to help). By contrast, if one does want to deprecate the principle, realize what that is likely to do to increase the requirement to specify _everything_ exactly and, in the presence of almost never using even the two-stage version of the standards process, the requirement to get everything right the first time. People are already complaining about how long it takes the contemporary IETF to develop and finish a standard (in some cases taking work elsewhere as a result); consider the impact of an increase in that time. Certainly we've seen enough abuses in the name of the robustness principle that some clarification, especially about applicability and context, are in order. But those who want to throw it away should start working on the IETF's epitaph. best, john
- Re: [arch-d] deprecating Postel's principle- cons… BRUNGARD, DEBORAH A
- Re: [arch-d] deprecating Postel's principle- cons… Barry Leiba
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Brian E Carpenter
- Re: [arch-d] deprecating Postel's principle- cons… Andrew G. Malis
- Re: [arch-d] deprecating Postel's principle- cons… Barry Leiba
- Re: [arch-d] deprecating Postel's principle- cons… Warren Kumari
- Re: [arch-d] deprecating Postel's principle- cons… Tony Li
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Adam Roach
- Re: [arch-d] deprecating Postel's principle- cons… Salz, Rich
- Re: [arch-d] deprecating Postel's principle- cons… Joel M. Halpern
- Re: [arch-d] deprecating Postel's principle- cons… Adam Roach
- Re: [arch-d] [IAB] deprecating Postel's principle… Christian Huitema
- Re: [arch-d] [IAB] deprecating Postel's principle… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Matthew Kerwin
- Re: [arch-d] deprecating Postel's principle- cons… Rich Kulawiec
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] [IAB] deprecating Postel's principle… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Christian Huitema
- Re: [arch-d] deprecating Postel's principle- cons… Brian E Carpenter
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Mark Andrews
- Re: [arch-d] deprecating Postel's principle- cons… Paul Wouters
- Re: [arch-d] [IAB] deprecating Postel's principle… Randy Bush
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… Jari Arkko
- Re: [arch-d] deprecating Postel's principle- cons… John C Klensin
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Phillip Hallam-Baker
- Re: [arch-d] deprecating Postel's principle- cons… Bless, Roland (TM)
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Henry S. Thompson
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… S Moonesamy
- Re: [arch-d] deprecating Postel's principle- cons… Eliot Lear
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… Eliot Lear
- Re: [arch-d] deprecating Postel's principle- cons… Bob Briscoe
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Henry S. Thompson