Re: deprecating Postel's principle- considered harmful

Warren Kumari <warren@kumari.net> Tue, 07 May 2019 20:54 UTC

Return-Path: <warren@kumari.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 9A51E1202CC for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 13:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 pyC-PFoWgVq2 for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 13:54:13 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 08DD4120285 for <ietf@ietf.org>; Tue, 7 May 2019 13:54:13 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id d13so3821494qth.5 for <ietf@ietf.org>; Tue, 07 May 2019 13:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Win2FeVyu/f65VlAY3qIWmwRn++FtxvJJXCa0v/HYoE=; b=aWjDijHaaeTScnEytA7uubUB/4LmcnjLJcHu9uUqN3lnQ6MP4IUL/bt3BLUoXbPaOX G0+TuSpXvvEuMyUbzypPrixIQtigMF5rEoOKiBaRmk2KS6vfxClY4rCIyRA3XgfHFCn6 XK6/SxTxg0/BaH1EX+IaHdw65Bx3BGoisiE6LArX47s3OpzHd76fyt8wU7cu9UZtGs1X pxG4K5pET0pbesJ0UAqcoCnfVf/X1rpuTszpYjfvgMcgHRp/WsJ1UP73mOdk65g9qNaB Kka8fF/kt+0XCVdFYl7uFtZ8yj5wFtB2OZfE6gF9+us1AI2uicyXbtN/LtMgu7D6LUiI uEGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Win2FeVyu/f65VlAY3qIWmwRn++FtxvJJXCa0v/HYoE=; b=j81DmiNge4W7Pxau0pIzpdFQVGDysag7VwXnea1eYuP26aZGucI75OXSLr/JAqac9Q YXQ0RSkP4MyF/wsqJ/nUvNlteSqKt6Kg9riZlZItiI/STBZeM6cYtjOQv3gL5UQSIQUm u1c7CizBsgk2PhqnEbU6OCcgVsHBwk5mjX5aJ/H7JGbVE8/4Nx3UmJOPQTdnkGt5NEWy qL+Yko4djEntjp3cWvEaZe723w+nLbq/G8xRLRjzBrJW91cbFhK0AeTp68QHDb1JiUMZ 0MB4o8vFUv38x7LOS62ztJos6yXp4wAJvIt2t8xi8OVjT/oN2WEXanku3RAwHeoZHHjx 7T6w==
X-Gm-Message-State: APjAAAV9XiKhXG5KzMpSIqLtuIrc6mLLjndqtztFOcBFE1B4gBkIHElw NUp97WeUeRvDoK+4TXe+X3z6ATTqaHvxDa+LFj+2pA==
X-Google-Smtp-Source: APXvYqxUdjBhh5xOe7d7hQdbzFXxhadHDaFrVM4sXTc4ovjmRVX6NwF2FBN7yHgr/OI8gVtG2Z9hZeWGT/LmoP0cgQE=
X-Received: by 2002:a0c:a94b:: with SMTP id z11mr28067699qva.166.1557262451637; Tue, 07 May 2019 13:54:11 -0700 (PDT)
MIME-Version: 1.0
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com>
In-Reply-To: <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 07 May 2019 16:53:34 -0400
Message-ID: <CAHw9_iKE9SSOK_9AUpoMaS9pGz91LuJr1_HNv0B-6RxT_rb2dw@mail.gmail.com>
Subject: Re: deprecating Postel's principle- considered harmful
To: Barry Leiba <barryleiba@computer.org>
Cc: "BRUNGARD, DEBORAH A" <db3546@att.com>, The IESG <iesg@ietf.org>, "iab@iab.org" <iab@iab.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004098be0588526b45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ewdQw7wLQzSYKjc3Lv5v9V8dNnI>
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 20:54:21 -0000

On Tue, May 7, 2019 at 4:29 PM Barry Leiba <barryleiba@computer.org> wrote:

> I think the questions Deborah raises are layer-dependent, and it's
> likely that I agree with Martin more than Deborah does exactly because
> Martin and I live at the same layers.
>
> > It just erroneously blames Postel for sloppy implementations.
>
> Blaming the principle isn't the same as blaming Postel; the point here
> isn't so much that "Postel was wrong" as it is that there are many
> consequences of adhering to that principle that Jon didn't anticipate.
>

s/consequences of adhering/consequences of blindly adhering/

It's the robustness *principle*, not the robustness law; as with most
principles, it should be applied with thought and consideration.

If the principle is completely ignored, one ends up with ossified
protocols; every bit has to be defined and checked - and we cannot easily
extend (things like GREASE exist so some extent to stop this). If it is
strictly followed then I should be able to send you "Hel ow Brry, hwz leye
f?" and expect you to be able to cope with it.

The principle should be applied judiciously (sometimes it isn't), not
discarded.

W


> The classic cases here are in email and web applications, where what
> one might call "loose" use of the protocols has resulted in some real
> messes.  Acceptance of badly formed messages has led to widespread
> sending of badly formed messages, to the point that it's caused
> problems with the integrity of the email system.  In web applications,
> poor implementation of things like character set and content type
> labelling has resulted in great difficulty in figuring out what
> character sets and content types are really meant.
>
> So the general thing is that if we were *not* liberal in what we
> accepted, from the start, aberrant implementations would never have
> worked in the first place, and would either have been fixed or died on
> the vine.  And that would have been far better for the Internet as a
> whole than what we have now, at least at the higher stack layers.
>
> My sense is that at the lower stack layers, we're *not* actually very
> liberal in what we accept, at least not in general.  Saying, there,
> that the principle we're talking about is correct and good for the
> Internet is really saying that the principle works only when it's used
> sparingly and in targeted ways.
>
> Barry
>
>
> Barry
>
> On Tue, May 7, 2019 at 3:18 PM BRUNGARD, DEBORAH A <db3546@att.com> wrote:
> >
> > Not seeing much discussion on this document on the lists, I put a twist
> on the title-
> >
> > I find the document (as currently written) is incorrectly interpreting
> the robustness principle as saying there is no need for clear rules on
> protocol evolvability/extensions. For example, section 6, "relying on
> implementations to consistently apply the robustness principle is not a
> good strategy for extensibility". In the routing area, we do have rules and
> we use the principle to ensure interoperability, as we don't have the
> luxury to do a "forklift". Section 8's "it is not always possible to
> produce a design that allow all current protocol participants to continue
> to participate", my question would be "but does it harm the network"?
> >
> > Actually most of the document confusingly is not contradicting Postel's
> principle but supporting it (except for the nuances which seem to condone
> forklifts). It just erroneously blames Postel for sloppy implementations.
> For the document to summarize saying "the robustness principle can, and
> should, be avoided" as it is harmful (I think) will be harmful to the
> Internet.
> >
> > Hopefully more folks will read it-
> > (probably discussion is more appropriate on the architecture-discuss
> list)
> > Deborah
> >
> > -----Original Message-----
> > From: IAB <iab-bounces@iab.org> On Behalf Of internet-drafts@ietf.org
> > Sent: Monday, May 06, 2019 10:40 PM
> > To: i-d-announce@ietf.org
> > Cc: iab@iab.org
> > Subject: [IAB] I-D Action: draft-iab-protocol-maintenance-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Internet Architecture Board IETF of the
> IETF.
> >
> >         Title           : The Harmful Consequences of the Robustness
> Principle
> >         Author          : Martin Thomson
> >         Filename        : draft-iab-protocol-maintenance-03.txt
> >         Pages           : 11
> >         Date            : 2019-05-06
> >
> > Abstract:
> >    Jon Postel's famous statement of "Be liberal in what you accept, and
> >    conservative in what you send" is a principle that has long guided
> >    the design and implementation of Internet protocols.  The posture
> >    this statement advocates promotes interoperability in the short term,
> >    but can negatively affect the protocol ecosystem over time.  For a
> >    protocol that is actively maintained, the robustness principle can,
> >    and should, be avoided.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Diab-2Dprotocol-2Dmaintenance_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=Fxp9wRoCVRJ_8BZBzY1MoExjRlVCegLbFtq8txcr6F8&e=
> >
> > There are also htmlized versions available at:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=aCbWfZ2WFHlTnh7WeiI8hJ_N04EoyW90y-Wuml8gLuA&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=lBVwS9yzx9lBmBEMA0cIidmh_hgRqGFclGMt6iNTPfw&e=
> >
> > A diff from the previous version is available at:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=JdV3Cux54CLr3GLrhc4SapVMu0mBchg-65xKrwqYPCo&e=
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> >
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=FA3-28RGBPX6oeQnIR42NBpfekSVh-BU7wyHCkuesdA&e=
> >
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf