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: 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 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\))
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/architecture-discuss/-4dQ1XNNGesAjZmcsv4cfBbANX8>
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: Tue, 07 May 2019 23:52:56 -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: [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