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
>