Re: [arch-d] deprecating Postel's principle- considered harmful
Mark Andrews <marka@isc.org> Tue, 07 May 2019 23:52 UTC
Return-Path: <marka@isc.org>
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 B929C1202BA; Tue, 7 May 2019 16:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 h3k_6xU63Xzt; Tue, 7 May 2019 16:52:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1415120251; Tue, 7 May 2019 16:52:49 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1EB073AB060; Tue, 7 May 2019 23:52:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D1E9E160075; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 922A8160074; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uhfA_Zwe1CuN; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D58CF160054; Tue, 7 May 2019 23:52:46 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CACgrgBahawkXbyXoYHbwYSkfCG9zxn6M8jgwswDpcFjfZVcffw@mail.gmail.com>
Date: Wed, 08 May 2019 09:52:42 +1000
Cc: Christian Huitema <huitema@huitema.net>, "ietf@ietf.org" <ietf@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>, The IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6095149F-F4BE-400D-BD1E-F25BC60FDA8A@isc.org>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <CAA=duU1TxZx9W8huPp5md25Wf+9=f50WYGpU=Bb1OQ+OdF6k6A@mail.gmail.com> <CACgrgBYs95Q4hb=y-6i7SW9mEx9Bg-gp0TrpAYpsP-aODSx+YA@mail.gmail.com> <eb979c24-e9d2-4ebb-1d4b-94b8c9aa16e1@huitema.net> <CACgrgBahawkXbyXoYHbwYSkfCG9zxn6M8jgwswDpcFjfZVcffw@mail.gmail.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UdbGRYfPj5Isjk48F_0MxEqLIoA>
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: Tue, 07 May 2019 23:52:57 -0000
The fix for that is to implement the new feature and get customers to log bug reports against the other implementation. It does work. Even Fortune 500 companies listen to their customers. Implementations can be fixed and with regular update mechanisms in place the fixes do get deployed. In early 2018 the open source DNS vendors declared a flag day on Feb 1, 2019. We where no longer going to treat timeout as “the server doesn’t understand EDNS”. I.e. we where intending to deliberately break interoperation with servers that where stuck in the last century. We set up a site where you could test your servers to see if your servers where broken. We also had that site report a whole lot of other EDNS protocol violation. You got RED if there was a fatal fault, ORANGE if any other fault was detected and GREEN if the server passed the test queries. The number of sites which would get RED was << 1 in 10000. We advertised this flag day, in a number of places. The testing server got overwhelmed and DNS vendors with broken servers got thousands of “this site says your product is broken, when are you going to fix it” complaints. Implementations got fixed and the fixes got deploy. This included firewall vendors fixing their default blocking rule. https://ednscomp.isc.org/ has lots of graphs which show failures of various populations of servers and how things changed in the lead up to Feb 1 and later fixes being released and deployed. In particular https://ednscomp.isc.org/compliance/ts/au.optfail.html show Microsoft fixing their servers (see the “echoed” line). The Jan 28 was when they fixed their Azure service. The drop around April 11 is when fix pushed out in the March patch Tuesday release started to take effect. The March 1 failure spike was when one of the links from the testing site started dropping DNS UPD packets but passed DNS TCP packets. It took a couple of days to track down the bad (wrong style for the conductor) RJ48 connector that caused that failure. > On 8 May 2019, at 8:53 am, Henning Schulzrinne <hgs@cs.columbia.edu> wrote: > > It's kind of the inverse robustness problem - lots of perfectly-well documented protocol features are not usable in practice since they break "lazy", but important, implementations. The SIP crowd will remember the endless discussions about MIME multipart. > > In those cases, it would probably be wise to simply declare that a well-intentioned feature is no longer recommended for new implementations and possibly look for alternative options. (We seem to get into the circular arguments of "We need X", "use standard mechanism M to do X", "but none of the major implementations do M and are unlikely to in the foreseeable future", "but we cannot have two ways to do X and M is actually a better idea"; wait two years; repeat. Alternative: people develop a kludge that kind of works.) > > The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to catch this, but that process protocol path obviously was also rarely exercised. > > Henning > > > And then for a counter example, also related to IPv6. The IPv6 specs > allows implementations to insert a variety of intermediate headers > between the IPv6 header and the transport packet, but many router > implementations just don't like that and slow down or drop packets if > such intermediate routers are present. A case where the spec is arguably > too permissive, or the implementations too strict. > > -- Christian Huitema > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- RE: deprecating Postel's principle- considered ha… BRUNGARD, DEBORAH A
- Re: deprecating Postel's principle- considered ha… Barry Leiba
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Brian E Carpenter
- Re: deprecating Postel's principle- considered ha… Andrew G. Malis
- Re: [arch-d] deprecating Postel's principle- cons… Barry Leiba
- Re: deprecating Postel's principle- considered ha… Warren Kumari
- Re: [arch-d] deprecating Postel's principle- cons… Tony Li
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: deprecating Postel's principle- considered ha… Adam Roach
- Re: deprecating Postel's principle- considered ha… Salz, Rich
- Re: deprecating Postel's principle- considered ha… Joel M. Halpern
- Re: deprecating Postel's principle- considered ha… Adam Roach
- Re: [IAB] [arch-d] deprecating Postel's principle… Christian Huitema
- Re: [IAB] [arch-d] 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… Randy Presuhn
- 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: deprecating Postel's principle- considered ha… Martin Thomson
- Re: [arch-d] [IAB] deprecating Postel's principle… Randy Bush
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… Masataka Ohta
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: [arch-d] deprecating Postel's principle- cons… Jari Arkko
- Re: [arch-d] deprecating Postel's principle- cons… John C Klensin
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Phillip Hallam-Baker
- Re: deprecating Postel's principle- considered ha… Paul Wouters
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: [arch-d] deprecating Postel's principle- cons… Bless, Roland (TM)
- Re: deprecating Postel's principle- considered ha… Paul Wouters
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… John Levine
- Re: [arch-d] deprecating Postel's principle- cons… Keith Moore
- Re: deprecating Postel's principle- considered ha… Brian E Carpenter
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Keith Moore
- Re: deprecating Postel's principle- considered ha… John C Klensin
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Martin Thomson
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… S Moonesamy
- Re: [arch-d] deprecating Postel's principle- cons… Lloyd Wood
- 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… Joel M. Halpern
- Re: [arch-d] deprecating Postel's principle- cons… Bob Briscoe
- Re: [arch-d] deprecating Postel's principle- cons… Phillip Hallam-Baker
- Re: [arch-d] deprecating Postel's principle- cons… Masataka Ohta
- Re: [arch-d] deprecating Postel's principle- cons… Aaron Falk
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Henry S. Thompson