Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 05 November 2019 01:13 UTC
Return-Path: <brian.e.carpenter@gmail.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 F3D18120874 for <architecture-discuss@ietfa.amsl.com>; Mon, 4 Nov 2019 17:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 Qg7h1b1Y5bPp for <architecture-discuss@ietfa.amsl.com>; Mon, 4 Nov 2019 17:13:30 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 A7712120911 for <architecture-discuss@ietf.org>; Mon, 4 Nov 2019 17:13:30 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id n13so2163946pff.1 for <architecture-discuss@ietf.org>; Mon, 04 Nov 2019 17:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=YUhnxTmgc+FWSiqO7tDEestw1hag5mgJW64avGssIEL3DCB2/qoUrgpa3XjC00L74U NfwZVY5VT68ELn/KRW0UEBZBMNLSevMDlD78zFhLx/+IqLYTOav+nADImQnpzB6OHg0n GDse3jw/omxevwo9K+TUnv5SAmFxV9H0N+7FPzRSDMjjE5688c6Dus7EA0iWxfz3YT4Z q4FnVXA0BfllkRSOCseIgjIRK66HIJKUrRZsnLbb9YPrQ41eFYwv27Q/uhXY8DC9sdsk rYRaOoUEHWkCrBySEcRNADafwMiFsI/XjN54hkbDnKN+71HweqJ3Xu0D29dUslMu74b6 kBig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=e1vmZu7DzbUmzxYR2R9pADANyvF7/QRVk6ADs2wQaeqVT5c221iGYwUp05zO7U7+Eb SWODITIB95aHeKPpBErKwKdnC+nLFc4i6xy66tcXudkwi+ZWYWbAbMTRbhCi1OXX06h+ cGz76ZcnrLhkloRGET3KEYKw9EiTYbn9uRClc5bRNZ1OFd+etRvt3VaP0NCMKfQAWEIa EO9IB6fEXT5jGBA95GDfAdnX/NTHK7wxPFDzDOa30e8zcoQ7coDn3f6demyxmNK9ASkE 5iPNPjmfhod25ibkFEwaPLrdwZkaxPLm5gsbWB3OoVpwgUvD1+gSETcvYkjiEueyi41Y IHPw==
X-Gm-Message-State: APjAAAXErRNTZcFCVa3toZ2mDZRu9vf86HFt+Z7WsfWd5naM8E7bAcht +N1l0IyYcxDsdY1dua9N4KowMW5r0lU=
X-Google-Smtp-Source: APXvYqxMdcnjWSjvXXTgMthK+Phc3/zhIv369iqGiJ+tf/FlNWhOFP4DYrhi8F10NvHBNkJUlnHC1g==
X-Received: by 2002:a17:90a:348c:: with SMTP id p12mr2719853pjb.105.1572916409769; Mon, 04 Nov 2019 17:13:29 -0800 (PST)
Received: from [130.216.38.14] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.14]) by smtp.gmail.com with ESMTPSA id r185sm17691096pfr.68.2019.11.04.17.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 17:13:28 -0800 (PST)
To: iab@iab.org, architecture-discuss@ietf.org
References: <157284936054.13440.20144182660413459@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <d6c4e7b7-1a43-7859-427a-35ebf1343fcf@gmail.com>
Date: Tue, 05 Nov 2019 14:13:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <157284936054.13440.20144182660413459@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/jBCAqATbCy0kzt8bR_59LNlWjCU>
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt
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, 05 Nov 2019 01:13:38 -0000
Hi, Thanks for the updates, but I still have concerns about this draft. > Abstract ... > For a protocol > that is actively maintained, the robustness principle can, and > should, be avoided. To be blunt, I don't think there is community consensus for this statement. Now the IAB can of course express an opinion, but for something as contentious as this, I think it needs to be labelled as an opinion statement, especially in the Abstract which tends to bias the reader's mindset. Or a more neutral phrasing could be used; for example: For a protocol that is actively maintained, the impact of applying the robustness principle should be carefully considered. > 1. Introduction ... > Ideally, protocol implementations never have to apply the robustness > principle. Or, where it is unavoidable, use of the robustness > principle is viewed as a short term workaround that needs to be > quickly reverted. In an ideal world, all implementations would be perfect, so the robustness principle would be unnecessary. But the very basis for it is that the world *is not* ideal and many implementations *are not* perfect. So, really, what is the point of the first sentence? And no, I don't believe it's a short term workaround. That's like saying: when I've finished testing my Python program, I can take out all the try:... except:... statements because I've fixed all the errors, so I don't need the except: cases any more. On the contrary - good engineers leave the exception handling in for ever. When they don't, planes crash. Is there really a consensus view in the community that "the robustness principle is viewed as a short term workaround"? I don't believe it. > 4. Ecosystem Effects > > Once deviations become entrenched, it can be extremely difficult - if > not impossible - to rectify the situation. I take the point. Sloppy usage of the robustness principle can indeed allow sloppy errors in the spec or in an implmentation to survive. But there's a trade-off that, IMHO, the draft does not recognize: non-robust implementations that do not tolerate sloppy inputs are bad for users trying to accomplish something. It's perfectly reasonable to argue that an implementation should have a strict mode, in which it logs errors etc., in a way that allows the detection of sloppiness at the other end. And I agree that this is of particular value during active development of the protocol and its ecosystem**. But I don't see any developer shipping code to the mass market that has strict mode on by default. I don't see any recognition of this reality in the draft. It's also correct to argue that sloppiness in certain security functions such as algorithm negotiation is never OK. ** If anyone here is masochistic enough to try my prototype of GRASP, they'll discover that its first two questions to the user are: Test mode (many extra diagnostics)? Y/N: Diagnostics for inbound message parse errors? Y/N: So yes, I agree with a lot of the points this draft makes. Regards Brian Carpenter On 04-Nov-19 19:36, internet-drafts@ietf.org wrote: > > 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-04.txt > Pages : 12 > Date : 2019-11-03 > > Abstract: > The robustness principle, often phrased as "be conservative in what > you send, and liberal in what you accept", 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://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 > https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-04 > > > 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: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Brian E Carpenter
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Joe Touch
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… BRUNGARD, DEBORAH A
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Carsten Bormann
- Re: [arch-d] [IAB] I-D Action: draft-iab-protocol… Ted Hardie
- Re: [arch-d] [IAB] I-D Action: draft-iab-protocol… BRUNGARD, DEBORAH A
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Bernard Aboba
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Paul Ebersman
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Randy Bush
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… John Levine
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Bernard Aboba
- Re: [arch-d] I-D Action: draft-iab-protocol-maint… Stewart Bryant