Re: [arch-d] deprecating Postel's principle- considered harmful
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 07 May 2019 20:45 UTC
Return-Path: <brian.e.carpenter@gmail.com>
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 1D543120226; Tue, 7 May 2019 13:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YyrHbddJqZRI; Tue, 7 May 2019 13:45:42 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 1EC8F12013A; Tue, 7 May 2019 13:45:42 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id j26so8901413pgl.5; Tue, 07 May 2019 13:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3FTMNcnHEgK9HtQeeusLCdCM8OEe6JDK/XREnOUjNnk=; b=I5vh5PzfQ0GX6XkJxPjxLAurGVw+NQ12O8vAsAV/sIzWbOmn8J5ApL31W+fnYWb/PF WdWzWTqSMxkKqtjsW6M0dsZxPVrv26YvKsN+fOeED3ekf/sfM+sO207c5s0fviNAAV8d B0IhLvXARYKlyaL4Fo5h1bAakG3KvopJGvBXOvCeMqVaUZYt9cqstBTUR7MtoJb3axi5 /RtPNBFqeZBpbenyTnYnLnw4VkOLbrDMMJm25b2SdIbTzGwwyUzmXmVWPmcFLn1eOeqS I8hZ/DAJwYmNCXOa/9z36cntFn1eO2R3JclNuQ23wBVqInReaa+gi5Q42Julz7YWRP55 1SZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3FTMNcnHEgK9HtQeeusLCdCM8OEe6JDK/XREnOUjNnk=; b=HJAczk1XIrPkdXOEa+MvyK6t/Lsg015Gx+/vzgrGozp41IjnH71fkpUs0BozwfuuBs FeIztHnu+grnkBGhxOl360xINJQAry2aqpKlTWrgAgRa8+H0MuUVGnk95rzrodVBMnbq VmwzGALmupxw0bm+iacmeQpV4RmOwPPjMsPKpn6eREIoxneB+6gxmFhms2J5VKNspFjE Ys9i7d7Qb6Fmb8TRKnipIxwbM4iXi0zpzYb0757+loIgHRgwWs5PDxJHtW4Gfl15Hv+c arYErdyI8Ur6aOhbcXuddhwpQVIs3y/g/gVLa4Ly+cBez7dy2c2DDIXhIOW1U5XuKGNS 3BTw==
X-Gm-Message-State: APjAAAWtm9YCM/9ICGqufQdwYjdq+raD2nbal5/yAFkzxVT/N3stuJJ0 uZVZR3MVBiR4Ssqu5IZMznr1LG+k
X-Google-Smtp-Source: APXvYqwEVtf+/lUiYJA624IeM+BH6ijUiAxbxIW/DgJXxACzj2D5rkGfXE4NgjAvEtcy0Css3ctmrA==
X-Received: by 2002:a63:c601:: with SMTP id w1mr42958341pgg.190.1557261940638; Tue, 07 May 2019 13:45:40 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id t5sm1659346pgn.80.2019.05.07.13.45.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 13:45:39 -0700 (PDT)
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, "iab@iab.org" <iab@iab.org>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, The IESG <iesg@ietf.org>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <a114ba7c-2247-5c38-3989-3ae7553c1345@gmail.com>
Date: Wed, 08 May 2019 08:45:35 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KE_osv-4NLYP3NUi4AKhjp88tTw>
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:45:45 -0000
Hi Deborah, On 08-May-19 07:17, BRUNGARD, DEBORAH A 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". Yes, thank you for saying that, I hadn't seen it so clearly. I do regret that we failed to discuss the robustness principle explicitly in RFC6709. However, it's in the background of https://tools.ietf.org/html/rfc6709#section-4.7 . > 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. I agree. I think that as a warning against blind reliance on the principle, the document is correct and useful. But IMHO that doesn't justify the title, or the recommendation in the Abstract. To be constructive, I suggest: Title: The Unintended Consequences of the Robustness Principle Abstract (last sentence): For a protocol that is actively maintained, the robustness principle can often be avoided. If there was a Conclusions section, I expect I'd have a suggested change for that too. > Hopefully more folks will read it- > (probably discussion is more appropriate on the architecture-discuss list) Yes, but that list is generally very quiet, unfortunately. Brian > 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= > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >
- 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